Ask HN: Examples of real-world SSH MitM attacks?
6 comments
I don't think it's a very realistic attack vector, or more specifically, I think there are many more priorities over fingerprints, it's very low on the list of security priorities.
> not checking the fingerprint upon first use,
I don't know a single engineer, including security engineers, who does this.
> ignoring the "remote host identification has changed" warning,
This has helped me operationally when I wrongfully log in to a different machine than the one I was expecting. It's definitely useful to understand what it means. I think it is low on the list of security problems.
If I were interviewing someone for a security/admin position I would expect some level of: Don't allow passwords for ssh period, only key pair authentication. Control key forwarding behavior. Implement 2fac. Log everything to another machine.
If I were forced to write an SSH lab, it would be to show what happens when your key forwarding behavior is poorly configured.
I think time would probably be better spent teaching about `auditd` and then running a lab where you run a script on a machine that someone has set up logging for, and then they have to tell you what it did.
If you really want something man in the middle then superfish is probably one of the best real world examples and probably not all that horrible to re-create.
https://en.wikipedia.org/wiki/Superfish
Arp cache poisoning was an absolute classic back in the day.
I haven't really worked on security in a long time, so I'm probably out of date.
> not checking the fingerprint upon first use,
I don't know a single engineer, including security engineers, who does this.
> ignoring the "remote host identification has changed" warning,
This has helped me operationally when I wrongfully log in to a different machine than the one I was expecting. It's definitely useful to understand what it means. I think it is low on the list of security problems.
If I were interviewing someone for a security/admin position I would expect some level of: Don't allow passwords for ssh period, only key pair authentication. Control key forwarding behavior. Implement 2fac. Log everything to another machine.
If I were forced to write an SSH lab, it would be to show what happens when your key forwarding behavior is poorly configured.
I think time would probably be better spent teaching about `auditd` and then running a lab where you run a script on a machine that someone has set up logging for, and then they have to tell you what it did.
If you really want something man in the middle then superfish is probably one of the best real world examples and probably not all that horrible to re-create.
https://en.wikipedia.org/wiki/Superfish
Arp cache poisoning was an absolute classic back in the day.
I haven't really worked on security in a long time, so I'm probably out of date.
What certainly comes to mind is the recent leak of the Github SSH Host key where such a mishap opens the possibility of MITM attacks if no appropriate actions are taken.
Practical examples of common sense could be pipelines in gitlab where a ssh connection is started. In such situations, the easiest solution is to just ignore the fingerprint but of course if the gitlab server network environment is compromised, a MITM attack is very possible.
Practical examples of common sense could be pipelines in gitlab where a ssh connection is started. In such situations, the easiest solution is to just ignore the fingerprint but of course if the gitlab server network environment is compromised, a MITM attack is very possible.
Take a look at how Viasat inserts their "You need to pay us more money" redirects. Its technically not MitM but then again its technically not "internet connection" either.
Why not set this up yourself in a virtual lab and demonstrate the scenarios you just listed? Put two victim hosts on the network, and then with a third attacker host,
perform your MITM attack.
Thanks for suggestion! I did do several fire drills in the past, where I would change keys and wait for people to reach out. At the beginning of the semester, almost nobody would; by the end, over 80 % of the class would reach out prior to connecting to our shared infrastructure. But I thought that having a real-world smoking gun would be even better motivation to think about it. Sort of "don't be this poor guy" kind of thing. I've also been thinking about actually MitM-ing them myself, and probably will, but I am not sure how far I want to go :).
Maybe include one of the identify you by your public key widgets as well.
If you have a good story involving any kind of common sense violation when it comes to SSH fingerprints, would you please share it to motivate future colleagues to do better? Examples of common violations I see in practice: not checking the fingerprint upon first use, ignoring the "remote host identification has changed" warning, only checking a part of the fingerprint optically (instead of typing/pasting the fingerprint), etc.
Thanks!