"It is never too late to be who you might have been."

- George Elliot

Introduction:

This is a continuation of my write-up about this year's Crack Me If You Can challenges. You can view my previous two write-ups using the following links. Each one covered a specific challenge of the CMIYC contest: [Striphash] and [Radmin3 hashes]. 

I'll admit, in my previous posts I was focusing on the plumbing of the challenges. Aka how to extract the hashes and get them in a format that you can run password cracking attacks against. But I danced around how to run successful cracking sessions against those hashes. There's a lot of reasons for that, but the biggest one is that I wasn't very successful during the contest itself. I needed time to step back, and start investigating all the challenges and hints that Korelogic gave out during the contest but I didn't have time to really dig into. Then with sleep and no pressing deadlines I could start to solve, understand, and then incorporate these challenges into my cracking session. That's a lot of words to say that I didn't solve the wifi cracking challenge during the contest, but I felt it would be worthwhile to look into it afterwards and document how I went about working through it. This will hopefully be one of the more day-to-day practical write-ups as well since cracking wifi passwords is something that can be pretty common during pen-test engagements if you can line up the appropriate permissions.

Important Links, Tools, and References for this Post:

• Rapid7 Writeup: Poorly Purged Medical Devices Present Security Concerns After Sale on Secondary Market




• Link: https://www.rapid7.com/blog/post/2023/08/02/security-implications-improper-deacquisition-medical-infusion-pumps/


• Reason: This is why I normally don't have to crack wifi passwords during my research. There are usually other ways to gain access to networks than having to start up Hashcat. Also this report is really interesting and I'd like more people to be aware of it.




• Cap-2-Hashcat




• Link: https://hashcat.net/cap2hashcat/


• Reason: This site will extract WPA handshakes from wireless packet captures and convert them into a format you can crack with Hashcat. I'm really hesitant to include this link since while it is very good for helping out during password cracking competitions, please don't ever use this site for any sort of real life penetration testing assistance. You are sending the data to the "cloud" and you should always be mindful about doing that with a sponsor's traffic.




• HCXTools




• Link: https://github.com/ZerBea/hcxtools


• Reason: This is the proper way to parse packet captures and extract password hashes to crack on your own machines. It takes more work than Cap2Hashcat, but it's the proper way to treat sponsor data, and it gives you more flexibility to troubleshoot when something goes wrong.




• Wireshark Wiki: How to Decrypt 802.11 Traffic




• Link: https://wiki.wireshark.org/HowToDecrypt802.11


• Reason: Once you've cracked the WPA1-PSK password, you'll want to view the decrypted traffic. Wireshark is one the easier ways to do that.




• Example Hashcat Formatted Hashes




• Link: https://hashcat.net/wiki/doku.php?id=example_hashes


• Reason: You really should have this page bookmarked regardless of if you are competing in a competition or not. Whenever I'm starting a non-standard password cracking session I find myself referring back to this site to try to figure out what type of hash I'm dealing with, or to understand how I need to format it so I can crack it with Hashcat.

Background on cracking WPA sessions:

As a bit of backstory for myself, I got my start in computer security being a wireless penetration tester/red-teamer. I had perfect timing since new tools to crack WEP sessions had just been released and a Symantec Antivirus remote exploit had become available. So by pressing a few buttons I could look like a super L33t hacker without really knowing anything.

Ever since then, I've had a soft spot in my heart for wireless hacking. The challenge though is I rarely do any wireless hacking in my day job. Yes, I do vulnerability impact analysis research, but I usually start with a white card that assumes I already have access to the wireless network. How do I justify that? Well let me refer you to my talk at BSidesLV2023: Passwords911 Authentication Adventures in Healthcare. To be more specific, I end up buying a lot of used medical equipment off of eBay (my job is so weird but awesome). Often these medical devices still have hospital credentials such as wireless passwords, and Active Directory tokens, as well as patient records still on them.

Don't just take my word for it. The security company Rapid7 did a similar analysis and found over half of all wireless infusion pumps that they purchased on the secondary market had sensitive data still on them [Link]. As a disclaimer, I haven't seen any reporting of threat actors doing this in the wild. This particular attack requires a lot of luck and physical proximity to the institution that sold the medical equipment. Basically it would be a huge pain to try and pull off in real life. But it does work pretty well when I'm requesting a white-card so that way I can focus on the part of the assessment that I really want to dig into.

Now that the "cooking recipe back-story" of this post out of the way, let's look at the challenge itself. In the first hint file released after the contest started "cmiyc-2024_street_files_2" it included a "street.pcap" file along with the following note:

-----

From: Jarlaxle

To: Tiamat

Extracting the WPA1 Hash:

Figuring out accounts sounds promising when it comes to cracking the challenge passwords. So let's open up the pcap in Wireshark.

