Uncategorized

Aleph Security: Firehorse: Research & Exploitation framework for Qualcomm EDL (Firehose)

Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
By Roee Hay (@roeehay) & Noam Hadad
January 22, 2018
* QPSIIR-909, ALEPH-2017029, CVE-2017-13174, CVE-2017-5947

There are many guides across the Internet for ‘unbricking’ Qualcomm-based mobile devices. All of these guides make use of Emergency Download Mode (EDL), an alternate boot-mode of the Qualcomm Boot ROM (Primary Bootloader). To make any use of this mode, users must get hold of OEM-signed programmers, which seem to be publicly available for various such devices. While the reason of their public availability is unknown, our best guess is that these programmers are often leaked from OEM device repair labs. Some OEMs (e.g. Xiaomi) also publish them on their official forums. […] In this 5-part blog post we discuss the security implications of the leaked programmers. The first part presents some internals of the PBL, EDL, Qualcomm Sahara and programmers, focusing on Firehose. In Part 2, we discuss storage-based attacks exploiting a functionality of EDL programmers – we will see a few concrete examples such as unlocking the Xiaomi Note 5A (codename ugglite) bootloader in order to install and load a malicious boot image thus breaking the chain-of-trust. Part 3, Part 4 & Part 5 are dedicated for the main focus of our research – memory based attacks. In Part 3 we exploit a hidden functionality of Firehose programmers in order to execute code with highest privileges (EL3) in some devices, allowing us, for example, to dump the Boot ROM (PBL) of various SoCs. We then present our exploit framework, firehorse, which implements a runtime debugger for firehose programmers (Part 4). We end with a complete Secure-Boot bypass attack for Nokia 6 MSM8937, that uses our exploit framework. We achieve code execution in the PBL (or more accurately, in a PBL clone), allowing us to defeat the chain of trust, gaining code execution in every part of the bootloader chain, including TrustZone, and the High Level OS (Android) itself.

The merit of our research is as follows:
* We describe the Qualcomm EDL (Firehose) and Sahara Protocols. (Part 1)
* We created firehorse, a publicly available research framework for Firehose-based programmers, capable of debugging/tracing the programmer (and the rest of the bootloader chain, including the Boot ROM itself, on some devices). (Part 3 & Part 4)
* We obtained and reverse-engineered the PBL of various Qualcomm-based chipsets (MSM8994/MSM8917/MSM8937/MSM8953/MSM8974) using the Firehose programmers and our research framework. (Part 3)
* We obtained the RPM & Modem PBLs of Nexus 6P (MSM8994). (Part 3)
* We managed to unlock & root various Android Bootloaders, such as Xiaomi Note 5A, using a storage-based attack only. (Part 2)
* We managed to manifest an end-to-end attack against our Nokia 6 device running Snapdragon 425 (MSM8937). We believe this attack is also applicable for Nokia 5, and might be even extensible to other devices, although unverified. (Part 5)

Research & Exploitation framework for Qualcomm EDL Firehorse programmers
https://github.com/alephsecurity/firehorse

Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
https://alephsecurity.com/2018/01/22/qualcomm-edl-1/

Exploiting Qualcomm EDL Programmers (2): Storage-based Attacks & Rooting
https://alephsecurity.com/2018/01/22/qualcomm-edl-2/

Exploiting Qualcomm EDL Programmers (3): Memory-based Attacks & PBL Extraction
https://alephsecurity.com/2018/01/22/qualcomm-edl-3/

Exploiting Qualcomm EDL Programmers (4): Runtime Debugger
https://alephsecurity.com/2018/01/22/qualcomm-edl-4/

Exploiting Qualcomm EDL Programmers (5): Breaking Nokia 6’s Secure Boot
https://alephsecurity.com/2018/01/22/qualcomm-edl-5/

 

Standard
Uncategorized

Intel: Root Cause of Spectre/Meltdown Reboot Issues Identified

https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/

January 22, 2018 […]We have now identified the root cause for Broadwell and Haswell platforms, and made good progress in developing a solution to address it. Over the weekend, we began rolling out an early version of the updated solution to industry partners for testing, and we will make a final release available once that testing has been completed. Based on this, we are updating our guidance for customers and partners: We recommend that OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions, as they may introduce higher than expected reboots and other unpredictable system behavior. For the full list of platforms, see the Intel.com Security Center site.[…]

Standard
Uncategorized

Maritime security and firmware security

http://cimsec.org/cyberphysical-forensics-lessons-from-the-uss-john-s-mccain-collision/35254

Cyberphysical Forensics: Lessons from the USS John S. McCain Collision
January 22, 2018 Guest Author Leave a comment

By Zachary Staples and Maura Sullivan

[…]To generate network situational awareness sophisticated enough to do cyber forensics, the team will need to search for electronic anomalies across a wide range of interconnected systems. A key component of anomaly detection is the availability of normal baseline operating data, or trusted images, that can be used for comparison. These critical datasets of trusted images do not currently exist. Trusted images must be generated to include a catalog of datasets of network traffic, disk images, embedded firmware, and in-memory processes.

1. Network Traffic:
A common attack vector is to find a computer that has communications access over an unauthenticated network, which issues commands to another system connected to the network (i.e. malware in a water purification system issuing rudder commands). Cyberphysical forensics require network traffic analysis tools to accurately identify known hosts on the network and highlight anomalous traffic. If the trusted images repository contained traffic signatures for every authorized talker on the network, it would allow forensic teams to efficiently identify unauthorized hosts issuing malicious commands.

2. Disk Images:
Every console on the ship has a disk that contains its operating system and key programs. These disks must be compared against trusted images to determine if the software loaded onto the hard drives contains malicious code that was not deployed with the original systems.

3. Embedded Firmware:
Many local control units contain permanent software programmed into read-only memory that acts as the device’s complete software system, performing the full complement of control functions. These devices are typically part of larger mechanical systems and manufactured for specific real-time computing requirements with limited security controls. Firmware hacks give attackers control of systems that persist through updates. Forensic teams will need data about the firmware in the trusted image repository for comparison.

4. In-memory Processes:
Finally, advanced malware can load itself into the memory of a computer and erase the artifacts of its existence from a drive. Identifying and isolating malware of this nature will require in-memory tools, training, and trusted images.

In addition to the known trusted images, future forensic analysis would benefit from representative datasets for malicious behavior. Similar to acoustic intelligence databases that allow the classification of adversary submarines, a database of malicious cyber patterns would allow categorization of anomalies that do not match the trusted images. This is a substantial task that will require constant updating as configurations change. However, there are near-term milestones, such as the development of shipboard network monitoring tools and the generation of reference datasets that would substantively improve shipboard cybersecurity.

[…]

Standard
Uncategorized

bios-8088: disassembled BIOS from 8088 machines

Disassembled BIOS from 8088 machines

https://github.com/ricardoquesada/bios-8088

Speaking of old Intel chips:

https://github.com/jeffpar/pcjs
https://github.com/morphx666/x8086NetEmu
https://github.com/nkeck720/tiny-8088

The IBM BIOS reference was a classic, and archives of it exist online:
https://www.google.com/search?q=IBM+BIOS+Interface+technical+reference

 

Standard