THC Blog

The nice underground magazine Uninformed v10 came out today.
Kinda reminds me of the old days of underground magazines. Fine to see that there are still several around.

What is special about issue 10?
HD Moore talks about penetrating systems via IPv6, and hypes our thc-ipv6 attack toolkit
Thanks HD Moore, and the article sure is a read.

Have fun guys, here is the link:
http://www.uninformed.org/?v=10&a=3

Today vonJeek/THC released his tool and a video how to duplicate (clone) and modify
a Passport with RFID chip.

http://freeworld.thc.org/thc-epassport/

The weakness is in the way the system has been rolled out. The terminal accepts
self-signed data.

This attack is different to the grunwald attack. VonJeek's attack makes it possible to copy,
forge and modify the data so that it is still accepted as a genuine valid passport by the terminal.

Using a Certification Authority (CA) could solve the attack but at the same time
introduces a new set of attack vectors:

1. The CA becomes a single point of failure. It becomes the juicy/high-value target for the attacker.
Single point of failures are not good. Attractive targets are not good.

Any person with access to the CA key can undetectably fake passports. Direct attacks, virus,
misplacing the key by accident (the UK government is good at this!) or bribery are just a few
ways of getting the CA key.

2. The single CA would need to be trusted by all governments. This is not practical as this
means that passports would no longer be a national matter.

3. Multiple CA's would not work either. Any country could use its own CA to create a valid
passport of any other country. Read this sentence again: Country A can create a passport data
set of Country B and sign it with Country A's CA key. The terminal will validate and display the information
as data from Country B.

This option also multiplies the number of 'juicy' targets. It makes it also more likely for a CA key to leak.
Revocation lists for certificates only work when a leak/loss is detected. In most cases it will not
be detected.

Note: The last item received some comments. Some readers suggested that this can be fixed. Yes,
of course, any system can be fixed. Indeed it would be a first good step by the terminal to check
that a passport from country A is also signed with the CA key of country A and not by the CA key of
country B.

The current implementation and plans make it unlikely that this will be implemented securely. In the
end we are trusted those people who gave out ePassports that can be read by anyone and not just
authorized terminals. We are trusting those people who say that good security practice to verify
the validity of a passport is optional and not mandatory.

So what's the solution? We know that humans are good at Border Control. In the end they
protected us well for the last 120 years. We also know that humans are good at pattern
matching and image recognition. Humans also do an excellent job 'assessing' the person
and not just the passport. Take the human part away and passport security falls apart.

    Never let a computer do a job that can be done by a human.

Let's take a look at a few other things now possible with ePassports:

ePassports aid Data Theft:

The 3 meter barrier has recently been broken for reading RFID data (e.g. your ePassport data)
from a distance 3 meters away. Attacks always get better. They never get worse. The next barrier
is 5, 10 and 20 meters.

An attacker can read the data from your ePassport (while you walk in the street!) and can use
your credentials to authenticate himself or duplicate your passport.

ePassports aid Terrorism:

Thanks to the ePassports is it now possible to build Smart-IED's. A Smart-IED waits until
a specific person passes by before detonating or let's say until there are more than 10
americans in the room. Boom.

Do ePassports make you feel more safe now as the government says they would do?

Dont get me wrong. Here at THC we love technology but we dont trust it.


Interesting times,

The Ministry Of Truth
http://www.thc.org

During one of my recent projects, it became necessary to undelete files from a Windows Mobile device. Unfortantely, there are no free, reliable tools that will do this. Also, the device that I needed to do this on, was configured so as to not allow 3rd party apps to run on it, limiting my options. Now, you'd think "i'll just google this' but alas, even google will not tell you how to do this. So after a few hours of poking around I found this solution that I thought I'd share with you just so that the next time someone googles this, there actually will be 1 relevant hit.

The steps are quite simple. First download http://nah6.com/~itsme/itsutilsbin-20080313.zip
Hook up your windows mobile device to your activesync host. You need active sync for this to work.

Unzip and find loads of funky utils written by Dutch hacker Itsme.

Most windows mobile devices run their disk partitions on a chip called DiskOnChip (DOC). Older devices us DOC 3, newer ones DOC 4. One of the utils we need is pdocread.exe. The first time you run any itsutil, it'll upload a dll to the device that performs the low-level functions. First, we run from a dos box:

