FortiGuard Labs Threat Research
Welcome back to our monthly review of some of the most interesting security research publications. July was very busy with the annual DEFCON and BlackHat US conferences, but also RMLL, the Worldwide Free Software Meeting held this year in France.
With the nickname "Crypto Girl", I obviously had to listen to this talk, and I initially thought it would be great. After listening to it, I decided it was not just great, it was EXCEPTIONAL. I'm going to try to summarize the main points here.
The authors were able to craft two documents that hash the same with SHA1. This does not work with any document, but only with documents they specifically make themselves for this attack.
So, if you provide them with a given document of your own, they most probably won't be able to craft a collision. First of all because, so far, their collision only works for PDF documents. But even if you supply a PDF document, they can't create a collision (except for a few lucky exceptions) with your exact document. Rather, what they do is create another document that looks like yours and for which they know how to create a collision. Subtle :)
I am absolutely not trying to downplay their attack. Their work is wonderful. I just intend to clarify the differences between a collision attack (which is what they have), and first or second pre-image attacks. For more on this, see Wikipedia or slides 7 to 9 from their presentation.
It is very easy to generate colliding PDF documents. Proof? I generated one myself in a few seconds using this tool.
See the screenshot below of two obviously different PDFs:
These documents are clearly very different. And yet, they produced the same SHA1 hash:
$ sha1sum out-*.pdf 510f340e2341c83066f64398fa1bc45b8644d1e5 out-blog.pdf 510f340e2341c83066f64398fa1bc45b8644d1e5 out-iot.pdf
Note that the tool takes as input two PDFs, and generates as output two other PDFs, which display like the originals but produce a SHA1 collision.
If it's so easy to generate a collision, why did it take the authors so long to compute one, you might ask? Their research was long because they had to find the right file prefix and collision blocks. That's the long part. Once this is done, the tool just re-uses the work to use the right blocks and adjust to the input, and that's very quick.
The authors showed this has an impact on:
I'll keep this part very short, as it's better to follow the slides or the video. However, the main idea consists of inserting specific near-collision blocks in the middle of the files to manipulate the hash result. These near-collision blocks also cause the PDF to display a first JPEG image in one case, and another JPEG image in the second case.
See slides 17, 18. and 35.
In this talk, the authors showed how they opened a home router, located the EEPROM holding the firmware, and dumped the firmware from the EEPROM using the HydraBus SPI interface. Then, they connected two pins labeled TX1/RX1 to HydraBus, captured the signal that they viewed on their PC using a logic analyzer, and found they could communicate with the router using USB. They connected to the home router via the TX1/RX1 pins using HydraBus as a USB bridge and got access to a serial console on the router!
The hardware can be purchased for approx. 70 euros. It is a handy tool, provided you have hardware knowledge (you need to be able to spot the rights pins, protocols etc). I am not sure if it supports Bluetooth Low Energy. However, it supports many things, such as CAN buses (automotive).
Password managers are definetely convenient to remember passwords - especially on smartphones where typing long passwords isn't easy. The problem is that many password managing apps - even some from serious companies - have serious flaws.
am start.... For example, it's possible to display the settings window and reset the security question ;)
am start activity --ei intent.... That's how the authors get the premium version of an Android app for free ;)
Wow. Has the development of those Android applications been done by a first grade intern?!
There are several ways to hook the functions of Android apps:
In this talk, the author presented ParaSpectre, which is a JRuby hooking tool for Android, based on Xposed.
This was a good talk about Android obfuscators, packers, and protectors. There are already several talks about this, including my own paper in Virus Bulletin in 2014 ;) The good thing about this one is that it mentions the ART and how DEX files are converted to OAT.
The authors also provided a tool to unpack Android applications.
Note: this will take quite a long time to compile, because you need to clone the AOSP project and then patch it.
This talk was about finding hidden instructions in processors.
The problem is that instructions can be between 1 and 15 bytes long, so it would take too long to try all possible instructions.
In this paper, the author came up with an interesting idea for guessing the length of an instruction. He configures two consecutive pages in memory: the first one with read, write, and execute permissions, and the second one only with read and write. He then places his attempted guess instruction with the first byte in the first page, and the rest in the second page. Next, he executes the instruction. If the instruction has more than one byte, fetching the second byte will generate a page fault. Note as well that if the instruction does not exist, this will generate an invalid opcode exception. He then does the test again, only this time placing the first two bytes in the first page. This allow him tests if the third byte is needed or not, etc. In the end, he is able to determine the length of the instruction.
The author scanned several processors and was able to find hidden instructions and bugs :) His tool is available here.
Smart guns are (in theory) guns which can only fire when authorized. This talk analyzes the security of the Armatic iP1 pistol. This pistol is coupled with a smart watch. When you wish to fire, the pistol sends an authorization request to the watch. The watch responds with an authorization token, which is validated (or not) by the pistol, and then the pistol fires.
Plore was able to perform three different attacks:
IMHO, this is funny and interesting from a hardware perspective, but not extremely useful. By the way, even a distance of 25cm can be dangerous: what if an attacker fights with the owner and turns the smart gun against him? The pistol will still fire.
Plore demoed the DoS with his own low cost transmitting device. It would have been interesting to also demonstrate a DoS with a cordless phone or other common device.
This vulnerability has nothing to do with computer science, but it is certainly the biggest fail for the smart gun! Note that similar issues are also seen on smart locks. Lesson learned: when building "smart" hardware, ensure the hardware is mechanically safe and secure.
-- the Crypto Girl
Quote from Vocabulary: "A researcher is someone who conducts research, i.e., an organized and systematic investigation into something. Scientists are often described as researchers". Somebody who searches for his keys or ... malware is not a researcher but a Seeker.
Sign up for weekly Fortinet FortiGuard Labs Threat Intelligence Briefs and stay on top of the newest emerging threats.