Security Information Vulnerability Research Security Blog

Who’s your SMTP daddy?

November 20th, 2008 by , Filed under: Corporate Security, Networking, Privacy

In a hotel in Beijing, using their wifi in the lobby. Everything goes fine until Noam tells me my email headers are weird.

Return-Path: aviram@hsia.com.cn
[...]
Received: (qmail 9613 invoked from network); 19 Nov 2008 13:26:43 -0000
Received: from mail.hsia.com.cn (HELO hsia.com.cn) (61.152.154.60)
by 0 with SMTP; 19 Nov 2008 13:26:43 -0000
Received: from FBH.hsia.com.cn ([123.124.225.63])
by hsia.com.cn (8.13.1/8.13.1) with ESMTP id mAJDTJlY005475;
Wed, 19 Nov 2008 21:29:20 +0800
Received: from beat.local (unknown [172.31.8.65])
by FBH.hsia.com.cn (Postfix) with ESMTP id 8AFEB520B0;
Wed, 19 Nov 2008 21:13:54 +0800 (CST)

Clearly I’m sending through another SMTP server, who goes as far as mangling my ‘Return-Path’ address header.

Only I’m not. My SMTP server is set (as always) to the corporate SMTP who is accessible through the VPN, in an encrypted connection that should not allow anyone to change fields. Just in case, I check it again. Yup, the SMTP server is there. So what’s up?
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).

Share
  • http://blog.invisibledenizen.org natron

    Wouldn’t you have noticed that VPN was not functioning? Regardless of transparent proxies, etc, you can’t ever assume that using an unencrypted protocol over an unencrypted link is going to offer you any security against data theft or manipulation.

    There’s always a vivid reminder of this at every defcon, in the shape of a large, abused sheep projected on the wall.

  • http://www.BeyondSecurity.com Aviram

    @natron my VPN runs in the background and usually ‘just works’. Even if I did have an indication, a smart attacker can temporarily block the vpn and run the attack and then restore the VPN again. A 10% packet loss is not something most people will even notice, and it allows the attacker to capture 10% of the traffic without being caught.

    The VPN is of course encrypted, that’s the main purpose of the VPN. The problem is not a man in the middle attack: it’s simply that when resolving my mail server this DNS gives me an IP of another server which does the proxying.

  • md

    plus, if you had a full tunnel VPN as opposed to a split tunnel, and you used a hostname for your mail server that was only resolvable internally, you’d have averted your situation all together.

  • Just Guess

    Hostname wouldn’t have resolved anything md, I believe they can still use DNS wildcards to catch any request for resolving you send.

    If you do static hostname, using /etc/hosts they can still do a ‘wildcard’ transparent connection redirecting (similar to HTTP transparent proxy).

  • Jason

    If split tunneling were disabled, would this have prevented your problem?

    I’m guessing split tunneling was already disabled, but since the VPN was completely nonfunctional, your system fell back to your open connection.

    Can you configure your VPN client to stick an icon on the system tray with RED = BAD, GREEN = GOOD or something similar?

    That would provide a quick visual queue and prevent situations like the crazy one you had.

  • http://www.BeyondSecurity.com Aviram

    @Jason – actually I do have split tunneling enabled. Disabling it would have made me notice the VPN isn’t functioning but also considerably slow down the connection speed especially when abroad.

    You are right that the basic problem is letting the user know the VPN is down; but a clever attacker could have filtered the vpn traffic to block it momentarily once in a while but allow some of it through. This would make the VPN client think the connection is up, but if the timing the attack outlined here may still work.

  • http://www.astorandblack.com Suits

    The issue with SSL is that it can also be decrypted and sniffed. What i would do is use a Tor to scramble the traffic leaving my computer. Also don’t connect unless you have your VPN intact.

  • les

    the best price and protection I have found it vpn.
    and therefore I think it is worthy to use it.

  • Share







  • Categories


Security RSS Subscribe