Tuesday, December 6, 2011

Cookie decoder: F5 BIG-IP

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!

Saturday, October 29, 2011

Hacking Vulnerable Web Applications Without Going To Jail

(LAST UPDATE: 2013-10-20)

Shameless plug: I will be teaching the 6-day SANS SEC575 training, "SEC575: Mobile Device Security and Ethical Hacking", in Abu Dhabi, UAE (Apr 26, 2014 - May 1, 2014) and Berlin, Germany (Jun 16-21, 2014).

LAST UPDATE: Since October 18, 2013, this list of vulnerable web applications has been moved to a new OWASP project: "OWASP Vulnerable Web Applications Directory (VWAD) Project".

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).
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.
Online/Live: The following list references online and live vulnerable web applications available on the Internet to play with.
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!

Updates: (Thanks to everybody that sent me new vulnerable web-apps)
2011-10-31: Added VulnApp (.NET) & Sauron (Quemu).
2012-06-17: Added Metasploitable 2, Positive Hack Days (PHDays) I-Bank, and Hacme Bank Prebuilt VM.
2012-07-23: Added GameOver, Virtual Hacking Lab, and Hacking-Lab.
2012-12-19: Added SQLol, SQLI-labs, and WIVET.
2012-12-27: Hack.me (beta).
2013-01-21: bWAPP.
2013-01-31: Drunk Admin Web Hacking Challenge, Hackxor online demo, Kioptrix4, and check The Hacker Games (VM) - some new additions via vulnhub.com.
2013-03-15: DVWS.
2013-09-09: Added PentesterLab and OWASP Bricks (thanks to m0wgli).
2013-10-08: Added Pentester Academy (thanks to m0wgli) and Bee-Box, and updated bWAPP homepage.
2013-10-20: List moved to OWASP VWAD project.

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

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

Wednesday, October 12, 2011

TLSSLed v1.2

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!

Monday, August 29, 2011

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

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:
  1. 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.
  2. 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.
  3. 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”

Friday, August 26, 2011

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

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”

Thursday, August 11, 2011

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

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... :-)

Tuesday, July 26, 2011

OWASP Session Management Cheat Sheet

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.

Saturday, July 16, 2011

Our latest Security Challenge

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)

Sunday, July 10, 2011

TLSSLed v1.1

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!

Friday, May 27, 2011

TLSSLed v1.0

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

Thursday, May 5, 2011

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

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.

Tuesday, May 3, 2011

Selective attack with a rogue GSM/GPRS base station

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”