ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands • Hacker News Board

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#71

Post by ohazi » Sat, Aug 25, 2018, 6:27 PM UTC

Flow wrote: post #67

ohazi wrote: post #59

Earlier quoted context omitted.

It'd be nice if someone designed a phone that architecturally resembled a computer attached to a mobile hotspot. You could have an SoC of your choice for a user-facing operating system and a separate SoC with separate memory for the baseband and whatever the hell the carrier wants to push to the device. The operating system running on the user SoC could have a driver that allows it to get internet access from the bas…

I recall reading an article years ago describing iPhone being architectured like this. Even if the baseband system is compromised, it don't have access to the rest of the system. And traffic from the rest of the system passing thru the baseband is mostly encrypted. I don't know if it's true, but it makes sense given the, allegedly, crappy code base in Broadcoms firmwares.

Wow, I didn't know that!

Although I guess it makes sense given that apple designs their own application processor SoCs and then has to use a separate (Qualcomm, Intel) modem rather than using a Snapdragon eight-something with everything talking to everything in the same package.

I'm not a huge Apple fan lately, and have never liked the iPhone, but this definitely seems like a pretty concrete bullet point for "iPhone is generally more secure than Android."

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#72

Post by userbinator » Sun, Aug 26, 2018, 12:29 AM UTC

kevin_thibedeau wrote: post #53

userbinator wrote: post #50

I'm surprised that the full command strings appear verbatim in the firmware --- and even more surprised that they appear with their "AT" prefix; this suggests they're being parsed by an algorithm that isn't particularly efficient, like a linear search. If something more optimised like a switch or trie were used, it wouldn't be possible to extract them this way, and some more intense reverse-engineering would be requi…

Sequential search is near optimal for short lists. On embedded hardware you don't always have the luxury to create elaborate data structures for the "proper" solution.

That makes it all the more surprising that they would include the "AT" prefix, which all the commands start with --- if I were implementing a command processor like this in a memory- and CPU-constrained environment, I'd match "AT" separately from the rest (differing) parts of the command.

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#73

Post by exikyut » Sun, Aug 26, 2018, 3:40 AM UTC

Flow wrote: post #67

ohazi wrote: post #59

Earlier quoted context omitted.

It'd be nice if someone designed a phone that architecturally resembled a computer attached to a mobile hotspot. You could have an SoC of your choice for a user-facing operating system and a separate SoC with separate memory for the baseband and whatever the hell the carrier wants to push to the device. The operating system running on the user SoC could have a driver that allows it to get internet access from the bas…

I recall reading an article years ago describing iPhone being architectured like this. Even if the baseband system is compromised, it don't have access to the rest of the system. And traffic from the rest of the system passing thru the baseband is mostly encrypted. I don't know if it's true, but it makes sense given the, allegedly, crappy code base in Broadcoms firmwares.

Well, the iPhone 6, released after the San Bernardino shooter incident involving an iPhone 5S, used PCI-e to talk to the NVMe.

For maximum speed (900MB/s), the NVMe in the 6 shipped data to/from the processor core using NVMe-side DMA bus mastering.

This begged the question: if you could hardware-MITM the communications between the NVMe and the main processor, and then reverse-engineer the way the DMA bus mastering was done... could you do arbitrary I/O on the main CPU?

Well, the NVMe has a package-embedded Cortex-M5 (actually a Cortex-R5) inside, which handles raw NAND interface, TRIM, sector reallocation, and related functionality. (It may operate at 200MHz.)

So... since the NVMe is PCI-e, it begs the question, could you possibly connect it to a PC? The answer is a solid YES, if you're motivated enough to commision the custom ZIF SOIC receptacle required. But it Just Works(TM)!

It turns out the firmware upgrades for this microcontroller were (at the time, at least) distributed in unencrypted iOS packages. This made it possible to understand the NVMe update process, fake the iPhone CPU side of the update sequence via the PC PCI-e connection, and exploit the firmware update code to write attacker-defined code into the host PC's memory - proving without a shadow of a doubt that the NVMe's PCI transciever fuses were configured for RDMA.

With this established, all you need to do is flip everything over and turn _the PC into a fake NVMe_ by creating a 2nd test rig (with a 2nd commission for the inverse of the SOIC socket) that hooks the PC PCE-e port to the iPhone CPU _via an FPGA_, figure out the various low-level steps involved in initialization before the RDMA bit is enabled...

...and discover that the iPhone 6 CPU doesn't IOMMU-protect the memory area where SecureROM is running from. (Since, at the point the NVMe is initialized, SecureROM is running and waiting for the NVMe to ping it so it can fetch and validate iBoot, the iOS stage2 bootloader).

Woops.

Maybe. Why didn't Apple IOMMU-protect the SecureROM area?!?

At least the guy who figured this out got $200k for his efforts.

The above was TL;DRed from http://ramtin-amin.fr/#nvmepcie and http://ramtin-amin.fr/#nvmedma, which I needed to read multiple times (in some cases weeks/months apart) to fully grasp.

Since I read the above I have 0% confidence in Apple device security.

To be fair, I highly doubt the 6's design phase started anytime after the incident, so maybe a "we don't need to push that far" carried through the life of the 6 project. I wonder if anyone tried to lobby to lock this down. Or maybe Apple doesn't care if people push that hard? Or maybe...

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#74

