Category Archives: Security

Exploring GSM Vulnerabilities to Assess Mobile Users’ Location

The privacy of about 5 billion GSM users worldwide is exposed. Their location is available to eavesdroppers while society keeps attention to vulnerabilities in software layers which may compromise the privacy of a very select group of users. The GSM networks depend on the mobile phones location to provide a good service. That dependency is intrinsic to the GSM protocol, where the phone must be near to an antenna in order to ensure a good radio signal quality between the mobile phone and the Base Transceiver Station. Unlike social networks or other Internet services where the users need to explicitly authorize the sharing of information about their location, the GSM protocol does it ubiquitously.
 

Using as excuse my master’s degree, in the past years I’ve been fully entertained studying/researching about some GSM vulnerabilities that may expose the geolocation of users. During the work I’ve studied known vulnerabilities and I also made some patches on known GSM security tools which may be very handful to reproduce the experiments I’ve made to prove my point.

 

My work was divided into three different ways to assess the user geolocation, they are unrelated but information gather in one may be useful to others attacks. These three different attacks intend to collect the victim geolocation in the following accuracy levels: countryportion of the city and neighborhood. This may vary depending on the provider configuration. So, do not expect this to work on all cases.

 

To illustrate the attacks we use two different entities: the attacker and the victim. For the second and third attacks, besides knowing the mobile number of the victim,  the attacker also needs to have two OsmocomBB compatible mobile phones and some specific OsmocomBB patches that are explained in this post. For the first attack, the attacker just need to have an account in an HLR provider and, of course, the mobile number of the victim.

 

First attack, Country

By knowing the telephone number of the victim it is possible to track down its country of origin by the phone prefix. It is also possible to know if the number still valid, working and if the user is in roaming or not. If so, which country the user is.

All this information can be gather using an HRL query provider. Note, however, that just some providers are leaking such information. In some countries (like Brazil) the providers are not able to leak this information, due law enforcement. In the map bellow is possible to identify in which countries the information is available (in green) or not (in orange).

HLR Map

Depending on your HLR provider, the information about the country comes already parsed, as illustrated in the example bellow.

hlr

As further work, the MSC gateways could be used to map the geolocation of the users, however, a mapping of the region is needed to be done prior to the attack.

 

Second attack, Portion of the city

This attack relays on the fact that a mobile phone is always connected to a BTS, listening a broadcast channel which belongs to a virtual group called: LAC. Knowing that, the attacker can address some demand (SMS or call) to the victim phone number and wait to see the victim identification (IMSI or TMSI) being redirected by the network to an specific channel/time slot to receive the demanded content. Broadcast channels are always delivering messages to users, more than one per second which makes impossible to the attacker to identify the victim TMSI or IMSI in the first try, so subsequent attempts need to be made reducing a `possible-victim list`, narrow it to one if the victim is part of a LAC or zero if the victim is not part of it.

Bellow there is a graphic of my hometown, Recife, with the LACs in different colors. It gives us an idea how big the LACs are and consequently the accuracy of the attack.

Rede Oi

 

Third attack, Neighborhood

This last attack is the one with the best accuracy. The idea is based on the fact that a SMS or a call will be delivered faster between two members of the same BTS/Tower. In different towers the message will be delivered from one tower to another and so one, until it reaches the final destination. By having the two phones on the same BTS, the message will be delivered directly to the destination as soon as it hit the tower.

Similar to the second attack, the ID of the victim on the network should be revealed before anything. After that, the attack jumps from tower to tower verifying the amount of time that the network takes to send the victim to a proper time slot/channel to receive the message.

The coverage area of a BTS may vary, it tends to be bigger in rural areas, with lower phone density and smaller in downtown, bellow is illustrated the area of coverage from BTSs in my hometown. Where F and E are the biggest and the smallest coverage area. Its sizes can be found on the table bellow.

Rede Oi

 

table

 

Conclusion

Those problems are not new, they have been discussed for a while. The idea of this post was to give short intro about the subject by exposing the vulnerabilities.

All these hypothesis were proved on my dissertation. For further reading, including tests, have a look on my dissertation available here.

For information about the ways to circumvent or minimize those problems, fire me an e-mail.

AppArmor D-Bus Mediations

