What would Dick Tracy do?: A review of OpenGarages' "Car Hacker's Handbook"

Dick Tracy, the great comic strip detective, is known for having great gadgets like his 2-way radio/computer wristwatch.  Though a wrist mounted walkie-talkie or smartphone is no longer the height of technology and it's easy to think that law enforcement often lags behind, that's not always the case.

As modern day agencies work with their local High Tech Crime Investigators Associations(HTCIA), Dick Tracy has also kept up to date with criminal uses of tech.  In fact in late 1989-early 1990, detective Tracy had a story arc that covered criminals using attacks on HVAC systems, automotive computer systems, logic bombs and a video game to commit data theft/destruction and real life murder. Dick Tracy went to various subject matter experts(SMEs) to become qualified on the new technology law enforcement faced.

In order to solve a difficult case Dick Tracy approaches subject matter experts on car computer systems. 

In the course of the story Dick Tracy sees a bunch of murders that could only have been committed via the use of computerized systems, a hallmark of one of his villains Memory Banks. Poor Memory had passed away and so he was in the clear. Or one would think. It turned out that Memory had a neural network "clone" of himself and had partnered with his sister Data Banks to take revenge on his enemies. They kill off one criminal colleague by setting off the sprinklers with scalding hot water in his apartment, driving him screaming into an elevator shaft.

Walter "Worm" Wendell tried testifying against his employers. They didn't think that was a good idea.

Memory's widow and her new lover are killed when their car unintentionally accelerates and they drive off a cliff.

Memory's wife Diane Dreeg and lawyer/lover Al Lemoni. 

In the end Dick Tracy faces off in a life and death battle with the AI version of Memory Banks. Most law enforcement and others involved in Information Security do not need to go that far to track down high tech criminals. Faced with newer technology like the Internet of Things or Automotive telematics systems, what would Dick Tracy do? If he needed to get up to speed on the embedded systems that run today's late model cars, a good start would be picking up a copy of the Car Hacker's Handbook.

OpenGarages' Car Hacker's Handbook

The Car Hacker's Handbook by Craig Smith is a short(about 70 page) tome. Hacking on cars is sort of like wizardry and OpenGarage's Car Hacker's Handbook is a spellbook; in the right hands it opens doors, in the wrong or untrained hands it simply raises more questions.

While ostensibly the Car Hacker's Handbook is targeted at novices in information security or embedded systems reverse engineering, much could be missed. It can feel sometime more like a conversation with the author than a full reverse engineering manual. I'm not discounting this method of instruction as I've had numerous such conversations with presenters at security conferences and they can be quite enlightening. Those discussions usually count on both parties having a shared knowledge base. A quick primer on software and firmware reverse engineering and network security would help unlock a good number of the nuggets in this slim volume.

Hacking and modifying an Infotainment system
A short chapter in the first third of the book provides nearly all the information one would need to investigate a Microsoft Auto/Windows Embedded(CE 7?) based interface. Having written a few short pamphlets to train others on reverse engineering embedded systems, I can see all the milestones Smith was aiming for, though the end result is still obscured. In a short four pages he passes over the following procedures

• identifying OS, firmware and executable versions
• locating/identifying update mechanism update files
• analyze/bypass simple file checksums
• extracting/analyzing/modifying firmware
• acquiring manufacturer SDKs

Not every step is explained and not every tool is introduced, yet there is enough for the experienced Reverse Engineer to follow in Smith's footsteps.

Where do I catch the CANBus?
The heart of the handbook introduces the reader to the various communication systems within a modern automobile before settling on discussing the CAN Bus. This is the most common bus over which messages travel between the components(e.g ECU, Radio, Tire Pressure Monitor, other sensors) of one's car.

The various interfaces to the ODB II ports(and thence on to the CAN Bus) one would find are detailed with wiring diagrams. From a hobbyist perspective or at least for a researcher with a limited budget, the book's concentration on open source software and hardware is quite appealing. Commercial rigs are eschewed over building one's own Engine Control Unit(ECU) workbench from recovered units in the junkyard.  The book includes links to a good collection of open source CANBus monitoring software

