Monday, September 20, 2010

GPRS/EDGE Security

You should already know by now that GSM voice calls and SMS messages are not secure. Any third party can easily set up a rogue base station and listen to your calls, read your SMS messages, and reroute, drop, or alter any of them.

Yes, GSM security is that broken.

What you may not have realized yet, is that your GPRS/EDGE connections are just as insecure.

Take a look at the following two pictures and try and answer this question: is the smartphone shown on those images connected, via GPRS and via EDGE, respectively, to the network operator "movistar"?

iphone gprs

iphone edge

Figure 1. iPhone 3G connected via GPRS and EDGE, respectively

Note for those of you unfamiliar with the iPhone: the smartphone in the pictures is an iPhone 3G, which, on the top left corner of the screen, it usually displays the name of the network operator it is connected to, and then, next to it, a symbol representing the type of data connection it has established: a circle, if it is connected using GPRS, or a letter "E", if it is connected using EDGE (or "3G" if it is connected using UMTS).

The right answer, sadly enough, is this:"Maybe it is, but then again, maybe it is not". That's the thing: you simply cannot tell!

In fact, the pictures were taken while the smartphone was connected to a rogue base station (BTS) that we set up in Taddong's lab, pretending to belong to the network operator Movistar. The BTS, in turn, was connected to a PC that emulated a whole network operator (BSC, SGSN, GGSN, etc.) and had Internet access via ADSL. The PC would route any traffic between the smartphone and the Internet. The following diagram depicts the lab setup:

lab diagram

Figure 2. Diagram showing the lab setup

Note: In this case, the Internet connection of the PC was established via ADSL, but we could have used any other access technology like cable, UMTS or even GPRS/EDGE.

So, for example, when the user navigated to our web page ( using the web browser of the smartphone...

iphone homepage tadddong

Figure 3. Smartphone browsing

... we could see those packets going through our PC, with as little effort as simply invoking good old Wireshark:

wireshark capture

Figure 4. Wireshark's capture of the HTTP request from the smartphone to

The above example, in which a user simply navigates to a static web page and the attacker sniffs the connection is a really simple one, granted, but it does illustrate the point: the attacker is sitting between the user's smartphone and the Internet, with full control over any packet flowing between them. Now, think of the possibilities for mischief: the attacker could read any e-mail sent or received in cleartext, she could read any usernames and passwords sent in cleartext by the user to remote servers, she could redirect any outgoing HTTP request to a malicious web server that would then send malicious content back to the browser, etc.

Just think about it the next time your smartphone tells you that it is using a GPRS/EDGE connection. Or, if you feel that your data is not interesting enough for an attacker, think about what might be going on the next time the smartphone of your CEO or any other VIP in your organization reports that it is using GPRS/EDGE. Would those connections be interesting to an attacker? Oh, yes!

So, what can you do to protect your GPRS/EDGE communications? We'll give you a short answer and a long answer.

The short answer: Do not use GPRS or EDGE; instead, use only UMTS ("3G", "3.5G", HSPA). Alternatively, make sure you use end-to-end authentication and encryption for all aplications that you access wirelessly. Or, even better, do both.

The long answer is actually a shameless plug ;-):


Come to our GSM/UMTS Security training course and you will see for yourself! In the course, we cover everything you need to know about GSM and UMTS security, including voice calls, SMS messaging, and data connections (GPRS/EDGE/UMTS/HSPA). All packed in a very short, very intense training experience, with lots of interactive demonstrations, that will make you fully understand all the vulnerabilities and risks involved and all the countermeasures available.

In November 2010 we will be teaching it for the first time, in Valencia, in Spanish, but if you don't speak Spanish or can't make it this time, don't worry: we'll be running English editions soon enough. Follow our blog, tweets and/or web page, and you won't miss it when we announce them.


Finally, if you fear that this GPRS/EDGE problem might apply to more than just smartphones, your instincts are serving you well: it definetely does. We will talk about that on a future post.

In the meantime, "be afraid, be very afraid..." of GPRS/EDGE connections!

Jose Pico & David Perez


Alvaro Del Hoyo said...

Would it be possible to sniff IMSI, TIMSI or IMEI on captured traffic?

Is it easy to know IMSI once TIMSI is captured?

How feasible is MITM attack against htpps bank session?

Which is best way to check https associated data on iPhone?

Thanks in advance


David Perez said...

Hi Alvaro,

> Would it be possible to sniff IMSI, TIMSI or IMEI on captured traffic?

Yes to all.

> Is it easy to know IMSI once TIMSI is captured?

When you run a BTS, you simply ask the MS for its IMSI and it will give it to you. That easy.

> How feasible is MITM attack against htpps bank session?

Just the same as when an attacker has control of your default gateway in an Ethernet network, for example. If the client and server are setup correctly and the user does not accept certificates with errors, HTTPS connections are secure against MITM attacks (but we all know that the last bit, about the user, is sometimes difficult to achieve).

> Which is best way to check https associated data on iPhone?

You will have to check the capabilities of your web browser, be it Safari in the iPhone, or any other browser in other smartphones, or GPRS/EDGE devices in general. But you should do so even if you never use GPRS/EDGE: HTTPS MITM attacks may occur at any point between the client and the server; it just so happens that with GPRS/EDGE it can be done wirelessly.

Juan said...

Nice post.

I wanted to know if in this setup do you have used USRP1 or USRP2?

David Perez said...

Hi Juan,

Actually, neither. We will be releasing the details of the lab experiment in the near future, so stay tuned!

Anonymous said...

It's a fake demonstration. The IP address is not an Iphone connected on a fake BTS. It's a vmware station with a fake browser! Why did you erase the Time in wireshark? Because with the time we can see it's a local LAN and not GSM access!


David Perez said...

Dear Anonymous:

The IP address is indeed a vmware station running Linux, and the network trace was indeed captured in the LAN segment. But the Linux box is not running a fake browser: it is forwarding NAT'ed packets coming from the iPhone via EDGE.

The software running in the Linux box assigned the iPhone a private address in a different range (e.g. and iptables was configured on that box to perform NAT on packets coming from that range, sharing the address of the LAN interface of the Linux box. Note that those packets would be NAT'ed again on the ADSL router, before leaving the LAN to enter the Internet.

You can see more details about this setup in our Black Hat presentation "A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications". Link available at our lab's web page:

Post a Comment