Man in the middle – of what?

We hear a lot about so-called MITM attacks, but what is it in a nutshell? Let’s look at the “layman” explanation.

From time to time security experts come up with some peculiar – and seemingly self-explanatory – terms that others (mass media included) pick up and use all around – without giving much of an explanation of what it is exactly.

Take Man-In-The-Middle-Attack for instance. It’s quite logical to assume that it has something to do with eavesdropping. Perhaps. Or has it? Come on, somebody, explain what is it? For a layman! Anyone?


Well, okay, let’s see. Yes, indeed it’s about eavesdropping. Specifically, it’s about “active” eavesdropping – when an attacker is not just able to intercept data transferred between sender and receiver, but also modify it, yet still both victims would think that there is just two of them on the line and the data is intact. 

The following example is purely theoretical. Alice calls Bob, Bob responds, and B.G. Mallory is able to tap the wire in between and hear them both. Or, rather receive and relay their messages to each other. Alice requests an authorization key, Bob sends it. It is Mallory who has it then, and he goes on sending Alice his own key. Alice still thinks it is Bob’s.

Alice then encrypts her messages with the rogue key, and sends encrypted data to – Bob? Wrong, it goes to Mallory; he may decrypt the information from Alice, read it, modify it, then encrypt it with Bob’s key (that he still has) and relay it to Bob. Bob receives rogue data, believing it is from Alice. Alice also has no idea that her information has never reached Bob.

Alice sends: “Can you meet me tonight? Got a couple ideas to discuss” (Yes, of course, nobody’s going to launch a secure channel to chat about something like this, but, again, it’s just an example of how it is done).

Mallory intercepts this message and sends to Bob the following: “Can you lend me a couple hundred bucks? Got in a mess, need to sort things out, but no free cash right now. Please?”

Bob responds: “Uhm… Okay. What about meeting at 9pm at Harry’s Bar? I’ll bring the cash.”

Mallory intercepts, modifies message cutting out last sentence and relays it to Alice, while continuing his own exchange with Bob:

“That would be great, but it’s a bit urgent for me. Can you transfer them to my credit card account right now?” (Mallory’s account credentials follow).

Bob: “Well, alright, stand by… Here we go. Have you received money?”

Mallory: “Ah, yes, thank you, thank you, thank you! See ya tonight!”

Meanwhile, Alice sends: “Harry’s Bar? Nice one, will be there by 9. See ya!”, but Bob never receives it. Mallory, in turn relays to Alice Bob’s “See you there” before they hang up.

In time Bob questions whether Alice is going to return money he’s given “her”, which is met with a well-reasoned surprise and confusion, and potentially leads to a bad conflict. And Mallory gets away with a shiny new $200, no tax deductions.

Well, instead of “Bob” there most likely would be some bank, while Alice (a human being) was just checking her account, neglecting precautions.

And “Mallory”, in practice, would be, most likely, a “rogue” router. An attacker can set up his own device with wireless capabilities to act as though it is a “legitimate” hotspot, then perch himself at some crowded place – a cafe with free WiFi available or railroad terminal, or airport. The more people, the better. Some of them most likely will be careless enough to hook up to any free WiFi available and then connect to their bank or a commerce site. Bingo one. 

The other way it can be done: Exploit a weakness in the configuration or encryption implementation of a legitimate WiFi router. While it’s harder to do technically, actually there is a lot of information about the bugs in popular routers on the Web, and once an attacker takes over one of them, he’s got himself a sort of persistent presence within the attacked network, being able to eavesdrop at any communications passing via the device. Bingo two. Until someone decides to update the router’s firmware. And that’s not happening too often.

Add here a newer type of attack nicknamed “Man-In-The-Browser”. Oh, wait, what a name! That’s some “Johnny Mnemonic” stuff: a 160-170 lbs adult human being packed into a piece of software?



Actually, it’s again about planting malicious code on a victim’s machine, that would run inside the browser and record all data sent between the browser and target sites, hardcoded within malware.

This kind of attacks grew in popularity over the last few years since attackers can target a number of sites while staying quite away from the victim base.

As we can see, the primary problem with MITM attack is, most likely, financial. But not only this. A successful MITM attack on a data exchange between two entities (other than a bank, etc.) potentially renders all data transferred extremely untrustworthy. Neither side can be sure that information provided by the other side isn’t bogus. And that may lead to vast problems, especially if the data is sensitive and its amounts are formidable.

How to protect yourselves? First of all, using public WiFi access points for banking or e-commerce is, mildly put, unhealthy. Second, even if you do use public hotspots for something, still watch what you’re connecting to help exclude any malware planting by a miscreant who may (or may not) sit 10 yards away from you.

Most of the defenses against MITM attacks are set up on router/server side, so that users have no control of the security of the transaction. But users still can (and should) protect themselves against some kinds of MITM attacks by employing browser plug-ins such as HTTPS Everywhere or ForceTLS that always establishes a secure connection whenever the option is available.

As for the business, Kaspersky Lab’s Safe Money (available as a separate product or as part of larger solutions, such as Kaspersky Small Office Security, for instance), launches its own browser instance with security level “paranoid”, every time users connect to a banking site.

Adding an extra encryption to sensitive data before transferring them is a good idea too, but it will only work if the recipient already has an encryption key that you use.