Looking like the SELinux but less boring, the AppArmor is a Linux security module (LSM) which provides mandatory access control (MAC). The first distro to adopt the utilization of AppArmor was SUSE in SUSE Linux Enterprise Server 10 and in openSUSE 10.1. It is part of Ubuntu since the version 8.04 and the adoption increase version to version since more profiles are created.

Other software that is part of more and more applications each day is the D-Bus, adopted by GNOME and KDE as an inter-process communication mechanism, the usage of D-Bus allows the communication between different applications. It is used, for example, to provide the communication between a software Core with the UI. Due to the nature of the communication of certain applications (sensible data) is indispensable to have some control about who can acquire some interface or who can listen or send some message.

D-Bus daemon has support to mediate SELinux messages and there is also a D-Bus internal mechanism that has some control over the use of the bus, but none of this is related to AppArmor. There are some experiments that show that it is possible however the necessary patches (Kernel, libapparmor and D-Bus daemon) were not submitted to be part of the respective projects, as explained in the earlier post.

The patches on the experiment enable apparmor parser to understand the tag dbus, as illustrated on the example bellow (line 15). More information about the experiment and the syntax of the file can be seen in: https://lists.ubuntu.com/archives/apparmor/2011-September/001541.html

/home/zimmerle/hello.py flags=(complain) {
#include <abstractions/base>

/usr/bin/python2.7 ix,
/usr/include/python2.7/pyconfig.h r,
/usr/local/lib/python2.7/dist-packages/ r,
/usr/share/pyshared/PIL.pth r,
/usr/share/pyshared/lazr.restfulclient-0.11.2-nspkg.pth r,
/usr/share/pyshared/lazr.uri-1.0.2-nspkg.pth r,
/usr/share/pyshared/pygst.pth r,
/usr/share/pyshared/pygtk.pth r,
/usr/share/pyshared/ubuntu-sso-client.pth r,
/usr/share/pyshared/ubuntuone-client.pth r,

dbus bar.foo.hello acquire,
}

In order to ensure the functionality of the suggestion made in the post: D-Bus Loadable security module support, I decided to modify the AppArmor D-Bus daemon patches to make them compatible with the suggested model. And it is working like a charm.

The code of the current experiment can be fetched from:

http://cgit.collabora.com/git/user/zimmerle/dbus-apparmor-lsm.git/

Note that in this experiment I had to use the D-Bus internal functions/headers. I made little hacks in order to get it working but apparently, this is a good way to go.

D-Bus Loadable security module support

While I was thinking about LSM mediations of the D-Bus messages, I found out a nice work that is being developed by the Ubuntu sec team in order to support the AppArmor mediation on D-Bus message exchange and service acquisition.

Having a chat with John Johansen (from Unbuntu sec team), he said that he was missing a loadable module support on the D-Bus. Allowing the support of different Linux Security Modules mediation without messing up the D-Bus daemon code, which does make sense.

I started to implement a little PoC about this loadable support, which consists in the following: the LSM modules can be dynamically loadable at the d-bus daemon startup. By copying a D-Bus LMS module to a given directory (which can be specified at the d-bus configuration) it will be loaded and registered.

The idea is to have independent modules, if possible use only the D-Bus functions provided by libdbus, however, of course, if needed symbols can be copied from libdbus-internal.a.

Despite the fact that the modules can be independent of the D-Bus internals, they must have at least one known function, this function should be named as “pre_init“, and receives the pointer to the D-Bus internal function “register_security“. The “register_security” function should be called by the module if it is loaded successfully. The “pre_init” function must return a “dbus_bool_t“: true if everything goes right or false if not. Note that audit can be also initialized by this function.

The function “register_security” receives as parameter a pointer to the structure “security_validations” that is part of dbus-security.h. The structure is illustrated bellow:

struct security_validations
{
 char *name;
 dbus_bool_t (*bus_security_allows_send) (DBusConnection *,
                                         DBusConnection*,
                                         const char *,
                                         const char *,
                                         const char *,
                                         const char *,
                                         const char *,
                                         const char *,
                                         const char *,
                                         DBusError *);
 dbus_bool_t (*bus_security_allows_acquire_service) (DBusConnection *,
                                                    const char *,
                                                    const char *,
                                                    DBusError *);
 dbus_bool_t (*shutdown) (void);
};

The structure “security_validations” defines the hooks and the name of the security module and also the function to shutdown the mediation. Two main hooks were needed, the first is the one responsible to mediate the message exchanges and the second is the responsible to avoid unauthorized process to acquire some service. The shutdown hook is not less important, but less used. Shutdown is only called when the D-Bus daemon is hanging out.

