WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

ACM.99 Verifying that you are making an SSH connection to the host you think you are

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Network Security | AWS Security | Cybersecurity

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post we took a look at some reasons why you might not be able to connect to a VM On AWS. I explained public and private IPs and a bit about route tables.

While resolving issues with our connection, we got some warnings. This post is going to explain what those warnings mean and how they could be resolved.

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:

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%\.ssh\known_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:

1. 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.
2. You get this warning the first time you connect.
3. You log into the host and run the command and the signature matches the host you log into. Of course it does.
4. 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 keys for that connection exist on the AWS server and on your laptop, hopefully the attacker does not have access them so they can’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 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.

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 | © 2nd Sight Lab 2022

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab