search

Ettercap / ettercap

Ettercap Project
http://www.ettercap-project.org
GNU General Public License v2.0
2.32k stars 486 forks source link

SSL MITM #296

Open aeduroth opened 11 years ago

aeduroth commented 11 years ago

I'm using the latest ettercap version from the git repository.

I'm trying to set up an SSL MITM attack with ettercap using the following command: sudo ettercap -Tq -M ARP /10.211.55.36/ /10.211.55.1.1/ -w ~/Desktop/capture.pcap

I had no success* with the following cipher suites (I forced the behaviour by disabling all other cipher suites in firefox's 'about:config'.):

Only the following ciper suites worked for me:

I did not test/try any other cipher suites.

I can't find a reasonable explanation since the mitm itself works. So ettercap is obviously able to decrypt the message given that it forwards the correct information to the actual/real server.

It is noticeable that aes and camellia are block ciphers where rc4 is a stream cipher. Could the reason lie in the 'recent' changes due to the beast attack [1]? - However this doesn't make sense either considering that ettercap is obviously able to decrypt the message.

Here's another observation which is worth mentioning. As a workaround I dumped the traffic via option '-w'. My motivation was to use wireshark's decryption functionality [2].

Could it be that this is a problem with OpenSSL (I guess Wireshark is using openssl too)? BUT if that would be true why is ettercap able to decrypt the traffic?

Does somebody have a reasonable explanation? The aim is to make the ssl mitm part of an exercise in information security class so it would be nice to have either a fix or a reasonable explanation.

Thanks in Advance

* The connection itself was successful but the captured information are not being printed to console by ettercap. [1] http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack [2] http://wiki.wireshark.org/SSL [3] http://comments.gmane.org/gmane.network.wireshark.bugs/34075

brav0hax commented 11 years ago

Did you edit the proper fields in the etter.conf file?

On Thu, Aug 8, 2013 at 5:08 AM, aeduroth notifications@github.com wrote:

I'm using the latest ettercap version from the git repository.

I'm trying to set up an SSL MITM attack with ettercap using the following command: sudo ettercap -Tq -M ARP /10.211.55.36/ /10.211.55.1.1/ -w ~/Desktop/capture.pcap

I had no success* with the following cipher suites (I forced the behaviour by disabling all other cipher suites in firefox's 'about:config'.):

  • rsa_aes_256_sha
  • rsa_camellia_256_sha Only the following ciper suites worked for me:
  • rsa_rc4_128_rsa I did not test/try any other cipher suites.

I can't find a reasonable explanation since the mitm itself works. So ettercap is obviously able to decrypt the message given that it forwards the correct information to the actual/real server.

It is noticeable that aes and camellia are block ciphers where rc4 is a stream cipher. Could the reason lie in the 'recent' changes due to the beast attack [1]? - However this doesn't make sense either considering that ettercap is obviously able to decrypt the message.

Here's another observation which is worth mentioning. As a workaround I dumped the traffic via option '-w'. My motivation was to use wireshark's decryption functionality [2].

  • rsa_camellia_256_sha: Wireshark wasn't able to decrypt the traffic. Problems with decrypting camellia seem to be a known issue though [3].
  • rsa_aes_256_sha: Only certain packages were decrypted but not the one containing the credentials.
  • rsa_rc4_128_rsa: Wireshark successfully decrypted the package containing the logon credentials. => It seems that wireshark has problems with the exact same cipher suites.

Could it be that this is a problem with OpenSSL (I guess Wireshark is using openssl too)? BUT if that would be true why is ettercap able to decrypt the traffic?

Does somebody have a reasonable explanation? The aim is to make the ssl mitm part of an exercise in information security class so it would be nice to have either a fix or a reasonable explanation.

Thanks in Advance

— Reply to this email directly or view it on GitHubhttps://github.com/Ettercap/ettercap/issues/296 .

aeduroth commented 11 years ago

Yes.

ec_uid = 65534 # nobody is the default

ec_gid = 65534 # nobody is the default

ec_uid = 0 ec_gid = 0

if you use iptables:

redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport" redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

brav0hax commented 11 years ago

OK one other thing, check for more than one etter.conf file if you had a previous (distro) version installed it may be picking that up.

Or you can try -a /path/to/etter.conf

Just a thought...not sure its your issue but these are things that we run into pretty often.

Best Regards, Eric

On Thu, Aug 8, 2013 at 5:15 AM, aeduroth notifications@github.com wrote:

Yes.

ec_uid = 65534 # nobody is the default

ec_gid = 65534 # nobody is the default

ec_uid = 0 ec_gid = 0 if you use iptables:

redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport" redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

— Reply to this email directly or view it on GitHubhttps://github.com/Ettercap/ettercap/issues/296#issuecomment-22319253 .

aeduroth commented 11 years ago

Used the '-a' option. Doesn't change anything -> works with rc4 but not with aes256

eaescob commented 11 years ago

Have you tried using arp:remote?

aeduroth commented 11 years ago

@eaescob: I'm NOT saying it's not working at all. My discovery was that it's only working with certain cipher suites. Was somebody able to reproduce that?

eaescob commented 11 years ago

That's the thing, I've tested SSL MiTM with IE, Firefox and Chrome and have not had any issues. But it sounds more like an OpenSSL issue, what version are you using?

aeduroth commented 11 years ago

@eaescob I'm still on it but didn't have time so far...

eaescob commented 11 years ago

I say we move this out of the 0.8 milestone since it's been a while we've heard any updates.

aeduroth commented 10 years ago

Please excuse my delay!

I was able to reproduced the behavior by using:

Following the openssl libraries used:

$ dpkg-query -l | grep openssl
ii  libcurl4-openssl-dev                      7.29.0-1ubuntu3.2                          i386         development files and documentation for libcurl (OpenSSL flavour)
ii  libgnutls-openssl27:i386                  2.12.23-1ubuntu1.1                         i386         GNU TLS library - OpenSSL wrapper
ii  openssl                                   1.0.1c-4ubuntu8.1                          i386         Secure Socket Layer (SSL) binary and related cryptographic tools
ii  python-openssl                            0.13-2ubuntu3.1                            i386         Python 2 wrapper around the OpenSSL library
eaescob commented 10 years ago

Any updates for this?

aeduroth commented 10 years ago

@eaescob Are you asking me?

Was anyone able to reproduce the situation I posted about a month ago?

LocutusOfBorg commented 10 years ago

@aeduroth I didn't try so far, I have problems in finding a network for this kind of tests... here you can find an updated version of curl, ettercap and libnet

https://code.launchpad.net/~costamagnagianfranco/+archive/ettercap-stable-backports

can you please update and try again? Also @eaescob if you can, I don't know too much the code behind the cipher suites in ettercap (I'm trying to backport openssl too)

aeduroth commented 10 years ago

Same outcome by using your libraries.

However I don't think it is a bug in any libraries you use. It's most likely a bug in ettercap. Here's why:

I assume that ettercap does the MITM attack and not openssl. So what you do is building up two connections (victim <---> ettercap AND ettercap <---> service) using openssl. The connection between the victim and the service is work perfectly fine which means that you take the payload from one connection and successfully forward it to the other. What you're not doing is parsing the content and printing it to the console.

Like I mentioned it only works when using RC4 (which is a stream cipher) but not when using for example aes, camellia (which are both block cipher) could it be that you make the calls to openssl in a different class and it's just not implemented?

LocutusOfBorg commented 10 years ago

@aeduroth can you please try again with the latest git code?

aeduroth commented 10 years ago

@LocutusOfBorg could you successfully verify it?

LocutusOfBorg commented 10 years ago

do you have an example of websites that offers the different cipher suites?