Tag: IoT

RESEARCH | February 23, 2021

A Practical Approach to Attacking IoT Embedded Designs (II)

By Ruben Santamarta

In this second and final blog post on this topic, we cover some OTA vulnerabilities we identified in wireless communication protocols, primarily Zigbee and BLE.

As in the previous post, the findings described herein are intended to illustrate the type of vulnerabilities a malicious actor could leverage to attack a specified target to achieve DoS, information leakage, or arbitrary code execution.

These vulnerabilities affect numerous devices within the IoT ecosystem. IOActive worked with the semiconductor vendors to coordinate the disclosure of these security flaws, but it is worth mentioning that due the specific nature of the IoT market and despite the fact that patches are available, a significant number of vulnerable devices will likely never be patched.

View the Blog
RESEARCH | February 11, 2021

A Practical Approach To Attacking IoT Embedded Designs (I)

By Ruben Santamarta

The booming IoT ecosystem has meant massive growth in the embedded systems market due to the high demand for connected devices. Nowadays, designing embedded devices is perhaps easier than ever thanks to the solutions, kits, chips, and code that semiconductor manufacturers provide to help developers cope with the vast number of heterogeneous requirements IoT devices should comply with.

This never-ending race to come up with new features within tight deadlines comes at a cost, which usually is paid in the security posture of the commercialized device.

EDITORIAL | June 30, 2020

Warcodes: Attacking ICS through industrial barcode scanners

By Ruben Santamarta
Several days ago I came across an interesting entry in the curious ‘ICS Future News’ blog run by Patrick Coyle. Before anyone becomes alarmed, the description of this blog is crystal clear about its contents:
“News about control system security incidents that you might see in the not too distant future. Any similarity to real people, places or things is purely imaginary.”
IOActive provides research-fueled security services, so when we analyze cutting-edge technologies the goal is to stay one step ahead of malicious actors in order to reduce current and future risk. Although the casino barcode hack is made up, it turns out IOActive reported similar vulnerabilities to SICK months ago, resulting in the following advisory: This blog post provides an introductory analysis of real attack vectors where custom barcodes could be leveraged to remotely attack ICS, including critical infrastructure.

Introduction

Barcode scanning is ubiquitous across sectors and markets. From retail companies to manufacturing, utilities to access control systems, barcodes are used every day to identify and track millions of assets at warehouses, offices, shops, supermarkets, industrial facilities, and airports. Depending on the purpose and the nature of the items being scanned, there are several types of barcode scanners available on the market: CCD, laser, and image-based to name a few. Also, based on the characteristics of the environment, there are wireless, corded, handheld, or fixed-mount scanners. In general terms, people are used to seeing this technology as part of their daily routine. The security community has also paid attention to these devices, mainly focusing on the fact that regular handheld barcode scanners are usually configured to act as HID keyboards. Under certain circumstances, it is possible to inject keystroke combinations that can compromise the host computer where the barcode scanner is connected. However, the barcode scanners in the industrial world have their own characteristics. shipping automation From the security perspective, the cyber-physical systems at manufacturing plants, airports, and retail facilities may initially look as though they are physically isolated systems. We all know that this is not entirely true, but reaching ICS networks should ideally involve several hops from other systems. In some deployments there is a direct path from the outside world to those systems: the asset being handled. Depending on the industrial process where barcode scanners are deployed, we can envision assets that contain untrusted inputs (barcodes) from malicious actors, such as luggage at airports or parcels in logistics facilities. In order to illustrate the issue, I will focus on the specific case I researched: smart airports.

Attack Surface of Baggage Handling Systems

Airports are really complex facilities where interoperability is a key factor. There is a plethora of systems and devices shared between different stakeholders. Passengers are also constrained in what they are allowed to carry. luggage scanning In 2016, ENISA published a comprehensive paper on securing smart airports. Their analysis provided a plethora of interesting details; among which was a ranking of the most critical systems for airport resilience. Most modern baggage handling systems, including self-service bag drop, rely on fixed-mount laser scanners to identify and track luggage tickets. Devices such as the SICK CLV65X are typically deployed at the automatic baggage handling systems and baggage self-drop systems operating at multiple airports.

The Baggage Connection – SICK Whitepaper

