Security Research News in Brief - July 2017 Edition

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.

Past editions:

• June 2017
• May 2017
• April 2017
• March 2017

Elie Burzstein et al, How We Created the First SHA-1 collision and what it means for hash security video, DEFCON 25 and paper

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.

Collision

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.

How easy / difficult is it in practice?

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

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.

Impact

The authors showed this has an impact on:

• Browsers. In the past, we have seen clever malware use MD5 collisions on an X.509 certificate (see Flame). The same thing could happen again with SHA1. Consequently, Firefox, Chrome, Internet Explorer, and Edge have deprecated SHA1 (e.g validation of certificates).
• Git internally relies on SHA1 :( A clever attacker could use SHA1 collisions to have people retrieve completely different documents from the repository. Git intends to move away from SHA1, but this will take some time. Meanwhile, a tool has been created that detects potential collisions. This tool is being run for each commit at Github, for example.

How it works

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.

B. Vernoux and N. Oberli, HydraBus - an open source platform, RMLL, July 2017 slides

HydraBus can be seen as the hardware swiss knife for IoT devices. It's an (open source) piece of hardware with many connectors meant to help debug / inspect / reverse IoT hardware.

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).

S. Huber and S. Rasthofer, Bypassing Android Password Manager Apps Without Root, DEFCON 25, slides

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.

• Developers think in terms of user interface logic "if you press here, you go there". But, with Android, it's possible to bring up any activity (i.e user interface element) using the shell command am start.... For example, it's possible to display the settings window and reset the security question ;)
• Same, developers assume intents and actions come from legitimate sources, but, actually, it's quite possible to issue an intent with a shell command am start activity --ei intent.... That's how the authors get the premium version of an Android app for free ;)
• There are many other stupid errors such as hard-coded keys or naively obfuscated keys, use of HTTP instead of HTTPS.

Wow. Has the development of those Android applications been done by a first grade intern?!

Jeff Dileo, Ghost in the Droid, DEFCON 25 slides

There are several ways to hook the functions of Android apps:

• LD_PRELOAD
• JWDP: requires debugging capabilities
• Frida: requires root access. Hooks can be developed using Javascript.
• Xposed Android framework: requires ability to modify a system image. Requires root as well.

In this talk, the author presented ParaSpectre, which is a JRuby hooking tool for Android, based on Xposed.

A while ago, I tested Frida to enable/disable logs in an Android application. Although, I hate JavaScript, I liked Frida very much. I would have been interested in better understanding the benefits of ParaSpectre over Frida or Xposed.

S. Makkaveev and A. Bashan, Unboxing Android, DEFCON 25, slides

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.

Christopher Domas, Breaking the x86 Instruction Set, BlackHat US paper slides

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.

Plore, Popping a Smart Gun, DEFCON slides video

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:

• Defeat proximity. Normally, the pistol can only fire if the gun is close (25cm) to the watch. This restriction is handled by the communication between the pistol and the gun, which uses the 5.35 kHz frequency. Plore relayed the signal over 2.4 GHz, thereby extending the acceptable distance to three meters.

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.

• Denial of service. By interfering with the frequencies of the smart gun, Plore was able to perform a DoS because either the authorization token was never requested or it was never received. The awesome part is that many devices can interfere with the smart gun: Plore mentioned cordless phones for instance. Meaning if that someone is using a cordless phone nearby, the gun won't 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.

• Fire without authorization. Mechanically, the smart gun is prevented from firing by ... an electromagnet. So defeating the system merely consists in placing a big magnet close to the smart gun.

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.

Miscellaneous

• RMLL 2017 security track
• DEFCON 25 material, schedule

-- 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.