...stuff I do and things I like...

looks like I've been selected to give a talk at EUSecWest this year. The subject will be the security of NFC (Near Field Communication) mobile phones.

My friend Alech also seems to have a talk there. This should be some fun.

another bug I found in the software of the NAS-4220-B is that you can use telnet to login to the NAS-4220-B as root without being ask for as password. This is possible right after boot of the device. The problem seems to originate from the fact that the software puts together the filesystem in ram during boot. The actual bug is that telnetd is started before /etc/passwd is populated with a root account that has a password set.

[1] raidsonic nas4220 disk crypt key leak

Found while playing with my NAS-4220-B last Sunday. RaidSonic didn't answer my emails so here you go.

--- BEGIN ADVISORY ---

Manufacturer: RaidSonic (www.raidsonic.de)
Device:       NAS-4220-B
Firmware:     2.6.0-n(2007-10-11)
Device Type:  end user grade NAS box
OS:           Linux 2.6.15
Architecture: ARM 
Designed by:  Storm Semiconductor Inc (www.storlinksemi.com)


Problem: 
 Hard disk encryption key stored in plain on unencrypted partition.


Time line:
 Found: 09. March 2008
 Reported: 09. March 2008
 Disclosed: 16. March 2008 


Summary:
 The NAS-4220-B offers disk encryption through it's web interface. The key
 used for encrypting the disk(s) is stored on a unencrypted partition.
 Therefore one can extract the encryption key by removing the disk from
 the NAS and reading the value from the unencrypted partition. The key
 itself is stored in a file in plain (base64 encoded). Therefore the 
 NAS-4220 crypt disk support can not be considered secure.


Details:
 The NAS-4220-B can hold two SATA disks. Disk are encrypted through a 
 loop back device using AES128. The problem came to my attention when
 I could access the NAS after reboot without suppling the hard disk key.
 
 The key is stored in /system/.crypt, "/system" is a small configuration 
 partition on the same disk that holds the encrypted partition. The system
 partition is created by the system software running on the NAS-4220. The
 configuration partition of the second hard disk is not mounted by default
 but also contains the .crypt file holding the key for the encrypted 
 partition on the same disk.


 Accessing the key (key value is the example I used):
  $ cat /system/.crypt
  MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
 
  key in plain           key in base64
  12345678901234567890   MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=


 Base64 decode:
  #!/usr/bin/python
  from base64 import *
  print b64decode("MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=")


Reported by:
 Collin Mulliner 

--- END ADVISORY ---

raidsonic_nas4220_crypt_disk_key_leak_09Mar2008.txt

Some guys from Princeton found a way to defeat disk encryption systems by extracting the key from the memory of a computer/laptop. While this is not really new (other people did that before), their way is quite cool. They remove the RAM module from the computer and read it in a other computer in order to do this without loosing the content of the RAM module they freeze the RAM module and with freeze they really mean freeze.

Check out the demo video.



Their paper explains it in all details. Read it if you use disk encryption and feel safe.

[1] Cold Boot Attacks on Encryption Keys (paper, video, faq, ...)

Somebody or some group seems to have found a exploitable buffer overflow in the iPhone's baseband processor. The baseband processor is the subsystem of the phone that talks to the GSM network. The overflow seems to be in the SIM Toolkit manager.

The exploit lets one upload code into the baseband, so one could insert some application into your iPhones baseband. The this application would be mostly undetectable since the memory can not be read from the application processor.

Lets see what happens with this little thing...

Source:

From: steve 
To: gsm@lists.segfault.net
Subject: [gsm] JerrySIM -> Executing shellcode on the iPhone baseband

Hi,

JerrySIM leaked yesterday. It was posted here:
http://code.google.com/p/iphone-elite/wiki/JerrySim

The exploit code has been removed shortly after but google cached it
already :/ It's out.

The program exploits a bug in the SIM Toolkit manager (which is running
on the baseband) and thus enables the execution of shellcode directly
on the baseband.

This is good work.

This has the potential to turn the iPhone into a listening device.
It still requires a lot of work and I do not know if any of the iPhone
hackers is working on it. 

