Re: [tor-relays] Tor exit nodes attacking SSH?

[Mirimir <mirimir@xxxxxxxxxx>]

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@xxxxxxxxxxx
>     debug1: kex: client->server aes128-ctr hmac-sha2-256 zlib@xxxxxxxxxxx
>     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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays