OWASP ZAP SmartCard Project

OWASP ZAP (Zed Attack Proxy) has become THE open-source web application interception proxy and security auditing tool, replacing well known open-source players in this field we have been using all over the last decade, such as Paros, WebScarab, or AndiParos. The tool is under active development nowadays, with new features and fixes added every other month, and with more to come, for example, from GSoC 2012. As a result of this tool progression and consolidation, ZAP was recently awarded the Toolsmith of the Year for 2011.

Some time after Paros was discontinued (v3.2.13 back in August 2006), new fork projects derived from Paros' source code were born. Surprisingly, as this behavior is not common in our industry, Psiinon (author of the original ZAP tool) and Axel (author of AndiParos), left their egos apart :-) and took a really smart decision: They joined forces to develop a single and powerful web application security tool, instead of developing two very similar but less powerful tools. The result is what we know today as OWASP ZAP!

However, inexplicably still today Paros is downloaded more than 2,500 times per week from the SourceForge.net project page, while the latest ZAP stable version (1.3.4) has been downloaded only 15,000 times in total during the last 5 months (based on the official open-source platforms statistics). This demonstrates people are used to their routines, and that there is still a lot of work to do to promote and spread the word about the existence of ZAP, its features, and benefits.

ZAP considerably and brightly stays on top of other commercial and open-source web application security tools and web interception proxies when assessing the security of web applications making use of smartcard-based authentication. When a target web application requests client authentication through digital certificates during the SSL/TLS handshake (re)negotiation, ZAP is able to access the local smartcard and authenticate the user as she would do when no interception proxy is in place. ZAP provides support for multiple smartcard types under different operating systems (Windows, Linux, and Mac OS X) thanks to the Java smartcard built-in capabilities and its integration with PKCS#11 hardware modules. The original ZAP smartcard support (from version 1.1.0) was merged by Axel from Andiparos. The current ZAP smartcard support has been greatly simplified through the drivers.xml configuration file. This XML file offers a centralized and extensible architecture to easily add support for new smartcards.

