Slashdot Mirror

Yes. You need a rootable Android phone which has a Qualcomm modem (not difficult, they seem to have a monopoly) and a specific kernel option enabled which creates a diagnostic character device (this is usually enabled, I know that it's present in LineageOS).

Go here and get it: https://opensource.srlabs.de/p...

Good thing we don't use our fingers to hold the phone. Hold it, we do. As a starting point: https://srlabs.de/spoofing-fin...

It's almost as bad as leaving the combo for the gun safe lock next on the gun safe.

I leave mine inside it!

Obligatory link to the BadUSB project, including proof-of-concept:

https://srlabs.de/badusb/

I don't remember the powered off bit so maybe I'm thinking of something else but the attacks against SIMs would seem to still be possible, e.g. the srlabs work. The IOS security guide (PDF link) states that it'll only load cryptographically signed baseband. However that only makes any difference at boot, once loaded then I'd guess it's still fair game if it can be exploited.

IMO the FBI could get into this phone if they wanted without Apple's help, there have been a few possible options published like de-soldering certain chips and copying them. They've just picked this particular case to kick off their argument against encryption on consumer devices, quite possibly as they think they can get the most public support in this instance.

SnoopSnitch
Karsten Nohl on mobile self-defense

Android IMSI-Catcher Detector
More information here.

For security people scanning for these devices. I'm sure an "official" IMSI catcher detector will cost millions as well, however, there are free detection programs for rooted Android phones, like https://github.com/SecUpwN/And... and https://opensource.srlabs.de/p...

First you have to find them. Fortunately there is software for that: on a rooted Android, use https://github.com/SecUpwN/And... and https://opensource.srlabs.de/p...

You've got the wrong impression of BadUSB as impersonating a HID certainly isn't required. USB is fundamentally insecure in a number of ways...

https://www.blackhat.com/prese...

http://media.blackhat.com/bh-d...

https://srlabs.de/blog/wp-cont...

When the USB drivers themselves can be attacked with malformed protocol data there is a fairly direct channel to gaining access to the whole system. Also a USB drive controller can make itself look like an internal drive, meaning that DMA (yes, USB supports DMA) restrictions get lifted and then you have a hole in security similar to Firewire.

As for filesystem attacks being 'rare', that's only because other attacks (esp. remote) have offered so much opportunity to attackers. If an attacker wants an offline mode of exploitation then filesystems -- being complex data formats themselves -- then filesystems are a wide-open field of opportunity.

https://play.google.com/store/... https://opensource.srlabs.de/p...

The primary methods of detecting IMSI-Catchers and Fake BTS's is described here (pdf), and due to the variety of manufacturers' baseband interfaces, there wasn't an easy way to uniformly detect these devices.

IMSI-Catcher doesn't seem to work on my old, non-GSM Android, but I've also found OsmocomBB to be interesting; it's an open source GSM broadband implementation that seems to work on some older, cheap phones, like some motorola candy bars; check out Catcher Catcher for more info.

In terms of the IMSI Catcher devices themselves, I've seen estimations of $20 to $1500 to make one, from using cheap RTL-SDR devices to a full SDR (~$400-1500) to run a full fake GSM BTS.

The legal usage of IMSI-Catchers doesn't seem clear to me. It is essentially a MiTM attack, which at least android devices seem to go out of their way to ignore. The law enforcement usage seems worded in ways that would just confuse 50+ year old judges. And they have to go far out of the way to make sure that you don't notice an interruption in service, by forwarding any on-going communications to their intended recipients and tunneling them back, if they go are run over time and don't disassociate.

I haven't seen any estimation on how often these things are used. Besides, hacked femtocell's are probably also responsible for a lot of these rogue BTS's; I wonder if that would be discovered with such detection methods?

Thunderbolt is more like USB to the user - it's a thing you use to connect untrusted devices to your system.

No. USB is not safe either. Don't plug untrusted devices into your system's I/O ports, period.

USB, Firewire, eSATA, SAS, and Thunderbolt do not have a security model.

Thunderbolt just happens to have more capabilities since there is direct access to the PCI bus, and this is also where the greater performance comes in.

With greater capabilities and access comes greater possibilities of abuse from untrusted components. Including the possibility of malicious option ROMs and malicious access to other hardware devices attached to the bus.

It can. See BadUSB.

For the record, Wired isn't exactly a first-class source.

No, but I suspect you'll also find some issue with Nohl and Lell's presentation, and also perhaps the BadUSB homepage.

For the record, Wired isn't exactly a first-class source.

No, but I suspect you'll also find some issue with Nohl and Lell's presentation, and also perhaps the BadUSB homepage.

It won't be long before IMSI catchers are easily detectable. Even though I have nothing to hide, I can't wait for that day.

https://opensource.srlabs.de/p...

http://forum.xda-developers.co...

https://github.com/jtwarren/sp...

There are several projects based on mapping cell towers.

There are also projects looking to use network diagnostic info from the phone itself. Everything is still very alpha at this stage, but hopefully that will change.

The most well known is probably this one;

https://opensource.srlabs.de/p...

There is also a project on XDA that has attracted some attention;

http://forum.xda-developers.co...

Unfortunately I don't think it is as easy as the parent suggests.

Great - you don't want ACPI.

I'm looking at my Nokia n900 phone. (merely because I happen to have a detailed understanding of the design).

Inside it, there are the following closed-source blobs running on turing complete processors.

LED controller firmware. SIM java virtual machine SIM raw firmware. eMMC controller. SD controller. Hard-real-time modem controller. Modem high-level engine. Bluetooth CPU. Wifi processor. Main linux application processor GPU. I strongly suspect there is also an embedded processor in: Power managment controller. LCD. Battery charge monitor. GPS. (It's possible this is just an application running on the closed-source modem high level engine).

https://srlabs.de/rooting-sim-... http://www.youtube.com/watch?v... (rooting SD cards) http://www.youtube.com/watch?v... (battery firmware hacking) Similar efforts have been done with reverse engineering the firmware of bluetooth devices, wifi. The notion that you should only care about the code running on the CPU being open has always seemed really naive to me.

Though I agree on the security implications of all this code, it's always seemed really naive to me that people open source would make an automatic difference. There are so many examples now of long overlooked OSS vulnerabilities, and a growing realization that proper security development lifecycle and stringent testing procedures with fuzzy testing etc. are more successful approach to catching vulnerabilities. And many closed source shops are better resourced to do this better, and with a more programmatic approach.

Great - you don't want ACPI.

I'm looking at my Nokia n900 phone.
(merely because I happen to have a detailed understanding of the design).

Inside it, there are the following closed-source blobs running on turing complete processors.

LED controller firmware.
SIM java virtual machine
SIM raw firmware.
eMMC controller.
SD controller.
Hard-real-time modem controller.
Modem high-level engine.
Bluetooth CPU.
Wifi processor.
Main linux application processor
GPU.
I strongly suspect there is also an embedded processor in:
Power managment controller.
LCD.
Battery charge monitor.
GPS. (It's possible this is just an application running on the closed-source modem high level engine).

https://srlabs.de/rooting-sim-...
http://www.youtube.com/watch?v... (rooting SD cards)
http://www.youtube.com/watch?v... (battery firmware hacking)
Similar efforts have been done with reverse engineering the firmware of bluetooth devices, wifi.
The notion that you should only care about the code running on the CPU being open has always seemed really naive to me.

So ... who is working on an Android firewall at the appropriate level? I see 48 demos, meetoos and other indistinguishable dreck.

I would say a good start is to just use the airplane mode of your phone. That should disable your RF transmitter. But of course you wont be notified when the network is paging your IMSI. The save option is to use a phone with OsmocomBB, a free software implementation of the GSM stack: http://bb.osmocom.org/trac/ It has limited functionality (no GPRS working at the moment) but at least you know exactly would your phone is doing. With that, you can even run CatcherCatcher, which is able to detect IMSI catchers: http://opensource.srlabs.de/projects/catcher The supported phones are a bit outdated, mostly old Motorola phones. But there is one supported smartphone: the Openmoko Freerunner. It is pretty usable these days and is fully supported by Debian. I love it, but you will need to tinker - a lot.

Nohl also discussed protective measures users should take against these attacks, and others in use by intelligence communities around the world.

From the summary, it doesn't sound like there are actually particularly feasible protective measures to use on a routine basis. All I see is some discussion of the "Catcher Catcher" software, which can be used to estimate the likelihood of an "IMSI catcher" being used in the vicinity. But this isn't something most users can practically use on a routine basis.