HITB Amsterdam 2017 Day #2 Wrap-Up

After a nice evening with some beers and an excellent dinner with infosec peers, here is my wrap-up for the second day. Coffee? Check! Wireless? Check! Twitter? Check!

As usual, the day started with a keynote. Window Snyder presented “All Fall Down: Interdependencies in the Cloud”. Window is the CSO of Fastly and, as many companies today, Fasly relies on many services running in the cloud. This reminds me the Amazon S3 outage and their dashboard that was not working because it was relying on… S3! Today, all the stuff are interconnected and the overall security depends on the complete chain. To resume: You use a cloud service to store your data, you authenticate to it using another cloud service, and you analyse your data using a third one etc… If one is failing, we can face a domino effect. Many companies have statements like “We take security very seriously” but they don’t invest. Window reviewed some nightmare stories where the security completely failed like the RSA token compromization in 2011, Diginotar in 2012 or Target in 2013. But sometimes dependencies are very simple like DNS… What if your DNS is out of service? All your infrastructure is down. DNS remains an Achille’s heel for many organizations. The keynote interesting but very short! Anyway, it meant more time for coffee…

The first regular talk was maybe the most expected: “Chasing Cars: Keyless Entry System Attacks”. The talk was promoted via social networks before the conference. I was really curious and not disappointed by the result of the research! Yingtao Zeng, Qing Yang & Jun Li presented their work about car keyless attack. It was strange that the guy responsible of the most part of the research did not speak English. I was speaking in Chinese to his colleague who was translating in English. Because users are looking for more convenience (and because it’s “cool”), modern cars are not using RKE (remote keyless entry) but PKE (passive keyless entry). They started with a technical description of the technology that many of us use daily:

How to steal the car? How could we use the key in the car owner’s pocket? The idea was to perform a relay attack. The signal of the key is relayed from the owner’s pocket to the attacker sitting next to the car. Keep in mind that cars required to press the button on the door or to use a contact sensor to enable communications with the key. A wake up is sent to the key and unlock doors. The relay attack scenario looks like this:

During this process, they are time constraints. They showed a nice demo of a guy leaving his car, followed by attacker #1 who captures the signal and relay to the attack #2 who unlock the car.

The current range to access the car owner’s key is ~2m. Between the two relays, up to 300m! What about the cost to build the devices? Approximatively 20€! (the cost of the main components). What in real case? Once the car is stolen and the engine running, it will only warn that the key is not present but it won’t stop! The only limit is running out of gas 🙂 Countermeasures are: use a faraday cage or bag, remove the battery more strict timing constraints.

They are still improving the research and are now investigating how to relay this signal through TCP/IP (read: the Wild internet). [Slides are available here]

My next choice was to follow “Extracting All Your Secrets: Vulnerabilities in Android Password Managers” presented by Stephan Uber, Steven Arzt and Siegfried Rasthofer. Passwords remain a threat for most people. For years, we ask users to use strong passwords, to change them regularly. The goal was not here to debate about how passwords must be managed but, as we recommend users to use passwords manager to handle the huge amount of passwords, are they really safe? An interesting study demonstrated that, on average, users have to deal with 90 passwords. The research focused on Android applications. First of all, most of them say that they “banking level” or “military grade” encryption? True or false? Well, encryption is not the only protection for passwords. Is it possible to steal them using alternative attack scenarios? Guess what? They chose the top password managers by the number of downloads on the Google play store. They all provide standard features like autofill, custom browser, comfort features, secure sync and confidential password storage of course. (Important note: all the attacks have been performed on non-rooted devices) Manual filing attack: Manual filling is using the clipboard. 1st problem: any app can read from the clipboard without any specific rights. A clipboard sniffer app could be useful.

The first attack scenario was: Manual filing attack: Manual filling is using the clipboard. First problem: any application can read from the clipboard without any specific rights. A clipboard sniffer app could be useful to steal any password. The second scenario was: Automatic filling attack. How does it work? Applications cannot communicate due to the sandboxing system. They have to use the “Accessibility service” (normally used for disabled people). The issue may arise if the application doesn’t check the complete app name. Example: make an app that starts also with “com.twitter” like “com.twitter.twitterleak”. The next attack is based on the backup function. Backup, convert the backup to .tar, untar and get the master password in plain text in KeyStorage.xml. Browsers don’t provide API’s to perform autofill so developers create a customer browser. But it’s running in the same sandbox. Cool! But can we abuse this? Browsers are based on Webview API which supports access to files… file:///data/package/…./passwords_pref.xml Where is the key? In the source code, split in two 🙂 More fails reported by the speakers:

• Custom crypto (“because AES isn’t good enough?”)
• AES used in ECB mode for db encryption
• Delivered browsers to not consider subdomains in form fields
• Data leakage in browsers
• Customer transport security

How to improve the security of password managers:

• Android provides a keystore, use it!
• Use key derivation function
• Avoid hardcoded keys
• Do not abuse the account manager

