3 ms·

How would one stage a MITM attack without knowing the private key corresponding to the old key?

by dheera 4y ago

edp 4y ago
The fact that users have to delete the old Github key from their systems and accept a new one is what could lead to a MITM attack. If your system doesn't know the public key of an SSH server, when you connect the first time, the SSH client will display a warning and ask you if you accept the server key. An attacker could be between you and Github and if you accept without checking it's the correct key, you would be toast.
- pbhjpbhj 4y ago
  Would it be more secure to access a https secured server to get the keyfile then?
  - tialaramex 4y ago
    Yes, GitHub's announcement provides the correct new public RSA key, and it also provides instructions for a curl invocation which does all the work if you don't trust yourself to copy-paste text or don't understand how.
  - dheera 4y ago
    Only if the https server cert wasn't compromised at the same time as the ssh key. For all we know, this entire announcement of "we have a new key" could be staged.
stouset 4y ago
They don’t need it. Millions of users are going to blindly trust the “new” GitHub public SSH key they see the next time they connect without checking to see if it matches the published signature.
p-e-w 4y ago
By pretending to be the host that the user is trying to connect to. You can then present the client with a key you generated yourself. Of course, SSH will warn the user that the fingerprint has changed, but they'll just think "Ah yes, GitHub changed their keys so it's probably fine." This is why updating the key creates a potential MITM risk, unless people actually bother to verify that the fingerprint is correct.
- cogogo 4y ago
  What specifically can you verify that cannot also be spoofed? If I go do this now I (and I’m sure millions of others) have no idea what to look for. I’d be blindly accepting like a sheep if it weren’t for this thread. edit: I found this helpful and honestly had no idea I should be doing this (I’m a hobbiest not a professional) https://bitlaunch.io/blog/how-to-check-your-ssh-key-fingerprint/ https://bitlaunch.io/blog/how-to-check-your-ssh-key-fingerpr...
ZiiS 4y ago
if you run a MITM attack today the victim gets the warning in the blog post. Thier most likly action is to google the blog post and see it is expected and and so accept your fake key. Having said that I dont see what choice Github had, they can't continue to use a leeked key.
- ddtaylor 4y ago
  Their solution is the second thing in the blog post which is demand into your known host file. The problem here is that their first command that they advise using is the one that removes the old key and most users are just going to stop right there because it solves the problem of getting the key warning. The right solution here is to provide a command that most users are going to copy and paste that deletes the old key and adds the new key all at once.
Karliss 4y ago
The key has changed, meaning that every user has to accept a new key. Meaning that a lot of users will blindly accept whatever new key (even when it might be the one owened by attacker doing MITM) because Github, their college or random person on internet said that that's what you have to do to get rid of error.
- iso1631 4y ago
  Fortunately this will become evident once they connect from elsewhere and the key changes again
  - macintux 4y ago
    Not strongly evident. I suspect most users would assume they did something wrong, or that GitHub was still making changes.
- tialaramex 4y ago
  > Meaning that a lot of users will blindly accept whatever new key (even when it might be the one owened by attacker doing MITM) This is less likely because unlike for TOFU the SSH client just rejects the mismatch and insists you take manual action, and the likely manual action will be "Paste this stuff from the announcement". So an adversary needs to either subvert whatever messaging you see (which is tricky, likely impossible for a random user visiting the github web site wondering what's wrong) or hope that you just try to muddle along and do TOFU again, putting you in the same spot as a whole bunch of users every day at GitHub.

How would one stage a MITM attack without knowing the private key corresponding to the old key?

by dheera 4y ago

How would one stage a MITM attack without knowing the private key corresponding to the old key?

edp 4y ago

The fact that users have to delete the old Github key from their systems and accept a new one is what could lead to a MITM attack. If your system doesn't know the public key of an SSH server, when you connect the first time, the SSH client will display a warning and ask you if you accept the server key. An attacker could be between you and Github and if you accept without checking it's the correct key, you would be toast.

pbhjpbhj 4y ago
Would it be more secure to access a https secured server to get the keyfile then?
- tialaramex 4y ago
  Yes, GitHub's announcement provides the correct new public RSA key, and it also provides instructions for a curl invocation which does all the work if you don't trust yourself to copy-paste text or don't understand how.
- dheera 4y ago
  Only if the https server cert wasn't compromised at the same time as the ssh key. For all we know, this entire announcement of "we have a new key" could be staged.

stouset 4y ago

They don’t need it. Millions of users are going to blindly trust the “new” GitHub public SSH key they see the next time they connect without checking to see if it matches the published signature.

p-e-w 4y ago

By pretending to be the host that the user is trying to connect to. You can then present the client with a key you generated yourself. Of course, SSH will warn the user that the fingerprint has changed, but they'll just think "Ah yes, GitHub changed their keys so it's probably fine." This is why updating the key creates a potential MITM risk, unless people actually bother to verify that the fingerprint is correct.

cogogo 4y ago
What specifically can you verify that cannot also be spoofed? If I go do this now I (and I’m sure millions of others) have no idea what to look for. I’d be blindly accepting like a sheep if it weren’t for this thread. edit: I found this helpful and honestly had no idea I should be doing this (I’m a hobbiest not a professional) https://bitlaunch.io/blog/how-to-check-your-ssh-key-fingerprint/ https://bitlaunch.io/blog/how-to-check-your-ssh-key-fingerpr...

ZiiS 4y ago

if you run a MITM attack today the victim gets the warning in the blog post. Thier most likly action is to google the blog post and see it is expected and and so accept your fake key. Having said that I dont see what choice Github had, they can't continue to use a leeked key.

ddtaylor 4y ago
Their solution is the second thing in the blog post which is demand into your known host file. The problem here is that their first command that they advise using is the one that removes the old key and most users are just going to stop right there because it solves the problem of getting the key warning. The right solution here is to provide a command that most users are going to copy and paste that deletes the old key and adds the new key all at once.

Karliss 4y ago

The key has changed, meaning that every user has to accept a new key. Meaning that a lot of users will blindly accept whatever new key (even when it might be the one owened by attacker doing MITM) because Github, their college or random person on internet said that that's what you have to do to get rid of error.

iso1631 4y ago
Fortunately this will become evident once they connect from elsewhere and the key changes again
- macintux 4y ago
  Not strongly evident. I suspect most users would assume they did something wrong, or that GitHub was still making changes.
tialaramex 4y ago
> Meaning that a lot of users will blindly accept whatever new key (even when it might be the one owened by attacker doing MITM) This is less likely because unlike for TOFU the SSH client just rejects the mismatch and insists you take manual action, and the likely manual action will be "Paste this stuff from the announcement". So an adversary needs to either subvert whatever messaging you see (which is tricky, likely impossible for a random user visiting the github web site wondering what's wrong) or hope that you just try to muddle along and do TOFU again, putting you in the same spot as a whole bunch of users every day at GitHub.