Wednesday, December 16, 2015

More with smbclient, smbget, enum4linux

More notes because I can never remember and I'm sick of looking it up

Testing open shares/445

List shares with smbclient -L

root@localhost:~# smbclient -L
Enter root's password: 
Anonymous login successful
Domain=[MSHOME] OS=[VxWorks] Server=[NQ 4.32]

        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       
Anonymous login successful
Domain=[MSHOME] OS=[VxWorks] Server=[NQ 4.32]

        Server               Comment
        ---------            -------

        Workgroup            Master

        ---------            -------

Try to connect to the share

root@localhost:~# smbclient \\\\\\MEMORY_CARD
Enter root's password: 
Anonymous login successful
Domain=[MSHOME] OS=[VxWorks] Server=[NQ 4.32]
tree connect failed: NT_STATUS_ACCESS_DENIED


When it works

root@localhost:~# smbclient \\\\\\MDMLOAD
Enter root's password: 
Anonymous login successful
Domain=[DEMO] OS=[Unix] Server=[Samba 3.6.23-20.el6]
smb: \> l
  .                                   D        0  Wed Nov  4 02:42:15 2015
  ..                                  D        0  Mon Oct 12 20:38:40 2015
  input.csv                           A     2024  Mon Nov  2 22:13:18 2015

59400 blocks of size 2097152. 19612 blocks available

enum4linux can help out when you have a bunch of shares to check or just want to do things quickly. -S to check shares, although you probably just want to do a -a for all.

root@localhost:~/enum4linux-0.8.9# perl -S
Starting enum4linux v0.8.9 ( ) on Tue Dec 15 22:34:52 2015

|    Target Information    |
Target ...........   
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none

|    Share Enumeration on    |
Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.12]
Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.12]

        Sharename       Type      Comment
        ---------       ----      -------
        www             Disk      Public Stuff
        IPC$            IPC       IPC Service (Samba Server Version 4.1.12)

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------

[+] Attempting to map shares on
//     Mapping: OK, Listing: OK
//$    Mapping: OK     Listing: DENIED
enum4linux complete on Tue Dec 15 22:35:09 2015

root@localhost:~# smbclient \\\\\\www
Enter root's password:
Anonymous login successful
Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.12]
smb: \> ls
  .                            DR        0  Sat Dec 12 14:23:20 2015
  ..                            D        0  Thu Oct  8 11:53:20 2015

 oops                           D        0  Fri Nov 27 17:38:04 2015

Want to download a whole folder?

root@localhost:~# smbget -R smb://
Username for www at [guest] 
Password for www at 
Using workgroup WORKGROUP, guest user
smb://   smb://            

enum4liux is also super handy internally as it tries multiple ways to get a domain SID, if successful it will brute force the SID to enumerate all the SIDs/user accounts for the domain.

Friday, December 11, 2015

Thoughts on the skills shortage

Sorry no meterpreter shells on this one.

Reading Trey Ford's article led me to want to put some ideas onto the blog that I've discussed at work and over beers but never here. So here it goes.

I'm not going to address each point rather I'm going to just share a few observations and opinions on the subject from my life/career.

1. I don't do any hiring but I can agree that there may be a lack of skilled mid to senior people in the market.  At every place I've worked it was always difficult to find qualified people to just to interview let alone hire. The fix, we/us/you/me need to grow them (more below).

1a. What I don't see is a shortage of INTERESTED junior people. There are tons and tons of people that want to get into infosec but sadly everyone wants mid to seniors and they don't want to train juniors.

