Browser Exploitation for Fun & Profit Reloaded

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

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

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

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

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

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

Browser Exploitation for Fun & Profit

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

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

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

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

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

GPRS/EDGE Security

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

Yes, GSM security is that broken.

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

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

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

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

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

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

Figure 2. Diagram showing the lab setup

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

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

Figure 3. Smartphone browsing www.taddong.com

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

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

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

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

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

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

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

<plug>

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

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

</plug>

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

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

Jose Pico & David Perez

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

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

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

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

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

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

(My personal) Hole 196 reflections:

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

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

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

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

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

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

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

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

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

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

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

# Linux/Mac $ sudo arp -s 192.168.100.1 01:00:5e:00:00:01 $ arp -an ? (192.168.100.1) at 01:00:5e:00:00:01 [ether] PERM on eth0      $ sudo arp -d 192.168.100.1

# Windows C:\>arp -s 192.168.100.1 01-00-5e-00-00-01 C:\>arp -a Interface: 192.168.100.2 --- 0x4   Internet Address      Physical Address      Type   192.168.100.1         01-00-5e-00-00-01     static

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

# TCP listener (you might need to manually close it after the incomplete  # SYN/SYN-ACK exchange when using the Scapy packet crafting technique): $ echo "hole 196" | sudo nc -l -p 196 # UDP listener: $ echo "hole 196" | sudo nc -u -l -p 196

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Seven Deadly Sins of Security Vulnerability Reporting

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

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

1. Communication channels
2. Confidentiality
3. Availability
4. ACK
5. Verification
6. Interactivity
7. "Researchability"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Capturing SMB Files with Wireshark

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

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

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

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

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

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

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

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

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

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

Session-fixation vulnerability in Joomla! (20100423)

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

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

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

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

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

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

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

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

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

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

Keep your sessions safe!

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

Certificate-based Client Authentication in WebApp PenTests

One of the key attack tools to perform effective Web Application Penetration Tests (WebApp PenTest) are interception proxies, allowing the analyst to inspect and modify all the requests and responses exchanged between the web browser and the target web application. Some of the most popular ones are developed in Java, such as Paros, Webscarab or Burp, being the Java platform a prerequisite to run.

