Using Signal to Detect Rogue Cellular Base Stations (Part Two)

Can Signal be used as a rogue base station detector?

For starters, this answer is subjected to the reliability and updating rate of the information source where Signal obtains the geographical location from.

Provided that the previous condition is met, we can distinguish three different cases:

1. If the attacker uses a non-existing cell identifier, the application will not provide any geographical information of it, and thus we will assume that the serving cell is false.
2. If the attacker uses an existing cell identifier, belonging to a tower that is located far away from the place where the attacker is located, then Signal will report that we are in a location that does not match our real position. This fact will indicate that the serving cell is not legitimate.
3. If the attacker configures his base station pretending to be one of the neighbor cells and achieves that the terminal registers to his base station (by emitting a signal that is perceived by the victim's terminal as much "better"), then Signal will not show any clue about the legitimacy of the cell. We must say that, in this situation, it is much more difficult for the attacker to force the terminal to register to his base station, due to the fact that the victim's terminal probably can see two radio signals with the same cell identifier (we don't know the terminal behavior in this case). To overcome this obstacle, the attacker could choose the identifier of an existing nearby cell, for which the terminal is not perceiving power at all.

Our conclusion is that this application can help detecting whether the service that our terminal is receiving is legitimate or not, and it makes much more difficult for the attacker to maintain his attack undetected. However, it cannot be considered a 100% reliable method.

Even so, we think that the use of the tower geographical location provides a very good way to help detecting rogue base station attacks, and it should be combined with other techniques as, for example, the GPS information of the terminal, the analysis of other parameters of the radio signal or the detection of some functionalities that a false network will not tipically implement.

Network traffic analysis

For each one of the performed tests we have obtained the corresponding traffic capture using Wireshark. We have done so because, if there is an information source from which one can extract the geographical location of a mobile base station, of course we want to know it.

After analyzing some of the captures, we reach the conclusion that the source of such information was Google (what a surprise!). Also, we could realize that the answer/response has this appearence:

In the previous picture you can see that the request is qualified by the cell identifier (MCC, MNC, LAC and CI), and that the answer comes in "longitude/lattitude" format.
The "User-Agent" field reflects that we are using "wget" (instead of "Signal" as it would reflect any capture of the application traffic). This is because instead of using Signal we have written a little software tool to access this information, as explained below.

tadbsl.sh tool

This application is a shell script that, taking the cell identifier as input data, performs the correctly-formatted request to Google, using wget. Once the answer from Google comes, it shows the longitude and latitude on the console and, optionally, it starts a web browser showing the geographical location of the tower in Google maps.

The use instructions of the tool are shown here:

$ ./tadbsl.sh --help tadbsl.sh --MCC= --MNC= --LAC= --CI= [-s | --show_in_browser] tadbsl.sh [-h | --help] Description: this script asks Google for a particular Cellular Base Station Location and shows the Google's answer. (Based on the traffic analysis of Signal Cydia application from PlanetBeing) Arguments: MCC: Mobile Country Code of the carrier owning the Base Station MNC: Mobile Network Code of the carrier owning the Base Staion LAC: Location Area Code of the Base Station CI: Cell Identificator of the Base Station Options: -h | --help Shows this help. -s | --show_in_browser If you specify this options the script will launch your browser with the obtained coordinates. You can configure your browser location in a configuration variable inside the script.

An example of use is shown below:

tad3@ubuntu:~/tadbsl$ ./tadbsl.sh --MCC=302 --MNC=720 --LAC=65010 --CI=48626 LOCATION: 49.1560525 , -123.1586519

This tool is available at our lab.

NOTE: We first published this article, in Spanish, in this post of the blog “Seguridad Apple”

Using Signal to Detect Rogue Cellular Base Stations (Part One)

Some days ago Chema Alonso informed us that an application was able to show the geographical location of the tower that was providing service to an iPhone, as well as that of adjacent towers. The application also showed some technical data about these towers. Chema's question was whether this application could be used to detect a rogue base station attack or not. To be able to answer that question, we performed some tests. Some of them are explained in this article, as well as the conclusions and other things that we have obtained along the way.

The application is called Signal (available on Cydia) and has been written by PlanetBeing. The purpose of the authors is to create a map of nearby towers, measure their power and provide technical data about them.

Test I: testing the application with and without Internet access

Testing Lab

To perform the tests, we set up the laboratory shown in the picture:

The main objective of this set up was to be able to analyze the traffic generated by the application so that we could obtain preliminary conclusions before deciding what tests would follow.

Installation and first execution

After jaiblreaking our iPhone and installing Cydia, we configured the device in the following way:

• We disabled 3G service to only accept GSM (this way it would be easier to provide service using our rogue base station)
• The first time the application is launched, it asks if we want to use localization services. We answered "no" because we wanted to limit the available resources for the software to calculate its location, i.e., no GPS in the game.

Afterwards, we could see the application showing a map with the location of the towers nearby our position (somewhere in Valencia area), and a number that represents the perceived power in dBm. We checked that the geographical location really showed our position:

Running the application without Internet access

Since we suspected that the application obtained the geographical location of the towers from the Internet, we disabled all data services of the iPhone, including GPRS and WiFi.
In these conditions, as soon as the application started, we could see that the serving cell was detected and data and parameters belonging to it were reported. Also, the geographical location of a set of nearby towers was shown in the map, but with a different format, as we can see in the following picture:


The legend of color codes in the application reads as follows:

• Blue: Visible towers
• Red: Connected tower
• Gray: Unlocatable tower
• Yellow: Previously seen tower

It seemed to us that Signal kept some kind of cache where it stored information about previously seen towers. As the application has the ability to “Reset tower data”, we checked that when we chose this option, all geographical information was lost, and it didn't come back after several runs of the application.

Running the application with Internet access

After enabling WiFi, we started again the application and at that moment it detected again where the towers were in our geographical area.

Conclusions obtained in Testing Phase I

From the tests performed we can infer that:

• Signal obtains the geographical information about cellular base sations from the Internet
• The application holds a cache where it stores geographical information of the towers that he has previously seen; this cache can be erased by using the “Reset tower data” option

Test II: using a rogue base station

Testing Lab

For this second phase of tests, we modified our lab to provide GSM service using our rogue base station. The following schema illustrates this set up:


Testing with a non-existent cell identifier

To perform this test we configured our rogue base station for emitting with a non-existent cell identifier, and then we turned on the iPhone inside the cage (remember that the iPhone was connected to the Internet inside the cage through our WiFi infrastructure, as shown in the previous picture).

When the Signal application started, it detected the servicing tower and correctly reported our false cell identificator, but it could not locate that cell geographically.

Testing with a different cell identifier

In this test we used a cell identifier belonging to a cell that is located somewhere in the Madrid area (we were performing our tests in Valencia area) and, sure enough, the application located us in Madrid, next to that tower, as we can see in the following picture:

Conclusions obtained in Testing Phase II

From these tests we can infer that:

• The identifying information about servicing tower is obtained from the radio signal
• The geographical information, that Signal obtains from the Internet, depends uniquely on the cell identifier (MCC|MNC|LAC|CI) where:
  • MCC: Mobile Country Code
  • MNC: Mobile Network Code
  • LAC: Location Area Code
  • CI: Cell Identifier

NOTE: We first published this article, in Spanish, in this post of the blog “Seguridad Apple”

Building OWASP ZAP Using Eclipse IDE for Java… Pen-Testers

If I were only given a single tool for a web application penetration test, that would definitely be a web interception proxy!

As you can check within Samurai WTF, the number of web interception proxies available to web app analyst and pen-testers is... (at least) quite large. During the last years (after the old initial Achilles days... Wow!, from Oct 13, 2000), a few proxies have become the web application security assessment tool of choice. OWASP Webscarab, together with Paros (Proxy), have been two of the most commonly used open-source alternatives, with Burp (Suite) on the free/commercial side (but not open-source).

Unfortunately (or not... keep reading ;-p) Webscarab and Paros were somehow discontinued. The lastest official Webscarab build (not from GIT) is from May 2007, and Webscarab-NG (Next Generation) was born as a very promising Webscarab replacement, but is slowly progressing with new features and releases. Paros ended up on the famous 3.2.13 version from August 2006 (5 years ago!) and a replacement project or fork was born afterwards, called Andiparos. In parallel, a new OWASP project saw the light, called ZAP (Zed Attack Proxy). On a very smart decision from their leaders (Psiinon and Axel), both projects joined forces to contribute to a single and common open-source web interception proxy (and security assessment tool, considering all the features currently available within ZAP), keeping the name of ZAP for the final project. Therefore, OWASP ZAP (Zed Attack Proxy) is definitely the current open-source web interception proxy and security assessment tool of reference.

What all these web interception proxy tools have in common? They have been developed in Java, what makes them great multi-platform (Windows, Linux, Mac OS X...) security assessment tools.

Experience has demonstrated during the last few years that pen-testers need to use two types of tools on their daily activities: the latest official stable tool release, typically distributed by the project as a prepackaged and ready to install bundle (.tar.gz, .zip, .jar, etc), and the most current development tool revision, the one that includes the most cutting edge, neat and mighty features, options, and capabilities, typically distributed by the project from the official Subversion (SVN/CVS, GIT, etc) repository.

Most pen-testing tools are developed using traditional languages, like C/C++ (e.g. nmap), where the standard 3-way build handshake works like a charm ("./configure", "make" & "sudo make install"), or using interpreted languages, where there is no need to build the package, such as Ruby (e.g. Metasploit), Python (e.g. w3af), or others.

But... what about the Java-based web interception proxies? I've discovered that there is a significant barrier to entry that make it difficult for pen-testers to enter into the building process of this kind of tools, as a simple "javac" (Java compiler) invocation does not make the trick. In order to compile and build Java-based web interception proxy tools, as they make an extensive use of GUIs and library sets, a Java IDE (Integrated Development Environment) is required.

As a result, lots of security professionals cannot and are not using the most current features of these tools until a new official version is released by the project. In order to overcome this, I have released the "Building OWASP ZAP Using Eclipse IDE for Java… Pen-Testers" guide, available for download (as usual) from Taddong's lab.

The goal of this document is to provide a simplified step-by-step guide web app pen-testers can go through to be able to easily build the most current OWASP ZAP version from the official Subversion repository by using the open-source Eclipse Java IDE. A final appendix provides some brief guidance for those interested on, not only using the latest tool features, but contributing to the OWASP ZAP project (what I encourage you to do).

Do not forget to always, but specially when using the most current development version, extensively test the tools on your lab environment before using them against the real pen-test targets, probably in production (at least, before you started using the tool... :-)