2. It CAN be hard to afford people, especially  in expensive places like SFO/Silicon Valley, DC Metro Area, NYC, etc.  However, there is a real reluctance to allow remote workers, so when you base your HQ in an expensive area, or a place with a crappy commute AND don't allow remote employees then you don't get to complain that people are asking for lots of $$$.  Valsmith touched on this in a post as well; (

That being said, I know a lot of people want to make a difference and do cool shit and they are willing to take slight pay cuts to do this (also mentioned in Trey's article). Management should keep this in mind.  Also, maybe its less the pay and more the sense that it's going to be impossible to make impact in your organization. That's what keeps me from wanting to go back to doing gov work.

3. There is a clear problem with senior people getting upset that people "get trained" and leave the company.  Bottom line, we shouldn't get upset.  Every person that goes from junior to mid or mid to senior and moves on to another company brings those skills with them and improves the other company and Security as a whole. Less companies getting pwned or more companies being able to react better/faster to attacks is a good thing.

We should reframe our thinking of not wanting to pay to train someone else's employee and more on we need to grow literally as many security people as we possibly can for our industry. Every company should think this way.

4. Have a FORMAL plan to grow your security people. An unamed CISO mentions this in Trey's article but saidly no details are given; 
“I like to work with entry level candidates on a 2-5 year growth path. I realize they may not be here forever, but I want to focus on giving them the right tools and a good experience.”
 I've  never had a job outside of the military that had a written plan to grow a security engineer/pentester from junior to mid or mid to senior. No required tasks or knowledge identified, no listed skills for my job role, no specific training to take, books to read, or anything to prove I was ready for that next level.  It has always been On the Job Training (OJT).  To be fair there is no replacement for OJT and its absolutely required to gain experience but there is no "growth path" when you rely on the whatever pentest comes in as what guides a person's development or whatever internal projects come up or fires to put out. I think we have attempted to rely on certifications to do some of this, and it does to an extent, but its general knowledge and not going to be organization or position dependent. Not to mention the whole value of certifications dilemma. 

You know who does have a plan to grow people from zero to competency? The military.  They take someone with aptitude (usually) but zero experience (well... assumes zero experience) and put them through training and testing with specific objectives and at the end they demonstrate proficiency in those specified tasks.

I'm not saying we need to get THAT formalized in our training but we need SOME plan on how to take someone with aptitude (and i'm going to make the assumption that if you got through college with a CS degree or demonstrate aptitude some other way) and repeatably train and grow that person from one level to another.

I don't know if we can do this collectively in a broad security community/PTES type sense (maybe we should try?) but i'd certainly like to see it implemented at a team level inside companies.

The second part of the article is also worth a read:



Friday, November 20, 2015

CVE's & My Vuln Disclosure Experience

Back in January I received my first CVE; CVE-2014-9354


The reference above, like usual, gives no actual information. Luckily, the bug was simple enough. Once you log in to the Netapp interface, on the page that contains the page (Active Directory tab) to enter in some domain credentials, you can view source and see the starred out credentials in the source of the HTML. Party like its 1999!

Netapp was responsive and easy to work with, I asked that they request a CVE which they did, they were forthcoming with fix information and the time line for patch release. The overall experience went, more or less, like I think it should.

The second experience was much worse. I attempted to obtain another CVE for some vulnerabilities myself and @javutin found with the Steelcase RoomWizard product.

I discovered the RoomWizards were running a vulnerable version of Apache Struts making them vulnerable to CVE-2013-2251. This led to Remote Code Execution as root.  We found another issue where the HSQL database with sa/null is exposed by default. This allows you to retrieve the administrator password which then allows you to ssh into the device. A CVE (CVE-2015-2879) has been reserved for this issue after directly contacting CERT/CC as the vendor declined to request one. The struts vulnerability was slightly more interesting because the device runs as root.  An example of the vulnerable request requesting the output of whoami (and response) is shown below.

The exploit was simple enough, I just had to add the arm payload to the existing Metasploit struts module and add the vulnerable URI.  Module is here. Screenshot below:

My Initial contact with them was March 5th, 2015 and the fix came out Oct 19th 2015 (8 months). I’ve included the vulnerability timeline below for additional information and lolz.

Disclosure Timeline

3/5/15 - Initial contact with Steelcase and request PGP key to send details
3/10/15 – Receive PGP key
3/11/15 – Send vulnerability details and request Steelcase request CVEs for the issues
3/16/15 – Send follow up email requesting confirmation of receipt of vulnerability details
3/16/15 – Confirmation Steelcase received and could view the vulnerability details
3/30/15 – Request an update
3/30/15 – Steelcase responds they will fix in June/July with next firmware update
4/23/15 – Follow up on CVE request
4/28/15 – Received no response to 4/23 email, emailed again
4/28/15 – Receive response from Product Manager. States “As you know, we are implementing a fix in the next firmware version, slated for release later this Spring. We plan on holding communication and publishing a CVE until that time.”
6/18/15 – Request clarification on Spring answer as it is now June
6/18/15 – Receive response that Firmware is in alpha testing and expect release July/Aug
6/18/15 – Ask again if Steelcase will be requesting CVEs for the issues
6/18/15 – Receive an Affirmative response “Yes, to my knowledge we will but I’ve cc’d some principals who would be involved in the actual submission to be sure.”
7/8/15 – Received no reply from the principals, asked again
7/14/15 – Received no reply to 7/8 email, emailed again
7/16/15 – Email again stating lack of response is disappointing since they were 30+ days over the normal 90 day fix/disclosure timeline
7/20/15 – Receive reply. Steelcase will not apply for CVE. States “After internal discussions, we have decided not to apply for a CVE. No other devices are built upon the RoomWizard platform and the device itself is generally in a controlled environment.” Also states 4.5 move into Beta testing next week.
8/20/15 – Request an update as no updated firmware had been released and no other communication from Steelcase
8/20/15 – Receive response “We are going to Beta testing next week with anticipated release two weeks later, assuming positive results.”
8/20/15 – Reply back : “30 days ago you said it was going to beta testing next week?!?!”
8/20/15 – Steelcase replies “We found some bugs in Alpha testing that we felt it was imperative to fix before releasing at customer Beta sites.” Asks if we want the beta software, we decline.
9/28/15 – Request update as it has been another 30 days
9/29/15 – Steelcase replies the updated firmware should be available on Oct 19th 2015 along with a new version of the Administrative Console (required to install the new firmware)
10/19/15 – Steelcase emails me (!!) that the updated firmware has been released


Thursday, November 5, 2015

The Reason Why

If you are curious as to they the Government and big business are discussing infosec skill gaps, the ability to fill contracts and get quality work, the following video outlines it pretty well: 


Friday, September 25, 2015

Domain Controller Machine$ Account To Dump Hashes Notes

In case you missed it, Mubix posted this post a few days ago:

The great part of the post in case you didn't see/understand is that you can dump hashes from the domain controller using the Domain Controller machine account (example: CORP-MYDC$).  So finally a use for all those machine accounts you normally just cut out from pwdumps :-)

Whats also important about this from the defensive perspective is you can roll the krbtgt password but if an attacker still has the ability to talk any domain controller (and at some point dumped the full domain hashes) they can attempt to re-pull the hashes or most importantly the new krbtgt hash to create new golden tickets.

I'm going to steal Rob's impacket secretsdump output here in case it disappears in the future.

python -hashes aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 -just-dc LAB/DC2k8_1\$@

Impacket v0.9.14-dev - Copyright 2002-2015 Core Security Technologies

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets

Note: this is a 1-to-1 functionality, meaning DC2k8_1 hash needs to authenticate against DC2k8_1 IP address. If you do this against DC2k8_2 obviously it will fail.

Not sure on how to address this honestly.  More frequent machine password changes for domain controllers may be in order and initial reading says you can use netdom.exe to make the change as well. More info here: < --netdom.exe info

If anyone has resources/suggestions on managing this please post up.


Wednesday, September 23, 2015

Ways To Load Kerberos Tickets

Everyone is aware of the awesomeness that Mimikatz is and most likely golden tickets. Mimikatz ships with lots of kerberos functionality.

Just wanted to jot down some quick notes on using these tickets.

1. See the links in the resources section to generate a golden ticket.  Chris Truncer's post is more than clear on how to do it, so I wont reproduce the content. What's more interesting (to me) is that you can generate these tickets offline on a host that is not connected to the network you are working on.  This is perhaps handy if you have a bunch of host instrumentation on the network you are attacking and don't want to risk uploading and running Mimikatz on the host.

2. With this .kirbi ticket created you now need to load it into your session. You have a few options:

  • Mimikatz via Pass The Ticket (ptt) functionality
  • You can load it via the kiwi module in meterpreter -- stealing Chris' image here:

    • Via WCE kerberos functionality
      • -K              Dump Kerberos tickets to file (unix & 'windows wce' format)
      • -k              Read Kerberos tickets from file and insert into Windows cache
    What's important to note here is that WCE will NOT load a Mimikatz generated ticket (didn't try ccache format). What you CAN do is  load the ticket via mimikatz on your offline host then export with with WCE, then upload WCE and the WCE ticket (wce_krbtkts) to the host and load it into the cache there.

    3. Depending on the type of alerting when you make a ticket it uses the 500 account by default. Assuming you aren't spoofing that particular account you might get the added bonus of having your actions attributed to another account.

    Additional Gotchas

    1. CT's post uses a fake user. If you do this, according to @gentilkiwi you have to use the ticket within 20 minutes of creation.  Mimikatz does let you create a ticket in the future with the  /startoffset option
    2. Impacket currently (5 SEP 15 --this post will be published later) will NOT work with a fake or inactive user where windows will let it slide.  So if you make a golden ticket you need it to be with an active user.  I suspect beto will fix this soon.
    3. There is a lot of guidance around detecting this attack by using looking for tickets with a 10 year lifespan (this is the Mimikatz default). You can avoid this using the /endin option with Mimikatz.  More here from MS:



    Saturday, September 5, 2015

    DevOps Days DC 2015 Talk Video

    Here is  good copy of Ken and I's DevOps Days DC talk:
    "DevOops & How I hacked you"

    DevOpsDays DC 2015 - 30 - DevOops & How I hacked you - Chris Gates, Facebook & Ken Johnson, nVisium from on Vimeo.

    Tuesday, August 18, 2015

    Metasploit + VHOSTS in mass

    maybe this was a solved problem but I couldn't find a solution online.

    Problem #1:

    Metasploit RHOSTS takes the file parameter so you can pass in a list of ip ranges. It will also take hostnames  as long as they resolve. If you have giant list of stuff and one of them doesn't resolve then the RHOSTS wont load and you'll want to cry.

    Problem #2:
    Lots of proxy/WAFs/websites in general require the VHOST to be set.  Metasploit ships with tons of great auxiliary modules for http stuff but there isn't really a nice way to load a list of VHOSTS along with the list of IPs.

    Resource scripts to the rescue!  A simple read file and setting RHOST and VHOST for each attempt at an aux module seems to get it done.  I've created a gist with the script.  Wait, what about Problem #1?  The module will just error out on the single RHOST that doesn't resolve and just move on. Now you can have a file full of stuff that doesn't resolve mixed in with stuff that does and it should plow on through. :-)

    Resource script to get it done



    Sunday, June 14, 2015

    Hard to Sprint When You Have Two Broken Legs

    Today I saw this article: White House Tells Agencies to Tighten Up Cyber Defenses Immediately.

    By Valsmith

    Now as a disclaimer, I don't work for the government so there is a lot I don't know but I have friends who do or who have in the past and you hear things. I also pay attention and listen to questions I get in my training classes and conference talks.

    This directive from the White House is laughable for a number of reasons and demonstrates just how out of touch decision makers in the Government are on these issues.

    1.) Technically skilled people have been BEGGING to improve cyber security in the government for well over 15 years. I don't think this is any kind of secret, just google for a bit or talk to anyone who works in government in the trenches. Asking for staff, tools, budget, authority, support and getting little of it. In a way, this directive is insulting to them after years of asking, trying and failing suddenly someone says: "oh hey I have an idea, why don't you go and secure stuff!". Right.  Unless you are going to supply those things they need RIGHT NOW, they will fail. And government procurement and hiring organizations are notoriously slow so the chances of that happening are slim.

    2.) IT Operations. The first thing that has to be in place for there to be any real chance is solid IT operations. Organizations have to be able to push out images and patches quickly, orderly, and with assurance. Backup recovery, knowledge of inventory, well managed systems, etc. are all paramount. Do you know how most government IT operations are managed? By contractors, aka the lowest bidder. These are the Raytheons, Booz Allens, Boeings, Lockheeds, etc. who bid on large omnibus support contracts, win them, and THEN try to fill the staffing requirements. How do you win the lowest bid in services / support contracts? By keeping staffing costs down, aka paying the lowest possible salaries. This results in some of the most piss-poor IT operations in the world. You want to know why Hilary Clinton, former Secretaries of Defense, and numerous other government staff run their own private mail servers? Most likely its because their work provided email DOESN'T work. Slow systems, tiny inbox quotas, inability to handle attachments, downtime, no crypto or crypto incompatible with anyone else, these are just a few of the issues out there. And its not just email.  I have personally seen a government conference room system take 15-20 minutes to log in at the windows login prompt, due too poor IT practices. I was told that most of the time people resorted to paper hand outs or overhead projectors. Yeh like the ones you had in highschool in the 90s with the light bulbs and transparencies.

    Essentially what this directive is saying: "Hey you low end IT staff, winners of the lowest bid, who can barely keep a network up or run a mail server, make sure you become infosec experts and shore up our defenses, and you have 30 days to do it." Right. I have heard horror stories from acquaintances in the government of waiting 6 months for an initial account setup ticket to get performed. Weeks to get a new desktop deployed. It is idiotic to think that current IT operations can support this kind of request. But that is who typically manages servers, network and desktops, and who would have to deploy whatever security tools would be needed to do this in support of pitifully small infosec teams.

    3.) Infosec staff and hiring. There are none available. If they are good and employable they are employed at a better job making more money. And if there is, you (the government) can't engage them. The pay scales for well trained infosec professionals in industry are off the charts, regardless of degree or "clearability". Why would anyone in their right mind join a government agency (or worse a government contractor) and make 70k a year, be subject to clearance requirements  (how many hackers you know smoke weed?), and live in a place like Washington DC? Patriotism might draw some but that only goes so far.

    Many agencies have strict requirements for education standards, sometimes certifications, and years of experience. There are a lot of truly talented and skilled people who might be willing to fill these jobs but would never meet the outdated requirements that are designed for classic engineers and scientists. The government HR departments have not and maybe will never catch up to this fact. HR staff are not typically technically skilled, are not paid that great, and are trying to make decisions on things they don't understand or know much about. The deck is stacked against them being successful at recruiting and retaining the crack infosec staff that would be needed to achieve this directive. It also often takes 9 months on average to hire someone.

    There exist a number of highly skilled and trustable boutiques so maybe the government would engage them to do this work right? OH, sorry, these things have to be bid out. To the lowest bidder. Who has a war chest to wait through the 18 month, highly costly, contracting process. Who can meet all the government requirements for accredited accounting systems, policies and procedures for asset management, the FARs (10000000000000s of pages of regulations governing these sorts of contracts), and who can defeat an incumbent like a Lockheed or Bechtel with all their lobbying power, war chests, and former insiders now working as federal service sales staff. Commercial contracts take 2 weeks and have and NDA / MSA, maybe some insurance. That's about it, so from a business decision standpoint would you put your time into bidding on a government contract or pursuing commercial ones as a small infosec company?

    4.) Legacy systems. The government has everything you can imagine somewhere running something. I would not at all be surprised of OS2 Warp being in place somewhere. I have heard of VAXs running payrol systems. SPARC 10s as critical gateway servers for database applications. There is all this old stuff laying around, that few people understand anymore, that don't have great support or security guidelines, and often can't be updated. All a hacker has to do is compromise a windows workstation and wait for the victim to SSH, zmodem, telnet, or whatever ancient protocol they use to communicate to legacy systems and just take screenshots in order to get viably useful information. They dont even need to really know how to use the legacy systems to steal their data. Just hack someone who does and watch. To be fair this exists in industry as well, its not exclusive to the government, but it does greatly impact one's ability to fix security in 30 days.

    5.) The wrong decisions makers. Senior management in government agencies as well as politicians are often woefully inexperienced with cyber technology and security in general. A series of tubes, nuff said. But they don't always have or listen to advisers who are. I have heard of cases where in emergency knee jerk situations physicists are put in charge of designing cyber-security systems while the infosec staff are standing around holding their well thought out plans for addressing the issues wondering what just happened. Maybe we should have the IDS guy design the next missile system?

    And I'm not just picking on the federal government. Most states are in even worse shape. Few companies in the private sector could pull this off either. Especially any the size of a government agency.

    I could go on for pages describing reasons this directive is silly, but you get the idea. Maybe what is really needed here is a new Manhattan Project. When we built the bomb we went and found all the best people we could, incentivized them, removed most of the shackles, funded the hell out of them and LET them do what they are good at with smart guardrails in place to protect national security. Feynman was 24 when he was put in charge of a theoretical division group helping to work on the bomb. Put the right people in charge of the right components. It's a hard problem and we need a lot of smart people to figure out what to do, but here are some starting ideas:

    1.) Follow in Mudge's laudable attempt with the DARPA Cyber-Fast Track program and make it easier and quicker to engage small infosec firms.

    2.) Change the contracting guidelines for pricing on infosec services. We are not making bullets or other process based widgets where going with the lowest bid makes sense.

    3.) Change the hiring guidelines and either allow managers to make hiring decisions or train HR staff to understand the requirements better. Remove education requirements. PAY people competitive rates. (Govenment pensions are not what they used to be and neither is the stability of the job so stop acting like that is enough to make up for it).  Allow managers to fire incompetent infosec staff with a minimum of red tape.

    4.) Fix your IT operations! Get rid of the lowest bid contractor carousel and implement some real, performance based, competition! (When a new contractor wins they often just end up hiring the same people away from the old contractor and sucking just as bad).

    5.) Change clearance requirements (this would need proper compartmentalization to prevent problems) for infosec staff so that you can get some of those talented but unclearable people helping you somehow.

    6.) Figure out remote work. Nobody wants to live in DC.

    7.) Bring in smart infosec industry people, educate them on some of the problems and realities, and have them brainstorm to see what they might come up with. And I don't mean a bunch of Mitre and Booz consultants. I mean people with a proven track record in private industry. Partner them with your few strong government infosec staff and see what happens.

    8.) Stop talking about how you are going to "hire 1000 infosec professionals this year" or "fix security in 30 days" while the perfectly good private sector national resources who could actually help are languishing out in the world wishing they could while the big contractors rake in tax payer money and provide little value. You know where they are, go get them. Don't make them try to figure out the BAA process, its not worth it to them.

    In the meantime, good luck sprinting on two broken legs.



    Thursday, May 28, 2015

    Answers to Questions from the nVisium SecCasts Panel

    I was asked to be on on a panel for nVisium's SecCasts. Our episode should be out next week, so spoiler answers are below:

    If readers/friends/community want additional details on something let me know.

    Here are the answers to the questions I received ahead of time

    - What security projects are you currently interested in?

    * Still interested in metasploit.
    * current things I'm working on is pentesting at scale and continuously.  Pentest tools aren't great for diffing results across scans with large numbers of hosts.  It can be a challenge identifying all of X in an environment then performing actions against it to test for vulnerabilities.
    * osquery is pretty interesting

    - What technologies are you currently looking into?

    * Devops tools are really fun for me right now.  They are essentially botnet controllers...meaning they are designed to do a task against multiple machines quickly. Their security model leaves quite a bit to be desired. Their model is essentially, that if you can talk to the application you are trusted, which is horrible.

    * AWS has tons of neat things that I want to start looking in to

    * OSX exploitation

    - What are some of the latest offensive security trends?

    * Not sure this is necessarily a trend, but initial access vectors are always interesting to me. Especially as browser/memory corruption bugs are going away && they never ever work, pdfs/flash is better, default protections in office products, java has slowly been tightening the screws.  People will still open and run things but I wonder how that will look 5 years from now.

    * The concepts in server side browsing talk by Nicolas Gregoire is also interesting to me

    - How to use an internal RT in the best way
    * continuous testing
    * internal people have skin in the game
    * understanding the environment a bit more in a mature or well monitored enviro
    * breach assessments
    * training for other teams
    * not dropping problems on people and saying see ya
    * work with SOC/NOC/incident responders/application owners

    - What should defenders be concerned about or paying attention to?

    * Establishing a baseline of what is normal network traffic wise, so you can alert on what is abnormal (not trivial)
    * Effectively parsing tons of log data to create alerts on interesting events (not trivial)
    * Creating a system that encourages users to report suspicious things and have a team that responds to those reports in a reasonable amount of time. If you don't respond (in a reasonable amount of time) this very much de-incentivizes users to report (easier to do--at least from a technical perspective)
    * Know what you own and monitor it

    - What areas should security folks be focused on in the next 3-4 years?

    * How to make SSL/TLS, email encryption, 2fac more accessible to everyone
    * Bridging the gap between recommendation to fix and execution of fixes (not trivial). we can do better with our recommendations. A lot of time we say stuff like, have better passwords or dont allow X but sometimes stopping X is really really hard, no one knows the best way to do it or its going to be a lot of work to do that. It can be overwhelming to fix. see it next year on your pentest.
    * Engineering better tools for everyone to use. I'm SUPER guilty of releasing works for me code, but we need to do better about engineering good tools for more people to use

    - Having worked both sides (offense and defense), has this changed your perspective? If so, how?

    * Fixing is way harder than breaking.
    * Mature companies should be purple teaming, Where the offensive guys sit with the defenders to iteratively improve over time.  Removing the adversarial relationship is key for internal teams to work together in a better way.

    - What are your thoughts on the so called "stunt hacking" as of late and all the crazy branding behind vulnerabilities like shellshock, heartbleed, etc.

    * Behind most stunt hacking is a really bug/vuln/exploit.  I don't want those to go away. I also understand that people/businesses want to get paid and also that researchers have no control over the *PR releases* that marketing puts out though. At Lares we didn't win a RFP because someone had written a tool, the person selecting the company to do the work based the final decision on that. so I guess marketing is necessary evil.  However I'm a believer in putting the full issue out there. Checkpoint's dealing with the misfortune cookie issue is a good example of how NOT to do things in my opinion. they had enough time to come up with fancy marketing materials and clever name for the issue but never released exploit code.  Without code, no exploit, no exploit people don't give a crap. its sad but true. And the fortune cookie issue is a prime example. no exploit for it, no one cares, problem isn't getting fixed. Cool catchphrase and logo + exploit code == stuff gets exploited, fixed, and awareness generated...much better.

    - What is the security community getting right?
    * We are doing better with responsible disclosure despite some companies really really sucking at working with researchers
    * Volume of information being put out there via conferences & blogs...arguably too much

    - Where could the community improve?
    * Consistency of testing and reporting. PTES was an attempt at this but lots of work still to be done.

    * Touched on it above. we give crap recommendations to clients.  We need to do better on our recommendations to fix problems. it sounds trivial but we bitch and moan about clients being too stupid to do what we tell them but we give them little to no resources to actually fix issues.  Free business idea is for PT companies to partner with companies that can/want to fix these issues like hardening routers or creating secure baselines or GPOs.  most pentest companies don't want to do this, another camp says its a conflict of interest. The fix is to at least have a few places companies can immediately turn to get some help if the pentesters company doesn't want to do it.

    -Follow on by Rob: awareness trainings vs technical controls
    * Mostly in agreement. Technical controls should be better to prevent more things that we say users should catch/report.  On the other hand, security awareness transcends work and moves into home computer usage, education of others, and ideally more awareness in the real world (think 419 scams, 3 card monty scams, people selling you stuff door to door, etc). Facebook's Hacktober carries value all year long  so the human element of social engineering can not be fully fixed by technology.

    - Name the top 1-3 books you think every security person should read this year.

    *The Phoenix Project by Gene Kim  to understand how devops can work in an enterprise but also so we don't become the security guy with the black binder in the book who is perceived as doing nothing but creating unnecessary work.
    *Zero to One by Peter Thiel to understand what makes a good startup or idea (TLDR does the company solve a huge problem --aka go zero to one or does it just iterate on something somewhat solved). Its also a good way to see why companies in SV have some of the policies they have.
    * No Place to Hide by Greenwald (and Snowden) -- why and how it all played out is interesting despite your feelings on the action itself.

    - What are your favorite sites or resources for information, tools, etc.
    * twitter
    * blogs although it seems less and less people are blogging. Not sure where all that information is going
    * NoVA Hackers

    - What advice would you give a person entering the security field or who wants to get into it? 
    * Don't
    * Learn webapps
    * Learn python/ruby/javascript
    * Learn/have patience with clients. They aren't as smart as you (or as smart as you think you are) and have tons of other stuff to do besides fix the issues you found
    * If solving puzzles doesn't interest you, pick something else.
    * If you don't want to have to continually learn new things...FOR THE REST OF YOUR CAREER...pick something else.

    - (Assuming not answered in the previous question) What value do you place on a college degree (in terms of entering the field)?
    * Not required but there is something to be said for being a well rounded individual which the core/required classes they make you take in college attempt to make you learn.  From a life hacking perspective it has values as people automatically assume things based on having finished college or having a particular cert or having an MBA or whatever.  Not necessarily good or valid but it is what it is.

    -What's your favorite US and non-US security conference and why?
    * Troopers and BRUCON  but to be fair I haven't been to many EU cons and zero AP cons
    Derbycon for US con. I actually don't go to that many cons anymore. I'd rather be home with the wife and kids

    -Are you currently working on any security projects?
    * Not that I can currently share but maybe soon.

    -What are you general thoughts on crowdsource programs such as Bugcrowd or HackerOne?
    * Bugs getting fixed is always good. However, I think the payouts are too low for most bugs.

    -What recent research from the security community has excited you the most in the past year or has had tremendous impact (aside from Heartbleed)? 
    * BIOS rootkits, GPU rootkits, tools/techniques the NSA uses that were disclosed by Snowden.

    -Does the public really care about cybersecurity?
    * They care about their dickpics getting leaked or can be seen by the NSA ( but otherwise no.  Plus check out the stock for TJ Maxx, Target, any of these healthcare companies. Its not affecting them long term.


    Wednesday, May 27, 2015

    Answers on how to get started in Security

    I got hit up on twitter and email about how to get started in security by someone.  The question was pretty generic and since I didn't even receive a thanks back from the guy I'm sharing it with everyone else/archiving it in case I'm asked again in the future.

    The question:
    I want to become proficient at pentesting on computers and phones. I have a running version of Kali Linux on my computer and am using the "Kali Linux Cookbook" as a reference. What book or online tutorials would you recommend for me to use in order to get better? 

    A few things I think you should do to get started.

    1. Get rid of Kali. It is a shortcut to learning to have all these tools already there.  You'll learn way more by figuring out what tool you need for a job/task (feel free to use the index of tools in Kali which is readily available) and installing the tool yourself.  Ubuntu is the most supported hacker tool wise but there are other distros. Pick whatever suits you.  Use a VM so you can undo stuff if you break your distro but that's pretty rare these days. Most things apt-get install or  compile from source on ubuntu without issues.

    2. You are in luck these days as there are tons and tons of resources available to learn infosec.

    -Books I'd start with ( buy or torrent depending on ability)

    • The latest Hacking Exposed book. The methodology it teaches is still relevant today and its a 10,000 ft view of different hacking areas
    • Pick a basics of pentesting book (or a few)  to start with I've stopped reading the basics books but any of them should wet your appetite.

    Some examples (more netsec):

    Some examples (webappsec)

    Some examples (social engineering)

    Some examples (Physsec/redteam)

    Lots more here, the list is a bit dated i'll try to update it this week but it IS sorted by category

    Exploit dev

    • Tons and tons of books/resources.  Unless you are really really interested in writing exploits I wouldn't start here. Understanding the above will give you more opportunities for jobs in the business, writing exploits and automating tasks will come naturally as you progress

    3.  Pick a scripting language to work on

    • python is probably most supported/popular
    • ruby is what metasploit is written in, so there is value in learning that
    • javascipt/node.js will be useful going forward as well

    4. Online CTFs

    5. Training
    Lots out there, plenty is torrentable or pay for it if you feel like it/can (you should if you can afford it -- those people work hard on it).  With the amount of resources you should be able to learn the basics without paying a dime and seek out mentors or ask questions over email/twitter for topics you are stuck on.

    Second Question:
    Also, what steps did you initially take to become proficient at computer security?

    -I was a computer science major in college so I came out knowing some of the basics. My job in the military was communications and I ended up doing a lot of layer 2/layer 3 stuff along with MCSE type tasks.  Its going to be important for you to learn, if you don't already know, A+ type material and Network+/basic CCNA type materials.  Hacking is all about exploiting the mistakes someone made setting things up, abusing protocols, but a lot of finding/identifying/exploiting misconfigurations. This is a lot easier if you understand how to do these basic configurations.

    Aside from that, start practicing, reading blogs/twitter, watching talks that interest you. I'd start with a basic ones but also stuff advanced/over your head. Getting your mind blown occasionally helps let you know there really is no limit to the stuff you can do, what you can learn, etc. has pretty much everything and more content than you will ever be able to consume plus lots of free courses.

    That's what I have for starters as you asked a pretty generic question, so hope that helps



    Saturday, May 16, 2015

    Lets Call Stunt Hacking What it is, Media Whoring.

    Lets Call Stunt Hacking What it is, Media Whoring.

    by Valsmith

    I recently read this article: and it brought to mind some thoughts that have been percolating for quite a while. Sometime last year I believe Dave Aitel coined the term Stunt Hacking, which I think is a pretty good way to describe it. We often see these media blitzes about someone hacking a car, or an airplane, or some other device. The public who has a limited understanding of the technology, and the media who has a worse understanding, get in a frenzy or outrage, the security company hopes this translates into sales leads, and the researcher hopes this translates into name recognition leading to jobs, raises, conference talks, etc.

    A question that I think we should keep in mind is: Why would a company hire someone who just publicly displayed how little they understand about the technology and made their desired potential client look bad.

    There are two problems with this: 1.) The research is often FUD or based on a very limited understanding of real world deployment or 2.) Any actually valuable technical research gets lost in the hype.

    Let me be clear, I am not saying that researchers like Charlie Miller or Barnaby Jack haven't contributed meaningful or ground breaking research to the community, (they have), but many ride a hype wave that is often unwarranted. Unscrupulous infosec companies take advantage of such researchers work to drive sales of mediocre consulting services as well.

    The practice of companies pushing their best researchers to drop and overhype controversial or gimmicky bugs makes no sense from a business perspective either from the security vendor or the services purchaser point of view. Who wins in the long run? The vendor loses credibility and the purchaser suffers in the PR space.

    Stunt hacking often works something like this:

    1.) Purchase from Ebay or otherwise some component of a system widely in use that doesn't look like a computer but uses underlying computeresque technology.
    2.) Since physical access to the device is ensured (unlike in the real world), spend a period of time analyzing and understanding the device.
    3.) Develop or acquire some tool set to interact with the device.
    4.) Make the device do something that the public perceives is out of the ordinary or unusual.
    5.) Issue a number of hyping press releases. (The media has a vested interest in producing spectacular stories)
    6.) Jump on the security conference talk circuit and present the research as many times as possible.

    There are several issues with this and I can use some real world examples to explain them. When you state that you can hack an airplane based on something you saw (or worse did) on a flight, and that a particular vendor is or is not security responsible, you are missing a number of things:

    • FAA Involvement - There are processes for approval, auditing, development and release cycles that pass through FAA policies. This affects time frames for patches to be pushed, what kinds of software can be installed, and how things are updated and inter-connected.
    • Airline Involvement - What a particular vendor develops is often heavily modified or integrated into an airline's customized product suite. This means that company A could develop a piece of hardware or software for airplanes, the airline buys it, then the airline drastically changes it. It may not be immediately obvious where the responsibility for a security issue lies.
    • Aircraft Manufacturer Involvement - Essentially the same as the previous point.
    • Air crews - Maintenance and flight crews have the ability to modify some settings and make changes to the system.
    • Product Vendor - The originator of a particular product. If they want to push a change, such as a security fix, all the above stakeholders and more have to be involved in that process. That means that an issue can be known, a fix developed and released, and it can take months or even years while it transitions all the stakeholders and each makes a business decision about applicability and severity before it reaches a particular airplane.
    • Safety Concerns - Any technology that goes on to an aircraft is rigorously analyzed and tested for any potential impact to flight safety. Even if this technology doesn't touch the flight systems, its presence on the plane requires that it be checked. This leads to a slow down in the deployment of both new technologies, as well as fixes.
    • End of Life Cycles - An airline can purchase a particular system, but that doesn't mean that they will purchase a new system or upgrade the old one. Serious fixes will likely be implemented, but as technology changes, older systems may fall by the wayside in security maintenance. It is a valid business decision for an airline or other org. to look at the cost of general technology upgrades across a fleet.
     Just because a company doesn’t want to hire YOU in particular, or tell you about what they are doing security wise, doesn’t mean that they don’t care about security! Or that they are doing nothing! For all you know they have a team of well credentialed people working on it and external factors make the release of fixes slower than you would personally prefer. Such hubris in this industry.

    Do you want electronics and backpacks with gear in them banned on airplanes? Because that is how you get there. Do you want the adversarial, but slowly healing, relationship between hackers and business to become openly hostile and driving research totally underground? That's how you get there.

    Have some professionalism! Try to work with the vendor so that you get a fuller picture and can provide more value to the world. If they don't want to work with you, understand there may be many factors at play that you are unaware of, and rely on the fact that you are creative and move on to a new technology.

    The 1990's and early 2000's were a valuable time where groups such as the l0pht pushed companies to develop security programs and fix bugs. They succeeded for the most part. We now live in a world with bug bounties, security budgets, and companies that actually care about their security. Its time to evolve our tactics on the researcher side to match the evolution business has made. Unless you are an underground hacker / blackhat. In that case, don't promote yourself as a professional researcher and try to get contracts! Do your thing but own it, don't pretend to be something you're not.

    Let’s take another example; ATMs. When you buy a used ATM off of Ebay or something similar and develop an attack for it, there are assumptions that are made and important things left out of the equation.

    • What is the physical protection regime and tamper evident posture for a particular location, bank, or deploying maintenance company?
    • What vendor modules are enabled or disabled via licensing on the individual ATM?
    • What is the middleware in use and how is it configured to protect or configure a particular ATM?
    • What are the interconnects to the bank and what transports are used? Cell, modem, Ethernet, etc.
    • What card tracks are in use?
    • Is it a modified XP, OS2warp, or other OS?
    • How and where does an HSM come in to play?
    All of these things apply or have corollaries in the automotive, satellite, medical, SCADA, and other industries. In the end, they are just computers of one sort or another.

     Next we need to discuss what our industry is really doing with all of this. I've seen many researchers feign outrage that something is "so insecure" and wanting to "protect users". After sitting through 10 years of conference private parties, I have serious doubts that this is always the case. I think fame, media attention, hacker cred, etc. are more frequently the drivers than some sort of user centric altruism. Not always, but often.

    This is exacerbated by the fact that it is a common tactic for security companies to hire one or two "rock star" researchers, have them pull off a bit of stunt hacking, often of dubious impact, and then push the FUD as hard as possible across whatever conferences will take them and whatever news shows will interview them.

    I feel I can speak about this because I spent a lot of time speaking at conferences (at one point I think I held the record for the most talks in one week, 7.) and I was interviewed by media here and there. This personal experience is how I learned it is a bunch of BS. The media, for the most part, doesn't care or understand what you are talking about, really. They care about viewers for a short news cycle and FUD is sensational and achieves this goal. As far as the conference circuit, well that's full of BS as well. I remember attending a highly technical talk on rootkits by Joanna Rutkowska, a brilliant researcher in her own right, so please don't mistake this for me bagging on her, I'm not. The material in the talk was compelling and she broke new ground. However eavesdropping on other audience members, few knew what she was talking about. Multiple times I heard "I have no idea what she is talking about, but she's really smart". They paid thousands of dollars for that privilege. And rootkits have little impact on day to day security for most businesses. The value of highly technical security conferences is rather low, except to the researchers themselves, and pushing the field forward. But it is a money maker. I think it is rather telling that you don't see many talks from her anymore, perhaps she figured out the same issues I am talking about, I don't know. She does however continue to conduct highly technical, academically and business valuable work, quietly, without unnecessary hype.

    I gave both technical talks as well as conceptual ones full of pictures. Other researchers somewhat respected the former while general audiences got little out of it. Audiences enjoyed and found the latter valuable, while researchers couldn't take me seriously. I tested this over 10 years and my conclusion is that for me, conferences have little value. But stunt hacking plays deeply into this dysfunction. It generates press for the conference and the researcher, dazzles and outrages attendees, and generates money and fun for many. But is it really helping anything?

    If a "researcher" spends all their time on the conference circuit and talking on cable news shows, how much of a researcher are they really versus a marketing professional? A wise man once told me; "Let your work speak for itself."

    And now we can proceed into the darker side of all this. High pressure sales in infosec. Most of my clients are former clients of big name, well known security companies. After a period of trust building they often show me the reports, deliverables, and emails from previous infosec "professionals" that they have engaged before me. THIS is where the real outrage and disappointment comes into play. Extremely poor deliverables for big bucks, arrogant "recommendations" (more like demands) with little business value, and a focus on upselling versus doing a good job on the current project is the norm. Several times I have seen the following:

    Infosec company / individual: "Hire me/us to be your security researcher". Often this is after an initial first gig that didn't work out well.

    Potential Client: "No thanks, we already have someone and we don't like the way you do business". Doing business often refers to everything but the technical work. For example communications, documentation, status reports, pricing, honoring NDA's, etc.

    Infosec company / individual: "You better hire us or we will tell everyone how insecure and irresponsible you are!". Telling everyone involves conferences and media.

    Potential Client: "That seems like a bad idea, especially since we have someone good working on it and you have an NDA with us, which you would be violating."

    Infosec company / researcher: "We don't care, hire us or else!"

    I may have oversimplified the exchange slightly in the interest of brevity, but this borderlines on extortion and is unacceptable. This kind of short sighted behavior is dragging our industry down and hurting the credibility of everyone, especially since it is so common. The focus on short term, scan and bang profits versus long term relationship building and iterative, incremental, business benefiting improvement is damaging the ability of legitimate researchers and companies to engender real change. Organizations are becoming disillusioned with engaging in real infosec, even as it becomes a hot industry.

    This must stop. Stunt hacking must die. Researchers must learn to look beyond a overhyped-bug-snapshot in time and LEARN the industries and technologies they research. In the old days hackers knew more about a technology than the people building and maintaining it, not just how to break something and move on to the next trademarked bug. Let’s get back there before we lose all credibility.