DNS filtering

The normal DNS response to resolving thepiratebay.org using an unfiltered DNS resolver (and omitting the MX records) is:

$ host thepiratebay.org
thepiratebay.org has address 194.71.107.15

Using the default Ziggo DNS resolver this now gives:

$  host thepiratebay.org
thepiratebay.org has address 212.54.32.19

Using the xs4all DNS resolvers, the response is:

$ host thepiratebay.org
thepiratebay.org has address 194.109.6.92
thepiratebay.org has IPv6 address 2001:888:0:18::80

So the IP address of thepiratebay.org has been replaced with an IP address controlled by the ISP. On the Ziggo IP address the following message is shown:

xs4all chose to display a more informative message:

IP filtering

Besides various domain level bans, the court also ordered the blocking of 3 specific IP addresses. This seems logical because otherwise new DNS records pointing to thepiratebay.org IP address would probably pop-up faster than plaintiff BREIN would be able to add them to the block list. From a Ziggo connection, the traceroute to an unblocked IP address looks like this:

Tracing the path to 194.71.107.14 on TCP port 80 (http), 30 hops max
1  10.10.10.10  1.033 ms  0.323 ms  0.322 ms
2  * 53563a01.cm-6-7a.dynamic.ziggo.nl (83.86.58.1) 7.521 ms  7.774 ms
3  gv-rc0052-ds102-vl202.core.as9143.net (213.51.161.161)  7.657 ms  8.891 ms  7.943 ms
4  gv-rc0011-cr102-ae12-0.core.as9143.net (213.51.158.251)  7.859 ms  9.467 ms  7.554 ms
5  asd-tr0409-cr101-ae8-0.core.as9143.net (213.51.158.26)  10.406 ms  7.016 ms  8.157 ms
6  xe-8-0-1.edge4.amsterdam1.level3.net (212.72.40.173)  38.330 ms  15.699 ms  12.082 ms
7  4.68.110.198  10.337 ms  10.172 ms  8.879 ms
8  te3-2-10g.ar1.snv2.gblx.net (67.16.139.82)  151.346 ms  152.009 ms  154.799 ms
9  xe-1-0-1.cr1.sfo1.us.nlayer.net (69.22.153.205)  152.695 ms  156.498 ms  152.759 ms
10  as40475.ge-0-2-1.cr1.sfo1.us.nlayer.net (69.22.153.90)  152.918 ms  154.384 ms  164.536 ms
11  ge-0-1-0.ro4.sjc01 (208.83.220.46)  170.319 ms  165.839 ms  169.114 ms
12  ge-0-0.cal-cr-0.srstubes.net (74.116.251.2)  168.702 ms  171.355 ms  167.281 ms
13  ge-0-4.sth3-core-1.srstubes.net (194.68.0.194)  179.128 ms  180.895 ms  179.933 ms
14  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  180.699 ms  183.876 ms  180.785 ms
15  ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  179.694 ms  179.994 ms  183.420 ms
16  * * *

A traceroute to a blocked IP address looks like this:

Tracing the path to 194.71.107.15 on TCP port 80 (http), 30 hops max
1  10.10.10.10 0.414 ms  0.331 ms  0.318 ms
2  53563a01.cm-6-7a.dynamic.ziggo.nl (83.86.58.1)  48.198 ms * *
3  gv-rc0052-ds102-vl204.core.as9143.net (213.51.165.33)  13.757 ms  17.851 ms  7.605 ms
4  * * *
5  * * *

So it looks like the IP block is in effect on the Ziggo core router gv-rc0011-cr102-ae12-0.core.as9143.net.

From xs4all a unblocked trace looks like:

Tracing the path to 194.71.107.14 on TCP port 80 (www), 30 hops max
1  124.ae0.xr3.3d12.xs4all.net (194.109.21.13)  0.473 ms  0.313 ms  0.242 ms
2  nl-asd-dc2-ice-ir01.kpn.net (139.156.201.90)  11.780 ms  5.290 ms  11.953 ms
3  nl-asd-dc2-ias-csg01-ge-5-2-0.kpn.net (139.156.113.103)  0.373 ms  0.404 ms  0.367 ms
4  * * *
5  ae3-60g.cr1.ams2.nl.nlayer.net (69.22.139.238)  80.351 ms  80.317 ms  80.271 ms
6  xe-5-3-0.cr1.lhr1.uk.nlayer.net (69.22.142.94)  7.086 ms  7.045 ms  7.034 ms
7  xe-11-3-1.cr1.nyc3.us.nlayer.net (69.22.142.132)  80.444 ms  80.434 ms  80.466 ms
8  ae2-70g.cr1.ewr1.us.nlayer.net (69.31.95.145)  80.811 ms  80.803 ms  80.864 ms
9  xe-5-0-0.cr1.ord1.us.nlayer.net (69.22.142.74)  95.314 ms  95.363 ms  96.473 ms
10  xe-1-2-0.cr1.slc1.us.nlayer.net (69.22.142.102)  133.934 ms  132.688 ms  133.005 ms
11  xe-2-0-1.cr1.sfo1.us.nlayer.net (69.22.142.97)  146.579 ms  146.584 ms  146.568 ms
12  as40475.ge-0-2-1.cr1.sfo1.us.nlayer.net (69.22.153.90)  144.234 ms  144.108 ms  144.151 ms
13  ge-0-1-0.ro4.sjc01 (208.83.220.46)  143.621 ms  143.520 ms  143.585 ms
14  ge-0-0.cal-cr-0.srstubes.net (74.116.251.2)  143.196 ms  143.176 ms  143.300 ms
15  ge-1.sthix.srstubes.net (192.121.80.164)  171.578 ms  171.738 ms  171.557 ms
16  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  172.213 ms  175.003 ms  172.384 ms
17  sthix-ge-0-2.moria-cr-1.piratpartiet.net (192.121.80.181)  171.678 ms  171.728 ms  171.847 ms
18  * * *

and a trace to a blocked IP address:

Tracing the path to 194.71.107.15 on TCP port 80 (www), 30 hops max
1  * * *
2  * * *

I only have an xs4all shell account (no ADSL connection), but it seems the IP block is done quite early in the network. This is most likely to not affect other KPN owned ISPs.

Effectiveness

So is this an effective block to prevent the use of thepiratebay.org website? It is what the court ordered, and maybe it will stop a casual user. However, it is rather trivial to bypass. By using a proxy or VPN to a non-filtering ISP it is very easy to still get access to the site. There are also a number of mirrors/proxy sites that are still accessible. BREIN is allowed by the court to add to the blocklist as they see fit, so we will see how long they will survive. Some examples:

1. http://tpb.piratenpartij.nl/
2. http://thepiratebay.ee/
3. http://deblokkeer.nl/
4. http://thepiratebay2.nl/

xs4all has an up-to-date list of which domains are being blocked.

named[15984]: client 2001:da8:8000:d010:0:5efe:daf1:6c89#40681:
  query (cache) 'www.cnnic.cn/A/IN' denied
named[15984]: client 2001:da8:8000:d010:0:5efe:daf1:6c89#40681:
  query (cache) 'www.cnnic.cn/A/IN' denied
named[15984]: client 2001:da8:8000:d010:0:5efe:daf1:6c89#43074:
  query (cache) 'www.cnnic.cn/A/IN' denied
named[15984]: client 2001:da8:8000:d010:0:5efe:daf1:6c89#40683:
  notify question section contains no SOA

That IPv6 address is owned by Shanghai Jiaotong University:

inet6num:       2001:0DA8:8000::/48
netname:        SJTU6-CERNET2
descr:          ~{IO:#=;M(4sQ’~}
descr:          Shanghai Jiaotong University
descr:          Shanghai 200030, China
admin-c:        WW390-AP
tech-c:         WW390-AP
tech-c:         CER-AP
country:        CN
changed:        hostmaster@net.edu.cn 20041129
mnt-by:         MAINT-CERNET-AP
status:         ASSIGNED NON-PORTABLE
source:         APNIC

So what could be the reason for these requests? Are they trying to determine which IPv6 addresses are running DNS resolvers for visitors of Chinese domains? But they couldn’t possible be scanning the complete IPv6 space? Or is that actually feasible?

If you have seen the same entries in your logs, please let me know in the comments.

It is widely accepted that authenticating with only a username and password is not very secure. No matter how complex or long you make a password, it can be copied, intercepted, phished, etc. A lot of effort has been put into securing passwords. Encrypting them when stored on the server side, encrypting them while in transit (SSL/TLS), encrypting them for users that cannot remember it (KeePass, Password Safe). This does not solve the phishing problem. A user that can be tricked to enter his password in the wrong window or on the wrong site basically hands over the keys to the safe.

To protect against password theft (like phishing) one-time passwords were invented. As the name implies, these passwords can be only used once. In order to know what password to enter next, various methods exist:

• TAN list, often used by banks
• Hardware token, such as RSA or Vasco tokens
• Software token (i.e. running on a mobile phone)
• SMS message

This introduces the concept of two-factor authentication. A higher level of security can be achieved when a user is required to present two out of three categories of means to identify himself:

• Something you know (like a username or password)
• Something you have (like a physical key, a token or a mobile phone)
• Something you are (often implemented using biometrics like fingerprints, hand geometry or retina scan)

This sounds very secure, but unfortunately two-factor authentication does not protect against man-in-the-middle attacks. The classic scenario where Alice and Bob are communicating and Mallory is able to change what is being sent back and forth. Mallory and read the one-time password sent by Alice from the wire, and tell Alice that Bob is unavailable. Mallory then proceeds to authenticate against Bob using the credentials stolen from Alice.

The general protection against man-in-the-middle attacks is using a Public Key Infrastructure (PKI). The most widely known PKI is probably the SSL/TLS PKI implementation used for webservers. The core idea is that servers prove their identity to a Certificate Authority (CA) that in return signs their SSL certificate. Before Alice sends her credentials to Bob, she requests his SSL certificate. Alice checks the certificate is signed by a CA she trusts. If it is not, Alice will not proceed.

Mallory can change the certificate midway, but the idea is that she cannot present Alice with a valid certificate with Bob’s name in it that is signed by a trusted CA. This is the mechanism that is protecting the web since 1995. Coupled with two-factor authentication it was pretty strong. Until 2011 that is.

First in march 2011 an Italian reseller of the Comodo CA was hacked. Various false SSL certificates were signed for high profile sites such as Google Gmail, Yahoo Mail, and Microsoft Hotmail. Fortunately, Comodo found out and revoked the certificates before any harm could be done. Then in August a user from Iran noticed his Chrome browser gave a certificate warning when browsing to GMail. Investigation showed that a false certificate was being used by the Iranian government to intercept the traffic. The false certificate was signed by the Diginotar CA that was hacked in July 2011. These incidents show that relying on PKI server side certificates alone is not secure. The EFF SSL Observatory calculated there are around 650 organizations that function as a trusted CA in today’s browsers. Even though a server only uses a single CA for it’s certificate, an attacker can target any of the 650 CAs to get a fake one. Any certificate signed by any one of the 650 CAs will be trusted by the browser.

The only reason Google Chrome gave a warning is because both Chrome and GMail are products of Google. Google implemented an additional check for it’s own sites to see if they were indeed signed by the correct CA (SSL pinning). There have been several other proposals to fix the 650 trusted CAs issue, but they have a long way to go before they are implemented. Other solution would be to combine one-time passwords with the secure remote password protocol and TLS authentication (RFC 5054). Unfortunately browsers (like Firefox) nor web servers (like apache) support TLS-SRP at this moment.

There is another solution that is available today. Instead of just using SSL server side certificates, also use SSL certificates on the client side. This means that both Alice and Bob authenticate themselves using a certificate. If Bob signs the certificates for his users himself, there is no way for Mallory to get a valid client certificate unless she hacks Bob server. But then the point of generating fake certificates is moot: whatever information Mallory is after can be read directly from the server anyway.

There is one more threat we need to protect against. Even though a certificate in itself does not possess one-time properties, because the associated private key is not transmitted it is secure against a man-in-the-middle attack. If the private key is stored in software on the client, it can be stolen if the PC is infected by a trojan or malware. This can be overcome by only storing the private key in a hardware token. This can be a smart card connected to the PC using a reader, or a PKI chip embedded in an USB stick. Of course when a client is infected with modern malware such as Zeus and SpyEye they can perform a man-in-the-browser attack. No authentication method can protect against this attack, but when the private key is stored in a hardware token, when this token is removed and the PC turned off the attacker will not be able to impersonate the users with stolen credentials. Credentials can always be stolen when a software-only solution is used.

In general strong authentication that is resistant against man-in-the-middle attacks and credential theft should:

1. use mutual authentication so that both the client and server are authenticated to the other side
2. use a hardware token which output is used in the encryption layer (like TLS)

The second property requires some explanation. There are several ways to do mutual authentication (using client certificates is just an example). A challenge response scheme that does a full challenge 1 / response 1 + challenge 2 / response 2 handshake will work, but only protects against a man-in-the-middle attack when Mallory cannot intercept both sides of the handshake. For an offline (non-USB) token TLS-SRP can be a solution when this is widely implemented.

Beyond the standard X.509 PKI solutions and tokens, I know of 2 proprietary protocols that implement mutual authentication using hardware tokens: G/On and MobiKEY.

Another solution worth mentioning is the ABN-Amro E.dentifier2 hardware token. This USB connected device contains a PKI client certificate. Crucial banking transaction are routed (using a webbrowser plugin) end-to-end from the server to the token. An LCD display shows the details of the transactions before they are signed by the device. This method seems to protect against man-in-the-browser attacks as well.

{
clientKeyPairTagPrefix = "com.ing.nl.iMB";
encryptedClientPrivateKey = <xxxxxxxx xxxxxxxx ... xxxxxxxx>;
profileId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx";
serverPublicEncryptionKeyTag = "com.ing.nl.server.encrypt";
serverPublicVerificationKeyTag = "com.ing.nl.server.verify";
stage = 2;
}

Dit bevestigt mijn vermoeden dat de applicatie public/private key cryptografie gebruikt. Wat wel opvalt is dat het configuratie bestand niet is beschermd of versleuteld. Als een iPhone proces root rechten heeft kan het dit bestand gewoon lezen en de gegevens kopiëren. Om root rechten te krijg op een iOS device moet het device jailbroken zijn, of een aanvaller moet gebruik maken van een exploit zoals bijvoorbeeld jailbreakme.com deed.

Als de encryptedClientPrivateKey of het profileId wordt veranderd gaat de authenticatie al meteen mis als de optie Rekeningen wordt gekozen. De eerste handshake loopt stuk, nog voordat de pincode ingevoerd hoeft te worden. Ik heb geprobeerd om het nl.ing.iphone.app.Bankieren.plist bestand van een iPhone 4S te kopiëren naar een iPhone 3GS. Daarmee gaat de eerste handshake goed. Maar na het invoeren van de correcte pincode geeft de applicatie aan dat de pincode onjuist is. Kennelijk wordt in deze stap niet alleen de pincode uitgewisseld, maar ook een uniek device id. Daarmee wordt het lastiger voor een aanvaller om misbruik te maken van de ING applicatie. Het volgende is nodig:

1. De inhoud van nl.ing.iphone.app.Bankieren.plist, via een jailbreak of root exploit
2. Het device id. Dit kan via een applicatie die vanuit de appstore moet worden geïnstalleerd, maar aangezien er al root access nodig is voor stap 1, is dat de meeste logische manier om aan het device id te komen.
3. De pincode. Dit kan bijvoorbeeld door de ING applicatie te vervangen door een phishing applicatie. Hiervoor moet de iPhone wel jailbroken zijn, anders kan de phishing applicatie niet worden uitgevoerd.
4. Een aangepaste ING Mobiel Bankieren applicatie die het gestolen device id gebruikt ipv het device id van de iPhone waar het op draait. Deze kan vanuit een emulator worden gedraaid, of zelfs op een niet-iOS device als het authenticatie protocol bij de aanvaller bekend is, en is nagemaakt.

Het advies is om ING Mobiel Bankieren niet te draaien op een jailbroken iPhone of iPad. Dit is namelijk de eerste stap die nodig is om misbruik te maken van deze applicatie. Op een niet-jailbroken iOS device die de laatste iOS versie draait is het voor een aanvaller heel lastig om de nl.ing.iphone.app.Bankieren.plist te stelen. Als er een methode bekend wordt om vanuit userland root te krijgen (zoals via jailbreakme.com) zal dit veel publiciteit krijgen, en zal Apple een nieuwe iOS versie uitbrengen die het lek verhelpt.

Bij verlies van de iPhone of iPad moet meteen ING op de hoogte worden gesteld. Een kwaadwillende zou eventueel via USB een jailbreak kunnen uitvoeren en zo de benodigde informatie kunnen achterhalen. Voorwaarde is dan wel dat hij de pincode al weet.

Deze beveiliging is vergelijkbaar met de Android app.

#!/bin/bash

while [ 1 ]; do
wget -q -T 10 -O out --load-cookies=cookie -U "`cat ua`" --post-file=postdata --no-check-certificate https://presale.events.ccc.de/order/confirm
if [ -s out ]; then
grep -q "Confirm Order" out || exit
fi
rm -f out
sleep 1
echo Retrying...
done


The script succeeded at 16:15.

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<int name="STAGE" value="3" />
<string name="RIGHT_PAD">xxxxxxxxxxxxxxxxxxxx</string>
<string name="PROFILE_ID">xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</string>
<string name="LEFT_PAD">xxxxxxxxxxxxxxxxxxxx</string>
<string name="PRIVATE_KEY">xxxxxxx...</string>
<string name="PUBLIC_KEY">xxxxxx...|010001</string>
</map>

Dit bevestigt mijn vermoeden dat de applicatie public/private key cryptografie gebruikt. Wat wel opvalt is dat het configuratie bestand niet is beschermd of versleuteld. Als een Android proces root rechten heeft kan het dit bestand gewoon lezen en de gegevens kopiëren.

In de iOS app wordt bij de pincode controle een uniek device id gebruikt. De source code van de Android app doet vermoeden dat dit ook hier het geval is.

1. De inhoud van IngMobilePrefs.xml, via sudo (op een geroot device) of root exploit
2. Het device id. Dit kan via een applicatie die vanuit de market moet worden geïnstalleerd, maar aangezien er al root access nodig is voor stap 1, is dat de meeste logische manier om aan het device id te komen.
3. De pincode. Dit kan bijvoorbeeld door de ING applicatie te vervangen door een phishing applicatie. Die kan bij Android op verschillende methoden worden geïnstalleerd.
4. Een aangepaste ING Mobiel Bankieren applicatie die het gestolen device id gebruikt ipv het device id van het Android device waar het op draait. Deze kan vanuit een emulator worden gedraaid, of zelfs op een niet-Android device als het authenticatie protocol bij de aanvaller bekend is, en is nagemaakt.

Het advies is om ING Mobiel Bankieren niet te draaien op een rooted Android device. Dit is namelijk de eerste stap die nodig is om misbruik te maken van deze applicatie. Op een niet-rooted Android device die de laatste Android versie draait is het voor een aanvaller heel lastig om de IngMobilePrefs.xml te stelen. Ook moet de Instellingen -> Toepassingen -> Onbekende bronnen zoveel mogelijk uit blijven staan om te voorkomen dat er niet-Market applicaties op het device worden geïnstalleerd.  Ook Instellingen -> Toepassingen -> Ontwikkeling -> USB-foutopsporing moet uit staan. Deze instelling is vaak een vereiste voor het rooten.

Bij verlies van de iPhone of iPad moet meteen ING op de hoogte worden gesteld. Een kwaadwillende zou eventueel via USB het device kunnen rooten en zo de benodigde informatie kunnen achterhalen. Voorwaarde is dan wel dat hij de pincode al weet.

Deze beveiliging is vergelijkbaar met de iPhone/iPad app.

Update 2011/11/18: informatie over deviceId toegevoegd

1. De app vraagt om het invullen van de gegevens van de bankpas. Hierna wordt een verbinding gemaakt naar URL https://services.ing.nl/mb/registration/registerProfile waarbij de volgende POST variabelen worden meegegeven:
   1. deviceType: iPhone 4S
   2. profileId: GUID die de app op dit device identificeert
   3. encSymmetricKey: 512 character hex string
   4. deviceBrand: Apple
   5. publicKey: 256 character hex string met daarachter 5 (controle?) bits
   6. osVersion: iOS version
   7. deviceTag: naam die de gebruiker aan het device heeft gegeven (Richard’s iPhone)

   De server antwoordt hierop met een JSON data structuur die oa een sessiesleutel en een signature bevat. Het doorgeven van een publicKey duidt op het genereren van een public/private key paar op het device. De private key blijft op het device staan, de public key slaat ING centraal op zodat in de toekomst het device hiermee kan worden geauthenticeerd.

2. De volgende POST is naar https://services.ing.nl/mb/registration/proveIdentity waarbij de variabelen debitCardExpirationMonth, debitCardCode, accountNumber en dateOfBirth meteen al versleuteld worden verstuurd. Er wordt dus niet vertrouwd op de SSL encryptie, maar men past binnen SSL een eigen encryptie toe op de waarden van de variabelen. De server stuurt een JSON antwoord met een versleutelde apiResponse.

   

3. De gebruiker moet vervolgens met een webbrowser inloggen op mijn.ing.nl en krijgt na het invoeren van een TAN code een controle getal te zien. Dit getal moet worden ingevoerd in de app op het mobiele device. De app vraagt dan https://services.ing.nl/mb/authentication/getVariables op, waarbij de profileId GUID wordt meegegeven. Het antwoord is een JSON structuur met oa srpSalt en serverSrpKey variabelen. Dit duidt op het gebruik van het Secure Remote Password protocol. Hiermee kan een geheime sleutel worden afgesproken zonder dat een eventuele afluisteraar deze te weten komt. Dit vindt dus plaats binnen het SSL protocol dat ook al (enigszins) tegen afluisteren is beveiligd. Het controle getal wordt vervolgens versleuteld verstuurd naar https://services.ing.nl/mb/authentication/checkActivationCode
4. De gebruiker moet in de app de voorwaarden accepteren. Er wordt een hash van de voorwaarden verstuurd naar https://services.ing.nl/mb/authentication/acceptTerms.
5. De gebruiker moet nu een 5-cijferige PIN code kiezen voor beveiliging van de app. Deze code wordt versleuteld verstuurd naar https://services.ing.nl/mb/authentication/registerPin. Vervolgens worden er een aantal sleutels opgevraagd via https://services.ing.nl/mb/authentication/getSymmetricKey en https://services.ing.nl/mb/authentication/getSessionKey.

   

6. Nu de registratie is geslaagd, wordt bij elk volgend gebruik van de app alleen de PIN code gevraagd. Nog voordat die wordt ingevoerd wordt /mb/authentication/getVariables al opgevraagd om het SRP protocol te starten. De PIN wordt daarna versleuteld verstuurd aan /mb/authentication/checkPin waarna weer /mb/authentication/getSymmetricKey en /mb/authentication/getSessionKey worden opgevraagd.

Het authenticatie protocol ziet er goed doordacht uit. Er wordt niet vertrouwd op SSL of TLS. In plaats daarvan gebruikt ING een extra encryptielaag waarvoor het wachtwoord wordt afgesproken via het SRP protocol. Ook genereert elk mobiel device een eigen profileId en een public/private sleutelpaar.

Toch had ik had graag gezien dat de app de uitgever van het SSL certificaat van services.ing.nl had gecontroleerd. Dan was het voor mij (en een eventuele aanvaller) veel moeilijker geweest het protocol te achterhalen. Google Chrome doet dit bijvoorbeeld voor mail.google.com waardoor de man-in-the-middle aanval in Iran en de Diginotar hack werd ontdekt.

Als de registratie eenmaal is gedaan lijkt me dit protocol vrij robuust, ervan uitgaande dat de encryptie sterk is en goed is geïmplementeerd. De grootste kwetsbaarheid zit hem in het registratieproces. Als er tijdens dit proces iemand tussen het mobiele device en de services.ing.nl server in zit (man-in-the-middle), dan is het theoretisch mogelijk om het registratieproces te kapen, en namens de gebruiker de registratie te voltooien. Een aanvaller moet dan wel het hele registratieprotocol inclusief encryptie reverse engineeren en live na weten te bootsen. Ook is een vals SSL certificaat voor services.ing.nl nodig. Deze factoren maken het niet gemakkelijk of zelfs waarschijnlijk dat iemand een man-in-the-middle aanval op een gemiddelde ING klant weet uit te voeren tijdens het registratieproces.

Before you think these are l33t hacks that will be fixed soon, read those blog entries. It is all by design. Apparently one challenge Microsoft faced when designing AppLocker was the installation of new software. The default AppLocker rules allow users to run Windows installer files. (I don’t quite get what the point of using a whitelist is when users are still allowed to install new programs.) This poses an potential deadlock. Installer (msi) files often contain executables and DLLs that are placed in a temporary location and then executed during the installation process. Adding the %TEMP% directory to the AppLocker whitelist would be insecure. So Microsoft designed 2 special API flags for this case: LOAD_IGNORE_CODE_AUTHZ_LEVEL for LoadLibraryEx() to load DLLs and SANDBOX_INERT for CreateRestrictedToken() to load executables. With these flags set, AppLocker will not block the DLLs and executables, ever.

The problem with this design is that not only windows installer files can set these flags. Every single process with access to the Windows API can. This includes whitelisted applications, shellcode injected into a running process by an exploit, or (whitelisted) scripting languages. While allowing Perl or Python on a locked down Windows system is probably not a good idea, Visual Basic for Applications is something most power users can’t do without. This means that from within Microsoft Office applications like Word and Excel, the AppLocker restrictions are easily bypassed.

I have written a proof of concept macro that allows you to select the full path to an executable which will be executed bypassing all AppLocker restrictions. The macro is just a translation to VB of the C code written by Didier Stevens, so all the credit goes to him. This was my first ever Visual Basic script which shows how easy it is to write this bypass with all the needed information already out in the open.

To test this code:

1. In an MS Word document, type in the path to an executable that is not allowed by SRP/AppLocker. For example: C:\test.exe
2. Select the text you just typed, in this example select “C:\test.exe” without the newline
3. Press Alt+F11 (brings up VBA editor)
4. Right mouse button on “Normal” -> Insert -> Module
5. Paste the content of runexe.txt into the new module
6. Place the cursor inside the Sub RunExe()
7. Press F5 (runs macro)

I have submitted the code to Microsoft, asking them to fix this by adding a control mechanism for using the LOAD_IGNORE_CODE_AUTHZ_LEVEL and SANDBOX_INERT flags. A new registry key (disabling the use completely) or linking them to a specific AppLocker rule (only allowing the use when a certain AppLocker rule is matched) would do nicely.

Update: hotfix KB2532445 fixes this issue (MS internal fix was KB370118). Is was released on November 9th, 2011.

Note that this pop-up is very informative. It says that granting this privilege is a high risk (in bold). The applet could read, modify or even delete any of your files. Similar texts were shown for network access, etc. This is how I remember the Java applet sandbox security model. Applets can’t do much harm, if they would want to you will be shown a pop-up which will tell you what the risks are. Neat, clean, safe.

In 1998 Sun decided that this security model was too complex. With the release of JDK 1.2 (now renamed Java 2 Platform, Standard Edition or J2SE) the security model became more fine grained with the use of a security policy. This policy can be set to allow or disallow certain URLs, signers, etc specific privileges. This sounds great, but the default security policy that is shipped with Java/JDK/JRE ever since basically is a big on/off switch. If an applet needs additional privileges outside the sandbox, a single uniform pop-up is shown. No mention of high risk, or which privileges can be used by the applet. If the applet is signed by a Certificate Authority that your browser or OS trusts, it looks something like this:

if it was signed with a Certificate Authority that is not trusted it looks something like this:

In general I think end users always will make bad security decisions when it comes to browsing the web. However, the old style pop-ups would probably stop a lot more users from running suspicious applets. Think about it. Being able to operate outside of the Java sandbox gives applets full control over your computer. It can drop a malicious dll or exe on your hard drive, it can modify your registry to run it every time you log in, etc. And all you get as a warning is a lousy pop-up like the one above. Even ActiveX does that better these days. Of course I’m not the first to notice this. Many people have before. In 2002 a Mozilla bug report was opened requesting to change the misleading wording in the security warning, but no one has picked this up.

I think it is clear that the default Java security policy does not suffice today. End users cannot be expected to make the right decisions when pop-ups are shown. They certainly cannot be expected to write and maintain their own Java security policy. For home users, deinstalling Java is the best option right now. The chance you really need it to enjoy the web is quite low. If you do, at least take the precautions mentioned here. For corporate users, this problem is entirely different. Many organizations rely on software that use signed Java applets such as Oracle Forms. It is scary to think how many corporate desktops have Java installed and enabled in their browsers. Go ahead, try this signed applet example. Do you get a pop-up? Are you given a choice to run the applet? If so, your corporation is suspect to intruders, spamming your users with links to sites that show such a pop-up and use the Java applet to install malware. The Koobface worm is just one such example.

Fortunately there is something you can do about this: write your own java security policy. I’ll give a very short tutorial below, but I recommend reading the official Oracle documentation and this excellent site.

In the default java.home/lib/security/java.security file two Java policies are loaded:

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

You might want to remove the policy.url.2 to avoid users from changing your corporate Java policy. The default java.home/lib/security/java.policy is set up to restrict applets within the sandbox and ask the user what to do with signed applets. First, we need to turn off those pop-ups. You can do this by editing the java.home/lib/security/java.policy file or adding an additional one using policy.url.2 or policy.url.3 in the java.home/lib/security/java.security file. I recommend using a new file and placing it on a central file server. Add these lines:

grant {
permission java.lang.RuntimePermission “usePolicy”;
};

This tells the JVM to ignore the RSA signatures on all applets, and always and only use the Java policy defined by the policy URLs. Next, add any URLs with trusted applets that require access outside of the JVM sandbox. This acts like a whitelist:

grant codeBase “http://my.internal.site.local/-” {
java.security.AllPermission;
};

