Louwrentius

Many people asume that if you regularly update your computer, you are safe from hackers. But nothing could be further from the truth. Keeping your systems up-to-date only protects you against exploits for publicly known vulnerabilities.

Your systems are still not protected against privately known vulnerabilities and if hackers have zero-day exploits for such vulnerabilities, you are clearly having a false sense of security.

There couldn't be a better example than a high-risk vulnerability MS12-020 regarding the Microsoft Remote Desktop Protocol interface, as present on TCP-port 3389. Any unpatched Microsoft Windows-based server or desktop system can be compromised through this vulnerability. If the system is vulnerable and TCP-port 3389 is accessible, it is over. Your data is compromised.

Now, how many people knew about this vulnerability and for how long?

As we speak, someone may be reading these very words on your computer, just remotely, because of an undisclosed, unknown vulnerability. That sounds like paranoia, but it isn't.

Zero-day exploit market

There is a whole zero-day exploit market. Exploits are sold at enormous prices, as high as $100.000+ dollars. Only those who have the means (money) and a need for them will pay such prices. Buyers often tend to be government agencies and such.

There is no doubt in my mind that the computer I'm currently working on is affected by high-risk vulnerabilities I don't know of. It is very likely that for some of them, exploits exist. But look at the risk: who is going to spend a $100.000 exploit on me? But is the intelectual property of your company worth that much? Might sound way more realistic already, doesn't it?

You may hope that zero-day exploits are sold to trustworthy governments, but the marked is free. Anyone with sufficient means can buy them. Some sellers may scrutinize to whom they sell, but others?

This whole zero-day exploit market is a problem. Exploit-sellers have nothing to gain and only to loose from public disclosure of the vulnerability. As long it is undiscovered, it can be used by buyers. All parties involved in this market benefit from keeping systems insecure. From keeping systems unpatched.

So instead of informing the vendor of a security vulnerability so the public can be protected, knowledge of the vulnerability is sold to the highest bidder who then does who knows what with it.

For most organisations and people, the upside is that nobody will spend a $100.000 on you if you're not worth it. The reason is that every time an exploit is used, it can be discovered, rendering the exploit useless once a security patch is released.

Protecting against zero-day exploits

The question is then what to do against this kind of threat. What can you do to protect yourself against the risk of zero-day exploits if you perceive the risk as realistic towards your organisation.

The answer is a security strategy of defense in depth. It is not a solution that ends all problems, but it decreases the risk that your organisation gets compromised. It is about trying to diminishing risk to acceptable levels.

Assume that you will get compromised. Then, think about what can be done to reduce the impact of the hack. Will only one server get hacked, or the entire internal company network?

Defense in depth is the principle that you do not rely on one single security measure to protect systems and services from a compromise. There are many ways to implement such a strategy and I will name a few.

1. Only expose those services towards the internet that are required for production.
2. Make sure you have proper network segmentation in place, systems should not provide a stepping stone for an attacker to enter your internal company network.
3. Never expose management interfaces such as RDP towards the internet directly, use an additional security layer (white list IP address or use VPN).
4. Establish an emergency patch-policy to make sure that all systems are patched outside regular maintenance windows if high-risk vulnerabilities are reported.
5. Monitor the heck out of your environment. Carefully try to log and alert to those events that may indicate a security breach.
6. Audit your systems, regularly check for misconfigurations and resolve them.
7. Select hardware and software vendors based on their security track record.
8. Use different vendors and brands for different defensive layers.
9. Consider internet off-limits for end-user systems processing sensitive information

Software is vulnerable so prepare for the worst.

This blogpost discusses how to setup an IPSec-based VPN between your iPhone and a Linux server.

Updated 16 October 2012 - now compatible with Ubuntu 12.04 LTS

IMPORTANT! (update January 2013)

I find using OpenVPN with the new iOS OpenVPN client a way better solution. OpenVPN actually restores VPN connectivity when returning from sleep.

Why using a VPN with your iPhone?

1. Security: all data is encrypted and cannot be read by malicious people trying to eavesdrop on your data.
2. Performance: my subjective experience is that a VPN can speed up web browsing, it seems to reduce latency.

Introduction

I am assuming that you use:

• an iPhone as the VPN client
• a Debian-based Linux distro, such as Debian or Ubuntu (used here)

We will use the following software:

• openswan
• xl2tpd
• pppd

To setup the VPN, we need to configure the following steps:

1. install the software
2. configure IPSec
3. configure L2TP
4. configure PPP
5. open up the appropriate firewall Ports
6. setup firewall rules to forward traffic between the iPhone and Internet
7. configuring the iPhone

This set of instructions is 90% based on instructions on peen.net made by Niels Peen (Groeten!). I borrowed some other stuff from this blog.

I use openswan for IPSec support because strongswan does not support NAT by default. I just want to use software as part of the operating system and don't like to have to maintain manually compiled versions. This is why.