More specifically, SICK CLV62x-65x barcode scanners support ‘profile programming’ barcodes. These are custom barcodes that, once scanned, directly modify settings in a device, without involving a host computer. This functionality relies in custom CODE128 barcodes that trigger certain actions in the device and can be leveraged to change configuration settings. A simple search on YouTube results in detailed walkthroughs of some of the largest airport’s baggage handling systems, which are equipped with SICK devices. Custom CODE128 barcodes do not implement any kind of authentication, so once they are generated they will work on any SICK device that supports them. As a result, an attacker that is able to physically present a malicious profile programming barcode to a device can either render it inoperable or change its settings to facilitate further attacks. We successfully tested this attack against a SICK CLV650 device.

Technical Details

IOActive reverse engineered the logic used to generate profile programming barcodes (firmware versions 6.10 and 3.10) and verified that they are not bound to specific devices. The following method in ProfileCommandBuilder.class demonstrates the lack of authentication when building profile programming barcodes.

Analyzing CLV65x_V3_10_20100323.jar and CLV62x_65x_V6.10_STD

 

Conclusion

The attack vector described in this blog post can be exploited in various ways, across multiple industries and will be analyzed in future blog posts. Also, according to IOActive’s experience, it is likely that similar issues affect other barcode manufacturers. IOActive reported these potential issues to SICK via its PSIRT in late February 2020. SICK handled the disclosure process in a diligent manner and I would like to publicly thank SICK for its coordination and prompt response in providing its clients with proper mitigations.
WHITEPAPER | February 10, 2020

LoRaWAN Networks Susceptible to Hacking: Common Cyber Security Problems, How to Detect and Prevent Them

By Cesar Cerrudo

LoRaWAN is fast becoming the most popular wireless, low-power WAN protocol. It is used around the world for smart cities, industrial IoT, smart homes, etc., with millions of devices already connected.

The LoRaWAN protocol is advertised as having “built-in encryption” making it “secure by default.” As a result, users are blindly trusting LoRaWAN networks and not paying attention to cyber security; however, implementation issues and weaknesses can make these networks easy to hack.

Currently, cyber security vulnerabilities in LoRaWAN networks are not well known, and there are no existing tools for testing LoRaWAN networks or for detecting cyber attacks, which makes LoRaWAN deployments an easy target for attackers.

In this paper, we describe LoRaWAN network cyber security vulnerabilities and possible cyber attacks, and provide useful techniques for detecting them with the help of our open-source tools.

Launch the whitepaper

RESEARCH | April 25, 2019

Internet of Planes: Hacking Millionaires’ Jet Cabins

By Daniel Martinez

The push to incorporate remote management capabilities into products has swept across a number of industries. A good example of this is the famous Internet of Things (IoT), where modern home devices from crockpots to thermostats can be managed remotely from a tablet or smartphone.

One of the biggest problems associated with this new feature is a lack of security. Unfortunately, nobody is surprised when a new, widespread vulnerability appears in the IoT world.

However, the situation becomes a bit more concerning when similar technologies appear in the aviation sector. Nowadays we can find Cabin Management and In-Flight entertainment systems that can be managed from mobile devices owned by crew members and/or passengers.

The systems I’ve analyzed in the research presented here, are deployed in business jets. The discovered vulnerabilities affect passenger and crew devices.

The Cabin Management System is based on a wireless access point installed onboard the aircraft that provides network connectivity from the mobile devices of passengers and crew members to the cabin server. The Android applications (and their iOS equivalents) for both vendors were developed by Rockwell Collins to manage the available cabin capabilities in the aircraft such as cabin temperature, light intensity and much more.

Manufacturer video promo: https://www.youtube.com/watch?v=pRA3AnPU1dE