The current implementation of SELinux mediation needs more hooks to work than what I am offering in this PoC. Since the SELinux implementation has some performance improvements by doing caching, it will be necessary to create new hooks to gather some information before deciding whether some message is ok to go or not, but this may be a later discussion.

The patched D-Bus code is available at:

http://cgit.collabora.com/git/user/zimmerle/dbus-lsm.git/

And there is a dummy module at:

http://cgit.collabora.com/git/user/zimmerle/dbus-dummy-lsm.git/

No eXecute and Atom, the current MeeGo state

The security of your box goes over the firewall, or the fact that you are running a platform where all binaries are trusted. Even on that case, is still possible that vulnerabilities of some software or library could be exploited by a malicious party.

The idea behind the NX bit, No eXecute, is to segregate the areas of the memory in two (lets keep it simple :P) big sets, the code execution area and the storage area. According to Wikipedia (http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors), the Atom family has the capability to handle such bit.

Adding this feature and a Linux kernel, is possible to avoid the execution of code in the data area, protecting the system against buffer overflows attack. However some marks should be placed on ELFs to archive such protection, these marks are made in the ELF construction and they can mark the ELF to have or not an executable stack. In the second case the executable flag has no effect, is useless.

The marking can also be made on a library (it is also an ELF, duh!) and when this happens, the software which loads that library will be also allowed to run code inside the data segment, disabling again the protection against buffer overflow.