regards,

steve

[1] code.google.com/p/iphone-elite/wiki/JerrySim
[2] Exploit code from Google cache

here is a patch for Dnsmasq (the very popular DHCP server and DNS forwarder and cache) that will prevent DNS rebinding attacks against private networks (192.168,10.,...). The patch basically adds a filter to the forward resolver of Dnsmasq. The filter will basically drop all private IP addresses contained in answers. Of course this will not prevent a rebinding attack against other IP ranges like if your local network uses some public IP range. But since Dnsmasq is mainly used for home Cable/DSL routers (like the OpenWRT-based routers) this patch should offer sufficient protection.

dnsmasq_stopdnsrebind.patch (for dnsmasq 2.40)

To activate the DNS rebinding protection add --stop-dns-rebinding to the dnsmasq command line. I made it a command line option since dnsmasq is also used as a DNS cache on clients (e.g. Nokia N800) and you still want to be able to resolve local IP addresses.


Feedback is welcome!

Links

DNS rebinding
DNS rebinding (wikipedia)
DNS rebinding talk (by Dan Kaminsky)
Dns-wall
Dnsmasq
OpenWRT.org
0sec

Last week I moved my last computer to full disk encryption (FDE if you need an acronym). The last computer was my desktop/laptop therefore I thought it will be slightly more work since I wanted to have suspend to disk (aka. hibernation) - it turned out to be quite easy after all (see 1).

Previously I had setup my rented root server and my home server using a small hand build system you can ssh to in order to open the root partition and continue to boot the real system (see 2).

In the recent days I did some research on possible attacks against fully crypted computer systems. Basically there is only one attack (if we rule out a brute force attack against the encryption key) this is keylogging. Keylogging basically is trying to capture all key strokes in order to obtain the passphrase for the crypted disk. Keylogging can be be done in either soft- or hard-ware both have advantages and disadvantages for both the attacker and the victim (the owner of the crypted disk).

Hardware keyloggers basically are small devices that are plugged in between the computer and the keyboard. The device then just logs all key strokes that it sees. The big advantage (for the attacker) is that this is totally OS independent. The big disadvantage for attacker of course is that he needs physical access to the victims computer twice (once to install once to retrieve the logged data). Further the victim can more or less easily find a hardware key logger if he cares to look for one. Also there are PCI-card based keyloggers (see [3]) that are probably harder to find (the computer would need to be opened). There are also keyboards with build in keyloggers (see [4]) but I doubt that these are any good since most people would recognize if their keyboard has suddenly changed. Of course you could also open up the victims keyboard and place the keylogger there, but there is always a chance that you break the keyboard while doing this. The biggest disadvantage of hardware keyloggers is that these can't monitor remote login sessions which can also be used to decrypt and boot a computer, this is where software keyloggers come into play.

Software keyloggers come in two variants, the general kernel/driver based keylogger that just monitors all keyboards and terminal devices (e.g. a remote session) and the application based keylogger where a specific application is modified so that it logs some specific or all input (e.g. the decrypt command could be modified to log the passphrase). So software keyloggers have the advantage that they can log more data (local + remote sessions) but have the big disadvantage that the attacker needs system level access to the plain not encrypted part of the computer (e.g. the boot partition) in order to place the modified kernel or binaries. If the hardware is probably secured (e.g. not booting from external disk or cdrom) the software manipulation will take really long since the hard disk would need to be removed (or at least the PC would need to be opened). Also this might not be possible at all if the victim always boots the computer from an USB stick that he carries around with him at all times. In this case there wouldn't be a plain boot partition on the PC and therefore nothing to modify. If the victim still needs to type-in the crypto password a hardware keylogger could catch him.

Laptops seem special while searching for keyloggers I only found that laptops are harder to attack since they are relatively small and therefore don't have much space to hide a hardware keylogger. The only thing I found was a Mini-PCI card based keylogger (see [5]) but since most laptops have Mini-PCI wireless cards this looks quite strange? Of course you could always disassemble the laptop to add a keylogger but this also takes a lot of time and there is always the chance to break it. The best time to do this would be if you send your laptop in for repair.