Initial assumptions

• You are using a Linux host as the VPN server
• The server is accessible from the internet or the appropriate UDP ports are forwarded to the box.
• You have full control over the box and it's firewall configuration.
• Your iPhone has an unfiltered internet connection. If UDP is blocked, this type of VPN is not for you.

Install the software

First, we start with installing all required software:

apt-get install openswan xl2tpd ppp

Configure IPSec

Now we start with configuring the software. First we start with IPSec:

/etc/ipsec.conf

config setup
    nat_traversal=yes
    protostack=netkey
    plutostderrlog=/tmp/log.txt (for debugging)

conn L2TP-PSK
    authby=secret
    pfs=no
    rekey=no
    type=tunnel
    esp=aes128-sha1
    ike=aes128-sha-modp1024
    ikelifetime=8h
    keylife=1h
    left=<INTERNET IP ADDRESS OF ROUTER / SERVER>
    leftnexthop=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    rightsubnetwithin=0.0.0.0/0
    auto=add
    dpddelay=30
    dpdtimeout=120
    dpdaction=clear

Some notes about this configuration:

• We use a secret or password for authentication. Sources on the internet seem to suggest that the iPhone cannot handle certificates.
• we must configure the dead peer detection rules at the bottom or else you cannot reconnect to the VPN when returning from sleep.

We thus also need to configure an encryption secret (password) for the IPSec tunnel.

/etc/ipsec.secrets

%any %any: PSK "thisismysupersecretpassword"

It is smart to choose a strong (long) password.

Configure L2TP

Inside the directory /etc/xl2tpd you have to edit xl2tpd.conf like this:

[global]
auth file = /etc/l2tpd/l2tp-secrets
debug network = yes
debug tunnel = yes

[lns default]

ip range = 10.0.1.201-10.0.1.240
local ip = 10.0.1.200
require chap = yes
refuse pap = yes
require authentication = yes
name = <ENTER SOME NAME HERE>
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

The "ip range" is within your internal network. It is a range outside of your DHCP-scope. The "ip range" must not include the "local ip". This IP address is dedicated to your Linux host.

Important: once the VPN setup is working properly Turn off all debugging options (set them to 'no'). Otherwise, your logs will fill up very quickly because every time a packet is transmitted, this is logged.

Configure PPP

Now we must configure PPP. Edit /etc/ppp/options.xl2tpd and make it look like this:

ipcp-accept-local
ipcp-accept-remote
ms-dns <ADDRESS OF LOCAL OR REMOTE DNS SERVER>
noccp
auth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute 
debug
lock
proxyarp
connect-delay 5000

Note that you must enter a valid DNS server that must be reachable by the VPN client (iPhone) through the tunnel.

We are almost there. Now we must also configure a password for the PPP connection. Edit /etc/ppp/chap-secrets and make it look like this:

* * thisissomesecretpassword *

This password is not related to the IPSec password. I think it is wise to configure different passwords for IPSec and PPP.

Configuring the firewall

An IPSec + L2TP + PPP VPN requires the following ports to be opened:

• 500/udp
• 4500/udp
• 1701/udp

You must open these ports in your firewall yourself.

Configuring traffic forwarding rules

If you use a Linux box with IPtables, you may already have a functioning configuration. However, this line is required for traffic forwarding to work:

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

You must replace the correct IP addresses according to your configuration. You may also have to enable traffic forwarding like this:

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

A detailed firewall configuration guide is outside the scope of this tutorial.

If you use IPtables for your local firewall, you may be interested in my "Linux Firewall script" (shameless plug alert).

Configuring the iPhone

To configure a VPN profile, goto settings -> general -> network -> vpn (at the bottom). Choose 'Add VPN Configuration..."

1. Enter a description
2. Enter the IP address or DNS name of your Linux box.
3. The 'account' field can be anything you like.
4. Leave RSA SecurID off.
5. The Password is the PPP password configured in /etc/ppp/chap-secrets
6. The IPSec secret (/etc/ipsec.secrets) goes into the 'Secret' field.
7. Keep 'Send All Traffic' enabled.

If the connection succeeds, a VPN symbol will show up in the iPhone status bar. All traffic from then on will flow through the VPN.

It may not immediately work. Look in /var/log/auth.log and /var/log/daemon.log for debug messages.

Once it is working properly, disable all debug settings in xl2tpd.conf and restart the daemon.

Final remarks

You may have to tweak the 'dead peer detection' within the IPSec configuration. When the iPhone comes out of sleep, the VPN connection cannot be reinitiated right away, which is inconvenient.

Also, I'm not sure what the impact is on battery life.

Many organisations just assume that the local physical network is trusted. That their network equipment is physically secure and that it is impossible for an attacker to get on the wire and start eavesdropping on network traffic.

