[Patch]Malware Exploit for all pre-Gingerbread phones

Search This thread

pulser_g2

Admin Emeritus / Senior Recognized Developer
Nov 27, 2009
19,544
11,630
Quick technical question...

I presume this is to prevent the malware from making an infected binary called profile, which is the Trojan itself?

If so, what's to stop a future attack from using a differently named, or self mutating, file?

Just curious as to how effective this is, given the fact we are talking about root exploits, which can be programmed to overcome most limitations like this.

Or am I missing something here? (reading from my phone so I could have missed a bit of something)
 

javip

Senior Member
Dec 3, 2009
202
111
out curiosity how do you know who the publisher of a certain app is? is it the name the appears right under the app in the market place?

the reason i ask is because i have chess for android and pewpew but neither say anything about Myournet being the publisher.
 

overground

Retired Senior Moderator / Inactive Recognized Dev
Quick technical question...

I presume this is to prevent the malware from making an infected binary called profile, which is the Trojan itself?

If so, what's to stop a future attack from using a differently named, or self mutating, file?

Just curious as to how effective this is, given the fact we are talking about root exploits, which can be programmed to overcome most limitations like this.

Or am I missing something here? (reading from my phone so I could have missed a bit of something)

I'm fairly sure this particular fix is just for this particular strain. I highly doubt it will thwart any pre-existing, alternate malware nor any futures.
 

MaluNoPeleke

Senior Member
Jan 8, 2011
929
175
www.peleke.de
Can my phone (HTC Desire Z with 1.82 firmware) be infected?
I don't have root and even with the psneuter temproot method I cannot create the blank profile file.
Thanks
 

fsc137

Member
Feb 5, 2011
31
1
Cambridge MA
www.tonystark.org
Niggling technicality:

Using 'adb shell' or terminal emulator (should work on any phone)

Using 'adb shell' or terminal emulator (should work on any ROOTED phone)

Isn't that right? Can't "su" without rooting. (Can you "su" from adb shell without rooting?)

