Analyzing_Automotive_Firmware.pdf汽车电子信息安全渗透测试中对于固件

文件名称: Analyzing_Automotive_Firmware.pdf

所属分类: 其它

开发工具:

文件大小: 357kb

下载次数: 0

上传时间: 2019-07-14

提供者: qq_24******

下载 (357kb)

不能下载？报告错误

详细说明：汽车电子信息安全渗透测试中对于固件的提取，纯英文版，对于逆向汽车固件可以参考3.2 Attacking UDS It is essential for fault injection to be able to perform a huge number of experiments. However, as the uds The Uds protocol is a diagnostics protocol standardized standard demands, a 10 minute timeout is implemented in Iso 14229 6 and progressively adopted by the auto- fter three incorrect key guesses. This slows us down motive industry It is implemented in most eCus found significantly as we can do only 3 key guesses within 10 in a modern car. The uds standard describes function minutes. Therefore, we started exploring the possibility lity that is interesting for hackers like accessing the in to attack the uds stack at another location for which the ternal memories of an ecu therefore the uds stack results are described in Section 3.2.2 on an ECU is a perfect entry point for hackers. If the UDS implementation complies with the standard, access to the memory and firmware of the ECU is protected. 3.2.2 Attacking ReadMemory By Address The client must established privileged session in order to The target implements the readMemory byAddress ser use security critical services. The SecurityAccess service implements a seed-key authentication scheme where the vice which potentially allows us to read out its internal client requests a seed from the eCu to derive a key using memory. No 10 minute delay is implemented for ac- an algorithm and a secret. The algorithm and secret are cessing this service. Other interesting commands that do not implement this delay are: WriteMemory byrd- known to both the client and the ecu. a logical repre- sentation of this algorithm is shown in Figure 3 dress, Requestupload, RequestDownload and transfer- Data. Whenever this functionality is accessed the target will respond with an error code as we are not properly UDS Authentication Sequence authenticated using the SecurityAccess check. We will ocus on ReadMemory ByAddress, but a similar approach can be taken for the other commands The ReadMemory ByAddress service uses two param eters:address and length. Whenever this service is ac key calculation cessed, it will check first if the tester is properly authenti- cated using the security access check. Then, if the tester is proven to be valid, the requested memory is returned The maximum amount of bytes that can be returned is 0x40. This restriction is not enforced by the UDS stan key verification dard and will therefore be different between different tar- gets. Whenever this service is accessed without the right ECV privilege level, an error code(nrc) is sent back to the tester by the server We performed an attack on the target where we aim Figure 3: Security Access check seed-key algorithm to bypass the privilege level check using a voltage glitch We do not know exactly when this check is implemented The uds standard describes the functionality of uds but we do know it must he between the command is sent but it does not provide recommendations on the strength and the response comes back The time between the of the Security Access check. Therefore the security level command is sent via the can bus and the response is of the security access checks used by the automotive in- sent back via the can bus is 1700 microseconds We fo dustry depends on the implementers themselves. This re- cused our initial glitch campaign on this window. After sults in a wide variety of different implementations. we performing 45,000 experiments which took roughly one have identified implementations where attackers were day we observed several successful glitches. By narrow able to brute force the key due to bad practices. Better ing down the glitch parameters we achieved a maximum implementations are secure and do not include vulnera- success rate of 3 %. bilities that can be exploited logically. Nonetheless, even We are able to extract Ox40 bytes per successful glitch though there are no software vulnerabilities, these imple- and therefore we needed in total 8192 successful glitches mentation can be attacked using fau lt injection to extract the targets 512 KB internal flash. After ap proximately 3 days and roughly 300,000 glitches, we ex 3. 2.1 Attacking Security Access tracted the entire firmware from the target. Now we are read to start analyzing the targets firmware for which We initially set out to bypass the SecurityAccess check the results are described in Section 4. A more efficient using fault injection. However, we found that a practical fault injection attack to extract the firmware is described hurdle prevent us from performing this attack efficiently. in Section 3.3 3.3 Attacking debug interfaces a better method for analyzing code is dynamic anal Most MCUs include debug interfaces that can be used ysis which requires full control of the code executed on the target. On embedded systems, like ECUs, this is typ to access the their internals, including firmware. These ically done using the debug interfaces. However, these debug interfaces are often protected from malicious by a debug interfaces are protected on the target and are not password or simply by disabling them functional for us. Therefore we started investigating the A logical representation of standard methods to imple- possibilities for emulating the firmware without needing ment debug interfaces on MCUS is shown in Figure 4 the targets hardware itself. For our largel, development of a customized emulator was necessary, since no stan- Serial dard emulation tooling(e. g. gemu [3] and unicorn [5]) 12C ECU USB JT AG was available for the target's processor architecture 9 Debugger MCU 4.1 Firmware emulation Figure 4: Typical debug interface We implemented the minimum hardware support re- quired for complete emulation of the firmware of the in- Often a hardware fuse is used to enable the protection strument cluster. In this section, we provide a high-level forever. The enforcement of this protection can be imple- summary of our implementation of the emulator itself mented in hardware and software. The authors of [14] followed by a discussion of the dynamic analysis func already identified that software is used to enforce this tionality it provides and the advantages this brings to the protection. We have shown that software can easily be reverse-engineering process. We spent approximately altered using fault injection attacks. Therefore, the e pro 10 man days of time writing the necessary software, in tection of debug interfaces can be subverted using fault cluding implementing the dynamic analysis features de Injection scribed below and debugging the code so it correctly em We used publicly available information in order to en ulated the targets firmware. The core functionality of the Lble the targets debug interface by setting a specific ex- emulator(including the peripherals/interfaces described ternal strap-pin pattern. Once the debug interface is en- below )is implemented in approximately 3000 lines ofC. abled, we used the tooling available from the Mcu man- We did not attempt to accurately emulate features which ufacturer in order to figure out what commands to send were not necessary for our target firmware, such as ac to the debug interface in order to access the MCU's in- curate emulation of the CPu pipeline and caches. Such ternals. USing Voltage Fault Injection, we were able to functionality could be implemented if it were found to be Dypass the protections of the debug interface that were necessary for specific firmware to function correctly enabled This allowed us to extract the targets firmware efficiently in the order of hours instead of days f can 4 Firmware analysis /区引-wcu-mc【 Firmware analysis is often revered to as reverse engineer ing. The target's processors architecture is partially sup ported hy commercial and open source reverse engineer Figure 5: Firmware emulation ing tools(e. g. IDA Pro [2] and Radare2 [4]). Several il structions were not implemented and we were required to We used publicly-available data sheets that describe implement our own in order to analyze the firmware stat- the functionality of the target processor in detail. de ically. For other, more common processor architectures, pending on the target, this type of information might this tooling is better and less work is required before the not be available to an adversary and wr analysis can start. We found the firin ware to be very com- tor would be significantly more complicated. However, plex as it consists of multiple different code parts like our experience is that the necessary information can of operating system code, custom code and generated code. ten be found in leaked documentation, leaked software Additionally, the targets firmware is properly stripped or by investing(significantly) more time into the reverse from debug information which increases the analysis dif- engineering process ficulty significantly. We concluded quickly after starting The target's firmware uses a large number of hard- the static analysis of the firmware that we needed a more ware registers, but many can be ignored without any ap efficient technique. Analyzing the firmware statically is parent adverse effect on the functioning of the firmware simply too time consuming and too error prone. (for example, power management registers) and others were successfully implemented using stubs which ignore bus connected to the emulator, and observed that packets writes and always return a fixed value. We bootstrapped sent using these ids influenced the behavior of the de the emulator by outputting warning messages when un- vice. For example, many changed I/O outputs(e.g. cor- known reads/writes were performed, and adding the nec- responding to turn indicators or the speedometer) of the essary functionality only as required. However, an im- processor, or produced a Can packet in response. Other plementation of both the interrupt controller, as well sev- packets only changed the internal state(e.g. memory eral different timer peripherals, were required for the tar- of the emulated device, without producing an externall get firnware to successfully execute the boot process. visible resu The targets processor communicates with two other chips that are populated on the PCB using its I2C inter- 4.2.2 Debugging face: the eEProM and the display controller. We emu lated the functionality of the EEPROM and display con We implemented a gNu Debugger(GDB) stub in order troller which were necessary for our targets firmware. to implement debugging facilities using standard tooling We needed to provide a reasonably complete emulation This allowed us to set software break points and single of the EEPROM, including both reads and writes. Since step through the code. Debugging is a standard tool or the 12C interface is external to the processor, we were developers to analyze bugs in their code. However, in able to use a logic analyzer on the instrument cluster to a similar fashion, this can be used by attackers analyze confirm that the bus traffic was identical for the real hard binary firmw ware and the emulator The information stored in the EeProM includes static 4.2.3 Execution tracing vehicle-specific information such as the Vehicle ldentifi cation Number (VIN), as well as persistent data such as One limitation of analyzing binary code statically is that the vehicle mileage and security state. From an adver it takes significant effort in order to deter it cert sary's point of view it is interesting to identify what is branches are taken or not using the emulator we can stored where and how different data is stored. By trac simply keep track of the locations in the code that are ing the flow of execution before and after the eeprom executed. This allows us to separate the code that is ex is accessed we were able to discover where certain data ecuted from the code that is not executed. This prevents is stored. Data read from EEProm was spread across us from analyzing code that is not executed multiple locations and obfuscation was applied which we will not publicly discuss 4.2. 4 Taint analysis We implemented a technique, often referred to as taint 4.2 Advanced analysis analysis, in order to identify specific functionality within the target's firmware. For example, using this technique An adversary who is able to emulate the targets firmware it is easy for us to identify what parts of the code are is provided with several advantages compared to static responsible for operating on the data of a can bus mes analysis of the firmware. In this section we describe sev- sage. Simply said, we keep track on the reads and writes eral advanced features we implemented to speed up the on the data of the Can bus message. A logical represen analysis of the tarts firwmare tation of taint tracking is provided in Figure 6 4.2.1 SocketCAN 2 CAN message e Data[2]=CAN read()CAN message We implemented emulation of the Can controller pe Data[7]=Data 2 ripheral used by our target, including reception and trans mission of all supported message frames This emulated controller can connect to Linuxs SocketCaN, using ei [ CAN mess-→oatn= calculate Key ther a virtual can bus or a physical can dongle. This allows us to use the same tools to communicate with both the emulated device and the actual target itself, and Figure 6: Taint analysis on incoming UDS command would allow an adversary to replace the original instru ment cluster with a flexible and controllable emulator- In this example we tracked the Security Access key in driven instance of the target, which simplifies reverse er order to identify the functionality responsible for deriv- gineering of other components(e. g. gateways) ing the key from the seed. The simplest approach was We ran open source can penetration testing tools simply to taint the input values for the relevant (key) (e.g. Caring Caribou for UDs [l against a virtual can bytes of the can packet; the taint analysis would then find the conditional which was used to check whether secrets are embedded in the firmware Secrets, like keys, this matched the correct response, and we could then just should be properly stored securely using hardware secu restore the original state and provide the correct response rity modules (HSm). These keys should be diversified value instead, allowing us to obtain access to restricted between ECUs as well in order to minimize the impact UDS services. Since we control all sources of entropy when a key is extracted by an attacker. Authentication (such as the timing, sensor inputs and EEPROM con- mechanisms should be implemented using asymmetric tents )of the emulated device, we only needed to do this cryptography which means no secret is stored in the eCu once, since the seed (challenge)was always identical on at all. If there is no secret in the eCu, an attacker cannot all other execution runs extract that secret. Most importantly the threat model of The target firmware sends and receives a variety of embedded devices, including ECUs, should be adjusted CAN packets; by observing the Can ID filters applied to incorporate hardware hackers. It is simply not true by the firmware, we could easily determine which ranges nowadays that an eCu is secure when there are no ex of packet IDs were potentially relevant and could be in- ploitable software vulnerabilities. Hardware attacks are teresting to analyze further. Rather than brute-forcing a real threat and are performed by the masses. these Id ranges, we tainted the bytes representing the CAN IDS of packets by tainting the relevant reads from the Can controller registers. Combined with execution 7 Conclusion tracing to discover when new paths were taken, this al We showed that sophisticated hardware attacks, like fault lowed us to observe which specific IDs were of interest injection, are feasible, effective and not difficult. We used fault injection in order to alter the intended behav 5 Scalability ior secure software in order to completely subvert the software security model on which most ECUs rely. We A sful fault tion attack de t scale used the of a fault injection attack as a stepping- well to multiple cars. The scalability is often brought up stone to perform several scalable attacks. We extracted as an argument when the impact of fault injection attacks the firmware of a secured eCu which allowed us to start is discussed. It is a valid argument. Fault injection at- performing the Understanding phase required to pull of tacks do not scale well. However, one must realize that a full attack the results of fault injection attacks do scale. In Figure 7 We analyzed the extracted firmware efficiently without we visualize how the extraction of firmware using fault using the ECU's hardware We used a custom emulator injection results in scalable attacks as the ECU's processor architecture is not supported by publicly available tooling. Our emulator allowed us to speed up the Understanding phase significantly. We are able to understand, extract secrets from, and identify spe- Understandi firmware cific functionality in the firmware efficiently Our recommendation for the automotive industry is Reconiiguration include hardware attacks in your threat model. Do not not rely on the secrecy of firmware, do not expose secrets Figure 7: Scalable attacks to software and make use of hardware security where Hackers will go to great lengths in order to The firmware extracted using fault injection allows at extract the firmware of secure devices We would like to tackers to analyze the firmware in order to perform the finalize with a simple statement that has shown to hold Understanding phase of a full attack. This understanding up through time: defense in depth is key can lead to the identification of exploitable vulnerabili ties, extraction of secrets or know ledge required for re Acknowledgment configuration. Fault injection attacks are really stepping stone for attackers to be able to perform attacks that do We thank all our friends and colleagues for their help scale You all know who you are!: i 6 Hardening ECUs References Is all hope lost? No! eCus can be hardened against so 1 Caring caribou -a friendly car security explo phisticated attacks like fault injection. You should not rationtoolhttps://github.com/caringcaribOu/ rely on the secrecy of the firmware. It is essential that no caringcaribou/ [Online; accessed 2018 [2]Idaprohttps://www.hex-rays.com/products/ ida/. [Online: accessed 2018 [3qemu,thefastprocessoremulatorhttps://www qemu. org/. [Online; accessed 2018] [4]radare2.https://rada.re/r/.[oNline:accessed 2018 [5Unicorn-theultimatecpuemulatorhttp://www unicorn-engine.org/. [Online; accessed 2018 [6]iso14229-1:2013.Iso.https://www.iso.org/ standard/55283.html. Online; accessed 201 [7 Hagai Bar-El, Hamid Choukri, David Naccache, Michael Tunstall, and Claire Whelan. The sorcerer's apprentice guide to fault attacks. IACR Cryptology ePrint archive, 2004:100,2004 [8lNewaeTechnologyInc.Chipwhisperer.https //newae. com/tools/chipwhisperer/. [Online: ac cessed 2018] [9] Federico Menarini Jasper g.J. van Woudenberg, Marc F. Witteman. Practical optical fault injection on secure microcontrollers. FDTC.20I I [10] Colin O'Flynn. Fault injection using crow bars on embed- ded systems. IACR Cryptology ePrint Archive, 2016: 810 20l6. [ll] Robert Van Spyk Rajesh Velegalati and Jasper van Woudenberg. Electro magnetic fault injection in prac- tice. International Cryptographic Module conference (CMC),2013 [12]Riscure.Inspectorfaultinjection(fi).https://www riscure. com/security-tools/inspector-fi [Online; accessed 2018 [13]Niek Timmers and Cristofaro Mune. Escalating privileges in linux using voltage fault injection. 2017 Workshop on Fault diagnosis and Tolerance in Cryptography (FDTC) pages 1-8, 2017. [14] N. Wiersma and R. Pareja. Safety != security: On the resilience of asil-d certified microcontrollers against fault injection attacks. In 2017 Workshop on Fault Diagno- sis and Tolerance in Cryptography(FDTC), pages 9-16 Sept 2017

(系统自动生成,下载前可以参看下载内容)