Wednesday, February 20, 2013

Wireshark SMB2 file extraction feature

Some time ago we contributed to Wireshark the SMB file extraction feature, which enabled the tool to extract a file (or portions of it) from the SMB traffic contained in a network traffic capture. From the moment when the plugin was published, we have received several requests to extend this funtionality to support SMB2 traffic as well, and we have also seen the need for that functionality in every pentest that we have done since then, but we haven't had the time to write the code. During a recent engagement we finally decided the time had arrived to go and write it.

Although SMB2 support was our main objective, we took the time to implement some other functionalities that we have detected that were necessary.

SMB2 support for ExportObjects->SMB
The major part of work to write SMB2 support has been finding out where the needed information can be found in smb2 dissector and, for those pieces of information not already there, how to store them in the right place to integrate, as far as we can, into the wireshark code structures. The rest of the code (the part where the file is built from the chunks that are extracted from each packet) has been almost completely reused. We have implemented the minimum functionality to be able to make a proof of concept, but we have tested it against a lot of real captures and it seems to be stable. You can see what it looks like in the following screenshot.


Other major changes
The "File ID" vs. "File Name" dilemma
There was another important issue flying around our minds since we wrote the first plugin. SMB and SMB2 identify a file based on a File ID (which has different formats and meanings in SMB and SMB2). It is usual to find the same file (i.e. same tree_id AND same file_name) several times in the same capture file. That means that it is possible that some parts of a big file are associated with one file_id and other parts of the same file are associated with a different file_id. In that case the plugin, as it was, would report that it knew a percentage of two different files. We were wondering if taking the "tree_id+file_name" as the file identifier could make the plugin to capture the whole file or at least a bigger part of it.

This seemed to make sense, because the plugin builds the final file by inserting the chunks that it receives in the order that appear in the capture, and so it overwrites older parts of the file with newer ones. Yet, we were not completely sure that was the best solution, and finally decided to make it an option for the user, available at
Edit->Preferences->Protocols->SMB and Edit->Preferences->Protocols->SMB2
for that purpose:


Support for other SMB dialects
Some time ago Paul Santangelo pointed out that the plugin didn't work under some circumstances. After studying the capture file that he sent us, we concluded that he was right: we had implemented the extract capability for *_ANDX SMB commands, but not for the original SMB_COM_CREATE, SMB_COM_OPEN, SMB_COM_READ and SMB_COM_WRITE commands. Although according to Microsoft these commands are deprecated, we decided to include support for them because wireshark smb dissector supports it and also because that way the plugin can be used in rare but existing old environments. By the way, Paul, we loved the example pdf file extracted from your capture!


Other minor changes
We have also include some minor improvements to the plugin.
The first one is a bit of cleaning in the way that file names are shown. Wireshark uses UTF-8 enconding to show strings in the ExportObjects->SMB window, but SMB uses some flavour of UTF-16. We have ensured that the string passed to that window is encoded in UTF-8 schema, and all non printable characters coming from UTF-16/UNICODE have been transformed into a single '?'. It is not a perfect solution, but it is a bit cleaner.
The last change we added has to do with tree id names and filenames. Until now, when the plugin was not able to find the tree id it just showed TREEID_UNKNOWN or TREEEID_XXX (where XXX was the ID number of the tree). Now, the server IP address has been added to the tree pseudo-name, so that the user doesn't have to dive into the packet trace to find it.
Regarding filenames, we have decided to show the full pathname instead of the basename, because we think that this provides better information.

Coming next
In a few days we will send the patch to wireshark for inclusion in the deveolpment trunk, so we hope it will be publicly available soon. As usual, we will then publish a windows compiled version of wireshark including all this. So stay tuned if you want this feature in your Wireshark!

Friday, February 1, 2013

TLSSLed v1.3

After more than one year since the previous TLSSLed version, we are happy to announce TLSSLed v1.3!

This version is the result of testing lots of HTTPS (SSL/TLS) implementations during real-world pen-tests, so it is full of minor improvements and extra checks to identify different behaviors we have found in the wild (see the changelog inside the tool/script: "New in version 1.3" section). In several of my "Security of National eID (smartcard-based) Web Application" talks during the last year I mentioned that an upcoming TLSSLed version was going to be released... so here it is! :) Additionally, the tool output has been changed for easy reading and to provide quick information for each finding: negative [-], positive [+], or informational [.] (as well as grouping tests [*] and highlight warning and error messages [!]).

The tool usage has not changed. Simply run the tool by providing the target hostname or IP address plus the target port:
$ ./TLSSLed_v1.3.sh <hostname or IP_address> <port> 


This version has been tested on updated versions of Samurai WTF 2.0 (running openssl 1.0.1 and sslscan 1.8.2), Backtrack5 R3 (running openssl 0.9.8k and sslscan 1.8.2), and Mac OS X Mountain Lion 10.8.x (running openssl 0.9.8r and sslscan 1.8.2; it requires to add and compile sslscan manually, see below). Samurai WTF 2.0 is the only one of these three that includes openssl v1.0.x by default, providing support for the TLS v1.1 and v1.2 protocol tests.

Instructions to get and compile sslscan for Mac OS X are available on the original webpage, although for Mountain Lion, if you have Xcode installed (or even without it?), you simply need to run the following command and ignore the openssl deprecated warnings:
$ gcc -lssl -lcrypto -o sslscan sslscan.c

Additionally, TLSSLed v1.3 has also been recently tested with a newest sslscan fork project that was released to better support STARTTLS, currently at version 1.8.3rc3, and available at GitHub.

If you find any bug, misbehavior, openssl/sslscan version combination, or target HTTPS (SSL/TLS) implementation that cannot be properly tested, please let us know so that we can fix it and add new features. Enjoy it!

TLSSLed v1.3 can be downloaded, as usual, from Taddong's lab.