Although other security tools provide support for client digital certificates (x.509 certificates obtained from a file, referred as PKCS#12), we have identified both significant and subtle differences in several target web applications in the way they interact and authenticate the user when using a standard client digital certificate versus a smartcard. Hence, the need to be able to assess how the application behaves when a smartcard is involved.

ZAP smartcard support can be found under the "Tools - Options" menu, within the "Certificate" category, and specifically, on the "PCKS#11" tab:

As a result of my research focused on the security of web applications based on the DNIe, I have been working on and committing code to ZAP to improve the stability and usage of smartcards, using the Spanish national eID (DNIe) as a reference. For example, capabilities to interact with target web applications that still provide support for unsafe SSL/TLS (HTTPS) renegotiation have been added (see my original blog post on this topic from two years ago), as well as minor fixes for several bugs and issues found during the execution of multiple web application penetration tests on DNIe-based environments. One of the key fixes was an improvement to overcome PKCS#11 concurrency access conflicts between ZAP and web browsers (such as Firefox).

Additionally, the Spanish DNIe implements brute-force protection capabilities by blocking the smartcard after three login attempts when the user fails to enter the associated access PIN or passcode. Once the DNIe is locked, the only chance to unlock it requires Spanish citizens to go to the police station and follow a custom unlocking procedure. There (in the police station), you can find proprietary DNIe kiosks that allow citizens to authenticate through their fingerprint, stored within a secure area of the smartcard at issuing time, and proceed to change the DNIe access PIN or passcode. In order to avoid frequent visits to the police station by security auditors and pentesters using their DNIe (or any other eID smartcard) while assessing the security of web applications, and entering by mistake the wrong PIN or passcode in ZAP, the tool now implements specific checks and warning messages to alert the user about failed login attempts, trying to avoid blocking the smartcard after three failed access attempts.

All this DNIe-related functionality has been available on the official ZAP SVN repository since revision 1209, live at RootedCON 2012 (check how to build ZAP from source code), and is currently available on the latest downloadable version, ZAP 1.4.0.1.

To extend this previous research and the implementation already available within ZAP, I have launched a new ZAP-related project focused on improving the support of smartcard-based authentication within ZAP to other eID cards. More information about the "OWASP ZAP SmartCard Project" can be found at ZAP's official wiki.

The purpose of this project is to extend the currently available smartcard support within ZAP to other national eID cards worldwide (apart from the Belgium, Swiss, and Spanish eID's), as well as, to other proprietary smartcard solutions from commercial vendors (apart from ActivIdentity, Aladdin, or Axalto). The goal is for ZAP to provide the widest smartcard support within the web application security industry to be able to assess the security of any web application using smartcards and eIDs for authentication purposes through HTTPS (SSL/TLS). Besides that and based on my previous experience, the complementary goal is to extend ZAP with new features that might be required to deal with and manage the different smartcard types.

The current set of supported smartcards within ZAP can be found at ZAP's official wiki. This wiki page will be updated as soon as we add support for new smartcards within ZAP, although you can always directly check the "drivers.xml" file from the latest SVN revision. The draft list of countries that already provide eIDs (electronic-based identification for their citizens) I am aware of is available on the same page (we hope to add support for all or most of them over the following months with the help of the web application development and security communities).

The new "OWASP ZAP SmartCard Project" requires the implication of the community around the world to provide details and help to test new smartcard types. If you are interested on contributing to it, send me an e-mail or write to the OWASP ZAP Google group (mailing list). You can contribute in very different ways: from providing details about the existence of a new smartcard that is used in your country of origin or residence (or commercial smartcards used) for web-based authentication, as well as using ZAP to evaluate the security of smartcard-based web applications and report bugs or any other issues you may find, up to contributing new drivers.xml entries for new smartcards or additional operating systems.

At the end of September I will be talking about the "Security of National eID (smartcard-based) Web Applications" during the BruCON 2012 security conference in Ghent (Belgium) - first talks pre-release - and running the "Assessing and Exploiting Web Applications with Samurai-WTF" training.

DNIe-based Web Applications Security

Early last month the third edition of Rooted CON took place in Madrid, Rooted CON 2012, with great contents and very interesting topics. During the last day of the conference I presented the results of the research I've been involved in during 2011 and early 2012, focused on the security of web applications based on the Spanish electronic identity card or eID (electronic ID) smartcard, called DNIe ("Documento Nacional de Identidad electrónico", electronic National Identity Card).

The DNIe (or eDNI) is the electronic version of the national ID card for Spanish citizens, and it is currently used to access a great variety of digital services from public and private sectors all over the country, including eGovernment services and web portals plus services from financial institutions, insurance and telecomunication companies, or utility companies (gas, water, electricity...).

Therefore, the DNIe is a key element to authenticate and identify users (Spanish citizens) within private and public critical web applications and services in today's information society in Spain. However, due to the limitations to interact with smartcards and, in particular, the DNIe of the currently available web auditing and pen-testing security tools... ¿are we really sure that the DNIe-based web application and services are secure? The DNIe is (assumed to be) secure, but... ¿is it used in a secure way? ¿Are the web-based client components associated to the DNIe secure? The presentation explored all these questions through new tools, real-world scenarios, and practical demonstrations.

The DNIe is an ISO 7816 smartcard (an evolution from PCKS#15), that contains a pair of X.509 digital certificates plus the associated public and private keys. One certificate is used for authentication/identification purposes (KeyUsage = Digital Signature) while the other is used for signature purposes (KeyUsage = contentCommitment). It is important to emphasize that the latter has legal validity, similar to a traditional manuscript signature, what makes the DNIe a recognized CWA 14169 secure signature-creation device (EAL4+).

So far, the main DNIe (or generally speaking, smartcard) security threats assume the attacker was able to get physical access to the smartcard and the associated PIN/passcode, or was able to compromise the victim's computer where the smartcard is plugged to and used from. A couple of examples are last year's Rooted CON 2011 research on using a DNIe remotely through a proxying computer, “Man-In-Remote: PKCS11 for fun and non-profit” by Gabriel González, or the Sykipot trojan, targeting US DoD smartcards (ActivClient), reported by AlienVault.

Considering Spain is the worldwide leader on digital identity and signature, with more than 25 million DNIe issued as of September 29, 2011 (since this +341 million euros project started in 2005), I feel we should lead too the security implications of web applications making use of the DNIe and similar smartcard solutions. In the same way Spain was significantly ahead on the "Monitoring eAccessibility in Europe: 2011 Annual Report", we must be ahead on the next eSecurity report (if any) too, both on the public and private sectors. It seems there are at least 26 countries worldwide providing smartcard-based (or digital certificate based) identification and signature solutions to their citizens, therefore this research has to be extended to other smartcard types and scenarios (see [0]).

I presented together with the smart and fun José A. Guasch, security researcher and one of the editors of the security-related Spanish blog Security By Default, as a while ago we realized we were researching about different (but related) security aspects of DNIe-based web applications, so our findings fit perfectly for a joint presentation on this topic.

From a technical side, I talked about the authentication and signature capabilities of web applications based on the DNIe, and the three main vulnerable areas: HTTPS (SSL/TLS), user authentication and registration through the DNIe, and session management in web applications. I have published details and tools previously on the first (HTTPS) and last (session management) topics, so the main focus was on the web interaction with the DNIe (and smartcards in general). During the talk I published live the new DNIe capabilities for web application pen-testers through the OWASP ZAP SVN repository (SVN official revision 1209 - drivers.xml file). These new capabilities are available on the ZAP SVN branch as well as the OWASP ZAP 1.4.x version, published yesterday (see [0]).

The presentation covers in depth how to interact with PKCS#11 smartcard devices from Java, and how ZAP smartcard support has been enhanced with DNIe capabilities, stability fixes, and new functionality for the three most common pen-testing platforms: Windows, Linux, and Mac OS X. Additionally, the second portion of my talk presented the results and statistics (plus the associated recommendations) obtained from pen-testing the DNIe capabilities of 15 critical web applications during 2011. The impact of the different vulnerabilities and weaknesses identified on this type of applications is very significant, specially considering the perceived extra security and confidence in the usage of smartcard authentication. If DNIe-based web applications are not securely architected and developed, an attacker can decrypt the victim's web traffic, launch Man-in-the-Middle (MitM) attacks, and manipulate the user registration and authentication processes, plus the user session, to fully impersonate legitimate users in the target web application. Unfortunately, based on the results obtained from these pen-tests there is still a long way to walk to be able to assert that relevant web applications making use of the DNIe are secure.

José talked about the overall security, as well as specific vulnerabilities, that can be found on the client-side components used by web applications (Java applets and ActiveX controls) that interact with the DNIe. These components access the DNIe to (sometimes) provide authentication capabilities and (mainly) verify and generate digital signatures. More information is available on the associated Security By Default blog post(s) (in Spanish).

This research, plus the additions we are currently working on, are going to be contributed over time to the OWASP DNIe project (in Spanish). This open initiative was launched in June 2011 with the goal of evaluating and improving the security of web applications based on the DNIe.

The presentation (in Spanish) can be downloaded from Taddong's lab in PDF format and it is also available on-line (SlideShare) from the Rooted CON papers/talks archive.

[0]: More specific smartcard and DNIe-related ZAP details, as well as extended research I'm working on, will be published on a near future Taddong's blog post.

OWASP Session Management Cheat Sheet (v2.0) & Podcast

On July 2011 the OWASP Session Management CheatSheet was released with the main goal of becoming a useful security reference for web application architects, developers, and security professionals. The document tries to summarize in a concise way all the best practices, recommendations, and countermeasures required to improve the security of today's session management implementations in web applications. The results on our web application penetration tests over the last few years, unfortunately, ratify that session management vulnerabilities are very common and widely prevalent in critical web applications still today.

Jim Manico gave me the opportunity to include this content in the famous OWASP CheatSheet series and talk about this topic. As a result, OWASP Podcast number 90, "Raul Siles", has been released (check the whole OWASP Podcast series). Thanks Jim!

Around October 2011 I slightly updated the official CheatSheet version in the OWASP Wiki, and last week, in sync with the podcast release, I've published a new version (v2.0). This updated downloadable version (in PDF format) includes the updates from October (check the Wiki and document changelog) plus a new feature I plan to expand in future versions of this document: It includes additional session management references to attacks, pen-testing and auditing techniques, tools, and demonstrations complementing the original security countermeasures and defensive recommendations. 

This new version, v2.0, includes the first 10 references/demos, including the OWASP Cookie Database Project, the BIG-­‐IP_cookie_decoder.py and TLSSLed tools, the OddJob session hijacking banking trojan, and more.

I encourage everybody involved in web applications security to review the OWASP Session Management CheatSheet, apply its contents to the currently available web applications and implementations, help spreading the word and contribute to it.

Image src: http://www.gabrielwoo.com/cookie-monster.jpg

Building OWASP ZAP Using Eclipse IDE for Java… Pen-Testers (v2.0)

The OWASP Zed Attack Proxy (ZAP) is the Toolsmith Tool of the Year for 2011. Last Summer, the "Building OWASP ZAP Using Eclipse IDE for Java... Pen-Testers" (version 1.0) was published, and as the beggining of 2012 seems to be the time for second editions of my work ;-) (check the upcoming blog post with v2.0 of the "OWASP Session Management CheatSheet"), a new version of the guide has been released.

This new "Building OWASP ZAP Using Eclipse IDE for Java... Pen-Testers" (version 2.0), available for download from Taddong's Lab, includes significant changes from the first version. It provides an updated development environment not only to get and build the latest ZAP version from the official SVN repository, but to easily commit your changes if you want to contribute to the ZAP project. The proposed environment is more user friendly than in the first version, without requiring any external SVN client. Eclipse and Subclipse provide all the development and SVN capabilities integrated into the same tool. The guide also references the recent OWASP ZAP Extensions project and provides guidance to manage Java (JRE or JDK) updates in Eclipse.

I encourage everyone involved in Web Application Security, from architects to developers, Q&A, auditors, and pen-testers, to take a look at OWASP ZAP, the OWASP ZAP Extensions, and use this new building ZAP guide to enjoy the most current version from SVN and contribute to the project. The official "Building ZAP" Wiki has been updated to link to both versions of this guide.

NOTE: I will be talking about OWASP ZAP and release new smartcard features during my Rooted CON 2012 talk: "Security of Web Applications using the (Spanish) eID" ("Seguridad de aplicaciones web basadas en el DNIe", in Spanish).

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!

Hacking Vulnerable Web Applications Without Going To Jail

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

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)

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”

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”

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