The complete research is available here. [Slides are available here]

After the lunch, Antonios Altasis presented “An Attack-in-Depth Analysis of Multicast DNS and DNS Service Discovery”. The objective was to perform threat analysis and to release a tool to perform tests on a local network. The starting point was the RFC and identifying the potential risks. mDNS & DNS-SD are used for zero-conf networking. They are used by the AppleTV, the Google ChromeCast, home speakers, etc. mDNS (RFC6762) provides DNS-alike operations but on the local network (uses 5353). DNS-SD (RFC6763) allows clients to discover instances of a specific service (using standard DNS queries). mDNS uses the “.local” TLD via 224.0.0.251 & FF02::FB. Antonios make a great review of the problems associated with these protocols. The possible attacks are:

• Reconnaissance (when you search for a printer, all the services will be returned, this is useful to gather information about your victim. Easy to get info without scanning). I liked this.
• Spoofing
• DoS
• Remote unicast interaction

mDNS implementation can be used to perform a DoS attack from remote locations. If most modern OS are protected, some embedded systems still use vulnerable Linux implementations. Interesting: Close to 1M of devices are listening to port 5353 on the Internet (Shodan). Not all of them are vulnerable but there are chances. During the demos, Antonios used the tool he developed: pholus.py. [Slides are available here]

Then, Patrick Wardle presented “OverSight: Exposing Spies on macOS”. Patrick presented a quick talk yesterday in the Commsec track. It was very nice so I expected also some nice content. Today the topic was pieces of malware on OSX that abuse the microphone and webcam. To protect against this, he developed a tool called OverSight. Why bad guys use webcams? To blackmail victims, Why governments use microphone to spy. From a developer point of view, how to access the webcam? Via the avfoundation framework. Sandboxed applications must have specific rights to access the camera (via entitlement ‘com apple.security.device.camera’ but non sandboxed application do not require this entitlement to access the cam. videoSnap is a nice example of avfoundation use. The pending tool is audioSnap for the microphone. The best way to protect your webcam is to put a sticker on it. Note that it is also possible to restrict access to is via file permissions.

What about malware that use mic/cam? (note: the LED will always be on). Patrick reviewed some of them like yesterday:

• The Hackingteam’s implant
• Eleanor
• Mokes
• FruitFly

To protect against abusive access to the webcam & microphone, Patrick developed a nice tool called OverSight. The version 1.1 was just released with new features (better support for the mic, whitelisting apps which can access resources). The talk ended with a nice case study: Shazam was reported as listening all the time to the mic (even if disabled). This was reported by an OverSight user to Patrick. He decided to have a deeper look. He discovered that it’s not a bug but a feature and contacted Shazam. For performance reasons they use continuous recording on IOS but a shared SDK is used with OSX. Malicious or not? “OFF” means in fact “stop processing the recording” but don’t stop the recording.

Other tools developed by Patrick:

• KnockKnock
• BlockBlock
• RansomWhere (detect encryption of files and high number of created files)

It was a very cool talk with lot of interesting information and tips to protect your OSX computers! [Slides are available here]

The last talk from my list was “Is There a Doctor in The House? Hacking Medical Devices and Healthcare Infrastructure” presented by Anirudh Duggal. Usually, such talks present vulnerabilities around the devices that we can find everywhere in hospitals but the the talk focused on something completely different: The protocol HL7 2.x. Hospitals have: devices (monitors, X-ray, MRI, …), networks, protocols (DICOM, HL7, FHIR, HTTP, FTP) and records (patients). HL7 is a messaging standard used by medical devices to achieve interoperability. Messages may contain patient info (PII), doctor info, patient visit details, allergy & diagnostics. Anirudh reviewed the different types of message that can be exchanged like “RDE” or ” Pharmacy Order Message”. The common attacks are:

• MITM (everything is in clear text)
• Message source not validated
• DoS
• Fuzzing

This is scaring to see that important information are exchanged with so poor protections. How to improve? According to Anirugh, here are some ideas:

• Validate messages size
• Enforce TLS
• Input sanitization
• Fault tolerance
• Anonymization
• Add consistency checks (checksum)

The future? HL7 will be replaced by FHIR a lightweight HTTP-based API. I learned interesting stuff about this protocol… [Slides are available here]

The closing keynote was given by Natalie Silvanovich working on the Google Project Zero. It was about the Shakra Javascript engine. Natalie reviewed the code and discovered 13 bugs, now fixed. She started the talk with a deep review of the principles of arrays in the Javascript engine. Arrays are very important in JS. There are simple but can quickly become complicate with arrays of arrays of arrays. Example:

var b = [ 1; “bob, {}, new RegExp() ];

The second part of the talk was dedicated to the review of the bug she found during her research time. I was a bit lost (the end of the day and not my preferred topic) but the work performed looked very nice.

The 2017’s edition is now over. Besides the talk, the main room was full of sponsor booths with nice challenges, hackerspaces, etc. A great edition! See you next year I hope!