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

[grarpamp]

On Wed, Aug 9, 2017 at 4:08 PM, Alexander Nasonov  wrote:
> m...@eugenemolotov.ru wrote:
>> After that check from which ip it was logged in. This probably
>> would be ip of the exit node.
>
> What if they "bridge" mitm-ed traffic to a different host?
>
> I saw a similar ssh warning few weeks ago but I wasn't prepared to
> identify the bad exit. I set SafeLogging to 0 and I will enable
> debugging via SIGUSR2 next time this happens. Can someone confirm
> whether it's a good way of identifying bad exits?

This lack of having easy access to even a short term
(3 hour / 10k connections) in memory simple log buffer,
that doesn't write to disk or have other log junk to filter out,
of what exits users were using before they later happened
to notice something wrong, or before the exit changes out
from under them for reasons, thus ending their diagnosis,
is a *constant* problem users mention on these lists.

You should reopen and lend your support / work this ticket...

# Combine setevents circ and stream
https://trac.torproject.org/projects/tor/ticket/11179
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Chad MILLER]

You choose your own path and exit. It couldn't be any node before your
chosen exit because of onion.

You can't look for incoming traffic on your ssh server to know the bad
node. You have to know your chosen exit from the client end, to know the
MITM.

On Aug 9, 2017 1:08 PM, "Alexander Nasonov"  wrote:

> m...@eugenemolotov.ru wrote:
> > Make a "trap" ssh server (for example on virtualbox machine
> > without any sensitive data) and log in into it through tsocks.
> > After that check from which ip it was logged in. This probably
> > would be ip of the exit node.
>
> What if they "bridge" mitm-ed traffic to a different host?
>
> I saw a similar ssh warning few weeks ago but I wasn't prepared to
> identify the bad exit. I set SafeLogging to 0 and I will enable
> debugging via SIGUSR2 next time this happens. Can someone confirm
> whether it's a good way of identifying bad exits?
>
> --
> Alex
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Roman Mamedov]

On Wed, 9 Aug 2017 21:08:30 +0100
Alexander Nasonov  wrote:

> m...@eugenemolotov.ru wrote:
> > Make a "trap" ssh server (for example on virtualbox machine
> > without any sensitive data) and log in into it through tsocks.
> > After that check from which ip it was logged in. This probably
> > would be ip of the exit node.
> 
> What if they "bridge" mitm-ed traffic to a different host?

They could feed MITMed traffic back into Tor, framing a different exit node
in the process :)

-- 
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Alexander Nasonov]

m...@eugenemolotov.ru wrote:
> Make a "trap" ssh server (for example on virtualbox machine
> without any sensitive data) and log in into it through tsocks.
> After that check from which ip it was logged in. This probably
> would be ip of the exit node.

What if they "bridge" mitm-ed traffic to a different host?

I saw a similar ssh warning few weeks ago but I wasn't prepared to
identify the bad exit. I set SafeLogging to 0 and I will enable
debugging via SIGUSR2 next time this happens. Can someone confirm
whether it's a good way of identifying bad exits?

-- 
Alex
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[eric gisse]

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  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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Andreas Krey]

On Wed, 09 Aug 2017 10:58:01 +, 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

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Mirimir]

On 08/08/2017 06:58 PM, Roman Mamedov wrote:
> On Tue, 8 Aug 2017 18:51:51 -1100
> Mirimir  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 :(
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[me]

On 08/08/2017 01:48 PM, Steven Chamberlain wrote:
> Further investigation shows that this happens for any destination IP
> address, even where there's no SSH service running:

Make a "trap" ssh server (for example on virtualbox machine without any 
sensitive data) and log in into it through tsocks. After that check from which 
ip it was logged in. This probably would be ip of the exit node.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Roger Dingledine]

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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Roman Mamedov]

On Tue, 8 Aug 2017 18:51:51 -1100
Mirimir  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.

-- 
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Mirimir]

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

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

[teor]

> On 9 Aug 2017, at 10:48, Steven Chamberlain  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-rel...@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






signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor exit nodes attacking SSH?

[Steven Chamberlain]

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 z...@openssh.com
debug1: kex: client->server aes128-ctr hmac-sha2-256 z...@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,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays