Yikes :) ...
Posted on 2014-01-17, 48 comments, 230 +1's, imported from Google+/Chainfire

NOTICE: This content was originally posted to Google+, then imported here. Some formatting may be lost, links may be dead, and images may be missing.

...

Reshared from https://plus.google.com/+ClaudXiao/posts/H7xC18RR6wm

Hi all,

We found an Android trojan in the boot partition of an infected Android device. Since the boot partition will be loaded as a read-only RAM disk during Android's running, all existing antivirus solutions can't effectively clean it.

The trojan will drop malicious APK to system directory, connect to C&C servers, download and install other adwares, fetch and execute other commands.

We classify this trojan as bootkit and named "Oldboot". This is the first Android bootkit in the wild as best we know. By our statistics, there’re more than 500,000 Android devices infected by this bootkit in China in last six months.

Oldboot: the first bootkit on Android | 360移动安全

+1230
James Passmore commented on 2014-01-17 at 14:27:

It was only a matter of time, I suppose. Unfortunately, the press will probably inflate this into another silly Android security scare.

Ellie Kennard commented on 2014-01-17 at 14:27:

I am not someone who has rooted my device. Will this affect my Note2? Thanks +Chainfire 

Bazz Freeman commented on 2014-01-17 at 14:27:

Was only a matter of time. Surprised it's taken this long.

Details on the filename? or are they polymophic?

David Perez commented on 2014-01-17 at 14:29:

+Chainfire Greetings and compliments. I can do my root BLU Life View with some Kernel yours?

Paul Vitorino commented on 2014-01-17 at 14:31:

China eh? I wonder if Kingo Rooting tool has anything to do with this...

Ned Jeffery commented on 2014-01-17 at 14:31:

Let me guess, rooted and unlocked only? (now I have to read it to find out) 

Brian Klippel commented on 2014-01-17 at 14:35:

It has to be some kind of rooting or rom tool, or the boot partition couldn't have been written to in the first place.  

David Poole commented on 2014-01-17 at 14:36:

Old Boy reference?

Brian Klippel commented on 2014-01-17 at 14:36:

+Ellie Kennard No. 

Brian Klippel commented on 2014-01-17 at 14:38:

Just wait until Apple bribes the press to blow this out of proportion.

Randy Beavers commented on 2014-01-17 at 14:38:

Any one run the "do you have it" app yet?

Jörg Krause commented on 2014-01-17 at 14:41:

Oldbootkiller ups...i can not read China Letters! Please in english=)

Markus Birth commented on 2014-01-17 at 14:43:

It looks like it will log chinese texts - so that's how you can detect it using the debug monitor?

Justtyn Hutcheson commented on 2014-01-17 at 14:43:

+Brian Klippel Why pay for what will happen anyway?  The ridiculous part is that the only way to get this loaded is a) downloading an infected file to a rooted device with system write protection and SELinux disabled or b) flashing an already-infected boot.img, both of which require explicit interaction with the user.  Again the Android mantra holds true: only root if you want to take responsibility for your device.

Farhan An Nahar commented on 2014-01-17 at 14:46:

[QUOTE]

The problem is, how the attacker put the imei_chk into / sbin directory and successfully modified the init.rc script We believe there're at least two ways to achieve it?:

  1. The attacker has a chance to physically touch the devices, and flash a malcious boot.img image files to the boot partition of the disk;

  2. During system's running, after gaining root permission, forcibly write malicious files into boot partition through the dd utility.

. In Oldboot's case, we're more likely to believe that the attacker chose the first way (But we still can't exclude possibility of the second one)

[/QUOTE]

兄貴分背の高い commented on 2014-01-17 at 14:48:

Hope this will be fixed !

Brian Klippel commented on 2014-01-17 at 14:51:

+Justtyn Hutcheson I'm not even sure "a)" is a guaranteed infection.  For the trojan to be written to the boot partition the device pretty much has to be in a recovery mode or cable connected to ADB.

Pașca Alexandru commented on 2014-01-17 at 15:02:

+Brian Klippel

One can write to the boot partition with a live device.

No ADB, no fastboot.

You'd need hands-on access or some remote root access.

Once you'd gain root access to the device you can write anything anywhere and execute any arm binary or shell script.

But these devices were "infected" by the reseller or someone inside the reselling chain.

Even where I live, pretty far from China, resellers, especially gsm carriers, are very into "customizing" the phones and tablets.

A logo and some "special" apps... What's so difficult?

Matteo Panella commented on 2014-01-17 at 15:10:

Going with the "physical access" method, you'd need:

a) an infected boot.img for each specific device and specific firmware revision;

b) a recovery which doesn't verify signatures or a bootloader which will happily flash unsigned binaries while in download mode.

As far as the infection through the running system is concerned, it's even harder: the app would have to detect the device type and firmware revision, determine its partition layout and fetch the right payload for the exact pair of device/firmware revision (condition a) still stands: boot.img is a combination of kernel+initramfs, which are very device/firmware specific). Only then it can write boot.img to the eMMC.

Also, it has to run as root in an unconstrained SELinux context, which essentially means that the user authorized it.

Nevertheless, almost all media outlets are definitely going to blow this out of proportion and make Android sound like it has no security model whatsoever.

Pașca Alexandru commented on 2014-01-17 at 15:19:

+Matteo Panella

What about a platform independent method?

Hypothesizing that I'd get root permissions in a live phone, I'd dump the boot partition (/dev/block/mmcblk0p1), grep for the initrd, dd -skip $offset the initrd.cpio, dump de contents of the cpio in a tmpfs folder, add my binary, libs and lines for /init, repack the cpio, concaternate with the kernel, dd back to mmcblk0p1, and reboot. 