pdocread -l

This will list all disks and partitions on your device and the hex file handle.

To find the actual size in blocks of the partition, you need to address the partition using the hex file handle:

pdocread -h -t

This will tell you the amount of 512-byte blocks you will be reading.

then we create the disk image:

pdocread -h 0 0xamount_of_blocks

So you now have created a bytewise diskimage of your windows mobile partition. Note that this is also very handy for:
-backups
-forensics
-FAT analysis

So........ transfer this disk image to your linux machine. Now we download TestDisk, an excellent, free, disk repair utility that will run under most OS's.

First we need to calculate the offset for this disk image:

sfdisk -uS -l

Under the column 'start' you'll see how many blocks into the image the actual partition starts. usually, for DOC images this is 32 blocks. 32blocks*512 bytes=16384. We can now simply mount and/or create a loop device:

mount -o loop=/dev/loop1,offset=16384

Then run testdisk /dev/loop1 to recover files or do other funky stuff.

Works like a charm....

Today fyodor/nmap gave a talk at defcon ("Nmap: Scanning the Internet"). It was one of the better if not the best presentation at defcon for me. Fyodor presents his research with a lot of charm, fun and motivation.

Nmap can now be used to scan the entire Internet.

Before joining THC I was doing research for Team-Teso. In 2000 one of our problems at Teso was that many script kiddies entered the arena
and started setting up DDoS hosts and owning like mad. Hacking became mainstream.

At Teso we did not like script kiddies and we abhorred those doing DDoS. A small group of Teso and some friends reverse engineered the backdoors and started scanning for them. Our objective was to discourage script kiddies and stop DDoS attacks (by removing the DDoS agents).

Techniques

We developed a new scanner (called 'bscan', not published but a handful of people had it) that was capable of scanning
the internet.

The main features of bscan were:
- Raw SYN scanner. Full TCP/IP stack in userland.
- Using ghost IP and ghost MAC (untraceable)
- Modular. We developed loadable modules for telnet handshake, bind, http (HEAD / HTTP/1.0), ...
- Sending out 50.000 or more syn packets per second.
- Running on linux, sunos/solaris and bsd.

In short the scanner was capable of scanning the entire Internet (0.0.0.0 - 239.255.255.255). The scanner retrieved all Web Server versions
or telnet banners within hours.

Fyodor's nmap was developed for a different reason. The features of nmap are far superior to bscan. Bscan was a tool and nmap is a professional application.

Results

All this is history now and I think that 7 years after the development the time has come to share some of the stuff that we learned
while scanning the Internet:

1.	The Internet is full of hosts that do not comply with the RFC.
2.	There are hosts on the Internet that keep sending ACK packets for hours even if you send back FIN, RST or ICMP error messages. They just wont stop sending!
3.	Sometimes you send a SYN to one host and you get the SYN/ACK back from a different host (asymmetric NAT).
4.	There are entire class A networks with no hosts in them at all (The Black Holes of the Internet).
5.	Never scan sequential. If a remote class B or class C is hit with 50k SYNCs per second the serving router of the target network will start sending out ARP requests to resolve the MAC of all these hosts. ARP requests are broadcast messages. This will overload some hosts on the target 'local' network which will crash or not respond for several seconds while processing the ARP requests. You will miss those hosts. Scan 'spread spectrum' and increment the IP by 256 or a similar value.
6.	The first syn packet is often lost. When scanning 10-20 class A networks in 'spread spectrum mode (-X option in bscan) then the router of a large network (e.g. class B) still has to resolve several hundred ARP entries per second. Some routers can not handle this and will start dropping SYN packets if the MAC is not known and can not be resolved because the router is already busy resolving other MAC addresses.
7.	Coordinate with your people that you are the only one scanning the Internet. Same reason as above: If two people scan at the same time the target hosts have to process to many ARP requests and both of you will miss hosts.
8.	Never wait longer than 3 seconds for a host to complete. If it takes longer than 3 seconds for a host to reply you are not interested in owning that host anyway.
9.	Be kind to other administrators. We set up a charity ("The Institute for Internet Statistics") to have a reasonable explanation for any IT administrator who complained about our scanning activities.

