Man-In-The-Middle experience in Warsaw 
Thursday, June 16, 2011, 03:17 PM
Posted by Administrator
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 (also known as at port 993, Thunderbird warned me about a certificate error. The certificate presented by IP address was issued to

Subject: C=US, ST=California, L=Mountain View, O=Google Inc,

and it was issued by

Issuer: C=US, ST=California, L=Sunnyvale, O=Fortinet, OU=Certificate Authority, CN=FortiGate CA/

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, 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 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 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
- anyone else in control of one of IP addresses on the route between the hotel and Google:

$ traceroute
traceroute to (, 30 hops max, 60 byte packets
1 ( 4.169 ms 4.206 ms 4.287 ms
2 * * *
3 ( 15.412 ms 15.578 ms 15.712 ms
4 ( 15.903 ms 16.043 ms 16.239 ms
5 ( 38.372 ms 38.978 ms 39.663 ms
6 ( 40.449 ms ( 30.391 ms ( 40.327 ms
7 ( 90.287 ms 65.451 ms ( 43.865 ms
8 ( 134.331 ms 134.560 ms ( 124.102 ms
9 ( 139.958 ms 140.091 ms ( 136.167 ms
10 ( 140.229 ms ( 140.453 ms ( 129.356 ms
11 ( 134.299 ms ( 130.482 ms ( 127.593 ms
12 ( 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 "")

There's one detail that surprises me most: I am able to find several reports about MITM for 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:
Version: 3 (0x2)
Serial Number:
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=Sunnyvale, O=Fortinet, OU=Certificate Authority, CN=FortiGate CA/
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,
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption

view entry ( 49258 views )   |  permalink   |  $star_image$star_image$star_image$star_image$star_image ( 3 / 4631 )

<<First <Back | 1 | 2 | 3 | 4 | 5 |