Home > Information Security > Beware the Transparent Proxy…Your Faith In VPNs Might Waiver

Beware the Transparent Proxy…Your Faith In VPNs Might Waiver

November 20th, 2008 Leave a comment Go to comments

Aviram from the Securiteam blog wrote a post titled "Who's Your SMTP Daddy?" that caught my eye regarding the false sense of security that use of corporate IPSec VPNs brings to traveling road warriors due to the use by providers of so-called transparent proxies.

Let's say that you've got some sort of IPSec VPN solution installed on your laptop using the standard corporate configuration with your mail client pointing to mail.foo.com.  Your machine has AV, HIPS, firewall, etc.

You connect to a provider's network (wired, wifi, hotel, airport, etc…) and fire up your VPN client which authenticates just fine.  You then launch your mail client and type a quick note to your CEO about the confidential M&A project you're working on.  A few minutes later you get a response from your CEO to proceed with the tender.

You disconnect.

Here's the problem: that SMTP session you thought was encrypted through your VPN back to the corporate mail server was actually sent in the clear.  In fact, it wasn't even sent through your mail relay/server.

Here's a great example of why taken from Aviram's blog:

A quick investigation shows the following: The hotel’s network blocks
my VPN (as some of them do) but happily resolves any unresolvable host
name (such as my SMTP server’s hostname). This is resolved to a
catch-all server that proxies everything. Transparently. (well, almost)

Lesson learned. Changed the hostname to the IP, and will soon switch
to SSL based SMTP who will authenticate the server. In the meanwhile –
be careful from helpful Beijing wifi providers who are only too happy
to forward your mail on! (with some changes, of course).

Aviram is in China, but this example is valid in many countries and you can probably expect that given the behavior of some domestic ISP's, Telcos and Mobile Operators that it is or will go on here too.  It could easily work with other protocols that aren't sensitive to session tampering/MITM.*  Further, Aviram's example was about interception.  There's every reason to believe that one could expect the content of your email to be modified also…

I personally use SSL authenticated SMTP with valid issued certificates so at least if there is tampering with my session, my mail client barfs letting me know something is wrong.  That error probably wouldn't help the average sales droid in the field as he/she would just click OK like most people do to any security error that pops up, but it's worth considering.


* Obviously this example presents a worst case scenario with certain configuration assumptions and license taken for illustration, but take the message for what it's intended: blind faith in VPNs can cause you some serious heartache.  Transparent proxies work very well…

