Man-In-The-Middle experience in Warsaw 
Thursday, June 16, 2011, 03:17 PM
This is a report about a Man-In-The-Middle (MITM) situation that I experienced a couple of days ago while travelling.

I spent the night in a hotel in Warsaw, Poland. I bought access to the Internet WiFi. When my Thunderbird email client started, it automatically checked my various email accounts.

For the SSL connection to imap.googlemail.com (also known as imap.gmail.com) at port 993, Thunderbird warned me about a certificate error. The certificate presented by IP address 74.125.115.16 was issued to

Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=imap.googlemail.com

and it was issued by

Issuer: C=US, ST=California, L=Sunnyvale, O=Fortinet, OU=Certificate Authority, CN=FortiGate CA/emailAddress=support@fortinet.com


Given that Google's computers usually use certificates from Certificate Authorities that are trusted by Thunderbird, and given that this particular is not, this appeared to be a MITM attack.

The next question was, who is it that sends this unknown certificate to me? Is it sent by Google's IP address 74.125.115.16, or is it sent to me by another computer that is physically present on the route between me and Google?

I started an analysis. I made remote connections to other computers, including my server located in Germany. I repeated the connection attempt from my server to the same IP 74.125.115.16. For this connection, things looked good, I received a valid certificate from a CA trusted by Thunderbird. A friend of mine, who lives in Warsaw, repeated the test using his home Internet connection. Again, things looked good.

The conclusion is, someone along the route between me (sitting in the hotel) and the imap.google.com server, was using a MITM software or hardware to hijack my connection.

Luckily I noticed it, thanks to the automatic checks used by Mozilla Thunderbird.

So, who is it that performed the attack on me? That's not easy to tell.

Without blaming anyone, I'm naming the involved parties:
- I was in the Metropol Hotel Warsaw
- the Internet provider appears to be atman.pl
- anyone else in control of one of IP addresses on the route between the hotel and Google:


$ traceroute 74.125.115.16
traceroute to 74.125.115.16 (74.125.115.16), 30 hops max, 60 byte packets
 1  192.168.69.254 (192.168.69.254)  4.169 ms  4.206 ms  4.287 ms
 2  * * *
 3  z-atman.48.warsawhotelmetropol.com (213.189.36.165)  15.412 ms  15.578 ms  15.712 ms
 4  r7-global-lt-3-2-0-30.atman.pl (85.232.232.13)  15.903 ms  16.043 ms  16.239 ms
 5  72.14.219.114 (72.14.219.114)  38.372 ms  38.978 ms  39.663 ms
 6  209.85.240.64 (209.85.240.64)  40.449 ms 209.85.241.110 (209.85.241.110)  30.391 ms 209.85.240.64 (209.85.240.64)  40.327 ms
 7  209.85.248.94 (209.85.248.94)  90.287 ms  65.451 ms 72.14.233.104 (72.14.233.104)  43.865 ms
 8  72.14.239.94 (72.14.239.94)  134.331 ms  134.560 ms 216.239.43.90 (216.239.43.90)  124.102 ms
 9  209.85.243.114 (209.85.243.114)  139.958 ms  140.091 ms 209.85.241.222 (209.85.241.222)  136.167 ms
10  209.85.241.207 (209.85.241.207)  140.229 ms 209.85.251.228 (209.85.251.228)  140.453 ms 64.233.174.87 (64.233.174.87)  129.356 ms
11  209.85.253.185 (209.85.253.185)  134.299 ms 209.85.253.181 (209.85.253.181)  130.482 ms 209.85.242.181 (209.85.242.181)  127.593 ms
12  vx-in-f16.1e100.net (74.125.115.16)  128.946 ms  130.188 ms  129.702 ms


The first step on identifying the potential attacker was to inspect the certificate that was presented by the MITM. The certificate claimed to be issued by FortiGate CA. What does this mean?

FortiGate is a product sold by Fortinet, Inc. It is a device that can be used to perform a various set of actions on Internet connections. For example, a company could use it to block connections, for example to disallow employees to access their private email. Another use is being able to watch the contents of encrypted connections between a browser and Internet services.

It is debatable whether the use of such appliances is acceptable. There might be scenarios where this is acceptable. For example, one could think of a governmental agency that allows its employees to make private connections to the Internet, but at the same time all employees have agreed to never publish any confidential information, and employees might have agreed that all their actions are being watched while at work, in order to verify that no confidential data is being published. This might be an acceptable scenario.

In my opinion, using such a MITM appliance, for the purpose of hijacking connections of hotel guests to Email service providers, is clearly not acceptable. Other's have to decide whether this is a criminal situation, but I think it might be.

