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.