
ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands - p4bl0
https://atcommands.org/
======
klondike_
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.

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

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

~~~
exikyut
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](http://ramtin-
amin.fr/#nvmepcie) and [http://ramtin-amin.fr/#nvmedma](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...

~~~
ohazi
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).

~~~
exikyut
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...](https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-
broadcoms-wi-fi_4.html)

\- [https://googleprojectzero.blogspot.com/2017/04/over-air-
expl...](https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-
broadcoms-wi-fi_11.html)

On iOS:

\- [https://bugs.chromium.org/p/project-
zero/issues/detail?id=12...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1289) <\-- pwning an iPhone 7, FWIW

\- [https://googleprojectzero.blogspot.com/2017/09/over-air-
vol-...](https://googleprojectzero.blogspot.com/2017/09/over-air-
vol-2-pt-1-exploiting-wi-fi.html)

\- [https://googleprojectzero.blogspot.com/2017/10/over-air-
vol-...](https://googleprojectzero.blogspot.com/2017/10/over-air-
vol-2-pt-2-exploiting-wi-fi.html)

\- [https://googleprojectzero.blogspot.com/2017/10/over-air-
vol-...](https://googleprojectzero.blogspot.com/2017/10/over-air-
vol-2-pt-3-exploiting-wi-fi.html)

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](https://issuetracker.google.com/issues/36911336)

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

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

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

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

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

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

~~~
gnachman
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…

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

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

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

~~~
ForHackernews
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?

~~~
joezydeco
There's the USB Condom:

[https://int3.cc/products/usbcondoms](https://int3.cc/products/usbcondoms)

[http://syncstop.com/](http://syncstop.com/)

~~~
digi_owl
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...](https://www.startech.com/Cables/USB-2.0/USB-
Adapters/USB-2-Fast-Charging-Adapter~USB2CHADP)

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

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

------
ddtaylor
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?

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

------
nanch
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-...](https://www.bloglovin.com/blogs/xda-
developers-5233323/2015-samsung-lock-bypass-exploit-details-4833408555)

Video of the unlock back then:
[https://twitter.com/rpaleari/status/674983960162787328/video...](https://twitter.com/rpaleari/status/674983960162787328/video/1)

The code published by FICS here:
[https://github.com/FICS/atcmd/blob/master/usbswitch/usbswitc...](https://github.com/FICS/atcmd/blob/master/usbswitch/usbswitcher.c)

is based off the same code from Dec 2015 here:
[https://github.com/ud2/advisories/blob/master/android/samsun...](https://github.com/ud2/advisories/blob/master/android/samsung/nocve-2016-0004/usbswitcher.c)

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

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

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

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

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

------
nicogetz
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...](http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone)

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.

------
wemdyjreichert
Thank you for not branding this vuln!

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

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

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

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

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

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

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

~~~
js2
You can use something like a PortaPow USB condom to isolate only the charging
capability.

~~~
ddingus
Good to know, thanks!

------
strags
[https://youtu.be/ITbqTl8pTMs?t=200](https://youtu.be/ITbqTl8pTMs?t=200)

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

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

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

------
oopsman88
AT vulnerabilities... 2003 all over again

