Since my previous post about zero-permission Android applications, I have continued researching along the same lines. This work is similar to research presented by Lookout at Defcon. As that work is a few years old, I thought this topic should be reviewed with fresh eyes.

At Defcon 18, three researchers from Lookout Mobile Security presented on several permission-related security issues. My observation is that most of the research presented was targeted at Android 2.2 and below. They demonstrated that an app with no permissions can reboot a device, start on boot, block user input, and obnoxiously play noise. More interestingly, they showed that they could launch the browser and perform two-way communication with a remote server, and that they could do so when the screen was off.

Building on this work, I wanted to test out their approach to two-way communication using the browser while the screen is off and the device is locked. I found that, indeed, registering a URI handler and calling that URI from within the browser worked well. I was able to have the app query my server, causing the server to call a URI to instruct the app on what to send next. This would cause the app to send that data and query the next instruction and then close the browser window when there was nothing left to do. Hiding this activity was another matter.

I could not launch the browser while the screen was off, at least not in 2.3 or 4.0: the intent to launch the browser would begin, but it would block until the screen turned back on. On 2.3, this meant that when the screen was off, my app would launch and then wait until the screen was on but still locked. My app could then freely perform two-way communication. Of course, if the device was quickly unlocked once the screen was on, it would be evident that the browser was open. On 4.0, things were a little trickier: I found that when the screen was on but the device was locked, the browser would launch but fail to navigate to the requested page. I'm not sure what changed in 4.0, but it definitely makes sneaky browser games much more difficult to perform.

Building upon my previous release, this version of my No Permissions app includes many new actions I could accomplish without requesting permissions. Like before, it can gather version and identifier information and send that information to my server. It can also upload any readable file, whether from the SD card or from a world-readable directory, and send that data to the server. I also created a location mining function that would read the pictures stored on the SD card, scan them for EXIF tags, and upload the location within the EXIF along with the time the picture was taken. While not as good as having the FINE_LOCATION permission, this information can contribute to creating an accurate impression of where a person was, assuming that the storing of location data within pictures is enabled. The app uses the browser trickery described in the previous paragraph for two-way communications, as such the server is able to instruct the app to download a file, store it in the app's private storage, and either open the file with the default handler for that file type or execute it as Java code. While not allowing any new permissions, executing new Java code can further expand the possible activities. Lastly, I created the option to take a base64-encoded string and execute that on the command line -- if the app detects that the device may be rooted, it attempts to perform that command line action as root, otherwise it executes it as our unprivileged app's user id.

At some point, when attempting to implement code to run shell commands given by the server, I noticed that ping was the only binary in /system/bin that was setgid and world-executable. After some testing, I quickly realized that my application with zero permissions was able to successfully ping Internet hosts. I tested this out on a device running 2.3.5 and it worked, but when I tested the code on a device running 4.0.4, it didn't. After a bit of reverse engineering, I found that the ping binaries were different on the two devices. In fact, the differences corresponded to this commit by Nick Kralevich. According to the git logs, the fix was committed after the deadline for the 2.3.x branch. This means that any device running Android 2.3.x or below is vulnerable to this slight oversight in permission checking. Just to be thorough, I downloaded a ROM for a Honeycomb-based tablet. The ROM, which was at Android 3.0.1, contains a ping binary with the changes present in the 4.0.x branch.

It's important to realize this is not a regular ICMP tunnel; we can only execute the ping binary from a command-line. The end result is that one can send 24 bytes of data to a remote server and receive a small integer in the range 8-64 (less than 6 bits of data) in return. This technique allows for a slow trickle of ICMP packets to carry information off of a device and is able to receive enough information back to know what data to send next from a list of possible options. While being a much smaller channel on which to exfiltrate data, this is undetectable to the end-user. In fact, when testing this on a rooted device with a firewall app, I found that the firewall only filters TCP and UDP, missing the ICMP packets completely.

As a side note, execution of the ping binary is also the only way I determined that an application with zero permissions can perform DNS lookups. It may be possible to achieve a wider communication channel using DNS lookups, but I did not look into this option.

Based on this research, I strongly advise that users update to Ice Cream Sandwich (4.0.x), if possible. In addition, disable location data within pictures you take if you don't need the feature. Do not store any files or data on your SD card or external storage any longer than necessary; move them to your computer or delete them if you no longer need them on your phone or tablet. Finally, be careful about what apps you install; even if it doesn't ask for many permissions, a malicious app can perform all sorts of nasty actions on your device.

Android app developers should continue to write apps that only request the permissions needed by the app, and they also need to be wary of any 3rd-party code, such as advertising libraries, that they include in their apps. App developers should also be mindful of file-level permissions of any locally stored files and avoid using external storage where possible; I suggest that they consider using libraries such as SQLCipher to increase the privacy of any stored user data.

Google has some work to do, too. It's my opinion that Google needs to take responsibility for device updates away from the neglectful carriers and push the latest version to every device that can run it. If 4.0 isn't possible for all devices, security updates like fixing the ping binary should be back-ported to the older 2.3 branch. Further, Google should be adding more permissions, such as restricting access to browser launching and restricting the execution of shell commands.

The source for the revised No Permissions app is available here: NoPermissions-1.5.zip

The source for the Ping tunneling app is available here: Ping.zip

There's been a lot of research in the Android security space. The most notable examples are Jon Oberheide's fake Twilight app, Georgia Weidman's SMS bot, and the numerous clever root exploits. Recently in the mainstream media, there's been buzz about apps (allegedly) misusing permissions; some of these apps include Facebook, Skype, Path, and just about every advertisement library.

One question that was posed internally was: what data can an app access when it has no permissions? I thought this was an interesting question, so I decided to make a proof-of-concept app to explore this idea. Some previous work had been demonstrated by Thomas Cannon of viaForensics. I wanted to develop that work further through a discussion backed by source code.


Continue reading "Zero-Permission Android Applications"

Original Research May 9, 2011

Introduction

