Skip to main content
All about AWS Inspector-2 for EC2 and how to intentionally generate Inspector-2 findings
27 Jul 2023

All about AWS Inspector-2 for EC2 and how to intentionally generate Inspector-2 findings

Worried about vulnerabilities lurking in your EC2 instances? Fear not! This blog dives deep into AWS Inspector 2, a powerful tool for continuously scanning your EC2 environment, helping you identify and address security risks proactively. Learn how Inspector 2 works, the types of findings it generates, and even how to intentionally trigger findings for testing purposes!

What is AWS Inspector – an introduction

In the ever-growing threat landscape, ensuring the security of data within an organization's AWS (Amazon Web Services) environment is crucial. Amazon offers various security services to bolster protection. Among them is the Amazon Inspector service. This service plays a significant role in continuously scanning resources within AWS for package vulnerabilities and network exposure. By identifying vulnerabilities introduced by software packages, Inspector enables proactive measures to develop applications with adherence to best practices and policies. When a vulnerability or network exposure is detected, Inspector generates an event, commonly referred to as a finding, containing all pertinent information about the affected resources and the remediation required. The service supports scanning for EC2, ECR, and Lambda function resources. For pricing details, refer to the AWS Inspector Pricing page.

Types of findings:

Two major types of findings are supported by the Inspector:

  • Package Vulnerability
  • Network Reachability 

Finding 1 - Package Vulnerability:

  • This type of findings identify software packages in your AWS environment that are exposed to Common Vulnerabilities and Exposures (CVEs). 
  • EC2 are virtual machines in AWS environments on which a user can install different software packages, helper libraries,etc and it can also have existing support files. 
  • The Inspector helps in scanning these packages and find out if there are any vulnerabilities in versions of packages that are installed or the way that software is configured etc.
Prerequisites: 
  • For an inspector to scan your EC2 instance for vulnerabilities, it is mandatory that the system manager manages the EC2 instance. 
  • Another prerequisite is you need to enable the Inspector. Follow this document to enable Inspector - Activate Amazon Inspector.
How to check if a system manager manages an EC2 instance?
  • Go to the System manager console in AWS account - https://us-east-1.console.aws.amazon.com/systems-manager 
  • Do a quick setup if not done already 
  • Go to Node management > Inventory 
  • On the inventory page, you will see a list of EC2s managed by the system manager. Verify if your EC2 is on the list.

Easiest way to enable system manager for EC2
  1. Go to the IAM manager in the AWS account -  
  2. Click on Role > Create role  
  3. Select trusted entity type as AWS service and common use cases as EC2  
  4. Click on next  
  5. Select policies - AmazonEC2RoleforSSM and AmazonSSMFullAccess 
  6. Click on next > enter roles name > click on create role 
  7. Once the role is created, go to EC2, for which you want to enable the system manager 
  8. Click on actions > Security > Modify IAM role 
  9. Select the IAM role created in step number 6 and attach it to EC2 
  10. Once the role is updated. Verify EC2 in the inventory list of the system manager.

How to verify if your EC2 is getting scanned by an inspector?  

  1. Open Amazon Inspector  
  2. Go to Account management > click on the instances tab 
  3. You will see a section named 'Scanning'; it shows the EC2s that are getting scanned. Verify your EC2 in the list.

How to intentionally generate package vulnerability events in Inspector?

After creating EC2 instance with Ubuntu Server 22.04 AMI/Ubuntu Server 20, this AMI will by default generate some medium and low severity package vulnerabilities based on default package installation during launch of EC2 such as CVE-2022-40897 - python3-setuptools,CVE-2023-22809 - sudo, CVE-2022-33070 - sudo, CVE-2022-41903 - git,CVE-2022-23521 - git,CVE-2022-42898 - libgssapi-krb5-2,CVE-2018-20217 - libgssapi-krb5-2.  (ensure the IAM role with required SSM policies is attached while creating EC2 ).

You can also intentionally install software packages with vulnerabilities to create package vulnerability findings.

Install the below mentioned packages on Ubuntu Server 20.04 EC2 to generate the respective finding.

1. Libopenexr24

To generate finding, run the below commands -  
     sudo apt update 
     sudo apt-get install libopenexr24 2.3.0 
           
This will generate the below finding -  
     Low Severity -  
     CVE-2021-3598 - libopenexr24 
     CVE-2021-3941 - libopenexr24 
     CVE-2021-23215 - libopenexr24 
     CVE-2021-20296 - libopenexr24 
     CVE-2021-26260 - libopenexr24 
 
     Medium Severity - 
     CVE-2021-3605 - libopenexr24 
     CVE-2021-3933 - libopenexr24

