browser. The script executes on the admin’s browser giving the attacker full control of the admin session. In Section 3, we present the most interesting XCS attacks we discovered.

We also found a related class of attacks in which a Web vulnerability is used to attack a non-Web channel. We refer to this as a reverse Xcs vulnerability. We give examples in Section 4.

XCS and reverse XCS are more likely to affect embedded devices than traditional Web sites because these devices often provide a number of services (e.g., Web, SNMP, NFS, P2P) which are cobbled together from generic components. The interaction between the components may not be completely analyzed, leading to an XCS vulnerability. In contrast, many Internet Web sites only provide a Web interface and hence are less likely to be affected by XCS. Interestingly, large Web sites, such as Facebook and Twitter, provide non-Web cloud APIs for third-party applications which present XCS opportunities, as discussed in Section 5.

Detecting an XCS or reverse XCS vulnerability can be difficult because these attacks abuse the interaction between the Web interface and an alternate communication channel. Simply inspecting the Web application code and the other service code is not enough to detect the vulnerability. The Web application and the other service, such as an FTP server, can be completely secure in isolation and become vulnerable only when used in conjunction.

An XCS exploit can be used to carry out a variety of attacks
including
• exfiltrating sensitive data, such as NAS-protected files
or a user’s keystrokes
• Redirecting the user to a drive-by-download site10 or a
phishing site
• exploiting the user’s Ip address for DDoS9 or for
proxying the attacker’s traffic
On consumer electronic devices, an XCS exploit can be a
stepping stone toward a larger attack on the user’s LAN that
aims to assimilate home machines into a botnet4 or to break
into the user’s corporate network. For instance, a reverse
XCS can be used to reboot a switch and therefore shutdown
an entire LAN.

2. cRoSS channeL ScRiPTinG in a nu TSheLL

An XCS attack is an attack where a non-Web channel is used to inject a script into Web content running in a different security context.

An XCS attack comprises two steps, as shown in Figure 2. In the first step the attacker uses a non-Web channel such as an FTP or SNMP service to store malicious JavaScript

106 communicaTionS of The acm | auGust 2010 | Vol. 53 | no. 8

figure 2. overview of the XcS attack.

Alternate
channels
Web
Attacker
Device
User
Injection
Storage
Reflection

code on the server. In the second step the malicious content is sent to the victim by the Web application. As soon as the victim accesses the malicious content via her browser, it is executed with her permissions. While an XCS exploit is a form of persistent (Type 2) XSS, we argue that a distinction between the two should be made for two reasons.

First, XCS vulnerabilities are harder to detect since they involve multiple protocols. Static analyzers used to detect XSS (such as Pixy8) do not detect XCS because their taint analysis assumes that the user input is stored in global variables. Using taint analysis to detect XCS is difficult because of the large number of possible tainted data sources. For example, for PHP, in addition to the obvious file( ), and other file related functions, many other protocol specific functions need to be considered. This includes every SNMP function that reads data, such as snmpget(), ftp_nlist() which lists an FTP directory, and of course database functions that return a result set, such as mysql_ fetch_object( ). Even if all the functions were correctly enumerated, the number of false alarms would be overwhelming. Current research on static analysis shows promise in improving the situation in the near future. 1

Second, XSS defenses that sanitize data at input time are unlikely to protect against XCS. These mechanisms are mostly applied to data acquired from Web traffic, while in XCS the attack vector is presented through a non-Web channel which is unlikely to sanitize for Web exploits. This difficulty of detecting and preventing XCS vulnerabilities explains why in every embedded device we examined we were able to uncover XCS problems.

3. ReaL-WoRLD XcS

We present four case studies illustrating different types of real-world XCS vulnerabilities in popular embedded devices and mobile phones. The first example uses file transfer protocols such as FTP to inject a script into persistent storage, the second uses P2P networks, and the third injects a script into log files. The final example uses the calendar protocol to infiltrate the Palm Pre.

3. 1. a two-stage XcS exploit

NAS appliances are lightweight servers that provide data storage services to other devices on the network. The low-end NAS market is very active with over 50 vendors offering products, including Apple, Buffalo, Dell, Lacie, and Linksys.