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
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
• exfiltrating sensitive data, such as NAS-protected files
or a user’s keystrokes
• Redirecting the user to a drive-by-download site10 or a
• 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
An XCS attack comprises two steps, as shown in Figure 2.
In the first step the attacker uses a non-Web channel such
106 communicaTionS of The acm | auGust 2010 | Vol. 53 | no. 8
figure 2. overview of the XcS attack.
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.