ACM.99 Verifying that you’re making an SSH connection to the host you suppose you might be
This can be a continuation of my sequence of posts on Automating Cybersecurity Metrics.
Have you ever ever been logging into an host and seen this error message and questioned what it meant?
Or possibly this one?
There are a lot of good posts o this subject so I’m not going to utterly re-write them. Right here’s one:
However what does all that imply precisely?
For the primary error message, WARNING: HOST IDENTIFICATION HAS CHANGED!, signifies that the host related to the IP handle that you’re making an attempt to hook up with with SSH has modified. If it had been a bodily server, consider it as somebody unplugging one server and swapping it with one other that responds to the identical IP handle. Within the bodily world that may be very unusual certainly. In a cloud setting, this will occur quite a bit, and it does as we make modifications to the EC2 occasion we’re deploying on this weblog sequence.
To be able to log into the host after it modifications it’s a must to delete the known_hosts file, which is often at ~/.ssh/known_hosts on a Mac or Linux system. On Home windows it may be at: %USERPROFILE%.sshknown_hosts. When you delete that folder there are not any extra associations of distant hosts to particular SHA signatures.
The primary time you log into a bunch, or after you delete your known_hosts file, the host doesn’t exist within the known_hosts file anymore. The host is unknown. Your laptop is aware of nothing about that host. It has no method to confirm if it’s the right host or not. Subsequently it pops up the second warning: The authenticity of host ‘xyz’ can’t be established.
Now, if you happen to learn the article above, you may run some instructions on the host to get a signature to match to the one you get whenever you first login. However let’s take into consideration this a minute. If we login to the fallacious host then we’ll get the signature that matches it doesn’t matter what if we run that command whereas logged into the host we try to confirm.
What could be nice is that if AWS would run these instructions after which publish them within the AWS console after which you possibly can confirm that means. Presumably AWS would be capable of securely generate that code and show it within the console.
Let’s stroll by how that may assist in an assault state of affairs:
- An attacker tips you into logging into their host after which proxies all of your instructions to AWS and again so you haven’t any concept what’s occurring.
- You get this warning the primary time you join.
- You log into the host and run the command and the signature matches the host you log into. After all it does.
- Now let’s say that AWS revealed a signature within the console for the host on the time they launched it. In that case neither the signature that popped up on this error or the one on the proxy host would match.
What makes it difficult for the attacker is that you just downloaded a key from AWS. They would wish to have the ability to make your connection work together with your AWS key to their host. Properly, for the reason that personal key for that connection is on the AWS server and hopefully the attacker doesn’t have entry they couldn’t do a man-in-the-middle in your connection to the AWS server.
However what if there was a rogue insider at AWS who by some means might get the personal key on the AWS system and arrange this type of proxy the place you hook up with their machine after which over to the right EC2 occasion? In that case they might additionally need to get into no matter community units route site visitors round to get your machine to hook up with the general public IP revealed within the AWS console however that’s, out of your community and the units between you and it, pointed on the attacker’s machine as a substitute of the AWS VM.
How would you understand if that is occurring? The attacker could be proxying all of the requests over to AWS. In the event you look in cloud path or any IAM logs, you’ll see all the suitable info, as a result of the identical requests you made would find yourself on AWS.
Probably you possibly can inform based mostly on the IP handle that’s making the requests. Except the attacker can spoof your IP handle at your location within the AWS logs, it’s going to come back by with their IP handle on their proxy system as a substitute of the system the place you might be initiating the request.
How else can we strive to ensure we’re on the right machine? In the event you run varied requests to the AWS metadata you would possibly be capable of see info that doesn’t match what you’ll count on out of your EC2 occasion based mostly on what’s within the AWS Console. The attacker would have to ensure the metadata returns precisely the fitting info matching all the information within the AWS console for that occasion. An insider at AWS might most likely do it if that they had entry in and data to all of that, however I count on it might nonetheless be exhausting to drag off with the controls AWS had in place.
I’ll most likely write extra concerning the AWS metadata service later, in case you are not conversant in it.
I haven’t totally thought by this state of affairs or dug into each element, nevertheless it looks as if a easy means to assist us out on this case could be for AWS to place the signature of the system that matches the error message above within the AWS console on the tab with the occasion particulars. Then earlier than you settle for the knowledge and join, you possibly can examine the signature within the console to ensure it matches.
Maybe you possibly can even pull the knowledge off AWS so as to add to your machine earlier than you join so that you by no means see the error within the first place. If customers weren’t allowed to make use of the AWS console an administrator might present them the knowledge prematurely of utilizing SSH to make sure they will join with out getting that error message.
Just a few concepts…however I really wish to get to an precise operating batch job in some unspecified time in the future so I’m not going to spend extra time on this proper now.
Comply with for updates.
Teri Radichel
In the event you favored this story please clap and comply with:
Medium: Teri Radichel or Electronic mail Record: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests companies through LinkedIn: Teri Radichel or IANS Analysis
© 2nd Sight Lab 2022
All of the posts on this sequence:
____________________________________________
Creator:
Cybersecurity for Executives within the Age of Cloud on Amazon
Want Cloud Safety Coaching? 2nd Sight Lab Cloud Safety Coaching
Is your cloud safe? Rent 2nd Sight Lab for a penetration take a look at or safety evaluation.
Have a Cybersecurity or Cloud Safety Query? Ask Teri Radichel by scheduling a name with IANS Analysis.
Cybersecurity & Cloud Safety Assets by Teri Radichel: Cybersecurity and Cloud safety lessons, articles, white papers, shows, and podcasts