(In fact, as an old Unix guy, I'm nervous about this whole "su with null password" business in Android. Seems to me that exploits like this could be prevented by installing a root password.)
 

pulser_g2

Admin Emeritus / Senior Recognized Developer
Nov 27, 2009
19,544
11,630
Niggling technicality:

Using 'adb shell' or terminal emulator (should work on any phone)

Using 'adb shell' or terminal emulator (should work on any ROOTED phone)

Isn't that right? Can't "su" without rooting. (Can you "su" from adb shell without rooting?)

(In fact, as an old Unix guy, I'm nervous about this whole "su with null password" business in Android. Seems to me that exploits like this could be prevented by installing a root password.)

Most devices I know of can open adb shell after enabling usb debugging. No su or remount unless ro.secure=0.

You cannot su from adb shell without root, as you need root to reflash boot.img to set ro.secure=0.

Root password wouldn't help IMHO, as the suid could still be set, AND... root exploit grants you root, regardless of the length of said password.
 

fsc137

Member
Feb 5, 2011
31
1
Cambridge MA
www.tonystark.org
It seems to me that the whole "outside developers" idea is, at present, based on the existence of a root exploit, so if all the root exploits were fixed, these wonderful ROMs would not be available.

A better way to go, in the long term, would be to fix the root exploits and then have the outside developer software loaded (at least initially) through Odin. That would be more secure, requiring that someone actually hold down "1" while rebooting, rather than allowing root to ever be achieved through software.
 

Rodderik

Inactive Recognized Developer
Sep 8, 2010
1,300
1,295
devphone.org
Niggling technicality:

Using 'adb shell' or terminal emulator (should work on any phone)

Using 'adb shell' or terminal emulator (should work on any ROOTED phone)

Isn't that right? Can't "su" without rooting. (Can you "su" from adb shell without rooting?)

(In fact, as an old Unix guy, I'm nervous about this whole "su with null password" business in Android. Seems to me that exploits like this could be prevented by installing a root password.)

You're right! I have updated the OP to clarify that. Thanks.

Most devices I know of can open adb shell after enabling usb debugging. No su or remount unless ro.secure=0.

You cannot su from adb shell without root, as you need root to reflash boot.img to set ro.secure=0.

Root password wouldn't help IMHO, as the suid could still be set, AND... root exploit grants you root, regardless of the length of said password.

root permissions do not get called from any password based authentication on android
 

Rodderik

Inactive Recognized Developer
Sep 8, 2010
1,300
1,295
devphone.org
It seems to me that the whole "outside developers" idea is, at present, based on the existence of a root exploit, so if all the root exploits were fixed, these wonderful ROMs would not be available.

A better way to go, in the long term, would be to fix the root exploits and then have the outside developer software loaded (at least initially) through Odin. That would be more secure, requiring that someone actually hold down "1" while rebooting, rather than allowing root to ever be achieved through software.

Correct again! Developers could easily extract, modify, inject, and release a hacked up initramfs with root built-in an Odin .tar (or any stock image flashing program). On the same note though not much is going to prevent a malicious apk from reflashing the kernel of unsuspecting users and then on reboot have a go at the info they want. I guess my point is anything is possible given the time and determination.
 

cyansmoker

Inactive Recognized Developer
Sep 18, 2010
501
636
Los Angeles
nexus.zteo.com
Niggling technicality:
(In fact, as an old Unix guy, I'm nervous about this whole "su with null password" business in Android. Seems to me that exploits like this could be prevented by installing a root password.)

Then, as an old unix guy, I'm sure you realize that this exploit has nothing to do with su, which is just an executable, and that it, instead, uses privilege escalation (or in rageagainstthecage's case: lack of de-escalation)

If so, what's to stop a future attack from using a differently named, or self mutating, file?

Nothing. As you suspect, this particular patch only addresses this particular malware and we were lucky that its behavior is so...compliant.
 

pulser_g2

Admin Emeritus / Senior Recognized Developer
Nov 27, 2009
19,544
11,630
Then, as an old unix guy, I'm sure you realize that this exploit has nothing to do with su, which is just an executable, and that it, instead, uses privilege escalation (or in rageagainstthecage's case: lack of de-escalation)



Nothing. As you suspect, this particular patch only addresses this particular malware and we were lucky that its behavior is so...compliant.

Fair enough :) It does the trick here.

Obviously it would be trivial to code it such that "static" measures such as this would not work. Randomly naming the file, or abusing the root permissions to delete the existing file and overwrite it.

I wonder... how many HTC users were saved by their NAND locking, which would prevent these changes being committed to NAND, despite being root. Perhaps manufacturers will use this as justification for NAND locks?
 

fsc137

Member
Feb 5, 2011
31
1
Cambridge MA
www.tonystark.org
Correct again! Developers could easily extract, modify, inject, and release a hacked up initramfs with root built-in an Odin .tar (or any stock image flashing program). On the same note though not much is going to prevent a malicious apk from reflashing the kernel of unsuspecting users and then on reboot have a go at the info they want. I guess my point is anything is possible given the time and determination.

Apps can reflash the kernel??? That should not be permitted. One of the whole points of a Java virtual machine is that the apps can't get a hold of the real hardware.

Anyone who cared about security would be very careful about what they flashed with Odin. Software from a trusted source, possibly assembled and compiled one's self from source code (inspected source code, if necessary), is the way to go.

Some sort of accommodation would have to be made so that the wireless carrier can modify the ROM, but that should be done with some sort of strict hardware-based encryption and handshaking.

Meanwhile, you're not going to catch me doing any banking on my phone.
 

thunderteaser

Senior Member
Jul 22, 2010
830
296
Please, give me an advice.
Suppose I want to create this file while installing a rom, I would make a little script like this:

Code:
#!/sbin/sh
echo "Fixing vulnerability issues..."
touch /system/bin/profile
chmod 644 /system/bin/profile

and edit the updater-script to copy it in /tmp and run it, will it work?
 

thunderteaser

Senior Member
Jul 22, 2010
830
296
Yes it should work except I wouldn't label it "Fixing vulnerability issues..."
That's a tad misleading.

Thank you very much! That was just an example, also it's a script I would personally use, I'm not a professional cooker so I'm not releasing ROMs! I could also delete that echo part, it was just for fun! :)
 

Rodderik

Inactive Recognized Developer
Sep 8, 2010
1,300
1,295
devphone.org
Please, give me an advice.
Suppose I want to create this file while installing a rom, I would make a little script like this:

Code:
#!/sbin/sh
echo "Fixing vulnerability issues..."
touch /system/bin/profile
chmod 644 /system/bin/profile

and edit the updater-script to copy it in /tmp and run it, will it work?

even simpler your updater-script should copy files to /system so simple put that file in the right place and set_perm(0, 0, 0644, "/system/bin/profile") in your updater-script or download the edify zip from the first post and use it as an example.
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 54
    [Patch][Rom]Malware Exploit for all pre-Gingerbread phones
    Who is affected? All phones pre-gingerbread
    Who should act? Users and developers using pre-gingerbread roms
    How do I fix? Flash attached .zip at the bottom of this post or use one of the alternate methods down there
    What if I think I was infected? Completely wipe your device, format sdard, go back to stock and re-apply rom, then flash the attached .zip (before installing any apps)
    Why should I care? read below...

    http://www.androidpolice.com/2011/0...your-phone-steal-your-data-and-open-backdoor/

    Link to publishers apps here. I just randomly stumbled into one of the apps, recognized it and noticed that the publisher wasn’t who it was supposed to be.

    Super Guitar Solo for example is originally Guitar Solo Lite. I downloaded two of the apps and extracted the APK’s, they both contain what seems to be the "rageagainstthecage" root exploit – binary contains string "CVE-2010-EASY Android local root exploit (C) 2010 by 743C". Don’t know what the apps actually do, but can’t be good.

    I appreciate being able to publish an update to an app and the update going live instantly, but this is a bit scary. Some sort of moderation, or at least quicker reaction to malware complaints would be nice.

    EDIT: After some dexing and jaxing, the apps seem to be at least posting the IMEI and IMSI codes to http://184.105.245.17:8080/GMServer/GMServlet, which seems to be located in Fremont, CA.

    I asked our resident hacker to take a look at the code himself, and he’s verified it does indeed root the user’s device via rageagainstthecage or exploid. But that’s just the tip of the iceberg: it does more than just yank IMEI and IMSI. There’s another APK hidden inside the code, and it steals nearly everything it can: product ID, model, partner (provider?), language, country, and userID. But that’s all child’s play; the true pièce de résistance is that it has the ability to download more code. In other words, there’s no way to know what the app does after it’s installed, and the possibilities are nearly endless.

    The offending apps from publisher Myournet:

    * Falling Down
    * Super Guitar Solo
    * Super History Eraser
    * Photo Editor
    * Super Ringtone Maker
    * Super Sex Positions
    * Hot Sexy Videos
    * Chess
    * 下坠滚球_Falldown
    * Hilton Sex Sound
    * Screaming Sexy Japanese Girls
    * Falling Ball Dodge
    * Scientific Calculator
    * Dice Roller
    * 躲避弹球
    * Advanced Currency Converter
    * App Uninstaller
    * 几何战机_PewPew
    * Funny Paint
    * Spider Man
    * 蜘蛛侠

    http://www.androidpolice.com/2011/0...-android-nightmare-and-weve-got-more-details/

    Now, on to some more details of the virus. We should point out that this vulnerability was patched with Gingerbread, meaning any device running Android 2.3+ should be fine. In other words, if you’re looking to play the blame game (which I’m not, but having read all the comments on the original post, many people are), then there’s plenty to go around. The hole was fixed by Google, but it’s relatively useless since many phones aren’t yet running a version of Android that is protected. It’s noteworthy that some manufacturers released updates that patched the exploit for devices without updating to Gingerbread; unfortunately, it appears that minority is quite a small one.

    Perhaps most important is the question of what infected users can do about their situation; unfortunately, the answer is not much of anything. Because the virus opens up a backdoor and can bring in new code at any time, the only way to really rid an infected device of any damage is to completely wipe the device – not exactly the optimal solution, but it looks like the only one available, at least for now.

    Finally, Justin notes that ROM developers working with pre-Gingerbread versions of Android can prevent the virus from backdooring in code by putting a dummy file at /system/bin/profile.


    As you can see androidpolice.com reports on this backdoor and roots and steals personal information. The apps are removed from the market but that doesn't mean they got them all. Attached is a flashable fix as suggested by androidpolice.com

    So users can flash this .zip or simply create a blank file called profile and place it in /system/bin/ (developers are encouraged to include this file in future releases. A blank file is not going to affect performance at all)

    Alternate methods:

    Using 'adb shell' or terminal emulator (should work on any ROOTED phone) as suggest by xaueious here
    Code:
    $ su
    su
    # remount rw
    Remounting /system (/dev/stl9) in read/write mode
    # touch /system/bin/profile
    # chmod 644 /system/bin/profile
    #

    Alternate 2:
    Download blank profile file from here (or create one and name it profile)
    Use a program like Root Explorer to copy it to /system/bin/
    Then longpress on it and check the permissions should be read/write for user, read for group, and read for others.

    Alternate 3:
    cyansmoker has put together an apk for the patch here https://market.android.com/details?id=com.voilaweb.mobile.droiddreamkiller

    Thanks for pointing this out photoframd and androidpolice.com for investigating and reporting!

    UPDATE: I renamed the .zip file and reuploaded it (350 hits wow). Also in the edify scripted version I added 644 permissions to the file (but if you already flashed it then it should have defaulted to that). I also added a pre-edify version of the patch thanks to xaueious for people using a recovery that does not yet understand edify.
    5
    This .zip is flashable for the Epic running ClockworkMod Recovery. I will include directions in the OP for other methods of getting the file there. If some one wants to put together an apk or a signed update.zip feel free to let me know and I'll make sure it gets posted.

    Also I have requested some more technical information on the malware and I will update with the new information when I get it.

    Well, these is now an .apk. Look for "DroidDreamKiller" on the market (I know it's a stupid name) or on the web: https://market.android.com/details?id=com.voilaweb.mobile.droiddreamkiller

    It's a really simple app that I quickly put together by ripping pieces of another of my apps.
    2
    Rodderik - very useful, thanks much. This will be in SyndicateROM Frozen 1.0.1.

    EDIT: Between this and CIQ removal, we devs have malware removal/prevention covered. ;)
    1
    Anyone think an android AV program like Lookout would have caught this if running when the infected app was installed?

    I suspect it would.
    1
    Would it be safe to assume that if you look in your system/bin directory and already have a file named profile than you have been infected?

    It is quite possible. Check and see if you installed any of the programs lately from the OP. If so then it is quite possible. It is also quite possible a rom developer put that file in there so that is not a 100% way of making sure.

    Instead of flashing, using Root Explorer could I just create a file named "profile" in the system/bin directory for a fix?

    Yes indeed!

    Anyone think an android AV program like Lookout would have caught this if running when the infected app was installed?

    Here is more from the articles I posted
    Wow – from our perspective, it’s almost like the world exploded overnight. We have more information and details on the virus – which Lookout has named "DroidDream" (the word was consistently used in package names by the malware developers) – and some updates on where things stand.

    So I'm assuming that means Lookout scans for or will soon scan for this malware.