How Zombie Phones Could Create a Gigantic, Mobile Botnet – All Thanks to Epub3

506027963_2699090c81[1]There's an article in the National Journal yesterday that caught my eye. It covers a new report on mobile botnets, and who your smartphone is potentially at risk:

You've heard of the "botnet"—a collection of enslaved, malware-infested computers that act together to pump out spam and DDoS attacks, often unbeknownst to their owners. For the past decade, botnets have mostly been a problem for the PC world. But, according to a new report on mobile malware, it may not be long before we start seeing botnets built out of an increasingly sophisticated type of device: cell phones.

"It's only a matter of time before that's pervasive," said Karim Toubba, a vice president at Juniper Networks, the publisher of the study.

Whoever wrote the article is rather uninformed; computer security companies have been documenting mobile botnets for years (Google). In fact, back in January Symantec blogged about a mobile botnet that they thought was the largest in China:

In February 2012, we blogged about Android.Bmaster (a.k.a. Rootstrap), which infected hundreds of thousands of devices. At that time, it was the largest mobile botnet documented to date. Recently, the Bmaster botnet has been overtaken by the newly uncovered MDK botnet. Dubbed as Android.Troj.mdk, Kingsoft believes it is hidden in more than 7,000 apps and has infected up to one million devices.

FYI: Botnets are built by malware finding and exploiting security holes on devices. You might visit an unsafe website, install an app that was corrupted, etc, and then the malware you downloaded will go to work corrupting your device.

So what's the ebook angle?

One of the security holes that malware developers try to exploit is JavaScript, which happens to be supported in Epub3. Right now it is unlikely that you will encounter an Epub3 ebook that you need to worry about, but that could change in the future.

I myself have only recently woken up to the fact that the Epub3 spec includes a massive security hole, and as part of my efforts to raise awareness of this issue I asked Baldur Bjarnason to spin out a plausible scenario in which your smartphone could be hacked:

S works as an assistant in a large office in Oxford. With rental prices in Oxford being has high as they are, S has to commute in on the train every day. Living in Oxford proper is just too expensive on that salary, especially if you're trying to save up some money.

To ease the boredom of the commute S reads ebooks. Since S is a voracious reader on a tight budget S only buys the books he already likes, after downloading from the web and reading them.

So S is a regular visitor to an ebook pirating site. S justifies this to himself by saying that his book buying budget is higher than most other's with his salary, even with the pirating and all, so he reads on the train with an easy conscience.

X is the owner of said site, which proudly boasts that it has the complete NYTimes Best Seller list available. The site now has tens of thousands of regular readers who download ebooks from it. Every one of those ebooks has a javascript packet that connects home to a control server. That control server can send arbitrary javascript to all devices connected to it whenever it needs to and the ebooks store the code using local storage.

X makes his money by leasing his network out in lots of 100 compromised devices at a time. Even though his 'user base' is relatively small in malware terms, they spend a lot of time with the ebooks open (they need to read them, remember), certainly more time than most users spend in compromised mobile phone apps on average. These are high value assets.

X's customers rent these ebook botnets to commit cybercrimes ranging from Denial of Service attacks, to compromising one of the hundreds of thousands of unsafe out of date WordPress installs that have been plaguing the internet for almost a decade. There are a lot of uses for a network of javascript virtual machines.

Given what I quoted from the Symantec blog post this scenario is not only plausible, it also has a high probability of coming true.

Should Epub3 ever become widely adopted, we're going to read stories about security researchers finding security holes in reading apps. If we're really unlucky we're going to read stories about security researchers finding malware that exploits the security holes.

It's going to be messy, it's going to be public, and it's going to be professionally embarrassing to everyone who thought adding Javascript to Epub3 was a good idea.

Fortunately it is also, to a limited degree, preventable.

The best way to prevent this impending disaster would be to not add JavaScript to the Epub3 spec, but that pooch has already been screwed.  So all we have left are changing developer behavior and changing user behavior.

Good luck with that. As you can see from the current state of the computer security industry, at best that will minimize the problem, not eliminate it.

The best option, IMO, is to add Epub3 to your personal avoidance list. I don't visit unsafe website; I try to avoid unsafe downloads, and from here on out I plan to be cautious about installing Epub3 reading apps and downloading Epub3 ebooks.

P.S. Luckily for me there's not much of a reason to adopt the format. Virtually all of the ebooks I read can be displayed using Epub 2.x, which might explain why Epub3 adoption is lagging so.

In fact, the developers of Calibre (best free ebook conversion software) and Sigil (best free Epub creation software) see no reason to add support for the format. John Schember, the developer of Sigil, has told me that "As of right now EPUB 3 is not a priority." Kovid Goyal, the developer of Calibre, was more eloquent about the topic:

And currently, epub 3 has no compelling feature that does not work if you are willing to generate non-standards compliant epub 2, which by the way the O'Reilly backwards compliant epub 3 files will be, i.e. non-epub2 standards compliant. O'Reilly wont care since they don't have to publish their files with various distributors that insist on epubcheck 1.x.

With luck, Epub3 might never be widely adopted. But I would not guarantee that.

P.P.S. I ran this post by Baldur, and he suggested that I add a couple footnotes:

  • iBooks' safeguards (i.e. no network, no storage, no fun), in my opinion, very effectively counter most of the security issues with javascript in ebooks. Unfortunately, they also pretty effectively undermine most, if not all, use cases people have proposed for javascript in ebooks.
  • We still don't know what the defaults will be for Readium SDK, which in turn will probably decide the defaults for EPUB3 support for a *lot* of future ereading apps. If the SDK disables javascript by default or blocks network and storage by default, then the risk is lessened dramatically.

image by jeffedoe

About Nate Hoffelder (11581 Articles)
Nate Hoffelder is the founder and editor of The Digital Reader:"I've been into reading ebooks since forever, but I only got my first ereader in July 2007. Everything quickly spiraled out of control from there. Before I started this blog in January 2010 I covered ebooks, ebook readers, and digital publishing for about 2 years as a part of MobileRead Forums. It's a great community, and being a member is a joy. But I thought I could make something out of how I covered the news for MobileRead, so I started this blog."

24 Comments on How Zombie Phones Could Create a Gigantic, Mobile Botnet – All Thanks to Epub3

  1. A badly-behaved EPUB3 file isn’t limited to coming from pirating sites. They could come from well-established sites, a la Sony Rootkit fiasco. That’s a worst scenario than a pirating site.

  2. Nate, I’m sad to read such an alarmist and misinformation-filled post. It’s true that as digital publications become rich and interactive that will inherently create security and trust issues comparable to websites. So why exactly is that a zombie apocalypse?? Your site is serving me ads – do you know where all of them came from and have you verified that no servers hosting and delivering them have been compromised? In practice in addition to avoiding “dodgy” websites, we all rely on the browser vendors to deliver secure systems. There are breaches but they are promptly patched and open source browsers get security scrutiny from researchers all over the world. EPUB 3 by building on HTML5 and the rest of the Open Web Platform inherits the security model and regime of the browser. In general digital publications will have more scrutiny than arbitrary websites since as you note most retailers perform content validation en route to distribution, and IMO be far less likely in practice to be vectors for malware than websites and infected apps. And in practice non-browser-engine based reading systems written from scratch are far more likely to be vectors for malware b/c their engines will not have been subject to hardening and scrutiny, and most attacks exploit bugs that allow native code execution that have nothing to do with remote data sending or fetching. Consider for example the many Adobe Reader security breaches, few of which have anything to do with remote data access. And can you really argue that PDF is “safer” than EPUB 3 given all these breaches? No way – it’s actually less safe – the main reason Mozilla developed PDF.js was to make sure that PDF didn’t expand the net “attack surface” for malware beyond the core browser engine that’s already there by default. EPUB 3 takes the same approach in aligning with the Web Platform.

    The alternative of leaving digital publications static disconnected artifacts wouldn’t make any sense – whether it’s a digital magazine or an enhanced e-textbook, interactivity is a critical requirement and that includes the abilty to send and receive data. There are already a number of commercially available EPUB 3 reading systems that support remote data access, including Kobo Reader and VitalSource Bookshelf, and so the Readium SDK project will certainly support that model, with appropriate sandboxing per the Web security omain model.

    Also, Baldur apparently doesn’t understand how malware works. How much user time is spent in the propagating vector (whether it be app, website, or ebook) doesn’t really matter b/c once the malware has employed that vector (typically almost instantaneously) to infect its new host it has no further use for it, the malware execution is an entirely separate rogue process in that host. So whether eBook readers spend more or less time in a given execution context than website visitors or app users isn’t really relevant (although since interactivity in an eBook is typically sandboxed in an iframe and only active on a specific page, he may well also be wrong in his assumption that more attack time is available with eBooks).

    • Bill, your comment here amounts to little more than FUD, but I am going to let you get away with attacking me and trying to obfuscate the issue – this time.

      But I am not going to address your arguments because they are equal parts straw men, irelevant, and FUD.

      All I will say is that if stating facts while raising a valid concern in a calm and level tone is “alarmist and misinformation-filled” then there is no reason for me to debate you.

  3. I’m sorry Nate, clearly “How Zombie Phones Could Create a Gigantic, Mobile Botnet – All Thanks to Epub3” is a calm, level toned and fact-filled headline. As were your subsequent statements like “that pooch has already been screwed”, “it’s going to be messy” and “impending disaster”.

    So I don’t know what I was thinking in attempting a fact-based discussion of the (real) issues in security of interactive digital publications.

    And clearly there’s no reason for you to debate whether EPUB 3 is any less secure than PDF in Adobe Reader or HTML in the browser since that doesn’t seem to matter to your (oops I almost said alarmist again) agenda. An agenda very well aligned with those like Amazon who would prefer that digital publications remain crippled and under control of their proprietary reading systems.

    • One, if you had clicked the link you would have seen that the title of the post was copied from the original article with a small addition.

      Two, thank you for once again conceding that Epub3 is not secure:

      “whether EPUB 3 is any less secure than PDF in Adobe Reader or HTML in the browser”

      You made the same argument in your earlier comment, only not in such a succinctness form. Thank you for agreeing that Epub3 is as insecure as websites. That is what I said all along.

      And three, I did warn you. Good-bye now.

      • Nate the troll looking for hits.
        Give it up sparky and give up all your infested windoz devices while you’re at it.
        And don’t forget to get the hyper disinfectant for home and gloves too. Don’t touch that dial, it’s infested!
        It’s a war against germs Nate and you’re the 4 star general.
        Good luck and good riddance.

  4. Even if EPUB3 is turned off by default, it is only going to take one book that pops up a “This eBook requires EPUB3 (or JavaScript or ‘Enhanced Display[tm]’), do you want to enable it?” box to enable it. Who’s going to remember (or even know) to turn it off.

    • “it is only going to take one book that pops up a “This eBook requires EPUB3 (or JavaScript or ‘Enhanced Display[tm]‘), do you want to enable it?” box to enable it.”

      Well, no. That box will never pop up on Amazon, Apple, or B&N platforms in the first place, because none of them are ever going to support the EPUB3 spec as it was written. Not going to happen.

  5. Welcome to the fight against Javascript Part X.
    Never mind that Mr Nate is loading your computer’s tummy with many scripts:
    /* (c) 2008-2012 AddThis, Inc */
    var addthis_conf={ver:300};if(!((window._atc||{}).ver)){var _atd=”www.addthis.com/”,_atr=window.addthis_cdn||”//s7.addthis.com/”,_atrc=”//c.copyth.is/”,_euc=encodeURIComponent,_duc=decodeURIComponent,_atc=
    };

  6. LOL, that’s not a logical discussion. More like something I’d say to a toddler.
    Perhaps you should turn it around and consider just how much javascript you have on your page, from where it’s sourced, it’s reliability and security and then project your experiences onto how javascript in much much smaller doses would effect the performance and security in an epub3 document.

    • Actually, you’re wrong. Yes, Javascript has turned more secure recently, but in web browsers. There’s no guarantee that ePub3 Readers will use a secure HTML/JS engine, will take steps to further secure their apps, or that End Users will update their apps with the latest security fixes. Hell, on the last point, it’s hard to get End Users to update their base systems.

      It’s better to err on the side of caution than spend 10 years trying to fix all the bad decisions.

  7. So you’re saying if I use Apple’s multi-platform ibook or an Apple app store approved app I am at risk!

    Like hell I would be…

    • Maybe you should finish reading the post before commenting.

      First, Apple has placed restrictions on iBooks that lessens the risk, a detail that is mentioned in the postscript. And second, a few iOS apps have been found to have malware, yes.

  8. While you’ve proposed a possible DDoS attack vector from within an EPUB, it’s arguably one of the sillier attack vectors. Why would a hacker go to all the trouble you suggest to create a perpetually unreliable number of infected books from which to launch an attack? Especially when that attack vector is so easily undermined? I personally find Apple’s approach overly restrictive, but it’s their right. I’d rather see reading systems simply inform the reader that the book is attempting to access remote resources, and to authenticate the traffic. If that message comes up from your pirated ebook, how likely would you be to allow access?

    But as Bill pointed out to you, the goal of most malware is to get into the OS and from there do real damage (the rapidity of professional malware attacks). The holes are typically in the OS and are plugged from the OS, and the boxed nature of JavaScript make it a poor doorway to get at them. JavaScript attacks usually take the form of directing you to an infected program, or resource in some more compromisable format. But again, if your pirated ebooks suddenly tries to launch an external application, what is you first reaction going to be? If it’s to see what the program/document is, you probably deserve what you get for pirating content.

    But this FUD article about scripting also doesn’t acknowledge how easy it is to social engineer people into doing dumb things regardless of the format. Do you really think it’s hard to inject static links to malware into any ebook? From a social engineering standpoint, aren’t you more likely to trust a link that appears to have been inserted by the author than a random scripted action that attempts to launch itself? If you’re looking for maximum damage, why wouldn’t you exploit the simplest mechanisms with the broadest support across all ebook formats, rather than the more complex ones that are more rigorously scrutinized?

    You also claim that EPUB 2 is more secure than EPUB 3 by virtue of not having scripting, but with HTML5 comes native audio and video support so EPUB 3 doesn’t have the much bigger security hole, in my opinion, that Flash represented thanks to ADE. But hey, even images have been known to carry exploits, so why stop at javascript and flash. Let’s reduce ebooks to plain text, because that’s exactly what publishers and readers wants is some nice Courier New text to read.

    Anyone who claims any technology can’t be exploited is generally a fool, but there are more “if”s in this article than facts.

    • “While you’ve proposed a possible DDoS attack vector from within an EPUB, it’s arguably one of the sillier attack vectors. Why would a hacker go to all the trouble you suggest to create a perpetually unreliable number of infected books from which to launch an attack? Especially when that attack vector is so easily undermined?”

      Nonsense and more nonsense.

      This blog is under attack by a couple botnets at the moment and has been a target for the past month. The level of attack varies based on how many computers are online, and far fewer are needed to achieve DDOS than you might think.

      “But this FUD article about scripting also doesn’t acknowledge how easy it is to social engineer people into doing dumb things regardless of the format. Do you really think it’s hard to inject static links to malware into any ebook? From a social engineering standpoint, aren’t you more likely to trust a link that appears to have been inserted by the author than a random scripted action that attempts to launch itself?”

      So in your opinion worrying about scripting is FUD because social engineering is also a possible vector for malware? Nonsense.

      BTW, had you read my previous post you would have noticed that I advocated taking a more general security conscious position on Epub3. I say it needs to be treated like websites and web browsers, with similar security cautions applied.

      “You also claim that EPUB 2 is more secure than EPUB 3 by virtue of not having scripting”

      No I did not say that, but it is true nonetheless.

      “but with HTML5 comes native audio and video support so EPUB 3 doesn’t have the much bigger security hole, in my opinion, that Flash represented thanks to ADE”

      One, I don’t use ADE for much and the Flash support is used so rarely that I can count on one hand all of the times I have seen it. So its Flash is not a serious concern.

      And two, audio and video in Epub 2 is the exception and not the rule. Scripting could end up being the rule in Epub3, not the exception, and that would make it a more serious problem.

    • “Do you really think it’s hard to inject static links to malware into any ebook?”

      If the reader doesn’t support Javascript or other executable code?

      Yeah, it’s pretty damned hard.

      • Missed this part:
        “in my opinion, that Flash represented thanks to ADE.”

        My ebook reader doesn’t run Flash, either, and I don’t have any Adobe crapware books.

        I’m not actually sure what your point is here.

      • The premise started was distributing ebooks that have been manipulated to include javascript. If you’re going to process an ebook to insert code, it’s just as easy to insert random links, as suggested. Funny how that’s not hard at all, ain’t it?

        What’s with the weird cult of luddites and “what works on my reading system” on this site, tho? If you guys start an argument, you can’t navel gaze and cherry pick your comments.

        • And exactly what are those “random links” going to do if the platform doesn’t execute any scripts that it finds there?

          Oh, right: nothing.

          You don’t actually know what you’re talking about, do you?

          • Maybe I’d better break it down for you a little bit more.

            1) Bad guy creates a web site that contains nasty malware that executes when the page is loaded.
            2) Good guy has a reader that doesn’t execute embedded code.
            3) Bad guy puts a link in his ebook.
            4) Good guy follows the link with the ereader that DOES NOT EXECUTE EMBEDDED CODE.
            5) What happens? Nothing.

            Is that clear enough for you?

1 Trackbacks & Pingbacks

  1. Reading Ebooks on Your Smartphone | Musings and Marvels

Leave a comment

Your email address will not be published.


*