I've talked to a representative of the German office of Fortinet. I was told, by default the FortiGate appliances come with a zero configuration. Any blocking or MITM behaviour of the FortiGate appliance must be deliberately enabled by the customer.

In my understanding, we cannot blame Fortinet. They appear to have provided the tool being used to perform an attack, but it appears that someone else has installed and abused that tool.

Unfortunately I don't know whom to blame. This would have to be decided by an investigation.

The important lesson that we can take away from this story:

Don't lightheartedly ignore security warnings. They can be real attacks. In my scenario, if I had decided to connect anyway, the person performing the MITM would have been able to hijack my password to one of my accounts.

(Also, I have a technical question about the kind of connection used by Android's Google Mail application. Does it use IMAP with SSL on port 993? I hope it does not. When I connected the Android phone to the hotel wifi, it successfully connected. I did not get any security warning. This might be OK, depending on which protocol is being used by the software. If know what it uses, please let me know. Thanks. (To be on the safe side, I had immediately changed my password using a non-MITM client.))

[Update 1] (My separate worry about the Android app was unfounded. Meanwhile I've been in contact with a representative from Google. I've been told that the "Google Mail / Gmail App" on Android always uses https on port 443. This port was not affected by the MITM attack. The attack was limited to imap/ssl on port 993.) [/Update 1]

FYI, I saved the MAC address of the Wireless Access point that I've been connected to, and can provide it to authorities. It looked like 00:4F:62:xx:xx:xx. There were other Access points in the hotel. Unfortunately only this one AP's signal was strong enough to keep a connection to it from my room.

[Update 2] This scenario appears to happen more frequently.

After reading the article, Stephen Davidson found the following two discussions on the web, which appear to report the same issue:
- report 1 (experienced at a hotel, probably located in the USA, because the author mentioned Sprint)
- report 2 (seems to be happening at a school in the US, last comment indicates probably caused by an accidental misconfiguration)

I was able to find some additional reports:
- report 3 - report 4 - report 5 - report 6 - report 7 (search that page for "imap.gmail")

There's one detail that surprises me most: I am able to find several reports about MITM for imap.gmail.com mentioning a FortiGate CA, but I cannot find reports mentioning Fortigate and IMAP in combination with some other imap server. Is the explanation that Gmail is the most popular imap service on the web, and that users of other imap servers are aware of the fact that they are being monitored by their environment? [/Update 2]

[Update 3] Clarification: The MITM experience was only seen in one combination of host and port (out of the combinations I tried). In my opinion, if the box accidentally ran an incorrect configuration by mistake, I would have expected it to equally affect all connections on a set of port numbers. However, access to other IMAP/SSL hosts on port 993 (including my own mail server) were NOT affected and used trusted certs. The MITM appears to have been specifically targeted to a certain (set of) host(s). [/Update 3]


    MITM used this cert:
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number:
                4c:9f:a7:fd:00:00:00:48
            Signature Algorithm: sha1WithRSAEncryption
            Issuer: C=US, ST=California, L=Sunnyvale, O=Fortinet, OU=Certificate Authority, CN=FortiGate CA/emailAddress=support@fortinet.com
            Validity
                Not Before: Apr 22 20:17:57 2010 GMT
                Not After : Apr 22 20:27:57 2011 GMT
            Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=imap.googlemail.com
            Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                    Public-Key: (1024 bit)
                    Modulus:
                        00:ad:81:6b:dc:b4:15:cf:1e:b6:f3:bf:d1:39:7d:
                        42:26:77:23:55:29:28:05:61:1e:ea:bb:7b:a2:02:
                        d1:10:b3:9e:49:d9:b4:8b:54:e5:50:78:0d:52:e1:
                        43:ad:d9:53:fd:2f:a5:23:56:aa:36:7f:54:88:1c:
                        06:68:96:18:dc:b7:43:5e:f3:9a:b6:bc:a8:75:d4:
                        fd:e0:c4:7f:65:3b:8e:63:1f:bf:6e:f4:f5:c1:de:
                        f5:58:f5:9a:c9:6f:2d:a9:75:b7:d4:04:97:3a:d9:
                        f4:22:1a:57:bd:26:36:2c:52:64:2c:b8:77:45:c2:
                        0c:1e:80:72:e9:d4:25:8e:59
                    Exponent: 65537 (0x10001)
        Signature Algorithm: sha1WithRSAEncryption
            6f:e7:95:81:3b:a6:99:6b:35:e2:48:09:77:63:d1:f6:7c:1c:
            bb:5c:67:60:5d:00:ac:2d:7c:2f:8b:02:98:75:5c:1e:43:4b:
            f4:de:64:6e:9d:c6:23:5b:ee:ce:23:13:e5:29:cd:50:b9:47:
            ae:dd:c9:8f:82:3a:7a:3d:cc:f0:35:33:ea:bd:25:6f:02:89:
            e8:3d:27:b7:ee:b7:6f:95:21:a1:a2:6c:4b:2e:17:f8:eb:f1:
            dd:96:90:0e:32:ee:80:f9:61:79:c6:88:1e:75:29:e1:a8:d1:
            34:58:b0:a6:d7:c7:99:18:89:57:8d:b7:f5:c0:73:d6:ae:66:
            a4:e6:af:ce:85:71:e1:de:89:8f:e9:29:65:e5:f3:75:23:02:
            9e:9d:a6:8c:00:d7:9a:f9:7f:13:61:b6:79:65:1e:50:b0:8e:
            dd:bf:cd:b8:7b:72:c2:fa:a3:ab:a0:e1:ca:6f:54:8d:79:37:
            43:0e:98:7a:b0:d6:3e:f9:b5:82:e2:89:e3:5b:65:c2:ec:3a:
            cf:ac:1b:f2:b8:c6:16:74:6c:2b:c4:ce:42:60:e2:93:23:1e:
            13:d5:54:f2:6a:c2:93:94:91:8f:02:6e:1f:30:8d:29:2b:06:
            4b:0f:0a:8d:92:16:ad:fc:e2:73:7c:66:0e:24:14:5a:fd:5b:
            54:42:63:71
-----BEGIN CERTIFICATE-----
MIIDDzCCAfegAwIBAgIITJ+n/QAAAEgwDQYJKoZIhvcNAQEFBQAwgaUxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5ueXZhbGUx                                                                                                                               
ETAPBgNVBAoTCEZvcnRpbmV0MR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3Jp                                                                                                                               
dHkxFTATBgNVBAMTDEZvcnRpR2F0ZSBDQTEjMCEGCSqGSIb3DQEJARYUc3VwcG9y
dEBmb3J0aW5ldC5jb20wHhcNMTAwNDIyMjAxNzU3WhcNMTEwNDIyMjAyNzU3WjBt
MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNTW91
bnRhaW4gVmlldzETMBEGA1UEChMKR29vZ2xlIEluYzEcMBoGA1UEAxMTaW1hcC5n
b29nbGVtYWlsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArYFr3LQV
zx6287/ROX1CJncjVSkoBWEe6rt7ogLRELOeSdm0i1TlUHgNUuFDrdlT/S+lI1aq
Nn9UiBwGaJYY3LdDXvOatryoddT94MR/ZTuOYx+/bvT1wd71WPWayW8tqXW31ASX
Otn0IhpXvSY2LFJkLLh3RcIMHoBy6dQljlkCAwEAATANBgkqhkiG9w0BAQUFAAOC
AQEAb+eVgTummWs14kgJd2PR9nwcu1xnYF0ArC18L4sCmHVcHkNL9N5kbp3GI1vu
ziMT5SnNULlHrt3Jj4I6ej3M8DUz6r0lbwKJ6D0nt+63b5UhoaJsSy4X+Ovx3ZaQ
DjLugPlhecaIHnUp4ajRNFiwptfHmRiJV4239cBz1q5mpOavzoVx4d6Jj+kpZeXz
dSMCnp2mjADXmvl/E2G2eWUeULCO3b/NuHtywvqjq6Dhym9UjXk3Qw6YerDWPvm1
guKJ41tlwuw6z6wb8rjGFnRsK8TOQmDikyMeE9VU8mrCk5SRjwJuHzCNKSsGSw8K
jZIWrfzic3xmDiQUWv1bVEJjcQ==
-----END CERTIFICATE-----



Comments

Paul Sladen 
Sunday, August 14, 2011, 03:08 PM
I just got the FortiGate CA/Fortinet MITM/SSL certification spoofing here on the Stena Line ferry between Hoek van Holland and Harwich International. It's snooping Port 993 going to the corporate mail server (_not_ imap.gmail as everyone else is reporting). SSH itself it just fine (no spoofing happening), as are various HTTPS sites (again, no spoofing).

I think what I find disgusting and dishonest here, is the _copying_ of the genuine Subject CN/OU/O fields from the _real_ certification; then using those in creating the fake/spoofed ("FortiGate CA") certification. It's relying on most users just not noticing.

If Fortinet's intention is to allow their customers to intercept third-party encrypted IMAP username+password combos and email communications, then the I'd expect Fortinet to at least be upfront and honest about the spoofed certification being a fake, and why it is.

It's fine to provide an service to generate a throwaway private certification in order to perform MITM virus checking/logging __for those Fortinet customers that want it__, but intentionally spoofing a certification (with explicitly retrieved and bonafide identifiers) is not helping anyone.

That fake cert might be well-intentioned in this case, but the next time an end-user sees a dialogue box with legitimate names but a broken chain of trust, it's probably __not__ going to be quite so friendly.



Erik 
Sunday, July 10, 2011, 03:47 PM
I agree with Robert, they probably prefer MITM'ing imap.googlemail.com (on TCP 993) rather than mail.google.com (on TCP 443), since the email clients are less likely to give a certificate error than web browsers. It is after all the same Gmail username and password being sent when using IMAP over SSL as when using HTTPS.

By the way, I mentioned this blog post in my latest post on "How to detect reverse_https backdoors": http://www.netresec.com/?page=Blog& ... -backdoors

John Turner 
Friday, July 1, 2011, 10:38 AM
I experienced the same issue yesterday on two different WiFi networks at the Bangkok International airport, as well as the EVA Air business lounge in Bangkok. On both Thunderbird and MailApp as well as on iPhone. All three email clients issued certificate challenges similar to the ones that you experienced.

In my case, the imposter SSL certs related to a Gmail account, a Google Apps email account and a corporate account that, while it uses Port 993 and a Courier IMAP server has nothing at all to do with gmail.

I didn't have time to try to track down the owner of the false certs, but it looked and smelt like an MTM.

Not sure if this is all caused by someone misunderstanding how to set up the Fortigate appliance, or is a real MTM attack. I spoke to someone on the plane from BKK to LHR who said that he had seen the challenge and just accepted it. AFAIK, an MTM arrangement of this sort will result in your UID and PWDs being captured in plain text, not to mention all of your email traffic, including attachments.

I think that Fortigate should be investigating, as I agree, this seems illegal to me. Well, it would be illegal in the UK -- not so sure about Thailand!

Many thanks for your post - very helpful!

Regards

John Turner

Robert Relyea 
Friday, June 17, 2011, 06:35 PM
> I am able to find several reports about MITM for imap.gmail.com mentioning a
> FortiGate CA, but I cannot find reports mentioning Fortigate and IMAP in
> combination with some other imap server.

I wonder if there is some silently 'capture gmail' configuration. You wouldn't try to capture web based gmail SSL because that would trigger a lot of Firefox/IE/Opera/Chrome warnings.

I also noticed that all the issues were with someone using Thunderbird. It might be good to test what Outlook does when the imaps server cert doesn't match. Whoever came up with this configuration probably didn't expect Thunderbird actually checking the cert.

Administrator (Kai Engert) 
Friday, June 17, 2011, 02:15 PM
Lior, I fully understand what the Fortigate appliance is supposed to do. When I said, someone abused the Fortigate product, this wasn't said by Fortinet.

I am the one who claims that the Fortigate product is being abused in this environment.

I distinguish between environments, where every user of the network is aware of the MITM (like in some corporate environments), and private environments, like a hotel room in a democratic country, where I am not supposed to be watched.

Nobody had asked for my permission to intercept and monitor my data.

Nobody had informed me that the Internet connection at this place would attempt to intercept and monitor my connections. As far as I remember, the Wifi login page was very minimal, and it didn't announce this practice either.

That's why I call it an abuse.


Lior Gradstein 
Friday, June 17, 2011, 12:42 PM
I don't really see what you mean, or what you are not understanding in this situation. Fortigate is a company that sell appliances to filter trafic and eventually scan for virii.

"In my understanding, we cannot blame Fortinet. They appear to have provided the tool being used to perform an attack, but it appears that someone else has installed and abused that tool."

I don't understand you here. You correctly identified the "problem". The goal of this FortiGate product IS TO INTERCEPT trafic, including HTTPS/IMAPS (everything SSL related). The only way to do this is to stop the SSL trafic as you can see, and relay the demand afterwards (after having inspected the data for virii, for example).

So I find it really fun if someone from Fortigate told you that someone "abused" their tool.
Look at the Fortigate UTM manual (http://www.slideshare.net/yusuf310/fortigate-utm40mr1), bottom of the page 17. Also look at the page 18, where they explain the "feature" you saw at your hotel in Warsaw.

And yes, I agree with you, it's a really really bad functionality on so many points.


Add Comment
Comments are not available for this entry.