grant codeBase “http://another.site.local/-” {
java.security.AllPermission;
};

In the above the dash – is a recursive wildcard. Of course you can be much more granular instead of using java.security.AllPermission. The AllPermission property gives the same privileges a signed applet would get when the “Run” button was clicked on the pop-up.

Effectively you have now removed the choice of breaking out of the Java sandbox from the end user and defined it in a corporate java policy instead. This really is needed in any corporate environment with a JVM installed on the desktop. The default Java security policy is just a major security incident waiting to happen. In fact, abusing java applets is a well known technique in penetration testing. If the whitehats are catching on, you can count on the blackhats doing far worse.

I’ll ignore the legal issues with this solution (privacy/is knowing where your stolen laptop is considered acceptable proof by the police?) and skip to the interesting bit. I can imagine that experienced laptop thieves wipe or swap the hard drive before selling it. Computrace solves this by embedding software in the BIOS. When enabled, at every system boot the BIOS checks if the software is still installed on the hard drive. If not, it drops rpcnetp.exe in C:\windows\system32 and makes sure Windows runs it. This program then downloads and activates the full rpcnet.exe software.They call this feature persistence and according to their website it is embedded in the BIOS of the almost all mainstream Windows laptops available today. At this point in the presentation I looked at the colleague next to me and we both said at the same time: rootkit!

Later some googling showed that we were not alone in this. In 2009 Anibal Sacco and Alfredo Ortega presented their research on this product at Black Hat Vegas (which I attended, but missed this interesting talk) and discovered that a malicious rootkit could leverage Computrace to become very persistent.

Another thing that struck me during the presentation is that if this type of anti-theft software would become widely used, laptop fencers would find a way to disable the Computrace BIOS feature. Absolute Software claims all this is not possible, but they have already been proven wrong.

So be aware of the rootkit that is probably already inside your laptop’s BIOS, just waiting to be activated.

Thanks to Wikipedia for all of the above info. Please donate today.