Ok, so this pcap looks like something we can use to crack the WPA1 pre-shared key. The next question is, how do we get the WPA1 hash?

The problem is you can get in big trouble if you use this site for real world penetration testing engagements. You are uploading sponsor data to a cloud based hacking site probably being monitored by who knows what threat actors. I'm not throwing shade at the Hashcat team for offering this service. It's a great service and I really appreciate they provide it. But you don't want to be uploading client data to other reputable cyber security sites such as Virus Totals either. Basically if you are getting paid to do this type of analysis, you are also getting paid to learn to dump the hashes from a packet capture file using your own systems.

Using John the Ripper's wpapcap2john to Manually Dump the WPA1 Hash:

If you are going to use John the Ripper to crack the WPA1 hash, there is an easier option available to you. Included in the Jumbo version of JtR is a tool called wpapcap2john that is super easy to use and will save the resulting hash in a format that John the Ripper can use.

The WPA1-PSK hash file formats for both John the Ripper and Hashcat are different but once you have the hashes you can pick which tool you want to crack them with. I personally like using John the Ripper since I don't have a lot of GPU power to throw at the problem and I like JtR's rule logic better. But Hashcat is much preferable if you do have the compute power to really throw at the problem. I'm going to show examples of using both tools, since luckily the street password that Korelogic provided for this file was fairly simple to crack.

Cracking with John the Ripper:

Cracking with Hashcat:

The first step with cracking the WPA1-PSK hash in hashcat is figuring out what format to target. There's a lot of different wifi cracking modes! Now if you are lazy you can simply skip the '-m' option and let Hashcat autodetect the password hash which works pretty well for well defined hash types. The other option is you can refer to the list of Hashcat hash mode examples. The hash dumped from HcxTools starts with "WPA*02*" and when looking through the example hashes that matches up to "-m 22000"

Now it's just up to us to run a cracking session. To keep things simple, I used the standard JtR passwords.lst wordlist since that's a pretty good small one, and I picked the d3ad0ne.rule included in Hashcat as that tends to be my default go-to ruleset to use. In retrospect I should have kept it smaller with something like best64.rule (you can tell the reason when you look at my anemic password cracking setting in the screenshot below), but it was a very weak password so it didn't make much of a difference this time.

• hashcat -m 22000 -a 0 ./hashes/pcap.hash ~/repos/john/run/password.lst -r ~/tools/hashcat/rules/d3ad0ne.rule

Decrypting the Packet Capture:

The easiest way to decrypt the encrypted session in the packet capture is to use Wireshark. I included a link to the official tutorial on how to do that at the top of this blog entry since I always have to look it up every time I do this. But here is a quick list of the steps:

1. Open the packet capture in Wireshark


2. In Wireshark go to Edit->Preferences


3. Next go to Protocols and expand it out. Select "IEEE 802.11". Note: I always forget it starts with IEEE.


4. Next to "Decryption Keys" click "Edit"


5. Press the "+" button to add a new key and pick "WPA-pwd". Then enter in the PASSWORD:SSID and click "save"

• Trust me on taking the time to enter in the PASSWORD:SSID vs. just the password. It'll usually work with just the password, but I've wasted time troubleshooting when problems popped up due to me being lazy and just YOLOing in the password by itself.

Quick Disclaimer: I don't know if Wireshark is smart enough to realize the last ":" is the delimitator or not so it might not actually mess up your decryption if a ":" is in the password. Setting up a wifi network and testing that out will need to be a rabbit hole for a different day.

Once you do this, Wireshark will automatically decrypt the traffic making it really easy to start digging into it and looking for fun conversations and artifacts.

Analyzing the Packet Capture:

I'm sure there is some toolset or script out there that will parse through this decrypted traffic and pull out interesting passwords and information from it. My first instinct would be to go with DSniff, but looking at the repo it hasn't been updated in the last 14 years. (Side note: This also gave me the realization "OMG I'm old"). 

FTP Credential Analysis: I need to dig into this more, but at least in the initial street file hashes, there does not appear to be a user with the name "yashica". I might need to throw their password, (along with others extracted from this packet capture) into a general wordlist and run it against all the uncracked hashes I have. That is, unless there is another hint file that provides further context. So the next question, is "what about that passwords-street" file they are downloading?

Yup, that could be useful as well! Now, I want to preface this next point by once again saying that there must be a better way to analyze these packet captures, and doing it by hand is tedious and error prone. But if you are going to parse it hand like I am doing, you can look at the filter that gets applied in Wireshark when you follow a TCP stream and manually increment it by one to view the next TCP session. It's not a pretty way to do things, but it's much better than hunting and pecking and scrolling through the full packet capture.

Other interesting side quests: There is one session where the user grabs the following webpage: "/obscure/path/for/extra/security/passwords-street.html", 

The post CMIYC2024: Wifi Cracking Challenge appeared first on Security Boulevard.