After the hackers 2 hackers conference talk last year, some people contacted me about known Python performance issues regarding the use of threads related to the GIL.

Indeed the threading wasn’t performing well due the nature of GIL so I’ve rewritten the code to support Python’s multiprocessing module. It’s a tad faster but I haven’t tested it exhaustively so if you feel the inner-beta-tester in you, let me know!

The download is available as always at the github project page at https://github.com/jseidl/GoldenEye and you can read more about the tool at the project page at this blog.

Please test it (ON YOUR OWN RESOURCES!!) and let me know your thoughts!

Ettercap is a great tool for MITM poisoning and sniffing. Everyone on Infosec should have played with it (or Cain) at least once.

Man-In-The-Middle

MITM attacks are pretty easy to perform on a local network but the tools tend to crash a LOT. Cain (Windows) is a little more stable than Ettercap but I prefer it over Cain because it doesn’t spoof SSL that I consider too loud depending on the attack. NOTE: Ettercap runs better on text mode.

Filters

Well, another nice feature of Ettercap are its filters. You can do lot of stuff while playing with them. The nicest toy I’ve found to play around so far is content rewriting (but I think custom packet injection can be even funnier). Irongeek has played with Ettercap Filters in the past to rewrite img tags.

Sniffing while MITM

Sniffing plaintext passwords are just easy. Either Cain and Ettercap are built to detect common strings containing passwords but SSL has made this kind of sniffing impossible and many sites are using it at least for the login processes.

So while we wait for the super-quantum-computers to break 256-bit AES encryption, we may consider avoiding SSL for the period we’re sniffing so I’ve thought that filters could be perfect for that.

What would define where the login form data will be sent? The form‘s action field. So if I can interfere in the HTTP response I can send the login data ANYWHERE.

I’ve decided to just downgrade the SSL because I always tend to make the least noise I can (because we don’t want to get caught by the forensics, do we?). I could redirect the request to a specially crafted site or so but it would be much more noticeable.

What if SSL is required on server-side

No problem, SSL on server-side can be a requirement but by the time the server complains, data was already sent over in plain-text. :)

Getting things done

You can get my filter on my github page.

Just run the attack with the filter (assuming router is 192.168.0.1 and victim is 192.168.0.100):

You should see the following output:

And your victim will no longer receive (nor send) any https string anymore.

Quick note about request / response filtering

Sometimes you may have to comment one leg (request / response) out of the filtering or you will get redirection loops (like while tampering Facebook connections). Also, if the request is already under https, you won’t be able to filter it. The beauty of this attack is disallowing your victim to escape your domain to a secure zone.

HTH!