Other researchers, such as Charlie Miller & Chris Valasek[2], have investigated the effects of sending crafted CAN packets to unlock doors, control the speed displayed and turn the wheel. Building off research like theirs, the Car Hacker's Handbook walks through intercepting packets with a sniffer(as with WireShark on the PC). It also provides a nice methodology, utilizing a binary search to locate the packet of interest. The practical example is covered in a chapter targeting the Tire Pressure Monitoring System(TPMS).

The CAN Bus section eventually concludes with a humorous( likely unintentional) troubleshooting list when one performs their experiments. Pro tip: Know where your car's fuses are located.

Hotwiring - No really, like in the movies
While the handbook is not a criminal guide it does contain historical information on security bypass methods. There are short chapters covering "hotwiring" cars and cracking keypad combinations. Admittedly only ever having seen hotwiring on film or TV, this was a most enjoyable and archaic chapter.

As newer security features have obsoleted the technique, Smith covers how researchers can investigate modern security(keyfobs and immobilizers).  The Handbook covers a number of potential attacks on Immobilizers without going over specific implementations of the attacks. The author assumes you know what an SDR is and what software one needs. Like with a Wizard, if you can't figure out the tools and components for a particular spell, you shouldn't be messing with it.

What's all this about "spells"?
There is a short sequence in the book on "weaponizing" exploits, implemented as the creation of a particular Metasploit module. If that last sentence made no sense to you, then the Car Hacker's Handbook will not turn you into a criminal hacker.

Exploits are like spells. Spells can be used for good and bad. They also require a lot of research to create.  The Handbook provides a methodology(or actually a modification) for discovering vulnerabilities in automotive control systems.

The handbook is not yet an all in one resource for auto security nor is it a step by step guide. Eventually it may become so, or even better it will become a comprehensive introduction with links to further resources.

In the end the Car Hacker's Handbook definitely sends one in the right direction to hack on one own's car but it is still not an introduction on exploit development. It really is a Wizard's manual; if one already has the capability to "spellcast"(write exploits) on PCs, the Handbook will fill in a number of holes in your knowledge base.

The content of the book is available electronically for free, though one can purchase a physical copy at:

Amazon.com(paperback)
Barnes & Noble(paperback or ebook)
Google Play(ebook)

What would Dick Tracy Do?
Knowing where to look can sometimes be as useful as what to look for; the Handbook and the related OpenGarages wiki provide that direction. Dick Tracy knew it decades ago; when getting up to speed on a newer field, save time by going to the experts.

---

[1] A friend, Security Researcher Julia Wolf, recounted the ransomware or more specifically the logic bomb aspect of the Dick tracy storyline. Unfortunately her original copies of the comic strips were lost over the years. Tracking down copies of the comic strips was truly an adventure and enlightening on user education techniques from decades previous.

[2] Their research is referenced on the OpenGarages wiki. Miller and Valasek have also presented at the Def Con conference.

"Things have their own Internet?" - A look at the Internet of Things

The Internet of Things is not as complex as one would think. Smart Objects(e.g. Power meters, Fridge computers, etc.) or "Things" don't have their own Internet, instead they "speak" to each other over the same Internet we all use. There lies their vulnerability. Assuming that since the machines will only talk to each other, that no one will eavesdrop or intrude on their conversation. Security researchers have a saying, "Security through Obscurity is no Security".

In the past if a Utility(like electric or water) were manufacturing a network of power or water meters each meter would not just be connected to an individual house, they would also be wired to each other. Now that we are able to connect computers efficiently via radio frequencies(i.e through WiFi) we can cut these wires between each Smart meter. The advantage of the wired network for the Utility was that the communication would not be tampered with unless an attacker physically tapped into the wires. An attack that would be very noticeable. As such an attack was rare the Utility could make the risk assessment that says encryption was unnecessary on the network. Essentially since the machine(power meter) was talking to a machine(Electric company server) why add "useless" security measures?

Machine to machine(M2M) communication is actually a service offered by Mobile Phone Carriers. In M2M, a Smart "Thing" gets its own SIM card or mobile phone account so that it can talk back to its server over a mobile phone network. The most common system using M2M one might see would be the telematics system in their car(e.g. GM OnStar, Chevrolet MyLink). While these systems which turn your car into a Smart "Thing" have better security than the majority of other "Things", they still have vulnerabilities and have faced scrutiny from security researchers[CAESS, Bailey/Solnick, Valasek/Miller].

How do Attackers look at the Internet of Things(IoT)?
M2M and the Internet of Things are not as well documented as desktop PCs or Mobile phones.  Any device(e.g. Smart watches, Smart fitness sensors, etc.) that connects to the Internet is open to interest from attackers. One's data has value and Smart sensors collect a large amount of personal data, more than enough to attract attackers out to make money by using or reselling that data.

An attacker looking at a target "Thing" would need to perform reconnaissance on a device and the network to which it belongs.  In the case of a power meter, they would acquire a meter(legally through surplus sales, or illegally through theft). Legitimate security researchers solely utilize legal means, perhaps photographing markings, stickers and anything visible on a meter in the wild.

OSINT(Open Source Intelligence)
When assessing a target one of the first steps involves gathering as much research on the public facing and accessible portions. For many corporate and most government targets, one would think that all relevant information is proprietary or highly classified. It turns out that this is not the case. One can find out quite a bit from open sources. These are public and commercial databases, newspapers, trade publications, patents, etc. Some experts on covert intelligence say that up to 80% of the information they gather can be obtained from these open sources.

The attacker's next step after acquiring images of the target meter is to source information based off of any text, serial numbers or other information. Google is useful for using these details to get pointers to even more detail.

The meter may consist of or be entirely patented. While a patent prevents competitors from selling one's technology,  that security is in exchange for providing a method to replicate an invention. The attacker can locate the relevant patents and find out how the meter is put together.

The attacker would also like to scan and map out the target network. A wireless meter is useless if it can't connect back to a Utility company or get any new commands. As the Smart Meter connects to the Internet, the attacker can search open records for IP addresses affiliated with the company. They may also search for publicly accessible management interfaces.

Next steps would utilize separate attacks against the components of the network; pen testing the web interface/management console, reverse engineering of the meter hardware, cryptanalysis of any encryption used in communication and more.

Theoretically these are methods that an attacker or researcher would use, but it's easier to explain when there is a real target.

Solar Powered Parking Meters - An IoT thought experiment
A few years ago I and a couple of colleagues took a look at what we called "Solar Powered Parking Meters". These were a series of smart Parking Meters that had built in conspicuous solar panels. The panels were the primary source of power with battery backup.

We had been influenced by prior research[Grand] on Smart Parking meters from a different manufacturer. Those researchers had acquired parking meters second hand through eBay and never agreed to any additional licenses from the manufacturer. As the meters we were interested in were only available through the manufacturer, we consulted with Attorneys on how far we could proceed.  Per their advice, purchasing a parking meter from the manufacturer would restrict our research efforts, so we confined our efforts to researching open sources. This limited our assessment to a thought experiment(real attackers would of course not be so restricted).

A majority of the information I attained was presented to a local computer user group. The slides are available on Slideshare.

Simply through particular Google searches, I was able to source:

• profits made per meter
• name of senior engineers
• information on how the meters process Credit Cards transactions(PCI compliant?)
• how Coins are collected
• the type of information stored on the meters(e.g. private, financial, etc.)
• mockups of the parking meter management console
• likely provider of the M2M SIM cards

All that was obtained via news articles, patents, brochures, and searches of the manufacturer's site.  Nothing anyone would consider secret or even "obscure".  An attacker unencumbered by laws could easily find the same information and continue on to infiltrate a target network.

Internet of Things - Sufficiently secure?

Attackers will always have an advantage on a new platform if security is not included in the production of new devices. We already do so with mobile phones and devices. It would be a mistake for us to neglect securing these new "Things". 

Mobile Spyware: Finally criminal?

Commercial Mobile Spyware apps have been around for over a decade. They've been on every platform with the best(if one can call it that) support on the most popular Operating Systems. They're usually sold as tools to help one monitor their children or keep track of a spouse or significant other. Tracking the latter groups lean toward a gray or even a black/illegal area.

The FBI has come along to the idea that folks selling spyware(or at least mobile spyware) are committing a crime. Specifically since your phone is a telecommunications device, installing spyware on it is the same as wiretapping.  Also the CEO of Invocode(producers of StealthGenie spyware) and his employees are members of a "criminal conspiracy responsible for StealthGenie".  Fortunately, the FBI arrested the CEO in Los Angeles over the weekend.

StealthGenie is a spyware app that supports iOS, Android and Blackberry OS. Blackberry support only applies to pre Blackberry 10 devices so newer devices would not be vulnerable. The capabilities of the spyware is not breaking any new ground, we've seen all of this before and in software from their competitors.

StealthGenie's hompage - The World's Most Powerful Mobile Phone Spy Software"

Intriguingly from the Government's complaint, Invocode expected that the majority of their sales of the StealthGenie mobile spyware would be to "[s]pousal cheat: Husband/Wife of boyfriend/girlfriend suspecting their other half of cheating or any other suspicious behaviour or if they just want to monitor them.".  So mainly to monitor someone else's phone without their permission.  The FBI agents purchased a copy of StealthGenie and were able to immediately monitor the calls and text messages from another of their phones.  While investigating monitoring software from competitors of Invocode, I've also seen that they perform similarly or perform additional functions.

Speaking of Invocode's competitors, they don't seem to think highly of StealthGenie:

"...simply isn't worth the money!" - advice from other criminals?

This screenshot above is from a competitor that recommends two other mobile spyware packages in addition to itself that they prefer to StealthGenie. This implies that these are three other, possibly more powerful, mobile spyware and "wiretapping"/interception tools that are still available on the app markets. I applaud the US government going after Invocode in the "first-ever criminal case concerning the advertisement and sale of a mobile device spyware app".

Due to the gray-area uses of mobile spyware, Anti-malware and Anti-Spyware companies have had to come up with classifications to keep us from stepping on possibly legal  developers of spyware. This is mainly to avoid being sued for being anti-competitive or harming the business of legitimate monitoring software developers. It would certainly ease matters now that governments are starting to criminally prosecute producers of tools that can be used to intercept users calls and texts.

--------------

If you're curious about the legality of selling mobile spyware, the US Government cites the following sections of law:

Title 18, United States Code,
Section 2512(l)(b) (sale of an interception device)
Section 2512(l)(c)(i) (advertisement of a known interception device)
Section 2512(l)(c)(ii) (advertising a device as an interception device)

One can read the details themselves in the Federal complaint.

My smartphone is my key: Musings on the security of Smart-padlocks

Keys can be a bother. You forget them inside the apartment, they're stuck in a pocket or bag with your arms full, or you just lose them. When I was in high school, combination locks really appealed to me: no keys to misplace, just a simple three number combination to remember. Awesome, until the first time I forgot my combination after gym class. One pair of bolt cutters and I was able to change for my next class, but I was out one fancy combination lock. Potential memory lapses(my head is full of much more today than back in high school) rendered combination locks more of a hindrance than boon.

In previous years solutions to my problems with hotel keys and my house keys have arrived, but until the recent Noke(pronounced 'No Key') Kickstarter campaign I didn't have a reasonable way to replace the keys to my padlocks. Fortunately for me, the people at FŪZ Designs have thrown physical keys and combinations out to create a smart-padlock.

Smartphones? Now, smart-padlocks.

No more forgotten combinations?
Like a door from Star Trek, just walking up to your Noke lock with your smartphone unlocks it. For some of my more efficiency-minded friends that easily saves them seconds in their day. Given that the associated lock control apps let one control the unlock distance, I'm not too worried that attackers will steal things from my locker or ride off with my bike before I've gotten to them.

One can shorten the unlock distance via the control app.

The Noke lock actually shares more with the ignition lock in a modern car than with that old combination lock on my high school locker. Like the car without a new Transponder key, the Noke can be set so that it won't open without your smartphone. Of course that would just turn your smartphone into the key; lose your phone or let it run out of power and you've lost your key.  The designers have thought of that; they include a way to unlock the Noke with a 'Quick-Click' code. That code of course being the spiritual successor to my old nemesis the 'Combination'.

The Quick-Click code is a good backup opening method when you don't have your phone.

Truthfully the Quick-Click code, utilizing the shackle(that metal U-shaped part at the top) of the lock to enter the combination, is quite brilliant. While one could say it is a cousin of the original combination on a lock, its purpose is more like that spare key you keep under the doormat or that rock in your front yard.