Wolfang RS commented on 2014-01-17 at 15:27:

The big question.... How this device was infected?

Tyler Raber commented on 2014-01-17 at 15:28:

+Pașca Alexandru you can also do Adb over WiFi which is possible

Sinan Çetinkaya commented on 2014-01-17 at 15:48:

Samsung users keep using Chinese origin root tools and saying "YaY!!! I'm rooted" despite all the efforts from xda and +Chainfire 

Good luck guys :D

Craig Carboni commented on 2014-01-17 at 16:08:

Is the device unlocked and rooted?

Wolfang RS commented on 2014-01-17 at 17:05:

Level 5 Trolling

Brian Klippel commented on 2014-01-17 at 17:28:

+Pașca Alexandru I know system can be remounted writable while active, but I did not know that boot could be. I always assumed that could only be done when the recovery partition was the active.. Or is it just a matter of staging what needs to go to boot then forcing a restart?

Joel Albertson commented on 2014-01-17 at 17:33:

Wish I knew if I have this or not. I ran the test app. Cant understand...

Daniel Tejeda commented on 2014-01-17 at 17:42:

Yeah, thats the problem, so how do we know if we have it on our devices and what the soulution might be.

Pașca Alexandru commented on 2014-01-17 at 17:45:

+Brian Klippel partitions are not active or inactive. The boot partitions, 0 containing bootloader and some configs and 1 holding the kernel and initrd, are never mounted or readily accesible by the user.

0 is usualy a fat16 with fastboot and 1 contains raw zImage folowed by initrd. the recovery partition contains a minimal operating system usable in a full-reset of the main Android OS. It ain't recovering anything. Custom ones, like TWRP do.

So, as the #0 partition is not mounted by default it could be mounted by user. r/o of r/w. Whichever.

The partition containing kernel+initrd does not contain a filesystem. The kernel is written directly in the gpt partition. There is nothing protecting it from writing. For example, piping data towards the block character in /dev is writing it. 

L.e. obviously it is writable only by the user with correct permissions.

Fernando Sosa commented on 2014-01-17 at 18:07:

Damm... Well something important to remember..... Use and GOOD ANTIVIRUS ON YOUR ANDROID.

Pașca Alexandru commented on 2014-01-17 at 18:09:

+Fernando Sosa name one. An OPEN source one! One that does not just pretend to find vi... malware and prompt you to pull up the credit card.

Brian Klippel commented on 2014-01-17 at 18:22:

+Pașca Alexandru Thanks for the detail, I appreciate it. I haven't explored android system operations past using custom recoveries and image tools such as Odin. I suppose it all makes sense to have it that way in typical environment where the end user is assumed never to have su/sudo. But I have to admit I'm curious why they don't just mount both r/o locked when booting to system, and only allow write from recovery? Would it make OTA impossible? If not it seems it would be a lot more virus resistant.  I'm not advocating a locked bootloaded, but is there any room for a middle ground?

Artem Russakovskii commented on 2014-01-17 at 18:36:

According to +Tim Strazzere, it's just this: https://blog.lookout.com/blog/2013/12/09/mouabad-p-pocket-dialing-for-profit/, which isn't new.

Pașca Alexandru commented on 2014-01-17 at 18:40:

+Brian Klippel If you have a partition mounted readonly it's just a matter of remounting with rw flag.

And, as far as I know, nand flash can't be hardware r/o.

Tim Strazzere commented on 2014-01-17 at 18:44:

+Artem Russakovskii That one is specifically Mouabad.p -- this one we track as Mouabad.s -- but yes, same family :)

Tyler Raber commented on 2014-01-17 at 19:20:

+Fernando Sosa more like don't be a dumbass and install bad files

无言独上西楼，醉里挑灯看剑，问青天我是谁 commented on 2014-01-18 at 00:03:

Using any productor of 360, you lost your safety.

无言独上西楼，醉里挑灯看剑，问青天我是谁 commented on 2014-01-18 at 01:04:

+Brandon Padilla 360 is not china, just fucking 360

Tyler Raber commented on 2014-01-18 at 01:07:

+ajahdkalsamkakdslsaak ahskaikakalw too bad apple sells your data to the US Government 

Yongce Tu commented on 2014-01-18 at 06:13:

Mark

Jose Faria commented on 2014-01-18 at 10:44:

About samsung, kingo jabs,

If this was somehow flashed in a current samsung device it would trigger the binary count and Knox, something kingo root has avoided so far.

Sam Adeli commented on 2014-01-18 at 12:35:

If it's in boot partition it means that either this was placed there by manufacturer or only affects rooted devices.

Tyler Raber commented on 2014-01-18 at 14:23:

+Juha Uotila I know this I was merely poking fun. The NSA doesn't buy shit they just steal it from every company that involves private user data

Frank Hauptle commented on 2014-01-19 at 16:54:

It would have to be device specific or very adaptive as there is way more variance in android devices than there is in the PC world.

Frank Hauptle commented on 2014-01-19 at 16:56:

Also googles play service is an admin service so google can stop it. It is still very likely to be something people install rather than a windows style malware that you can just catch from bing online. (Think nimda and codered)

Prem Suraj commented on 2014-01-20 at 04:09:

There will just be a few cases of this mainly because of the difficulties in getting this thing on devices. But I'm waiting for the media blowup, oh what fun it will be.. :(

Mark Lester Navarro commented on 2014-01-28 at 11:58:

And they have done it again... Those guys of the red empire...

keir blackie commented on 2014-02-02 at 17:09:

Are you not better to scan a file on PC before flashing it to be safe?

This post is over a month old, commenting has been disabled.