6 ms·

Interesting attack, but likely impractical. - Iterating over all internal IPv4 addresses to try attacking them isn't that expensive, there are about 16 million

Interesting attack, but likely impractical. - Iterating over all internal IPv4 addresses to try attacking them isn't that expensive, there are about 16 million IP addresses, and there are likely patterns in their allocation if your goal is an internal network. - `HashKnownHosts yes` is not the default setting. - Shell history likely leaks the hosts anyway if you enable this SSH setting. - You could substitute `ssh` with a malicious version of it.

aussieguy1234 8y ago
Put the 16 million IP addresses and their hashes into a sql database table and index the field. Like a rainbow table attack for passwords, but for IPs
- namanyayg 8y ago
  They are salted.
cjbprime 8y ago
And, of course: - The user might be connecting through (perhaps internal) DNS names rather than IP addresses. And probably is, because who wants to type in IP addresses all the time?
- jarfil 8y ago
  It isn't hard to type 10.0.0.1, and using local hostnames like "main" or "box1" wouldn't be much more secure either.
fulafel 8y ago
Another point for IPv6 :)
- bcaa7f3a8bbc 8y ago
  Seriously, using IPv6 really does helps in this case!
nccgroupie 8y ago
You are right it isn't expensive, but it is much noisier to use something like masscan over 16m internal IP addresses if you are pentesting an organization with a decent blue team. I don't think this tool was made for the use case of HashKnownHosts not being set. Using shell history, known hosts, netstat, etc are all great ways to find hosts to pivot to. Substituting ssh with a malicous version is extremely noisy and risky as well.
cranesan 8y ago
(disclosure - I've had conversations with the author of this tool) I'd say that it's HashKnownHosts that is impractical, not the attack. One of the reasons someone would publish a tool like this is to raise awareness of the brittle security HashKnownHosts offers vs. modern GPUs.
laumars 8y ago
I don't disagree with some of the points you have made however there are also counterarguments to be made against them as well: 1) Iterating over the network: The point of this type of attack is to stay under the radar of NIDS which should (if configured correctly) detect someone trying to knock on port 22 of every server in your private address space. 2) `HashKnownHosts yes` is not the default setting: True. But it is an available setting and since some would enable it assuming it would provide them with extra security then the strength of that extra security does still need to be proven. Hence why this research was done. 3) Shell history likely leaks the hosts anyway if you enable this SSH setting: Indeed. However it's also not that uncommon for people to disable shell history on bastion servers. Plus if that particular user hasn't SSH'ed in a little while it's possible the history file has rolled over to reveal fewer servers in its log. 4) You could substitute `ssh` with a malicious version of it: You could. That's probably the most likely attack to try first but it's not without it's problems as well: * You'd either need root access to replace the ssh client, or to be damn sure you updated the right user shell profile to update the $PATH variable to include the location of your preferred ssh client (ie putting export PATH=~/boobytrapped:$PATH ) and the user not noticing either the modification to their profile nor the new folder in a user writable directory (it's worth referencing an earlier point about how a network scan was dismissed because it is a detectable attack) * It's a longer term attack since you wouldn't get a list of servers until after a user has connected to them (on the plus side, you could glean more detail about the target).
- achamayou 8y ago
  export PATH=~/.boobytrapped:$PATH would make it less noticeable for a start.
  - laumars 8y ago
    Indeed but only until someone opens their \.$SHELL(rc|_profile) or lists hidden files. Which, for some engineers, wouldn't take long. Bare in mind it might also take a while to collect data from your new boobytrapped SSH client so staying hidden is imperative.
    - 8y ago
deleted 8y ago
[deleted]
tinus_hn 8y ago
There are basically 4 billion IPv4 addresses, practically 2.5 billion. If there were only 16 million they'd have run out really quickly.
- rocqua 8y ago
  The 10.0.0.0/8 range has ~16 million addresses. Which is what was referred to.

aussieguy1234 8y ago

Put the 16 million IP addresses and their hashes into a sql database table and index the field. Like a rainbow table attack for passwords, but for IPs

namanyayg 8y ago
They are salted.

cjbprime 8y ago

And, of course: - The user might be connecting through (perhaps internal) DNS names rather than IP addresses. And probably is, because who wants to type in IP addresses all the time?

jarfil 8y ago
It isn't hard to type 10.0.0.1, and using local hostnames like "main" or "box1" wouldn't be much more secure either.

fulafel 8y ago

Another point for IPv6 :)

bcaa7f3a8bbc 8y ago
Seriously, using IPv6 really does helps in this case!

nccgroupie 8y ago

You are right it isn't expensive, but it is much noisier to use something like masscan over 16m internal IP addresses if you are pentesting an organization with a decent blue team. I don't think this tool was made for the use case of HashKnownHosts not being set. Using shell history, known hosts, netstat, etc are all great ways to find hosts to pivot to. Substituting ssh with a malicous version is extremely noisy and risky as well.

cranesan 8y ago

(disclosure - I've had conversations with the author of this tool) I'd say that it's HashKnownHosts that is impractical, not the attack. One of the reasons someone would publish a tool like this is to raise awareness of the brittle security HashKnownHosts offers vs. modern GPUs.

laumars 8y ago

I don't disagree with some of the points you have made however there are also counterarguments to be made against them as well: 1) Iterating over the network: The point of this type of attack is to stay under the radar of NIDS which should (if configured correctly) detect someone trying to knock on port 22 of every server in your private address space. 2) `HashKnownHosts yes` is not the default setting: True. But it is an available setting and since some would enable it assuming it would provide them with extra security then the strength of that extra security does still need to be proven. Hence why this research was done. 3) Shell history likely leaks the hosts anyway if you enable this SSH setting: Indeed. However it's also not that uncommon for people to disable shell history on bastion servers. Plus if that particular user hasn't SSH'ed in a little while it's possible the history file has rolled over to reveal fewer servers in its log. 4) You could substitute `ssh` with a malicious version of it: You could. That's probably the most likely attack to try first but it's not without it's problems as well: * You'd either need root access to replace the ssh client, or to be damn sure you updated the right user shell profile to update the $PATH variable to include the location of your preferred ssh client (ie putting export PATH=~/boobytrapped:$PATH ) and the user not noticing either the modification to their profile nor the new folder in a user writable directory (it's worth referencing an earlier point about how a network scan was dismissed because it is a detectable attack) * It's a longer term attack since you wouldn't get a list of servers until after a user has connected to them (on the plus side, you could glean more detail about the target).

achamayou 8y ago
export PATH=~/.boobytrapped:$PATH would make it less noticeable for a start.
- laumars 8y ago
  Indeed but only until someone opens their \.$SHELL(rc|_profile) or lists hidden files. Which, for some engineers, wouldn't take long. Bare in mind it might also take a while to collect data from your new boobytrapped SSH client so staying hidden is imperative.
  - 8y ago

deleted 8y ago

[deleted]

tinus_hn 8y ago

There are basically 4 billion IPv4 addresses, practically 2.5 billion. If there were only 16 million they'd have run out really quickly.

rocqua 8y ago
The 10.0.0.0/8 range has ~16 million addresses. Which is what was referred to.