Adler32 is a checksum designed to detect corruption in Zlib's compressed data or corruption in the algorithms. Since it was much faster than its more reliable competitor, CRC32
it was chosen for this task [1]. If the uncompressed data does not match the Adler32 checksum, the application can inform its protocol or the user to retransmit the data.
However, the main use of Adler32 was to debug implementations of Zlib. Adler32 as well as CRC32 are insufficient for any purpose that requires a high degree of certainty. The
chance of a collision for an ideal 32-bit checksum is 1 in 4 billion, which can be easily computed in a few hours by anyone with a reasonable computer. An attacker can even do
it in realtime if they had precomputed all checksums beforehand. Adler32 has known weaknesses making it much more susceptible to collision than the more reliable CRC32.

In 2002, RFC 3309 changed the checksum of the SCTP protocol from Adler32 to CRC32. In doing so it explained a weakness of Adler32 with short messages [2]. Since it is not
relied upon for important cryptographic security and is used for speed, few research papers have been published on it. Adler32 also contains a weakness in long messages
where the end of the message is modified but the start of the message is the same. This means that Zlib cannot be transmitted by itself without use of a slower checksum or
hash. Gzip and PNG formats are designed to use Zlib and choose to have an optional CRC32 checksum of the compressed zlib data instead of the original data.

In this blog post I will describe a method to generate collisions between Adler32 checksums. This has no security implications but may be interesting to cryptographers looking
for a trivial distinguisher [3]. CRC32 and all 32-bit checksums can be analyzed with the same scripts with no modifications to the algorithm. By dividing secure hashes into 32-bit
chunks, they can be tested not fully but spot checked using this same algorithm.

Collision

The following is a Python script to generate Adler32 collisions. I have tested this on millions of pieces of data and fails only on a small subset of data.


from zlib import adler32
from random import randint

def rand_data(l = 4):
    return ''.join([chr(randint(0, 255)) for i in xrange(l)])
#end def rand_data(l = 4)

def generateAdler32Collision(data):
    y = list(data)
    adler_input = adler32(data)
    y[-1] = chr((ord(y[-1])+1)%256)
    y[-3] = chr((ord(y[-3])+1)%256)
    y[-2] = chr((ord(y[-2])-2)%256)
    output = ''.join(y)
    adler_output = adler32(output)
    if adler_output == adler_input:
        return output
    #end if
    #print 'Looking for a different collision'
    y[-1] = chr((ord(data[-1])-1)%256)
    y[-3] = chr((ord(data[-3])-1)%256)
    y[-2] = chr((ord(data[-2])+2)%256)
    output = ''.join(y)
    adler_output = adler32(output)
    if adler_output == adler_input:
        return output
    #end if
    #print 'I give up'
    return None
#end def generateAdler32Collision(data)

a = 'A'*1013 + 'test'
adler32(a) == -1892941051
adler32(generateAdler32Collision(a)) == -1892941051
generateAdler32Collision(a) != a
generateAdler32Collision(a) == ('A'*1013 + 'tfqu')

successes = 0
failures = 0
for i in xrange(1<<24):
    a = rand_data(1024)
    a32 = adler32(a)
    coll = generateAdler32Collision(a)
    if coll == None or coll == a:
        failures += 1
        continue
    #end if
    successes += 1
#next i
print 'Successes:', successes
print 'Failures: ', failures
print 'Success rate:', (1.0 * successes)/(successes+failures)


Method

To find this method, I took a subset of the first 4 billion checksums and found
all the collisions. The most frequent collision repeated for almost every piece of data. The difference between the two data is only 3 bits in the last 3 bytes.

    y[-3] += 1
    y[-2] -= 2
    y[-1] += 1

    Also:

    y[-3] -= 1
    y[-2] += 2
    y[-1] -= 1


The exceptions to this algorithm are when the last 3 bytes are an edge case.

Mark Adler himself explains this in an e-mail correspondence:

The particular case you found, and many more, are easily derivable from the algorithm. When you append three bytes a, b, and c, the sums are updated as follows:

s1' += a + b + c
s2' += 3s1 + 3a + 2b + c

If we want to find deltas to a, b, and c, call them da, db, and dc that result in the same Adler-32 value (from the sequence a + da, b + db, c + dc), then you can easily derive
the deltas:

pick da to be any value,
set db = -2da,
and set dc = da

i.e. any multiple of the vector {1, -2, 1}.

Then the sums will be the same. So your example is da = dc = 1, db = -2, or the base vector {1, -2, 1}.
You could just as well pick something like da = dc = -3, db = 6, or {-3, 6, -3}. So there are many ways to change three bytes to return to the same Adler-32 value.
Therefore the Hamming distance is at most three bytes, or when the distance is measured in bits, three bits in distinct bytes (when there happens to be no carry to adjacent
bits for those deltas). You can find many, many more such vectors where the three bytes not adjacent. E.g. multiples of {1, 0, -3, 2}.

It is confusing to say that Adler32 has a weakness against short messages (less than a few hundred bytes). If you choose a 1024-byte psuedorandom prefix and modify the last
bytes, you will find the same number of collisions as a short message. I chose to use a 1024-byte prefix (which was unnecessary) computed the Adler32 checksum of all 0-4 byte
combinations appended to the prefix. Using this I was able to catalog many collisions among Adler32 checksums. The table in its current optimized format is 16GB.

By simply indexing the data and removing unnecessary duplicates, a full set of collisions can be created that allows the generation of collisions with Adler32 in real-time. Since
collisions should not affect the security of any application using Adler32 or CRC32, this information is only useful for research purposes.

Data


