An introduction to AWS Inspector for EC2 vulnerability scanning

Introduction:

In this blog, I will show you how you can use AWS Inspector to scan your cloud resources, specifically EC2 instances, so that you have a high-level understanding of how AWS Inspector works and allow you to navigate comfortably. The other objective of this blog is to give you an understanding of vulnerability findings in your software and why they are important in security, specifically vulnerability management in your organization.

What is Amazon Inspector?

AWS Inspector is a vulnerability scanning service by AWS that is used to scan your EC2 instances, container images, and Lambda functions. Its findings will report vulnerabilities known as CVE’s (Common Vulnerabilities and Exposure) which are computer security flaws that are made public with the intention of bringing awareness and transparency.

What are CVE’s?

The US Government maintains a database of vulnerabilities with data such as risk score, product name, references, remediation and more. This database is known as the National Vulnerability Database(NVD) and is the source for many companies when trying to understand the impact of each vulnerability. Amazon Inspector uses the NVD score in many of its vulnerabilities.

A CVE naming convention will normally start with CVE followed by the year the vulnerability was discovered and then followed by a unique order number. Additionally, a profile of the vulnerability such as the severity, and in some cases how to “remediate” is updated frequently to keep users informed.

Scenario:

You are part of the Cybersecurity team and have been tasked to improve your security posture around your cloud virtual instances. You will need to run vulnerability scans around your environment and assess potential security risks around software packages used by your developers.

Main objectives you will learn from this exercise:

• Review high level implementation architecture for a single account
• You will learn how to enable Amazon Inspector
• Create a role for your EC2 instance that grants permissions to AWS Inspector via SSM
• Create an EC2 and confirm the agent is installed
• Attach the SSM agent role to the EC2 instance
• Review the scanned report in AWS Inspector and understand how to read it
• Login to your EC2 and patch using the recommendation found in the report
• Review the updated scanned report and confirm the fix

High level architecture diagram

At a high level, AWS Inspector is dependent on an agent to be installed in the EC2 instance that will be used to scan and report the security findings. Additionally, the EC2 will need a role that grants SSM to reach the EC2 instance. AWS Inspector uses the SSM agent to connect to the instance. Note that as of November of 2023, there is a new agentless scan option that is in preview but for this blog exercise we will cover the agent installation.

AWS Inspector can be supported at the organizational level and scan all accounts in the organization; however, the scope of this blog will be a single account.

How to enable Amazon Inspector

Login to your AWS account using your admin account or an account that has admin privileges to enable the service and navigate to Inspector. Once in Inspector, on the left side you will see “Switch to Inspector Classic” which is an older version of Inspector that has been replaced with Inspector v2. You will see the button to Activate Inspector, click on that button. If this is your first time enabling, you get a 15-day free trial.

Once in Inspector, you will see the Inspector dashboard with a summary view with a readout of Environment coverage, Critical findings, and Risk based remediations.

On the left side, you will see Findings with different breakdowns such as by vulnerability, by instance, etc. We will revisit these later after we create our EC2 and scan it.

Create a role for your EC2 instance that grants permissions to AWS Inspector via SSM

As mentioned earlier, AWS Inspector is dependent on an SSM role or a role with SSM permissions to be able to communicate with the SSM agent inside the EC2. Let’s create this role now using the SSM quick setup option.

Navigate to Systems Manager and click on Quick Setup on the left. Inside the QuickSetup configuration screen, click on Create button Host Management. This will create an IAM role configuration that will allow communication with EC2s. Additionally, this will also allow you to connect to EC2 using SSM.

This will take you to a Host Management screen where you will have configuration options to automatically manage agent updates and patch scanning. For now, accept the defaults and navigate to the bottom of the screen and click on Create.

If you have already enabled SSM prior, you may not need to do this step.

The following screen will be your Host management configuration dashboard showing the progress of the configuration. Once this completes, you should see a role named AmazonSSMRoleForInstanceQuickSetup. This is all that we need to continue.

Navigate to IAM console and confirm the role exists. If you click on the role, you will see this policy attached: AmazonSSMManagedInstanceCore. If you don’t have it, let’s go ahead and create one.

Navigate to IAM, click on Roles then click on the Create role button. You will be prompted to select an entity type, in our case select “AWS service”, and for service select EC2. This will create a trust policy that will allow EC2 to assume it.

Click Next

Now we must add permissions to the role that the EC2 will assume. Under the Add permissions config screen, search for AmazonSSMManagedInstanceCore, select it and click Next.