Categories: Information Security Tags:
  1. November 20th, 2008 at 03:38 | #1

    Interesting point, and certainly any time you're out in public – in country or abroad – you have to assume that any public network you're connected to is untrusted. Transparent hijacking can be carried out on any Wi-Fi network using simple ARP poisoning, so it's not just ISP's you have to watch out for, it's other client systems, too.
    That said, most of the client VPN solutions out there today support some variation on "full tunnel" connections. This means that once the IPSec or SSL VPN tunnel is established, all traffic from the laptop is shoveled over it, including DNS. The all-or-nothing VPN mode prevents the local network from successfully carrying out MITM attacks, at least while the VPN client is connected, and also protects the office network from leap-frog attacks through the client machine.

  2. Mike Fratto
    November 20th, 2008 at 05:11 | #2

    Yeah, the right way to support road warriors accessing internal services is to put them behind a firewall and only allow connections internally, including the VPN. So if the VPN fails, and VPN software WILL tell users about failed connections, the name can resolve to anything you want, but you can't actually do anything. You can also enforce authentication or mail over TLS. Lots of options.

  3. November 20th, 2008 at 05:53 | #3

    When I'm feeling particularly paranoid on OS X (or OpenBSD) I not only tunnel, but I set up ipfw rules. They basically go like this:
    Allow all to localhost
    Allow any established connection
    Allow the VPN or SSH port to my VPN/SSH concentrator's public IP
    Deny all
    Then, if my VPN or SSH fails, nothing leaves my laptop and nothing gets in, either. This is what I did at DefCon, for example. I also do this whenever I do business work from any public place (wired or wireless)

  4. November 20th, 2008 at 17:03 | #4

    That's why I use Outlook with Exchange and RPC over HTTPS. I don't have to worry about VPN, my connection will automatically use SSL and fail to connect if it can't.

  5. windexh8er
    December 6th, 2008 at 07:43 | #5

    Well, whoever setup that IPsec connection was completely, and utterly brain dead I guess. As people have already (indirectly) mentioned if you're doing any sort of split tunnel with a corporate connection you should be fired from your security position to begin with — let alone even allowing clear text SMTP (WhoTF uses non SSL protected SMTP anymore anyway – what is this 1995???) out any interface from the laptop when you're not actually on the corporate LAN. There's lots of ways to avoid this easily — it just takes about 10 minutes of actual thought process.

  6. December 6th, 2008 at 11:28 | #6

    @windexh8er: I think you missed the premise.
    Regardless of whether split-tunneling was on or off, the mail client was configured to access a non-resolvable (from the Internet) DNS name for the mail server as if it were inside the corporate network.
    If you're inside the network (normally,) most companies don't want to impose additional load on the mail server or have to stand up an internal proxy by enabling SSL…they usually don't see the need/threat.
    Thus, if you're outside, the only "normal" way you'd be able to resolve and internal DNS name is if your VPN was up and you could resolve against an internal DNS server, which is what the security/administrators obviously expected in this case.
    In the case cited above, the VPN was blocked by the provider and the proxy simply spoofed the hostname to redirect SMTP to their $evil mail server. This had nothing to do with split tunneling, because quite frankly, even if split-tunneling were disabled, this still would have worked.
    It's a case that most security folks probably wouldn't even think of.
    The "encrypt everything, everywhere" is often unrealistic, no matter how good of an idea it may be.
    Case in point, there's an obvious trade-off here with denying split tunneling and still allowing Internet access, which if you're using services that are Internet based (such as Salesforce.com, for example) where you need simultaneous access to both Internet and Intranet resources.
    That trade-off is the scalability of whatever proxy you're using internally to forward Internet-destined traffic through as well as the size of the pipe(s) connected to the corporate network through which now all traffic has to pass (after going through the proxy.)
    If you're a small SMB, this is probably still a non-issue.
    If you're a global company with lots of roaming staff, the notion of SLA's and business pressures along with the the costs and support infrastructure that disabling split tunneling brings means that it's not quite as simple…
    Now, I'm not arguing that what you're proposing isn't a good idea, I'm simply suggesting that the ol' "you should be fired for not being a good security professional argument" simply ignores the realities of the fact that you're squeezing the balloon; the problem simply shifts.
    It's only going to get worse with all this cloud zaniness — your Intranet is likely to either be exposed to or may very well be based on the Internet…
    Another good reason to think about thinner client alternatives…
    As to the cleartext SMTP issue, the answer is probably in the high double digits…

  7. vmiroslav
    February 22nd, 2009 at 05:59 | #7

    I use a vpn to secure connectivity – this eliminates the need to expose internal systems to the whole wide world. Related to topic- proxy

  8. February 22nd, 2009 at 08:20 | #8

    owever, the Strong vpn server in New York that I use appears never to vary from a speed of between 4000 kb/s and 5000 kb/s. And with that kind of bandwidth, it's possible to watch not just streaming video, but to watch the hi-resolution version that many sites offer. StrongVPN seems almost too good to be true, and I think it will take me some time to lose my fear that the amazingly good bandwidth I've been getting might be just a fluke somehow. I'm sure it is not a fluke, though. I think StrongVPN's service will continue to be just as incredibly fast and dependable as it's been so far. To sum up: after the experience of having to cope with what a number of really shoddy companies offer elsewhere

  9. amir
    February 27th, 2009 at 04:35 | #9

    If you love blogging then I am sure you heard about http://vpnomania.com/proxy-surf.html . There are many companies offering you some protection service for your data in the online world. Make sure that you choose the trustable company for it so you can safe your data

  1. No trackbacks yet.