Taddong

Cookie decoder: F5 BIG-IP

2011-12-06T23:42:00.001+01:00

I still remember with excitement the first time I found my first F5 BIG-IP load balancer persistent cookie, disclosing the network details of the internal hosts: IP address and TCP port. Although it was a few years ago during a pen-test, still today is very common to find them on lots of target environments. The BIG-IP cookie value (used by the F5 devices to balance the client web traffic load) is encoded using a public algorithm (since May 2007) designed by F5 ("SOL6917: Overview of BIG-IP persistence cookie encoding").

As it is clearly described in the "OWASP Session Management Cheat Sheet" I published this Summer (section "2.4. Session ID Content (or Value)"), it is not a very good practice to include any meaningful or sensitive data inside the session ID, or cookie in this case. At some point, someone will figure out how to decode it :-)... so, instead of encoding the data, it is better to use other kind of session ID values. F5 provides a solution to this issue based on encrypting these persistent cookies: "SOL7784: Overview of cookie encryption".

It is possible to decode the cookies manually reversing the F5 algorithm used to encode the data, but when you are dealing with multiple load balancers and/or internal servers, it is better to use a tool to help in decoding all the cookie values gathered. Although this is an old and well known issue, based on the Python script published by dusty on March 29, 2011, we decided to release a extended version of the script, called "BIG-IP_cookie_decoder.py" and available here (in ZIP format), that decodes both, the internal host IP address and TCP port. Usage example (as root - in fact not required ;-):

Enjoy it!

Hacking Vulnerable Web Applications Without Going To Jail

2011-10-29T02:19:00.001+02:00

While teaching web application security and penetration testing, one of the most prevalent questions from the audience at the end of every week is: "How and where can I (legally) put in practice all the knowledge and test all the different tools we have covered during the training (while preparing for the next real-world engagement)?" Along the years I have been providing multiple references to the attendees (including the option of testing real-world vulnerable open-source web applications) and mentioned several times that I had a pending blog post listing all them together... Today is the day! ;)... and I will be able to refer people here in future training sessions.

This blog post provides an extensive and updated list (as of October 20, 2011) of vulnerable web applications you can test your web hacking knowledge, pen-testing tools, skills, and kung-fu on, with an added bonus... without going to jail :) The vulnerable web applications have been classified in three categories: offline, VMs/ISOs, and online. Each list has been ordered alphabetically.

Offline: The following list references downloadable vulnerable web applications to play with that can be installed on a standard operating system (Linux, Windows, Mac OS X, etc) using a standard web platform (Apache/PHP, Tomcat/Java, IIS/.NET, etc).

The BodgeIt Store (Java): http://code.google.com/p/bodgeit/ (download)
The ButterFly Security Project (PHP): http://sourceforge.net/projects/thebutterflytmp/ (download)
Damn Vulnerable Web Application - DVWA (PHP): http://www.dvwa.co.uk (download)
OWASP Hackademic Challenges Project (PHP): https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project (download)
Google Gruyere (Python): http://google-gruyere.appspot.com (download)
Hacme Bank (.NET): http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx (download)
Hacme Books (Java): http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx (download)
Hacme Casino (Ruby on Rails): http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx (download)
Hacme Shipping (ColdFusion): http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx (download)
Hacme Travel (C++): http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx (download)
OWASP Insecure Web App Project (Java): https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project (download - orphaned)
Mutillidae (PHP): http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 (download)
OWASP .NET Goat (C#): https://owasp.codeplex.com (download)
Peruggia (PHP): http://peruggia.sourceforge.net (download)
Puzzlemall (Java): https://code.google.com/p/puzzlemall/ (download) (docs)
Stanford Securibench (Java) & Micro: http://suif.stanford.edu/~livshits/securibench/ (download)
OWASP Vicnum Project (Perl & PHP): https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project (download)
VulnApp (.NET): http://www.nth-dimension.org.uk/blog.php?id=88 (CVS download & vulns)
WackoPicko (PHP): https://github.com/adamdoupe/WackoPicko (download) (whitepaper)
OWASP WebGoat (Java): https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project (download) (guide)
OWASP ZAP WAVE - Web Application Vulnerability Examples (Java): http://code.google.com/p/zaproxy/downloads/list
Wavsep - Web Application Vulnerability Scanner Evaluation Project (Java): https://code.google.com/p/wavsep/ (download) (docs)

Virtual Machines (VMs) or ISO images: The following list references preinstalled and ready to use virtual machines (VMs) or ISO images that contain one or multiple vulnerable web applications to play with.

BadStore (ISO): http://www.badstore.net (download - registration required)
OWASP BWA - Broken Web Applications Project (VMware - list): https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project (download)
Exploit.co.il Vuln Web App (VMware): http://exploit.co.il/projects/vuln-web-app/ (download)
Hackxor (VMware): http://hackxor.sourceforge.net/cgi-bin/index.pl (download) (hints&tips)
LAMPSecurity (VMware): http://sourceforge.net/projects/lampsecurity/ (download) (doc)
Metasploitable (VMware): http://blog.metasploit.com/2010/05/introducing-metasploitable.html (download - torrent) (doc)
Moth (VMware): http://www.bonsai-sec.com/en/research/moth.php (download)
Samurai WTF (ISO - list): http://www.samurai-wtf.org (download)
Sauron (Quemu) [Spanish]: http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html (solutions)
UltimateLAMP (VMware - list): http://ronaldbradford.com/blog/ultimatelamp-2006-05-19/ (download)
Web Security Dojo (VMware, VirtualBox - list): http://www.mavensecurity.com/web_security_dojo/ (download)

Online/Live: The following list references online and live vulnerable web applications available on the Internet to play with.

Acunetix:

http://testasp.vulnweb.com (Forum - ASP)
http://testaspnet.vulnweb.com (Blog - .NET)
http://testphp.vulnweb.com (Art shopping - PHP)

Cenzic CrackMeBank: http://crackme.cenzic.com
Google Gruyere (Python): http://google-gruyere.appspot.com/start
HackThisSite (HTS - Basic & Realistic (web) Missions): http://www.hackthissite.org
HP/SpiDynamics Free Bank Online: http://zero.webappsecurity.com (admin/admin)
IBM/Watchfire AltoroMutual: http://demo.testfire.net (jsmith/Demo1234)
NTOSpider Web Scanner Test Site: http://www.webscantest.com (testuser/testpass)
OWASP Hackademic Challenges Project - Live (PHP - Joomla): http://hackademic1.teilar.gr

For completeness, there have been some other similar lists published in the past that I'm aware of, and also some "in-the-cloud" commercial training lab options are getting popular (let's call them "pay-per-hack" :-). Enjoy all these different web vulnerable environments and sharp your web app pen-testing skills and tools practicing with them!

Shameless plug: I will be teaching the 6-day SANS SEC542 training, "Web App Penetration Testing and Ethical Hacking", in Spanish (March 12-17, 2012, in Madrid - Spain) and English (May 7-12, 2012, in Amsterdam - The Netherlands).

Updates: (2011-10-31) Added VulnApp (.NET) & Sauron (Quemu).

NOTE: WAVE and Wapsec main goal is to evaluate the features, quality, and accuracy of automatic web application vulnerability scanners.

Image source: http://www.headhacker.net/wp-content/uploads/2010/04/get-out-of-jail.jpg

TLSSLed v1.2

2011-10-12T23:28:00.028+02:00

TLSSLed v1.2 has been released and can be downloaded, as usual, from Taddong's lab.

This new version incorporates feedback from several people, as well as new features, including support for Mac OS X (TLSSLed should now run in both Linux and Mac OS X; check how to build sslscan on Mac OS X first), an initial check to verify if the target service speaks SSL/TLS (finishing its execution if it does not), a few other optimizations and error checks, and new tests for TLS v1.1 and v1.2.

The latter feature has been added as a result of the recent BEAST vulnerability and research, CVE-2011-3389. In order to be able to check for TLS v1.1 and v1.2 you need to use openssl-1.0.1-stable, available from the openssl snapshot repository. TLSSLed identifies if the target service supports TLS v1.1 and v1.2, if it does not, or if your local openssl version does not support these TLS versions.

This new test simply checks if the target service supports these two TLS versions, however, this does not mean the implementation is secure from a BEAST perspective, as lots of other factors can influence this, such as:

The implementation could downgrade from TLS v1.1 or v1.2 to TLS v1.0 or SSLv3 if these versions are also supported by the server and a client requests it.
The implementation can use RC4 instead of AES CBC to mitigate this vulnerability.
Certain SSL/TLS implementations might not be vulnerable to BEAST, such as openssl since version 0.9.6d, as they already added empty plaintext fragments (problem #2) - if SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not set.

The first two scenarios can be easily verified through the new "Testing for SSLv3 and TLSv1 support first ..." test. If you know how to remotely check for the third scenario using the openssl binary, I would love to hear about it and implement that inside the tool... Therefore, a careful and thorough brain-based analysis is still required :)

The output below shows this new feature against "tls.woodgrovebank.com", an SSL/TLS public Interop Test Server from Microsoft, using openssl 1.0.1-dev:

$ ./TLSSLed.sh tls.woodgrovebank.com 443

------------------------------------------------------
TLSSLed - (1.2) based on sslscan and openssl
               by Raul Siles (www.taddong.com)
------------------------------------------------------
+ openssl version: OpenSSL 1.0.1-dev xx XXX xxxx
+ sslscan version 1.8.2
------------------------------------------------------

[-] Analyzing SSL/TLS on tls.woodgrovebank.com:443 ..

[*] The target service tls.woodgrovebank.com:443 seems to speak SSL/TLS...


[-] Running sslscan on tls.woodgrovebank.com:443...

[*] Testing for SSLv2 ...
  Accepted  SSLv2  168 bits  DES-CBC3-MD5
  Accepted  SSLv2  128 bits  RC4-MD5

[*] Testing for NULL cipher ...

[*] Testing for weak ciphers (based on key length) ...


[*] Testing for strong ciphers (AES) ...
  Accepted  TLSv1  256 bits  AES256-SHA
  Accepted  TLSv1  128 bits  AES128-SHA

[*] Testing for MD5 signed certificate ...

[*] Testing for certificate public key length ...
  RSA Public Key: (2048 bit)

[*] Testing for certificate subject ...
  Subject: /C=US/ST=WA/L=Redmond/O=Microsoft/CN=tls.woodgrovebank.com

[*] Testing for certificate CA issuer ...
  Issuer: /CN=RSACERTSRV

[*] Testing for certificate validity period ...
  Today: Wed Oct 12 00:50:07 UTC 2011
  Not valid before: Feb 14 22:52:50 2011 GMT
  Not valid after: Feb 14 23:02:50 2012 GMT

[*] Checking preferred server ciphers ...
Prefered Server Cipher(s):
  SSLv2  168 bits  DES-CBC3-MD5
  SSLv3  128 bits  RC4-SHA
  TLSv1  128 bits  AES128-SHA



[-] Testing for SSLv3/TLSv1 renegotiation vuln. (CVE-2009-3555) ...

[*] Testing for secure renegotiation ...
Secure Renegotiation IS supported


[-] Testing for TLS v1.1 and v1.2 (CVE-2011-3389 aka BEAST) ...

[*] Testing for SSLv3 and TLSv1 first ...
  Accepted  SSLv3  168 bits  DES-CBC3-SHA
  Accepted  SSLv3  128 bits  RC4-SHA
  Accepted  SSLv3  128 bits  RC4-MD5
  Accepted  TLSv1  256 bits  AES256-SHA
  Accepted  TLSv1  128 bits  AES128-SHA
  Accepted  TLSv1  168 bits  DES-CBC3-SHA
  Accepted  TLSv1  128 bits  RC4-SHA
  Accepted  TLSv1  128 bits  RC4-MD5

[*] Testing for TLS v1.1 support ...
TLS v1.1 IS supported

[*] Testing for TLS v1.2 support ...
TLS v1.2 IS supported


[-] Testing for SSL/TLS security headers ...

[*] Testing for Strict-Transport-Security (STS) header ...

[*] Testing for cookies with the secure flag ...

[*] Testing for cookies without the secure flag ...


[-] New files created:
-rw-r--r-- 1 root root 5684 2011-10-18 20:50 sslscan_tls...com:443_2011-10-18_20:49:23.log
-rw-r--r-- 1 root root 2675 2011-10-18 20:50 openssl_HEAD_tls...com:443_2011-10-18_20:49:23.log
-rw-r--r-- 1 root root 2408 2011-10-18 20:49 openssl_RENEG_tls...com:443_2011-10-18_20:49:23.log
-rw-r--r-- 1 root root 540 2011-10-18 20:49 openssl_RENEG_tls...com:443_2011-10-18_20:49:23.err
-rw-r--r-- 1 root root 523 2011-10-18 20:50 openssl_HEAD_tls...com:443_2011-10-18_20:49:23.err


[-] done

If the target service does not support TLS v1.1 or v1.2 it will say "... IS NOT supported" instead. If your local openssl version does not support TLS v1.1 and v1.2, you will get the following output:

$ ./TLSSLed.sh www.example.com 443

...
[-] Testing for TLS v1.1 and v1.2 (CVE-2011-3389 aka BEAST) ...
...
[*] Testing for TLS v1.1 support ...
The local openssl version does NOT support TLS v1.1

[*] Testing for TLS v1.2 support ...
The local openssl version does NOT support TLS v1.2
...

Some people suggested new additions to TLSSLed based on adding checks from other already available SSL/TLS related tools, such as openssl-blacklist or ssl-cipher-check.pl. After a careful thought and detailed analysis process, TLSSLed will remain loyal to its original spirit and design, trying to keep to a minimum the prerequisites to run it (just openssl and sslscan since version 1.0). Therefore, the goal is not to make use of any additional tools from within TLSSLed except openssl and sslscan, unless there is a very critical security test that cannot be accomplished with these two. However, I'm open to implementing other missing tests using these two tools.

One of the future releases will include an associated user guide that briefly explains the different TLSSLed results and their meaning, so that you can easily understand the security implications of the findings reported by the tool without been well versed on SSL/TLS (HTTPS).

Remember, the tool is open to comments, suggestions, improvements, and new tests from the community. Do not hesitate to contact me with ideas! Thanks to Abraham Aranguren and others that want to remain anonymous for their feedback!

Using Signal to Detect Rogue Cellular Base Stations (Part Two)

2011-08-29T16:27:00.035+02:00

Can Signal be used as a rogue base station detector?

For starters, this answer is subjected to the reliability and updating rate of the information source where Signal obtains the geographical location from.

Provided that the previous condition is met, we can distinguish three different cases:

