4 ms·

You could just run `history | grep ssh` and look at all the domain names that show up.

chris408 8y ago
That is true and it is the first place I usually check when I compromise a new server. This wasn't mentioned in the post but imagine you compromised a server and found an unprotected ssh key. You don't know where it can be used, and the .bash_history has rolled over or has very few ssh commands in it. You see a lot of hosts in the known_hosts file though but it is hashed. That is where this would be helpful, and is why I went down this route.
- bcaa7f3a8bbc 8y ago
  Let's suggest an alternative scenario - the hosts and ports are encrypted. Now what can the attackers do? Well, they still have hashes of public keys. The attacker can scan the entire IPv4 Internet with Z-MAP, and record all SSH public keys. With some hashing, the host can be identified. With online services like Censys (https://censys.io/ https://censys.io/), the attackers don't even have to scan and compute, but can directly obtain the information from a public database... Also, to make it clear, while I'm saying that the attack is too impractical to make sense, I have full respect to your research project, thanks for analyzing this security issue for the community.
- nodesocket 8y ago
  > first place I usually check when I compromise a new server Probably don't want to admit publicly that you compromise servers, though I assume you mean with consent. :-)
  - chris408 8y ago
    Yes, with concent of course (Red Teaming).
integrate-this 8y ago
Or run nmap, or look at your own IP address and just guess at it, or look at your /var/log/messages and ssh logs, all of which are likely just as effective and way less time-consuming than cracking hashed host information. This isn't really a vulnerability. It's a curiosity. If you're on the sever (or NFS), and have access to this information already, then you're already in pretty damn good shape. This just allows you to be more thorough.

That is true and it is the first place I usually check when I compromise a new server. This wasn't mentioned in the post but imagine you compromised a server and found an unprotected ssh key. You don't know where it can be used, and the .bash_history has rolled over or has very few ssh commands in it. You see a lot of hosts in the known_hosts file though but it is hashed. That is where this would be helpful, and is why I went down this route.

bcaa7f3a8bbc 8y ago
Let's suggest an alternative scenario - the hosts and ports are encrypted. Now what can the attackers do? Well, they still have hashes of public keys. The attacker can scan the entire IPv4 Internet with Z-MAP, and record all SSH public keys. With some hashing, the host can be identified. With online services like Censys (https://censys.io/ https://censys.io/), the attackers don't even have to scan and compute, but can directly obtain the information from a public database... Also, to make it clear, while I'm saying that the attack is too impractical to make sense, I have full respect to your research project, thanks for analyzing this security issue for the community.
nodesocket 8y ago
> first place I usually check when I compromise a new server Probably don't want to admit publicly that you compromise servers, though I assume you mean with consent. :-)
- chris408 8y ago
  Yes, with concent of course (Red Teaming).

integrate-this 8y ago

Or run nmap, or look at your own IP address and just guess at it, or look at your /var/log/messages and ssh logs, all of which are likely just as effective and way less time-consuming than cracking hashed host information. This isn't really a vulnerability. It's a curiosity. If you're on the sever (or NFS), and have access to this information already, then you're already in pretty damn good shape. This just allows you to be more thorough.