Crack Me If You Can 2013 - Street Challenge 3

The Crack My If Can Street Challenge #3 was a fairly straight-forward "extract hashes and start cracking" problem. The hashes were Salted SHA1 inside a Berkeley DB. You could certainly have played with getting db_dump to work but it's just faster to use strings.

Crack Me If You Can 2013 - Challenge 9: Part 1

I again had some fun this year playing KoreLogic's Crack Me If You Can password cracking contest at DEFCON 21. This year they separated teams between "Pros" and "Street" to make things a little more fair for individual users vs large groups. If you have any interest in password cracking then you can still download all the past 4 years of data and crack away! Huge thanks to the KoreLogic guys for putting on an excellent contest!

New to the contest this year, password hash files were grouped into companies with each company having their own password policy. The description of the policies were given as hints within the Challenge files which may have their own complex password requirements. It was truly inventive and really gave the contest a real-world feel to it.

Of course my biggest problem is that by playing the game you don't get to really attend DEFCON so I didn't spend a lot of time cracking. You can tell my submissions were pretty much few and far between when I was back in my hotel room:

Even so I came in third place mostly because I spent a little extra time on Challenge 9 because of the point value - 250,000 points!

http://contest-2013.korelogic.com/stats_types.html:

As you can tell from the graph the scores for three of us (brad, I Cant Believe Its Not Butter, and me) jumped near the final few hours of the contest because of Challenge 9. Here's how I did it...

Huawei Security Advisory released for SNMP

For those keeping track, Huawei has released their advisory and work-around for affected devices.

http://support.huawei.com/support/pages/news/NewsInfoAction.do?actionFlag=view&doc_id=IN0000054930&colID=ROOTENWEB%7CCO0000000170

Crack All The Hashes!

Crack All The Hashes!

A few months back I was having a discussion with a co-worker about how to effectively crack a large PWDUMP file (thousands and thousands of users and hashes). I have a bunch of manual steps I use to churn through John the Ripper, oclHashcat and Rainbowcrack that I shared. Then I asked myself, "wtf, why not make a shell script instead?"

When mubix mentioned lm2ntlm patches to JtR for helping to crack from LANMAN to NTLM I remembered that I never fully wrote up anything here about the script. Soo... here's the script!

Fork it, fix it, do whatever you want with it from https://gist.github.com/3416932

Execution is fairly straight forward. Hopefully I didn't make any glaring security holes when processing PWDUMP files. Use all your favorite precautions before or while running this.

HP/H3C and Huawei SNMP Weak Access to Critical Data

HP/H3C and Huawei SNMP Weak Access to Critical Data

Overview

HP/H3C and Huawei networking equipment suffers from a serious weakness in regards to their handling of Systems Network Management Protocol (SNMP) requests for protected h3c-user.mib and hh3c-user.mib objects.

Identifiers

•  US-CERT VU#225404
•  CVE-2012-3268

Vendor releases

HP/H3C:

• https://h20565.www2.hp.com/portal/site/hpsc/public/kb/docDisplay/?docId=emr_na-c03515685&ac.admitted=1350939600802.876444892.492883150

Huawei EBG:

• SN: http://support.huawei.com/enterprise/NewsReadAction.action?newType=0301&contentId=NEWS1000001069&idAbsPath=0301_10001&nameAbsPath=Services%2520News

Huawei CBG:

• SN: http://support.huawei.com/support/pages/news/NewsInfoAction.do?doc_id=IN0000054625&colID=ROOTENWEB|CO0000000170&actionFlag=view

Researcher

 Kurt Grutzmacher

 grutz <at> jingojango dot net

 http://grutztopia.jingojango.net/

 twitter: @grutz

Details

Huawei/H3C have two OIDs, 'old' and 'new':

•   old: 1.3.6.1.4.1.2011.10
•   new: 1.3.6.1.4.1.25506

Most devices support both formats.

The MIBs h3c-user.mib and hh3c-user.mib, for the purpose of this document, will be referred to as (h)h3c-user.mib. This MIB defines the internal table and objects to "Manage configuration and Monitor running state for userlog feature."

This means there are some cool objects with data in this MIB penetration testers or malicious actors would want to get their dirty little hands on. Most objects are only accessible with the read/write community string.

In the revision history of (h)h3c-user.mib, version 2.0 modified the MAX-ACCESS from read-only to read-create the following objects within the (h)h3cUserInfoEntry sequence:

•   (h)h3cUserName
•   (h)h3cUserPassword
•   (h)h3cAuthMode
•   (h)h3cUserLevel

The purpose of these objects are to provide the locally configured users to those with a valid SNMP community. After the change only those with the read-write community string should have access, however this was not the case and the code still retained the earlier access of read-only.

So if you have the SNMP public community string then you have the ability to view these entries.

Why this is impactful