If the attacker uses a non-existing cell identifier, the application will not provide any geographical information of it, and thus we will assume that the serving cell is false.
If the attacker uses an existing cell identifier, belonging to a tower that is located far away from the place where the attacker is located, then Signal will report that we are in a location that does not match our real position. This fact will indicate that the serving cell is not legitimate.
If the attacker configures his base station pretending to be one of the neighbor cells and achieves that the terminal registers to his base station (by emitting a signal that is perceived by the victim's terminal as much "better"), then Signal will not show any clue about the legitimacy of the cell. We must say that, in this situation, it is much more difficult for the attacker to force the terminal to register to his base station, due to the fact that the victim's terminal probably can see two radio signals with the same cell identifier (we don't know the terminal behavior in this case). To overcome this obstacle, the attacker could choose the identifier of an existing nearby cell, for which the terminal is not perceiving power at all.

Our conclusion is that this application can help detecting whether the service that our terminal is receiving is legitimate or not, and it makes much more difficult for the attacker to maintain his attack undetected. However, it cannot be considered a 100% reliable method.

Even so, we think that the use of the tower geographical location provides a very good way to help detecting rogue base station attacks, and it should be combined with other techniques as, for example, the GPS information of the terminal, the analysis of other parameters of the radio signal or the detection of some functionalities that a false network will not tipically implement.

Network traffic analysis

For each one of the performed tests we have obtained the corresponding traffic capture using Wireshark. We have done so because, if there is an information source from which one can extract the geographical location of a mobile base station, of course we want to know it.

After analyzing some of the captures, we reach the conclusion that the source of such information was Google (what a surprise!). Also, we could realize that the answer/response has this appearence:

In the previous picture you can see that the request is qualified by the cell identifier (MCC, MNC, LAC and CI), and that the answer comes in "longitude/lattitude" format.
The "User-Agent" field reflects that we are using "wget" (instead of "Signal" as it would reflect any capture of the application traffic). This is because instead of using Signal we have written a little software tool to access this information, as explained below.

tadbsl.sh tool

This application is a shell script that, taking the cell identifier as input data, performs the correctly-formatted request to Google, using wget. Once the answer from Google comes, it shows the longitude and latitude on the console and, optionally, it starts a web browser showing the geographical location of the tower in Google maps.

The use instructions of the tool are shown here:

$ ./tadbsl.sh --help

tadbsl.sh --MCC= --MNC= --LAC= --CI= [-s | --show_in_browser]

tadbsl.sh [-h | --help]

	Description: this script asks Google for a particular

	Cellular Base Station Location and shows the Google's answer.

	(Based on the traffic analysis of Signal Cydia application

	 from PlanetBeing)

	Arguments:

		MCC: Mobile Country Code of the carrier owning the Base Station

		MNC: Mobile Network Code of the carrier owning the Base Staion

		LAC: Location Area Code of the Base Station

		CI:  Cell Identificator of the Base Station

	Options:

		-h | --help

			 Shows this help.

		-s | --show_in_browser

			 If you specify this options the script will launch

			 your browser with the obtained coordinates.

			 You can configure your browser location in a

			 configuration variable inside the script.

An example of use is shown below:

tad3@ubuntu:~/tadbsl$ ./tadbsl.sh --MCC=302 --MNC=720 --LAC=65010 --CI=48626

LOCATION: 49.1560525 , -123.1586519

This tool is available at our lab.

NOTE: We first published this article, in Spanish, in this post of the blog “Seguridad Apple”

Using Signal to Detect Rogue Cellular Base Stations (Part One)

2011-08-26T17:53:00.031+02:00

Some days ago Chema Alonso informed us that an application was able to show the geographical location of the tower that was providing service to an iPhone, as well as that of adjacent towers. The application also showed some technical data about these towers. Chema's question was whether this application could be used to detect a rogue base station attack or not. To be able to answer that question, we performed some tests. Some of them are explained in this article, as well as the conclusions and other things that we have obtained along the way.

The application is called Signal (available on Cydia) and has been written by PlanetBeing. The purpose of the authors is to create a map of nearby towers, measure their power and provide technical data about them.

Test I: testing the application with and without Internet access

Testing Lab

To perform the tests, we set up the laboratory shown in the picture:

The main objective of this set up was to be able to analyze the traffic generated by the application so that we could obtain preliminary conclusions before deciding what tests would follow.

Installation and first execution

After jaiblreaking our iPhone and installing Cydia, we configured the device in the following way:

We disabled 3G service to only accept GSM (this way it would be easier to provide service using our rogue base station)
The first time the application is launched, it asks if we want to use localization services. We answered "no" because we wanted to limit the available resources for the software to calculate its location, i.e., no GPS in the game.

Afterwards, we could see the application showing a map with the location of the towers nearby our position (somewhere in Valencia area), and a number that represents the perceived power in dBm. We checked that the geographical location really showed our position:

Running the application without Internet access

Since we suspected that the application obtained the geographical location of the towers from the Internet, we disabled all data services of the iPhone, including GPRS and WiFi.
In these conditions, as soon as the application started, we could see that the serving cell was detected and data and parameters belonging to it were reported. Also, the geographical location of a set of nearby towers was shown in the map, but with a different format, as we can see in the following picture:

The legend of color codes in the application reads as follows:

Blue: Visible towers
Red: Connected tower
Gray: Unlocatable tower
Yellow: Previously seen tower

It seemed to us that Signal kept some kind of cache where it stored information about previously seen towers. As the application has the ability to “Reset tower data”, we checked that when we chose this option, all geographical information was lost, and it didn't come back after several runs of the application.

Running the application with Internet access

After enabling WiFi, we started again the application and at that moment it detected again where the towers were in our geographical area.

Conclusions obtained in Testing Phase I

From the tests performed we can infer that:

Signal obtains the geographical information about cellular base sations from the Internet
The application holds a cache where it stores geographical information of the towers that he has previously seen; this cache can be erased by using the “Reset tower data” option

Test II: using a rogue base station

Testing Lab

For this second phase of tests, we modified our lab to provide GSM service using our rogue base station. The following schema illustrates this set up:

Testing with a non-existent cell identifier

To perform this test we configured our rogue base station for emitting with a non-existent cell identifier, and then we turned on the iPhone inside the cage (remember that the iPhone was connected to the Internet inside the cage through our WiFi infrastructure, as shown in the previous picture).

When the Signal application started, it detected the servicing tower and correctly reported our false cell identificator, but it could not locate that cell geographically.

Testing with a different cell identifier

In this test we used a cell identifier belonging to a cell that is located somewhere in the Madrid area (we were performing our tests in Valencia area) and, sure enough, the application located us in Madrid, next to that tower, as we can see in the following picture:

Conclusions obtained in Testing Phase II

From these tests we can infer that:

The identifying information about servicing tower is obtained from the radio signal
The geographical information, that Signal obtains from the Internet, depends uniquely on the cell identifier (MCC|MNC|LAC|CI) where:
- MCC: Mobile Country Code
- MNC: Mobile Network Code
- LAC: Location Area Code
- CI: Cell Identifier

NOTE: We first published this article, in Spanish, in this post of the blog “Seguridad Apple”

Building OWASP ZAP Using Eclipse IDE for Java… Pen-Testers

2011-08-11T10:20:00.015+02:00

If I were only given a single tool for a web application penetration test, that would definitely be a web interception proxy!

As you can check within Samurai WTF, the number of web interception proxies available to web app analyst and pen-testers is... (at least) quite large. During the last years (after the old initial Achilles days... Wow!, from Oct 13, 2000), a few proxies have become the web application security assessment tool of choice. OWASP Webscarab, together with Paros (Proxy), have been two of the most commonly used open-source alternatives, with Burp (Suite) on the free/commercial side (but not open-source).

Unfortunately (or not... keep reading ;-p) Webscarab and Paros were somehow discontinued. The lastest official Webscarab build (not from GIT) is from May 2007, and Webscarab-NG (Next Generation) was born as a very promising Webscarab replacement, but is slowly progressing with new features and releases. Paros ended up on the famous 3.2.13 version from August 2006 (5 years ago!) and a replacement project or fork was born afterwards, called Andiparos. In parallel, a new OWASP project saw the light, called ZAP (Zed Attack Proxy). On a very smart decision from their leaders (Psiinon and Axel), both projects joined forces to contribute to a single and common open-source web interception proxy (and security assessment tool, considering all the features currently available within ZAP), keeping the name of ZAP for the final project. Therefore, OWASP ZAP (Zed Attack Proxy) is definitely the current open-source web interception proxy and security assessment tool of reference.

What all these web interception proxy tools have in common? They have been developed in Java, what makes them great multi-platform (Windows, Linux, Mac OS X...) security assessment tools.

Experience has demonstrated during the last few years that pen-testers need to use two types of tools on their daily activities: the latest official stable tool release, typically distributed by the project as a prepackaged and ready to install bundle (.tar.gz, .zip, .jar, etc), and the most current development tool revision, the one that includes the most cutting edge, neat and mighty features, options, and capabilities, typically distributed by the project from the official Subversion (SVN/CVS, GIT, etc) repository.

Most pen-testing tools are developed using traditional languages, like C/C++ (e.g. nmap), where the standard 3-way build handshake works like a charm ("./configure", "make" & "sudo make install"), or using interpreted languages, where there is no need to build the package, such as Ruby (e.g. Metasploit), Python (e.g. w3af), or others.

But... what about the Java-based web interception proxies? I've discovered that there is a significant barrier to entry that make it difficult for pen-testers to enter into the building process of this kind of tools, as a simple "javac" (Java compiler) invocation does not make the trick. In order to compile and build Java-based web interception proxy tools, as they make an extensive use of GUIs and library sets, a Java IDE (Integrated Development Environment) is required.

As a result, lots of security professionals cannot and are not using the most current features of these tools until a new official version is released by the project. In order to overcome this, I have released the "Building OWASP ZAP Using Eclipse IDE for Java… Pen-Testers" guide, available for download (as usual) from Taddong's lab.

The goal of this document is to provide a simplified step-by-step guide web app pen-testers can go through to be able to easily build the most current OWASP ZAP version from the official Subversion repository by using the open-source Eclipse Java IDE. A final appendix provides some brief guidance for those interested on, not only using the latest tool features, but contributing to the OWASP ZAP project (what I encourage you to do).

Do not forget to always, but specially when using the most current development version, extensively test the tools on your lab environment before using them against the real pen-test targets, probably in production (at least, before you started using the tool... :-)

OWASP Session Management Cheat Sheet

2011-07-26T09:41:00.005+02:00

The results and conclusions obtained from dozens of web application penetration tests completed during the last few years confirm that session management is still today one of those web application critical components prone to suffer multiple and critical vulnerabilities.

Session management is a core and very complex module in modern web application architectures, and has to integrate smoothly and securely with other critical components, such as the authentication and access control modules:
Sessions, represented by a session ID or token, bind the user authentication credentials to the user HTTP traffic and the appropriate access controls enforced by the web application. The stateless nature of the HTTP protocol, the complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

Unfortunately most people put the focus on the top two or three risks or vulnerabilities, injection (being SQL injection the top one), Cross-Site Scripting (XSS) and (if lucky) Cross-Site Request Forgery (CSRF), but the OWASP Top 10 already reflected the importance of session management flaws on its 2007 version (7th position - A7), and highlighted this fact even more in the 2010 version, raising authentication and session management risks ("A3: Broken Authentication and Session Management") to the 3rd position.

Although the emphasis goes to authentication, due to all the weaknesses of the current authentication mechanisms (mainly based on username and password), session management tends to suffer serious vulnerabilities even for the most secure web applications. Do not forget that, once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the web application, such as username and password, passphrase, one-time password (OTP), client-based digital certificate, smartcard, or biometrics (such as fingerprint or eye retina).

For all these reasons, the OWASP Session Management Cheat Sheet has been released, with the goal of providing guidance and best practices to web application architects, developers, and information security professionals when building or auditing the session management module of web applications.

The whitepaper with the original content that has inspired and has been used for the creation of the first version of this OWASP cheatsheet is available in PDF format for easy download, distribution, and usage at Taddong's lab.

I encourage anyone involved in web application security to provide comments, feedback, and improvements to the OWASP Session Management Cheat Sheet, for the benefit of the whole web application community.

Our latest Security Challenge

2011-07-16T01:52:00.019+02:00

In the past few years, some of us have had the opportunity to participate in some security challenges organized by different teams in different events. It has always been an experience where we have had a lot of fun and where we have learned a very useful knowledge. The way the sponsor have created the challenges it is always different and this point of view make you acquire another perspective. Also, the way that other participants or people in your team approach a problem is also extremely interesting and didactic. When the challenge finishes you always have this feeling of a very good job by everyone, and a very rich experience in the technical and personal area.

Other times, we have been in charge of designing and prepare one or more security challenges in the context of a particular event. In this case, it is also a very interesting experience, because preparing a challenge makes your kwnowledge go deeper and wider. You also have a lot of fun trying to guess how the participant will behave when he is in front of the problems you are creating for him and, after that, you have the opportunity to check whether you were right or wrong, watching the participants make their way to the solution. Also, participants usually provide solutions that are different from those that you designed.

For all these reasons we always encourage any person that likes computer security to participate in such activities.

At present, we are involved in a security challenge of the second flavour: Movistar Mexico, sponsor of Campus Party Mexico 2011, has asked us to prepare a set of security challenges in the context of the event. The challenge has been named "Retos Movistar - Security Geek" and this is the official website.

We have designed seven security challenges, grouped into two main categories:

offline challenges, accessible by everyone that can be solved using only your own PC
online challenges, that are online accessible through internet if you have registered into the challenge

The tests that we have prepared cover different areas of security: from malware analysis to web security, from forensics to pen testing, and more... Tests are absolutely independent, so that participants can solve one test without even starting other.

The challenge has just started and will last until Saturday 23th of July. We hope that the experience will be fun and motivating for all participants. All the information can be found in the web page of the challenge and news and notifications can be followed through the official twitter account @SecurityGeekCP3 (hashtag #secgeekcpmx3)

TLSSLed v1.1

2011-07-10T12:50:00.001+02:00

A few weeks ago we released TLSSLed v1.0 with the goal of helping organizations to test their SSL/TLS (HTTPS) implementation for common flaws and misconfigurations. Today, we release an updated version, v1.1, that includes some additional tests.

The new tests check the certificate public key length, the certificate subject and issuer (CA), as well as the validity period, but besides that, they focus on the existence of HTTP secure headers on the target website main page (by using the HTTP/1.0 HEAD method), such as Strict-Transport-Security and cookies with and without the "secure" flag set.

TLSSLed v1.1 can be downloaded from Taddong's lab.

Future versions of the tool are open to improvements and new tests. Do not hesitate to contact me with ideas!

TLSSLed v1.0

2011-05-27T19:51:00.000+02:00

When running web application security assessments it is mandatory to evaluate the security stance of the SSL/TLS (HTTPS) implementation and configuration. OWASP has a couple of references I strongly recommend to take a look at, the "OWASP-CM-001: Testing for SSL-TLS" checks, part of the OWASP Testing Guide v3, and the Transport Layer Protection Cheat Sheet.

We have had several tools to test for SSL and TLS security misconfigurations along the years, but still today, lots of people get the output from all these tools and are not very sure what they need to look at. Apart from the SSL/TLS web application best practices, it is important to also check the security of SSL/TLS at the web platform layer.

The purpose of the TLSSLed tool (named from the idea of your website being TLS/SSL-ed, that is, using "https;//") is to simplify the output of a couple of commonly used tools, and highlight the most relevant security findings of any target SSL/TLS implementation. It is based on sslscan, a thorough SSL/TLS scanner that is based on the openssl library, and on the "openssl s_client" command line tool.

TLSSLed is a Linux shell script inspired on ssl_test.sh by Aung Khant, where a few optimizations have been made to reduce the stress on the target web server (sslscan is run only once and the results are stored on a local file), and some tests have been added and tuned.

The current tests include checking if the target supports the SSLv2 protocol, the NULL cipher, weak ciphers based on their key length (40 or 56 bits), the availability of strong ciphers (like AES), if the digital certificate is MD5 signed, and the current SSL/TLS renegotiation capabilities. The tool is open to comments, suggestions, improvements and new tests from the community. Do not hesitate to contact me with ideas!

NOTE: First idea for v1.1 - Would it be useful to check for the certificate key length (<= 1024 bits)?

TLSSLed v1.0 can be downloaded from Taddong's lab.

The following output shows how to use TLSSLed and the kind of results you will get. It only requires two arguments ("yes, I know, with no verification..."): the target HTTPS server hostname (or IP address) and the target port. The example below shows a secure implementation from https://www.owasp.org, because unfortunately, I'm sure you will find multiple insecure examples out there (Make your web environment look the same!):

$ ./TLSSLed.sh www.owasp.org 443

------------------------------------------------------
 TLSSLed - (1.0) based on sslscan and openssl
 by Raul Siles (www.taddong.com)
 ( inspired by ssl_test.sh by Aung Khant )
------------------------------------------------------
+ openssl version: OpenSSL 0.9.8g 19 Oct 2007
+ sslscan version 1.8.2
------------------------------------------------------

[*] Analyzing SSL/TLS on www.owasp.org:443 ..

[*] Running sslscan on www.owasp.org:443...

[*] Testing for SSLv2 ...

[*] Testing for NULL cipher ...

[*] Testing for weak ciphers (based on key length) ...


[*] Testing for strong ciphers (AES) ...
    Accepted  SSLv3  256 bits  DHE-RSA-AES256-SHA
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  128 bits  DHE-RSA-AES128-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  TLSv1  256 bits  DHE-RSA-AES256-SHA
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA
    Accepted  TLSv1  128 bits  AES128-SHA

[*] Testing for MD5 signed certificate ...

[*] Checking preferred server ciphers ...
  Prefered Server Cipher(s):
    SSLv3  256 bits  DHE-RSA-AES256-SHA
    TLSv1  256 bits  DHE-RSA-AES256-SHA


[*] Testing for SSLv3/TLSv1 renegotiation vuln. (CVE-2009-3555) ...
depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy ...
... Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
verify error:num=19:self signed certificate in certificate chain
verify return:0
RENEGOTIATING
Secure Renegotiation IS supported
12172:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:

[*] New files created:
-rw-r--r-- 1 samurai samurai 5980 2011-05-27 19:47 sslscan_www.owasp.org:443_2011-05-27_19:46:59.log


[*] done

Vulnerability in Android: To add, or not to add (a Wi-Fi network), that is the question

2011-05-05T01:50:00.000+02:00

Title: Preferred Network List (PNL) disclosure vulnerability in Android based on the method used to add Wi-Fi networks
Vulnerability ID: TAD-2011-003
Credits: This vulnerability was discovered by Raul Siles, Founder and Senior Security Analyst with Taddong (www.taddong.com)
Publication date: May 5, 2011
Vendors contacted: Android Security Team

Vulnerability Summary:
Depending on the method the user followed to add a Wi-Fi network to its Android mobile device, selecting it from the Wi-Fi networks scan list or manually through the “Add Wi-Fi Network” button, the network name could be disclosed in the air by Android and be used by an attacker to impersonate that network, forcing the victim mobile device to connect to it to capture and manipulate its traffic and launch more advanced attacks.

For all broadcast Wi-Fi networks the user has previously connected to from the “Add Wi-Fi Network” button, it is advised to delete them all and re-add them back from the scan list once the user is under the network coverage.

Android users should preferably connect to a new broadcast Wi-Fi network from the scan list and use the “Add Wi-Fi Network” button only for connecting to a non-broadcast Wi-Fi network. A non-broadcast Wi-Fi network does require a Wi-Fi client to expose the network name in its probe request packets in order to be able to successfully connect to the network, making the client vulnerable to the previously mentioned security threats.

Vulnerability Description:
Android mobile devices, as most Wi-Fi clients, keep a list of the wireless networks manually configured, plus the networks it has connected to in the past, on the Preferred Network List (PNL). Every time the Wi-Fi interface is turned on, and periodically once it has been activated (for example, to roam between access points), the device checks through 802.11 probe requests what networks in its PNL are available in the current location. Based on the responses obtained, it tries to connect to the most preferred network.

In the past this network discovery process was performed by sending a generic probe request for the broadcast (or any) network plus specific requests for every network in the PNL. This meant devices disclosed the full PNL in the air [1], exposing themselves to karma-like attacks [2], where an attacker can identify all the networks (or access points) the mobile device is trying to connect to and impersonate them, forcing the victim device to connect to the attacker's network to capture and manipulate its traffic and launch more advanced attacks.

In order to avoid this vulnerable behavior, modern operating systems and Wi-Fi supplicants changed the previous vulnerable behavior not to advertise the wireless networks in its PNL. Modern Wi-Fi clients only generate 802.11 probe requests for the broadcast network, generically asking for the networks available in the area. An exception to this behavior is presented by the existence of Wi-Fi hidden networks in the PNL: due to the fact hidden (or non-broadcast) networks do not include their SSID (Wi-Fi network name) in the beacon frames, and do not respond to generic queries asking for any network available, the Wi-Fi clients need to specifically ask for these hidden networks, disclosing its name and existence inside the device PNL. This makes devices vulnerable again to the aforementioned attacks.

Android mobile devices provide two methods to add and configure Wi-Fi networks into the device. If the network is visible, it will appear on the Wi-Fi networks scan list. By simply selecting it form the list, and after providing the network credentials, the user can add the Wi-Fi network to the device. Additionally, Android provides an “Add Wi-Fi network” button at the bottom of the scan list, to manually add Wi-Fi networks. This is the only method available to add hidden networks, as they will never appear on the scan list.

However, Android does not provide any specific configuration option through this method to specify if a network is hidden (non-broadcast) or visible (broadcast). Although the most natural way of adding a network for end users is from the scan list (fortunately, for Android, this is the secure option), unfortunately, the method of manually adding Wi-Fi networks to a device is very common too, and recommended from a security perspective, as advanced users have more control over all the Wi-Fi network settings and options.

This subtle configuration behavior has serious security implications. Depending on how the user added the Wi-Fi network to the device, selecting it from the scan list or through the "Add Wi-Fi network" button, you are vulnerable or not. As a result, all the Wi-Fi networks (hidden or visible) added to Android through the “Add Wi-Fi network” button are implicitly considered as hidden, its details will be revealed in the air, and the mobile device will be exposed to Karma-like attacks [2].

The expected non-vulnerable behavior implies the propagation of probe requests only for the broadcast (or any) network plus all the intentionally configured hidden networks in the PNL. By default, unless it is clearly specified by the user, all networks should be treated as visible, not generating any probe request frames for them.

The vulnerable behavior exists on the default Android configuration when adding a Wi-Fi network through the “Add Wi-Fi network” button; the Wi-Fi networks connected from the scan list are not exposed and hence not vulnerable.

This vulnerable behavior is similar to TAD-2010-003 [3], but in the case of Android, only those Wi-Fi networks added through the “Add Wi-Fi Network” button are disclosed, instead of the full PNL.

Security Solutions, Workarounds, and Countermeasures:
Every time a user connects to a Wi-Fi network for the first time from her Android mobile device, it must select it from the Wi-Fi networks scan list, instead of using the “Add Wi-Fi Network” button except when connecting to hidden networks (option not recommended). This method ensures the Wi-Fi network will be added to the PNL in a secure way and won’t be disclosed through probe request scans.

End users, corporate administrators, and security professionals, using or managing Android mobile devices must be aware of this behavior and ensure that all the Wi-Fi networks available on the device PNL are treated as visible.

Unfortunately, Android does not provide any indication on the user interface to be able to differentiate between the two types of networks (hidden or visible) for the already configured Wi-Fi networks. Once a Wi-Fi network has been added, the user cannot know if it was securely added or not. Thus, for all Wi-Fi networks previously added to the device the user must delete them all and re-add them again, selecting each of them from the scan list (and not using the “Add Wi-Fi Network”) once the user is under the network coverage (and it is visible).

A similar scenario occurs for those Wi-Fi networks that were configured as hidden in the past, were manually and insecurely added to Android, and are configured as visible now because the administrator learned about Karma-like attacks and improved the security of the network by making it visible. It is highly recommended not to setup or connect to Wi-Fi hidden networks, as the Wi-Fi clients will be exposed to the attacks previously mentioned.

A more granular solution is to monitor the mobile device Wi-Fi traffic, identify what Wi-Fi networks Android is generating probe requests for, and delete and re-add again only those networks.

The recommended solution would be for Android to add a new configuration setting to the user interface that allows the user to specify if the network must be considered hidden or visible every time a new Wi-Fi network is added to the mobile device, independently of the method used, or at least when it is manually added through the vulnerable “Add Wi-Fi Network” button. The default value for this new setting must reflect that the network to connect to is visible (unless the user specifies otherwise by changing the default value).

Besides that, Android users should be able to see and change this “type of network” setting at any time, that is, when the Wi-Fi network is added for the first time, or afterwards, through the "Edit network" button.

Vulnerable Platforms:
The vulnerable behavior was discovered on Android 2.2.

The Android Security Team has confirmed this vulnerable behavior also affects all currently available Android 2.x and 3.x versions (such as 2.2.1, 2.2.2, 2.3, 2.3.2, 2.3.3, or 3.0).

Vendor Information:
The Android Security Team confirmed the existence of this vulnerable behavior and is working on changing the "Add Wi-Fi Network" dialog box to read "Configure a non-broadcast network". The original intent of the "Add Wi-Fi Network" dialog box was only to add non-broadcast networks; the wording will hopefully make that clearer.

The new dialog box text will inform aware users that probe request messages will be sent from their device. They also confirmed there is no Android documentation available which describes the “scan list” versus the “Add Wi-Fi Network" behavior, hence the importance of the distribution of this security advisory in an effort to raise awareness on this issue.

In the “Vulnerability Description” section above, Taddong generally recommends from a security perspective the method of manually adding Wi-Fi networks to a device so that advanced users have more control over all the Wi-Fi network settings and options. The Android Security Team thinks that adding a network via the scan list is more secure, because more critical security information can be conveyed automatically, rather than relying on the limited options available to the user. We (at Taddong) agree this could be true for the average user, especially to avoid misconfiguration and user mistakes, IF the user connects to a secure and properly configured Wi-Fi network, but unfortunately, this is not always the case.

We at Taddong honestly believe this finding must be publicly known by end users and by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have tried to coordinate the release of this security advisory together with the vendor, following responsible disclosure principles. This vulnerable behavior is especially relevant considering the broad market adoption of Android mobile devices (with significant increasing adoption estimations for the upcoming years), and its extensive usage to connect to Wi-Fi networks.

Vulnerability Report Timeline:
2011-04-08: Taddong contacts the Android Security Team to provide details about this vulnerable behavior. The Android Security Team requests more details and clarifies the expected behavior.
2011-04-09: Taddong provides extra details after reanalyzing the expected behavior and ratifies the vulnerable behavior only when the “Add Wi-Fi Network” button is used. Taddong asks for details to differentiate the two types of networks, available documentation, expected behavior, and future plans to mitigate the vulnerable behavior.
2011-04-12: Taddong asks for feedback, and the Android Security Team replies back clarifying the previous questions and notifying future plans to improve the Android user interface. Both parties start to coordinate the public disclosure of this issue.
2011-04-15: Taddong completes and provides an initial security advisory draft to the Android Security Team for its review and comments. The Android Security Teams confirms its reception, internal distribution, and feedback is expected for next week.
2011-04-22: The Android Security Team confirms it is still collecting feedback regarding the security advisory draft.
2011-04-28: Taddong tries to get an update of the status of the security advisory draft review process.
2011-05-04: Taddong again tries to get an update of the status of the security advisory draft review process. The Android Security Team provides its review and comments to the security advisory draft.
2011-05-05: Taddong publishes security advisory TAD-2011-003.

References:
[1] "Trying to shut up your wireless chatty Windows". Raul Siles. 2005.
URL: http://www.raulsiles.com/docs/Chatty_Windows_Wifi_Sep05.html
[2] "KARMA Wireless Client Security Assessment Tools". Dino A. Dai Zovi. 2005.
URL: http://theta44.org/karma/index.html
[3] “TAD-2010-003: Full 802.11 Preferred Network List (PNL) disclosure in windows Mobile 6.5”. Raul Siles. Taddong. 2010.
URL: http://blog.taddong.com/2010/09/vulnerability-in-indiscreet-wi-fi.html

About Taddong:
Taddong (www.taddong.com) is a company established in Spain in 2010 with the purpose of improving customer's information security, by discovering and eliminating or mitigating the real risks that threaten their networking and information technology infrastructures. To achieve this goal, Taddong's portfolio includes specialized information security services, requiring an in-depth technical knowledge and broad understanding of the information technology market, as well as training services, focused on providing customers with auto-defense skills. Taddong remains at the forefront of the security market through continuous research and education activities.

Disclaimer:
The contents of this security advisory are copyright (c) 2011 Taddong S.L., and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

Selective attack with a rogue GSM/GPRS base station

2011-05-03T22:43:00.026+02:00

An attacker employing a rogue GSM/GPRS base station usually wants to compromise the communications of a particular user, while trying to generate the least possible activity for the rest of mobile users within his radio range. We call this a “selective attack”. In order to perform it, the attacker must know the victim’s IMSI (the number that identifies a SIM card) in advance.
There are two widespread misconceptions regarding this type of attack. Most people think that:

A.- It is difficult to obtain the victim’s IMSI, and
B.- It is difficult not to affect the other users in the radio range of the rogue base station

However, there are some techniques that allow the attacker to solve the aforementioned issues. In this article we explain one of them as an illustrative example.

Discovering the victim’s IMSI

To solve point A, the attacker could do the following:

Step 1: the attacker positions himself in the area where his victim lives (the victim’s home location) when the victim is inside and captures all the IMSIs in the range of his rogue base station. He will probably use a directional antenna to limit the geographical area where he is capturing IMSIs. During this operation, the rogue base station will reject all registration attempts from any mobile, but it will annotate the IMSI numbers of the subscribers that are trying to register.
Step 2: afterwards (for example the next working day), the attacker positions himself in the victim’s office location, and performs the same procedure. It is to be expected that the first IMSI that is present in both IMSI lists will be the one of the victim.
Step 3: after that, the attacker should authorize the registration of the victim’s IMSI (and only this one) in his rogue base station in order to intercept all its communications. The registration attempts from any other IMSI will be rejected.

Avoiding affecting the rest of users.

Once point A is solved, let’s see how the attacker can tackle point B. First, and most important, notice that the attacker didn’t leave the registration open for all mobile stations at any time, thus preventing the appearance of any symptom that could alert the mobile users in the area (such as a sudden change in the coverage indicator, any abnormal error in outgoing calls, the absence of incoming calls, etc.) and any overload problem for his rogue base station (that will typically have limited capabilities for traffic and call management).
For every aforementioned step, the attacker performs the following configuration actions to affect the least possible the rest of mobiles in his radio range:

Step 1: the attacker will configure its rogue base station so that each IMSI tries to register to it only once. This is convenient for him for several reasons: it will minimize any symptoms in the mobile phones in his range, and also he will reduce to the minimum redundant and useless information in his logs. One way to achieve this objective is to configure a Reject Cause Code 0x0C “Location Area Not Allowed”. This reject code is included by the base station in the “Location Update Procedure Reject” message, sent whenever the base station rejects a registration attempt. According to 3GPP 24.008 and the tests in our lab, the mobile station annotates the LAI (Location Area Identifier) in its “forbidden location areas” list and it will not try to register to any cell with this LAI (at least not until the mobile station is reset or the SIM is removed). This way, the attacker is forcing the mobile terminals in his range to try to register only once to his rogue base station, but they will continue to be able to register back to a legitimate base station.
Step 2: at this moment the attacker wants the victim’s mobile station to be rejected in its first registration attempt, as well as the other subscribers in his radio range. He can configure its rogue base station with a LAI different from the one used in the previous day, so that he will ensure that the mobile station will try to register again. Once identified the first IMSI matching any one stored the previous day, he shutdowns the base station.
Step 3: at this time, the attacker already knows the victim’s IMSI. He can then turn on again his rogue base station with a new LAI and with the victim’s IMSI authorized. When the victim’s mobile station tries to register, the registration will succeed and the attacker will be able to intercept the communications of the victim. All other mobile stations will try to register only once in the rogue base station and will register back to a legitimate cell, because the configured Reject Cause Code will still be 0x0C.

This procedure would allow an attacker to identify the victim’s IMSI with a first capture session that would last some minutes, and a second session in which he would be able to selectively intercept the victim’s communications. The only collateral effect on other mobile terminals in the attacker’s range would be that they would try to register to his rogue base station, but only once (or twice at most), and the users won’t even get an indication of this fact on their screens.

NOTE: We first published this article, in Spanish, in this post of the blog “Un informático en el lado del mal”

Vulnerability in SAP NetWeaver Portal: Session Fixation

2011-03-18T20:17:00.003+01:00

Title: Session fixation vulnerability in the SAP J2EE Engine affecting the core SAP NetWeaver platform
Vulnerability ID: TAD-2011-002
Credits: This vulnerability was discovered by Raul Siles, Founder and Senior Security Analyst with Taddong (www.taddong.com)
Publication date: March 18, 2011
Vendors contacted: SAP AG

Vulnerability description:
SAP's NetWeaver platform is vulnerable to a (web based) session fixation vulnerability. An initial HTTP connection to the J2EE Engine gets assigned a standard Java cookie, named JSESSIONID, that contains the user session ID pre-authentication. Once the user successfully authenticates through any SAP web application or module, hence using the SAP NetWeaver platform and the SAP J2EE Engine, the session ID is not renewed post-authentication, therefore, the platform is vulnerable to session fixation.

SAP NetWeaver is SAP’s integrated technology platform and technical foundation for all SAP applications and modules:

This session fixation vulnerability can be used to selectively attack targeted key business SAP users (regular or administrator), as well as any SAP user indiscriminately. As a result of the attack, the attacker will get unauthorized access to SAP by hijacking the victim user session and fully impersonating the user within the SAP environment.

Session fixation vulnerabilities can be leveraged to bypass the most advanced authentication mechanisms, including passphrases, client-based digital certificates, smart cards, and biometrics.

Considering SAP industry presence as the world’s leader in business software, and its current numbers (+100K customers in 120 countries, +140K installations, and +2,4K certified partners), the impact of this specific vulnerability is extremely high worldwide, affecting thousands of critical business environments and their daily activities.

All the vulnerability details, how it was discovered, worldwide impact, and additional protections mechanisms (apart from the ones detailed in this advisory) are available on the associated presentation and whitepaper [1], and specifically on case study #3.

Security solutions, workarounds, and countermeasures:
Companies and organizations using SAP products and solutions, therefore the SAP NetWeaver platform, must apply the recommendations detailed on the associated SAP Security Note, 1310561 [2], and ensure that the newly added "SessionIdRegenerationEnabled" Web Container Service property is enabled. Turning on this property adds a new secure (HTTPS) cookie to sessions, called JSESSIONMARKID, that gets renewed after a successful login, thus mitigating session fixation attacks.

By default, this property is disabled in previous/legacy versions (6.x), and it is enabled since version +7.11 SP06 and all SPs for 7.20 and 7.30.

Taddong's Black Hat Europe 2011 presentation and whitepaper associated to this advisory [1] contain considerations for specific deployment scenarios, additional SAP security-related properties, and other recommended security best practices to mitigate session fixation (as well as other session management) attacks.

Vulnerable platforms:
SAP has confirmed that multiple SAP NetWeaver versions are vulnerable, including 6.40 up to 7.20. See the associated SAP Security Note for details [2].

The vulnerability was discovered on SAP NetWeaver Portal version 6.4.200607310245.

Vendor information:
SAP confirmed the existence of this vulnerability on July 2009 and released an associated SAP Security Note, number 1310561, on December 2010 [2], acknowledging proper security researcher credit [3].

We at Taddong honestly believe this finding must be publicly known by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have tried to coordinate the release of this security advisory together with the vendor, following responsible disclosure principles. This vulnerability is extremely relevant considering the extensive number of SAP-based business environments available in the industry and the potential impact of the associated attacks.

Vulnerability report timeline: (Summary)
2009-07-02: Taddong contacts SAP to provide details about this vulnerability.
2009-07-14: SAP ratifies the vulnerability and provides the temporary available countermeasures ("SessionIdRegenerationEnabled"). The disclosure plans and estimated timeframe for a fix started to get discussed.
2009-07-23: The initial estimated timeframe is set in two months (end of September), being both parties aware that most probably this is a best case scenario.
2009-09-18: A few difficulties and stability issues associated to fixing the vulnerability started to arise, so a new fix estimate is set for January 2010. During the next couple of weeks different options are evaluated to reduce the newly estimated deadline, and to analyze the real impact worldwide.
2009-11-24: An status update is requested by Taddong, and the January estimation is confirmed to be still valid. An initial technical solution was being tested by that time. Besides that, the disclosure plans and models of both parties continued being evaluated. SAP clarifies is in the process of evaluating its externally facing security program.
2010-01-26: A solution is still not available, the issue was escalated internally, and several months were required to be able to fix the vulnerability for all the different releases affected (7 months after initial notification). During the process, responsible disclosure and impact are reevaluated.
2010-03-08: A new deadline is established for September 2010 trying to cover all releases, as a few issues were found on legacy versions. In parallel, the option of providing partial fixes for specific customers is under evaluation (9 months after initial notification).
2010-08-06: A meeting is scheduled for November 2010 with the goal of discussing in-depth the vulnerability details and conclusions, plus collaborating and agreeing on the final disclosure actions and release deadline (13 months after initial notification).
2010-12-14: The vulnerability is privately released by SAP in the SAP Service Marketplace as Security Note 1310561 [2] to its customers and partners (18 months after initial notification).
2011-03-17: The vulnerability and lessons learned are publicly released by Taddong during the Black Hat Europe 2011 conference in Barcelona [1] after an implementation time of three months (21 months after initial notification).
2011-03-18: Taddong publishes this security advisory.

References:
[1] "SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. Taddong. Black Hat Europe 2011. March 2011.
URL (presentation): http://www.taddong.com/docs/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf
URL (whitepaper): http://www.taddong.com/docs/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf

[2] SAP Security Note 1310561. SAP. December 2010. (Registration on the SAP Service Marketplace, SMP, is required).
URL: https://websmp130.sap-ag.de/sap/support/notes/1310561

[3] SAP acknowledgements to security researchers. SAP. December 2010.
URL: http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/c05604f6-4eb3-2d10-eea7-ceb666083a6a

About Taddong:
Taddong (www.taddong.com) is a company established in Spain in 2010 with the purpose of improving customer's information security, by discovering and eliminating or mitigating the real risks that threaten their networking and information technology infrastructures. To achieve this goal, Taddong's portfolio includes specialized information security services, requiring an in-depth technical knowledge and broad understanding of the information technology market, as well as training services, focused on providing customers with auto-defense skills. Taddong remains at the forefront of the security market through continuous research and education activities.

Disclaimer:
The contents of this security advisory are copyright (c) 2011 Taddong S.L., and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

Browser Exploitation for Fun & Profit Revolutions

2011-03-09T18:16:00.002+01:00

Unexpectedly, at the end of last week I had to prepare in less than 24 hours the third (and last by now) episode of the "Browser Exploitation for Fun and Profit" trilogy, dubbed "Revolutions". With this one, the "Matrix-like" series is over ;)

I have had most of the ideas I wanted to highlight on the third episode on my mind for a few weeks/months, but had to put them all together on a slide deck for a last minute presentation slot on the awesome Rooted CON 2011 Spanish security and hacking conference. It was the perfect scenario to finish the trilogy:

Picture by @a_zumito.

The full trilogy is available on three different Taddong's blog posts and associated presentations:

"Browser Exploitation for Fun and Profit". November 2, 2010. SANS Special Webcast. Internet.
"Browser Exploitation for Fun and Profit Reloaded". December 2, 2010. SANS@Night. SANS London 2010. London, UK.
"Browser Exploitation for Fun and Profit Revolutions" (this post). March 4, 2011. Rooted CON 2011. Madrid, Spain. Presentation available here.

Each episode content somehow builds on the topics and knowledge covered on the previous episodes, trying to minimize the overlap, except for the most important messages and goals I wanted to address with this initiative:

XSS vulnerabilities and attacks are undervalued, and both their risk and real impact must be seriously considered by any organization interested on protecting their web applications, and collaterally, their web users and clients.
XSS (Cross-Site Scripting) should be renamed WCI (Web Content Injection) in order to reflect the real scope of the attack, as well as what can be really done with it.
One of the main goals was to provide web application pen-testers with an open-source XSS exploitation platform, based on Samurai WTF, BeEF (the old PHP-based and the new Ruby-based versions) and Metasploit, to push XSS vulnerabilities to the limit and be able to really demonstrate the impact of XSS.

This third episode emphasizes all these main principles, focusing on the current XSS state-of-the-art and using (again) a practical and live demo, plus including two related topics I had a pending publication for:

A “new” kind of XSS I have dubbed "Global (or URL-based) non-persistent XSS": I've called it "new" not stating I'm the one that has discovered it, but emphasizing how most organization put all their attention on enforcing input validation and output encoding to mitigate XSS vulnerabilities mainly on HTTP parameters (GET and POST) and HTTP headers, forgetting about the URL itself.
There are specific scenarios, such as web applications with multi-language support, where this vulnerability is specially relevant, and in particular, due to its global nature, as it affects all the resources within the web application.

Multi-technology WCI (or XSS) on mobile devices: XSS, or better said WCI, not only affects the traditional web applications and web browsers but other "web clients" (or web-based user interfaces) associated to wireless technologies, such as the SMS or Bluetooth notification systems in mobile devices, like Windows Mobile (WM) 6.1, WM 6.5 (HTC), or Palm WebOS. My bet is that other inputs, such as barcodes, QR-codes, or audio, will affect mobile devices in the near future too!

I added a new final step to the live demo to demonstrate the BeEF frame redirect plug-in capabilities (by Yori Kvitchko), where the victim user can remain hooked to the BeEF framework through the vulnerable web application, while the vulnerable web page is hidden under a 100% iframe showing a different page, such as Google. Although this technique still has a few drawbacks on the pen-tester side due to the original URL and favicon not being replaced by the new attacker's iframe, this can be easily bypassed on some (web clients of) mobile devices (e.g. iPhone and Android) using URL or address bar hiding techniques (see the references at the end of the presentation).

I hope everybody attending any of the related presentations run during the last four moths, or that have simply read the material, enjoyed the whole trilogy. Now it is your turn to put that knowledge and skills into practice and help organizations to mitigate the impact and reduce the prevalence of XSS (or WCI) on web applications.

NOTE: In addition to these three episodes, I run an extra live episode on a special SANS promotion event in Madrid on January 25, 2011, "Browser Exploitation for Fun and Profit - Redux". It was a summary of episodes 1 and 2 in preparation for the last one (potentially) during Rooted CON 2011. The event was used to promote my upcoming 2-day "Metasploit Kung Fu for Enterprise Pen Testing" (SEC580, June 1-2, 2011) and 6-day "Web App Penetration Testing and Ethical Hacking" (SEC542, September 19-24, 2011) training courses in Spanish in Madrid later this year.

Does your phone warn you when it is not encrypting your calls?

2011-02-21T16:20:00.025+01:00

Looking at the following picture, do you know what the open lock icon, near the top left corner of the screen of the Nokia phone, mean?

In short, it means that the phone call is not being encrypted. But that being the case, shouldn't the iPhone be displaying a similar icon? (the call in progress in the picture was established between the two phones). Keep on reading, and you will see that there is more to it than meets the eye.

GSM usually encrypts your calls to protect your privacy, and the same goes for your GPRS/EDGE data connections. Now, GSM has many security problems, but for the purpose of this discussion, let us concentrate on the "usually" part in the above sentence.

The GSM specification gives full control to the network to select the encryption algorithm to be used to protect the communications on the radio interface, choosing from a set of supported algorithms, which nowadays in most cases include only two choices: A5/1, which is the most commonly used encryption algorithm in GSM networks (already broken, but that's another story), and A5/0, which is an euphemism for no-encryption-at-all. Thus, the network can choose to encrypt, or not, your communications.

Most GSM operators do encrypt their subscribers' communications, but some may choose not to do it, and in some countries, like India, they may even be required by law not to use encryption. Making things even more worrisome, an attacker can very easily set up a rogue GSM base station, pretending to belong to your usual network operator, and route all your calls and data connections, unencrypted, through his base station.

So, you cannot decide whether the communication will be encrypted or not. But, could you, at least, KNOW if your communication is being encrypted or not?

The GSM specification states that you, the user, "should" be informed by your mobile device when the communication is not encrypted (3GPP Rel.9 TS 33.102-920 "3G Security Architecture" 5.5.1 Visibility):

"Although in general the security features should be transparent to the user, for certain events and according to the user's concern, greater user visibility of the operation of security features should be provided. This yields to a number of features that inform the user of security-related events, such as:
indication of access network encryption: the property that the user is informed whether the confidentiality of user data is protected on the radio access link, in particular when non-ciphered calls are set-up;

[...]
The ciphering indicator feature is specified in 3GPP TS 22.101 [...]"

The referenced 3GPP TS 22.101 specification (R99 22.101-3.17.0), on section 13, "Types of features of UEs", says:

"The basic mandatory UE requirements are:
[...]
- Ciphering Indicator for terminals with a suitable display;
The ciphering indicator feature allows the ME to detect that ciphering is not switched on and to indicate this to the user. The ciphering indicator feature may be disabled by the home network operator setting data in the SIM/USIM. If this feature is not disabled by the SIM, then whenever a connection is in place, which is, or becomes unenciphered, an indication shall be given to the user. Ciphering itself is unaffected by this feature, and the user can choose how to proceed;"

Interesting! So, according to the specification, our mobile devices should tell us that the communication is not encrypted and we should be allowed to choose how to proceed, unless our SIM card were configured to disable this feature. However, is that how it is in real life?

In a little experiment we did in our lab, we took 2 SIM cards from 2 different network operators, let us call them Operator1 and Operator2, and we inserted them in the phones you saw in the previous picture, an old (2004) Nokia 6230, and a more recent (2008) iPhone 3G. Then, we established a call between them, using our own base station with A5/0, that is, no encryption, and the result was the one depicted in the previous picture: the old Nokia phone displayed the open lock icon, indicating that the call was not being encrypted, while the iPhone did not show any indication of this fact.

Then, we swapped the SIM cards between the two phones, and established again a call between them. The result: this time neither the Nokia 6230 nor the iPhone 3G displayed any indication of the call not being encrypted, as you can see in the following picture:

The conclusions we can draw from this little experiment are:

the Nokia 6230 will show an open lock icon when a call is not encrypted, unless the SIM card disables this feature,

the iPhone 3G will never notify the user about a call not being encrypted,

the SIM card from Operator1 (inserted in the Nokia Phone in the first picture) does not disable the ciphering indicator, and

the SIM card from Operator2 (inserted in the Nokia Phone in the second picture) disables the ciphering indicator

Think about it for a second, and then try again to answer the question in the title of this article: does your phone warn you when it is not encrypting your calls?

<plug>
If you want to find out, bring your mobile phone and SIM card to our GSM/UMTS (2G/3G) SECURITY training course, and you will be able to test it yourself! Sessions available in English and in Spanish!
</plug>

Vulnerability in HTC Peep: Twitter Credentials Disclosure

2011-02-04T00:30:00.084+01:00

Title: Twitter credentials disclosure in HTC Peep mobile app (default HTC Twitter client)
Vulnerability ID: TAD-2011-001
Credits: This vulnerability was discovered by Raul Siles, Founder and Senior Security Analyst with Taddong (www.taddong.com)
Publication date: February 4, 2011
Last update: March 17, 2011 - FOTA fixes released by HTC for Tattoo & Hero. See timeline and (UPDATE2) marks.
Previous updates: February 14, 2011 - Fix released by HTC and validated by Taddong. See timeline and (UPDATE) marks.
Vendors contacted: HTC (and MITRE - CVE ID)

Vulnerability description:
The default Twitter client (or application) in HTC mobile devices is called HTC Peep. HTC Peep is vulnerable to two different credentials disclosure vulnerabilities during the authentication process against the Twitter service (twitter.com).

During the authentication process, the HTC Peep app establishes an HTTP (TCP/80) connection against the twitter.com servers, sending a few HTTP OAuth-related requests. The first two HTTP GET requests try to gather and make use of an OAuth token: "GET /oauth/request_token" (the response contains the "oauth_token") and "GET /oauth/authorize?oauth_token=...".

The first vulnerability resides in the third HTTP request, a POST request towards the "/oauth/authorize" resource, which contains several parameters, including the Twitter username and password in the clear, making the authentication process vulnerable to eavesdropping attacks:

authenticity_token=c8b5abaf53f223e827d9258ddfef4285a816db5f&

oauth_token=I4FK956n1foaHjayLKXJT2IaBpsmoo0amKyPhebc&

session%5Busername_or_email%5D=USERNAME&session%5Bpassword%5D=PASSWORD

This authentication exchange should be protected by HTTPS, forcing the credentials to be sent over an encrypted channel.

The second vulnerability resides in the way HTC Peep works. Once the Twitter session has been established, all the HTTP requests from the mobile device to the Twitter service include an HTTP Basic authentication header that contains the Twitter username and password (although the app is supposed to be using OAuth). Examples of standard Twitter resources retrieved through HTTP GET requests: "/direct_messages.json?count=50&page=1", "/favorites.json?page=2", "/statuses/friends_timeline.json?count=50&page=1", or "/statuses/mentions.json?count=50&page=1".

GET /statuses/friends_timeline.json?count=50&page=1 HTTP/1.1

Accept: text/xml, application/xml;q=0.9, */*;q=0

Authorization: Basic BASE64("USERNAME:PASSWORD")

User-Agent: TwitterEngine

Host: twitter.com

OAuth is a technology that enables applications to access a service, in this case Twitter, on behalf of the user, with the user approval, without asking the user directly for (or storing) her password. HTTP Basic authentication is one of the most basic, hence the name, and insecure web-based authentication mechanisms. The credentials are sent (almost) in the clear on every HTTP request from the web client to the web server. In fact, the credentials ("username:password") are encoded in Base64 in the HTTP "Authorization" header. Simply by capturing or eavesdropping the web traffic and looking at the HTTP request headers, an attacker can easily obtain the user Twitter credentials.

The Twitter session can be protected by using a pure OAuth exchange, without making use of Basic authentication, or by protecting the whole session with HTTPS.

Coincidentally, the discovery of these vulnerabilities was aligned with Twitter's announcement to increase the security of third-party apps: "Starting August 31, all applications will be required to use “OAuth” to access your Twitter account". This service switch didn't make any difference regarding this vulnerability, as HTC Peep still works through its OAuth capabilities. However, as this advisory demonstrate, technology must be implemented properly. Historically, Twitter developers have been able to choose one of two authentication methods: Basic Authentication or OAuth. Somehow, HTC Peep is using both methods simultaneously, exposing the user credentials.

Modern mobile devices implement multiple communication technologies, such as IrDa, Bluetooth, Wi-Fi, and mobile (2G/3G). The last two, Wi-Fi and 2G/3G, are the most commonly used methods to establish data communications from the mobile device to other entities. Therefore, this vulnerability can be exploited on targeted attacks when the mobile device is using any of these two technologies:

Wi-Fi: When the mobile device connects to a Wi-Fi (802.11) network, an attacker can intercept all your web traffic if it is an open or WEP Wi-Fi network. If the network is based on WPA(2)-PSK, any user with access to that network can also collect all your traffic. You can protect your Wi-Fi data communications if you only connect to WPA2-Enterprise Wi-Fi networks (or, potentially, if you thoroughly make use of VPN technologies). Unfortunately, even when your device is not connected to any Wi-Fi network, still this vulnerability can be exploited in combination with other vulnerabilities, such as Karma-like attacks. See "TAD-2010-003: Full 802.11 Preferred Network List (PNL) disclosure in Windows Mobile 6.5".
2G/3G: When the mobile device connects to a mobile network (2G or 2.5G: GPRS or EDGE) an attacker can intercept all your web traffic. You can protect your mobile data communications if you only connect to +3G data networks. For more information see the "GPRS/EDGE Security" blog post and the recent "A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications" BlackHat DC 2011 Taddong presentation, by David and Jose.

Independently of the data network access used by the mobile device, at some point the web traffic will enter on the public Internet in the clear (unencrypted), where it can be intercepted by anyone with access to capture the traffic on any of the intermediate network segments between the mobile device and Twitter.

The fact that Twitter credentials can be easily eavesdropped has a pretty significant impact, as most users assume other users credentials have not been hijacked, therefore, they blindly trust tweets (or microblog/blog posts) coming from trusted parties (their friends, people they frequently follow, public personalities...). Twitter account hijacking can be used for web-based & client-based targeted attacks (specially through the use of short URLs), and can cause a significant damage to the image and credibility of the victim user.

While analyzing in-depth the affected HTC Peep version and the version associated to the temporary hotfix provided by HTC (LEO_S01175.exe), we collected the following details from the Windows Mobile registry:

[HKEY_LOCAL_MACHINE\Software\OEM\MASD]

"Manila_Twitter"="2_5_19212224_0"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\HotFix]

"Social_Networks_Engine_version"="20101005-00"

"Manila_Twitter_version"="20101005-00"

NOTE: Extract your own conclusions about the hotfix version number. Hint: It looks like a date.

(UPDATE) While validating the software update released by HTC on February 10, 2011, the version associated to the final hotfix (LEO_S01236.exe), replaces the following details on the Windows Mobile registry:

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\HotFix]

"Social_Networks_Engine_version"="20110208-00"

"Manila_Twitter_version"="20110208-00"

NOTE: It is a date ;)

Security solutions, workarounds, and countermeasures:
(UPDATE2) HTC has publicly released a couple of FOTA (Firmware Over-The-Air) fixes or updates [3] for HTC Tattoo and HTC Hero associated to the HTC Peep Client. Please note that these two HTC mobile devices are not based on Windows Mobile but on Android.

(UPDATE) HTC has publicly released a hotfix [2] that forces HTC Peep not to use HTTP Basic authentication but OAuth during the whole Twitter session, and that performs the authentication process over HTTPS (versus HTTP) against the "api.twitter.com" service on port TCP/443, not disclosing the user credentials for the Twitter service. However, after completing the OAuth authentication process over HTTPS, HTC Peep switches to HTTP for the remaining of the Twitter session, making the unencrypted session vulnerable to HTTP session hijacking attacks based on eavesdropping Twitter's session id (e.g. cookies).

We think HTC should release a software update to change the vulnerable behavior in the HTC Peep mobile application, solving both credentials disclosure issues: the usage of HTTP Basic authentication versus pure OAuth capabilities, and the usage of HTTP versus HTTPS during the authentication process (and preferably, for the whole HTTP(S) session).

HTC has just confirmed (February 3, 2011 - 6pm CET) that an update is available, although it has not been released publicly. It will be delivered under request to any interested customer. If you are interested on the fix, you must contact HTC directly.

Due to the absence of a public software update at this time (5 months since the initial notification), we strongly recommend users not to use HTC Peep to connect to Twitter. Users must evaluate the usage of HTC Peep as their preferred mobile Twitter client, and use other Twitter clients available for their HTC mobile device instead. There are multiple third-party Twitter clients for Windows Mobile (available through a simple Google search: "windows mobile twitter app (or client)") such as: ceTwit, GPS Twit, Jitter, Locify with Twitter, Pocket Tweet, PocketTwit, Quakk, SQIJ, TinyTwitter, Twibble, Twikini, TwitToday, Twitter2Go, Twitter Answers, Twitter deBolsillo, Twitula, Twobile, Viigo, or direct access to the official Twitter Mobile homepage (https://moblie.twitter.com/login) from a mobile web browser.
Disclaimer: These mobile Twitter applications have not been analyzed against these, similar, or other security vulnerabilities.

Users must avoid reusing their Twitter credentials in other services and applications (a common security best practice), as their Twitter username and password can be easily retrieved by an attacker.

Vulnerable platforms:
HTC mobile devices running HTC Peep (HTC Peep is the default HTC Twitter client). HTC has confirmed HTC Peep is vulnerable at least in the following HTC mobile platforms: HD2, T-Mobile HD2, Topaz, Rhodium, and HD Mini.

(UPDATE2) A new hotfix is available for HTC Tattoo & HTC Hero [3].

(UPDATE) The final hotfix is available for HTC Touch Pro2/HTC HD2/HTC Touch Diamond2/HTC HD mini [2].

Other mobile platforms running HTC Peep, based on Windows Mobile or other mobile operating system, such as Android (if available), could be affected too.

The vulnerability was discovered on an HTC HD2 mobile device running Windows Mobile 6.5 Professional and the built-in HTC Peep version ("2_5_19212224_0").

Vendor information:
HTC has confirmed the existence of this vulnerability and it is working to release a hotfix to solve the issue. The temporary hotfix provided was named "LEO_S01175" but it still discloses the Twitter credentials by using HTTP instead of HTTPS.

(UPDATE2) On March 11, 2011, HTC released a hotfix for the HTC Peep Client in the form of a FOTA update for HTC Tattoo and HTC Hero, both based on Android [3]. The build numbers after installing the updates will be 1.67.405.70 (for Tattoo) and 3.36.405.1 (for Hero): "From the Home Screen go to MENU> Settings> About Phone> Software Information> Software number".

(UPDATE) On February 10, 2011, HTC released a hotfix for this HTC Peep credentials disclosure security vulnerability for HTC Touch Pro2/HTC HD2/HTC Touch Diamond2/HTC HD mini [2]. The hotfix filename for the various HTC models varies: LEO_S01236.exe (HD2), PHO03880.exe (HD mini), RHO_S2_00923.exe (Touch Pro2), and TOP_S2_00478.exe (Touch Diamond2).

We at Taddong honestly believe this finding must be publicly known by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have tried to coordinate the release of this security advisory together with the vendor, following responsible disclosure principles. This vulnerability is especially relevant considering the extensive number of HTC mobile devices available in the market and the potential impact of the associated attacks.

Vulnerability report timeline:
2010-08-21: Taddong tries to report the vulnerability to HTC through the standard channels (web, e-mail...) without success.
2010-08-23: Taddong contacts other security researchers (Thanks Alberto!) previously involved in reporting vulnerabilities to HTC in order to identify a valid contact or notification channel to let HTC know about the issue.
2010-08-25: Taddong spends around a week trying to identify a secure channel to report the issue to HTC, without any success. Please, read "The Seven Deadly Sins of Security Vulnerability Reporting"!! [1]
2010-09-03: Taddong finally decides to notify HTC about the vulnerability through the only available (but insecure) web channel and sends a brief technical report.
2010-09-04: HTC confirms they "...will investigate (the issue) and get back to us as soon as they get a reply."
2010-09-19: Taddong contacts HTC again (after 15 days) emphasizing this is a serious issue that requires immediate action, as Twitter credentials are directly exposed. Taddong tried to get an estimated date when an update would be available in order to proceed to publicly and responsibly disclose the vulnerability.
2010-09-20: HTC replies and they "...apologize for the inconvenience and the delay. The case is being investigated and they will get back to us as soon as they get a reply."
2010-10-03: Taddong contacts HTC again (one month since the initial notification) in order to gather specific details, such as an official confirmation of the vulnerability and an estimated fix release date, trying to coordinate the publication of the associated advisory.
2010-10-10: No response was received from HTC. Taddong tries to contact HTC again (+1 week).
2010-10-22: HTC replies apologizing (again) for the delay and... asking for "all the details for further investigation"? Taddong replies and clarifies it is still waiting for a confirmation or any chance to discuss the technical details. At the same time, an estimated deadline is set by Taddong for the public release on November 4, 2010 (two months since the original notification).
2010-10-26: HTC clarifies the reason for its previous request (for further details), as it is still starting to "...check if there is in fact a vulnerability and try to reproduce it". Taddong replies back clarifying the details were provided on September 3, 2010, and offering again another brief technical description.
2010-11-06: Taddong contacts HTC again asking for the latest details or updates regarding the issue. The goal was to offer HTC an opportunity to step in prior to the public release, even delaying the previously set deadline (of Nov, 4), trying to be extremely responsible.
2010-11-08: HTC replies back informing Taddong that currently they are still analyzing it and will issue a notification on their website once they have reached a conclusion.
2010-11-21: Taddong informs HTC that plans to release the vulnerability to the public on Monday, December 6, 2010, and encourage them to contact us during the remaining two week period, as the best option would be having a fix/update ready in order to offer a solution to end users.
2010-11-22: HTC informs Taddong that the engineering department is investigating and finding a solution for this issue.
2010-12-01: Taddong asks HTC about the availability of (or future plans to get) a CVE ID for this issue prior to the final public disclosure, trying to coordinate both parties.
2010-12-02: HTC confirms the engineering department has been notified about the CVE proposal and will get back with a response (three months since the original notification).
2010-12-11: Due to the lack of a response, Taddong finally requests one (or two; this is left up to MITRE) CVE ID(s) to MITRE. The CVE ID request process is the reason for a new delay in the second proposed deadline for the public disclosure (Dec, 6).
2010-12-15: Taddong tries to confirm if the CVE ID request has been received by MITRE without success. Taddong never got a response from MITRE about the CVE ID request.
2010-12-16: HTC provides a hotfix for testing to Taddong (named "LEO_S01175").
2010-12-17: Taddong replies back confirming that the hotfix solves the Basic authentication issue, as OAuth is the only authentication method used after applying the hotfix. However, still HTC Peep discloses the user credentials in the initial OAuth exchange through HTTP. Taddong suggests to use HTTPS for the whole Twitter session as the right solution (that would also solve other session-based attacks) and asks for the details of a future release.
2010-12-20: HTC confirms the suggested solutions have been notified to the engineering department, and that the fix is available for several models. Taddong requests details of the affected models.
2010-12-21: HTC confirms that the affected models include: HD2, T-Mobile HD2, Topaz, Rhodium, and HD Mini. There is no information yet about the web page where the update will be available.
2011-01-17: Taddong tries to gather details about the web page where the update will be available, as well as information about the pending issue, the credentials being disclosed through HTTP (vs. HTTPS). It is four and a half months since the original notification.
2011-01-18: HTC replies notifying they "haven’t received any further information yet (from engineering), and that they will resend our feedback regarding the update again and check with them if they will release any further upgrades soon".
2011-01-24: Taddong sets the final vulnerability advisory release for February 4, 2011 (in +10 days and five months since the initial notification), and notifies HTC accordingly, asking for HTTPS support over the hotfix functionality, and trying to retrieve the specific webpage where the update will be available to include it in the advisory. HTC confirmed the reception of this notification. Taddong sent an e-mail to MITRE trying, once again, to get one (or two) CVE IDs for these vulnerabilities.
2011-02-03: One day before publishing the advisory, Taddong contacts HTC and tries to gather details about the web page from where users could download a fix for this vulnerability, trying to include an official solution in the advisory. HTC replies back informing "...that for the time being the update hasn’t yet been released on the website however, any customer who wishes to download it can contact us and we will send it out to them".
2011-02-04: Taddong publishes security advisory TAD-2011-001.
2011-02-04: (11:30pm CET) Bugtraq ID assigned: 46153.
2011-02-10: (UPDATE) HTC releases on its support website the fix for the HTC Peep credentials disclosure security vulnerability. The fix for the following models, HTC Touch Pro2/HTC HD2/HTC Touch Diamond2/HTC HD mini, is available at http://www.htc.com/europe/SupportViewNews.aspx?dl_id=1085&news_id=866 [2].
2011-02-14: (UPDATE) Taddong validates the fix on a HTC HD2 device and updates this advisory accordingly.
2011-03-11: (UPDATE2) HTC released a new update for HTC Tattoo and HTC Hero, both based on Android (and not Windows Mobile).
2011-03-17: (UPDATE2) Taddong updates this advisory with the new Android-based hotfixes.

References:
[1] "The Seven Deadly Sins of Security Vulnerability Reporting". Raul Siles. Taddong. August 15, 2010.
http://blog.taddong.com/2010/08/seven-deadly-sins-of-security.html
[2] "Update for HTC Touch Pro2/HTC HD2/HTC Touch Diamond2/HTC HD mini Peep Security update". HTC. February 10, 20111.
http://www.htc.com/europe/SupportViewNews.aspx?dl_id=1085&news_id=866
[3] "HTC Support (Europe)". HTC. March 11, 2011.
http://www.htc.com/europe/support.aspx

About Taddong:
Taddong (www.taddong.com) is a company established in Spain in 2010 with the purpose of improving customer's information security, by discovering and eliminating or mitigating the real risks that threaten their networking and information technology infrastructures. To achieve this goal, Taddong's portfolio includes specialized information security services, requiring an in-depth technical knowledge and broad understanding of the information technology market, as well as training services, focused on providing customers with auto-defense skills. Taddong remains at the forefront of the security market through continuous research and education activities.

Disclaimer:
The contents of this security advisory are copyright (c) 2011 Taddong S.L., and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

Wireshark SMB capture feature for Windows

2011-01-24T09:30:00.020+01:00

Since we published our "SMB export object" feature for wireshark a few people has asked for a windows version.

When a functionality is included in the wireshark development trunk, but is not yet included in an stable version, the only way to use it is to obtain the source code (by using "svn co http://anonsvn.wireshark.org/wireshark/trunk/ wireshark") and compile it. Although windows compilation has no technical secret since it is very well explained in Wireshark's development guide, it is a little bit of a burden because you have to install some tools (Microsoft C Compiler and SDK, cygwin, python, SVN client, etc.) before being able to compile it.

For that reason, we've decided to build a Windows version of wireshark that includes our feature, and publish it in our Lab page. The file is a windows installer executable packaged with NSIS. It has been tested in a Windows XP system and a Windows 7 system.

Before install and use it, please be aware that this is a wireshark development version and, by definition, it is subject to errors (our functionality is not an exception). We are still working on some enhancements. Therefore, although running wireshark as a non-privileged user is always a good practice, in this case is even more recommended.

We will announce future improvements of the functionality via twitter and/or on this blog.

(UPDATE) This functionality is included in the oficial version of Wireshark for Windows 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. Until Wireshark publishes release 1.5.2, you can obtain a windows installer from our lab.

Browser Exploitation for Fun & Profit Reloaded

2010-12-08T18:12:00.000+01:00

This week during the SANS London 2010 conference I presented the second part of the web browser exploitation series, "Browser Exploitation for Fun and Profit Reloaded". This presentation is a follow up of the previous "Browser Exploitation for Fun and Profit" one from last month, and builds on top of the penetration testing setup previously described based on Samurai WTF v0.9, plus BeEF v0.4.0.3, and Metasploit v3.5.x.

This second part provides penetration testers with new tools, ideas, and techniques to demonstrate the impact of XSS vulnerabilities on the client side (but not only), with a specific focus on the top vulnerable (client-side) applications during the first three quarters of 2010: web browsers and their associated plug-ins.

The core of the session covers Java and Adobe Reader exploitation, including the availability of related exploits in multiple criminal sploit packs, and several demonstrations of different complexity levels for these two vulnerable plug-ins. In some scenarios, extra steps on the pen-tester side are required. On the one hand, the MSF Java exploit for CVE-2010-0886 requires a few tweaks to avoid binding conflicts on the web-based ports between Apache (used by Samurai & BeEF) and Metasploit; see the details on part one of the series. On the other hand, the proposed pen-testing setup provides capabilities to turn file format exploits, such as the MSF CVE-2010-0188 exploit, into web application exploits. To be more realistic and succeed in real-world environments, this attack makes use of (a slightly modified version of) the MSF meterpreter reverse_https module, which requires again a few tweaks to avoid port binding conflicts between Apache & BeEF and MSF. Both modifications have been made available through the "misc" directory of the SVN repository for the Samurai WTF project.

The presentation additionally introduces how to update Samurai v0.9 to the latest BeEF Ruby-based version, v0.4.2-alpha, as this is where the main XSS browser exploitation framework project is leading the industry to. Although the project is still in alpha state, the new features are very promising, and definitely opens the door for future presentations in this series ("To be continued...").

The third and final section of the presentation introduces web browsing best practices, pros and cons, extra countermeasures, and new industry movements into plug-in checking services and sandbox client applications.

Thanks to all the people that showed up and the interesting debate afterward. Enjoy the PDF file of the presentation (no, it is not malicious... ;-) and try to put all this info in practice within your pen-tests... of course... with authorization!

Browser Exploitation for Fun & Profit

2010-11-03T15:31:00.000+01:00

This past Tuesday I run a SANS special webcast titled "Browser Exploitation for Fun and Profit" complementing the "Security 542: Web App Penetration Testing and Ethical Hacking" training I will run in SANS London 2010 at the end of November, early December:

"Cross-Site Scripting (XSS) is still one of the most prevalent vulnerability on web applications, and its exploitation is a very relevant threat to be considered by any organization. As the owner of the web application, you don't want your visitors and customers to get exploited through your website, and as the owner of any company, you don't want your users, browsing the web innocently, to become victims of large scale or targeted attacks. Browser exploitation frameworks, such as BeEF, provide attackers and pen-testers advanced capabilities to perform in-depth devastating attacks into an organization, using the ubiquitous web browser as the entry point."

The main goal was to introduce the state of the art of client vulnerabilities on the web browser and its associated plug-ins, and focus on the prevalence and impact of (the sometimes undervalued) XSS vulnerabilities. In order to change the general perception and help others to identify the real impact of XSS, pen-testers can make use of the attack platform suggested on the presentation: Samurai WTF v0.9, plus BeEF v0.4.0.3, and Metasploit v3.5.x. The integration of BeEF and Metasploit provides the capabilities required for advanced attacks. The presentation guides pen-testers through the process of updating, configuring, and launching these tools, greatly simplified by using Samurai WTF as your favourite web-app pen-testing platform :)

From the most commonly used web browser plug-ins (Adobe Reader, Flash Player, Java, Quick Time, Windows Media Player, RealPlayer…), I had to select one as my target, and Java was the (chosen) one as all webcast attendees had it installed; it is a pre-requisite for the Ellumitate Live! webcasting platform used by SANS. Despite the technical difficulties during the webcast (it seems an XSS attack affected the slides and the application sharing capabilities of the webcast ;-p ), I could run a demo of a Java-based vulnerability (CVE-2010-0094) to show how smoothly the integration of these two tools work. Time constraints didn't allow me to run the second, and more advanced demo, exploiting a different Java-based vulnerability (CVE-2010-0886), but you have all the details on the presentation. This presentation is an extended version of the original one with extra detailed steps and references.

Unfortunately, we almost didn't have time for questions and answers, so feel free to send me an e-mail.

This is the first of a series of XSS and browser exploitation presentations I will be running in the next few months. The next one will take place during the SANS London 2010 conference: Thursday, 2 December, from 19:30 - 20:45. This second part, titled "Browser Exploitation for Fun and Profit Reloaded", will take the already covered setup for granted, and will describe and demo live more XSS attacks, tools, and techniques, including (if it is mature enough) the new Ruby-based BeEF, v0.4.1.x. Hope to see you there!

GPRS/EDGE Security

2010-09-20T19:08:00.064+02:00

You should already know by now that GSM voice calls and SMS messages are not secure. Any third party can easily set up a rogue base station and listen to your calls, read your SMS messages, and reroute, drop, or alter any of them.

Yes, GSM security is that broken.

What you may not have realized yet, is that your GPRS/EDGE connections are just as insecure.

Take a look at the following two pictures and try and answer this question: is the smartphone shown on those images connected, via GPRS and via EDGE, respectively, to the network operator "movistar"?

Figure 1. iPhone 3G connected via GPRS and EDGE, respectively

Note for those of you unfamiliar with the iPhone: the smartphone in the pictures is an iPhone 3G, which, on the top left corner of the screen, it usually displays the name of the network operator it is connected to, and then, next to it, a symbol representing the type of data connection it has established: a circle, if it is connected using GPRS, or a letter "E", if it is connected using EDGE (or "3G" if it is connected using UMTS).

The right answer, sadly enough, is this:"Maybe it is, but then again, maybe it is not". That's the thing: you simply cannot tell!

In fact, the pictures were taken while the smartphone was connected to a rogue base station (BTS) that we set up in Taddong's lab, pretending to belong to the network operator Movistar. The BTS, in turn, was connected to a PC that emulated a whole network operator (BSC, SGSN, GGSN, etc.) and had Internet access via ADSL. The PC would route any traffic between the smartphone and the Internet. The following diagram depicts the lab setup:

Figure 2. Diagram showing the lab setup

Note: In this case, the Internet connection of the PC was established via ADSL, but we could have used any other access technology like cable, UMTS or even GPRS/EDGE.

So, for example, when the user navigated to our web page (http://www.taddong.com/) using the web browser of the smartphone...

Figure 3. Smartphone browsing www.taddong.com

... we could see those packets going through our PC, with as little effort as simply invoking good old Wireshark:

Figure 4. Wireshark's capture of the HTTP request from the smartphone to www.taddong.com

The above example, in which a user simply navigates to a static web page and the attacker sniffs the connection is a really simple one, granted, but it does illustrate the point: the attacker is sitting between the user's smartphone and the Internet, with full control over any packet flowing between them. Now, think of the possibilities for mischief: the attacker could read any e-mail sent or received in cleartext, she could read any usernames and passwords sent in cleartext by the user to remote servers, she could redirect any outgoing HTTP request to a malicious web server that would then send malicious content back to the browser, etc.

Just think about it the next time your smartphone tells you that it is using a GPRS/EDGE connection. Or, if you feel that your data is not interesting enough for an attacker, think about what might be going on the next time the smartphone of your CEO or any other VIP in your organization reports that it is using GPRS/EDGE. Would those connections be interesting to an attacker? Oh, yes!

So, what can you do to protect your GPRS/EDGE communications? We'll give you a short answer and a long answer.

The short answer: Do not use GPRS or EDGE; instead, use only UMTS ("3G", "3.5G", HSPA). Alternatively, make sure you use end-to-end authentication and encryption for all aplications that you access wirelessly. Or, even better, do both.

The long answer is actually a shameless plug ;-):

<plug>

Come to our GSM/UMTS Security training course and you will see for yourself! In the course, we cover everything you need to know about GSM and UMTS security, including voice calls, SMS messaging, and data connections (GPRS/EDGE/UMTS/HSPA). All packed in a very short, very intense training experience, with lots of interactive demonstrations, that will make you fully understand all the vulnerabilities and risks involved and all the countermeasures available.

In November 2010 we will be teaching it for the first time, in Valencia, in Spanish, but if you don't speak Spanish or can't make it this time, don't worry: we'll be running English editions soon enough. Follow our blog, tweets and/or web page, and you won't miss it when we announce them.

</plug>

Finally, if you fear that this GPRS/EDGE problem might apply to more than just smartphones, your instincts are serving you well: it definetely does. We will talk about that on a future post.

In the meantime, "be afraid, be very afraid..." of GPRS/EDGE connections!

Jose Pico & David Perez

More WPA2 Hole 196 Reflections and TCP/IP Stack (Mis)Behaviors

2010-09-14T11:14:00.002+02:00

This year I had the opportunity to gather the details of the latest vulnerability in Wi-Fi technologies before it's announcement during the BlackHat and DefCon conferences, dubbed "(WPA2) Hole 196", however at that point, I didn't have the time to analyze it and publish the details. I always like to perform an in-depth analysis and share my comments on the current Wi-Fi security threats, as I did during the last years in our original RaDaJo blog with the PTW WEP cracking attack (104 & 40-bit), WEP cloaking, autoimmunity disorder in WLANs or the WPA/TKIP ChopChop attack. (WPA2) Hole 196 couldn't be left apart!

My last WPA/TKIP ChopChop attack analysis emphasized the temporary nature of TKIP, recommending WPA2/AES as the reference security technology for Wi-Fi networks. However, the first well-known vulnerability for WPA2-Enterprise has been released. During BlackHat and Defcon 2010, MD Sohail Ahmad senior wireless security researcher from AirTight Networks, presented "WPA Too!", demonstrating an inherent flaw in the design of WPA(2). Apart from the original presentation, whitepaper, blog post, webinar and FAQ, there is a great analysis by Glenn Fleishman available here.

So, let's start this quick analysis emphasizing a security principle the infosec industry does not fully assimilate yet: "If something is shared, it cannot be secret" ;) Hole 196 exploits this principle attacking the GTK, the Group Temporal Key shared by all Wi-Fi clients to exchange broadcast and multicast traffic. This principle is also what makes WPA(2)-PSK solutions vulnerable, as the Pre-Shared Key is known by all Wi-Fi clients, so any legitimate user can easily decrypt the Wi-Fi traffic from other users.

Why "Hole 196"? Because it exploits a security weakness in the GTK pointed out on page 196 of the current IEEE 802.11-2007 specification. As this is a design flaw, fixing Hole 196 will require an update to the current IEEE 802.11 spec.:

To sum up, I agree with my friend Josh Wright that this new vulnerability won't make people to switch off their Wi-Fi networks (as WEP flaws did a few years back). What makes this finding more interesting is that it affects the most secure Wi-Fi environments nowadays, those based on WPA2/AES-Enterprise (802.1X). To put things in context, there are still thousands, or even millions, of Wi-Fi deployments that are based on WEP or WPA(2)-PSK vulnerable to much more relevant flaws than this one.

(My personal) Hole 196 reflections:

All WPA and WPA2 environments, independently of the encryption technology used (TKIP or AES) or the authentication method (Personal, PSK or Enterprise, 802.1X) are vulnerable. Hole 196 is particularly relevant on WPA2/AES-Enterprise.
Hole 196 is an insider attack, meaning the attacker needs to be a legitimate Wi-Fi user to get access to the GTK. It therefore affects security conscious organizations concerned about the insider threat (unfortunately, still today not everybody is concerned) or the few Wi-Fi hotspots based on WPA(2)-Enterprise (where other legitimate users are not trusted users implicitly).
It allows stealthier ARP poisoning (MitM) attacks, as the malicious ARP frames won't be seen on the wired network segments and, therefore, on a wired IDS/IPS. This could be a good reason for security conscious organizations, already using WPA2-Enterprise, to deploy a wireless IDS (WIDS).
An attacker can use ARP poisoning techniques to get access to (decrypt) other users Wi-Fi traffic, as in a default WPA(2)-PSK setup or wired LAN, manipulate that traffic, or launch DoS attacks. Less-stealthier ARP poisoning attacks are possible on any Wi-Fi network (not just through Hole 196), and quite honestly, still today lots of organizations are unable to detect ARP poisoning attacks on their networks (LAN or WLAN) or even enforce secure wired or wireless network access through 802.1X authentication.
A new kind of DoS is possible through Hole 196 by increasing the value of the packet number (PN) field, used by WPA2 to detect replay attacks. This attack joins the long list of Wi-Fi DoS attacks still possible today.
In essence, Hole196 allows the injection of fake broadcast or multicast frames in the Wi-Fi network that all users will accept as legitimate. Therefore, an attacker can launch any kind of attack that implies the usage of broadcast or multicast traffic at layer 2, being ARP poisoning the best example. This is what the FAQ refers to as "Other attacks such as port scanning, exploiting OS and application vulnerabilities, malware injection, DNS manipulation, denial of service, etc. are possible by misusing GTK."

In the absence of a WIDS, client-based detection capabilities are specially relevant to detect ARP spoofing attacks launched through Hole 196. This opens the door for a future blog post focused on analyzing nowadays ARP poisoning detection solutions on the client side (and in case you ask, Snort is not a client side solution for me), such as arpwatch by LBNL (already analyzed in 2003 on my "Real Worl ARP Spoofing" GCIH paper), DecaffeintID by IronGeek (Windows) or XArp by Christoph P. Mayer (Windows and Linux). What are the solutions available for other Wi-Fi clients, such as mobile devices?

Hole 196 has favored new research focused on how the current TCP/IP stacks behave and respond to layer 3 (IP) unicast packets encapsulated in layer 2 (802.11 or Ethernet) broadcast or multicast frames. Josh opened Pandora's box on his Packetstan blog post. Although still it is not clear how this misbehavior can be fully exploited on any network, apart from bypassing layer-2 filters, it is particularly relevant for one-way attacks on Wi-Fi PSPF (Publicly Secure Packet Forwarding, aka "client isolation") environments through Hole 196.

Following Josh research, I did a few extra tests with OS & platforms, and (in particular) mobile devices common in Wi-Fi networks, and confirmed the following facts:

Josh mentioned Windows Vista and 7 accept LAN broadcast traffic sent to unicast IP addresses. I confirmed that Windows Vista SP2 under VMware Fusion 3.1.1 (LAN) in fact does accept this kind of traffic for ICMP, TCP or UDP for broadcast and multicast layer-2 addresses. The most surprising fact is that Windows Vista and 7 accept TCP broadcast traffic. New TCP/IP stack implementations can always include hidden gifts!
Windows XP SP3 (WLAN) does not accept it for any of the protocols (ICMP, TCP or UDP), no matter the layer-2 address used, broadcast or multicast. So, does this mean XP is "more secure regarding Hole 196" than Vista & 7? ;)
Linux 2.6 (2.6.30.9), for the records running inside VMware 6.5.4 (LAN), accepts both broadcast and multicast traffic for ICMP and UDP. It rejects it for TCP. From a layer 2 vs. protocol perspective it makes sense, as ICMP and UDP protocols can make use of broadcast and multicast communications, while TCP cannot. However, the key question about this misbehavior is: should the layer 3 address be verified against the layer 2 address by the OS TCP/IP stack before processing a frame/packet?
iPhone 3.1.3 and 4.0.2 (WLAN) accept both broadcast and multicast traffic for ICMP and UDP, but rejects both layer-2 addressing types for TCP, like Linux 2.6.
Mac OS X 10.6.4 (WLAN) again behaves similarly to Linux 2.6, only accepting both broadcast and multicast traffic for ICMP and UDP.
Windows Mobile 6.1 and 6.5 behave as Windows XP, not accepting this kind of traffic for any of the protocols (ICMP, TCP or UDP) no matter the layer-2 address used, broadcast or multicast.

If you are interested on testing this kind of misbehaviors, you can use Josh's suggested packet crafting technique based on Python and Scapy (for ICMP, TCP & UDP) on various platforms, including the standard Backtrack 4 Final VM I used for these tests (with Scapy v2.1.0), or a simpler multi-platform method (Windows, Linux & Mac) based on creating a static entry on the local ARP table using a broadcast or multicast layer-2 address, and generating traffic against the associated layer-3 address through ping (ICMP) or netcat (TCP & UDP).

Example of an ICMP echo request packet addressed ("dst=") to a multicast layer-2 address and unicast layer-3 address in Scapy:

>>> p = Ether(dst="01:00:5e:00:00:01", src="00:0c:29:01:02:03", type=0x800) 
>>> p /= IP(src="192.168.100.2",dst="192.168.100.1") 
>>> p/= ICMP() 
>>> srp1(p)
Begin emission:
Finished to send 1 packets.
*
Received 1 packets, got 1 answers, remaining 0 packets
<Ether  dst=00:0c:29:01:02:03 src=00:0a:0b:0c:0d:0e type=0x800 |
<IP  version=4L ihl=5L tos=0x0 len=28 id=741 flags= frag=0L ttl=128 
proto=icmp chksum=0x2877 src=192.168.100.1 dst=192.168.100.2 options=[] |
<ICMP  type=echo-reply code=0 chksum=0xffff id=0x0 seq=0x0 |<Padding 
load='\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' |>>>>

For TCP & UDP packets replace the "ICMP()" line above with the appropriate line:

>>> p /= TCP(sport=65000, dport=196)    

>>> p /= UDP(sport=65000, dport=196)

Example of Linux/Mac & Windows ARP static entry to associate a multicast layer-2 address to a unicast layer-3 address. All local traffic sent to the unicast layer-3 address will use the multicast layer-2 address. Don't forget to delete the new ARP entry (-d) when the tests are finished :)

# Linux/Mac 

$ sudo arp -s 192.168.100.1 01:00:5e:00:00:01

$ arp -an

? (192.168.100.1) at 01:00:5e:00:00:01 [ether] PERM on eth0      

$ sudo arp -d 192.168.100.1

# Windows 

C:\>arp -s 192.168.100.1 01-00-5e-00-00-01

C:\>arp -a

Interface: 192.168.100.2 --- 0x4

  Internet Address      Physical Address      Type

  192.168.100.1         01-00-5e-00-00-01     static

For general operating systems, before testing, double check that the target TCP/IP stack, and associated personal firewall, allows the ICMP, TCP & UDP traffic used for the analysis (for example, using layer-2 & layer-3 unicast packets) and don't forget to launch the TCP & UDP listeners:

# TCP listener (you might need to manually close it after the incomplete 

# SYN/SYN-ACK exchange when using the Scapy packet crafting technique): 

$ echo "hole 196" | sudo nc -l -p 196

# UDP listener:

$ echo "hole 196" | sudo nc -u -l -p 196 

NOTE: It would be more secure not to use 196 as the target port (Hint: root level required if port <=1023).

For mobile or embedded devices, where netcat cannot be used, you need to identify first an open TCP & UDP port that replies to standard unicast traffic. Remember that for UDP you also need to send a properly formatted packet to the target service in order to force a valid reply (Hint: ARP static entry & "nmap -n -Pn -sU -sV -p5353,137 192.168.100.1").

Definitely, more research is needed if a relevant exploitation vector for this misbehavior is found, including the analysis of both broadcast and multicast packets, covering all interfaces (WLAN and LAN) just in case the TCP/IP stacks behave differently, and considering all kind of Wi-Fi clients such as mobile devices, printers, multimedia disks, etc. Anything with a TCP/IP stack should be part of this extended research. BTW, for the layer 2 multicast address I used 01:00:5e:00:00:01, that corresponds to 224.0.0.1 (all systems on this subnet, IANA). If you test other platforms or have exploitation ideas, please share them in the comments section below, or send me an e-mail.

I will cover Hole 196 as part of an in-depth technical look at the current state of Wi-Fi (802.11) security and the still today prevalent and cutting-edge Wi-Fi vulnerabilities and countermeasures, on my "Wi-Fi (In)Security: All Your Air Are Belong To..." talk during the GOVCERT.NL Symposium on November 16, 2010, in The Netherlands.

NOTE: The image above belongs to the Great Blue Hole of Belize, in the Lighthouse Reef atoll, a legendary 125 meters deep underwater sinkhole.
Another awesome Taddong-related place!

Vulnerability in the indiscreet Wi-Fi interface of Windows Mobile 6.5

2010-09-01T01:09:00.003+02:00

Title: Full 802.11 Preferred Network List (PNL) disclosure in Windows Mobile 6.5
Vulnerability ID: TAD-2010-003
Credits: This vulnerability was discovered by Raul Siles, Founder and Senior Security Analyst with Taddong (www.taddong.com)
Publication date: September 1, 2010
Last update: September 1, 2010 (7:45am CET) - Vendor statement updated
Vendors contacted: Microsoft

Vulnerability description:
Windows Mobile manages Wi-Fi (or 802.11) wireless communications through the Wireless Zero Configuration (WZC) client or service, similarly to the equivalent Windows-based desktop operating systems. Windows Mobile, as most Wi-Fi clients, keeps a list of the wireless networks manually configured, plus the networks it has connected to in the past, on the Preferred Network List (PNL).

Every time the Wi-Fi interface is turned on, and periodically once it has been activated (for example, to roam between access points), the device checks through 802.11 probe requests what networks in its PNL are available in the current location. Based on the responses obtained, it tries to connect to the most preferred network.

In the past, this network discovery process was performed by sending a generic probe request for the broadcast (or any) network plus specific requests for every network in the PNL. This meant devices disclosed the full PNL in the air [1], exposing themselves to karma-like attacks [2], where an attacker can identify the hidden networks (or access points) the mobile device is trying to connect to and impersonate them, forcing the target device to connect to the attacker's network to capture its traffic and launch more advanced attacks.

In order to avoid this vulnerable behavior, Microsoft released the Wireless Client Update (or patch) for Windows XP SP2 in January 2007 (KB917021) [3], changing the previous behaviour of Wireless Auto Configuration: "This update helps prevent a Windows wireless client from advertising the wireless networks in its preferred networks list."

The new update mitigates the vulnerability, as the wireless device or client only generates 802.11 probe requests for the broadcast network, generically asking for the networks available in the area. An exception to this behavior is presented by the existence of Wi-Fi hidden networks in the PNL: due to the fact hidden (or nonbroadcast) networks do not include their SSID (Wi-Fi network name) in the beacon frames, and do not respond to generic queries asking for any network available, the Wi-Fi clients need to specifically ask for these hidden networks, disclosing its name and existence on the device PNL. This makes devices vulnerable again to the aforementioned attacks.

The new functionality in KB917021 for Windows XP added a user configurable option, "Connect even if this network is not broadcasting", to be able to specify a Wi-Fi network as hidden (nonbroadcast) or visible (broadcast):

A similar configuration option is implemented in Windows Mobile. However, Windows Mobile 6.5 is vulnerable to an information disclosure flaw where the mobile device reveals its complete PNL every few seconds (30 or 120 seconds in the tests performed). As a result it presents (again) the old vulnerable behavior where 802.11 probe requests asking for the broadcast network plus all the networks available on the device PNL, hidden and visible, are revealed into the air. The expected non-vulnerable behavior implies the generation of probe requests for the broadcast network plus all the hidden networks in the PNL, but not for the non-hidden networks.

The images above show the generated 802.11 probe requests for the broadcast network, two hidden networks ("wifi" and "Taddong") and two visible networks ("hotspot" and "ejemplo").

The disclosure of the non-hidden or visible networks available on the device Preferred Network List (PNL) makes the "This is a hidden network" configuration option useless (the "Esta es una red oculta" option in the Spanish version of WM 6.5 below), as Windows Mobile 6.5 behaves as if all networks are hidden:

This behavior can be used by a potential attacker to launch karma-like attacks [1].

The vulnerability exists on the default configuration and there is no setup option to mitigate it or make the mobile device not vulnerable.

Security solutions, workarounds and countermeasures:
We think Microsoft should release a software update to change this vulnerable behavior in Windows Mobile 6.5 and make the "This is a hidden network" configuration option effective, as it did with the Windows-based desktop operating systems [3].

Due to the absence of a current or future software update, users must evaluate the contents of their PNL at any time. The only effective countermeasure against this vulnerability is to keep an always empty PNL, that is, the user has to actively remove the networks added to the PNL. This means the user must review the PNL and remove any new entries after finishing using the Wi-Fi capabilities every time she establishes a connection with any Wi-Fi network.

If a single network is left on the PNL, the device will try to discover its presence and connect to it, and a potential attacker will be able to launch the karma-like attacks previously mentioned. This kind of attack is especially critical when the user connects to not secure Wi-Fi networks, such as open hotspots or WEP-based networks, enabling unauthorized connections to the mobile device.

Unfortunately, Windows Mobile 6.5 does not have an equivalent option to the automatic connection switch available on Windows XP: "Connect when this network is in range".

The security recommendation of removing all the hidden networks from the PNL, only allowing connections to not hidden or broadcast Wi-Fi networks, is completely ineffective to mitigate the impact of this vulnerability and the associated karma-like attacks (in fact, it is the main victim of this vulnerability).

Vulnerable platforms:
Windows Mobile 6.5 Professional (5.2.21869 - 21869.5.0.82)

Non-vulnerable platforms:
Windows Mobile 6.1 Professional
Windows Phone 7 (*)
(*) Microsoft states Windows Phone 7 is not affected by this vulnerability, but this fact has not been tested and/or confirmed.

Vendor information:
Microsoft has confirmed the existence of this vulnerability, although an update for the Windows Mobile WZC won't be released:
"We have completed our investigations and can confirm that we saw the behavior reported by you on the Windows Mobile 6.5 phone. However, this issues constitutes a Low severity Information Disclosure issue which does not meet our bar for a security bulletin release."

The following statement is provided per the vendor request, but its inclusion into this security advisory does not mean we fully agree on its contents:
"As discussed previously during our investigation, we can confirm that Windows Mobile 6.5 does broadcasts the PNL. However, because of the low severity impact of the information disclosed combined with the fact that the attack would be untargeted (i.e. the attacker cannot force the mobile device to disclose the PNL), Microsoft would not issue a public security update to address this issue. Instead we would address this via next version of the product or service pack if it applies. As you've pointed out, this same issue was addressed on the desktop Windows platform via service pack described here http://support.microsoft.com/kb/917021. We also confirm that this issue does not exist in Windows Phone 7 when it releases."

We at Taddong honestly believe this finding must be publicly known by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have coordinated the release of this security advisory together with the vendor, following responsible disclosure principles. This vulnerability is especially relevant considering the extensive number of Windows Mobile 6.5 devices available in the market and the potential impact of the associated attacks.

Vulnerability report timeline:
2010-08-05: Taddong notifies the Microsoft security team about the vulnerability and sends a brief technical report.
2010-08-05: The Microsoft security team acknowledges the vulnerability report.
2010-08-20: The Microsoft security team confirms the vulnerability and notifies that an associated security bulletin or software update won't be released.
2010-08-23: Taddong notifies the Microsoft security team about the behaviour in Windows Mobile 6.1 (initial research was focused on Windows Mobile 6.5).
2010-08-23: The Microsoft security team acknowledges the vulnerability update.
2010-09-01: Taddong publishes security advisory TAD-2010-003.

References:
[1] "Trying to shut up your wireless chatty Windows". Raul Siles. 2005.
http://www.raulsiles.com/docs/Chatty_Windows_Wifi_Sep05.html
[2] "KARMA Wireless Client Security Assessment Tools". Dino A. Dai Zovi. 2004.
http://theta44.org/karma/index.html
[3] "Description of the Wireless Client Update for Windows XP with Service Pack 2". Microsoft. January 2007.
http://support.microsoft.com/kb/917021

About Taddong:
Taddong (www.taddong.com) is a company established in Spain in 2010 with the purpose of improving customer's information security, by discovering and eliminating or mitigating the real risks that threaten their networking and information technology infrastructures. To achieve this goal, Taddong's portfolio includes specialized information security services, requiring an in-depth technical knowledge and broad understanding of the information technology market, as well as training services, focused on providing customers with auto-defense skills. Taddong remains at the forefront of the security market through continuous research and education activities.

Disclaimer:
The contents of this security advisory are copyright (c) 2010 Taddong S.L., and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

Vulnerability in the chatty Wi-Fi interface of Windows Mobile 6.5 & 6.1

2010-09-01T00:49:00.003+02:00

Title: 802.11 traffic disclosure during the boot process when the Wi-Fi interface is turned off in Windows Mobile 6.5 and 6.1
Vulnerability ID: TAD-2010-002
Credits: This vulnerability was discovered by Raul Siles, Founder and Senior Security Analyst at Taddong (www.taddong.com)
Publication date: September 1, 2010
Last update: February 16, 2011 - Windows Mobile 6.1 is vulnerable too. See (UPDATE) marks.
Vendors contacted: Microsoft

Vulnerability description:
Windows Mobile manages Wi-Fi (or 802.11) wireless communications through the Wireless Zero Configuration (WZC) client or service, similarly to the equivalent Windows-based desktop operating systems. Windows Mobile keeps the previous Wi-Fi interface state during the boot process, that is, if the Wi-Fi interface was active during the last shutdown, it will remain turned on after the boot process; if the Wi-Fi interface was off during the last shutdown, it will remain turned off after the boot process.

Unlike the mobile data capabilities (2-3.5G), organizations (and individuals) interested on disabling, or not using at all, the Wi-Fi capabilities of Windows Mobile-based devices can simply switch off the Wi-Fi interface and it will remain disabled unless the user turns it on explicitly. This default behavior is particularly useful in untrusted or "dangerous" locations, where the device owner does not want to disclose the mobile device presence while the phone is turned on (but its data wireless capabilities are turned off), presenting a completely silent profile.

However, Windows Mobile 6.5 is vulnerable to an information disclosure flaw where the mobile device generates 802.11 traffic during the boot process even when the Wi-Fi interface is turned off. As a result, it generates Wi-Fi traffic in the form of 802.11 probe requests asking for the broadcast (or any) network, plus requests for all the hidden networks available on its Preferred Network List (PNL).

This is the expected behavior when the Wi-Fi interface is switched on, but the device should not generate any traffic while the interface is disabled. As a result of this vulnerable behavior, the MAC address of the Wi-Fi interface is revealed into the air, together with all the hidden networks available on the device PNL:

The image above shows the 802.11 probe requests generated for the broadcast network, plus two hidden networks ("wifi" and "Taddong").

The disclosure of the MAC address could seem low impact at first sight, as it is revealed every time the Wi-Fi interface is switched on. However, the impact is much bigger in very sensitive environments (defense, finance, healthcare, etc) where the Wi-Fi interface is always turned off, but other wireless technologies might be used, such as Bluetooth.

Bluetooth uses the device address, knows as the BD_ADDR (Bluetooth Device Address), as a secret, as it is required to establish a connection with a non-discoverable (or non-visible) Bluetooth device. Some vendors (even outside the Windows Mobile world, such as Apple with the iPhone 2G & 3G) assign correlative or sequential addresses to the different wireless interfaces of mobile devices, such as Wi-Fi and Bluetooth. As a result of this vulnerability, the knowledge of the Wi-Fi MAC address automatically discloses the BD_ADDR of the mobile device, exposing it to undesired Bluetooth communications and attacks.

The disclosure of the hidden networks available on the device PNL can be used to launch karma-like attacks [1]. The mobile device discloses the hidden networks while trying to find and connect to these networks if they are available. An attacker can identify the hidden networks (or access points) the mobile device is trying to connect to and impersonate them, forcing the target device to connect to the attacker's network to capture its traffic and launch more advanced attacks.

However, these karma-like attacks will only be possible if the Wi-Fi interface is switched on afterwards, so that the attacker can interact with the device wirelessly. The activation of the Wi-Fi interface will disclose the hidden networks (again), therefore, this vulnerability has the same impact as the one associated to configuring hidden Wi-Fi networks on the device.

The vulnerability exists on the default configuration and there is no setup option to mitigate it or make the mobile device not vulnerable.

Security solutions, workarounds and countermeasures:
We think Microsoft should release a software update to change this vulnerable behavior and keep the Wi-Fi interface silent until it is turned on. Due to the absence of a current or future software update, users must evaluate the physical locations where their Windows Mobile-based devices are switched on. A potential attacker located around the target mobile device during the boot process (in the range of several kilometers or miles, depending on the Wi-Fi hardware available) will be able to capture the information previously mentioned.

Additionally, users can reduce the impact of this vulnerability removing all the hidden networks from the PNL, and as a result, only allowing connections to not hidden or broadcast Wi-Fi networks.

Vulnerable platforms:
Windows Mobile 6.5 Professional (5.2.21869 - 21869.5.0.82)
Windows Mobile 6.1 Professional (5.2.21006 - 21006.1.5.74) (*)
(*) Windows Mobile 6.1 presents the same behavior described for Windows Mobile 6.5, ~~although the hidden networks available on the device Preferred Network List (PNL) are not disclosed~~; this slightly reduces the security impact on this version. In the tests performed, WM 6.1 deletes the hidden networks from the PNL after the mobile device reboots, so it can only generate 802.11 probe requests for the broadcast network:

(UPDATE) Additional tests on Windows Mobile 6.1 confirm that this OS version is also vulnerable to this issue, disclosing the hidden networks contained in the PNL during the boot process like Windows Mobile 6.5.

Non-vulnerable platforms:
Windows Phone 7 (**)
(**) Microsoft states Windows Phone 7 is not affected by this vulnerability, but this fact has not been tested and/or confirmed.

Vendor information:
Microsoft has confirmed the existence of this vulnerability, although an update for the Windows Mobile WZC won't be released:
"We have completed our investigations and can confirm that we saw the behavior reported by you on the Windows Mobile 6.5 phone. However, this issues constitutes a Low severity Information Disclosure issue which does not meet our bar for a security bulletin release."

We at Taddong honestly believe this finding must be publicly known by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have coordinated the release of this security advisory together with the vendor, following responsible disclosure principles.

Vulnerability report timeline:
2010-08-05: Taddong notifies the Microsoft security team about the vulnerability and sends a brief technical report.
2010-08-05: The Microsoft security team acknowledges the vulnerability report.
2010-08-20: The Microsoft security team confirms the vulnerability and notifies that an associated security bulletin or software update won't be released.
2010-08-23: Taddong notifies the Microsoft security team about the behaviour in Windows Mobile 6.1 (initial research was focused on Windows Mobile 6.5).
2010-08-23: The Microsoft security team acknowledges the vulnerability update.
2010-09-01: Taddong publishes security advisory TAD-2010-002.
2011-02-16: Additional tests on Windows Mobile 6.1 confirm it is vulnerable to this issue.

References:
[1] "KARMA Wireless Client Security Assessment Tools". Dino A. Dai Zovi. 2004.
http://theta44.org/karma/index.html

About Taddong:
Taddong (www.taddong.com) is a company established in Spain in 2010 with the purpose of improving customer's information security, by discovering and eliminating or mitigating the real risks that threaten their networking and information technology infrastructures. To achieve this goal, Taddong's portfolio includes specialized information security services, requiring an in-depth technical knowledge and broad understanding of the information technology market, as well as training services, focused on providing customers with auto-defense skills. Taddong remains at the forefront of the security market through continuous research and education activities.

Disclaimer:
The contents of this security advisory are copyright (c) 2010 Taddong S.L., and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

The Seven Deadly Sins of Security Vulnerability Reporting

2010-08-15T14:41:00.000+02:00

On a previous post, I opened the door for a new blog post with the goal of providing a few specific recommendations (from a security researcher perspective) for organizations, commercial companies, and open-source projects in order to improve the resources and procedures they put in place to be notified and act on security vulnerabilities on their official web site(s), services, or any of their products.

The Seven Deadly Sins of Security Vulnerability Reporting pretends to become an easy to follow list, not very technical but security relevant (so that we can point people to it), for any organization interested on improving the process of dealing with security vulnerabilities reported by external security researchers (or third parties). It is the result of common issues we found when reporting vulnerabilities and findings during penetration tests, security research, and incident handling:

Communication channels
Confidentiality
Availability
ACK
Verification
Interactivity
"Researchability"

I strongly recommend you to go through the list during this Summer, identify what sins you can redeem in your environment, and implement the changes on September! Let's get ready for the new season!

1. Communication channels
Do you have clear and simple communication channels to be notified about security vulnerabilities in your environment and products?

Provide a clear and simple notification channel (or channels) for researchers to submit security vulnerabilities about your environment and products. Two of the most common methods are e-mail (use an easy to remember e-mail address, like security@yourdomain.com or secure@yourdomain.com - very common nowadays) and an easy to remember web page, such as https://www.yourdomain.com/security/. This page might include a web-based contact form, although I personally prefer e-mail, so it can just contain the details to contact with your security team.

2. Confidentiality
Do you have secure communication channels to receive sensitive and/or confidential notifications?

Implement secure communication channels to receive the security-related notifications by using strong encryption. This way, anyone eavesdropping on the communication won't be able to get all the details about the vulnerability.

For the web-based option, make use of a trusted HTTPS connection for the web page used for the notifications (Did you see the "https://" above?). Do not use HTTP!
For the e-mail option, create and publish the GPG/PGP key associated to the e-mail address used for the notifications. Have the key ready in advance, and make it easily available and verifiable: use your web site plus the public GPG/PGP servers for its publication and distribution.

Always use the secure channel. As obvious as it might sound, for some reason, it is very common for people to end up not encrypting one of the messages at some point during the process of solving the vulnerability and finding the fix, disclosing confidential details as a result.

3. Availability
Are the notifications channels available 24x7, specially, when they are required ;)?

Ensure the web page and e-mail address used for the notifications work as expected and are always available. This is easier said than done. Are you sure someone in the organization is receiving the notifications? Check all the notification methods frequently, or at least, from time to time.

4. ACK (Acknowledgment)
How can the researcher know you have received the notification?

As soon as possible, reply with a quick e-mail message to the researcher confirming you have received the notification, and explain that the notification is going to be reviewed and verified in the next few days. This way the researcher can confirm you got the notification, she knows she can expect a further detailed message and when (try to define what "a few days" means), and you are both in sync.

The initial acknowledgment message (and associated exchange) is a great time for sharing GPG/PGP keys and verifying the secure communication channel works.

If you put in place an automatic response system to confirm the reception of messages on the web or e-mail notification channels, ensure you also provide a second human-based reply, so you demonstrate there is someone behind it, reading and processing the notifications.

Remember, e-mail is not a 100% reliable notification system (SPAM filters apart ;)), so I recommend you to acknowledge relevant messages during the whole process.

5. Verification
How do you know if the notification is related with a new vulnerability (0-day) or is a well known issue?

Take your time to read and understand in detail the contents of the notification and do not make assumptions till you test the issue in your environment. Clarify with the researcher any unclear points or undefined areas till you are able to reproduce it. Verify and, confirm or deny, if it is something you already knew about or a new vulnerability (0-day).

6. Interactivity
Once you confirm it is a new vulnerability, design a plan to fix it, and keep all parties involved informed about how the plan progresses.

This is all about information exchange, isn't it? Improve the information exchange procedures you put in place during the process of testing and fixing the issue. I highly recommend you to periodically notify the security researcher about how the fix progresses and any other relevant actions you take. During the process, you can plan and agree on the deadlines for future actions and the final (responsible) disclosure date.

Apart from using periodic status updates, avoid not responding to e-mails. I you do not have an answer yet, or need time to review the data and provide an answer, once again, send a quick message to the other party and set a reasonable timeframe to keep the information exchange flowing.

7. "Researchability"
All the previous sins provided guidance to the organization that has the responsibility to fix the vulnerability, but... what about the security researcher that found it?

I'm sure there are things we (as security researchers) do wrong, so this last sin is reserved for us :) A few common mistakes not to forget are:
- Follow the responsible disclosure principle (it seems nobody really knows what this means, or has its own definition ;) ).
- GPG/PGP does not encrypt the e-mail subject, so provide enough information in the subject to differentiate it from other notifications (for example by using an identifier), but do not include too much information so that other people could know what is going on.
- Everybody's time is valuable, so before taking the time to report a vulnerability, be sure you have thoroughly tested it and are able to reproduce it (if possible, on the latest product version and, definitely, with the latest patches and updates applied). Try to confirm in advance if it is a well known, previously published, vulnerability or not. You don't want to end up wasting everybody's time (including yours) to confirm it is something that was already fixed a while ago.

Credit
Once a fix for the vulnerability is available and it is finally announced, provide credit where appropriate.

Capturing SMB Files with Wireshark

2010-05-27T15:18:00.017+02:00

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.