Practical Security Assessments of IoT Devices and Systems
•Télécharger en tant que PPTX, PDF•
4 j'aime•3,413 vues
This talk briefly discusses strategies and methodologies than can be employed when assessing IoT devices. We look at how to develop credible threat scenarios for different IoT device and systems, perform static and dynamic attack surface mapping, perform static firmware analysis, perform static hardware analysis, undertake a dynamic device security analysis, sources of supporting information, supporting capability requirements and establishment, Execution of dynamic device analysis and approaches around network protocol analysis.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Practical Security Assessments of IoT Devices and Systems
Similaire à Practical Security Assessments of IoT Devices and Systems (20)
Dernier
Dernier (20)
Practical Security Assessments of IoT Devices and Systems
- 1. Practical Security Assessments of IoT Devices and Systems TBC NCC Group Technical Security Consulting NCC Group Security Research
- 2. Talk synopsis This talk will discuss strategies and methodologies than can be employed when assessing IoT devices. We'll look at how to develop credible threat scenarios for different IoT device and systems, perform static and dynamic attack surface mapping, perform static firmware analysis, perform static hardware analysis, undertake a dynamic device security analysis, sources of supporting information, supporting capability requirements and establishment, Execution of dynamic device analysis and approaches around network protocol analysis.
- 3. What we’ll zoom through Understanding Modelling Technical Capabilities Deep Dives Assessing Reporting
- 4. Internet of Things What do we mean?
- 5. What is the IoT?
- 6. What is the IoT?
- 7. Understanding Purpose, Use Case & Design
- 9. Understanding – Design Device – components Communications – protocols System – what, where, how, when
- 10. Modelling Threats & Resilience Expectations Flows & Trust Boundaries
- 11. Modelling – Threats Device level Communication level System level
- 12. Modelling – Resilience Expectations Device level Communication level System level
- 13. Modelling – Flows & Trust Boundaries On device – data and features Device to system – traffic System – data and functionality
- 15. Technical Capabilities - Dump Software - firmware (persistent storage) Data (persistent storage) Memory (non-persistent storage) FPGA Bitstream files / CPLD JEDEC files (persistent)
- 16. Technical Capabilities - Dump Removable storage e.g. SD card via built-in functionality / debugging (in firmware) via JTAG via observing data transmitted across memory buses* Chip-off analysis
- 17. Technical Capabilities - Observe On device – I2C, SPI, USB, GPIO, generic.. Off device – RF (ZigBee, 6LoWPAN, 802.11, Bluetooth, GSM/GPRS, Ethernet etc.) Side Channels - RF / DPA etc. System – end-to-end
- 18. Technical Capabilities - Debug Chip level – JTAG Device level – serial ports (e.g. console) – software interfaces – internal debugger (in firmware) Network – RF / wired – GDB stubs System – end-to-end
- 20. Deep Dives: Obtain Documentation SDKs GPL etc. Trigger auto-update then capture network traffic (if SSL not used) Firmware update bundles
- 21. Deep Dives: Extract Structure Clear-text / Encoding Obfuscation Compression Encryption / Signatures
- 22. Deep Dives: Reverse Boot loader Operating system / software Sensitive data IP – data representing device characteristics e.g. intelligent suspension / stability control
- 23. Deep Dives: Identify Technologies Security indicators 1st / 3rd party software Open Source libraries Security algorithms
- 25. Security Assessment / fuzzing tools
- 26. How to assess Review configuration Standard web app / product assessment methodologies Use the product Fuzz / correctness tests Code review
- 27. Example .. of the technical aspects .. (i.e. excluding understanding / modelling)
- 30. Summary & Conclusions IoT = embedded systems + wider system Approach = understand, model, ensure capability, assess … it’s not rocket science but it’s more complex than a web app, mobile app or standard infrastructure assessment …
- 32. Further Information Detailed paper on how to design and build securely https://www.nccgroup.com/en/learni ng-and-research-centre/white- papers/security-of-things-an- implementers-guide-to-cyber- security-for-internet-of-things- devices-and-beyond/
- 33. Further Information & Resources - Binwalk - http://binwalk.org/ - JTAGulator - http://www.grandideastudio.com/portfolio/jtagulator/ - Face Dancer - http://goodfet.sourceforge.net/hardware/facedancer21/ - DevTTYS0 Blog - http://www.devttys0.com/blog/ - Tamper detection / Anti-tamper .. plus many more ..
- 34. Europe Manchester - Head Office Cheltenham Edinburgh Leatherhead London Milton Keynes Amsterdam Copenhagen Munich Zurich North America Atlanta Austin Chicago Mountain View New York San Francisco Seattle Australia Sydney
Notes de l'éditeur
- The Internet of Things is a loose term to describe embedded systems in the form of computing devices and sensors that use the Internet to communicate. Today this touches on everything from the home and solutions such as Nest etc. through to wearable technologies, smart farms and cities etc.
- Looking at this from a technology perspective these IoT devices are typically formed of a Systems of Chip (SOC) using traditional general purpose CPU technology from vendors like ARM through to Microcontroller architectures from a variety of vendors. The important thing to keep in mind though is that these systems are just that repurposes general purposes CPUs & microcontrollers running software typically developed in common high-level languages such as C, Python, .NET and similar. As such they are potentially susceptible to the same types of attacks as a laptop, server or traditional mobile device.
- In order to assess an IoT device and the systems and software it integrates with it is important to understand its purpose, use case and design. By undertaking this activity we can perform a context aware assessment factoring in real-world risks, attacks and scenarios. For example if we assessed an in car after market ODB (On-board diagnostics) connect device as being susceptible to local attack and firmware tampering that allows us to unlock the car we have to ask ourselves what is the real-world risk. In order to launch the attack you need to be inside the car already or have intercepted the device during shipping. Whilst best practice says that the device should enforce code signing the cost to add such as feature to the bill of materials (BOM) is an extra 3 GBP due to the a component change. On a device that sells for 30 GBP this isn’t practical. This is why it is critical to understand the purpose of the device, its functionality and the design as well the likely deployment scenarios.
- So what do we look to understand? Device hardware components – what is the device comprised of, what communication protocols does it use and what comprises the system. What does it communicate with, where, how and when. By understanding these very basic aspects to the device and system we are collecting the inputs that will be used when formulating our attack scenarios against which we will assess. Equally in order to gain certain capabilities to interrogate the device in order to further understand the implementation, debug any issues discovered and otherwise perform operations against it we’ll need to understand the fundamental makeup of the design. For example once we understand the components used to build the device we can obtain datasheets from the vendors to understand functionality as well as the security properties. If working for the vendor directly this activity can typically be achieved by meeting with product architects and lead developers. However this is often not the case and as such a variety of other techniques need to be used. Some of this analysis will be done via static review by: - reviewing product documentation - deconstruction of the device to undertake components, design and availible interfaces - once components have been identified review of vendor datasheets and developer documentation Additionally dynamic analysis should be performed of the device in at the least the following scenarios: - during device start-up - during initial configuration - during software update - during normal use - during key functionality moments (alarms, key functionality etc) These observations will
- First we need to model the real-world threat at different levels. Device level – i.e. local attack Communication level – i.e. man-in-the-middle and remote network based attack System level – i.e. integration into the wider system and higher level functionality It is recommended that threats be modelled capturing the following information: High level threat Description We want to capture what is reasonable. For example if we take a smart meter the threats might include: Sensitive information transmission Remote disable Local firmware tamper Local fraud Physical compromise
- As for security threat it is also useful to model resilience expectations of the system: Device – what are the expectations around single device or many devices being available. Communication – what are the expectations of communications being functional System – what are the expectations that the system as a whole is functional This exercise is done as much to understand the impact of any DoS type issues which might be discovered whilst also helping prioritized what types of issues are assessed for,
- Next we need to model the data and functionality flows. This activity will be completed likely using the following inputs: Our understanding of the device and system design Passive monitoring of the network communication Using the device and solution This modelling is again done to distil our understanding whilst helping understand where the trust boundaries in the system exist.
- In order to assess IoT devices we typically need certain technical capabilities. Under like COTS operating systems on the desktop or mobile due we aren’t afforded in a lot of situations well documented platforms, SDKs and tooling. As such we need to establish a capability to make the blackbox we are assessing less so. The success we can achieve the required capability will vary based on a number of factors. These factors may include time, resource, experience, newness of platform, platform security, platform sophistication. However you should always strive to achieve these four core capabilities to a grater or lesser extent.
- When we say dump we mean extract, we want to be able to dump as much from the platform both from both persistent and non-persistent storage mechanisms. Our interest in persistent storage mechanisms is two fold: Gain access to the software that the device runs Gain access to any data the device stores e.g. configuration data, user data etc. Our interest in RAM is normally to allow us to gain access to unencrypted data that we would otherwise be precluded from accessing. However we may also use access to RAM to perform rudimentary debugging at a later stage. Finally if an FPGA (Field Programmable Gate Array) is being used at part of the solution we would also like to gain access to the bitstream (configuration data). This will allow us to understand the functionality implemented in the FPGA and thus identify any logic issues.
- How we achieve dump capability will be via a variety of mechanisms depending on the complexity and level of security of the system. The first one listed here (removable storage) is obviously the most trivial. Where such storage is used it can often trivially lead to access to both firmware and data with the exception of the boot ROM. Next we what to understand what the built-in functionality of the system exposes be it local serial ports which we can solder onto or debugging functionality we can easily communicate with. Next JTAG is where we further into the hardware realm, being able to identify JTAG ports, connect and communicate with tools like JTAGulator are critical here. Suffice to say JTAG if present often gives you everything you need to dump and debug the system and thus is very powerful. The most security conscious vendors will either attempt to obfuscate such ports or spin them out of the final design. Other defences against the misuse of JTAG include efuses which can be flow to disable after manufacture is complete and similar. If we can’t access a device via JTAG we can observe data which is transmitted across memory buses, how this is done we’ll cover next. Chip-off analysis is obviously where you don’t want to get to if you can avoid it. Whilst this may be easier in systems with external NOR flash this can get complex quite quickly especially with newer NAND flash where the wear levelling (how data is allocated from physical flash) algorithm awareness is needed.
- Next we wish to achieve an observe capability. How this is done will very much depend on the technologies in the device. On device – we are referring to data buses this is often achieved with either an oscilloscope and/or specialised sniffer for the particular bus. Knowledge and aware of electronics is essential. Off device – we are referring to network communication both in terms of local networks as well as wider. With the increasing levels of inbuilt security in technologies such as ZigBee or Bluetooth it is important often to be able to integrate the device into your own network and/or a test network for which you know properties such as PINs or similar. Without this information otherwise it can preclude the decryption of any captured RF traffic. How you observe these will depend for example Bluetooth there are now open source sniffers, similar for 802.11. For GSM/GPRS you will likely opt for your own rogue base-station using OpenBTS and similar. Side channels – this is not something we do as it requires a deep level of specialisation and equipment. However differential power analysis and other techniques can be used and often are asked for by high-security clients such as smart card vendors and system. System – finally any capability you can establish which allows you to observe the system at different points and thus gain an end-to-end view is valuable. Be it the API server, database server, network, device or similar. Gaining the most comprehensive view possible of the system will allow cause and effect to be understood when performing certain attacks or operations.
- Finally if we were to discover a potential security issue there is good chance we will likely want to be able to debug it. Similar being able to debug the system anyway is useful to understand behaviour and functionality. So how is this done? Chip level – as already mentioned JTAG is often critical here. Device level – there are a variety of different ways and possible interfaces. For example serial ports e.g. the console. We had a situation Christmas before last with one of the children toys. One of our consultants soldered onto the serial port and we obtained a read-only output. This read-only output whilst initially frustrating became critical is successfully exploiting our arbitrary code execution vulnerability due to the logging it provided us. This is a good example… beyond this there may be other software interfaces or internal debuggers (for example we’ve seen this on routers) that may be useful in debugging the system. Network - At the network level it will vary. There may be a GDB Server (debug server for GDB to connect to) or other similar proprietary debug server. Identify and understanding these will come from understanding the technology (e.g. operating system / platform) and information gleaned from other sources such as firmware and similar. For example there have been situations where network debug servers are present in the device but not enabled. This was identified by reviewing the firmware.. Modifying the firmware configuration and re-loading then enabled this functionality. System – again a catch all… find logs, find interfaces find anything that tells you something about how the system is behaving..
- Next we move into our deep dive capability – this is where we want to go to the lowest level possible and understand as much about the system as possible…
- The goal of the obtain phase is to acquire as much information about and copies of the devices software. Documentation – review all the documentation you can to understand how firmware is updated and what if any GPL is used and how it can be obtained. SDKs – if the vendor provides SDKs or developer documentation or if the vendor’s vendors provide such information request. This will include trial system or developer demos. This can provide you valuable tooling, information, software libraries and source code. GPL – where GPL is used, request it. We’ve seen everything from just the bare minimum to vendors shipping their proprietary scripts in the source bundles. Triggering any updates can help us obtain both the location as well as the contents of binary updates. Similar any downloadable firmware bundles can be used to obtain copies of the firmware images.
- Typically once firmware has been obtained it will be one monolith file made up of a variety of different components. These components will include potentially: Structure Boot ROM Kernel Userland software Filesystem Checksums Signatures The first task will be to understand the structure of the firmware. Tools like binwalk can help brute force this to a certain degree but others if you have copies of the firmeware update or production tools reverse engineering these can help understand any structure. But be prepared to touch on all of the points listed here. That is understanding firmware structure, being able to decode-encode data, different obfuscation detection techniques, different file systems (Cram/Squash etc.) and compression extraction.
- Next we want to reverse engineer. The first pass is normally to achieve a certain goal e.g. enable ‘this’ functionality or understand how ‘this’ works. However more broadly you will want to reverse various aspects. Whilst this is normally achieved with vendor datasheets and IDA Pro/Capstonr engine for common architecture types it can sometimes descend into a world of decryptors and the very worse case custom decompilers for weird little microcontrollers that IDA has seen no need to support. The goal of this reverse engineering exercise to obviously allow us to understand to the fullest extent functionality and identity vulnerabilities via this capability if required.
- So we’ve now obtained, extracted and are able to reverse the software of the device. We now enter into the identify phase.. We want to identity Technologies – key technologies for example if we see FTP/TFP versus SSH/TLS 1.2 we know the device is potentially going to be very weak from a security perspective. Security indicators – already touched on but things like which protocols, which compilers, how current software is, configuration etc. Anything that indicates a security awareness by the product team. 1st / 3rd part software – again as much as possible. Vendor, software, version. Both so we know what to try and get hold of as well as feed into the security indicator aspects. For example we once looked at the .NET Compact Framework .. We spotted the SSL/TLS stack shipped with it was vulnerable … we notified Microsoft … the vulnerable version had been shipped for a long time.. Similar open source libraries – depending on the level of effort the client is investing in the exercise code review / fuzzing etc. can all be considered. Security algorithms – we identify these for variety of different reasons. Firstly for the security indicator reason (i.e. SHA-2 v MD5) but also for to know what to try and target versus not or obtain more information about.
- The tools a techniques one would use to achieve each of these will device specific… NCC Group has for example produced network protocols fuzzers for things like USB, Bluetooth and Infrared but there are many many more. There isn’t a once size fits all approach, what is listed on this slide represents some of the common activities you should be prepared to perform. However depending on the system, it’s complexity and what you’ve managed to obtain in terms of capability will greatly impact what you choose to employ.
- We can talk about this product as it’s in the public domain and we actually helped the vendor with dealing with a disclosure issue. We’re going to talk about how the researchers approached the problem, how they achieved their capability, what they achieved and how we helped the vendor mitigate in-line with their risk appetite.