The Android apps analyzed in this post are:

  1. Venue Cabin Remote by Rockwell Collins – Android Application Version 2.1.12 (Current Version 2.2.2) (https://play.google.com/store/apps/details?id=com.rockwellcollins.venue.cabinremote)
  2. Bombardier Cabin Control – Android Application Version 2.1.12 (Current Version 2.2.1) (https://play.google.com/store/apps/details?id=com.rockwellcollins.venue.cabinremote.bombardier)
Figure 1. Google Play Store: Bombardier Cabin Control Developed by Rockwell Collins
Figure 2. Google Play Store: Venue Cabin Remote developed by Rockwell Collins

The purpose of this post is to:

  • Provide an overview of the operations of these emergent systems, with a focus on the vulnerabilities that affect the Android mobile apps
  • Provide a detailed explanation on how to exploit them

The main vulnerabilities I’ve discovered in the systems are:

  • ZIP Files: Path traversal / Arbitrary File Write
  • Lack of Legitimacy Checking of the Server
    • Rockwell Collins Venue Cabin Remote Version 2.2.2 – Legit Connectivity AP Emulation https://youtu.be/8QRAlTBOatU
    • Unencrypted Communications

Based on the vulnerabilities found during the research, an attacker could create the following situations:

  • Deploy a rogue aircraft access point and write in the devices of the connected clients. This could lead to a full compromise of the device.
  • Deploy a rogue aircraft access point and capture credentials or application secrets used to get access to protected areas in the application managed by the crew members in the real aircraft access point.
  • Connect to a real aircraft access point and interact with the cabin devices using the application. This could lead to full access to the cabin capabilities via the application if the attacker gets the password to access protected application menus and create situations of discomfort onboard an aircraft by altering the temperature to a higher or lower value or modifying light intensity, switching off or blinking.
  • Connect to a real aircraft access point and multicast other server configuration to force the devices that are connected to the network to get a new configuration file, this could lead to some dangerous situations like:
    • A full compromise of the client’s devices connected to the network.
    • Create situations of discomfort onboard an aircraft by altering the temperature to a higher or lower value or modifying light intensity, switching off or blinking.

Research Timeline:

  • 2018 February: IOActive discovers vulnerability
  • 2018 February: IOActive notifies vendor
  • 2019 April: IOActive advisory published

Dani Martinez – @dan1t0 (https://twitter.com/dan1t0)
Security Consultant

The complete research, including: full systems overview and analysis, vulnerability discoveries with the Android apps, and detailed exploit scenarios, can be found on the Technical Advisory Paper.

Get the Technical Advisory Paper
PRESENTATION, VIDEO |

Critical Infrastructure: Hack the Smart City

By Cesar Cerrudo

Cesar Cerrudo, CTO, IOActive, provides a webinar presentation on the ever-growing risks of using technology that enables smart cities. With the advancement of information, communication, and IoT technologies, come new vulnerabilities, and opportunities for cyber attacks, resulting in disruption and denial of services.

RESEARCH | January 11, 2018

SCADA and Mobile Security in the IoT Era

By Alexander Bolshev & Ivan Yushkevich
Two years ago, we assessed 20 mobile applications that worked with ICS software and hardware. At that time, mobile technologies were widespread, but Internet of Things (IoT) mania was only starting. Our research concluded the combination of SCADA systems and mobile applications had the potential to be a very dangerous and vulnerable cocktail. In the introduction of our paper, we stated “convenience often wins over security. Nowadays, you can monitor (or even control!) your ICS from a brand-new Android [device].”


Today, no one is surprised at the appearance of an IIoT. The idea of putting your logging, monitoring, and even supervisory/control functions in the cloud does not sound as crazy as it did several years ago. If you look at mobile application offerings today, many more ICS- related applications are available than two years ago. Previously, we predicted that the “rapidly growing mobile development environment” would redeem the past sins of SCADA systems.
The purpose of our research is to understand how the landscape has evolved and assess the security posture of SCADA systems and mobile applications in this new IIoT era.

SCADA and Mobile Applications
ICS infrastructures are heterogeneous by nature. They include several layers, each of which is dedicated to specific tasks. Figure 1 illustrates a typical ICS structure.

Figure 1: Modern ICS infrastructure including mobile apps

Mobile applications reside in several ICS segments and can be grouped into two general families: Local (control room) and Remote.


Local Applications
Local applications are installed on devices that connect directly to ICS devices in the field or process layers (over Wi-Fi, Bluetooth, or serial).

 Remote Applications
Remote applications allow engineers to connect to ICS servers using remote channels, like the Internet, VPN-over-Internet, and private cell networks. Typically, they only allow monitoring of the industrial process; however, several applications allow the user to control/supervise the process. Applications of this type include remote SCADA clients, MES clients, and remote alert applications. 

 In comparison to local applications belonging to the control room group, which usually operate in an isolated environment, remote applications are often installed on smartphones that use Internet connections or even on personal devices in organizations that have a BYOD policy. In other words, remote applications are more exposed and face different threats.

Typical Threats And     Attacks

In this section, we discuss the typical threats to this heterogeneous landscape of applications and how attacks could be conducted. We also map the threats to the application types.
 
Threat Types
There are three main possible ICS threat types:
  • Unauthorized physical access to the device or “virtual” access to device data
  • Communication channel compromise (MiTM)
  • Application compromise

Table 1 summarizes the threat types.

Table 1: SCADA mobile client threat list
 
Attack Types
Based on the threats listed above, attacks targeting mobile SCADA applications can be sorted into two groups.
 
Directly/indirectly influencing an industrial process or industrial network infrastructure
This type of attack could be carried out by sending data that would be carried over to the field segment devices. Various methods could be used to achieve this, including bypassing ACL/ permissions checks, accessing credentials with the required privileges, or bypassing data validation.
 
Compromising a SCADA operator to unwillingly perform a harmful action on the system
The core idea is for the attacker to create environmental circumstances where a SCADA system operator could make incorrect decisions and trigger alarms or otherwise bring the system into a halt state.
 
Testing Approach
Similar to the research we conducted two years ago, our analysis and testing approach was based on the OWASP Mobile Top 10 2016. Each application was tested using the following steps:
  • Perform analysis and fill out the test checklist
  • Perform client and backend fuzzing
  • If needed, perform deep analysis with reverse engineering
We did not alter the fuzzing approach since the last iteration of this research. It was discussed in depth in our previous whitepaper, so its description is omitted for brevity.
We improved our test checklist for this assessment. It includes:
  • Application purpose, type, category, and basic information 
  • Permissions
  • Password protection
  • Application intents, exported providers, broadcast services, etc.
  • Native code
  • Code obfuscation
  • Presence of web-based components
  • Methods of authentication used to communicate with the backend
  • Correctness of operations with sessions, cookies, and tokens 
  • SSL/TLS connection configuration
  • XML parser configuration
  • Backend APIs
  • Sensitive data handling
  • HMI project data handling
  • Secure storage
  • Other issues
Reviewed Vendors
We analyzed 34 vendors in our research, randomly selecting  SCADA application samples from the Google Play Store. We did, however, favor applications for which we were granted access to the backend hardware or software, so that a wider attack surface could be tested.
 
Additionally, we excluded applications whose most recent update was before June 2015, since they were likely the subject of our previous work. We only retested them if there had been an update during the subsequent two years.
 
Findings
We identified 147 security issues in the applications and their backends. We classified each issue according to the OWASP Top Ten Mobile risks and added one additional category for backend software bugs.
 
Table 4 presents the distribution of findings across categories. The “Number of Issues” column reports the number of issues belonging to each category, while the “% of Apps” column reports how many applications have at least one vulnerability belonging to each category.
Table 4. Vulnerabilities statistics

In our white paper, we provide an in-depth analysis of each category, along with examples of the most significant vulnerabilities we identified. Please download the white paper for a deeper analysis of each of the OWASP category findings.

 Remediation And Best Practices
In addition to the well-known recommendations covering the OWASP Top 10 and OWASP Mobile Top 10 2016 risks, there are several actions that could be taken by developers of mobile SCADA clients to further protect their applications and systems.

 In the following list, we gathered the most important items to consider when developing a mobile SCADA application:

  • Always keep in mind that your application is a gateway to your ICS systems. This should influence all of your design decisions, including how you handle the inputs you will accept from the application and, more generally, anything that you will accept and send to your ICS system.
  • Avoid all situations that could leave the SCADA operators in the dark or provide them with misleading information, from silent application crashes to full subverting of HMI projects.
  • Follow best practices. Consider covering the OWASP Top 10, OWASP Mobile Top 10 2016, and the 24 Deadly Sins of Software Security.
  • Do not forget to implement unit and functional tests for your application and the backend servers, to cover at a minimum the basic security features, such as authentication and authorization requirements.
  • Enforce password/PIN validation to protect against threats U1-3. In addition, avoid storing any credentials on the device using unsafe mechanisms (such as in cleartext) and leverage robust and safe storing mechanisms already provided by the Android platform.
  • Do not store any sensitive data on SD cards or similar partitions without ACLs at all costs Such storage mediums cannot protect your sensitive data.
  • Provide secrecy and integrity for all HMI project data. This can be achieved by using authenticated encryption and storing the encryption credentials in the secure Android storage, or by deriving the key securely, via a key derivation function (KDF), from the application password.
  • Encrypt all communication using strong protocols, such as TLS 1.2 with elliptic curves key exchange and signatures and AEAD encryption schemes. Follow best practices, and keep updating your application as best practices evolve. Attacks always get better, and so should your application.
  • Catch and handle exceptions carefully. If an error cannot be recovered, ensure the application notifies the user and quits gracefully. When logging exceptions, ensure no sensitive information is leaked to log files.
  • If you are using Web Components in the application, think about preventing client-side injections (e.g., encrypt all communications, validate user input, etc.).
  • Limit the permissions your application requires to the strict minimum.
  • Implement obfuscation and anti-tampering protections in your application.

Conclusions
Two years have passed since our previous research, and things have continued to evolve. Unfortunately, they have not evolved with robust security in mind, and the landscape is less secure than ever before. In 2015 we found a total of 50 issues in the 20 applications we analyzed and in 2017 we found a staggering 147 issues in the 34 applications we selected. This represents an average increase of 1.6 vulnerabilities per application. 

 We therefore conclude that the growth of IoT in the era of “everything is connected” has not led to improved security for mobile SCADA applications. According to our results, more than 20% of the discovered issues allow attackers to directly misinform operators and/or directly/ indirectly influence the industrial process.

In 2015, we wrote:

SCADA and ICS come to the mobile world recently, but bring old approaches and weaknesses. Hopefully, due to the rapidly developing nature of mobile software, all these problems will soon be gone.

We now concede that we were too optimistic and acknowledge that our previous statement was wrong.

 Over the past few years, the number of incidents in SCADA systems has increased and the systems become more interesting for attackers every year. Furthermore, widespread implementation of the IoT/IIoT connects more and more mobile devices to ICS networks.

 Thus, the industry should start to pay attention to the security posture of its SCADA mobile applications, before it is too late.

 For the complete analysis, please download our white paper here.

 Acknowledgments

Many thanks to Dmitriy Evdokimov, Gabriel Gonzalez, Pau Oliva, Alfredo Pironti, Ruben Santamarta, and Tao Sauvage for their help during our work on this research.
 
About Us
Alexander Bolshev
Alexander Bolshev is a Security Consultant for IOActive. He holds a Ph.D. in computer security and works as an assistant professor at Saint-Petersburg State Electrotechnical University. His research interests lie in distributed systems, as well as mobile, hardware, and industrial protocol security. He is the author of several white papers on topics of heuristic intrusion detection methods, Server Side Request Forgery attacks, OLAP systems, and ICS security. He is a frequent presenter at security conferences around the world, including Black Hat USA/EU/UK, ZeroNights, t2.fi, CONFIdence, and S4.
 
Ivan Yushkevich
Ivan is the information security auditor at Embedi (http://embedi.com). His main area of interest is source code analysis for applications ranging from simple websites to enterprise software. He has vast experience in banking systems and web application penetration testing.
 
IOActive
IOActive is a comprehensive, high-end information security services firm with a long and established pedigree in delivering elite security services to its customers. Our world-renowned consulting and research teams deliver a portfolio of specialist security services ranging from penetration testing and application code assessment through to semiconductor reverse engineering. Global 500 companies across every industry continue to trust IOActive with their most critical and sensitive security issues. Founded in 1998, IOActive is headquartered in Seattle, USA, with global operations through the Americas, EMEA and Asia Pac regions. Visit for more information. Read the IOActive Labs Research Blog. Follow IOActive on Twitter.
 
Embedi
Embedi expertise is backed up by extensive experience in security of embedded devices, with special emphasis on attack and exploit prevention. Years of research are the genesis of the software solutions created. Embedi developed a wide range of security products for various types of embedded/smart devices used in different fields of life and industry such as: wearables, smart home, retail environments, automotive, smart buildings, ICS, smart cities, and others. Embedi is headquartered in Berkeley, USA. Visit for more information and follow Embedi on Twitter.
RESEARCH | February 17, 2016

Remotely Disabling a Wireless Burglar Alarm

By Andrew Zonenberg
Countless movies feature hackers remotely turning off security systems in order to infiltrate buildings without being noticed. But how realistic are these depictions? Time to find out.
 
Today we’re releasing information on a critical security vulnerability in a wireless home security system from SimpliSafe. This system consists of two core components, a keypad and a base station. These may be combined with a wide array of sensors ranging from smoke detectors to magnet switches to motion detectors to create a complete home security system. The system is marketed as a cost-effective and DIY-friendly alternative to wired systems that require expensive professional installation and long term monitoring service contracts.
     

 

Looking at the FCC documentation for the system provides a few hints. It appears the keypad and sensors transmit data to the base station using on-off keying in the 433 MHz ISM band. The base station replies using the same modulation at 315 MHz.
 
After dismantling a few devices and looking at which radio(s) were installed on the boards, I confirmed the system is built around a star topology: sensors report to the base station, which maintains all system state data. The keypad receives notifications of events from the base station and drives the LCD and buzzer as needed; it then sends commands back to the base station. Sensors only have transmitters and therefore cannot receive messages.
 
Rather than waste time setting up an SDR or building custom hardware to mess with the radio protocol, I decided to “cheat” and use the conveniently placed test points found on all of the boards. Among other things, the test points provided easy access to the raw baseband data between the MCU and RF upconverter circuit.
 
I then worked to reverse engineer the protocol using a logic analyzer. Although I still haven’t figured out a few bits at the application layer, the link-layer framing was pretty straightforward. This revealed something very interesting: when messages were sent multiple times, the contents (except for a few bits that seem to be some kind of sequence number) were the same! This means the messages are either sent in cleartext or using some sort of cipher without nonces or salts.
 
After a bit more reversing, I was able to find a few bits that reliably distinguished a “PIN entered” packet from any other kind of packet.
 
 

 

I spent quite a while trying to figure out how to convert the captured data bytes back to the actual PIN (in this case 0x55 0x57 -> 2-2-2-2) but was not successful. Luckily for me, I didn’t need that for a replay attack.
 
To implement the actual attack I simply disconnected the MCUs from the base station and keypad, and soldered wires from the TX and RX basebands to a random microcontroller board I had sitting around the lab. A few hundred lines of C later, I had a device that would passively listen to incoming 433 MHz radio traffic until it saw a SimpliSafe “PIN entered” packet, which it recorded in RAM. It then lit up an LED to indicate that a PIN had been recorded and was ready to play back. I could then press a button at any point and play back the same packet to disarm the targeted alarm system.
 
 

 

This attack is very inexpensive to implement – it requires a one-time investment of about $250 for a commodity microcontroller board, SimpliSafe keypad, and SimpliSafe base station to build the attack device. The attacker can hide the device anywhere within about a hundred feet of the target’s keypad until the alarm is disarmed once and the code recorded. Then the attacker retrieves the device. The code can then be played back at any time to disable the alarm and enable an undetected burglary, or worse.
 
While I have not tested this, I expect that other SimpliSafe sensors (such as entry sensors) can be spoofed in the same fashion. This could allow an attacker to trigger false/nuisance alarms on demand.
 
Unfortunately, there is no easy workaround for the issue since the keypad happily sends unencrypted PINs out to anyone listening. Normally, the vendor would fix the vulnerability in a new firmware version by adding cryptography to the protocol. However, this is not an option for the affected SimpliSafe products because the microcontrollers in currently shipped hardware are one-time programmable. This means that field upgrades of existing systems are not possible; all existing keypads and base stations will need to be replaced.
 
IOActive made attempts through multiple channels to contact SimpliSafe upon finding this critical vulnerability, but received no response from the vendor. IOActive also notified CERT of the vulnerability in the normal course of responsible disclosure. The timeline can be found here within the release advisory. 
 
SimpliSafe claims to have its units installed in over 300,000 homes in North America. Consumers of this product need to know the product is inherently insecure and vulnerable to even a low-level attacker. This simple vulnerability is particularly alarming because; 1) it exists within a “security product” that is trusted to secure over a million homes; 2) it enables an attacker to completely own the system (i.e., disable it, change PIN codes, etc.), and; 3) many unsuspecting consumers prominently display window and yards signs promoting their use of this system…essentially self-identifying their home as a viable target for an attacker.