ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands | Hacker News Reader

ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

atcommands.org

185 pointsp4bl075 comments

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 baseband SoC over some high-bandwidth-but-not-memory-sharing bus.

Until I can buy something like this, my gpg and ssh keys are staying far away from my phone, which kind of sucks.

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.

From the iOS security guide PDF (https://www.apple.com/business/site/docs/iOS_Security_Guide....):

>> "To protect the device from vulnerabilities in network processor firmware, network interfaces including Wi-Fi and baseband have limited access to application processor memory. When USB or SDIO is used to interface with the network processor, the network processor cannot initiate Direct Memory Access (DMA) transactions to the application processor. When PCIe is used, each network processor is on its own isolated PCIe bus. An IOMMU on each PCIe bus limits the network processor’s DMA access to pages of memory containing its network packets or control structures."

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."

The iPhone connects to the baseband via an internal USB connection, so the baseband doesn't have full direct memory access to the phone

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...

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... <-- pwning an iPhone 7, FWIW

- 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

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

https://neo900.org/

Is this still a problem if the phone doesn't have a sim card and is on airplane mode with WiFi and Bluetooth turned on?

I guess the answer to this is "who knows". You can't really trust the hardware on your phone.

The new Librem phones are supposed to have a hardware switch that cuts the power to the baseband modem when needed. That's about the best we can do at this point in time it seems.

Huh, this is an old trick but always a good one. Back in the days when iPhones were AT&T exclusive people managed to bypass the carrier lock by fuzzing all possible permutations of AT commands to the baseband. Once a crash was found it could potebtially be used as an exploit to modify its internal state.

It took Apple four years to harden their baseband firmware to resist all kinds of fuzzing efforts and bear in mind Apple only had 2-3 concurrent models to worry about. It must be harder for android vendors with their myriad different platforms.

Apple provides the baseband firmware itself. Android manufacturers have to ask the chipset manufacturer for updates. That’s a major difference.

Related: Anyone remember how Geohot's iPhone 2G hardware unlock worked back in the day? (~2007)

I remember there was one that could be triggered just by loading a web page with a specially crafted image file.

That would be a later jailbreak, not a baseband unlock per se.

Geohot's first iPhone hack, IIRC, used an unsecured JTAG pinout he managed to find on the PCB that allowed direct write access to the firmware. Later it was discovered that the system bootloader had enough exploits that the process could be done entirely in software.

Later iPhone models would gradually ramp up security to the point that nothing of this sort could be done very easily even with physical access.

Umm, Hayes commands are still used? That's a blast from the past. I thought those went out in the 80s or 90s?

The popular esp8266 wifi microcontroller was initially sold as a wifi interface to other microcontrollers, communicating over a serial interface, using AT commands. Indeed this was the first esp8266 I came across (ESP-01) - a cheap wifi interface for an arduino. Later folks discovered that the esp is more powerful itself than an arduino, but I think the stock firmware that comes on the chip is the serial-wifi interface using AT commands.

Yes, I was wondering if I read that right, but it seems that AT commands are still in use.

Us BBS nerds used to know AT commands by heart. We would send instructions to our 2400 baud Hayes modems using QModem:

   ATZ = reset

   ATDT1234 = dial 1234 on a touch tone phone (DP for pulse dial)

Those of us who later moved to US Robotics modems started learning proprietary USR ampersand codes.

   ATH0.

Many peripherals with serial interfaces still use AT commands - Bluetooth <-> Serial adapters, the original ESP2866 firmwares where it was a Wifi-to-Serial adapter, most Serial <-> CANBus/OBD adapters like ELM327, basebands all spring to mind.

Dialup was still a thing in this century, even if it feels like a long, long time ago. You could still reset people's connections by having them echo ATH0 back to you, if they were on a bad setup.

Only if you could get the other party to type +++ first to enter command mode, though. I'm not aware of any modem that would accept commands, including ATH0, outside of command mode. Then again, there were a lot of bad modems in the world…

Well, yeah, my "ATH0" was shorthand for "+++ATH0". All it would take was a hand crafted ping packet and a bad modem on the receiving end. The better modems implemented the Hayes safeguard of checking that no data was sent for an entire second after the third plus. Then, and only then, they would enter command mode.

NO CARRIER

As recently as 2001 the majority of americans used dialup to connect to the internet. AOL was the worlds biggest ISP, and carried more than 50% of all US web traffic.

Anything talking to a modem is using them still...

From what I understand, this is because GSM is based around the model of a voice/data modem.

The phone OS itself would actually use something like the QMI (Qualcomm management interface) protocol or MBIM for modem cards.

The Hayes/AT commands are still used either for debug purposes, or for non-smartphone use cases like IoT.

They're used by a variety of communication devices. I recently worked with some Phoenix Contact industrial bluetooth devices that used Hayes commands for configuration.

Of course.

>We found that in some cases the "charge-only" USB mode may also fail to block AT commands.

wow that is embarrassing. This needs to be added to CTS like 5 years ago ..

You can never trust software to block data flows. There is no such thing as "charge-only" as long as the cable still has data wires in it.

> We found that in some cases the "charge-only" USB mode may also fail to block AT commands.

This is a good point. I wonder if there's a market for "power-only" USB cables without data? Or would those fail to negotiate the right wattage?

There's the USB Condom:

https://int3.cc/products/usbcondoms

http://syncstop.com/

While not at guaranteed, killing the data wires (or shorting them) makes the device think it is dealing with a charge only port.

Thus various companies have made devices that conditionally apply said short.

Here is one example: https://www.startech.com/Cables/USB-2.0/USB-Adapters/USB-2-F...

The USB condom is more for situations where you are in public and wish to charge your device from an unknown and possibly hostile USB-A receptacle.

That Startech device still isolates the data line, it just has the added bonus of adding fast charging support. It'd be effective as a "USB condom" alternative.

USB-C has separate lines for the "Configuration Channel", that is used to negotiate voltage and amperage. I'm unaware if the specification allows for cables without data lines, but I don't believe they would be required.

It would only work on USB-C host devices as well though, USB-A would still revert to either 500mA as long as the data lines are tied with a resistor

I have several cables like this. It's always briefly mystifying when I accidentally grab one to sync some data. No negotiation, my fancy devices just charge at 500mA using these cables.

This allows KDE/modemmanager to unlock the SIM card of my phone by just plugging it in though. I like it. I know my phone isn't top-notch on security but thankfully I know it isn't and take precautions outside.

Yep, when using an untrusted USB power source, you can use what is called a "USB condom": either an adapter or a USB cable with the data wires cut letting only power go through. You can search the web for tutorial on which wires to cut in your USB cable, or for already made USB condoms to buy for less than $10 a piece.

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.

Not sure of any that do that, but I've seen quite a few that support most of the charging standards and negotiate the highest current available (still at 5V) so that the phone can usually charge reasonably fast.

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

> when using an untrusted USB power source...

Don't do that. Ever. Always use your own charger and cable, preferably the ones that came with the phone. If not make sure you're sourcing them from a reputable company and not an anonymous Chinese importer.

Has anyone done research yet on the ability to control low level modems using a GSM tower? It seems likely commands like these could be executed over the air.

Also I see they got access to /proc which I assume is also access to memory via /proc/pid/mem?

I've done a little, and from what I saw AT wasn't available over the air, but more scary stuff like "update your firmware to this unsigned binary" and stuff were. Testing was with SIM[8/9]00. Albeit those are simpler basebands than you would find in a smart phone. They have a "lol, what's a OS/mmu" view of the world.

I'm glad to see this research being done. They did a great job with the paper and their searchable site.

As mentioned in the article/paper, this attack vector has been used before.

The AT+USBDEBUG command was used to unlock the Samsung S6 Dec 10, 2015.

Blog about this exploit back then: https://www.bloglovin.com/blogs/xda-developers-5233323/2015-...

Video of the unlock back then: https://twitter.com/rpaleari/status/674983960162787328/video...

The code published by FICS here: https://github.com/FICS/atcmd/blob/master/usbswitch/usbswitc...

is based off the same code from Dec 2015 here: https://github.com/ud2/advisories/blob/master/android/samsun...

Awesome, reminds me of my day's working in telco, doing automated testing of our DPI based billing by having a laptop on my desk connect > download file > disconnect > repeat and checking for discrepancies in the records. Was it ever hard to find the AT commands at the time to automate this from the spec sheets on the modems.

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 required.

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.

It would be ridiculous over-engineering to use a trie here given the performance requirements.

I read something a few years ago which led me to believe all phones had a baseband processor which scarily accepts all AT commands, unauthenticated, over the air-http://www.osnews.com/story/27416/The_second_operating_syste...

Am I conflating 2 different issues? Before, it was a theoretical risk. So with a basestation/stingrays you could do it remotely, and now over USB as well.

Thank you for not branding this vuln!

Really curious, why treat these automation capabilities as a vulnerability? Several security popups appeared, a cable was attached, an application executed on the computer... as a user I'd much rather have the possibility in the future of automating my phone's UI than to have vendors treat this as a vulnerability and patch.

Edit: Just realized that the commands bypassed the prompts. That is a different beast. But the question still remains.

I found it somewhat amusing that they mentioned model, manufacturer, IMEI and serial as being a "sensitive information leak" --- if you're in physical possession of the phone, those things can be found without even turning it on.

It doesn't require an attacker to have physical possession of the phone. They just need you to plug your phone into one of their USB ports. Something like a public charging station would be perfect for this.

An IMEI and serial are still unique identifiers that can be used for tracking.

Any info about Apple phones? Do they use AT commands?

They do internally, but as far as I know there's no way to send them from outside - you have to be root, and if you're root you don't really need AT commands to exfiltrate data.

Or you could be the cellular telco/hacker who knows how to program/attack the baseband from the RF side.

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 can use something like a PortaPow USB condom to isolate only the charging capability.

Good to know, thanks!

You should check out Tasker.

I did. Very useful, thanks for the tip!

https://youtu.be/ITbqTl8pTMs?t=200

Err... were these commands meant to be obfuscated the whole time?

I'm not really sure why it was blurred when it is easily searchable on the database they publish

At the time we released the video, that specific command was still not patched in some vendors.

No I think the latter ones were because he typed the usb one out later.

AT vulnerabilities... 2003 all over again

Reply on news.ycombinator.com