PDAs I like my Palm Tungsten T5 because it supports complete filesystem encryption. Of course this encryption is not verifiable since the source is not open but at least it is a secure algorithm (AES).

Backups don't forget to encrypt your backups. Having a fully crypted PC and plain text backup is just stupid. Good backup software should support this. Otherwise PGP/GPG your ZIPs/tarballs/whatever.

I would say that keylogging is only feasible under certain conditions: the attacker is extremely knowledgeable and the victim is some how unaware. All other cases would involve a huge portion of luck for the attacker.

[1] good starting point for crypto suspend: howto completly encrypted harddisk including suspend to encrypted disk with ubuntu
[2] small howto on: build a crypted root server
[3] PCI-based keylogger
[4] Keyboard with built in keylogger
[5] Mini-PCI keylogger
[6] USB keylogger

Marko Rogge finally published his article on RexSpy (see my comments on RexSpy). Marko and I talked a lot about RexSpy in order to determine if a bug/attack like Hafner described is possible at all.

The article is available as Blog Entry and PDF

One actually funny part of the whole story is that after I published my comments on RexSpy I got tones of emails from various people of which some seem to hope that I know how it works. So folks tried to get more information from me (I didn't have any more information). One guy even had product ideas based on this technology. Just hilarious!

some time ago I setup a new root server for a new project of a friend and myself, this time I wanted to go full crypto. In the beginning I thought this might be a lot of work but as it turned out it is quite simple if you do some thinking.

There are many ways to do this, this is how I did it.

The setup works like this: the server boots into a minimal system starting only the SSH daemon. The you login and enter/upload the passphrase to unlock the disk(s). Finally you tell the system that you are done, after which you are kicked out and the system completes the boot by mouting the real root partition and executing init from there. At this point everything is as usual.

There are two basic parts in this setup: first building a good minimal system so you don't waste too much space and second build the init script for the minimal system.

The minimal system needs to contain stuff like: sshd, filesystem tools such as mkfs, fsck, fdisk, etc., cryptsetup, networking tools like ifconfig, route, ip, etc., mdadm (if you run raid), and of course all the required libraries. The easiest way to do this is using the recovery tool your hoster provides. Just setup a minimal system on one partition and strip it down before moving it to the boot partition.

The init script is quite simple, it needs to do three things: first, configure the network (ip address and route); second, start sshd; and third, start the actual system after the root partition has been unlocked. My script works as follows: after sshd has been started the script waits for a file to be created in the tmp directory. As soon as the file is created all ssh processes are killed, and the real system is booted.


Files:

file list of my minimal system
init script for minimal system (touch /tmp/READY_TO_BOOT after you unlocked the root partition)

Some notes:

You need to encrypt your swap otherwise this is useless!
If you upload a key to your minimal system only upload to key to a ram drive, never write it to disk. Otherwise all the work is useless!
Remember your key! Remember your key! Remember your key!

Todo:

Filesystem integrity check for the minimal system. This is a very hard task and I don't have a solution so far.

I just benchmarked Aircrack-ptw on my Nokia N800 (ARMv6 320Mhz) and it finished in 19 seconds. Sadly enough the wireless packet injection doesn't work on the N800/770. 19 Seconds is quite impressive.

Erik Tews with the help of two others published a new attack on WEP called: Breaking 104 bit WEP in less then 60 Seconds.

Like the older attacks on WEP this attack uses sniffed IVs in order to break/compute/crack the WEP key. The nice thing about this attack is that it only needs between 40.000 and 85.000 unique IVs (older attacks needed between 250.000 and 1.000.000 in order to succeed). This already reduces the overall attack time since one needs to capture less packages. But the attack also uses a new/other attack on RC4 which further improves the speed. The paper gives an average of 3 seconds on 1.7Ghz Pentium-M. The attack even works with 5000 keys.

Paper
Info and tool

here are the slides on RexSpy. They say nothing at all, I just post the link for completeness.

since I first heard about RexSpy in late February (I know it was announced in October 2006) I wanted to know how real it is and how it works.

RexSpy is supposed to be the ultimate mobile phone trojan that allows one to monitor (listen to) all calls of the infected device. Also the Wilfrid Hafner (the author) claims that it works on every single mobile phone.

The German Focus (a mainstream non technical magazine) interviewed Hafner and did a trial using a SymbianOS and WinCE based phone. They claim that he could listen to calls made with both phones. Other websites like Techworld.com quote him saying that this attack also works against a Siemens C45 (which is a very simple phone with out a fancy smart phone OS).

I myself connected Hafner to find out if he is willing to release real technical information to the public about his findings, but he refused saying that he sold the RexSpy Technology and therefore no longer could publish any material. This is very bad especially because Hafner's company is selling a protection kit against mobile phone tapping. This makes you wonder if this is just a marketing thing.

Since I'm not a student anymore I don't have too much spare time on my hands so I only did some basic research. The basic operation of RexSpy as claimed by Hafner is: the trojan is install via a SMS (a Service-SMS to be precise). The trojan itself creates a kind of back channel by calling home as soon as the infected phone has an incoming or outgoing call, thereby the attacker can listen to the call. But how does this work? First idea was: a bug/feature in the GSM module or SIM card (or SIM Toolkit). A bug is kind of unlikely to be present on all platforms. A monitoring feature would be documented by someone, so this is also unlikely.

I searched a little more and found the recording of Hafner's talk at Systems, in his talk he kind of gives it away (if you know what you have too look for). He says he only implemented it for Windows Mobile (WinCE / PocketPC). That is very interesting since he first claims the RexSpy is universal across all platforms. The thing that keep me thinking is the Service-SMS which others (including myself) call binary-SMS, since I used binary-SMS for my MMS attack. Here you basically tell the device where to download a MMS message. But as far as I remember there are other binary-SMS messages (or actually WAPPush messages that are send via binary-SMS) that tell a mobile phone to go and download a WAP/WEB page. The URL could of course also point to a application binary, which could be downloaded and executed without user interaction. So maybe Hafner just found a small back door in the WAPPush handler that allows silent application installation, and writing a phone monitor tool for Windows Mobile and SymbianOS shouldn't be hard at all. For monitoring one could use the simple feature like a conference call, this way the trojan application would be very simplistic and small.

I'm still not 100% sure how it works (especially because he claims that it works with a old Siemens C45) but analyzing the Windows Mobile RexSpy Killer provided by SecurStar should bring me a step further (I haven't done this yet). I'll keep working on this and keep you updated.


