On Monday the 28th of September 2015 a rather rare event occurred. At around 4 a.m. the moon changed its colour into a dim of red, luckily the sky was clear enough to see something.
As TROOPERS15 has come to an end, I’ve finally got the time and energy to give you a deeper insight into the TR15 badge. As most of you have probably heard during the conference, this year’s badge was based on the OpenPCD2. The OpenPCD 2 is a 13.56MHz NFC Reader, Writer and Emulator under the GNU GPL v2. As NFC is, yet again, on an uprise, a badge with NFC simply gives you the chance to fiddle around and hack stacks of stuff in the real world. Adding some TROOPERS spirit and a few little secrets we hope we’ve designed a pretty nice badge! Continue reading “Troopers 15 Badge”
Simple everyday work dialog:
“The heater in the basement is still missing a proper thermostat, the ‘binary solution’ isn’t that effective”
– “Buy one…”
– “Ok”
– “Get one you can break…”
– “Ok, but then I’d like a few tools, too”
– “Go for it.”
(That’s the way work should be!)
Result of the dialog: a Danfoss Living Connect Z ( 014G0013 ) and a TI CC1100 Wireless Mini Dev Kit plus a copy of Z-Force to start with. Goal: Talk to the thermostat!
TROOPERS14 has come to an end, and it’s finally time to let you have a go at the Badge’s source code. As promised, it was slightly modified and extended, to show you the full potential of your new gadget. I’ve added some nice payloads from Nikhil Mittal and a few own ones. Above that, for those who took their parts for soldering home, I’ve also added a few quick instructions on how to do the soldering.
Greetings from the Print Media Academy in Heidelberg. Just in time for TROOPERS14, I’ve got the great honor to present this years badge!
Being a TROOPER is tough: You need to know loads of information, learn even more and be able to work fast.
This year we decided to increase your efficiency and speed when collecting data from computer systems and, let’s say, hacking them! Your newest gadget is based on a plain Arduino Leonardo, modded with one of our famous shields. After adding a few LEDs and buttons, it will power up to full functionality. Continue reading “A TROOPER’s Keyboard”
I recently got in contact with Intel AMT for the first time. Surely I had heard about it, knew it was “dangerous”, it was kind of exploitable and had to be deactivated. But I hadn’t actually seen it myself. Well, now I have, and I simply love it and you will probably, too (and don’t forget: love and hate are very very close to each other 😉 )
The following blogpost will be a set of features and instructions on how to own a device with an unconfigured copy of Intel AMT without using any complicated hacks or the famous magic! Continue reading “How to use Intel AMT and have some fun with Mainboards”
As a lot of people were asking for, here comes the code of your badge. All You need to customize your badge, is a micro controller programmer, like the Pickit (its around 30 to 40 euros) and the build environment, MPLAB which you can get for free. Then just download the code and implement your own super cool features. Let us know what you did, the best hacks will get into the TROOPERS hall of fame (-; Continue reading “TROOPERS13 – The Badge Code”
There is a common misconception that the sheer amount of data coupled with multiplexed channels (e.g. WDM technology) make successful eavesdropping attacks on high speed Ethernet links – like those connecting data centers – highly unlikely. This is mainly based on the assumption that the amount of resources (e.g. RAM, [sufficiently fast] storage or CPU power) needed to process large files of captured data is a limiting factor. However, to the best of our knowledge, no practical evaluation of these assumptions has so far been performed.
Therefore we conducted some research and started writing a paper (to be released as a technical report shortly) that aims to answer the following questions:
– Can the processing of large amounts of captured data be done “in a feasible way” ?
– How much time and which type of hardware is needed to perform this task?
– Can this be done with readily available tools or is custom code helpful or even required? If so, how should that code operate?
– Can this task be facilitated by means of public cloud services?
We performed a number of tests with files of different sizes and entropy. Tests were both carried out with different sets of dedicated hardware and by means of public cloud services. The paper describes the tools used, the various test setups and, of course, the results. A final section includes some conclusions derived from the insights provided by the test sets.It is assumed that an attacker has already gained access enabling her to eavesdrop on the high speed data link. A detailed description how this can be done can be found e.g. here or here. The focus of our paper is on the subsequent extraction of useful data from the resulting dump file. It is further assumed the collected data is available in standard pcap format.
We’ll summarize some of the stuff in a series of three blog posts, each discussing certain aspects of the overall research task. In the first one we’ll describe the tools and hardware used. In the second we’ll give the results from the test lab with our hardware while the third part describes the tests performed in the (AWS) cloud and provides the conclusions. Furthermore we’ll give a presentation of the results, including a demo (probably the extraction of credit card information from a file with the size 500 GB which roughly equates to a live migration of 16 virtual machines with 32 GB RAM each) at the Infoguard Security Lounge taking place on 8th of June in Zug/Switzerland.
Last but not least before it get’s technical: the majority of the work was performed by Daniel, Hendrik and Matthias. I myself had mostly a “supervisor role” 😉 So kudos to them!
COTS packet analysis tools
A number of tests utilizing available command-line tools (tethereal, tshark, tcpdump and the like) were performed. It turned out that, performance-wise, “classic” tcpdump showed the most promising results. During the following, in-depth testing phase two problems of tcpdump showed up:
– It’s single-threaded so it can’t use multiple processors of a system (for parallel processing). Given the actual bottlenecks to be related with I/O anyway (see below) this was not regarded to be major problem.
– Standard pcap filters do not allow for “keyword search” which somehow limits the attack scenarios (attacker might not be able to search for credit card numbers, user names etc. but would have to perform an IP parameter based search first and then hand over to another tool which might cause an unacceptable delay in the overall analysis process). To address this limitation Daniel wrote a small piece of code that we – not having found an elegant name like Loki so far 😉 – called pcap_extractor.
Pcap_extractor
This is basically the fastest possible implementation of a pcap file reader. It opens a libpcap file handle for the designated input file, applies a libpcap filter to it and loops through all the filter matching packets, writing them to an output pcap file. Contrary to tcpdump and most other libpcap based analysis tools, it provides the possibility to search for a given string inside the matching packets, for example a credit card number or a username. If such a search string is applied, only packets matching the libpcap filter and containing the search string are written to the output file.A call to search a pcap file for iSCSI packets which contain a certain credit card number and write them to the output file would then look like:
The source code of pcap_extractor can be downloaded here.
Identifying the bottleneck(s)
While measuring the performance of multiple pcap analysis tools the profiling of system calls indicated that the tools spend between 85% and 98% of the search time on waiting for I/O. In case of the fastest tool that means 98% of the time the tool does nothing, but waiting for dump data. So the I/O bandwidth turned out to be the major bottleneck in the initial test setups.
Actual lab setup
The final test system was designed to provide as much I/O bandwidth as possible and was composed of:
Intel Core i7-990X Extreme Edition, 6x 3.46 GHz
12GB (3 * 4GB) DDR3 1600MHz, PC3-12800
ASRock X58 Extreme6 S1366 mainboard
4 * Intel 510 Series Elm Crest SSD 250GB
The mainboard and the SSDs were chosen to support SATA3 with a theoretical maximal I/O bandwidth of 6 Gbit/s. FreeBSD was used as operating system.
===
In this post we’ve “prepared the battle ground” (as for the tools and hardware to be used) for the actual testing, in the next one we’ll discuss the results. Stay tuned & have a great day
