such posting is assumed to be under the control of the
At this point, the problem is to acquire the data that will be
exfiltrated. The standard way to post a file is to use a file input
field that the user will use to select which file to post. Of course
in our case, we need to find an alternate method as we don’t
have the user’s cooperation, and, moreover, it is not possible
approach. Based on the observation that the files we want
to exfiltrate are located in the same domain as the ghost, we
came up with the idea of using an XHR (XMLHTTPRequest) to
The same origin policy is once again unable to prevent
this behavior because our ghost acts here as an autoimmune disease: an infected page attacks the rest of the same
Web site. One difficulty with using this method is that the
XHR object is not designed to fetch binary data—only text,
and so using solely XHR is not sufficient. To go around
this issue, we came up with the idea of changing the http
request header and more precisely the Mimetype encoding.
In Firefox, for example, it is possible to override the mime
type used in an XHR and request a custom charset encoding
by using the method:
Using the XHR object with this override allows the ghost to
The rest of the ghost code is straightforward: it is used to
decode the XHR custom encoding (line 4), re-encode the file
in base64 (line 5), post it (line 6) in the iframe, and reload
the interface to exfiltrate the next photo.
The last problem we had to deal with was the reload
timer used in the photo frame: every 500 ms the page was
reloaded. Of course this behavior was breaking the ghost
activity so a part of the ghost is used to override the time-out value with a huge number and when the photo is exfiltrated the reload method is explicitly called by the ghost.
In this way the ghost is able to transparently accommodate any upload speed.
4. 2. The ghost in the P2P client
Recall from Section 3. 2 that some devices have an
embedded P2P client. Besides being an XCS injection
vector, this client can be abused by a reverse XCS to seed
illegal data and exfiltrate data. The idea behind the attack
is as follows: the attacker, who has control over the Web
interface, uses it to insert torrents that he wants the NAS
to seed for him.
This can have two purposes: on the one hand he can use
the NAS capacity and the user bandwidth to seed illegal files
on his behalf. Combined with the P2P XCS approach from
Section 3. 2, this is a way to seed illegal data on a massive
scale. On the other hand, the attacker can use the P2P client
to exfiltrate NAS content through the P2P network.
The user is oblivious to the attack because, as in the
photo frame case, having full control of the page allows
the attacker to hide his malicious activity. By playing with
the CSS display attribute the attacker can mask his
malicious torrents and display only those requested by
the user. So unless the user views the page source, he will
be completely unaware of the attack. The key challenge
was to find a way to allow the ghost to control which files
need to be seeded. To achieve this, we used an externally
seeded by reading the client page and comparing it to a
list supplied by the attacker. If one file is not seeded, then
to add a torrent file. Note that again a firewall cannot pre-
vent this attack since the client is authorized to download
its own torrents.
4. 3. Bypassing cSRf defenses
Another application of reverse XCS, which is a natural
extension of previous attacks, is to use the infected page
to attack the same site using XHR or CSRF. This combination allows to bypass current CSRF defenses because they
all rely on the same origin policy in one way or another. In
other words, the same origin policy does not apply to our
attack because we use an infected page to attack other
pages within the same domain.
The two prominent defenses against CSRF2 are to verify
the HTTP header referer/origin and to use a hidden secret
token. Checking the HTTP header is useless in the context
of XCS because the request comes from the same domain.
The use of secure tokens can be defeated by sending an
XHR request to the page, reading its result and extracting
the token value to construct dynamically the form that
will be used to perform the CSRF attack. The direct conclusion of this is that any device subject to an XCS is also
subject to CSRF attacks regardless of the CSRF defense it
implements. Moreover, since the XCS injection vector is
not Web based, pure Web defense mechanisms have no
impact on XCS attacks.
5. Back To The WeB: ReSTfuL RXcS
Up to this point we have intentionally avoided direct references to product vendors. In this section, we address the
challenges posed by two specific social networking sites;
however, the problem discussed has a much wider scope.
We feel that being concrete will help illustrate the problems in each environment without having to point at any
third-party application developers.
In this section, we present RXCS vulnerabilities that
make use of the APIs provided by large social networking
Web sites. RESTful APIs are becoming the ubiquitous way to
interact with cloud services. Many popular cloud services,
including Twitter, Facebook, E-bay, Google and Flickr, offer
this kind of API.
For example, the Twitter RESTful API allows anyone to
query user profiles in XML format by issuing the following