The first search for collisions found 32 checksums with 64 collisions.
The Adler32 checksum of each item the following list is 15728760:
['w\x00', '\x00v\x01', '\x01t\x02', '\x02r\x03', '\x03p\x04', '\x04n\x05', '\x05l\x06', '\x06j\x07', '\x07h\x08', '\x08f\t', '\td\n', '\nb\x0b', '\x0b`\x0c', '\x0c^\r', '\r\\\x0e', '\x0eZ\x0f',
'\x0fX\x10', '\x10V\x11', '\x11T\x12', '\x12R\x13', '\x13P\x14', '\x14N\x15', '\x15L\x16', '\x16J\x17', '\x17H\x18', '\x18F\x19', '\x19D\x1a', '\x1aB\x1b', '\x1b@\x1c', '\x1c>\x1d',
'\x1d<\x1e', '\x1e:\x1f', '\x1f8 ', ' 6!', '!4"', '"2#', '#0$', '$.%', '%,&', "&*'", "'((", '(&)', ')$*', '*"+', '+ ,', ',\x1e-', '-\x1c.', '.\x1a/', '/\x180', '0\x161',
'1\x142', '2\x123', '3\x104', '4\x0e5', '5\x0c6', '6\n7', '7\x088', '8\x069', '9\x04:', ':\x02;', ';\x00<']

prefix = "739b1478e08a126d24148678c4f7b35b8f5976ef06e02d04118dc0f568512bf747c7c7e29d980aee2968b490e8874abcb80c320f363bc14e6aa9cae809de0af5f3ce262d547867
bd085a2ddda8339e530f0252038d31d5b52bfd879236b340040708881521bc8f473482cc20b9dcbd134c7f43398bede1abf5e15030942b7f4ee7fb77c68968752398fcb68fbde2f3f53fa5
ed5ac470d79d9456f4bde059885905017eb333fe8057e4429b4d463735ebf0f947840de7c16221fdc6a0cf2d3f18a8fec11408fbee629a004830bd1103bf1211e59e5db0c753482ed76b1d
c0860aadaad259e7cc091fd935170d83ce95d8b0e7c07d512e8f42bd6c8344c5d716cb70e68c501e62a024cf749fe60be4ecd2db4780a60f953e534f80de44a54d50783d66c211abc3355
8c5dae6f6a879bc5264ae79a2f78d04f508400de3097b643e72eeb6d222fba2eea933c05efe71b212fe7a9d173189ff83ba389c04b4c6f3b7ecf7f7edca307211ce61d381c7cdf9c1075aa1
071abd1b59ee5acd3318aded06295c961e1d30611d4a9c81880b9c5ea66048aa8f60962257a30c8c3c3147e86200b8dde4c8d934b388914bccbc74dc5fe419899c443cbe30023adfbae
e83d78a57c0c9774ff04ae4cbfc3e1be5099e43494bc4b608fe9d317309d31a22a771c72dcbb474770e55bc724d83001e08309e0de4a3814789c619e0a9f7df4f1347a77b6bbde8086b21
2fe70324b1243164e703af194ed76236dd3225e4c04dd2b60f89266e6231afa52c6c4391953355a8151ec8ddde3ad737b3ad87fcf7720efda5032d26efb36079ce579c8f5030637e2d6f1ad
43ac18083e80d49aef56404858c657ec97e3a4a4a6cf8815db68e275a1c507aab209ad70d9d1e711de03471d90252e6f896a9e4d1e5634335f9dd30eb088930ffd18c844ef463f4242afe96
11becaedfc95f11ed4471f295ab45fddc04f3f77dcfaa818fa8b14aa93dbbcee559700fed9db70acb4ca0f40a679d1d51ab02aba02b0e7bc0bdf9f9ce144133079ac9a1e1f1552c04345e9092
2cc4badf85a5f0c0373c8d7f66b308a41609b5f5f6271787fa839664606f8bfad3ea8bbdcdc781c981a05263951edb960033ea4f1b8fb822c319b2ad021f462c40bb1071307142a07e5df70d
c3e2f07fac56310e4860665c939c4480fd083e08764f225f5a04ee2d5ac64755db03c76e394dc853613273ba0216528814eb9d4bf8fc4ca7b430e9977096f58e833abcbdda66701fb6480ab
75f08818524e628128c806756da025114f6767b6c23545f8bf645b4d7ea85c551f9a706647f3add10fbc67653ebf04e7cbc8da19d1dc9bcc795442cb047157015d59ea4915c49eb0f9b9667
8dc1e2ffac28abecb23bfdb26a7b8a22bb907ffc4c57017bc5b47c403ac3844c0099bd1e36f7edf613fed1b8b364494f6d389".decode('hex')

Using the pseudorandom prefix above, my program found the following collisions:

Adler32 checksums starting with byte 0b:
Adler32 checksums with no collision: 457
Adler32 checksums with collisions: 12285
Adler32 checksums max collisions: 803
Adler32 checksums total: 2190952

Adler32 checksums starting with byte 0c:
Adler32 checksums with no collision: 365
Adler32 checksums with collisions: 51047
Adler32 checksums max collisions: 4480
Adler32 checksums total: 63387000

Adler32 checksums starting with byte 0d:
Adler32 checksums with no collision: 256
Adler32 checksums with collisions: 68800
Adler32 checksums max collisions: 11011
Adler32 checksums total: 282481503

Adler32 checksums starting with byte 0e:
Adler32 checksums with no collision: 226
Adler32 checksums with collisions: 82300
Adler32 checksums max collisions: 18096
Adler32 checksums total: 619301010

Adler32 checksums starting with byte 0f:
Adler32 checksums with no collision: 554
Adler32 checksums with collisions: 93047
Adler32 checksums max collisions: 21680
Adler32 checksums total: 913874100

Adler32 checksums starting with byte 10:
Adler32 checksums with no collision: 642
Adler32 checksums with collisions: 127437
Adler32 checksums max collisions: 21846
Adler32 checksums total: 993022364

Adler32 checksums starting with byte 11:
Adler32 checksums with no collision: 502
Adler32 checksums with collisions: 140245
Adler32 checksums max collisions: 20569
Adler32 checksums total: 795505939

Adler32 checksums starting with byte 12:
Adler32 checksums with no collision: 545
Adler32 checksums with collisions: 139404
Adler32 checksums max collisions: 14851
Adler32 checksums total: 459911612

Adler32 checksums starting with byte 13:
Adler32 checksums with no collision: 3005
Adler32 checksums with collisions: 114560
Adler32 checksums max collisions: 7619
Adler32 checksums total: 161746754