Post by ohazi » Sun, Aug 26, 2018, 5:53 AM UTC

exikyut wrote: post #73

Flow wrote: post #67

Earlier quoted context omitted.

I recall reading an article years ago describing iPhone being architectured like this. Even if the baseband system is compromised, it don't have access to the rest of the system. And traffic from the rest of the system passing thru the baseband is mostly encrypted. I don't know if it's true, but it makes sense given the, allegedly, crappy code base in Broadcoms firmwares.

Well, the iPhone 6, released after the San Bernardino shooter incident involving an iPhone 5S, used PCI-e to talk to the NVMe. For maximum speed (900MB/s), the NVMe in the 6 shipped data to/from the processor core using NVMe-side DMA bus mastering. This begged the question: if you could hardware-MITM the communications between the NVMe and the main processor, and then reverse-engineer the way the DMA bus mastering wa…

I mean, it seems kind of reasonable to assume that it's game over once an adversary gains physical access to the device, let alone MITMing busses inside the phone.

I was mostly concerned about what horrible things could be done via OTA updates from the carrier (or payloads designed to look like carrier OTA updates, since apparently they're rarely encryoted).

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#75

Post by pabs3 » Sun, Aug 26, 2018, 6:12 AM UTC

ohazi wrote: post #59

klondike_ wrote: post #46

The real issue here is proprietary baseband modems. These modems contain fully functional microprocessors along with low level access to the main processor. Even if you replace your ROM with an open source one, it is usually impossible to change the firmware on the modem.

It'd be nice if someone designed a phone that architecturally resembled a computer attached to a mobile hotspot. You could have an SoC of your choice for a user-facing operating system and a separate SoC with separate memory for the baseband and whatever the hell the carrier wants to push to the device. The operating system running on the user SoC could have a driver that allows it to get internet access from the bas…

That seems a bit like the modem isolation and monitoring features of the Neo900, which isn't yet available:

https://neo900.org/

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#76

Post by exikyut » Sun, Aug 26, 2018, 8:37 AM UTC

ohazi wrote: post #74

exikyut wrote: post #73

Earlier quoted context omitted.

Well, the iPhone 6, released after the San Bernardino shooter incident involving an iPhone 5S, used PCI-e to talk to the NVMe. For maximum speed (900MB/s), the NVMe in the 6 shipped data to/from the processor core using NVMe-side DMA bus mastering. This begged the question: if you could hardware-MITM the communications between the NVMe and the main processor, and then reverse-engineer the way the DMA bus mastering wa…

I mean, it seems kind of reasonable to assume that it's game over once an adversary gains physical access to the device, let alone MITMing busses inside the phone. I was mostly concerned about what horrible things could be done via OTA updates from the carrier (or payloads designed to look like carrier OTA updates, since apparently they're rarely encryoted).

Fair point.

In the case of ultra-portable devices (that are all the more easily stolen) there should be a measure of physical security though. I also use the iPhone 6 example because the San Bernadino shooter's 5S was physically confiscated by police.

This being said, wireless vulnerabilities are indeed a high priority. You're probably already aware of the various vulnerabilities suffered by Broadcom Wi-Fi chipsets used in almost all phones.

On Android:

- https://googleprojectzero.blogspot.com/2017/04/over-air-expl...

On iOS:

- https://bugs.chromium.org/p/project-zero/issues/detail?id=12... - https://googleprojectzero.blogspot.com/2017/09/over-air-vol-...

- https://googleprojectzero.blogspot.com/2017/10/over-air-vol-...

Your concerns regarding cellular encryption are made all the more valid because of the extremely high political sensitivity of surfacing _anything_ that would even remotely suggest that encryption is not being used (classical security by obscurity). Someone asked for a cellular encryption indicator in Android 9 years ago, and I thought the response they received was very very insightful and gave a lot of food for thought. Slowly reading between the lines of every official reply is necessary. https://issuetracker.google.com/issues/36911336

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#77

Post by kevin_thibedeau » Sun, Aug 26, 2018, 2:55 PM UTC

userbinator wrote: post #72

kevin_thibedeau wrote: post #53

Earlier quoted context omitted.

Sequential search is near optimal for short lists. On embedded hardware you don't always have the luxury to create elaborate data structures for the "proper" solution.

That makes it all the more surprising that they would include the "AT" prefix, which all the commands start with --- if I were implementing a command processor like this in a memory- and CPU-constrained environment, I'd match "AT" separately from the rest (differing) parts of the command.

They probably support other commands without a common prefix. It's not worth special casing a subset of the command set. It only burns a few dozen bytes.

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#78

Post by Avamander » Mon, Aug 27, 2018, 10:02 AM UTC

Immortalin wrote: post #19

noja wrote: post #11

Earlier quoted context omitted.

You need to buy good ones otherwise the power negotiation doesn't happen and you get a slow charge.

Any way to sandbox or proxy the power negotiation through the sheath? Laptop's USB controller chip could be vulnerable.

There are chips you can buy that do power negotiation. You could design your own PCB that does the job.

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#79

Post by ddingus » Tue, Aug 28, 2018, 5:20 AM UTC

fmj wrote: post #57

ddingus wrote: post #6

This is all super interesting! Now I am wary of public charging stations. And, it is time to hack on my phone. Frankly, the automation they show in the video can be super useful.

You should check out Tasker.

I did. Very useful, thanks for the tip!