Compromized tor ssh instances

[chigurh]

I use tor on OpenBSD host for sshing into remote servers with dynamic IP addresses. In the middle of February, 2015 I witnessed strange pattern while trying to SSH into remote server running Debian GNU/Linux. I was offered a fake key and out of curiosity I accepted it. This same pattern continued with other remote machine running CentOS; I decided not to accept the key and contacted the admin at other side. They said they have not regenerated the keys on their host.

On OpenBSD host I checked how many users were logged in and it showed me 4 instances of a single user logins; which was strange. I regenerated the keys on the first machine, removed the previous one and reinitiated ssh sessions.

It is my understanding that tor's x.509 certificates are self-signed and it is possible to force a MITM attack by forging certificates. Tor's exchange can be intercepted and forged. I can't demand logs from remote hosts to verify these incidents.

After considering several options and in order to minimize the risk I decided to chroot tor as per instructions available at http://pestilenz.org/~bauerm/tor-openbsd-howto.html and https://trac.torproject.org/projects...bsdChrootedTor

These documents are not up-to-date and during the test I have taken into account the missing bits. After the setup when I tried to start tor in chroot I got 'Abort trap'. The trials were carried out on OpenBSD-5.6 i386 running in qemu on OpenBSD host.

I will like to know how I can achieve this and chroot tor. This security concern is only about sshing thru tor or hosting a hidden service, for everything else I pass traffic thru <lan> --- <OpenBSD-router> --- <squid> --- <privoxy-chrooted> --- <tor> --- <Internet>.

Thanks!

[jggimi]

Disclaimer: I don't know anything about your compromised servers/clients, nor about tor as an ssh attack vector. But there is a reason ssh(1) warns the user if the server keys have changed.

Prior to 5.6, the OpenBSD FAQ had a section (FAQ 10.16) that discussed chrooted application requirements for web servers. While intended for applications running with Apache or nginx, it contained general considerations you might find helpful. Here's a link to revision 1.187 of FAQ 10, the changes which removed section 10.16 from the FAQ occurred in revision 1.188.

[chigurh]

Originally Posted by jggimi

Disclaimer: I don't know anything about your compromised servers/clients, nor about tor as an ssh attack vector. But there is a reason ssh(1) warns the user if the server keys have changed.

Prior to 5.6, the OpenBSD FAQ had a section (FAQ 10.16) that discussed chrooted application requirements for web servers. While intended for applications running with Apache or nginx, it contained general considerations you might find helpful. Here's a link to revision 1.187 of FAQ 10, the changes which removed section 10.16 from the FAQ occurred in revision 1.188.

Yeah, my bad I did not second guess at that time and I hushed it. I have checked FAQ 10.16 before and it got me started with chroot. Tor will need /dev/urandom & /dev/null. I think I will refine my chroot strategy and put it here later tonight for experts review.

[jggimi]

I don't know what you are using for authentication; nor is it clear to me if any client private keys were exposed if used.

If client private keys were (or are) at risk, you might consider one of the two-factor authentication options available for SSH.

In addition, ChrootDirectory can apply chroots to authenticated client sessions. I've used that very successfully when needed to restrict users to sftp activity within a specific filesystem branch.

Both of these may be helpful. It's also possible that neither are helpful, or that you're already using both techniques.

[chigurh]

Originally Posted by jggimi

I don't know what you are using for authentication; nor is it clear to me if any client private keys were exposed if used.

I use password authentication.

If client private keys were (or are) at risk, you might consider one of the two-factor authentication options available for SSH.

After the incident I removed all keys and regenerated.

In addition, ChrootDirectory can apply chroots to authenticated client sessions. I've used that very successfully when needed to restrict users to sftp activity within a specific filesystem branch.

Thanks for the pointer, will deploy it in my test environment in qemu and see how that goes.

Both of these may be helpful. It's also possible that neither are helpful, or that you're already using both techniques.

Not tried any of those before, have fairly large infrastructure behind OpenBSD router and I depend heavily on Tor & SSH for day-to-day use; it was wrong on my part to accept the key in good faith before verifiying the status with remote admin. After chrooting Tor there will be this possible exploit but then the attacker will not gain access beyond ChrootDirectory.

[jggimi]

Originally Posted by chigurh

I use password authentication.

That is single-factor authentication, and, I'm going to guess, most likely how your client credentials were obtained. While passwords are easy to use, they require your client to trust the server with the password. And the server you connected to was compromised.

Some of the other authentication methods available with SSH do not require passing of usable client credentials, so that a compromised server cannot steal a client's identity. This includes the skey(1) one-time-pad, but as that is single factor and requires provisioning and reprovisioning for single-use keys ... far more widely, people use Public Key Authentication, which uses passphrases (something you know) with private client keys (something you have) for two-factor authentication with a host that has the public half of the client's key pair. The server never obtains access to the client's private credentials -- authentication is done mathematically.