Adler32 checksums starting with byte 14:
Adler32 checksums with no collision: 27671
Adler32 checksums with collisions: 72271
Adler32 checksums max collisions: 2371
Adler32 checksums total: 20276876

Adler32 checksums starting with byte 15:
Adler32 checksums with no collision: 30761
Adler32 checksums with collisions: 5131
Adler32 checksums max collisions: 102
Adler32 checksums total: 105776

Adler32 checksums starting with byte 16:
Adler32 checksums with no collision: 6162
Adler32 checksums with collisions: 0
Adler32 checksums max collisions: 0
Adler32 checksums total: 6162

Adler32 checksums starting with byte 17:
Adler32 checksums with no collision: 55
Adler32 checksums with collisions: 0
Adler32 checksums max collisions: 0
Adler32 checksums total: 55

Adler32 checksums starting with byte 18:
Adler32 checksums with no collision: 201
Adler32 checksums with collisions: 0
Adler32 checksums max collisions: 0
Adler32 checksums total: 201

Adler32 checksums starting with byte 1b:
Adler32 checksums with no collision: 1
Adler32 checksums with collisions: 0
Adler32 checksums max collisions: 0
Adler32 checksums total: 1


With the given prefix and a suffix of less than 5 bytes, there are no checksums that do not start with 0b, 0c, 0d, 0e, 0f, 10, 11, 12, 13, 14, 15, 16, 17, 18, or 1b.


Summary of all Adler32 checksums found:
Adler32 checksums with no collision: 71403
Adler32 checksums with collisions: 906527
Adler32 checksums max collisions: 21846
Adler32 checksums total: 4311810305


The largest collision found (most number of values with the same checksum) had 21846 data with the same checksum. It is available in the attached text file
(adler32_mpmp3_1043a_21846.txt). To verify I suggest the following code:


from zlib import adler32
from hashlib import sha1
coll_data = file('adler32_mpmp3_1043a_21846.txt', 'r').read()
if sha1(coll_data).hexdigest() != 'd1bec182b115bd874487b603c7d5eaaf3c1bd9c8':
    print "Error: Invalid data"
    exit(1)
#end if
coll_array = coll_data.split('\n')
coll_d = coll_array[1][coll_array[1].index('['):]
# Note that this command is insecure if the data is above is untrusted.
collisions = eval(coll_d)
a_colls = [adler32(prefix + coll) for coll in collisions]
a_colls == ([a_colls[0]] * len(a_colls))


Analysis

A large scale test for collisions in Adler32 shows that collisions are more common than values that do not collide. 4311738902 values that collide vs 906527 checksums that
do not collide gives us a 99.998% chance of there being a nearby collision for any checksum. The reason behind this high chance of collision is in the design of the algorithm.


adler32('\x00\x22\x33\x00') = 13631574
adler32('\x00\x22\x33\x01') = 13697111
13697111 - 13631574 = 65537
adler32('\x9f\x39\xf3\xbc') = 97321608
adler32('\x9f\x39\xf3\xbd') = 97387145
97387145 - 97321608 = 65537


Two adjacent pieces of data with the same prefix except the last byte will have a difference of 65537.


a = [adler32(prefix + 'rew' + chr(i)) for i in range(256)]
b = [a[i+1]-a[i] for i in range(255)]
b == [65537] * 255
c = [adler32(prefix + 're' + chr(i) + '\xff') for i in range(256)]
d = [adler32(prefix + 're' + chr(i+1) + '\x00') for i in range(255)]
e = [d[i] - c[i] for i in range(255)]
e == [-16580862] * 255


Two adjacent pieces of data with last byte being ff and 00 will have a
difference of -16580862.


f = [adler32('\x00' * i) for i in range(256)]
g = [f[i+1]-f[i] for i in range(255)]
g == [65536] * 255


The difference between different length strings of 00 is 65536.

adler32('\x00' * i) == adler32('\x00' * (i + 1)) + 65536



Adler32 addition is done modulo 65521 [4] for better mixing. This benefit allows it to outperform Fletcher-16, which was its original intent. All hashes must collide due to the
Pigeonhole principle [5], but Adler32's design does not use all pigeonholes effectively for similar data. When given the same prefix and different suffixes Adler32 performs much
worse than CRC32. To find a collision, I can modify the end of the stream to find collisions. If a collision is required between a good value and a specific bad value, the start of
the stream must be modified to change the most significant bits of the Adler32 checksum. Changing the last 4 bytes of the stream is insufficient to produce all possible checksums.

Also, it should be noted that some checksums are difficult to collide since Adler32 does not produce them regularly.

Performance

With advances in algorithms CRC32 is now much faster than it originally was. It is still slower than Adler32, but by a factor of 20% - 100%. For 1kB of data, Adler32 takes 31 seconds
per 16M (in Python) while CRC32 takes 38 seconds per 16M. In C, Adler32 takes 25 seconds while CRC32 takes 34 seconds.

In Python:

from time import time
from zlib import adler32, crc32

c = 'test'
start = time()
for i in range(256*256*256): c = adler32(str(c) + 'A' * 1000)

print 'Adler32 benchmark: %3.1f' % (time() - start), 'seconds'

start = time()
for i in range(256*256*256): c = crc32(str(c) + 'A' * 1000)

print 'CRC32 benchmark: %3.1f' % (time() - start), 'seconds'


Adler32 benchmark: 30.9 seconds
CRC32 benchmark: 37.8 seconds

In C:

/*
Benchmark for Adler32 and CRC32
by Joel R. Voss
Jan 23, 2012
*/

#include <zlib.h>
#include <sys/time.h>
#include <stdlib.h>
#include <stdio.h>


