Jacob Thompson, Independent Security Evaluators

Enterprise networks increasingly intercept and inspect SSL-protected employee web traffic—often without adequate understanding on the employee’s behalf—and almost certainly without the consent of the entity operating the server. The cases of Trustwave, TURKTRUST, and ANSSI illustrate how the confidentiality of client-server communications is further threatened by the mounting abuse, misuse, incompetence, and compromise of trusted certificate authorities. Prior notice and the need to install custom root certificates are no longer technical hurdles impeding SSL interception, and security professionals should fear the possibility that SSL interception could expand beyond enterprises in the near future. Much previous work has focused on detecting this interception at the client; we discuss how to leverage built-in browser and server capabilities, well understood in academia but rarely used in practice, to achieve mutual authentication, moving the decision of whether to allow SSL interception and inspection from the client to the server.

Introduction

Internet users, including many security professionals, often blindly rely on SSL/TLS to provide the confidentiality and integrity of our personal data, at least when using our web browsers. We expect SSL/TLS to do so even in the face of attackers with the ability to hijack and redirect our network connections and DNS traffic (i.e., a man-in-the-middle attack). To resist these attacks, our browsers rely on a list of trusted certificate authorities to authenticate server certificates. Browser vendors audit these certificate authorities, but must presume that neither the trusted root authorities nor any intermediate authorities chaining to a trusted root will sign a certificate for an entity without first verifying that the entity controls the domain name listed in the certificate.

Unfortunately, our faith in SSL/TLS is increasingly misplaced. Accompanying the string of severe security vulnerabilities affecting SSL/TLS libraries in recent years are three specific issues that undermine our browsers’ ability to verify a server’s certificate:

• The list of trusted certificate authorities on a client device can be customized. This is an issue in any situation where the user of a device is not also the administrator. Corporate enterprises often use this ability to add a custom, internally controlled CA to the list, used solely to sign phony certificates for the purpose of SSL interception [1].
• Some certificate authorities have allowed devices to be constructed, containing an intermediate CA chaining to a trusted root, for the explicit purpose of producing phony certificates on-the-fly to perform SSL interception while avoiding certificate warnings or the need to install a custom CA into each client device [2].
• Large organizations can obtain and internally operate a sub-CA chaining to a trusted root, allowing them to issue certificates to their servers in bulk, rather than submit an individual requests to the CA for each server [3]. Frequently, no technical constraints prevent an organization from using the sub-CA to issue certificates for domains they do not own. Though legal agreements may preclude it, these organizations can and at times do, without the root CA’s permission, load their sub-CA into an interception device to perform man-in-the-middle attacks with phony certificates that appear legitimate to browsers [4, 5].

In light of these issues, and the inability of browser vendors to effectively police certificate authorities that fail to fulfill their important responsibilities in the Internet security infrastructure, technical solutions have been proposed to supplement or replace the traditional CA-based model. Of those solutions that augment the existing CA infrastructure, rather than replace it, nearly all are fully client based (e.g., certificate pinning). The server still has no way to detect and block attempted SSL/TLS interception attacks.

For some time, all significant web browsers have had the built-in capability to generate public-private key pairs. Long known in academia but rarely used in practice, this can be leveraged to achieve mutual client-server authentication. The server acts as its own certificate authority for the purpose of authenticating the client. In doing so, we replace an SSL interception device’s problem of producing a phony server certificate to suppress warnings on the client with the harder problem of fraudulently obtaining a client certificate from the server. With a sufficiently secure process in place for obtaining the client certificate, we allow the server to resist, if not prevent, automated interception, or at least require an interception device to perform attacks that may cross legal boundaries in order to obtain the client certificate, such as phishing.

SSL/TLS Interception

Routine SSL/TLS interception is rarely performed outside of enterprise networks today. Still, just as hijacking failed DNS queries [6], imposing opt-out content filtering [7], and injecting JavaScript advertisement code [8] have become routine and accepted behavior among ISPs, we fear that interception could reach public networks in the future, in light of certificate authorities’ demonstrated willingness to assist in performing it. Just as these three examples are touted by ISPs as “helping” their users, SSL/TLS interception could be cast in a positive light as an anti-malware or content filtering feature.

In this section, we provide enterprises’ motivations to perform interception and an overview of how it occurs, explore three recent examples demonstrating public certificate authorities’ role in interception, and review the inability of browser vendors to effectively prevent the authorities from doing so.

Corporate Interception

Large enterprises are justifiably concerned with the risk that Internet connectivity presents. Potential unauthorized data egress could lead to financial and reputational harm. In order to monitor for this, many large corporations implement data loss prevention (DLP) systems, which put proxy servers in place to monitor traffic for sensitive data or malware.

In the past, many websites used HTTPS in exceptional cases, such as the transmission of the password from a login page, or receiving credit card information. Thus, the end-to-end security provided by SSL/TLS was not a major issue for the DLP system. More recent web applications use HTTPS to protect the entire site. The pervasive use of HTTPS for webmail, social networking sites, forums, and chat clients introduces a significant attack surface allowing incoming malware or outgoing confidential data to travel through the network without detection. Data loss prevention systems now include SSL/TLS inspection as a feature; some vendors of these applicances claim that an organization cannot be HIPAA or Sarbanes-Oxley (SOX) compliant without SSL inspection [9].

The advent of bring your own device (BYOD) environments is challenging and raises many questions. The use of SSL interception against these devices, and the presence of mobile device management (MDM) in general, mean that from security and privacy perspectives the device is, for all intents and purposes, company owned. Particular issues include:

• How is personal and business use of the device distinguished to ensure that only business traffic is intercepted and monitored?
• Who ensures that the interception stops if a user leaves the company?
• What stops the interception if a user gives a device to a family member as a hand-me-down and buys another?
• Misunderstandings about the role of the device (treated as personal by the employee outside of work hours, but as company by the enterprise) could lead to significant issues, e.g., if confidential employee communications with OHSA, the EEOC, the NLRB, or other regulatory agencies is inadvertently monitored and captured by the employer.

We concede that SSL interception in a business environment may be a case of making the best of a bad situation, under certain conditions: (1) the interception is facilitated using an internal certificate authority that does not chain to a publicly trusted root, to preserve the security model of public certificate authorities, (2) the interception is performed only against company-owned or controlled (BYOD) devices, and (3) users expressly consent to the monitoring (e.g., through a network usage agreement) and truly understand its implications. But corporate employees are just beginning to become aware of the privacy implications of business security controls [10], and thus we believe that an entity operating a web server should be able to protect its users by detecting SSL/TLS interception, if desired.

CA-Assisted Interception

As long as publicly-trusted root certificate authorities (and all intermediate certificate authorities chaining to those roots) fulfill their role in the web’s security model by refusing to provide signed certificates to anyone other than a domain’s owner, wide-scale, robust SSL/TLS interception is not possible in the absence of unrelated security vulnerabilities. Without the ability to produce trusted yet phony certificates for servers while performing interception, a system must use its own custom certificate authority to produce those certificates, with one of two consequences: (1) the need to install the custom authority as trusted on all machines affected by the interception, or (2) the need to override certificate warnings on all affected devices.

An important concept in the certificate authority industry is the concept of a subordinate certificate authority (sub-CA), also known as an external CA. Sub-CAs allow businesses who are not in the CA business to act as a CA regardless, by obtaining a sub-CA that chains to a trusted root. The purpose of sub-CAs is to allow businesses with the need to issue large numbers of certificates to their own devices to manage this process on their own, rather than interacting with a public CA each time a certificate is needed. GeoTrust is one certificate authority that issues sub-CAs; in order to obtain one, an organization must have a five-million dollar net worth [11]. Many large companies own sub-CAs, including Aetna, EarthLink, Dell, Ford, Fuji Xerox, General Electric, Google, and Wachovia [12].

The problem with sub-CAs is in preventing an entity with a sub-CA from signing certificates for domains that it does not own. The X.509 field used to restrict the scope of domain names that a CA can sign, name constraints, is not widely supported [13]. In fact, a survey of the entire IPv4 address space found 1,832 trusted (intermediate or root) CAs, of which only 7 had name constraints imposed [14].

Consider how three recent examples involving sub-CAs being used to produce phony certificates show that the classical root certificate authority-based trust model is breaking down:

1. Trustwave. In 2012, Trustwave issued a sub-CA to a private organization [2]. This sub-CA was to be loaded into a device performing a man-in-the-middle attack, and its sole purpose was to allow that device to generate trusted certificates for arbitrary domains, allowing interception against all devices on the network. This approach avoided the need to install a custom root certificate across all device, and also prevented certificate warnings, by chaining the phony certificates to Trustwave.
2. TURKTRUST. In 2013, a sub-CA issued by TURKTRUST, a root certificate authority based in Turkey, issued a phony certificate for the google.com domain. The certificate pinning capabilities added to Chrome by Google detected this certificate in the wild [4].
3. ANSSI. Also in 2013, ANSSI, a root certificate authority controlled by the French government, issued a sub-CA to the French treasury department, IGC/A, and IGC/A in turn used the sub-CA to intercept and monitor employee web traffic [15].

Failure to Effectively Police Certificate Authorities

When failures in the certificate authority trust model keep occurring each year, what consequences or penalties apply to the certificate authorities? A legal analysis of certificate authorities found that certificate authorities often use legal language to disclaim any warranty for a party relying on one of their certificates, and the case of an end user relying on a false certificate is untested in court [16]. Thus, the only effective recourse against misbehaving certificate authorities is for browser vendors to remove those authorities from the list of trusted CAs distributed with browsers.

As removing a trusted CA from browsers in response to a handful of invalid certificates causes collateral damage (all sites using valid certificates issued by that CA would begin receiving certificate warnings), the browser vendors have been reluctant to do so. The only prominent example was DigiNotar, whose trust was revoked only after DigiNotar itself was compromised [17].

A review of Mozilla’s security policy newsgroup [18, 19] illustrates the frustration that many in the Mozilla security community have with the inability to effectively police certificate authorities. Despite the fact that ANSSI was non-compliant with Mozilla and CA/Browser Forum policies, and the fact that both the TURKTRUST and ANSSI compromises had to be detected by third parties, rather than caught and self-reported by the CAs themselves, Mozilla determined that removing these CAs from the trusted list would be too disruptive. It is clear that there is little incentive for certificate authorities to make the investment in improving their practices as long as even the CAs with the poorest practices remain trusted.

When a compromise or abuse of a certificate authority does occur, blacklisting the affected certificates on client devices may happen only after a lengthy delay, if at all. The DigiNotar CA compromise was detected on August 27, 2011 [20], but the first iOS release to remove DigiNotar from the trusted store occurred on October 13, 2011—nearly three months later. On some older Android devices, the end user could not control the built-in trusted certificate store at all; a certificate blacklist feature was not added until the Jellybean release (4.2) [21].

Prior Work

Since it is evident that the integrity of root certificate authorities as a whole is unlikely to improve in the near future, many have worked on developing solutions. Some propose to replace the CA trust model entirely, such as the Convergence system by Marlinspike [22]. Others, such as Google, seek to build more defense-in-depth security checks into the existing model.

Certificate pinning as implemented by Google Chrome [23] and Mozilla Firefox [24] allows the browser to maintain a pre-loaded list of acceptable public keys for a handful of high-profile websites, such as Google, Twitter, and Facebook. This feature has already detected real-world attacks [25]. The limitation of certificate pinning (as of this writing) is that each protected site must be explicitly built into the browser, and requires cooperation with the browser vendors in order to add a new site, so it is not scalable to any but the highest-profile websites at this time. Other solutions, such as the Certificate Transparency initiative [26], aim to improve certificate authorities by having the authorities make a public log available containing their signing actions.

Mutual Authentication and SSL Interception

A solution for resisting SSL interception without breaking compatibility or requiring cooperation with third parties is needed. The SSL/TLS protocol allows not only servers to authenticate themselves using certificates, but clients as well. Client certificates are widely popular in some government agencies and countries, such as Estonia [27], but are not used by websites catering to the general (US) public. Interestingly, client certificates allow us to sidestep the interception problem.

First, enterprises have absolutely no control over the list of trusted client certificate authorities present on third-party web servers. Second, web servers can be set up to issue their own certificates, rather than rely on a third party CA. Since an interception device has no way to produce an acceptable client certificate on its own, it can only obtain one by extracting the certificate and key from an end user’s device, or by subverting the process used by a legitimate client to obtain a certificate in order to frauduluently obtain one.

In fact, all web browsers include support for generating RSA key pairs in order to facilitate the issuing of client certificates, and have for many years. The HTML keygen tag causes the browser to generate a key pair, retain the private key, and transfer the public key to a server as part of a form submission. This tag is supported by Chrome, Firefox, and Safari; Internet Explorer offers similar functionality through the certificate enrollment control. After receiving the public key, the server can generate a signed certificate and return it to the browser. Then, the browser immediately adds the certificate to its store of client certificates and allows it to be used for authentication to the server.

How should the server verify a user’s identity before issuing a certificate? As in any PKI system, this is a difficult problem. Since we are leveraging client certificate authentication only to frustrate man-in-the-middle attacks, and not to truly verify a client’s identity, we could ignore this issue, and allow the server to blindly sign any certificate requests that it receives. In fact, this would be similar to the level of security provided by SSH: as long as the very first connection to a server is not intercepted, a user would receive and retain a valid certificate. The user would never again need to go through the enrollment process unless the certificate were deleted, the user moved to a different device, or the certificate expired.

Instead, we have built a limited amount of identity verification into our proposed solution. We simply have the server generate a 128-bit enrollment key, and send it to the user through an out-of-band channel. Then, as long as either the public key is encrypted with this key before it is sent to the server, or the signed certificate is encrypted with this key before it is returned to the client, a man-in-the-middle cannot complete the enrollment process without possessing the key. Thus, the man-in-the-middle must obtain the key from the user, e.g. through phishing.

For Firefox and Safari, the solution works as follows:

1. The user access the website in its original form, e.g., mutual.www.ise.io, which does not require client authentication.
2. The resulting page tests for the presence of a client certificate by attempting to load an iframe from a mutually-authenticated server, in this case, www.mutual.www.ise.io.
3. If the iframe load succeeds, then the user must already have a client certificate, and JavaScript code within the iframe redirects the user to the mutually-authenticated website.
4. If the redirection has not occurred within a few seconds, then the iframe load must have failed. Therefore, the user must not have a certificate, and we begin the enrollment process.
   1. The user enters an e-mail address and CAPTCHA in order to receive the out-of-band key.
   2. The keygen tag is used to generate a certificate request and send it to the server.
   3. The server signs a certificate, encrypts it using the out-of-band key, and returns the encrypted certificate back to the client.
   4. JavaScript code prompts the user for the out-of-band key, and then uses it to decrypt and install the received certificate (entirely at the client side).
   5. The user can then access the mutually-authenticated server.

The process for Chrome is similar, but as limitations in Chrome prevent a certificate from being decrypted and then installed using JavaScript, the certificate request is encrypted, instead. We acknowledge that a MAC is a more correct solution for this purpose.

Example

An example server implementing this solution is available at mutual.www.ise.io.

Attribution and Acknowledgements

This research was conducted by Jacob Thompson and directed by Stephen Bono.

References

[1] Jarmoc, Jeff. SSL Interception Proxies and Transitive Trust. Black Hat Europe 2012, Amsterdam, Netherlands.

[2] Trustwave to escape ‘death penalty’ for SSL skeleton key

[3] Trusted Root Signing Certificates

[4] Enhancing digital certificate security

[5] Further improving digital certificate security

[6] DNS Hijacking – Manipulation by ISPS

[7] UK government to activate adult content filters by default

[8] Comcast Wi-Fi serving self-promotional ads via JavaScript injection

[9] Managing Encrypted Traffic With Blue Coat Solutions

[10] Mobile Workers: ‘I Want My BlackBerry Back’

[11] GeoRoot

[12] EFF SSL Observatory Map of CAs

[13] Adventures in X.509: The Utterly Ignored nameConstraints

[14] Analysis of the HTTPS Certificate Ecosystem

[15] French gov used fake Google certificate to read its workers’ traffic

[16] The “Certificate Authority” Trust Model for SSL: A Defective Foundation for Encrypted Web Traffic and a Legal Quagmire

[17] DigiNotar Removal Follow Up

[18] Revoking Trust in one ANSSI Certificate

[19] Netcraft blog, violations of CABF Baseline Requirements, any consequences?

[20] Is This MITM Attack to Gmail’s SSL? [sic]

[21] Certificate Blacklisting in Jelly Bean

[22] Convergence

[23] New Chromium security features, June 2011

[24] Public Key Pinning

[25] An update on attempted man-in-the-middle attacks

[26] Certificate Transparency

[27] Practical Issues with TLS Client Certificate Authentication

Analysts at ISE have identified and exploited a security vulnerability in the Android operating system allowing a remote adversary to gain control on the device with the same permissions as the web browser application. A successful attacker will have access to information such as cookies used for accessing sites, information put into web application form fields, and saved passwords, and can alter the way in which the browser works, potentially tricking the user into entering sensitive information.

UPDATE: A story in the New York Times about this work is available here.

Android phone.

Welcome

Charlie Miller, Mark Daniel, and Jake Honoroff of Independent Security Evaluators identified and exploited a security vulnerability in the Android operating system. The Android operating system, developed by Google, is open source and has many rich features specifically designed for cellular phones, such as web browsing, camera, GPS, and accelerometer control. The first commercial phone with the Android operating system, the T-Mobile G1 by HTC, is available as of October 22, 2008. These phones will currently ship with the vulnerability present and may pose a security risk to their users until an update becomes available.

The Vulnerability

Android is based on over 80 different open source packages. The vulnerability is due to the fact Google did not use the most up to date versions of all these packages. In other words, this particular security vulnerability that affects the G1 phone was known and fixed in the relevant software package, but Google used an older, still vulnerable version. So as not to inform the “bad guys”, we will not release any further information on the particular vulnerability or software package until a fix is available.

The Impact

A user of an Android phone who uses the web browser to surf the internet may be exploited if they visit a malicious page. Upon visiting the malicious site, the attacker can run any code they wish with the privileges of the web browser application. We have a very reliable exploit for this issue for demonstration purposes. This exploit will not be released until a fix is available.

The Android security architecture is very well constructed and the impact of this attack is somewhat limited by it. A successful attacker will have access to any information the browser may use, such as cookies used for accessing sites, information put into web application form fields, saved passwords, etc. They may also change the way the browser works, tricking the user into entering sensitive information. However, they can not control other, unrelated aspects of the phone, such as dialing the phone directly. This is in contrast, for example, with Apple’s iPhone which does not have this application sandboxing feature and allows access to all features available to the user when compromised. For more information on the security of the iPhone, visit ISE’s site describing the first exploit of an iPhone security vulnerability here.

Working with Google

Google was notified of this issue on October 20th, 2008. We are working with them to try to get a fix as quickly as possible.

Media Contact

We can be reached by phone at 443-270-2296.

Jacob Thompson, Independent Security Evaluators

Over the past year, ISE has brought our SOHOpelessly Broken router hacking contest to DEF CON, DerbyCon, Toorcon, and BSides DC. ISE started the contest to shine light on the need for manufacturers to better secure small office/home office (SOHO) devices; our thought was that by demonstrating the vulnerabilities first-hand, we could help manufacturers recognize that SOHO devices are highly vulnerable to malicious compromise, thus inspiring action and change. Among the contest’s tracks is a live capture-the-flag competition, in which contestants research known vulnerabilities and use them to attack real routers running on a test network. Cross-site request forgery (CSRF) is a common attack against the web interfaces of embedded devices. CSRF occurs when an adversary tricks the victim into clicking a link that leads to an attack page while simultaneously logged in to the vulnerable device. The attack page generates and sends malicious HTTP requests to the device, reconfiguring it without the victim’s knowledge or authorization. For the contest to be successful, we needed to automate the process of tricking a user into becoming a victim of a CSRF attack; the result is our link-clicking CSRF victim robot. This white paper describes the design and implementation of the resulting software.

Introduction

In 2014, ISE started the SOHOpelessly Broken router hacking contest to shine light on the need for manufacturers to better secure small office/home office (SOHO) devices; our thought was that by demonstrating the vulnerabilities first-hand, we could help manufacturers recognize that SOHO devices are highly vulnerable to malicious compromise, thus inspiring action change.

To facilitate the router hacking contest, we needed to find a way to allow our participants to launch cross-site request forgery (CSRF) attacks. Our ultimate goal was to develop an automated program that simulated the act of a hypothetical LAN-side router user clicking malicious links. CSRF occurs when a Web page loaded from one domain controlled by the attacker sends a malicious HTTP request to another domain, such as a router’s administration interface. While the browser’s same-origin policy does prevent the attacker’s code from obtaining the response to this request (as the attacker’s and router’s origins are different), the router nonetheless receives the request. If the user is actively logged in, and the router’s Web interface code has specifically been designed to detect and block CSRF, the router acts upon this fraudulent request. Depending upon other defenses present in the router, if any, CSRF can be used to change the administrator’s password, enable remote administration, or add new port forwarding entries to the router’s configuration.

We set up our contest network by assigning each router’s administrative interface a password unknown to the contestants, and then connecting one LAN port of each router to a central switch. The contestants, as well as our CSRF victim machine, were also connected to the same switch. The goal was to allow the contestants to trick a “user” into clicking an arbitrary link while logged into all of the routers’ interfaces and simultaneously preserving the secrecy of the router passwords, as well as the success or failure of the attack—much like a real-world scenario. To accomplish this, we needed the CSRF victim machine to provide the following functionality:

1. Keep the Firefox Web browser open and logged in to each router’s administrative interface. As some of the interfaces were set to time out automatically after login, this includes periodically reloading each interface to prevent the inactivity timer from expiring.
2. Provide a Web interface to which the contestants could submit their malicious links.
3. Keep the Firefox Web browser open and logged in to each router’s administrative interface. As some of the interfaces were set to time out automatically after login, this includes periodically reloading each interface to prevent the inactivity timer from expiring.
4. Upon receiving a malicious link, open the link in the same browser session in which the “user” is logged in to each router.
5. After a reasonable interval, close the malicious page and wait for the next link to be submitted.

We accomplished this using a laptop running CentOS 6. Below, we describe each goal, discuss how we accomplished them, and provide sample code.

Maintain Logged-In Sessions to Each Router

Our contest contained 10 routers, and we needed to set up a browser session that simulated what would occur if a user manually opened 10 separate windows and logged in to one router’s administrative interface in each window. A handful of routers turned out to perform authentication at the client side, so we did not need to take any steps to log in to routers (lucky for us, unfortunate for the users of those routers). Most routers use HTTP Basic authentication to secure access to their administrative interfaces.

The routers employing HTTP Basic authentication require the browser to submit an Authorization header with each request containing a base64-encoded username and password, and if this header is missing or incorrect, they return an HTTP 401 Unauthorized error. Normally, this causes the browser to issue an authorization dialog box, which we wanted to avoid, as we were trying to automate the process of remaining logged in to all of the routers. In fact, HTTP Basic authentication credentials can also be encoded in a URL (in the form http://username:password@domain.example.com/page.html), a feature rarely used today outside of phishing attacks. We leveraged this fact to create a page, one .html (shown in Figure 1), which, when displayed in the browser, causes the user to be automatically logged in to the router 192.168.10.1 with the username admin and password RouterOnePassword.

A few routers used more sophisticated techniques for authentication, such as an HTTP POST form submission, that, when received, causes the router to issue a session cookie (assuming the credentials are valid). After designing one HTML page per router, we then created a page (see Figure 2) that loads each of these per-router pages. It also automatically refreshes every 300 seconds (5 minutes) in an attempt to avoid any timeout features in the routers’ interfaces.

1: <img src="http://admin:RouterOnePassword@192.168.10.1/adm/status.asp">

Figure 1. When the browser encounters this IMG tag, it automatically attempts to log in to the router 192.168.10.1 using Basic authentication with our supplied credentials.

 1: <html>
 2: <head>
 3: <title>KeepLoggedIn</title>
 4: <meta http-equiv="Refresh" content="300">
 5: </head>
 6: <body>
 7: <iframe src="1.html"></iframe>
 8: <iframe src="2.html"></iframe>
 9: <iframe src="6.html"></iframe>
10: <iframe src="7.html"></iframe>
11: <iframe src="8.html"></iframe>
12: <iframe src="10.html"></iframe>
13: </body>
14: </html>
15: 

Figure 2. Our per-router authentication pages are all automatically loaded and refreshed every five minutes.

Accepting Malicious Link Submissions from the Contestants

We used a bare-bones PHP Web application to accept malicious link submissions from our contestants. It consists of a static HTML page as shown in Figure 3. The page shows a single field, which allows the attacker to specify any link he/she desires to open in a browser session while simultaneously logged in to each router.

When the user submits the form, it is sent to a back-end PHP page (see Figure 4). This back end simply opens a pre-created FIFO (named pipe) on the file system, writes the link to the FIFO, closes it, and then returns a status back to the user. Our link-clicking script listens on the far end of the FIFO and performs the actual clicking of the link. We split the components in this way so that the server-side PHP code and the link-clicking script could run under separate user accounts.

 1: <html>
 2: <head>
 3: <title>Link Clicker</title>
 4: </head>
 5: 
 6: <body>
 7: <form id="link_submission" action="click.php" method="post">
 8: <table>
 9:   <tr>
10:     <td style="vertical-align:text-top;">Link:</td>
11:     <td>
12:       <input form="link_submission" rows="7" cols="45" id="link" 
13:              name="link" value="http://">
14:     </td>
15:   </tr>
16:   <tr>
17:     <td colspan=2 height=50 style="text-align:center;">
18:       <input style="width:150; height:25;" type="submit" value="Submit">
19:     </td>
20: </tr>
21: </table>
22: </form>
23: </body>
24: </html>

Figure 3. Link submission page front end.

 1: <?php
 2:         
 3:         $fifo_file = "/usr/local/share/routers/fifo";
 4:         $fifo_handle = fopen($fifo_file, "a");
 5:         $link = $_POST["link"] . "\n";
 6: 
 7:         fwrite($fifo_handle, $link);
 8:         fclose($fifo_handle);
 9:         
10: ?>
11: Link clicked
12: 

Figure 4. Link submission page back end.

Link-Clicking Script

Our Web application performs the work of collecting malicious links from contestants, but the contest needs a simulated user to follow the link. The link-clicking script receives links from the Web application and opens them one-by-one inside a browser session in which the “user” is also logged in to each router. The script (shown in Figure 5) reads URLs from a pre-created FIFO, one per line, and then uses Firefox’s remote option to open a new browser window to display the specified link.

To make it easier to track when a malicious link is currently open, we previously reconfigured Firefox browser preferences to disable the option “Open new windows in a new tab instead.” After opening the malicious link, the script waits 30 seconds and then launches our window-closing program to close the attack window. Closing any newly opened windows between each attack helps to ensure that only one attack is underway at any time, and it reduces clutter on the victim machine screen.

 1: #!/bin/bash
 2: 
 3: IFS=''
 4: FIFO_FILE=/usr/local/share/routers/fifo
 5: 
 6: while read url < $FIFO_FILE; do
 7:         firefox -remote "openurl($url)"
 8:         sleep 30
 9:         ./closer
10: done 

Figure 5. Link-clicking shell script.

Window-Closing Program

The final component of our CSRF attack victim is a program that cleans up any Firefox windows left open after our 30 seconds of attack time has expired. The main window, which keeps the user logged in to each router (Figure 2), must remain open. The resulting C program (shown in Figure 6) uses window titles to track our “KeepLoggedIn” page and closes all others.

The program uses libX11, a low-level X Window System library, to locate windows to be closed and to generate and send the event messages to close those windows. It begins by opening a connection to the X server in lines 88–93. Next, in lines 96–98, it traverses all open windows. The X Window System organizes the open windows in a tree structure beginning with the root; the recursive process of visiting each window occurs in the traverse function in lines 66–81. The actual work of examining window titles and closing appropriate windows occurs in the process_window function in lines 32–64. Windows with a class of Navigator – Firefox are checked to see if their titles contain KeepLoggedIn. If so, they are “spared,” and if not, they are “closed;” the close_window function, in lines 10–30, generates the event needed to delete (close) the selected window.

 /* link with -lX11 */
 
 #include <X11/Xatom.h>
 #include <X11/Xlib.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 
 static void close_window(Display *display, Window window)
 {
    static Atom wm_protocols = 0, wm_delete_window = 0;
    XClientMessageEvent event;

    if (wm_protocols == 0)
       wm_protocols = XInternAtom(display, "WM_PROTOCOLS", False);
    if (wm_delete_window == 0)
       wm_delete_window = XInternAtom(display, "WM_DELETE_WINDOW", False);
 
    memset(&event, 0, sizeof event);
    event.type = ClientMessage;
    event.display = display;
    event.window = window;
    event.message_type = wm_protocols;
    event.format = 32;
    event.data.l[0] = wm_delete_window;
    event.data.l[1] = CurrentTime;
 
    XSendEvent(display, window, False, 0L, (XEvent *) &event);
 }

 static void process_window(Display *display, Window window)
 {
    static const char firefox_class[] = "Navigator\0Firefox";
    Atom actualType = 0;
    int actualFormat = 0;
    unsigned long nitems = 0;
    unsigned long bytes_after = 0;
    unsigned char *prop = NULL;

    XGetWindowProperty (display, window, XA_WM_CLASS, 0, 65535, 0, 
                       XA_STRING, &actualType, &actualFormat,
                       &nitems, &bytes_after, &prop);
    if (prop == NULL)
       return;
    if (memcmp(prop, firefox_class, sizeof firefox_class))
       return;
    XFree (prop);

    XGetWindowProperty (display, window, XA_WM_NAME, 0, 65535, 0,
                       XA_STRING, &actualType, &actualFormat,
                       &nitems, &bytes_after, &prop);

    if (prop == NULL)
       return;
    if (strstr ((char *) prop, "KeepLoggedIn"))
       printf ("%lx spared\n", window);
    else
    {
       printf ("%lx closed\n", window);
       close_window (display, window);
     }
    XFree (prop);
 }

 static void traverse(Display *display, Window window)
 {
    Window root = 0, parent = 0, *children = NULL;
    unsigned int nchildren, i;
   
    process_window(display, window);
 
    XQueryTree(display, window, &root, &parent, &children, &nchildren);
    
    if (children != NULL)
     {
       for (i = 0; i < nchildren; ++i)
          traverse(display, children[i]);
       XFree(children);
    }
 }

 int main (void)
 {
    Display *display;
    Window window;
 
    display = XOpenDisplay(NULL);
    if (display == NULL)
    {
       fputs("cannot open display\n", stderr);
       return EXIT_FAILURE;
    }
 
 
    window = DefaultRootWindow (display);
    traverse(display, window);   
    XCloseDisplay(display);
    return EXIT_SUCCESS;
 }

Figure 6. Window-closing program that closes any Firefox windows that do not contain “KeepLoggedIn” in the title.

Conclusion

By stitching together a short HTML document, PHP file, shell script, and C program, we designed a CSRF victim link-clicking robot with minimal effort. A logical extension to the robot would be to add support for Flash, Java, and other attack vectors; to add operating system or browser-specific attacks; or to require attackers to bypass anti-malware software of some form.

Note that these scripts and programs have not been thoroughly audited for security issues. Before modifying or using this code,we recommend that you carefully consider the security impact of accepting and handling link inputs from third parties and that you ensure that the inputs are validated and sanitized correctly before they are passed to shell scripts, Firefox, or other programs.