Sun/Oracle has recently released new updates for Java: Java 6 Update 19 on March 2010, fixing 27 security issues, and Java 6 Update 20 on April 2010, including a couple of fixes. If you have updated the Java version of your pentesting system (You did, didn't you?), you must be aware that your interception proxies won't be able to audit web applications that make use of client X.509 certificates for authentication. This specifically affects pentests on e-government and e-banking web applications making use of client certificates, such as those stored on smart cards (like some European national identity cards); in particular for Spain, dozens of websites integrate authentication through the electronic national id card, "DNI electronico" (DNIe).

The reason is that Java 6 Update 19 includes a fix for the famous SSL/TLS renegotiation vulnerability from November 2009 (CVE-2009-3555). The SSL/TLS renegotiation feature is specifically used by certificate-based client authentication, and the fix disables SSL/TLS renegotiation in the Java Secure Sockets Extension (JSSE) by default. As a result, when you try to access a web resource that requires certificate-based client authentication through the interception proxy, it generates the following Java SSL/TLS error message (javax.net.ssl.SSLException): "HelloRequest followed by an unexpected  handshake message".

Webscarab error message:

Burp error message:

However, it is still possible to re-enable the SSL/TLS renegotiation in Java by setting the new system property sun.security.ssl.allowUnsafeRenegotiation to true before the JSSE library is initialized. The following Windows command line launches Burp with SSL/TLS renegotiation enabled:

C:\>java -jar -Xmx512m -Dsun.security.ssl.allowUnsafeRenegotiation=true "C:\Program Files\burpsuite_pro_v1.3\burpsuite_pro_v1.3.jar"

Keep your WebApp PenTests rolling!

Shameless plug: Interested on learning the art of WebApp PenTesting? I will be teaching SANS SEC542, "Web Application Penetration Testing and Ethical Hacking", in London (May 10-15, 2010) in English and in Madrid (September 20-25, 2010) in Spanish.

Manual Verification of SSL/TLS Certificate Trust Chains using Openssl (Part 2/2)

Part 1 of this article covered how to manually verify the SSL/TLS certificate trust chain for a given "invalid" certificate using openssl. We used the Internet Storm Center certificate as an example, whose chain has three elements: the ISC (isc.sans.org) certificate, an intermediate USERTrust CA, and the Entrust root CA.

A quick look in the Firefox Preferences (Mac OS X) or Options (Windows and Linux), and specifically on the "Advanced - Encryption - View Certificates - Authorities" section, confirms the intermediate CA certificate from USERTrust was the one missing on Firefox 3.6.3 and, therefore, the one invalidating the certificate trust chain. None of the available USERTrust certificates has the right fingerprint, "af:a4:40:af...86:16".

The client browser does not have the intermediate certificate to be able to verify the full certificate trust chain, and generates the error.

The most common method to avoid this type of certificate validation errors at the web server level, thus for all the web server clients, is by delivering the missing intermediate certificate from the web server itself to the client at connection time.

In the Apache web server world, you simply need to get a copy of the intermediate certificate, in this case "USERTrustLegacySecureServerCA.crt" (see Part 1), and enter a reference to it through the "SSLCertificateChainFile" directive in the Apache configuration file, "httpd.conf", and specifically, in the section associated to the virtual host. Example for the ISC web server (not the real config file):

<virtualhost 10.10.10.10:443> DocumentRoot /var/www/html ServerName isc.sans.org SSLEngine on SSLCertificateFile /path/to/isc.sans.org.crt SSLCertificateKeyFile /path/to/isc.sans.org.key SSLCertificateChainFile /path/to/USERTrustLegacySecureServerCA.crt </virtualhost>

These three mod_ssl directives point to the server certificate, the server private key, and the intermediate CA certificate, respectively.

End-user awareness regarding the acceptance of invalid digital certificates is a must!

Manual Verification of SSL/TLS Certificate Trust Chains using Openssl (Part 1/2)

This week, during my Internet Storm Center (ISC) shift, Firefox 3.6.3 (the latest available version) displayed a digital certificate error when accessing the ISC login page through SSL/TLS: https://isc.sans.org/myisc.html. I confirmed this on a couple of Firefox instances running on Mac OS X and Windows XP.

We also got a few reports from ISC readers on the same issue, although other people running the same browser version, and even language (EN), on the same OS platforms, didn't get any error message. Finally, the reason was a new ISC digital certificate had been recently installed, and the required intermediate certificate was missing in some web browsers. As a result, the browser couldn't validate the full digital certificate chain to ensure you were really connecting to the website you intended to connect to.

This is a common scenario on security incidents, where Man-in-the-Middle (MitM) attacks or direct web server breaches modify the SSL/TLS certificate offered to the victim, and when accidentally accepted, the attacker can intercept and modify the "secure" HTTPS channel. As you may find yourself dealing with a similar situation in the future... how can you (as I did) check what is the real reason behind the SSL/TLS certificate validation error? By manually verifying the SSL/TLS certificate trust chain, or certificate hierarchy, through openssl.

The goal is to manually follow all the validation steps that are commonly performed it an automatic way by the web browser.

Step 1: Check the certificate validation error and download the controversial digital certificate.

$ openssl s_client -connect isc.sans.org:443 depth=0 /C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org verify error:num=27:certificate not trusted verify return:1 depth=0 /C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org verify error:num=21:unable to verify the first certificate verify return:1 CONNECTED(00000003) --- Certificate chain 0 s:/C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA --- Server certificate -----BEGIN CERTIFICATE----- MIIGATCCBOmgAwIBAgIQOxCOI6FirgnSgN/fCRi57jANBgkqhkiG9w0BAQUFADB/ MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxKjAoBgNVBAMTIVVT RVJUcnVzdCBMZWdhY3kgU2VjdXJlIFNlcnZlciBDQTAeFw0xMDAzMzEwMDAwMDBa Fw0xMTAzMzEyMzU5NTlaMIH5MQswCQYDVQQGEwJVUzEOMAwGA1UEERMFMjA4MTQx ETAPBgNVBAgTCE1hcnlsYW5kMREwDwYDVQQHEwhCZXRoZXNkYTESMBAGA1UECRMJ U3VpdGUgMjA1MRowGAYDVQQJExE4MTIwIFdvb2Rtb250IEF2ZTEbMBkGA1UEChMS VGhlIFNBTlMgSW5zdGl0dXRlMSgwJgYDVQQLEx9OZXR3b3JrIE9wZXJhdGlvbnMg Q2VudGVyIChOT0MpMSYwJAYDVQQLEx1Db21vZG8gVW5pZmllZCBDb21tdW5pY2F0 aW9uczEVMBMGA1UEAxMMaXNjLnNhbnMub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAvYLqphsusuyiVDookRrfsZDx0T1SOf1EQmzUFSK0qVTv+RKM VanUSwsbWuMYrS6W7bGld2/qCGuk2rxMjwtiNE1x2rtaXUkngoKfnQKH+zGErbmc Ead2IjY5OANT6xnxfJS8a29XTqRrKJW8c/PR9NYCGUmq1X+0EnB4+wPZbDsebZ3h 2wISxDaEJlOYbc3MzNyKwbTkwsyn1uwqZS0DQyKqVGL4hZeVmy5OwW9b8/RLYOov NYxTH0bHlbiaOuwakm4cx/ZJMELSBhbgwjt2sLkD8CShdES6fHPPAeMLW//ir3em RMXABEnF1wE5CmvMDe9e6b/joHurw34BISM8twIDAQABo4IB/DCCAfgwHwYDVR0j BBgwFoAUr6RAr58W/qsx/fvVl4v1kaMkhhYwHQYDVR0OBBYEFN6hBRDWEgv4hVZI hR1/CjtAx8k2MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjBCBgNVHSAEOzA5MDcGDCsGAQQBsjEBAgED BDAnMCUGCCsGAQUFBwIBFhlodHRwczovL2Nwcy51c2VydHJ1c3QuY29tMEsGA1Ud HwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RM ZWdhY3lTZWN1cmVTZXJ2ZXJDQS5jcmwwfQYIKwYBBQUHAQEEcTBvMEYGCCsGAQUF BzAChjpodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0TGVnYWN5U2Vj dXJlU2VydmVyQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMGkGA1UdEQRiMGCCDGlzYy5zYW5zLm9yZ4IRaXNjLmluY2lkZW50cy5v cmeCDGlzYy5zYW5zLmVkdYINaXNjMS5zYW5zLm9yZ4INaXNjMi5zYW5zLm9yZ4IR d3d3LmluY2lkZW50cy5vcmcwDQYJKoZIhvcNAQEFBQADggEBAGBhcG/MGgAsiwsB AAg4ZYndAEukeYXpIbXzU5T9ZqkqHPWiUearWDzBgWKJcpgF+v9ZCqCrKuYbXXnv zqZi+BPKX3BSMxHlDUZ0C6tU/G6+FqcV4j19S+xPjAVvk28yqaZc9BNpLnCogAc/ F3gHL7SwCDFowP+RaqUlbUr1UtQgKDILWSOM4ukoVMbCt5nNmyXu0eDFb9tlWkJK KdPYzuKCYfWS7/9bQ868fML3m1xCZqG7L0t/XAFSZYN3ytqtbRTyOjcjdEwSxwA5 O3gV+dW6qM7/AmGZu+0/Grw3WMwiXzO8tRAHYliNz9PDqnK2k5NE0VbKKhndsoRc oAA+AfY= -----END CERTIFICATE----- subject=/C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org issuer=/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA --- No client certificate CA names sent --- SSL handshake has read 2233 bytes and written 325 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 08BED94D2BBA7E525FB37BFE20DCD155CE62C93871B41ABBDF810D663FFC4A61 Session-ID-ctx: Master-Key: 620F10AF948333D43BCC2656E4493563C4A827A8BFAD46AF0815CF3643C602C0E1EBA3CD5DBFE0C4BA65F2DBD9762DF2 Key-Arg : None Start Time: 1271777232 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- closed

From the output, ans specifically the verify return code at the end, you can see that the server certificate cannot be verified.

First of all, create a "certs" directory to put all the required files in. Copy and paste to a file ("ISC.pem") the digital certificate, that is, the text between "-----BEGIN CERTIFICATE-----" to "-----END CERTIFICATE-----" (including both lines).

Step 2: Identify the issuer and get its certificate.

Open the "ISC.pem" certificate file (by double-clicking on it on most operating systems) and inspect the following fields:

• The certificate thumbprint or fingerprint that identifies the server certificate: "bd:95:df:ac...46:aa" (SHA1).
• Issuer (under the "Certificate" section): Who did generate and issue the server certificate? "USERTrust Legacy Secure Server CA" from "The USERTRUST Network".
• The "Certificate Authority Key Identifier" or fingerprint (under "Certificate - Extensions"): "af:a4:40:af...86:16".
• The "Authority Information Access" (under the same section): It contains a pointer to the digital certificate of the issuer certification authority (CA): "URI: http://crt.usertrust.com/USERTrustLegacySecureServerCA.crt".

Obtain a copy of the issuer certificate. The most secure option would be to get its certificate through HTTPS and not HTTP, but this only depends on how the CA decided to make it available. Double check with the CA website that the URL and the fingerprint are valid. In this case, USERTrust was acquired by Comodo, and the issuer certificate is available here (https link) and referenced in its list of certificates. This certificate belongs to the USERTrust intermediate CA and was the one not available in Firefox 3.6.3 by default, hence, the root cause of the initial SSL/TLS error on the ISC website.

Although you might be tempted to perform the manual verification all from the command line, it is not the most secure option, as you could be forced to use http vs. https when using wget or curl. Depending on the version and platform of these tools, they may be distributed without a default list of trusted root certificates or do not use the list available on the system. Therefore, ** this is NOT the way to get the intermediate certificate **, use a web browser instead:

$ wget http://crt.usertrust.com/USERTrustLegacySecureServerCA.crt --2010-04-20 17:32:44--  http://crt.usertrust.com/USERTrustLegacySecureServerCA.crt ... 2010-04-20 17:32:45 (32.0 MB/s) - `USERTrustLegacySecureServerCA.crt' saved [1073/1073] $

Step 3: Try to verify the digital certificate again, but this time make use of the previously downloaded certificate ("USERTrustLegacySecureServerCA.crt").

Before using the downloaded certificate, we need to convert it to the PEM format (not required this time; exemplified later), and build the certificates directory required by the openssl "-CApath" option. The Unix "c_rehash" script helps to create the appropriate directory structure and certificate hash symbolic links. Be sure to rename all the certificates in PEM format to .pem, such as "USERTrustLegacySecureServerCA.crt":

$ c_rehash ./certs Doing ./certs ISC.pem => fc1aa8ab.0 USERTrustLegacySecureServerCA.pem => cf831791.0  $

If we try to validate the certificate again, and if we already have the certificates for all the intermediate and root CA's identified in the trust certificate chain stored on the "certs" directory, we will get a positive response: "Verify return code: 0 (ok)".

$ openssl s_client -CApath ./certs -connect isc.sans.org:443 CONNECTED(00000003) depth=2 /C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority verify return:1 depth=1 /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA verify return:1 depth=0 /C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org verify return:1 --- Certificate chain  0 s:/C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org    i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA --- Server certificate -----BEGIN CERTIFICATE----- MIIGATCCBOmgAwIBAgIQOxCOI6FirgnSgN/fCRi57jANBgkqhkiG9w0BAQUFADB/ ... oAA+AfY= -----END CERTIFICATE----- subject=/C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org issuer=/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA --- No client certificate CA names sent --- SSL handshake has read 2233 bytes and written 325 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session:     Protocol  : TLSv1     Cipher    : DHE-RSA-AES256-SHA     Session-ID: C898C8DB5CD9CDFEE404451BA3E19A440951A1960DAC1BA62FD35F23D9772B30     Session-ID-ctx:     Master-Key: EC4D939A112112AAAB01DFF5FA0A5F6C26C568C8DEBBDF3A61515E8CD83F257DAB5894BC450A97A7EE5ABAB0B1893795     Key-Arg   : None     Start Time: 1271778616     Timeout   : 300 (sec)     Verify return code: 0 (ok) --- closed

If the certificate chain or hierarchy contains additional certificates, that is, there are multiple intermediate CA's involved, you may need to repeat the same process and download the certificates for all the other intermediate CA's and the root CA (omitted for brevity). For example, the intermediate USERTrust certificate was issued by "Entrust.net Secure Server Certification Authority". This root CA certificate can be manually obtained in DER format from Entrust website, with a fingerprint of "f0:17:62:13...d0:1a".

Once again, this DER file must be converted to PEM format using openssl:

$ openssl x509 -in entrust_ssl_ca.der -inform DER -outform PEM -out entrust_ssl_ca.pem

Finally, you will need to rebuild the certificates directory again, using "c_rehash", once it contains all the intermediate and root CA certificate files that belong to the certificate chain being tested, and try to verify the certificate again.

Part 2 of this article covers the chain layout for the ISC certificate in this case, how to identify the missing certificate on the web browser trust certificates list, and how to avoid this kind of error from the web server perspective, using Apache.