int main(int argc, char **argv)
{

    char z[1024];
    int i;
    for(i = 0; i < 1024; i++)
    {
        z[i] = random() % 256;
    }
    z[1023] = 0;
    struct timeval start;
    gettimeofday(&start, 0);
    int b = 0;
    for(i = 0; i < 16000000; i++)
    {
        long d[10];
        int j;
        for(j = 0; j < 10; j++)
        {
            d[j] = random();
        }
        // Switch the first 8 * 10 = 80
        snprintf(z, 1024, "%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx", d[0], d[1], d[2], d[3], d[4], d[5], d[6], d[7], d[8], d[9]);
        uLong a = adler32(0L, Z_NULL, 0);
        a = adler32(a, (Byte *)z, 1024);
        b += a;
    }
    struct timeval end;
    gettimeofday(&end, 0);
    printf("Adler32 total: %i\n", b);
    printf("Adler32 benchmark: %3.1f\n", (end.tv_sec - start.tv_sec) + (end.tv_usec - start.tv_usec)/1000000.0f);
    gettimeofday(&start, 0);
    b = 0;
    for(i = 0; i < 16000000; i++)
    {
        long d[10];
        int j;
        for(j = 0; j < 10; j++)
        {
            d[j] = random();
        }
        // Switch the first 8 * 10 = 80
        snprintf(z, 1024, "%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx", d[0], d[1], d[2], d[3], d[4], d[5], d[6], d[7], d[8], d[9]);
        uLong a = crc32(0L, Z_NULL, 0);
        a = crc32(a, (Byte *)z, 1024);
        b += a;
    }
    gettimeofday(&end, 0);
    printf("CRC32 total: %i\n", b);
    printf("CRC32 benchmark: %3.1f\n", (end.tv_sec - start.tv_sec) + (end.tv_usec - start.tv_usec)/1000000.0f);
    return 0;
}


Adler32 benchmark: 24.8 seconds
CRC32 benchmark: 32.5 seconds

This could explain why Gzip, BZip2 and LZMA chose CRC32 instead of Adler32 for checksum.

Knowing that the Adler32 checksum suffers from far greater occurrence of collisions than its competitor should convince anyone to reconsider its use in protocols and file formats. The computation,
memory and storage required to make this conclusion may not have been available in 1996 when the algorithm was written. However, its author was well aware of the issues with the algorithm.

This raises the question of what criteria an algorithm should meet. In 2011, cryptographic hashes hoping to become the SHA-3 standard have to pass a multi-stage contest with peer review and public
comments [6]. Each is tested by the strictest standards, which must involve far more than a trivial distinguisher. As computational power grows attacks can improve using as much computational power
as available to researchers. However the takeaway from this blog post should not be that brute force should find collisions in algorithms. Instead as we look for collisions, we must remember that our
current computational power is enough to test weak algorithms.

Conclusion

The Adler32 algorithm is not complex enough to compete with comparable checksums. A class of collisions exists when the end of the stream is modified in a certain way. The likeliness of this occuring is
low enough that it can only be expected to occur in rare circumstances, but when data is modified very often (e.g. HTTP over a wireless connection) Adler32 alone is not enough to ensure integrity.
Since CRC32 is only slightly more computationally expensive and cryptographic hashes are necessary for many uses, developers today have better choices for this purpose.

More detailed information about Adler32 and comparable checksums can be found in the 2009 Maxino-Coopman paper, "The Effectiveness of Checksums for Embedded Control Networks" [7].

Works Cited

1. Gailly, Jean-Loup. "RFC 1950: ZLIB Compressed Data Format Specification version 3.3". May, 1996. URL: http://www.gzip.org/zlib/rfc1950.txt

2. "RFC 3309: Stream Control Transmission Protocol (SCTP) Checksum Change." September, 2002. URL: http://tools.ietf.org/html/rfc3309

3. Ferguson, Niels, Schneier, Bruce. "Practical Cryptography". 2003. Page 47.

4. "Revisiting Fletcher and Adler Checksums". 2006. URL: http://www.zlib.net/maxino06_fletcher-adler.pdf

5. Various. "Pigeonhole principle". Retrieved: Oct 26, 2011. URL: http://en.wikipedia.org/wiki/Pigeonhole_principle

6. NIST. "Cryptographic Hash Algorithm Competition". Retrieved: Dec 8, 2011. URL: http://csrc.nist.gov/groups/ST/hash/sha-3/index.html

7. Maxino, Theresa, Koopman, Philip. "The Effectiveness of Checksums for
Embedded Control Networks". 2009. URL: http://www.ece.cmu.edu/~koopman/pubs/maxino09_checksums.pdf

Afterword

I wish to personally thank Mark Adler for his time in providing a detailed explanation of the Adler32 checksum and known issues. His feedback on my research made this blog post factually correct and far
more useful for readers.

Code signing aims to solve two specific problems. The first problem is how to identify the author of code. The second problem is how to verify that code has not been modified after release. Truly solving one or the other would be a good step forward. That both may be solved simultaneously is a great step forward. There is a common misconception, however, that code signing represents a giant leap forward by making the signed code itself "secure". There is not a little danger in trusting code simply because it is signed, without regard to the security of its development before release.

First, a primer on how code signing works. Code signing calculates a cryptographic hash of the code, which is then digitally signed by the author and appended to the code itself. After release, the appended hash can be compared to a newly calculated hash in order to detect modification of the code. The digital signature can be compared to the author's certificate in order to also detect modification of the appended hash. Optionally, the author's certificate may be compared against a certificate authority to detect an inauthentic certficiate. Remember that this process was only designed to gurantee the authenticity of the code, that it has not been modified after release and that it was released by the expected author. None of those steps, however, can attest to the safety of the signed code; inversely, code that is not signed is not necessarily less safe.

Safety is introduced into the code signing process as a byproduct of an organization's criteria for signing code and revoking certificates. For example, developers may request that Microsoft sign the developers' drivers through Microsoft's Windows Logo program, to indicate that they have passed Microsoft's tests for reliability and compatibility. In addition, x64 architecture Windows drivers are required to be signed by the author or they will be prevented from loading, and will also be prevented from loading if the signing certificate is revoked. The signature certificate could be revoked in the event the driver is observed to be misbehaving, but by then the damage is already done and only the scope can be minimized. Microsoft could decline to sign a driver that fails to pass their tests, but in this case, security is not something for which they are testing. For signed code to be trusted as secure, and not merely as authentic, it must be reviewed for vulnerabilities.

