6 ms·
SSH known_hosts hash cracking with Hashcat
- tptacek 8y agoThis is fun, but if you cat out your ~/.ssh/known_hosts file, you'll probably find that it's not hashed, and is just coughing up a map of your SSH relationships to anyone who can read it. It's true though, known_hosts for pivoting is a basic network pentest trick.
- caf 8y agoMaybe stashing a honeypot address in the known_hosts is a good idea?
- stormbrew 8y agoIt's been turned on by default on every ubuntu machine I've used/installed in the last few years. I believe that comes from debian [1]. So I don't think it's that unlikely that any given reader of this has it enabled, tbh. [1] search for HashKnownHosts here: https://manpages.debian.org/jessie/openssh-client/ssh_config.5.en.html https://manpages.debian.org/jessie/openssh-client/ssh_config...
- throwaway2048 8y agoIts the default in the openBSD openssh upstream, has been for years and years.
- jwilk 8y agoIs it? https://man.openbsd.org/ssh_config#HashKnownHosts https://man.openbsd.org/ssh_config#HashKnownHosts says "The default is no".
- GlitchMr 8y agoInteresting 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 agoPut 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 agoThey are salted.
- cjbprime 8y agoAnd, 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 agoIt 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 agoAnother point for IPv6 :)
- bcaa7f3a8bbc 8y agoSeriously, using IPv6 really does helps in this case!
- bcaa7f3a8bbc 8y agoTL;DR: OpenSSH uses ~/.ssh/known_hosts to record IPs, ports and public key fingerprints of, well, known SSH hosts. But it was argued many years ago that, the IPs and ports in known_hosts from a compromised system, can help attackers and viruses to discover more hosts to compromise. As a defense, OpenSSH introduced HashKnownHosts. Instead of saving IPs and addresses in plaintext, it saves HMAC-SHA1(host, salt). Some systems enable it by default, but most don't. This research project showed that, it's still vulnerable to brute-force attacks, especially from GPUs, just like every password storage scheme, and explained the issue with proof-of-concept tools. Finally, the difficulty and impracticability is stated by the authors, > It doesn't seem like there would be a clear solution. If they used a more expensive hashing algorythm like bcrypt, the GPUs could still crack the entire IPv4 address space. [...] Also, if bcrypt was used, this could cause slowness or performance issues potentially, especially for lower powered embedded devices. But my personal opinion is, the entire thing just doesn't make much sense... Computing 10,000 rounds of PBKDF2, or a state-of-art KDF like Argon2 (which can consume ~4 GB of memory as the "Proof-of-Work" to stop GPUs), but just for protecting a humble IP address, seriously? Even if you guard your IP address like a private key, a attacker with a grid of GPUs probably can still use their resources to get the information from elsewhere, like, capture some packets, or scan the entire IPv4 Internet with ZMAP... To me, if you seriously need to hide your hostname for your security, I would say the security is broken anyway... But in case it is really needed, to my mind there are two permanent solutions - 1. Use IPv6. 2. Introduce EncryptKnownHosts. You can implement it yourself using a shell script calling gpg before spawn an SSH instance. Unlike 10,000 rounds of PBKDF2, this solution is absolute.
- user111233 8y agoYou could just run `history | grep ssh` and look at all the domain names that show up.
- chris408 8y agoThat 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.
- metafunctor 8y agoAn alternative to host keys would be to use host certificates instead of keys. It's (a lot) more work to set up, but allows for flexible central management of authentication, plus also eliminates this issue with the known_hosts files.
- twakefield 8y agoDisclosure: I work at the company that created Teleport. Teleport [0] should hopefully make it easier to use certificates. An alternative implementation is Netflix’s Bless [1]. [0] https://github.com/gravitational/teleport https://github.com/gravitational/teleport [1] https://github.com/Netflix/bless https://github.com/Netflix/bless
- poisonborz 8y agoThose files can be cracked? The files should have better security then. /s
- leowoo91 8y agoWhat is the advantage of hcmask over hand written pattern loop here? Is it sent to gpu instead? Cant the attacker use the same algoritm that generates list of all ips without need of saving them?
- exabrial 8y agoSo basically, knownhosts needs to be kept in the equivalent of the osx keychain where it allows access based on the the signature from the app
- mikorym 8y agoCan one mitigate for this attack by not storing any information about the salt? Suppose there is a method x which creates a salt, but does not store it. Then, hash the IP a.b.c.d together with an output from method x. A user can perhaps specify an x of their choosing. Let's say the hash function is then of two variables g(x,a.b.c.d). Would cracking g(x,a.b.c.d) necessary expose the workings of x? (Note that one may want to think of this as two functions and write g(f(x),a.b.c.d) instead. In such a case we are cracking f as a first step.) In the article, one relies on the fact that step 1 exposes the salt and step 2 then exposes a.b.c.d.
- moviuro 8y agoThe salt has to be random, and stored locally. You propose a new hashing algorithm that does: IP -> h. If the salt depends on the IP, you can create a rainbow table offline. If you can generate the salt on the machine (on the fly), you need an algorithm that must run on the machine - what do you base that on? Hostname? local IP addresses? Hardware?... And known_hosts(5) can't be moved to a new machine anymore, as it's tied to a machine.
- mikorym 8y agoI think what I have in mind is essentially a customisation option. And I think your answer (and others) does make a good case that there is not a more general solution to this at the moment (and not even conceptually). As a custom solution there are many ways to solve this if we introduce a third parameter (such as simply encrypting your files with a password). I think however the point that many people are making is that the debate is about what the default should be, and without introducing a third factor. The two step de-hash case (IP hash + salt) suggests interesting research topics on whether there are ways to have other combinations e.g.: (IP hash + x) or (IP hash + x + y) but with the assumption that we don't want any further apriori information. The point that you are making is that in fact we only have one variable (the IP) and the salt is simply a obfuscation step. Any other approach requires more parameters (hardware, fingerprints, etc.).
- rocqua 8y agoOne might simply store a list of hash(address, Fingerprint) Here we are essentially using the fingerprint of the server as the salt, which doesn't need to be stored locally. This would mean you can't detect whether a host changed their fingerprint, just that you've never seen this host-fingerprint combination. So if someone were to MitM your box, you would need to be sufficiently surprised by the 'This is an unknown connection' warning to investigate further. To actually detect changed fingerprints, you need to keep a list of IPs for which you know the fingerprint. As the list of viable IPs is so small, there is no way to obfuscate it. The only possibility would be to encrypt it, but that requires keeping some secret from your attacker.
- tinus_hn 8y agoThe hashing is a defense in depth measure to avoid handing the attacker addresses to attack on a platter. So it does make sense to use a more modern hash so it takes more than a second to brute-force the whole address space but that's all you can do really. Most of these hosts are going to be in the same subnet anyway so a smart scan is never going to take long to retrieve most addresses.
- HorstG 8y agoI do consider HashKnownHosts harmful. Not only does it provide only the shallow appearance of security, as TFA shows. Also, as other commenters have argued, an attacker can often obtain the same info from syslog or shell history. But most problematic, I think, is that HashKnownHosts makes properly maintaining the known_hosts file tedious and error-prone. Its harder to remove hosts with known changed keys, and almost impossible to remove unneeded obsolete entries that have accumulated. Yet those old and obsolete keys could have been obtained by an attacker from recycled hardware or just by owning an old never-updated box. While this scenario might be unlikely, I would consider it just as unlikely that an attacker would find information only in known_hosts.