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 US-CERT 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.