Many organisations do not seem too concerned about a very old vulnerability regarding Ethernet-based networks called ARP-poisoning. Basically ARP-poisoning means that an attacker-controlled system steals the identity of another legitimate server, thus drawing all network traffic away from the legitimate server to the attacker-controlled system. Then, the attacker can do with that traffic as he or she sees fit. The attacker will be performing a man-in-the-middle attack. Please note that such an attack is trivial using tools as Cain and Abel or Dsniff.

It is often the case that many different server systems are placed in a single network segment or VLAN. That implies that any of these systems poses a threat to each other. It takes just one hacked system to compromise network traffic between all the other systems. This is especially a threat to all unencrypted network traffic, but encrypted sessions may also be attacked if clients don't check the sever's identity.

Unless you've actually implemented proper network segmentation using separate (V)LANS and filter traffic between these network segments through firewalling, your environment may be at risk. In that case, please understand that it takes just one single web application containing just one vulnerability to compromise the entire environment.

Not everybody has implemented proper network segmentation and firewalling, preventing these kind of attacks. And it takes quite some labour to change all that. So what can you do, assuming that you want to do something right now?

In general, in a shared network environment, as described, the only way to make sure that data in transit is kept confidential and unmodified is to make proper use of encryption, identification and authentication.

The solution

To secure web traffic, there is already a fairly easy solution: using HTTPS or HTTP over SSL. The most difficult part is getting a valid SSL certificate and configuring the HTTP server to use it.

But if you want to transfer files between servers or between clients and servers? How about that?

Is there actually an easy way to securely transfer files between two hosts? From what I can see, the answer is "no". Security comes with some additional effort and it isn't easy.

The first problem is to understand what 'secure' actually means. To me, it means that data is not stolen or modified by an attacker during transit.

There are three requirements to make sure that confidentiality and integrity is guaranteed:

1. data in transit is encrypted;
2. the client authenticates the server;
3. the server authenticates the client.

Encryption prevents a man-in-the-middle attacker from eavesdropping or altering data. And if the client verifies the identity of the server, the attacker cannot impose the real, genuine server. This part may be overlooked. "I'm using SSL, thus encryption, so I am safe, right?". That is a firm negative. The client is identified with a password, passphrase or client-side SSL certificate. But how does the client identify the server? If the client doesn't verify the identity of the server, you might as well turn encryption off.

For the Windows platform, there is no native solution. Most of the time, files are transfered using SMB and thus your files can be grabbed from the wire and you may be transferring your files to some impostor instead of the genuine host.

The other often-used solution is FTP. And everyone knows that the biggest problem with FTP is the lack data encryption. All communication, including credentials for authentication, are transmitted in plain-text.

Without any additional third-party software, it is impossible to securely transfer files between Windows hosts, except for one solution that I have never seen used: IPsec. IPsec is used to encrypt any network traffic between two host, thus also SMB traffic.

The Unix world has only one solution without using third-party tools and that is transferring files using SSH as a secure transport. But SSH is also used for secure shell access to hosts and it may be difficult to prevent shell access and still allow file transfers.

So now there is a new tendency to use FTP over SSL. You have the same inconvenience as with HTTPS: you need to install a valid SSL certificate on each FTPS server. And although this does improve security, encryption is still useless if the client side system does not properly validate the server's identity.

Furthermore FTP uses a control channel for commands and a separate data channel to transfer the actual data. You want both channels to be encrypted, but that may not be the default. Check your FTP server's configuration to make sure this is the case.

Implementations

To implement FTP over SSL on Windows, you might want to take a look at the Filezilla server. An FTP server that also supports FTP over SSL. It had some security vulnerabilities in the past but not too many. To me, it is a better solution than to expose TCP-port 445 to other systems. The SMB service doesn't have a good security track-record.

For Unix environments, take a look at VSFTPD. The Very Secure FTP daemon, is written by Cris Evans, who works on the security team for Google. The irony is that although VSFTPD itself doesn't seem to be affected by any security vulnerability itself, the hosting provider hosting the software was compromised by an the attacker. This attacker put a back-door in a specific VSFTPD release.

Anyway, I still recommend VSFTPD as it is very well-document and the configuration is simple.

If one of these solutions is not an option for your particular situation, you might think about using your existing insecure file transfer method on top of a VPN connection that handels authentication and encryption, such as OpenVPN. But setting up OpenVPN within such an environment may also be cumbersome.

Recent events regarding compromised certificate authorities show that the trust model SSL-authentication often leans upon may be broken. You must be sure which certificate authorities to trust. If you have your own certificate authority, make sure you take every precaution to keep it secured.

Question: should the client rely on build in CA certificates, the sames as present in your browser? Or are you going to configure the client to accept only the single certificate of the server?

If you have any other suggestions for a simple solution to securely transfer files between hosts, feel free to leave a comment.