The (h)h3cUserPassword is presented in one of three formats as defined in the (h)h3cAuthMode object and mirrors how passwords are stored in the device configuration:

•   0 -- password simple, meaning cleartext
•   7 -- password cipher, meaning ciphertext
•   9 -- password sha-256, meaning one-way sha-256 hash

SHA-256 is a recent addition and is not supported on all devices yet.

On top of this the (h)h3cUserLevel can be 0 to 3 where 0 is limited access and 3 is full access.

Globbing some users

You must have an SNMP read-only or read-write string and access to the

SNMP port (udp/161) for this to work:

 $ snmpwalk –c public –v 1 $IP 1.3.6.1.4.1.2011.10.2.12.1.1.1

or

 $ snmpwalk –c public –v 1 $IP 1.3.6.1.4.1.25506.2.12.1.1.1

Weaponizing

Files relevant to this disclosure:

•   hh3c-localuser-enum.rb - Metasploit auxiliary scanner module
•   snmp-h3c-login.nse - Nmap Scripting Engine module

These will soon be posted to https://github.com/grutz/h3c-pt-tools and requested to be added to each tool.

Mitigation

By itself this is already bad but most users who do any of the following may already be protected:

• Use complex SNMP community strings or disable SNMPv1
• Have disabled the mib entries for (h)h3c-user
• Block SNMP using access controls or firewalls
• Do not define local users, use RADIUS or TACACS+

More specific routines can be found in the vendor's release.

Why this is a bigger problem

People make poor choices. They like to think their equipment won't rat them out so they use cleartext passwords on networking equipment.

The cipher is an interesting one because it's basically an unknown... What, you think the only thing I had to share at Toorcon was SNMP and some cleartext credentials?

Timeline

June-ish 2012: Research begins after seeing something cool on a penetration test

August 6, 2012: Contacted US-CERT to coordinate vendor disclosure, VU#225404

September 5, 2012: No response from H3C, contacted US-CERT again

September 6, 2012: H3C (through US-CERT) requests more time, I state intention to present findings at Toorcon (Oct 19/20, 2012) or disclose if talk not accepted.

September 18, 2012: Approved for Toorcon! Information goes up not long after on Toorcon website.

September 18-October 16, 2012: Build slides, work on tools, no contact with US-CERT or vendors.

October 16, 2012: HP contacts me directly asking that I not present  this information at Toorcon

October 18, 2012: Publicly state agreement to cancel the Toorcon talk

October 22, 2012: HP discloses! What what? Why bother putting any pressure not to give the talk if you're gonna give everything out 2 days later?

October 23, 2012: So I publish.

On HP/H3C and Schrödinger's Disclosure

Background and Timeline

Whew! The past two days have been a whirlwind of activity and I wanted to get this down before things got too crazy or out of hand.

This weekend I had planned to be at Toorcon 14, my favorite security conference hands down, with a presentation entitled "A CouNtry's Honerable n3twork deviCes". The abstract:

Thanks to FX you can now use buffer overflows on Huawei routers. Buffer overflows are cool but there are issues you have to overcome. What if there was another path which looked more like regular traffic? This talk will release details of research done in parallel to FX's against H3C/HP routers, switches, access points and firewalls. Some stats of affected Internet-accessible devices will be thrown about and updates released to Metasploit to help audit your own network. After this talk you just might be able to control a large part of the Internet in a very large CouNtry.

It's a culmination of research I've been doing since June, 2012 into H3C gear with stats I (and others) have collected. On August 6, not long after FX's DEFCON talk, I submitted what I had to US-CERT for them to coordinate with HP/H3C. Standard US-CERT disclosure policy is 45 days from vendor notification. Unless the vendor asks and all agree to extend this.

30 days later I had not heard back from US-CERT or HP/H3C so I requested an update. At this time HP/H3C requested more time at which I said "ok, you can have until Toorcon. I'm going to submit to talk and even if not selected I want to disclose this."

All research and prep work for this talk was done as an individual researcher and not as part of any company. I had decided to go through US-CERT since I agree with their disclosure policy and felt this was something big and should be known and handled by them. They have a lot of experience and contacts to handle this. It's not that my employer's team isn't good, they're freaking awesome, I just didn't want to get them involved. Unfortunately.....

Then Comes Tuesday..

I received a very cordial and apologetic voicemail and e-mail from the HP Software Security Response Team asking me not to present this Saturday. The vulnerabilities are apparently too big for them to be ready. I had clearly stated back in September my intention to provide mitigation techniques so that their customers would not be left in the dark after the presentation was done. I'm not a bad person, really.. Honest!

While this was understood they still felt the information was too much of a risk and again requested I delay the talk until they could be ready.

I'm guessing somebody woke up on Tuesday morning and went "Oh hell, is Toorcon this Saturday?" but you can speculate as you see fit. I can't stop you.

Some dates were floated around. HP understands the urgency and also knows that ZDI, their own disclosure group, has a 6 month policy to "disclose no matter what." So the information will come out, just not right now by me or US-CERT.

