MITM Labs/Bettercap to Replace Images

Replacing Images in Web Traffic

The setup

We have a sheep connected to wifi. The sheep is going to be man in the middle attacked by the attacker, who will pretend to be the gateway to the sheep, and pretend to be the sheep to the gateway. Then the attacker will use this control of the traffic to modify HTTP content returned to the sheep, and replace all images with this one:

Materials

Get the custom ruby proxy module to replace images with a custom image:

$ wget https://raw.githubusercontent.com/evilsocket/bettercap-proxy-modules/master/http/replace_images.rb

(see Man in the Middle/Traffic Injection for more info).

Now you have replace_images.rb in a given directory with your materials and logs and scripts.

Make a directory that will contain the image you're going to serve up in place of the old images. This will be called img/ and will contain an image called hack.jpg.

Running bettercap

Now we can run bettercap from this directory, specifying the custom Ruby proxy module with the --proxy-module replace_images argument. You will also need to set the --httpd and --httpd-path options to run an http server, from the directory that contains your hack.jpg image, to serve up the image to the sheep.

The whole thing looks like this:

bettercap -I wlan2 -O bettercap_proxy.log -S ARP -X \
    --proxy --proxy-module replace_images \
    --httpd --httpd-path img \
    --gateway 192.168.0.1 --target 192.168.0.7

(Note that --gateway 192.168.0.1 is not strictly necessary.)

The first line specifies my network device, output file, type of attack, and turns on a sniffer.

The second line turns on the http proxy server, which is what gives me access to the traffic to modify it.

The third line runs a web server on the local machine to host my O HAI image - when we inject it in the sheep's traffic, it will be served up by us.

The last line specifies the internet gateway and the sheep, via their IP addresses.

Results

This worked like a charm. I ran the script on the attacker, closed the browser on the sheep, gave it about 15 seconds, and then opened the browser. It slows down the loading time by a substantial amount - but as you can see, it's worth it:

To see more info on how the http proxy works, and how else the traffic can be modified, see the Bettercap page.

Observations

Other observations I made: I could see the tool trying to use the HSTS attack, redirecting requests to wwww.charlesreid1.com. These would fail initially, but when I refreshed, they worked fine - totally transparent. Except for the failure.

HTTPS content was showing up as insecure - for example, an embedded Vimeo player would show up as a minipage with a "Your connection is not secure" error.

However, for the most part, on the HTTP sites that I tried, the images were replaced and the entire attack worked flawlessly. It is actually quite scary how easy it is to carry out this attack, once you've got it down pat, and how hard it would be for a sheep to detect. This is an excellent, excellent reason to assume that every bit of traffic on an untrusted network is being monitored.

VPNs - once again, running a VPN on the sheep (OpenVPN) led to all the traffic being tunneled through the VPN, and it was impervious to the attack.

Layers of protection:

• HTTP - absolutely zero protection. You're just walking around naked.
• HTTPS - encrypted traffic. It's gonna take a more dedicated attacker to crack this, but it isn't secure. Make sure you've got a modern browser.
• VPN - yet another layer of encryption. Yet another layer that's possible to crack, given a dedicated enough attacker.
• Encrypted tunnels - like HTTPS, these types of connections are still vulnerable to dedicated attackers (Bettercap can run SSH traffic through its TCP proxy and force the connection to happen using SSH version 1, which has known weaknesses, instead of version 2, opening up the communication channel to sniffing and more attacks.)

What kind of trouble you can get up to:

• Imagine you force an SSH connection down to version 1, you crack the encryption, and you man in the middle the session. Now, you run a regexp, and every time the user runs the "vim" command, you replace it with the "rm -rf" command.

Caveats

Some caveats:

• Sheep have to be visiting HTTP sites
• Need to disable HTTPS proxying
• Slows down loading times for the sheep
• The more targeted, the better - definitely.