To check the executable marks of your ELFs, you can use the pax-utils (http://www.gentoo.org/proj/en/hardened/pax-utils.xml). Running the tests on a daily MeeGo image (2010-22-07) the following results were archived:


[root@localhost ~]# scanelf -lpqeR
RWX --- --- /usr/lib/libmono.so.0.0.0
RWX --- --- /usr/lib/paxtest/getmain2
RWX --- --- /usr/lib/paxtest/getheap2
RWX --- --- /usr/bin/mono

This means that libmono and mono, for some reason, are expected to run code on the data segment of the memory. In Fedora the mono is marked as RW, I dunno why it is marked as RWX in MeeGo, further investigation should be done.

Mono’s GNU_STACK on Fedora:

(zimmerle@burbs)-(~/core/meego)$ readelf -l /usr/bin/mono | grep GNU_STACK
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000

Is acceptable to have some process without such kind of protecting, for example Java. Java depends on the executable stack to work. It is also acceptable to have some other binaries like: getmain2 and getheap2. These are used to test if the Machine is handling well the NX bit.

To check if your platform has handled well the support of the NX bit, you can use the pax-test, really nice utility that allows us to check the protection against various kinds of exploration. Tests were also made on the same release used above.

kidde mode:

PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest – Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>Released under the GNU Public Licence version 2 or later

Mode: kiddie
Linux localhost.localdomain 2.6.35~rc6-131.2-netbook #1 SMP PREEMPT Tue Jul 27 14:34:50 UTC 2010 i686 i686 i386 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect) : Vulnerable
Anonymous mapping randomisation test : 12 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 16 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : 10 bits (guessed)
Shared library randomisation test : No randomisation
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Vulnerable

blackhat mode:

PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest – Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux localhost.localdomain 2.6.35~rc6-131.2-netbook #1 SMP PREEMPT Tue Jul 27 14:34:50 UTC 2010 i686 i686 i386 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect) : Vulnerable
Anonymous mapping randomisation test : 12 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 16 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : 10 bits (guessed)
Shared library randomisation test : No randomisation
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Vulnerable

As you can see, we are protected against code execution in any other area than that intended for this purpose. We don’t have randomization on libs due the fact that we are making use of the prelink, subject for another post .

The pax-utils and pax-test pacakges can be found on my security MeeGo repostiory, at:

http://meego.zimmerle.org/repo/security/

If you are interested in testing it by yourself, you can download my ks file here.

That kind of protection is very important almost mandatory, modern system still been hacked by such kind of attack class, when they opt to not provide such protection, the case of Xbox, for example which is exposed to a vulnerability in the 007: Agent Under Fire (http://en.wikipedia.org/wiki/Agent_Under_Fire_(video_game)).

MeeGo: @SELinux on %packages.

I finally bought a netbook and since I am intending to use it with some work stuff (meaning data that requires confidentiality and integrity) I started to tuning my MeeGo to make it more protected before place my data

To make it more protected I think that it is interesting to confine some, let’s say, “untrusted applications”. Which basically means more restrictive control over the processes. Usually I use GRSecurity for that but this time I am using SELinux. Since I am dealing with RPM and Fedora use to be a reference (at least for me) in the support to the SELinux, most of the specs files were copied from Fedora including the policy. The policy should be well refined to fit my needs, but it will be the subject of another post.

Supporting SELinux involves to support not only the kernel part of SELinux (kernel-selinux-netbook), but to support a huge number of packages as you can see bellow:

  • selinux-policy-targeted
  • selinux-policy-doc
  • bwidget
  • selinux-policy
  • setools-libs-python
  • setools-libs
  • libsepol
  • kernel-selinux-netbook
  • libselinux-ruby
  • ustr-debug
  • policycoreutils
  • libprelude-python
  • libprelude-perl
  • policycoreutils-python
  • pax-utils
  • audispd-plugins
  • libselinux
  • perf
  • policycoreutils-newrole
  • libprelude-ruby
  • checkpolicy
  • ustr-debug-static
  • audit-libs-python
  • libsemanage-static
  • setools
  • libsemanage-python
  • ustr
  • libselinux-static
  • audit-libs
  • libsemanage
  • setools-libs-tcl
  • libsepol-static
  • setools-console
  • libselinux-python
  • ustr-static
  • libprelude
  • libselinux-utils
  • audit

Part of these packages are not needed to make the SELinux work, but they are used by auxiliary applications which make SELinux easy to deal with. As you can see, these packages provide dependencies on Ruby, Perl and Python for example. I think we just need the python dependency. The big difference between my packages and Fedora’s packages is the fact that I refuse myself to port the Java SELinux utilities.

All the support to that packages (and also the devel version of them) are available at my MeeGo repo at:

http://meego.zimmerle.org/repo/security/packages/

To add SELinux to your image, you just need to add to your .ks file, the following repo:

repo –name=security –baseurl=http://meego.zimmerle.org/repo/security/packages/
And you also need to place the SELinux package group in the package section:

@SELinux
kernel-selinux-notebook
An example of a kick start file can be downloaded here: http://meego.zimmerle.org/repo/security/build/meego-netbook-chromium-ia32-security-1.0.20100614.1459.ks

You can also download a SELinux MeeGo image at: http://meego.zimmerle.org/repo/security/build/

Here goes a picture of my netbook running selinux kernel:

4702450804_1080c8e351

The policy is not loaded automatically after the boot and the file system is not labeled yet. To load the policy just use load_policy tool.

tcpdump && lipcap on extras-devel

For those who are playing with Maemo and network, now are available at Maemo extras-devel {fremantle|diablo} the tcpdump package and its dependency (libpcap) working like a charm.

iptables on extras devel

The iptables package is on maemo extras devel. There is no support for connection state on the device Kernel consequently the NAT is not working. I tried to compile the modules, but I found myself in trouble trying to load them at the device. If you want to flash a kernel with support for connection state there is one available at my personal repository (read: mWall :: netfilter + ui for maemo for more information). Antoher discussion about that modules can be found: here.

screenshot05

mWall :: netfilter + ui for maemo

Something that certainly bothers me is the fact that i am always online independent of the network. I walk with my n900 in the pocket and sometimes I am using 3g, sometimes using wifi. I am jumping from trusted to untrusted wifi spots, and I have the strange feeling that maybe once (or more…) I will be part of a honeypot, malicious network or something like that.

As part of this type of network my device can be easily identified as an N900. (e.g. MAC address). Once the device is identified a person or a malicious software can start to guess passwords (rootme?) and can try to exploit softwares that are under development.

Avoiding been hacked on that situation I decided to write a small firewall UI for the n900 (netfilter/iptables back end), that allows me to block any incoming connection that is not authorized.

screenshot021

This is just a very first version of the firewall, a lot to be done yet. To install it on your device, check for mWall at my personal repository.

You can install my repository by clicking here: zimmerle’s repo.

I also provide in my repository: the iptables package and a kernel with support to iptables state match. The iptables binary was marked with the suid bit, allowing its execution by users without super powers. But this should be fixed in the next release.

Let me advise you that the firewall rules are not permanent, I mean, you need to run the firewall in every boot. It is under development.

The code is available at: http://git.zimmerle.org