I would really love to hear some comments on this.

Links:
Zone-H
Techworld (Hafner's talk at Systems in German language)
SecurStar

I just uploaded the web page I made for HID Attack. It explains how it all works. Enjoy.

Finally I released my HID attack kit I build over a year ago, get it here. Thanks to Thierry for including it in his talk!

Story on Heise.

Gary McGraw's Silver Bullet Podcast is a real nice podcast on computer security. If you are a security person check it out!

The Reliable Software Group (RSG) the lab I used to work for at UCSB finally put up the new website including all my Smart Phone Security research. I also put up my Master's Thesis titled Security of Smart Phones.

I also updated my Mobile Security Research website.

I'm going to do my 0wnd by an MMS talk at 23c3. The talk is more or less a redo from defcon-14, but I will try to fix it up a little. This will be my first talk at a Chaos Communication Congress and I'm already looking forward to it.

my second scientific paper, this time at ACSAC. The topic is MMS again - actually the paper was done before DEFCON. For more infos see details for Session 2. The paper is the last one in the session.

PS: I also applied to 23c3 with the same topic aka the DEFCON talk.

I'll be giving a talk at this years defcon (#14). My talk will be on Advanced Attacks Against PocketPC Phones and I will show some neat new stuff for/against PocketPC phones.

I've added greylisting to the list of spam countermeasures for our server project. It works surprisingly well and the amount of spam arriving at my inbox is reduced by a ratio of 20:1. While this is good there are of course downsides of greylisting such as an artificial delay for delivery of valid or good email. Also auto whitelisting should take care of regular contacts. Anyway I'm really interested in how many of our users will see the change in amount of spam vs. delivery delay, and if anyone of them will demand permanent whitelisting :-)