In fact, the code signing process could incorporate an actual level of security. Large software vendors could require security reviews as part of their code signing process. In addition, large organizations with their own security team could take this responsibility for reviewing the security of applications they use, regardless of whether the author signed them, and re-distributing them internally with the organization's own signature. Smaller organizations might outsource this responsibility to a security vendor. Finally, security vendors could counter-sign code as a seal of approval to encourage adoption of a product.

The primary advantage of this approach is enabling end-users to decide on the trustworthiness of an application based on whether it has been signed by a trustworthy security team, and not merely by the author, if it is signed at all. The secondary advantage is the possibility of automatically enforcing these trust decisions at an administrative level, rather than leaving it up to careless users on a case-by-case basis. That, however, is a post for another time....

On the front page of Google news just now. The difference in the reporting style between the business and technology press has rarely been more stark.

HTTP Strict Transport Security or more commonly known as HSTS is a draft policy by the IETF WebSec working group currently proposed that would extend the standard list of HTTP response headers to allow domain owners to enroll complying browsers into exclusively secure communications with the web server for an asserted period of time.

This is accomplished by rewriting all HTTP requests to that particular domain regardless of entry (be it via link, image or manually typed in the address bar) over HTTPS and validating the certificate chain. If a secure connection cannot be established or the certificate chain cannot be verified then the request fails with a transport level error and is abandoned.

The actual implementation of this is nearly trivial. Over a secure connection the server simply has to return the header specifying how long the browser should exclusively attempt HTTPS connections and a flag whether it should include sub-domains:

Strict-Transport-Security: max-age=31536000; includeSubDomains


Under normal circumstances as long as the user has been to that domain within the max-age of the policy, this is an effective mitigation against sslstrip type attacks which rely on users to initiate an HTTP connection to perform a man-in-the-middle attack against the browsers.


One of the less understood implications of this proposal is the role that wildcard SSL certificates play. When purchasing an SSL certificate the domain owner must decide between a standard certificate that covers only one particular FQDN such as store.domain.com or a (more expensive) wildcard certificate issued to *.domain.com that would encompass multiple sub-domains such auth.domain.com and store.domain.com.

As the certificate wildcard feature is decoupled from the HSTS includeSubDomains flag it leads to interesting behavior that allows an actor such as an advertising company or any other entity to store, retrieve, and edit data in the browser's database. When a wildcard SSL certificate is used it allows the owner to have a near unlimited number of entires in the HSTS databases as currently implemented by supporting browsers.

An entry in the HSTS database can grant a single-bit of information to an interested party that can be retrieved at a later time. Lets look at an example where we want to store and retrieve the word "HELLO" in a browser's HSTS database using nothing but forum image tags and a trivial encoding.

To set the bits we would simply need to create a post with the following tags:

[img]https://charcount-5.trackingdomain.com/setbit.png[/img]

[img]https://0-H.trackingdomain.com/setbit.png[/img]
[img]https://1-E.trackingdomain.com/setbit.png[/img]
[img]https://2-L.trackingdomain.com/setbit.png[/img]
[img]https://3-L.trackingdomain.com/setbit.png[/img]
[img]https://4-O.trackingdomain.com/setbit.png[/img]


When a browser goes to each of these URLs over HTTPS the web server would see the /setbit.png key and include a HSTS header with a large max-age value in the response and create an entry in the browser's HSTS table for each of the sub-domains.


To read this data back out a javascript block on a different domain than the original forum would first brute force the character count by creating resource requests enumerating possible values and having the server respond whether the request came in over HTTP or HTTPS as the requests would have been rewritten by the browser if the sub-domain is present in HSTS database. These requests would look like:

http://charcount-1.trackingdomain.com/getbit.png [ Server: HTTP ]
http://charcount-2.trackingdomain.com/getbit.png [ Server: HTTP ]
http://charcount-3.trackingdomain.com/getbit.png [ Server: HTTP ]
http://charcount-4.trackingdomain.com/getbit.png [ Server: HTTP ]
http://charcount-5.trackingdomain.com/getbit.png [ Server: HTTPS! ]


The same brute-force enumeration process would be performed to retrieve the individual characters of the message body. This enumeration is more effective than the current history enumeration attacks via CSS (here.)

At first this approach looks like a Bloom filter. Seemingly akin to burning in bits permanently and not having the ability to change them but thanks to the max-age specifier of the header it is possible to also clear bits by setting their maximum age to 0:

Request URL: https://charcount-5.trackingdomain.com/clearbit.png
Strict-Transport-Security: max-age=0;


Initially this doesn't look worse than standard tracking cookie as long as it is cleared on a regular basis but clearing the HSTS database frequently renders it much less effective in preventing the very attacks it sought guard against. Therein lies the classic trade-off of security versus privacy. Of the currently two HSTS supporting browsers there is no consensus on this topic. Chrome opts for increased privacy by clearing HSTS database when cookies are cleared while Firefox 4 opts to store HSTS settings in the separate and infrequently cleared site-preferences database.


So what can be done about this?


My proposal is to amend the draft to force the includeSubDomains flag on wildcard certificates. This would limit them to only one entry in the browsers HSTS database and make the technique above prohibitively expensive to non-CA owners as a separate signed SSL certificate would be needed for every bit of information stored and limit encoding options. That way we can have the best of both worlds, privacy and security.

Failed Security Predictions from 2010

As most of us return from attempts to relax over the holiday season various self-proclaimed information security experts quickly scramble to do press interviews and write blog posts about their predictions on what to expect over the next twelve months when it comes to security. In a tongue in cheek Twitter post, security luminary and privacy expert Adam Shostack mused “My 2011 security prediction: 75% of predictions from people who offered predictions last year won't start with a review of how they did.”

So, before we make some predictions of our own (hey everyone is doing it) let’s review some of the more misguided and wrong predictions made by others this time last year. As I used Bing.com to search for last year’s predictions I quickly realized that not many “visionaries” were really willing to go out on a limb and predict anything that wasn’t already very obvious. So, for those that do make this list of completely off base and wrong predictions for the last twelve months, we applaud your bravery in going on the record with some truly ambitious predictions.