Almost like Morse Code, one enters a series of short and long 'clicks' of the shackle. Entering the wrong code not only delays you but doing so 5 times disables this manual unlock method. Attackers trying to brute force the combination will get shut out.

Attacks against padlocks

I have friends who practice Locksport(recreationally playing with locks they own, looking for ways to bypass or 'lockpick' them). They're the sort to be first in line to buy a Noke once they hit the market. It's exactly the sort of puzzle they'd find amusing.

I'd already learned about the simplest physical attack from the teachers cutting my padlock off with the bolt cutters in school. The Noke has a hardened shackle to defeat this sort of attack. The physical security of the Noke could be bypassed with sufficient force, but it would lead to exposure of the attacker.

My Locksport friends have shown me more elegant means, such as the easy to make soda can shim. In a standard padlock the only thing holding the shackle locked is a spring loaded bar. The shim just pushes the bar out of the way releasing the shackle.  Shouldn't lockmakers have designed better ways to prevent attackers shimming their padlocks? Traditional lockmakers have and so have the Noke's makers.  They utilize a "double ball" mechanism to prevent 'shimming'. [More on 'double ball' padlocks from Deviant Ollam's fine book on lockpicking.]

Inside a Noke - Shackle at the top, 'Double ball' to counter shimming.

Attacks against smartphone apps

I'd be remiss if I didn't consider when an attacker would go after the low hanging fruit of the mobile app. The apps(one for each platform - Android, iOS, Windows Mobile) are the major interface to the padlocks. One can lock/unlock, set unlocking distance, and manage distribution of shared keys.  They also store a history of keys used.

I once described a possible threat scenario to a colleague regarding the ability of a particular piece of spyware to compromise the location and travel patterns of C-level executives. That last history feature of the app, while it doesn't leak the GPS data or location data can still provide an attacker with hints to location and specific time ranges when their victim is alone.

The sharing/key management feature of the app is another interesting target. Stealing keys from the app or, better, generating a valid shared key would allow the attacker to simply walk by and access the victim's valuables.  Since a shared key must be generated by the app, an attacker compromising it or controlling it can craft a permanent 'skeleton key' to access/unlock the Noke.

Are we ready for Smart-padlocks?
My trouble with padlocks began decades ago. Smartphones have made my life easier, I no longer need to remember every single password to access my accounts. If my padlocks have gotten smart enough to work with my smartphone so I don't need to memorize a new combination or keep track of a physical key then I'm happy.  Of course if my padlocks get smart enough that they need an immune system(or at least Antivirus) I won't be disappointed.

Tracking Mobile Malware Groups at Google

I ran across this opportunity at Google: Analyst, Android Security
https://www.google.com/about/careers/search#!t=jo&jid=66345001&

It piques my interest as one of the stated goals of the job is "[becoming] an expert in the workings of mobile malware campaigns".  A few years ago(2011) I was able to momentarily take a step back from analyzing individual samples to take a look at the state of mobile malware and how criminals and their networks profit.

The 'Mobile App Moolah' presentation was based off a number of years of data we had amassed on malware sources(e.g. geography and authors) as well as intelligence shared between other Antivirus researchers.  My strengths lay in analyzing the samples, identifying characteristics that would hint at possible origins and apparent motives of malware authors.  Other colleagues provided insight on how malware authors and organized crime set up infrastructure(i.e. monetization methods, advertising, acquisition of targets) for  turning what used to be a hobby into profitable enterprises.

How Criminals profit from mobile malware infections

From the collection of metadata I had on in the wild samples I could see how criminals operated in two large geographical regions; for ease of reference, Russian and Chinese speaking regions.  Based off of the code we were seeing the Russian zone employed simpler(though still highly successful) attacks and the Chinese zone using complex and multistage attacks.

I still had only half the picture. I could see the tactics used against victims on their smartphones, but the shared intelligence on crime networks filled in the rest. With Russian SMS sending trojans the profit turned on having easy access to vendors that provided relatively anonymous Premium Rate SMS short codes("Text 'Ring' to 12345 for the latest ringtones"). The ability to acquire a short code quickly and run a campaign(paid for by unaware victims through mobile billing) made it difficult for the perpetrators to get caught while still earning a return on their investment in developing the malware.

The Chinese attacks were complex with anti-evasion and encrypted Command and Control(C&C) channels, due mainly to competition. Competition equally from Security/Antivirus vendors and from rival organized crime. While one could easily steal 1 Yuan from a million victims and net a profit, keeping your enemies from hijacking your mobile botnet still requires a larger R&D investment(e.g. code protection, encryption, etc). The back end, or how the criminals profited also varied. Personally Identifiable Information(PII) and various chat accounts with associated wallets provided alternate streams of income versus Premium Rate SMS fraud.  Organized crime provided multiple service providers to facilitate the passage of virtual funds(QQ coins) to physical/electronic money. Resellers and fences add value to stolen data(social network accounts, credit card numbers).

This Google position appeals as they have access to a significantly larger pool of data on both malware developers and sources for malware. The first step to having victims find your new mobile malware tends to involve Google(i.e. the Play store, Google ads, getting indexed by Google, etc.). Never mind that the Android Security Team receives intelligence, samples and Proof of Concepts from researchers and the public. Whoever eventually gets the role will get some amazing insight into the Android malware underground.
----------------------

If one is interested, a video of the 'Mobile Moolah Presentation' and the slides are available. The geographic portion starts at 4:17, the 'How they profit' portion starts at 6:27.

On the Mobile Malware Lifecycle

A number of factors drive malware on new platforms. The chance for pure discovery and experimentation, the desire to be the first, a need to make an income. Truthfully these are the same reasons that drive legitimate software development. This is no surprise as malware development is a form of software development.

The accelerated pace of new platforms entering the market also accounts for a rise in malware. This also leads to a shorter lifecycle for malware and malware development. The current lifecycle, bolstered by more means of revenue generation(ads, in-app purchasing, premium services, etc.), now results in malware chasing a user's money rather than their computer resources.

The mobile malware lifecycle can be seen below:

Stage 1: R&D
The initial stage is the Research and Development stage. Here due to the similarity of legitimate and malicious software development the processes followed are the same. A developer will acquire an SDK(Software Development Kit), other development tools, and as much documentation as they can find. After an initial 'Hello World" program is written, the developer will attempt to recreate functionality on the new platform that existed on a previous one. In the case of Android, one would attempt to launch a web browser with http://www.google.com; similar to how they were able to on Windows Mobile. A malware author skilled in developing worms, trojan horses and viruses will figure out ways to achieve the same with the new SDK.

This first stage is about the exploration of new capabilities and for acquiring knowledge. As with legitimate development, this is where malware authors also share their hard won knowledge with others. Unlike previous generations though, the need for revenue will sometimes encourage the authors to move straight to the Profit-Taking stage.

Stage 2: Reuse
Generally after the first stage is passed, a move is made to evade detection. On the most basic level, where script kiddies and under-skilled malware developers lay, evasion takes the form of simple cosmetic changes(strings, colors, filenames, etc.).  This can lead to a flood of very similar variants where only the message displayed to the user is altered("You are hacked by: Skr1pt K1dd1e!").

The Resue stage can benefit from source code developed and released during the R&D stage. One of the first mobile worms, SymbOS/Cabir, had its source released by its author in the computer virus zine 29A. Though this was a release of the worm's original source code it did not result in as many modified variants as would be expected. This was due to the timing of its release and a separate,earlier reverse engineering of the source code by developer Marcos Velasco. Malware developers were able to take the Velasco code and once again through primarily cosmetic changes, recompile and create dozens of Cabir-like variants,

In some cases, as with legitimate developers, malware authors may take the source code as a starting point or example for implementing new functionality for their own productions. As with the R & D stage, the Reuse stage can be affected by the monetary needs of malware authors. Instead of producing new variants, simply adding fucntionality that steals money from users(e.g. Premium Rate SMS, unauthorized in-app purchases,stealing bank account information, etc.) may be the priority for malware authors.

Stage 3: Profit-Taking
The Profit-Taking stage is the most mature stage and can lead to the most interesting(at least for malware analysts and reverse engineers) malware. Evasion of anti-virus/anti-malware software is still a priority but it's also more necessary for other opponents. As methods of earning revenue from victims increases, infected devices become more valuable. On prior Operating Systems a malware author only needed to defeat the Anti-Virus software to survive in the ecosystem. Now if a malware author is successful in running a botnet, they now face competition and attack from other malware authors and organized crime.

This stage has its low hanging fruit in the malware that sends out Premium Rate SMS. These trojans are simple and guarantee a smaller amunt of money to the attacker. Evasion here involves encrypting the SMS numbers and shortcodes from Antimalware software.

More complex attacks involving botnet infections that can deliver false ad-clicks(draining a competitor's ad budget) or fake reveiws(driving up installs for a client's buggy app) make tempting targets. An opponent can take over the command channel of a botnet from the botmaster and redirect the adclicks or re-transfer stolen money.

This competition then leads malware authors to invest funds in countering competition and Antivirus/Antimalware. Profits drive research into new evasion techniques and offensive capabilities(e.g. removing/deleting Antimalware from a device). It also drives attackers to investigate new platforms, which starts the malware lifecycle all over again.

Adding more bounce to Bouncer

It's said that one shouldn't complain about something unless one is prepared to/or ready to provide solutions. In the case of Google's Bouncer a number of security researchers have performed analyses of the defensive system and figured out where the weaknesses lie. Attackers can take advantage of discoveries like this, but usually one expects that the software publisher will try to fix these vulnerabilities.  In some cases this can be difficult, where the problem is just too difficult with current methods. when that happens one would need to develop new techniques to solve these existing problems. This week two groups of researchers have done just that, publishing their research on detecting Android threats. Both solutions would require changes(for the better) to Bouncer and Android.


(One way to) keep Flappy Bird from taking complete control over your phone: Finding Root Exploits

A common method to get users to install malicious code and malware is to exploit recent news or tragedies. In the days after the Flappy Bird developer pulled the game from the app stores, there was a demand for the original or at least a good replacement. Attackers took advantage of this and produced malware that pretended to be Flappy Bird but actually contained malicious code. These were all swiftly detected by anti-malware software, but there is sometimes a window through which the bad guys can slip through. If an attacker had decided to use a root exploit, rather than just make money from sending Premium Rate SMS, they could have gotten or expanded a botnet.

Detecting such root exploits before or as you install is the first layer of defense, but there hasn't been a way to handle them once they're already on the device. Preventing the exploits from effectively functioning or failing on device would make a good second layer.  A group of researchers from North Carolina State University have come up with PREC(Practical Root Exploit Containment) as this second layer of protection. 

Attackers include root exploits in legitimate apps to take over your devices.

Credit: Flickr user greyweed licensed under Creative Commons Attribution

PREC uses profiles of normal behavior to judge if an app is "breaking" the rules.  A malicious app under Bouncer would run for an relatively long period(5-10 minutes) before executing any malicious functions. The emulation stage would time out and give a passing score to the app, while on a real device the malware could run unimpeded. The PREC system would use that emulator run to create a profile of what the app should do, including what native code is called.

These profiles would be downloaded to a user's phone or tablet when they install from the app store. A PREC client or system library would then use the profile to see if the app is sticking to the contract. An app will start running and then all calls to native code will result in that code running in a monitored thread. If it looks like the native code using a rarely used sequence(e.g. calling a root exploit binary vs. calling a game library) the system will implement a delay in the thread. The delay is increased in suspicious calls(native code that has not been or very rarely executed during the profile stage) which effectively creates a tarpit, eventually causing the exploits to fail.

The overhead from PREC is relatively low and appears to be very effective against root exploits. Since it's a behavioral method of detection, false positives can be an issue. As PREC only looks at calls to native code that isn't called very often the risk of detecting a legitimate app is quite low.

Verifying dynamically loaded code
Root exploits aren't the only native code to worry about on Android. An app can dynamically load native code and Android does not verify it. There are a number of native binaries and code that are used legitimately to speed up execution or gain access to hardware(e.g. accelerated graphics).

Researchers with iSecLab have developed methods to determine if dynamically loaded code is legitimate. Their solution offers a different way of solving the problem of unsigned code.

Android is a very open OS, similar in some way to MS-DOS. DOS due to its openness had quite a bit of malware, but its openness also allowed for the creation and addition of antivirus and other security software. Overall being open allowed thrid party developers to increase the overall safety of the DOS ecosystem. Android gives us the same opportunity.

The iSecLab answer is to provide verification or whitelisting of apps on a device. A trusted verifier or server will provide a hash for an application that passes its checks. Since Android is very open there would not be a single central server, instead users and enterprises could choose the verification servers that they trust.

Users would download a whitelist from a verification server or servers. Any loaded native code will be checked against these whitelists and unknown code would never run. Developers would just need to submit their native code files to various trusted servers


Bulking up the Bouncer
When it was first put into production Bouncer was quite effective, especially since it was a server side protection making its code harder to get to than locally stored files.. Other security researchers have shown that this is only a roadblock and not an impassable barrier.

Now that attackers have an idea what the original limitations of Bouncer were, they have developed methods to bypass detection. The methods presented by these two groups of researchers give us viable means to counter the threat posed by malware authors.  Android will need to be modified on the OS level to support these methods but that is a small price to pay for increasing the overall security of the ecosystem.

On Mobile Malware counts, detections, and similarly confused creatures

There was a fascinating article about "10 million" malicious Android apps today in The Inquirer. That certainly sounds like a large number of Android malware.  Especially with the Google Play store only having a bit more than a million apps. The good thing is that these are actually only unique infected apps(APKs), with a good portion infected by the same family or variant of a given malware(malware families consisting of multiple variants). Reading further, Kaspersky counts about 150,000 unique malware variants, an order of magnitude smaller. Still a lot of malware but not nearly as frightening. Do malware detections fluctuate that much? No they don't, in this case it's due to looking at the same threats from different viewpoints.

Polymorphic malware?
On Android, there are currently no file infecting viruses. These are the traditional viruses that infect legitimate programs. Run them and every program on your disk is infected. Over time file infectors , in order to avoid detection, modified or uniquely encrypted their code upon each infection leading to thousands of slightly different and unique samples. We refer to these varying, differently "shaped" samples as polymorphic viruses: one virus, many forms.  Antivirus firms learned to counter this, to see the underlying original code of the viruses and to detect them.

With Android most malware are Trojan Horse programs("trojans"), single apps that pretend to be legitimate but are really malicious. As each trojan is an individual threat, it would have a single detection. This explains the 150K number, but where do Kaspersky and other antivirus firms come up with these larger numbers in the millions?

That goes back to the tricks used by file infecting viruses and something that's more common today in PC malware: server-side polymorphism.

Crimeware(Zeus/Spyeye, Carberp, etc.) on the PC faces the threat of detection. If their component malware are detected they don't infect users, and they don't steal from user's bank accounts. Antivirus/antimalware companies are good about tracking down and detecting new samples of crimeware. Collect as many samples as possible and create an all encompassing detection. Crimeware authors try to counter this by only delivering one copy of their malware to one visitor/IP address. They also modify or encrypt the downloaded code, just like older viruses.

These millions of unique Android APKs come from the same sort of technique. The malware authors distribute a unique sample to each visitor/IP address. They also make minor almost cosmetic changes to APKs on the server. In a lot of cases the only thing changed are some strings in the AndroidManifest.xml(the app name and permissions requested are found in here) or one or two resources(images, config files, etc.). The malware code(within the classes.dex file) remains unchanged; meaning that while the hash of the APK has changed, the code that is the malicious app is still the same. This technique does inflate the number of unique samples(hashes), but it does nothing to prevent detection.

Unique APKs vs. Unique detections
The key here might be that it all comes down to whether the user has protection on their device(e.g. phone, tablet). Without protection(antimalware, app whitelisting, app reputation, URL reputation), the total numbers of unique APKs makes a difference.  In that situation a user would need to be able to figure out for themselves if these millions of apps are malicious.

With protection and knowing that most of these "unique" APKs effectively contain the same malware, the smaller number of detections gives users a better idea of the scope of the threat. The number of total Android malware(families and variants) is outsized by the number of legitimate applications.

Given all this, if you asked three Antivirus Researchers for the total numbers of Android malware you might get four answers and they would all be right.