2. Liblog4j2-java

To generate the findings, run below commands -  
     sudo apt install liblog4j2-java=2.11.2-1 
 
This will generate the below finding - 
     Medium Severity -  
     CVE-2021-44832 - liblog4j2-java 
     CVE-2021-45105 - liblog4j2-java 
 
     High Severity- 
     CVE-2021-45046 - liblog4j2-java 
     CVE-2021-44228 - liblog4j2-java

How to resolve these findings to keep your EC2 secure?

The findings indicate which package has introduced the vulnerability. To resolve this, you need to either remove or install the latest version of that package on your EC2. AWS also provides a remediation link for some of the findings, and you can also go and check the suggestions provided by AWS.  
Once the finding is resolved, its status will be changed to closed, and you can check these findings under closed issues.

Finding 2 - Network Reachability:

  • Another type of finding that the Inspector supports is network reachability. This finding is generated when a possible network path is available to your EC2. 
  • The external world can misuse this path, and your EC2 can get compromised. 
  • Network reachability findings are generated only for EC2 instances. The Inspector scans for Network Reachability issues every 24 hours. Regardless of SSM agent status, all of your EC2 instances will be scanned for network exposure issues.
 
Prerequisites:

The only Prerequisite required for an inspector to catch network reachability issues is that you need to enable the Inspector. Follow this document to enable Inspector - Activate Amazon Inspector

How to intentionally generate network reachability for EC2?
  • These findings appear when your TCP and UDP ports are reachable from an internet gateway, a VPC peering connection, or a VPN through a virtual gateway. 
  • There are several ways to generate these findings, but in this blog, I will talk about the simplest way to generate network reachability findings, and that is making TCP/UDP ports of your EC2 open to the internet gateway.  
  • Below are the details about some network reachability findings and how to generate them.
Port 22 is reachable from an Internet Gateway

To generate this finding, follow these steps: 

  1. Go to EC2 for which you want to generate this finding  
  2. Click on security > click on security group > edit inbound rules 
  3. Add rule > select type as SSH that is port range would be 22 
  4. Set source as anywhere IPV4 
  5. Click on Save rules

  • After the steps mentioned above, port 22 on your ec2 will be reachable from the internet gateway, generating medium severity network reachability finding for port 22. 
  • You can check open network paths in details of generate finding in the AWS inspector.

Similar to port 22 ne within AWS, there is a wide array of security services available to assist you in attaining the utmost level of security for your environment, with the Amazon Inspector service being just one among them. Findings for below-mentioned ports, having different severity, can also be generated by following the same steps.

Service TCP ports UDP ports Internet path rating
DHCP 67, 68, 546, 547 67, 68, 546, 547

Medium

Elasticsearch 9300, 9200 NA Medium
FTP 21 21 High
Global catalog LDAP 3268 NA Medium
Global catalog LDAP over TLS 3269 NA Medium
HTTP 80 80 Low
HTTPS 443 443 Low
Kerberos 88, 464, 543, 544, 749, 751 88, 464, 749, 750, 751, 752 Medium
LDAP 389 389 Medium
LDAP over TLS 636 NA Medium
MongoDB 27017, 27018, 27019, 28017 NA Medium
MySQL 3306 NA Medium
NetBIOS 137, 139 137, 138 Medium
NFS 111, 2049, 4045, 1110 111, 2049, 4045, 1110 Medium
Oracle 1521, 1630 NA Medium
PostgreSQL 5432 NA Medium
Print services 515 NA High
RDP 3389 3389 Medium
RPC 111, 135, 530 111, 135, 530 Medium
SMB 445 445 Medium
SSH 22 22 Medium
SQL Server 1433 1434 Medium
Syslog 601 514 Medium
Telnet 23 23 High
WINS 1512, 42 1512, 42 Medium
How to resolve these findings?

The findings I explained above indicate that your ports are open to internet gateways, so to resolve this, you can either delete the inbound rule added for that port in the security group of your EC2 or assign a valid resource IP address to it. AWS also provides a remediation link for some of the findings. You can also go and check the suggestions provided by AWS. 
Once the finding is resolved, its status will be changed to closed, and you can check these findings under closed issues.

In my upcoming blogs, I'll write about other security services AWS provides, such as the security hub, Amazon access analyzer, and Guard duty. 

Subscribe to our feed

select webform