My (with others) first scientific paper: Using Labeling to Prevent Cross-Service Attacks Against Smart Phones

just put up my mobile security research page. It will basically be a annotated link collection, since my stuff will mostly be PocketPC Security and I have a separate section for this. Feel free to send me additions and/or corrections.

Pierre Betouin wrote this nice little L2CAP fuzzer based on my psm_scan (l2cap port scanner). He also already discovered bugs in several phones with it.

The tool can be found at: www.secuobs.com

nice work!

mh57 just pointed me to a Spiegel Online article about Bluetooth advertising or BlueSpam as I like to call it. Its about a German company which uses Bluetooth to beef up their billboards in Berlin. Apparently they just push images, videos, text ads and coupons to any Bluetooth device in range. This is annoying but you can of course just ignore/reject the transmission or turn of visibility. The actual security/privacy problem is that people maybe get used to accept connections from certain senders e.g. BlueSpam (of course you wouldn't name your system BlueSpam). So what keeps me from standing next to one of the billboards naming my laptop BlueSpam and instead of sending a coupon I send hello.jpg. And since some phones still don't show what the Bluetooth connection is for I just pull their phonebook etc., the user will just see Allow connection from BlueSpam? Sure I want that coupon.

This is not a good idea!

Btw. the company doing this stuff is: Wall AG

on Friday Dec. 09. another UCSB iCTF took place once again. As always I was just helping out (the main work is done by others Greg,Vika and Marco) writing services, placing backdoors and doing what ever is needed. Every time the event gets bigger and bigger, this time there were 22 teams with about 20 players each plus 2-5 admins for each team and about 10+ people at UCSB organizing - this is about 500 people!

In the last years teams from Italy dominated the CTF, but not this time! The winners are all German speaking #1 Aachen, #2 Vienna and #3 Darmstadt. The full scoreboard with all teams is here.

This was really fun, even for just watching the teams fighting each other :-)

I all ways wanted to go crypto for my data storage but until now I never owned any big storage device. Now I have an external 250 gig USB disk which I want to secure.

The thing with crypted disk all ways comes down to where can I read the disk? Only on my computer, only with one specific OS, etc. For me it's basically Linux and from time to time Windows. The two solutions I found where BestCrypt which is commercial (at least for Windows) and dm_crypt/FreeOTFE which is free and has much more features.

I ended up using dm_crypt/FreeOTFE.

dm_crypt is the Linux part of the crypto solution and is in part of Linux Kernel since 2.6.4. With cryptsetup its super simple to setup. You can setup a partition or a file based crypto device. The device then can be formated with whatever filesystem you want. Of course you need one which is readable by Windows (e.g. vfat/fat32).

FreeOTFE is the Windows counterpart of dm_crypt and can mount whatever you created with dm_crypt. I guess multi-disk volumes don't work but I haven't tryed it. When mounting a filesystem use mount Linux... otherwise it doesn't work :)

For the external USB disk I have two partitions, one small partition which is not encrypted - this holds the Windows drivers (FreeOTFE), the second partition is the crypto filesystem. With this you can also take your disk to a friend without downloading drivers and stuff from the net. All in all a nice solution.

MobileBugtraq is a new bugtracking maillinglist dedicated to mobile device technology. The list is super new, so not many posts by now. I actually only saw two sofar and I couldn't find an archieve.

Anyway everybody who is into mobile and security (like myself) should check it out.

while doing some web research on PDA/phone security I found this company Paraben which sells special seizure equipment for PDAs and phones. They really sell a lot of crazy stuff. I especially like the StrongHold Tent (the image on the left).

today (at/for 21C3) Martin and I released our Bluetooth fingerprinting tool BluePrint.

It is a really nice and simple Perl script and just reads the output of sdptool (BlueZ). Please also check the Bluetooth Device Security Database.

I just started learning how to write exploits utilizing buffer overflows. It is a real fun thing to do and the best part of all: it is a part of a homework for university :-) Now I know why many people write exploits it is a nice way to get around a rainy weekend day.