Hi,
I often run my SSH sessions via Tor using tsocks. But today I see:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.
Further investigation shows that this happens for any destination IP address, even where there's no SSH service running:
$ tsocks ssh -vC root@8.8.8.8 OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 debug1: Reading configuration data /home/steven/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 8.8.8.8 [8.8.8.8] port 22. debug1: Connection established. debug1: identity file /home/steven/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_rsa-cert type -1 debug1: identity file /home/steven/.ssh/id_dsa type 2 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 debug1: Remote protocol version 2.0, remote software version dropbear_2015.67 debug1: no match: dropbear_2015.67 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-sha2-256 zlib@openssh.com debug1: kex: client->server aes128-ctr hmac-sha2-256 zlib@openssh.com debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a The authenticity of host '8.8.8.8 (8.8.8.8)' can't be established. RSA key fingerprint is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a. Are you sure you want to continue connecting (yes/no)? :
I could be wrong, but I think this "dropbear" service is most likely something malicious, running on one or more Tor exit nodes, attempting to collect passwords of people logging in this way.
If a user ignored the error (or trusts the fingerprint without verifying), their password, and further activity on the shell could all be captured by the attacker.
Since Tor makes my client connections anonymous, and the dropbear is seen even for hosts that don't provide an SSH service, makes me think this attack is indiscriminate, not targetted only at me or my servers.
The first time you connect to some machine, be careful to verify the fingerprint through independent means. Pay attention to notices like this of changed key fingerprints. And if you haven't already, disable PasswordAuthentication to something that cannot be intercepted (like authorization of private RSA/ECDSA keys).
Regards,
On 9 Aug 2017, at 10:48, Steven Chamberlain steven@pyro.eu.org wrote:
Hi,
...
I could be wrong, but I think this "dropbear" service is most likely something malicious, running on one or more Tor exit nodes, attempting to collect passwords of people logging in this way.
If you can find the exit fingerprints or IP addresses, please email them to bad-relays@lists.torproject.org. They will BadExit them.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 08/08/2017 01:48 PM, Steven Chamberlain wrote:
Hi,
I often run my SSH sessions via Tor using tsocks. But today I see:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.
I've seen that happen with Digital Ocean droplets. And when I've checked, I've found that the host key had, in fact, changed. Did you check for that?
Further investigation shows that this happens for any destination IP address, even where there's no SSH service running:
$ tsocks ssh -vC root@8.8.8.8 OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 debug1: Reading configuration data /home/steven/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 8.8.8.8 [8.8.8.8] port 22. debug1: Connection established. debug1: identity file /home/steven/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_rsa-cert type -1 debug1: identity file /home/steven/.ssh/id_dsa type 2 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 debug1: Remote protocol version 2.0, remote software version dropbear_2015.67 debug1: no match: dropbear_2015.67 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-sha2-256 zlib@openssh.com debug1: kex: client->server aes128-ctr hmac-sha2-256 zlib@openssh.com debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a The authenticity of host '8.8.8.8 (8.8.8.8)' can't be established. RSA key fingerprint is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a. Are you sure you want to continue connecting (yes/no)? :
That's not even a host key change. It's just that you don't yet have the host key.
I could be wrong, but I think this "dropbear" service is most likely something malicious, running on one or more Tor exit nodes, attempting to collect passwords of people logging in this way.
No, dropbear is an SSH server that 8.8.8.8 seems to be running.
If a user ignored the error (or trusts the fingerprint without verifying), their password, and further activity on the shell could all be captured by the attacker.
Since Tor makes my client connections anonymous, and the dropbear is seen even for hosts that don't provide an SSH service, makes me think this attack is indiscriminate, not targetted only at me or my servers.
The first time you connect to some machine, be careful to verify the fingerprint through independent means. Pay attention to notices like this of changed key fingerprints. And if you haven't already, disable PasswordAuthentication to something that cannot be intercepted (like authorization of private RSA/ECDSA keys).
Regards,
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, 8 Aug 2017 18:51:51 -1100 Mirimir mirimir@riseup.net wrote:
On 08/08/2017 01:48 PM, Steven Chamberlain wrote:
Hi,
I often run my SSH sessions via Tor using tsocks. But today I see:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.I've seen that happen with Digital Ocean droplets. And when I've checked, I've found that the host key had, in fact, changed. Did you check for that?
The authenticity of host '8.8.8.8 (8.8.8.8)' can't be established. RSA key fingerprint is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a. Are you sure you want to continue connecting (yes/no)? :That's not even a host key change. It's just that you don't yet have the host key.
I could be wrong, but I think this "dropbear" service is most likely something malicious, running on one or more Tor exit nodes, attempting to collect passwords of people logging in this way.
No, dropbear is an SSH server that 8.8.8.8 seems to be running.
Did you try ssh'ing into 8.8.8.8 (outside of Tor)? It does not run a public SSH server at all (obviously).
The point was to demonstrate that the exit node intercepts port 22 connections to any IP, and redirects them to the same particular instance of dropbear. Note how in both cases it's the same key fingerprint of e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.
On Wed, Aug 09, 2017 at 10:58:01AM +0500, Roman Mamedov wrote:
No, dropbear is an SSH server that 8.8.8.8 seems to be running.
Did you try ssh'ing into 8.8.8.8 (outside of Tor)? It does not run a public SSH server at all (obviously).
The point was to demonstrate that the exit node intercepts port 22 connections to any IP, and redirects them to the same particular instance of dropbear.
Right -- it seems clear that there is some exit relay out there that is handling requests for 8.8.8.8:22 (and probably *:22) poorly. If somebody can tell us which one it is, we'll get rid of it.
(Several groups who run scanners for this sort of thing will hopefully pick this thread up in the next day or so and we can resolve it then.)
--Roger
On Wed, Aug 09, 2017 at 02:41:34AM -0400, Roger Dingledine wrote:
Right -- it seems clear that there is some exit relay out there that is handling requests for 8.8.8.8:22 (and probably *:22) poorly. If somebody can tell us which one it is, we'll get rid of it.
Ok, we have identified the relay and begun the process of kicking it out of the network. It's some jerk on digital ocean.
Thanks, --Roger
Roger: I got an exitmap module that hunts for these.
https://github.com/jowrjowr/exitmap/blob/master/src/modules/sshmitm.py
On Wed, Aug 9, 2017 at 5:23 AM, Roger Dingledine arma@mit.edu wrote:
On Wed, Aug 09, 2017 at 02:41:34AM -0400, Roger Dingledine wrote:
Right -- it seems clear that there is some exit relay out there that is handling requests for 8.8.8.8:22 (and probably *:22) poorly. If somebody can tell us which one it is, we'll get rid of it.
Ok, we have identified the relay and begun the process of kicking it out of the network. It's some jerk on digital ocean.
Thanks, --Roger
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 08/08/2017 06:58 PM, Roman Mamedov wrote:
On Tue, 8 Aug 2017 18:51:51 -1100 Mirimir mirimir@riseup.net wrote:
On 08/08/2017 01:48 PM, Steven Chamberlain wrote:
Hi,
I often run my SSH sessions via Tor using tsocks. But today I see:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.I've seen that happen with Digital Ocean droplets. And when I've checked, I've found that the host key had, in fact, changed. Did you check for that?
The authenticity of host '8.8.8.8 (8.8.8.8)' can't be established. RSA key fingerprint is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a. Are you sure you want to continue connecting (yes/no)? :That's not even a host key change. It's just that you don't yet have the host key.
I could be wrong, but I think this "dropbear" service is most likely something malicious, running on one or more Tor exit nodes, attempting to collect passwords of people logging in this way.
No, dropbear is an SSH server that 8.8.8.8 seems to be running.
Did you try ssh'ing into 8.8.8.8 (outside of Tor)? It does not run a public SSH server at all (obviously).
The point was to demonstrate that the exit node intercepts port 22 connections to any IP, and redirects them to the same particular instance of dropbear. Note how in both cases it's the same key fingerprint of e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.
Oops, I missed the fact that the key fingerprints are the same :(
On Wed, 09 Aug 2017 10:58:01 +0000, Roman Mamedov wrote: ...
Did you try ssh'ing into 8.8.8.8 (outside of Tor)? It does not run a public SSH server at all (obviously).
8.8.8.8 is (pretty certainly) anycast, and might have different setups in different instances. But, being google, they probably *are* identical.
ssh 8.8.8.8 just times out here.
Andreas
tor-relays@lists.torproject.org
-
Andreas Krey -
eric gisse -
Mirimir -
Roger Dingledine -
Roman Mamedov -
Steven Chamberlain -
teor