The scanner was usually started on 5-10 Internet hosts in parallel. A big thanks at this point to the IT Administrators of the
various universities in Germany who let us use their hosts for scanning (legally!).

A typical TCP port scan of the Internet took between 8-16 hours.

Stories

There was a nice side effect of cleaning the internet from script kiddies and their backdoors: Teso had a full list of all
server versions of all hosts on the Internet. No longer had team teso to scan for vulnerable hosts. We just looked them up in our
log files.

One day one of the German hackers who helped Teso came home drunk and decided to start another scan for a script kiddie
backdoor that was running on TCP port 33645. He initiated a scan and set source port to 443 and destination port
to 33645. The morning after (and being sober again) he saw that various security mailing lists discussed a new
0-day vulnerability against HTTPS (port 443). Apparently someone was scanning with massive speed the HTTPS ports on
the Internet. He looked again of what scan he started the night before: He mistakenly swapped source and destination port while drunk and scanned for port 443 instead for port 33465.

These mails can still be found on the archives of various mailing lists around xmas 2002.

Lesson learned: Do not drink & hack.

We were not the only ones who scanned the Internet. We heart of an Israeli research group who did it in 1998.

In 2002/2003 Dan Kaminsky published another tool called scanrand. His tool is public. Try it.

Final Notes

These days bscan is old and not up to date anymore.

Whatever you do make sure it's legal and does not cause trouble to other people.


regards,

someone

I was leaving today from the United Kingdom/Heathrow airport. I am about to speak at the HITB IT security conference about GSM security and the USRP (gnu-radio project).

I was searched by British authorities while waiting at the Gate and reading a newspaper. A UK Government employee flipped his badge and said "Let's talk. Come over here".

They detained my USRP (Software Defined Radio), my mobile phone and my personal SIM card.

I informed them about my work and any possible risk in January before I was giving a talk about GSM security at Blackhat/Washington DC. They knew who I am, where i live, which day I speak at the conference and who I work for.

I'm involved in the GSM software project where we also developed a new attack against the GSM encryption A51. We published our research in February at the Blackhat security conference in Washington DC.

I understand that the government wanted to make sure that I'm not exporting any cryptanalytic device.

I did not. I will not. The USRP is a radio. My mobile phone is a normal nokia 3310 phone and my SIM card is a sim card.

They said they do not know what the USRP is and that I can not take it until they have checked it in the lab. This can take 14 days (1/2 month).

So be it. They have it for 14 days. Guys, enjoy the device! It's fun playing around with it!

I'm uneasy that they took my mobile phone and my sim card. Having a pregnant wife at home and not being reachable complicates my situation.

Is this common practice? Are they allowed to do this?
Any tips how I can get my mobile phone and my sim card back quicker?

Our project: http://wiki.thc.org/gsm
The USRP is available from http://www.ettus.com
The GNU RADIO project: http://www.gnu.org/software/gnuradio


stunning,

THC
---
Appendix: Surprisingly they did not detain my laptop or my paperwork which would be the most likely place to store any information related to cracking A51. They were also not interested in my 160GB harddrive which would have been the obvious place for storing the rainbow tables. Neither were they interested in the high performance FPGA chip.

Instead they took all equipment that could have been used for demonstrating that GSM signals can be received with publicly available hardware for 700 USD.

It does not appear that they were after cryptanalytic information.

I received a yellow paper about my detained goods. They left the field blank that reads
"The goods specified below are detained for the following reason:". What reason?

---
UPDATE 2008-04-18
Arrived back at Heathrow. Airplane crew announced "All passengers please have your passport ready. There is a passport check while leaving the airplane. Passenger Steve Mueller please make yourself noticeable to the crew. Steve Mueller please."

They told me at the gate that I can get my equipment back. I had a chat with them and they answered many of my questions. They did not answer who requested that I should be searched when I left the country.

I'm happy that I got my equipment back and I appreciate that they had it checked out quickly.

I'm still not sure why they took exactly the radio receiver parts. I had to change my presentation for the conference and was not able to demonstrate the USRP/gnu-radio.