In the next window, give the role a name (EX. SSMRoleForInspectorScans) and click Create role.

You should now see your role created.

Create an EC2 and confirm the agent is installed

Let’s create an EC2 that we can use for our test.

Navigate to EC2, Click on Launch Instance to open the “Launch an instance” configuration screen. Give your instance a name and select Amazon Linux under the Quick Start options, then under the Amazon Machine Image (AMI) dropdown select Amazon Linux 2 AMI. This AMI will already have the SSM agent installed.

Under Key pair (login) create a new key pair which you will need to be able to use to login to your EC2 via the terminal.

Assign your key pair a name, select RSA key pair type, and select .pem or .ppk (to be used with PuTTY in windows). For my tutorial using my mac, I will use .pem and assign the name UserNormaKeyPair.

Click “Create key pair” which will automatically create a .pem file and download to your computer. Note your .pem location; in my case I accepted the downloads folder as default.

Select your new key pair from the dropdown.

Scroll to the bottom and click Launch instance. A success message should display along with an instance ID.

Next, click on the instance id to see your instance in the EC2 dashboard. You should see your instance with a status check of ‘initializing’. You can refresh until the status check reads ‘passed’.

Now let’s connect to the EC2 instance so that we can confirm the SSM agent exists.

Navigate to the EC2 instance (you might already be in this screen), select your new instance and click the Connect button at the top (it should not be greyed out anymore). This will open the Connect to instance screen, accept the defaults and click on Connect.

This will open a terminal on your browser and connect you directly to your instance.

At the command terminal type:

sudo systemctl status amazon-ssm-agent

You should see a confirmation that the agent is “active (running)”

If you used a different AMI that did not have the agent installed, you can follow the instructions to install the agent for your respective OS here: https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html

At this point, lets open the AWS Inspector tab and see what the dashboard shows us. Inside the dashboard “Instances” with a percentage that is hyperlinked. This shows the percentage of EC2 instances that are getting scanned against all instances. Click on the percentage link.

In my example, I only have one instance and it shows that the operating system is “UNKNOWN” and that status is “Unmanaged EC2 instance”. Why is this?

Attach the SSM agent role to the EC2 instance

The reason we do not see any scans is because we have not yet attached the IAM Instance Profile role that will allow AWS Inspector to talk to the SSM agent. Let’s go back to our EC2 console and attach the role.

Select your instance, click on Actions, then click Security, and then click on Modify IAM role.

Within the Modify IAM role screen, select the role you created earlier. In my case, I am selecting SSMRoleForInspectorScans. Click on Update IAM role.

Review the scanned report in AWS Inspector and understand how to read it.

At this point we can navigate back to AWS Inspector tab and refresh to see if our scan status has changed. Don’t be alarmed if you don’t see the status change right away as this could take several minutes depending on how far the next initial cron job kicks off new instance scans. An observation I made was that if I created the instance and attached the SSM role at the same time the initial Inspector scan kicked off right away, as confirmed below (I created a second EC2 instance as I typed this).

If you are eye-balling the status, you’ll see the Status change to “No inventory” and eventually to “Actively monitoring”.

Once your scans have completed, you can go back to your dashboard and navigate through the findings.

Under the Summary view you will see the percentage updated to reflect the number of instances being scanned by AWS Inspector (In my case I have two EC2’s being scanned). You can also see the critical findings for ECR, EC2, and Lambda functions. You also have a view for Risk based remediations which will show you how many instances are impacted by the same package.

Click on the “By vulnerability“ under Findings on the left-hand pane. This view will show you the vulnerabilities that were found as well as the rating of critical or high.

Please note that other severity ratings (medium, low, and informational) are still captured as findings, but they are a lower risk and don’t carry a header value. You can still see the severity rating, but you will have to click on the vulnerability link.

If you navigate to “By instance”, you will get a view of critical and high per instance.

Let’s click one instance and see our findings.

In this view, you can see Details about the instance we are looking at. Scroll to the bottom and you will see the different findings and their assigned severity. Here we see this instance has a total of 12 vulnerability findings: five high, five medium, and two low. Click on the first high severity to see details around the vulnerability. In my case, I am clicking on CVE-2024–0565.

On the right side, you will see a pane open that will provide details about this vulnerability, including the severity, the type, when it was created, the package affected as well as the recommended remediation. For this CVE, we can simply run a ‘yum update’ command to update our packages to the latest version available from our library repository.

