ACM.99 Verifying that you are making an SSH connection to the host you think you are
This is a continuation of my series of posts on Automating Cybersecurity Metrics.
Have you ever been logging into an host and seen this error message and wondered what it meant?
Or maybe this one?
There are many good posts o this topic so I’m not going to completely re-write them. Here’s one:
Verifying the Authenticity of Remote Host (SSH Key Fingerprint)
But what does all that mean exactly?
For the first error message, WARNING: HOST IDENTIFICATION HAS CHANGED!, means that the host associated with the IP address that you are attempting to connect to with SSH has changed. If it were a physical server, think of it as someone unplugging one server and swapping it with another that responds to the same IP address. In the physical world that would be very strange indeed. In a cloud environment, this can happen a lot, and it does as we make changes to the EC2 instance we are deploying in this blog series.
In order to log into the host after it changes you have to delete the known_hosts file, which is typically at ~/.ssh/known_hosts on a Mac or Linux system. On Windows it might be at: %USERPROFILE%.sshknown_hosts. Once you delete that folder there are no more associations of remote hosts to specific SHA signatures.
The first time you log into a host, or after you delete your known_hosts file, the host does not exist in the known_hosts file anymore. The host is unknown. Your computer knows nothing about that host. It has no way to verify if it is the correct host or not. Therefore it pops up the second warning: The authenticity of host ‘xyz’ cannot be established.
Now, if you read the article above, you can run some commands on the host to get a signature to compare to the one you get when you first login. But let’s think about this a minute. If we login to the wrong host then we will get the signature that matches no matter what if we run that command while logged into the host we are trying to verify.
What would be great is if AWS would run those commands and then publish them in the AWS console and then you could verify that way. Presumably AWS would be able to securely generate that code and display it in the console.
Let’s walk through how that might help in an attack scenario:
An attacker tricks you into logging into their host and then proxies all your commands to AWS and back so you have no idea what’s happening.You get this warning the first time you connect.You log into the host and run the command and the signature matches the host you log into. Of course it does.Now let’s say that AWS published a signature in the console for the host at the time they launched it. In that case neither the signature that popped up in this error or the one on the proxy host would match.
What makes it challenging for the attacker is that you downloaded a key from AWS. They would need to be able to make your connection work with your AWS key to their host. Well, since the private key for that connection is on the AWS server and hopefully the attacker does not have access they couldn’t do a man-in-the-middle on your connection to the AWS server.
But what if there was a rogue insider at AWS who somehow could get the private key on the AWS system and set up this sort of proxy where you connect to their machine and then over to the correct EC2 instance? In that case they would also have to get into whatever network devices route traffic around to get your machine to connect to the public IP published in the AWS console but that is, from your network and the devices between you and it, pointed at the attacker’s machine instead of the AWS VM.
How would you know if this is happening? The attacker would be proxying all the requests over to AWS. If you look in cloud trail or any IAM logs, you would see all the appropriate information, because the same requests you made would end up on AWS.
Likely you could tell based on the IP address that is making the requests. Unless the attacker can spoof your IP address at your location in the AWS logs, it’s going to come through with their IP address on their proxy device instead of the device where you are initiating the request.
How else can we try to make sure we are on the correct machine? If you run various requests to the AWS metadata you might be able to see information that doesn’t match what you would expect from your EC2 instance based on what is in the AWS Console. The attacker would have to make sure the metadata returns exactly the right information matching all the data in the AWS console for that instance. An insider at AWS could probably do it if they had access in and information to all of that, but I expect it would still be hard to pull off with the controls AWS had in place.
Instance metadata and user data
I’ll probably write more about the AWS metadata service later, if you are not familiar with it.
I haven’t fully thought through this scenario or dug into every detail, but it seems like a simple way to help us out in this case would be for AWS to put the signature of the device that matches the error message above in the AWS console on the tab with the instance details. Then before you accept the information and connect, you could check the signature in the console to make sure it matches.
Perhaps you could even pull the information off AWS to add to your machine before you connect so you never see the error in the first place. If users were not allowed to use the AWS console an administrator could provide them the information in advance of using SSH to ensure they can connect without getting that error message.
Just some ideas…but I actually want to get to an actual running batch job at some point so I’m not going to spend more time on this right now.
Follow for updates.
Teri Radichel
If you liked this story please clap and follow:
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2022
All the posts in this series:
Automating Cybersecurity Metrics (ACM)
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
