Iâ€™m in Heidelberg (Germany) for the 10th edition of the TROOPERS conference. The regular talks are scheduled on Wednesday and Thursday. The two first days are reserved for someÂ trainings and a pre-conference event called â€œNGIâ€ for â€œNext Generation Internetâ€ focusing on two hot topics: IPv6 and IoT. As said on the website: â€œNGI aims to provide discussion on how to secure these core technologies by bringing together practitioners from this space and some of the smartest researchers of the respective fieldsâ€. I initially planned to attend talks from both worlds but I stayed in the “IoT” tracks because many talks were interesting.
The day started with a keynote by Steve Lord: â€Of Unicorns and replicantsâ€. Steve flagged his keynote as a “positive” talk (usually, we tend to present negative stuff). It started with some facts like â€œThe S in IoT stands for Securityâ€ and a recap of the IoT history. This is clearly not a new idea. The first connected device was a Coca-Cola machine that was available via fingerÂ in… 1982! Who’s remember this old-fashioned protocol? In 1985, came the first definition of “IoT”: It is the integration of people, processes and technology with connectable devices and sensors to enable remote monitoring status. In 2000, LG presented its very first connected fridge. 2009 was a key year with the explosion of crowdfunding campaigns. Indeed, many projects were born due to the financial participations of many people. It was a nice way to bring ideas to life. In 2015, Vizio smart TV’s started to watch at you. Of course, Steve talked also about the story of St-Jude Medical and their bad pacemakers story. Common IoT problems are: botnets, endpoints, the overreach (probably the biggest problem) and the availability (You remember the outage that affected Amazon a few days ago?). The second part of the keynote was indeed positive and Steve reviewed the differences between 2015 – 2017. In the past, cloud solutions were not so mature, there was communication issues, little open guidance and unrealistic expectations.Â People learn by mistakes and some companies donâ€™t want to have nightmare stories like others and are investing in security. So, yes, things are going (a little bit) better because more people are addressing security issues.
The first talk was â€œIoT hacking and Forensic with 0-dayâ€ byÂ Moonbeom Park & Soohyun Jin. More and more IoT devices have been involved in security incident cases. Mirai is one of the latest examples. To address this problem, the speakers explained their process based on these following steps: Search for IoT targets, analyze the filesystem or vulnerabilities, attack and exploit, analyze the artefacts, install a RAT and control using a C&C then perform incident response using forensic skills. The example they used was a vacuum robot with a voice recording feature. The first question is just… “why?”. They explained how to compromizeÂ the device which was, at the beginning, properly hardened. Â But, it was possible to attack the protocol used to configure it. Some JSON data was sent in clear text with the wireless configuration details. Once the robot reconfigured to use a rogue access-point, root access on the device was granted. That’s nice but how to control the robot, its camera and microphone? To idea was to turn in into a spying device. They explained how to achieve this and played a nice demo:
So, why do we need IoT forensics? IoT devices can be involved in incidents.Issues? One of the issues is the way data are stored. There is no HD but flash memory. Linux remains the first OS used by IoT devices (73% according to the latest IoT developers survey). It is important to be able to extract the filesystem from such devices to understand how they work and to collect logs. Usually, filesystems are based on SquashFS and UBIFS. Tools were presented to access those data directly from Python. Example: the ubi_reader module. Once the filesystem details accessible, the forensic process remains the same.
The next talk was dedicated to SDR (Software Defined Radio) by Matt Knight & Marc NewlineÂ from Bastille: â€œSo you want to hack radios?â€. The idea behind this talk was to open our eyes on all the connected devices that implement SDR. Why should we care about radio communications? Not that they are often insecure but they are deployed everywhere. They are also built on compromises: big size and costs constraints, weak batteries, the deployment scenarios are challenging and, once in the wild, they are difficult to patch. Matt and Marc explained during the talk how to perform reverse engineering. They are two approaches: hardware & software defined radio. They reviewed pro & con. How to perform reverse engineering a radio signal? Configure yourself as a receiver and try to map symbols. This is a five steps process:
- Identify the channel
- Identify the modulation
- Determine the symbol rate
- Extract symbols
In many cases, OSINT is helpful to learn how it works (find online documentation). Many informationÂ is publicly available (example: on the FCC website – Just check for the FCC ID on the back of the device to get interesting info). They briefly introduced the RF concept then the reverse engineering workflow. To achieve this, they based the concept on different scenarios:
- A Z-Wave home automation protocol
- A door bell (capture button info and then replay to make the doorbell ring of course
- An HP wireless keyboard/mouse
After the lunch, Vladimir Wolstencroft presented â€œSIMBox Security: Fraud, Fun & Failureâ€. This talk was tagged as TLP:RED so no coverage but very nice content! It was one of my best talk for today.
The next one was about the same topic: “Dissecting modern cellular 3G/4G modemsâ€ by Harald Welte. This talk is the result of a research conducted by Harald. His company was looking for a new M2M (“Machine to Machine”) solution. They searched interesting devices and started to see what was in the box. Once the good candidate found (the EC2O from Quectel), they started a security review and, guess what, they made nice findings. First, the device contained some Linux code. Based on this, all manufacturers have to respect the GPL and to disclose the modified source code. It takes a long time to get the information from Quectel). By why is Linux installed on this device? For Harald, it just increased the complexity. Here is a proof with the slide explaining how the device is rebooted:
Crazy isn’t it? Another nice finding was the following AT command:
It allows to send Linux commands to the devices in read/write mode and as root. What else?
The last talk â€œHacks & case studies: Cellular communicationsâ€ was presented by Brian Butterly. Brian’s motto is “to break things you must understand how they workâ€. The first step, read as much as possible, then build your lab to play with the selected targets. Many IoT devices today use GSM networks to interact with them via SMS or calls. Others also support TCP/IP communications (data). After a brief introduction to mobile network and how to deploy your own. An important message from Brian: Technically, nothing prevents to broadcast valid networks IDâ€™s (but the law does it :-).
It’s important to understand how a device connects to a mobile network:
- First, connect to its home network if available
- Otherwise, do NOT connect to a list of blacklisted networks
- Then connect to the network with the strongest signal.
If you deploy your own mobile network, you can make target devices connect to your network and play MitM. So, what can we test? Brian reviewed different gadgets and how to abuse them / what are their weaknesses.
First case: a small GPS Tracker with an emergency button. The Mini A8 (price: 15â‚¬). Just send a SMS with “DW” and the device will reply with a SMS containing the following URL:
This is not a real GPS tracker, it returns the operation (“262” isÂ Germany) and tower cell information. If you send “1111”, it will enable the built-in microphone. When the SOS button is pressed, a message is sent to the “authorized” numbers. The second case was a gate relay (RTU5025 – 40â‚¬). It allows opening a door via SMS or call. It’s just a relay in fact.Â Send â€œxxxxCCâ€ (xxxx is the pin) to unlock the door. Nothing is sent back if the PIN is wrong. This means that it’s easy to brute force the device. Even better, once you found the PIN, you can send “xxxxPyyyy” to replace the PIN xxxx with a new one yyyy (and lock out the owner!). The next case was the Smanos X300 home alarm system (150â‚¬). Can be also controlled by SMS or calls (to arm, disarm and get notifications). Here again, there is a lack of protection and it’s easy to get the number and to fake authorized number to just send a “1” or “0”.
The next step was to check IP communications used by devices like the GPS car tracker (TK105 – 50â‚¬). You can change the server using the following message:
adminip 123456 22.214.171.124 9000
And define your own web server to get the device data. More fun, the device has a relay that can be connected to the car oil pump to turn the engine off (if the car is stolen). It also has a microphone and speaker. Of course, all communications occur over HTTP.
The last case was a Siemens module for PLC (CMR 2020). It was not perfect but much better than the other devices. By example, passwords are not only 4 numbers PIN codes but a real alphanumeric password.
Two other examples: a SmartMeter sending UDP packets in clear text with the meter serial number is all packets). And a Solar system control box running Windows CE 6.x. Guest what? The only way to manage the system is via Telnet. Who said that Telnet is dead?
It’s over for today. Stay tuned for more news by tomorrow!