Others strongly suggested to me that I agree with this delay. If you're familiar with the 7-layer OSI stack (similar to but not exactly like the 7-layer Taco Bell burrito) then you know there are 2 additional layers atop it. Politics and Money.

Feel free to speculate as you see fit. I can't stop you.

So Are You At Risk?

If you own and use H3C or Huawei equipment then of course you are. I have information of serious vulnerabilities and you don't. Nanny nanny boo boo. But I believe in Full and Responsible disclosure, which is why I went through US-CERT. It's just that this information has serious industry-wide implications that HP isn't ready to release.

Can others figure out what I know? Certainly they could. Am I going to tell anyone or give hints? No, I cannot. There is this bag with an angry cat in it that wants to come out. Or it may not be a cat. It's Schrödinger's Disclosure! You just won't know until it's opened.

This is what's tough about Full and Responsible Disclosure and why you should listen when dates and intentions are stated.

If you own and use H3C or Huawei equipment then you already know you're at a serious risk thanks to FX's DEFCON talk. If you value your network and its data then you should already have taken steps to protect it. These protections will most likely keep you safe from me as well.

However I know there are guys and girls out there that can find the same stuff I did. Please be respectful of me and HP by not talking about it if you do. Do feel free to talk to me and we'll commisurate together over our shared information.

Contacting HP

If you have any questions in relation to this case, I encourage you to contact HP's PR contact Samantha Singh

Disclaimer

The content herein consists of my own personal opinions and not those of my employer.

The contest is over

Korelogic's Crack Me If You Can contest at Defcon is officially over. Team Not Appearing At Defcon scored decently given it was just me, two machines and not a lot of focused time.

The top teams scores fully show that given enough resources and dedication today's password hashes can and will be broken. Congrats to the top four teams: Hashcat, InsidePro,  john-users and bindshell-dot-nl. Reading your write-ups will be fun!

I had a few goals I wanted to achieve while participating in the contest. I knew I wouldn't score high or often due to outside commitments. I mostly wanted to:

• Stretch out the environment we had built up for penetration tests
• Try not to get sucked into trying for bigger scoring points and see how many overall hash types respond in the environment (failing sometimes to stick to this rule - damn competitive natures!)
• Gain more experience with Hashcat's tools and closing some of my knowledge gaps with it
• More real-world experience with using John The Ripper's modes.

Yes it would be possible to build your own password list, encrypt it and such but there's something about having a third party source. You have no clue what was used so you're starting out completely blind!

Overall I felt the contest was a good representation of real-life password cracking experience with a few minor issues in my opinion:

• In a real world penetration test you typically receive bundles of hashes at a time. Usually a few Windows systems with local administrator and one or two potentially useful accounts. Then as the days progress you start owning larger and larger systems with more and more passwords (mssql, oracle, windows servers, etc). I'm not really sure how they could incorporate that into a 48 hour contest but it would be cool.
• Individuals are severely outclassed by teams, but that's entirely ok. The contest was designed as a team-based system. Obviously those who had the resources to work together and develop their own tools have a huge step-up. The top three teams represented three different cracking toolsets.
• The mssql/mssql05 debacle was annoying but glad it was cleared up. The problem with mssql hashes is that they crack in both formats so you really need to know your source. I had achieved a high number of mssql05 hashes but when they didn't point score I switched to mssql, which was incorrect. Quite a bit of wasted CPU time.

Some of the things I liked about the contest:

• For those of us who are not hard-core shellcoders, this gave us something fun to play as part of Defcon instead of having our asses handed to us at CTF. The downside still is if you're at Defcon and you're in a contest you don't really get to enjoy Defcon. :)
• The challenges were a nice touch - zip, pdf, rar and doc files with extra hashes in them to crack! I wasn't expecting them so I didn't spend too many cycles on them. Something to note for our environment...
• A lot of hard work went into making this contest and from my vantage point it seemed to run pretty smoothly. Kudos to Korelogic!
• Separating the hashes into their respective files was really helpful for writing scripts. Saved a bunch of time compared to the prior year's huge textfile of hashes.
• The contest wasn't just about brute force strength, however having an arsenal of systems/people or an amazing GPU coder in your pocket helps. I heard that atom, the main coder for hashcat, wrote a GPU implementation of mscash2 in 8 hours. A serious leg up against everyone else given 16,000 points per DCC2 crack.
• Wordlists helped but spotting patterns early on and adapting helped, as expected. A system I wasn't really able to exploit due to limited personal time.

I look forward to the write-ups from the other teams. Big thanks to Solar Designer for making John The Ripper and the rest of the team that have been working to make tremendous improvements to it. It's been the tool-to-use for a number of years and continues to shine. Huge thanks to KoreLogic for their second year of designing and working the contest.

I look forward to next year's contest and the overall report!