If you click on the “Inspector score and vulnerability intelligence” tab on the right of this same pane view you will see a comparison of scores. The CVSS V3 score is the standard score that has been made public for the community. However, Amazon Inspector has its own logic that it applies to the CVSS score and lowers it if it finds that the vulnerability is not as high depending on factors such as network. That is to say, that a vulnerability that sits in a public facing network is less likely to be an issue in a private network. AWS Inspector accounts for these scenarios and labels the updated score as the Inspector score. In my case, there is no difference since I have deployed to a public subnet.

Let try to run the recommended ‘yum update’ command and see if we can fix some of these vulnerabilities. You will be surprised how many vulnerabilities get patched by simply updating you package libraries.

Login to your EC2 and patch using the recommendation found in the report

If you still have your console terminal open, type in ‘sudo yum update’ to collect all the latest updates and accept them all. If you are not logged in, then navigate to your session to continue. While the recommendation was to type ‘yum update kernel”’, I went ahead and typed ‘sudo yum update’ so that I could update all packages that were available (I prefixed with sudo as this is the command needed for root access).

In the packages to be updated response, you can see “kernel” is listed. I will type ‘y’ to accept all updates.

After the updates are completed, we can navigate back to AWS Inspector.

Review the updated scanned report and confirm the fix

AWS Inspector V2 is designed to scan your instances when a new instance is created, or when a package library is updated (as in our case), or when there is a new vulnerability identified and AWS Inspector has matched it as existing in your EC2 inventory from the initial scan.

Before our scan…

…and after our scan.

Here we see that the ‘yum update’ command only cleared two mediums. So, what happened?

If we recall the naming convention of our CVE, you will see that our first clue is the year. This CVE is named CVE-2024–0565. If we google the CVE Id and navigate to the NIST National Vulnerability Database, you will see more details.

Navigate here https://nvd.nist.gov/vuln/detail/CVE-2024-0565

The Quick Info section reads that this CVE was first published on 01/15/2024 (approximately six weeks ago from the time of this blog write up). This means this is still a fairly new CVE and may be fixed in the next kernel update (at least we hope).

If we look at the description it reads:

“An out-of-bounds memory read flaw was found in receive_encrypted_standard in fs/smb/client/smb2ops.c in the SMB Client sub-component in the Linux Kernel. This issue occurs due to integer underflow on the memcpy length, leading to a denial of service.”

This snippet tells us some information but not enough to gauge a risk. We can dive deeper by following the references link found in the NITS page for this CVE. We can see a hyperlink from redhat.com which will provide us more details.

https://access.redhat.com/security/cve/CVE-2024-0565

In the RedHat vendor link we see that RedHat reflects a score of 6.8, making this closer to a medium and not a high score. There is a message the vendor has added to explain the reasoning. If we read closely, we can see that the RedHat vendor states that the attack is complex and unlikely: “attack complexity high”.

This is pretty normal and is something that each company has to gauge to see how and if they are willing to live with this. Keep in mind, that had this been an older vulnerability, there would have likely already been a fix, especially for a well-recognized and used library package.

Let’s assume that as a Cybersecurity Engineer, you have reviewed this with you peers and have agreed that this is a low risk for your use case. In this case, AWS Inspector offers a feature that will allow you to suppress the findings so that you don’t see it, at least temporarily and skew your reports.

Create a suppression rule

Let’s go ahead and create a suppression rule for CVE-2024–0565. On your left pane, navigate to “Suppression Rules” and click on the Create suppression rule button.

This will open new window we can add a Suppression rule which will hide the CVE from the report. It does not eliminate or remove the issue from the instance, it only stops reporting it in the Vulnerability report until the Cybersecurity Engineer wants to bring it back in to confirm if it’s already been fixed by new yum updates.

Enter details for your rule to be suppressed and click on save. You will see the vulnerability id and the assigned instances that have it.

Once you click on save, you will see the Status updated to “Suppressed”.

You can always navigate to this screen to see your rules and associated resources that are carrying the suppressed vulnerability id.

We can confirm the suppression by navigating back to the Findings->Vulnerability view; we should not see our CVE id suppressed.

Conclusion

I hope you have found this useful. The intent was to give you an overview of AWS Inspector so that you can start playing around with it. It is very important that you understand how to configure the instance, role, and AWS Inspector console properly so that the scans can be executed.

While we did not cover the other areas of AWS Inspector such as Container Repositories and Lambda functions, you should have enough knowledge to understand how to navigate. Also, this blog would have been super long. Please note that AWS Inspector does not scan running containers at this point, but rather the images found in ECR. You can read more about this by reading the AWS Inspector user guide.