Taking the first two spots in our list is borderline charlatan and master of fear, uncertainty, and doubt, Verisigns very own overpaid mailing list moderator, Russ Cooper;

http://securityblog.verizonbusiness.com/2009/12/15/2010-security-predictions/

1.) RussCooper: “Social Media operators will gain more control over attackers”
This prediction was in direct contradiction with pretty much everyone else who made predictions in 2010. In fact, attacks via social networking sites clearly increased during 2010, and we have seen everything from malicious embedded ads, malicious applications, and of course the standard social engineering type attacks. While social networking sites attempt to make improvements to both security and privacy issues, they have not taken more control over attackers, and we have seen but the tip of the iceberg on how social networking can be leveraged in an attack.

2.) RussCooper: “Malware will not evolve”
I have two words for Russ on this prediction - Conficker and Aurora. Malware did in fact evolve and will continue to evolve. In fact those who want to make safe predictions can safely say that in 2011 Malware will continue to evolve as protection against said Malware also evolves. Malware protection has always been and will continue to be an arms race.

Next on our list we have a couple predictions that came from a Network World article written by Andreas M. Antonopoulos.

http://www.networkworld.com/columnists/2009/121609antonopoulos.html

3.) Andreas M Antonopoulos: “Self-propagating mobile phone worms and Trojans. Mobile security will get slightly worse as the proliferation of applications and smart devices broadens the attack surface. While we've seen worms on iPhone, they have not been self-propagating, depending on PCs to spread. Expect to see true self-propagating threats on iPhone and Android systems in 2010”

I suppose that this prediction is partially correct. Mobile and “smart” devices have grown in 2010. In fact Android devices specifically have exploded onto the scene. That said we still have not seen a large amount of attacks, malware, worms, or Trojans. I do think that this prediction will eventually become true as it is the obvious and natural evolution of threats.
Number four on our list is also from Andreas M. Antonopoulos and is very amusing and probably needs very little commentary to explain why it was completely incorrect.

4.) AndreasMAntonopoulos: “The Transportation Security Administration stops wasting billions of dollars in traveller delays by confiscating water bottles and removing shoes. Instead it focuses on real threats based on rational risk assessment, not security theater based on movie-plots (hat-tip Bruce Schneier). OK, unlikely, but I can dream, can't I?”
At least in this case the writer identified that they were in fact dreaming with this prediction, and I suppose we can respect the wishful thinking.

Halfway through our list of failed security predictions for 2010 at numbers five, six, and seven we have the analysts from Forrester Researcher.

http://biztech2.in.com/opinions/data-security/forresters-data-security-predictions-for-2010/72592/0

5.) Forrester: “In spite of the worldwide scope of botnets, we anticipate even more successes in the fight against all forms of cybercrime in 2010.”
I think all of us honestly wish that this prediction came true and while there have been some subtle wins for law enforcement in the fight against “cybercrime.” I think many would hardly consider this any form of success.

6.) Forrester: “Full disk encryption will continue its steady march into the enterprise, spurred on by breach disclosure laws”
While some more advanced enterprises may have implemented or thought of implementing full disk encryption, 2010 did not bring additional disclosure laws. Note that others who did not make this list did in fact predict more laws hitting the books in 2010, and there is no evidence of full disk encryption making any type of march into enterprises.

7.) Forrester: “Cloud data security concerns will begin to dissipate”
Much like the other Forrester predictions I am sure many of us wish that this one came true as well, but, sadly, 2010 brought multiple examples of why we should continue to be concerned about the security of the cloud and data stored in the cloud.

Coming in at number eight we have Tripwire who I almost ignored because it was painfully obvious that all of their predictions were aligned with their product offering and corporate messaging. This of course is a dangerous thing to do especially in this case where they were clearly dead wrong. They had others that were off base as well but also very clear attempts at peddling products. They will not make the list.

http://www.net-security.org/secworld.php?id=8647

8.) Tripwire: “Despite the hype of increased social networking threats, misconfigured ‘stuff’ (ie, servers, firewalls, laptops, etc) will be the real threat for companies to watch out for”
Obviously misconfigured devices are in fact a threat to an organization’s security, but threats via social networking were in the spotlight for 2010 and will probably only get worse in 2011.
Finishing off the list at numbers nine and ten we have predictions from Symantec and iDefense. Two companies who sell “Security Intelligence” that must have run out by the end of 2010 because these two predictions are clearly lacking.

http://www.symantec.com/connect/blogs/worst-yet-come-symantec-s-2010-security-predictions

9.) Symantec: “Mac and Mobile Malware Will Increase – The number of attacks designed to exploit a certain operating system or platform is directly related to that platform’s market share, as malware authors are out to make money and always want the biggest bang for their buck. In 2009, we saw Macs and smartphones targeted more by malware authors, for example the Sexy Space botnet aimed at the Symbian mobile device operating system and the OSX.Iservice Trojan targeting Mac users. As Mac and smartphones continue to increase in popularity in 2010, more attackers will devote time to creating malware to exploit these devices.”
This prediction is almost a duplicate of our third item on this list but worth mentioning, because Symantec went as far to expand from just mobile devices to Apple Mac devices. While it is very obvious that Apple’s “we are more secure” add campaign was nothing more than creative marketing and nowhere near reality, we still have not seen the predicted increase in OS-X related malware. Yes, we have seen some samples both in the lab and in the wild, but there was not a clear increase that justifies calling this out as a threat to worry about. Will it happen eventually? Maybe, but not yet.

http://blogs.verisign.com/idefense/2009/12/2010-prognostications.html

10.) iDefense: “There will be more Windows 7 vulnerabilities in 2010 than all of the Windows Vista vulnerabilities discovered in the three years since its release.”
I am truly at a loss to try and explain how a company who sells an intelligence service and purchases zero day vulnerabilities could come up with such a ridiculous prediction. A quick and non-scientific search of OSVDB (www.osvdb.org) for all Windows Vista vulnerabilities from January 2007 until December 2010 yields eighty-four (84) results. While a search for the same time period for Windows 7 yields thirty-seven (37). Granted this does not include any reported and yet to be fixed vulnerabilities, but, clearly, this prediction was off the mark.

