Is your Cloud insecure?
You use AWS services. You use them for a company or for your personal projects. In all this excitement to use the AWS cloud you might have:
- allowed all developers to access many resources in your AWS account
- given yourself permanent keys and full admin access on your own account
- created an s3 bucket that is world-readable
- applied security processes from your on premise data center to your cloud resources
As work goes, commitments get made and projects have delivery dates. Engineering also needs prototypes and access to cloud services. The clock is ticking. Rushing things without a good security base can lead to some bad consequences.
What are these consequences? A quick search of the internet can lead to answers.
- Exposed Data: Simply leaving a S3 bucket open to the world can be very damaging to customers because their data is exposed and cause irreparable damage to a company’s reputation. e.g. Accenture, Verizon, Time Warner Cable
- Exposed Service: An open port on a security group could leave MySQL or MongoDB and the data inside open to attack. Shodan even provides a search engine for services exposed to the Internet!
- Account Breach: Leaking credentials for the AWS root or IAM user can result in complete loss of control of the account (and a death-knell for your business) or large bills.
At this point you might be thinking that you really do not know the security status of your account. With so many resources in use, it is possible that something has been left unsecured. Admittedly, I have thought about this with regard to my personal account that I use for learning and prototyping. I have tested many ideas over the last few years, and I have on occasion failed to clean up after myself.
Well the good news is that tools have already been made to help you understand the security of your AWS account. One such open source tool is called Scout2 created by NCCGroup.
What Is Scout2
Scout2 is written in Python, runs with versions 2.7 and 3.3 through 3.6, and requires the AWS python library boto3. Scout2 is licensed under GPL v2.0, is freely available, and has an active set of contributors. As of this writing, Scout2 collects information on the following critical AWS services and displays issues in a locally generated HTML report with dashboards that allow you to drill down to the details:
|
|
|
Installing Scout2
This can be easily installed using pip because the NCCGroup uploaded the application package to PyPI. Make sure you have the supported versions of Python on your local machine and pip with it. Then just run:
| pip install awsscout2 |
It is worth recommending that the pip install be done in a Python virtual environment. Doing so will prevent your install of required 3rd party libraries from causing any conflicts with versions of libraries at the system level.
Running Scout2
After installing Scout2, you will need to make sure you have some AWS credentials (keys/tokens) that allow read only access to the AWS services that Scout2 will be checking. 
This access policy will need to be granted to the user or role that will be running Scout2. The NCCGroup gives a good default policy to use called the Scout2-Default IAM policy. This policy gives the default access necessary and can be cut and pasted into a policy in your AWS account. Another option is to assign the default AWS Managed Policy called ReadOnlyAccess to the user or role that is running Scout2. This policy gives more read only access than is needed to run Scout2, but it does not require you to create a new policy for Scout2. As always, please review the access policy you use to make sure it is appropriate for your use case.
With the install and AWS credentials properly completed, the executing of Scout2 is as simple as typing “Scout2”. There are some options that can be entered when running Scout2 and it would be worth looking at these. The full list is shown below and can be actively seen by typing “Scout2 –help”.
(demo-scout2) ~/Scout2]$ Scout2 --help
usage: Scout2 [-h] [--debug] [--force] [--profile PROFILE [PROFILE ...]]
[--regions REGIONS [REGIONS ...]] [--vpc VPC [VPC ...]]
[--ip-ranges IP_RANGES [IP_RANGES ...]]
[--ip-ranges-name-key IP_RANGES_NAME_KEY]
[--mfa-serial MFA_SERIAL] [--mfa-code MFA_CODE]
[--csv-credentials CSV_CREDENTIALS] [--report-dir REPORT_DIR]
[--timestamp [TIMESTAMP]]
[--exceptions EXCEPTIONS [EXCEPTIONS ...]]
[--services SERVICES [SERVICES ...]]
[--skip SKIPPED_SERVICES [SKIPPED_SERVICES ...]] [-l] [--resume]
[--update] [--ruleset [RULESET]] [--no-browser]
[--thread-config THREAD_CONFIG]
Options definitely worth considering are
- profile: use credentials for a specific AWS profile
- regions: assess a specific region instead of the default for all regions
- mfa-serial: allows use of credentials that require MFA
- no-browser: skip opening the browser after completing a run
- report-dir: path to generate the Scout2 HTML report into
An example of using these options is below:
| scout2 ––profile mytestprofile ––regions us-west-2 ––no-browser |
This will run Scout2 using the AWS credentials stored in “mytestprofile” and only run it against resources in “us-west-2”. Upon completion it will not open the report in a browser.
Output from Scout2
Upon completion, Scout2 will generate an HTML report that is automatically opened in your default browser unless you specify the --no-browser option. This report contains HTML, javascript and CSS. By default the reporting assets will go into the local directory under a folder called ‘scout2-report’. Inside the /scout2-report directory will be the main file, report.html, along with folders for supporting data and formatting. The path to this file can be put in a browser to view the report.
Opening the “report.html” file in a browser will display a web page that looks like Table 1 shown below. This is the main Scout2 dashboard, and it summarizes Scout2’s detections across the services it is evaluating.
Table 1: High level Scout2 Report Summary “report.html”
This easy to view dashboard contains good information and colors that help you quickly see concerns. The report is color coded such that Green = Good, Yellow = Warning and Red = Bad. It shows the number of resources evaluated for the service, of rules applied, and of findings and checks completes. Another great part about this dashboard view is that you can drill down into any of the services and get more information. For example, let’s dig into IAM (Identity and Access Management) since it shows as red.
Clicking on S3 will quickly display the Table 2 below.
Table 2: Drill Down to S3 Dashboard
Table 2 is just another easy to view dashboard with the status colors and information. However, this time the view is specific to the service into which you drilled down. The information shown is going to be specific to the checks done on the items of that service.
In this example, we have drilled down into the S3 service. S3 is a heavily used AWS service because it makes data storage easy, is highly scalable, and is reliable with low-latency. People who begin to use the service more frequently end up creating lots of buckets. These people are often in a rush to give others access to the bucket, permissions get opened up, and those permissions never get tightened down. This can cause a lot of problems if that bucket starts to hold important information like account keys and passwords or customer data.
As can be seen in Table 2, we have one red warning and some issues. Issues and warnings might be something we want more information about and since this is a dashboard, we can once again, click on the item and drill down. In this case, we are clicking on the red item called “bucket world-writable (anonymous)”. This sounds a bit dangerous to have anonymous world writable.
Table 3: Drill Down to “Bucket world-writable (anonymous)” Dashboard
This identified one bucket called “init-app-information” that is allowing “Everyone” to “List” and “Upload/Delete” items from the bucket. This information is very helpful in determining whether you intentionally set these permissions. If you did not mean for this bucket to be open to the world for writing, you should immediately go the AWS console and adjust the bucket permissions to be appropriate.
Note: The IAM Dashboard identified another issue that some buckets that were “Buckets world-listable (anonymous)”. Scout2 checks and identifies the read and write as separate issues. World-listable is also another drill down in the S3 dashboard that should be checked.
Summary
Scout2 is an open source tool that you run against your AWS account(s) to assess on the security status of your AWS resources. The tool is in active development and supported by NCCGroup. Scout2’s output is easy to view and traverse since every page uses colors to highlight issues and most pages are dashboards you can drill down into. In this example, we only drill down into S3 to show one critical issue. When you analyze your accounts, drill down into any of the critical or warning issues to understand the issue and begin mitigating the associated risk.
Scout2 also has additional features not covered in this post. Stay tuned for the next post on how to create a custom ruleset in Scout2 or to read ahead, you can go to the official Scout2 documentation.
