Capturing SMB Files with Wireshark

Most corporate networks include one or more file servers where shared information is stored and shared across the network using the SMB protocol. These servers are used as a repository for different departments, which share the same infrastructure but must have access to different and separate information sets, some of which will probably be very sensitive and confidential, like files belonging to top management, Human Resources or the Legal departmens, just to name a few examples.

The access control to the information in the file servers is enforced using the SMB protocol authentication, usually integrated with some unified directory (like Microsoft Active Directory).

While the authentication can be performed in a secure way, the information flow between the server and consumer is usually not encrypted, as it happens with the default SMB configuration. This makes this information vulnerable to any sniffing activity performed in the company’s internal network.

In our effort to identify weak points of corporate networks, we wanted to demonstrate how this vulnerability could be easily exploited, so that organizations better understand the risk this vulnerability poses for them, and how to protect themselves from it.

For that purpose, we have developped a plugin for the popular network analyzer Wireshark. The plugin adds to Wireshark the ability to extract and save separately, from any network capture, either live or previously saved, the contents of any files transferred between a server and a client using the SMB protocol. We have succesfully used this plug-in in some real pentests, demonstrating the potential impact of this vulnerability.

Once installed, identifying SMB streams in a Wireshark capture is easy: click on Export->Object-> SMB, and look at the windows that pops up, which will look similar to this one:

Then, just selecting the desired file and clicking "Save As" will put the captured file on disk and allow you to open it with the right program.

Please note that not all files will be 100% captured and there are some files that will not fit into memory.

A white paper with further details, as well as the plug-in itself, are freely available at the Lab section of our Web Page.

(UPDATE) This functionality is included in the oficial version of Wireshark from release 1.5.1 on.
(UPDATE) We have released a patch that corrects some bugs in the export object SMB functionality of version 1.5.1. It has been included in development trunk from SVN revision 36979 on. For linux users you can download source code and compile it. For Windows users, a windows installer is available in our lab.

Session-fixation vulnerability in Joomla! (20100423)

At the end of last year, during a web-app pen-test on a target application based on Joomla!, a well-known open-source web-based Content Management System (CMS), I discovered that the Joomla! core session management system was prone to a session-fixation vulnerability. Joomla! failed to change the session identifier after a user authenticates. The issue has been finally made public on April 23, 2010.

As far as I know, and at least according to Google, this is the first sessation-fixation vulnerability found in the information security history. Typos make you famous! ;)

Due to the fact the target web portal I was testing used the Joomla! built-in session management capabilities, before and after authentication, it was vulnerable. An attacker can exploit this vulnerability to hijack a user's session and gain unauthorized access to the protected portions (those requiring authentication) of the affected application.

Joomla! versions 1.5 through 1.5.15 are affected. Although I discovered the issue on version 1.5.14, and notified the Joomla! Security Strike Team (JSST) appropriately, through the Joomla Security Center and by e-mail on early November 2009, the fix couldn't get through the next version. The issue was fixed on version 1.5.16 (while the last available version as of today is 1.5.17).

As an exercise for the reader, you can review the Joomla! source code if interested on the fix; start with  the "libraries/joomla/session/session.php" file (other files are affected too). The Joomla! session cookies are of the form "cookie_name=cookie_value", where both cookie name and value are MD5 hashes. Example:

Set-Cookie: f2345657e5f302e02d18922ba903a4ef=74d0a95cfdf16feb8a9678510686ba63; path=/

Although some public sources reflect session-fixation vulnerabilities can only be exploited by tricking the user into logging in after following a specially crafted link, this is not completely right. There are multiple methods and scenarios that a clever attacker (or pentester) can use to exploit it while combined with other vulnerabilities:

• The most commonly used method is the one referred above: an attacker can craft a web link that contains the attacker's session id. This is only possible if the application parses GET parameters to set the session id value, instead of, or as well as, cookies. During my tests I confirmed the target Joomla! application was vulnerable to this scenario.
• If the attacker can add or modify the contents of the vulnerable web server, or a web server on the same domain (depending on the scenario), she can potentially add contents to set the session id to her preferred value.
• Although XSS vulnerabilities are commonly demonstrated by stealing the victim's cookies, they can be used for the opposite action. An XSS can be leveraged to set the victim's cookie on an unauthenticated state, and gather higher privileges through the session-fixation vulnerability afterwards, once the victim has been authenticated.
• Another common scenario to exploit session-fixation attacks is focused on intercepting and modifying the victim traffic (unencrypted HTTP session) through MitM attacks. Due to the fact the victim is just browsing an unprotected portion of the site, he is not authenticated yet, the web application uses HTTP (vs. HTTPS). An attacker can easily inject a new cookie header ("Set-Cookie:") on that traffic, and its value will be accepted and used by the victim web browser.

Finally, there are a few lessons we should learn, and things we can improve, regarding the management of web application vulnerabilities (some of these also apply to other types of vulnerabilities). As I'm currently dealing with similar issues in other open-source and commercial web applications, I want to share a few thoughts:

• The resources and procedures available on lots of open-source projects and commercial companies to be notified and act upon security vulnerabilities can be clearly improved. I will suggest a few specific recommendations on a future post.
• Session-fixation vulnerabilities are extremely prevalent in lots of web applications and web-based products still today (wait for future related posts on this blog :).
• Although in theory, session-fixation issues can be simply fixed by using a different session id before and after authentication, it turns out that fixing session-fixation (as well as other session management) vulnerabilities is not an easy task. It typically affects multiple portions of the application, other related applications and modules, such as the authentication and authorization code. As a result, fixing it sometimes requires to fully redesign the web application.
• Based on the previous assertion, session management countermeasures must be planned and tested during the application design phase, unless you really want to feel the pain of fixing them afterwards.

Keep your sessions safe!

UPDATE: This finding has been assigned Taddong's vulnerability id TAD-2010-001 for any further reference. A Taddong security advisory won't be released for it unless we identify enough demand from the infosec community.