Now that we have spent almost 1400 words poking fun at others we will stop. Our predictions for 2011 will be in a separate post coming soon.

One of the lessons I remember best from my early security career with Uncle Sam was the maxim: “crawl, don’t jump to conclusions.” Having heard of various botanic, historic and religious analysis on how the word “myrtus” - in a build path to a PDB file - clearly indicates that the Israelis are responsible for the Stuxnet worm, I have to conclude that this story has officially jumped the shark.

Here’s what the string in question looks like in ASCII:

b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb

I’ve had a bunch of SCADA security experience back in the day, and specifically with WinCC, so this path looked strangely familiar. What if we take the mystical word “myrtus” and write it like it would appear in the GUI like so: “My RTUs”.

Okay, can we stop speculating now until we have enough collective information?

Kthxbye.

P.S. Also, this really does highlight how ‘strings’ is not the best tool for reversing.

This year at ToorCon 12 in San Diego, California I will give a presentation entitled "Moving Targets.”

Location-based services are built into every major mobile platform, almost every social networking site, and more and more consumer electronics every day. These services, that record and sometimes share their users’ geographical location in real or near-real time, have been deployed by developers and embraced by users with little consideration of the threat posed by this data. An attacker who possesses the user’s location can abuse it to leverage both technical and social engineering attacks on that user. From cellular networks to web apps such as Foursquare, each layer presents a unique data set that is ripe for different attacks. In many cases, however, these threats can be mitigated with mindful application of recommendations for both location service development and usage. If you want to learn how your moving targets can avoid becoming someone else’s sitting ducks, then come to Toorcon 2010.

Please contact me directly at dkp at leviathansecurity if you have any questions or comments.

**Update: You can find the slides for this presentation here

At the Blackhat Briefings USA 2010 in Las Vegas I gave a presentation entitled "More Bugs In More Places" which was about secure development on mobile platforms.

Nothing succeeds like success, and with the attention garnered by Apple’s App Store, many companies are either looking to port existing applications to or develop exclusive applications for the top mobile platforms: Blackberry, iPhone, Windows Mobile, and Android. Each of these platforms provides the would-be developer with a SDK to do the heavy-lifting of coding, but can they be trusted to carry that weight? Just as some languages make it easier or harder to develop secure applications, so it is with SDKs. One SDK may provide robust cryptographic functions, another may restrict hardware access, and yet another may enforce strict memory management. Below are slides to the talk given at Black Hat 2010; they compare the top four SDKs in terms of the security features they provide and lack. They will help new mobile developers decide which is the safest and most dangerous for their applications.

Please contact me directly at dkp at leviathansecurity if you have any questions or comments.

You can view the presentation slides here

The last few weeks have been quite busy for researchers and IT administrators with a bevy of issues to follow and understand. While we probably cannot do all of them justice in this post, we will attempt to summarize each here for you.

We might as well start with the topic that will get the most attention today, it’s Microsoft Patch Tuesday; as most of you know this happens once a month. Microsoft released nine bulletins that address a total of eleven vulnerabilities that are assigned CVE (http://cve.mitre.org) numbers. Probably the most notable vulnerability is addressed in MS10-061; a Print Spooler Service (CVE-2010-2729) vulnerability is out in the wild being leveraged by the Stuxnet worm which is reportedly using multiple zero day vulnerabilities. There is a great blog post by the folks over at Microsoft Security & Defense outlining the risk of each of the updates. Give it a read and plan your system patching activities accordingly http://blogs.technet.com/b/srd/archive/2010/09/14/assessing-the-risk-of-the-september-security-updates.aspx.

While we are on the topic of vulnerabilities that were patched today we understand how easy it is for other issues to get buried underneath the Microsoft patch event. One such issue that many should be paying attention to is fixed in the release of Samba 3.5.5 which fixes a buffer overrun vulnerability (CVE-2010-3069). Remember Samba is not just on your favorite Linux distribution, but this will also affect Apple Macintosh OS X systems, certain network attached storage systems, and other embedded devices. While at this time we have no reports of this issue being used in the wild, it is probably only a matter of time, as even with the public release of Samba many of the alternate devices may remain vulnerable for quite some time.

Another, at this time unfixed issue which deserves our attention is being referred to as “Padding Oracle Attack.” While I know some of you will automatically think of older papers on this topic from 2002 (http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf) and then a presentation earlier this year at Blackhat Europe demonstrating a tool known as POET (http://netifera.com/research/poet/PaddingOracleBHEU10.pdf), coming up this week the brain behind POET is presenting additional research into this flaw that shows how ASP.NET web applications are vulnerable - http://ekoparty.org/juliano-rizzo-2010.php. The impact of this flaw can range from basic information disclosure to full system compromise, so we can expect this one to make a lot of noise and have an impact for quite some time to come.

As more details and analysis on all of the above issues are available we will update this post. In closing, we want to congratulate David Kane-Parry who will be presenting at this year’s Toorcon (http://www.toorcon.org) in San Diego; he will speak about Location Based Threats and Mitigations. We will have Dave post a detailed abstract of his talk here on our blog.

Cheers,
Leviathan Security Group

Welcome to Leviathan Security Group’s blog. If you need or want to know more about the minds behind Leviathan Security you can read about us here. Our goal with this Internet space is to share our opinions and ideas on Information Security topics. We will periodically write about high to low level technical topics and everything between and maybe some things outside. Posts, like this first one, will sometimes be limited to as few words as necessary, while you can expect us to go much deeper on other topics.

You can also find Leviathan Security Group on Twitter - http://twitter.com/LeviathanSec. Be sure to watch for many of our experts speaking at a security conference near you.

Thanks to everyone who supported us over the years. Hopefully this spot will inform and generate discussions.

Cheers,
Leviathan Security Group