After the incident I removed all keys and regenerated.

These are server keys that identify your server to clients, so that the clients will be notified if the server key at your IP address or domain name changes. This is not the same thing as Public Key Authentication used by clients. Client key pairs are easy to create, as ssh-keygen(1) with no parameters will create a public/private key pair using RSA, and prompt the user for an arbitrary passphrase.

The private key remains private, and in control of the client. The public key can be shipped insecurely -- via Email, posted on a forum -- and the host need only add it to the client's intended $HOME/.ssh/authorized_keys on the server, and the client can authenticate. Without a password, and without ever sending the client's private key to the server. Management of client keys and passphrases for connecting to (or through) multiple systems can be simplified for users with ssh-agent(1) and ssh-add(1).

[chigurh]

Originally Posted by jggimi

That is single-factor authentication, and, I'm going to guess, most likely how your client credentials were obtained. While passwords are easy to use, they require your client to trust the server with the password. And the server you connected to was compromised.

Yes, that is exactly what happened.

Some of the other authentication methods available with SSH do not require passing of usable client credentials, so that a compromised server cannot steal a client's identity. This includes the skey(1) one-time-pad, but as that is single factor and requires provisioning and reprovisioning for single-use keys ... far more widely, people use Public Key Authentication, which uses passphrases (something you know) with private client keys (something you have) for two-factor authentication with a host that has the public half of the client's key pair. The server never obtains access to the client's private credentials -- authentication is done mathematically. These are server keys that identify your server to clients, so that the clients will be notified if the server key at your IP address or domain name changes. This is not the same thing as Public Key Authentication used by clients. Client key pairs are easy to create, as ssh-keygen(1) with no parameters will create a public/private key pair using RSA, and prompt the user for an arbitrary passphrase.

The private key remains private, and in control of the client. The public key can be shipped insecurely -- via Email, posted on a forum -- and the host need only add it to the client's intended $HOME/.ssh/authorized_keys on the server, and the client can authenticate. Without a password, and without ever sending the client's private key to the server. Management of client keys and passphrases for connecting to (or through) multiple systems can be simplified for users with ssh-agent(1) and ssh-add(1).

For most remote hosts we have this type of setup but a small number of remote machine do not offer such comfort. I will try convince people and make sure they implement it. PasswordAuthentication process is tunneled and protected but it assumes client connetcs to trusted server.

I will still prefer chrooting Tor and minimize exposure.

[jggimi]

If you must use remote passwords -- and there are many times they are unavoidable -- then I recommend you and your user community never use the same password across different systems. If I understood what happened to you, your password happened to be used across multiple systems, so the theft of your credentials permitted reverse access. And possibly, access to any other systems with the same userid/pw combination.

I have dozens, if not hundreds of unique passwords for network services of all kinds, from forums like this to banking, healthcare, tax services, government portals. And with very few singular exceptions I do not know my passwords to any of them. I only need to know my passphrase for my password manager, which includes a random password generator, and I used that to create unique passwords for every site.

[chigurh]

Originally Posted by jggimi

If you must use remote passwords -- and there are many times they are unavoidable -- then I recommend you and your user community never use the same password across different systems. If I understood what happened to you, your password happened to be used across multiple systems, so the theft of your credentials permitted reverse access. And possibly, access to any other systems with the same userid/pw combination.

I have dozens, if not hundreds of unique passwords for network services of all kinds, from forums like this to banking, healthcare, tax services, government portals. And with very few singular exceptions I do not know my passwords to any of them. I only need to know my passphrase for my password manager, which includes a random password generator, and I used that to create unique passwords for every site.

I have same usecase. There are over 2 dozen different passwords for various utilities & applications. The password were different on remote machine and the client.

After a lot of thinking I guess it was the tor instance that triggered this, obviously some guy running exitnode was bored and decided to decrypt the traffic. Here are more details https://trac.torproject.org/projects.../doc/badRelays & http://www.cs.kau.se/philwint/spoile...s/pets2014.pdf

I have a select ExitNodes configured but I reckon it will be a good idea to put tor in chroot and I wish future OpenBSD tor package does that by default.

[jggimi]

Originally Posted by chigurh

The password were different on remote machine and the client.

Good. I'd interpreted this earlier statement:

Originally Posted by chigurh

On OpenBSD host I checked how many users were logged in and it showed me 4 instances of a single user logins...

to mean that your captured remote credentials were used locally, and assumed that the same credentials were being used both locally and remote.

[chigurh]

Originally Posted by jggimi

Good. I'd interpreted this earlier statement:to mean that your captured remote credentials were used locally, and assumed that the same credentials were being used both locally and remote.

Yes, 4 instances of user got me thinking. Unfortunately I can not reproduce this incident. I checked users after a couple of hours of Tor SSH exploit.