Skip to content

Restoring external symbol calls in IDA when ELF sections are deleted

Some time ago I wrote ZwoELF, an ELF parsing and manipulation library for Python, to learn about the ELF format. I used it for the hack.lu 2013 CTF challenge ELF to manipulate the binary file after it was compiled and linked. While writing ZwoELF I soon realized that almost every analysis tool rely on the sections of the ELF binary (like IDA, readelf and even strings). The problem with this is, the sections are optional and are not needed to execute the binary file. This means the sections can be missing or even be totally misleading. So I wrote ZwoELF with the intention to ignore the sections of an ELF binary and still try to get the same results (the example script "readElf.py" gets the same information that "readelf" of the "elfutils" packet gets but without using the sections).

Since almost all ELF analysis tools rely on sections, one of the obvious obfuscation techniques that can be used (for CTF challenges or by malware authors) is to delete the sections of an ELF binary. When they are deleted, IDA for example is not able to show you calls to external symbols like a call to "malloc()" or "printf()" (or at least I do not know how, I am not an IDA expert but I did not find anything on the Internet about it. If anyone knows an easier way to do it, please let me know).

Here is an example image of the "main()" function of the x86 "ls" binary.



And exactly there was my problem. The sections where deleted and I wanted the calls to external symbols be shown in IDA (I have access to IDA 6.1.1100421). The simplest way I could come up with was to use ZwoELF in combination with IDAPython. I wrote this small IDAPython script to restore the names of the symbols.

Here is the "main()" function of the x86 "ls" binary again, but this time after the IDAPython script was used.



At the moment, the ZwoELF library does only work with x86 binaries. But we (FluxFingers) need it for a project we are working on that will also be used with x86_64 binaries. So I think in the next time ZwoELF will also support x86_64 binaries.

eduroam WiFi security audit or why it is broken by design

Edit on 9th July, 2015

This article seemed to inspire a student to write his Diploma thesis about the topic. After some coincidences, I was asked to help to write an academic paper about the investigation and results of the thesis. This paper was published at the ACM WiSec 2015 conference in NYC. If you are interested in the findings, I would suggest to you to read the paper "A Practical Investigation of Identity Theft Vulnerabilities in Eduroam" instead of this blog article. This blog article was just a quick look into the deployed eduroam network and not a researched study.

A last fun fact: We had also a demo at the ACM WiSec 2015 were we used a self-signed certificate for a rogue eduroam access point. Even there the results were that over 50% of the attendees had wrongly configured eduroam devices and were therefore prone to an easy identity theft attack.


Start of the original article

Over Christmas I got a TP-Link TL-WN722N USB WiFi device which is supported by hostapd and finally I could test what I always wanted to test: eduroam.

But first, what is eduroam? Eduroam is a WiFi network located at universities around the world with the goal to provide internet access to students and university staff on every university that supports eduroam ( https://en.wikipedia.org/wiki/Eduroam ). This means I can connect to the internet with eduroam at a university in France with my user credentials from my university in Germany. Sounds good, but how does it work? Well, the WiFi network uses WPA-Enterprise, which means you connect to an access point and the access point uses a radius server to authenticate you. Generally not a bad idea. But my tests have shown that the practical deployment of the eduroam network is broken by design.


In advance

First things first. Some of my notes that I took from my tests can be seen here. I will provide them as a "POC||GTFO". But I stripped them to not provide a step by step tutorial in "how to pwn eduroam".


The set-up

I configured a VM with Debian Wheezy with an installation of hostapd. I never had configured a radiusd and wondered how I can get the user credentials if a client device would authenticate to my rogue access point. Well, I found this cool project https://github.com/brad-anton/freeradius-wpe.git. This does everything for me and I do not have to patch the radiusd myself. But honestly, I do not trust this modified radiusd entirely and after I configured everything I turned of the network interface of the VM which provides an internet connection to prevent the radiusd from leaking something of my tests to the internet.


Test without a certificate modification

On my first test I just set everything up and started it. I started wpa_supplicant on my laptop and it does not connect to the rogue access point because the certificate is wrong. Ok, but what with my Android device. I activated the WiFi on my mobile phone and ... WTF I am connected to the rogue access point. In the log file of the rogue access point I can read my user credentials in PLAINTEXT. Ok, that is not good. But what went wrong? The certificate used by the rogue access point is still invalid. The configuration on my Android device is completly flawed. I configured my Android device like the tutorial on my universities website said. The tutorial said that I do not have to configure any CA and use PAP for the phase2 of the WPA-Enterprise authentication. Now you can say "Idiot, everyone can see that this is wrong!". But to my defense, I always thought that Android then uses its own installed CAs to check if the certificate of the access point is valid. Hell, even the network-manager on ubuntu warns you if you give no CA in the settings. And I used PAP (I knew it sends the user credentials in cleartext) because I thought of the tutorials of my university that eduroam does only support PAP for the phase2 authentication. But both thoughts were wrong.

After I installed the "Deutsche_Telekom_Root_CA_2" CA on my Android device and used it in the WiFi configuration it no longer connects to the rogue access point.

Also, when the wpa_supplicant configuration misses this line:


ca_cert="/etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem"
 


it also ignores the invalid certificate of the access point and just connects to it.

I wrote the helpdesk of my university about the wrong tutorial for using eduroam on Android devices. The helpdesk replied to me that they knew this problem with the CA but Android is not able to verify the certificate of the access point. This is obviously wrong. And the funny thing about this is, they used screenshots in their tutorial to make it easier for everyone to configure eduroam on Android devices. And on these screenshots you can see the "CA certificate" option which is just ignored. Also their reply told me some other interesting things about eduroam, which I checked in my next tests.

As a summary for my first test: always configure the CA for eduroam (and in general for all WPA-Enterprise WiFi networks) and always use MSCHAPv2 instead of PAP. Even if your device connects to a rogue access point the adversary only gets challenge-response values and has to brute-force this. When your password is strong enough, the adversary can not use your credentials (at least he has to spend time brute-forcing MSCHAPv2 ...).


Test with an own certificate

In the eMail reply of the helpdesk of my university they wrote me that when the user added the CA to his WiFi settings, this would destroy the idea behind eduroam (to be able to connect to every eduroam access point in the world). First, I wondered about the "destroy the idea behind eduroam" part but then I thought "They would not be so stupid, would they?". I always thought that they agreed to use the "Deutsche_Telekom_Root_CA_2" CA for eduroam. But this is not the case. A friend of mine was in Belgium and had to change the configured CA in his WiFi settings to connect to eduroam there. I searched through some websites for eduroam tutorials of universities of other countries than Germany and they all used different CAs. Normally, the access point is configured to use a specific radius server which will send the certificate to the client (I do not know if it is even possible to use WPA-Enterprise in any other way). This means that by not agreeing on one CA for the entire eduroam infrastructure, the user has to NOT configure any CA in his WiFi settings to be able to use eduroam in the way it was intended to. And with this, we have the first reason for eduroam being insecure by design.(*)

The eMail also stated that even if the user added the CA to his WiFi configuration, this would not help. An adversary could get a certificate signed by the CA and could therefore set up a rouge access point. This statement is true. But this holds for every public key infrastructure. For HTTPS for example a CA should not sign my certificate for "gmail.com" (unless I can prove that this is my domain/address). And at this point a question comes to mind. The client gets the certificate by the access point and then checks with the configured CA if it is valid. But valid for what address? Normally, the CN (common name) in the certificate is checked with the used address. But with what address is the certificate provided by the radius server checked?

A valid connection to the eduroam WiFi at my university with wpa_supplicant looks like this:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with 00:25:45:b5:38:22
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=radius.ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
wlan0: WPA: Key negotiation completed with 00:25:45:b5:38:22 [PTK=CCMP GTK=TKIP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:25:45:b5:38:22 completed (auth) [id=0 id_str=]
 


The address given in the CN is "radius.ruhr-uni-bochum.de". But I never configured this anywhere. So in my next test I created my own CA and signed my own certificate with it. The certificate for the rogue access point and the CA got the following values:


CA:
C=DE
ST=Some-State
O=h4des.org
CN=sqall

certificate for rogue access point:
C=DE
ST=Some-State
O=h4des.org
CN=some-rogue-access-point
emailAddress=sqall
 


You can see, that the CN field got "some-rogue-access-point" as value, which is no address for a radius server at all.

First I tried wpa_supplicant with my newly created CA certificate in the configuration file:


ca_cert="./CA.cert.pem"
 


And what happened? wpa_supplicant connects with the rogue access point without any problems and discloses my user credentials as MSCHAPv2 challenge-response values. The output of wpa_supplicant shows that the radius server uses my newly created certificate.


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with b0:48:7a:88:fc:7a
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Some-State/O=h4des.org/CN=sqall'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Some-State/O=h4des.org/CN=some-rogue-access-point/emailAddress=sqall'
EAP-TTLS: Invalid authenticator response in Phase 2 MSCHAPV2 success request
 


Next I tested it on my Android 4.0.4 device. I installed my own CA on the device and changed the eduroam WiFi settings to check for this CA. The device connects with the rogue access point without any problems and also discloses my user credentials.

As a summary for this test: the certificate for the rogue access point just have to be a valid certificate signed by the used CA. It does not matter for which address the certificate was issued, it just have to be valid. Normally, the problem for forging a valid host in an TLS/SSL connection (such as the HTTPS example for "gmail.com" I gave earlier) is, that a CA does not sign your certificate request unless you own the domain/address (or rather the CA should not). But if you can use any address in the CN, it is no problem to get a signed certificate. Here lies the second reason for eduroam being insecure by design. I do not know if the vendor got a service to sign your own certificates with the "Deutsche_Telekom_Root_CA_2" certificate. But normally they do. And if the vendor does, there is absolutely no problem to configure a rogue access point which can not be distinguished from a valid one.

It should be mentioned, that the address of the radius server can be configured in the iDevice profiles. But I have no iDevice and so I can not check if the CN of the certificate provided by the radius server is checked against the configured address. In wpa_supplicant for example I did not found any configuration option for the address of the radius server. But I found the option to match certain criteria of the accepted server certificate with "subject_match". Android 4.0.4 does not provide any such options.


Test with an own intermediate CA

After an arbitrary signed certificate was tested, the next interesting thing is a certificate signed by an intermediate CA. When we look at the wpa_supplicant output when connecting to a benign access point:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with 00:25:45:b5:38:22
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=radius.ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
wlan0: WPA: Key negotiation completed with 00:25:45:b5:38:22 [PTK=CCMP GTK=TKIP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:25:45:b5:38:22 completed (auth) [id=0 id_str=]
 


we can see, that the certificate is signed by the CA of my university (and not the "Deutsche_Telekom_Root_CA_2" CA). Actually, the chain is "Deutsche_Telekom_Root_CA_2" -> "DFN-Verein PCA Global - G01" -> "Ruhr-Universitaet Bochum CA". So my idea at this point was, it could be difficult (and perhaps costly) to get a signed certificate by the "Deutsche_Telekom_Root_CA_2" CA, but a signed certificate by the university is very easy as student or university staff. So, I created my own intermediate CA signed by my formerly created CA and generate a new certificate for my rogue eduroam access point. The values for all these CAs and the certificate are:


CA:
C=DE
ST=Some-State
O=h4des.org
CN=sqall

intermediate CA:
C=DE
ST=Some-Other-State
O=h4des.org
OU=intermediate
CN=it is sqall again

certificate for rogue access point:
C=DE
ST=Some-Other-State
O=h4des.org
OU=intermediate certificate
CN=again sqall
 


Again, wpa_supplicant is tried first. The settings are the same as for the test before (this means wpa_supplicant uses the certificate of the CA to check the validity of the rogue access point). The output of wpa_supplicant shows, that the rogue access point offers my new certificate signed by the intermediate CA and that the client connects without any problems:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with b0:48:7a:88:fc:7a
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/ST=Some-State/O=h4des.org/CN=sqall'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Some-Other-State/O=h4des.org/OU=intermediate/CN=it is sqall again'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Some-Other-State/O=h4des.org/OU=intermediate certificate/CN=again sqall'
EAP-TTLS: Invalid authenticator response in Phase 2 MSCHAPV2 success request
 


The log file of my modified radius server shows me the MSCHAPv2 challenge-response values:


mschap: Sat Jan 11 19:42:27 2014

        username: pawlxyz@ruhr-uni-bochum.de
        challenge: 43:cd:42:0f:a6:14:46:4e
        response: 0d:b8:47:c0:11:a6:c9:10:a2:14:99:af:1d:15:d6:ef:4a:89:d3:95:aa:ba:2d:2b
        john NETNTLM: pawlxyz@ruhr-uni-bochum.de:$NETNTLM$42cd490fa604464c$0db486c012a6c910a21379ef1d15d6ff4a89d395baba2d2c
 


Next I tested my Android 4.0.4 device. Like the wpa_supplicant client, it connects without any problems (because the access point is now considered valid).

As a summary for this test: the client accepts certificates that are signed by intermediate CAs. In this constellation, it is the third reason for eduroam being insecure by design. It might be difficult to get a signed certificate by the main CA. But when intermediate CAs are in place, it could be a lot easier to get a valid certificate. The "Deutsche_Telekom_Root_CA_2" CA signed the "DFN-Verein PCA Global - G01" intermediate CA and this signed the CA of my university. I think that the "DFN-Verein PCA Global - G01" intermediate CA signed a lot of university CAs. And a lot of universities (like mine) offer the service to sign your server certificate (when it is inside the namespace of the university). When you are able to get a certificate that is signed by anyone of the CAs in the chain, you can forge a valid eduroam access point.


Test with a server certificate signed by my university

Ok, all the talk about "uhh, it is insecure with this used public key infrastructure!" and "it is theoretically possible to ...", let's break it! I helped the university to set up some servers. So I have access to a certificate signed by the university CA. And I configured my rogue access point to use this certificate. This certificate obviously does not have "radius.ruhr-uni-bochum.de" as CN value. It is valid for other addresses which I censored out. We saw in the tests above that the value in the CN field does not matter.

First I tried wpa_supplicant. Now with the settings that should be used for a valid eduroam access point. This is the output:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with b0:48:7a:88:fc:7a
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/OU=xxx/CN=xxx'
EAP-TTLS: Invalid authenticator response in Phase 2 MSCHAPV2 success request
 


And we can see that the client thinks it is a valid eduroam access point. The log file of the modified radius server shows my MSCHAPv2 credentials:


mschap: Sun Jan 12 01:24:03 2014

    username: pawlxyz@ruhr-uni-bochum.de
    challenge: 28:f5:bf:4d:3f:fe:bf:a2
    response: 7a:ab:24:87:35:82:46:40:33:73:89:5a:77:bb:ee:c0:4b:56:8b:a8:67:af:e9:94
    john NETNTLM: pawlxyz@ruhr-uni-bochum.de:$NETNTLM$28f5bb4d8ffaafa2$7aab248735824641d373895a77dbeec04b568ba867afe994
 


The same goes for my Android 4.0.4 mobile phone. A client is not able to distinguish a benign eduroam access point from my rogue access point.

A fun fact that happened when I just started my rogue access point with the valid certificate: the mobile device of one of my neighbors connected instantly to my rogue access point (his or her login credentials are from a different university than mine). One has to love all the folks that have their WiFi always turned on :-)


Test with a client certificate signed by my university

My university has the service to provide any student with a client certificate signed by the university's CA. My idea was "most clients do not provide options for the radius server address, perhaps they do not check if the certificate is only for clients". Beforehand, I can tell you that wpa_supplicant and Android 4.0.4 do (I did not test others).

I used a certificate with this key usages and signed by my university's CA:


X509v3 Key Usage:
        Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
        TLS Web Client Authentication, E-mail Protection
 


So, when I try to connect with wpa_supplicant I get this output:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with b0:48:7a:88:fc:7a
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication starte
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
TLS: Certificate verification failed, error 26 (unsupported certificate purpose) depth 0 for '/C=DE/O=Ruhr-Universitaet Bochum/CN=sqall'
wlan0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=0 depth=0 subject='/C=DE/O=Ruhr-Universitaet Bochum/CN=sqall' err='unsupported certificate purpose'
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unsupported certificate
OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
 


So we can clearly see, that wpa_supplicant checks the certificate purpose. The same goes for Android 4.0.4. It just tells me authentication error.

To summarize this part: this does not have anything to do with the design or security of the eduroam network. This is only an implementation thing of the used client software. I just tested it with the hope to find a "fuck up" of some WiFi clients, but was disappointed ;-)


Conclusion

In this part I conclude my short security audit of the eduroam WiFi network. In my opinion it has a huge design flaw which is not to fix without changing the whole public key infrastructure. For me it seems that when they were designing the whole eduroam network they just thought "We need some public key cryptography for eduroam. The protocol supports TLS/SSL for authentication. It is used by the internet. So let us just use it too!". Using different CAs in different countries which signed a lot of intermediate CAs is not a good idea when the clients do not/can not check the address of the radius server which provides the certificate. Every certificate that is signed by one of the intermediate CAs or the used top CA is valid for any client that tries to connect to the eduroam WiFi. Furthermore, the idea of eduroam was to provide a network to which a client from a different country could also connect (for example, a client from Germany could connect to an eduroam access point when he is in Belgium). This is not possible when different top CAs are used in each country (or perhaps even within a country). Or rather this is only possible when certificates are not checked. But when they are not checked, what is the point of using TLS/SSL?(*)

The next thing is, a lot of universities (like mine) provide flawed tutorials to configure WiFi clients for eduroam. Even when MSCHAPv2 is available, the tutorials often used PAP to authenticate the client. PAP sends all user credentials in plaintext whereas MSCHAPv2 provides a challenge-response procedure. Furthermore, a lot of tutorials do not set up the CA to check the server certificate. Without this setting the client connects to any eduroam access point without checking the validity of the server certificate. This means, when an user configured her client with the help of the flawed tutorials and uses eduroam, she could just as well shout out her credentials everytime she is connecting to the WiFi network.

The really bad thing about this is, when an adversary gets the user credentials of someone, he often has the user credentials for other services of the university as well because the same account is used (in the case of my university for the email account, the MSDNAA account, ...). I heared of some universities that even use these credentials to let the student subscribe/unsubscribe for exams of the offered courses.

The only way a client can protect herself against this attack is by using MSCHAPv2. When MSCHAPv2 is used, the adversary still has to brute force the password when he successfully forges an eduroam access point. This means the security comes from the strength of her password (and the strength of MSCHAPv2 ... which uses DES and can be cracked relatively fast with services like https://www.cloudcracker.com/ :/ ).

In my opinion, the only way to really fix this issue is to use an own public key infrastruture for the whole eduroam WiFi design. When an own CA is used for eduroam (perhaps with intermediate CAs for universities to use only for certificates that are used by the eduroam infrastructure) there is no way to forge a valid eduroam access point for an attacker, because he can not get a signed certificate for it. When the clients set up the CA in their eduroam settings, they would not connect to rogue access points. Even if the client is configured to use PAP instead of MSCHAPv2, the user credentials are secure in a way. But the own public key infrastructure would only work when the clients are configured correctly and this means that the universities have to fix their tutorials for the eduroam WiFi first.

I wrote my university about this issue and they fixed some tutorials (for example for Android). But not all are fixed (for example for wpa_supplicant) and I do not think that they will fix all of them. But even so, fixing the tutorials will not help when a lot of students and university staff already applied the flawed configurations.


Errata

(*)In the time of writing this article, I have not tested this statement. I just based it on the settings you can made in an access point, the statement of my university and the statement my friend had made. However, yesterday night I drove to the next city to test this statement at an other university (the TU Dortmund). Honestly, I did not expect this result:


wlan0: Trying to associate with SSID 'eduroam'
wlan0: Associated with 00:14:a8:14:86:f1
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=3 subject='/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=radius.ruhr-uni-bochum.de'
EAP-TTLS: Phase 2 MSCHAPV2 authentication succeeded
 


The wpa_supplicant output shows that even when I am at another university in Germany and use eduroam there, the CA chain looks the same as at my university. This means that my WiFi client still connects to the radius server of my university. I did not expect that (and have not really an idea how this infrastructure works exactly). Unfortunately, I have no way to test it with an university in a foreign country. Nevertheless, my conclusion which states that an own CA should have been used for the eduroam infrastructure remains the same.


Update on 27 January 2014

@fadenb send me this link via twitter. It shows a nice compatibility matrix for eduroam WiFi clients. This site states (like this article) that Android is not able to check the certificate of the radius server against an address. Also a lot of other clients are tested.

I also want to mention that my university updated almost all tutorials for the eduroam client configuration on their website by now. Unfortunately, not many of them check the radius server address in their configuration. I send them my wpa_supplicant configuration file (which checks the certificate with "subject_match") and they uploaded it to their website. At least some people which use these tutorials have a secure configuration now.

openvpn-auth-ldap STARTTLS and authentication bug finally fixed

Over a year ago I found a bug in the openvpn-auth-ldap module (bug report and patch for debian here and an explanation on my blog in german here).

Yesterday I got an eMail that this bug report is now fixed and closed.

We believe that the bug you reported is fixed in the latest version of
openvpn-auth-ldap, which is due to be installed in the Debian FTP archive:

openvpn-auth-ldap_2.0.3-2.debian.tar.gz
to main/o/openvpn-auth-ldap/openvpn-auth-ldap_2.0.3-2.debian.tar.gz
openvpn-auth-ldap_2.0.3-2.dsc
to main/o/openvpn-auth-ldap/openvpn-auth-ldap_2.0.3-2.dsc
openvpn-auth-ldap_2.0.3-2_i386.deb
to main/o/openvpn-auth-ldap/openvpn-auth-ldap_2.0.3-2_i386.deb

A summary of the changes between this version and the previous one is
attached.

[...]

Changes:
openvpn-auth-ldap (2.0.3-2) unstable; urgency=low
.
- Acknowledge Matthias Klose's NMU for #625146.
- patched/STARTTLS_before_auth.patch: Run STARTTLS before authenticatingi
to the LDAP server. Thanks Andre Pawlowski for finding this and the fix.
(Closes: #610339)
- debian/control: added Homepage field, added autotools-dev Build-Dep
- Added debian/source/format
- Added debian/watch
[...]


I have to say, it took a long time and I'm already forgot about the report (because I used a self compiled version of it with the fix). But I'm glad it's finally fixed, because I saw this module in a lot of environments used and the admins I talked to didn't know about this behavior of this module (and never would find out because they allowed anonymous access to their OpenLDAP system).

social engineering - the 2nd practical example

Last Friday I had my next practical social engineering event. But before I start here a short info why it came to this situation.

I worked for three years as a sysadmin at an university in the german state NRW. Therefore I was paid by the LBV ("Landesamt für Besoldung und Versorgung") like every employee for the state NRW. And everyone I know who is paid by the LBV has a story in which they had problems with an incompetent LBV employee. Perhaps it's not always the employee, just the bureaucracy, but EVERYONE who has something to do with the LBV knows what I mean. Now I study IT-security at another university in NRW and got an offer for an sysadmin job at this university. Well, studying is expensive and so I take this job. When I quit my old job a year ago, the LBV didn't send me all my documents back I now needed for the new job (the important one was a document for the taxes). Now a logical mind would say: "Hey, the LBV has the documents from your old job, why can't they use these documents for the new one?". Well, I said something like that. But the truth is, they must send me the documents back and my new employer will send them back to the LBV. And the problem is: the LBV works very slow and the time is short in this case.

Therefore I was on my way to the tax office to get a replacement for the document for the taxes. After I was in two offices talking to some very impolite employees about my problem I went to the third and last one. I was a little bit angry for this impoliteness and thought about how I can handle the next employee without getting this rude behavior. I thought about "killing them with kindness" (a very easy and cool method my girlfriend mastered... really, she is a master in manipulate others with her kindness. She does it unconsciously, but she does.) but I tried this at the two employees before and it doesn't work well for me (it seems like every employee at an office that is run by the state hates their jobs). I thought about: "How can I get the employee in the last office put himself in my position?". And the solution was very simple and very effective. The solution (and the problem ;-) ) was the LBV.

So I told the employee (it was a middle-aged woman) about my problem and at the end I added: "... but you know the LBV. I think you had problems with the LBV yourself.". She starts to smile and I know I got her. She told me some stories about her and the LBV and I told her some of my stories. From here, it took only 2 minutes and I had the replacement for the document.

So what do we learn here?

First of all: "Never underestimate the effect of the kindness of your girlfriend" ;-)
Second: "State Offices suck!"
And the last one: "Kindness and to get the other put her/himself in your position will work for your benefits"

social engineering - a practical example

Do you know these photobook services, where you can create your own photobook online and let it be sent to a local store? Well, my girlfriend has used this service a week ago and the photobook was sent to a local store (a german chain of stores called DM). I was in the city and she texted me her costumer and job number. When I was at the store I searched through all the packets of photobooks and finally find hers. On the package her name, her job number and her costumer number was written. I went to the cashier and wanted to pay for it when she asks me to show her the order form.

What now? I didn't want to go home and get the form for her so I have to try it with some discussing ;-)

I told her polite and friendly that this photobook is obviously not for me but for my girlfriend and she is away from town for the next two weeks and she texted me her costumer and job number so I get it for her. I showed the cashier the text message on my mobile phone with the name of my girlfriend on the top and she sold me the photobook.

Well I didn't lie with the "my girlfriend is away from town the next two weeks" thing but the order form was lying on my desk at home.

This is a great practical example for social engineering. The names, job and costumer numbers were written on the packages of the photobooks. I could grab any of them, send myself a text message on my mobile phone and change the addressbook entry with my own number to the name on the photobook. Then I can say something like this to the cashier "This photobook isn't for me. My brother sent me his costumer and job number so I can get it for him." and show him the text message. I would say 99% of the cashiers would sell you the package with the photobook.

The text message is a very important thing. I think that a lot of cashier wouldn't sell you the photobook without the text message. It's a little bit like Chrisopher Hadnagy has written in his book "Social Engineering - The Art Of Human Exploiting". He wrote a great story with a business card in it and that it's easier to make other people believe you when have something written that supports your story. In his case I think it was a TSA employee that let him pass the security check with his IT stuff because he had shown a business card that said that he is an IT security auditor.

What do we learn through these stories? You should always have a business card with you that tells people who you are (or who you wanted to be ;-) ) and never order photobooks with really private stuff in it ;-)