Wednesday, October 24, 2012

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.

Tuesday, October 23, 2012

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


Vendor releases


Researcher

 Kurt Grutzmacher
 grutz <at> jingojango dot 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.

Thursday, October 18, 2012

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.