Pentesting Amazon Web Services with KALI Sana

The installation through the AWS EC2 interface is dead simple. Point, click. Cutting keys and firing up ssh is also easy. But before you get too comfortable, there’s a few things you should know.

First, unlike every preceding version of BackTrack and Kali, you do not just log in as root and leave it there. In order to meet the Amazon terms of service, you must log in as a lower-level user (in this case, user “kali”) and then su to root:

    $ sudo su
    # <-- and you are root!

Note no password is required. You should consider running ‘passwd’ to ensure your instance requires one. No one will ever, ever guess ‘toor’. You’re welcome.

Second, you should also know this is a “barebones” install. I couldn’t find what the “barebones” term meant anywhere on the kali.org website or support forums. Well it actually means “The Kali Amazon image is what we call a ‘minimal image’, meaning, no tools pre-installed. You can install any tools you need individually, or install them all with the kali-linux metapackage.”

This would explain why I couldn’t even begin to fire up Metasploit:

    # service postgresql start
    postgresql: unrecognized service

So while “barebones” means a virtual machine instance can be spun up in seconds, you still have to do a bunch of updating before you can actually do anything. You have a choice of git or apt-get. I used the latter:

    #apt-get install kali-linux-full

Now go do something else as it will be a while before you’re in business. At least an hour. Just remember to comply with the Amazon Terms of Service for Penetration Testing before doing anything they may consider uncivilized.



Following is the policy which you must abide by while pentesting AWS nodes:
AWS's Policy Regarding the Use of Security Assessment Tools and Services

AWS's policy regarding the use of security assessment tools and services allows significant flexibility for performing security assessments of your AWS assets while protecting other AWS customers and ensuring quality-of-service across AWS.

AWS understands there are a variety of public, private, commercial, and/or open-source tools and services to choose from for the purposes of performing a security assessment of your AWS assets.

The term "security assessment" refers to all activity engaged in for the purposes of determining the efficacy or existence of security controls amongst your AWS assets, eg. port-scanning, vulnerability scanning/checks, penetration testing, exploitation, web application scanning, as well as any injection, forgery, or fuzzing activity, either performed remotely against your AWS assets, amongst/between your AWS assets, or locally within the virtualized assets themselves.

You are NOT limited in your selection of tools or services to perform a security assessment of your AWS assets. However, you ARE prohibited from utilizing any tools or services in a manner that perform Denial-of-Service (DoS) attacks, or simulations of such, to or from ANY AWS asset, yours or otherwise. Prohibited activities include, but may not be limited to:

- Protocol flooding (eg. SYN flooding, IMCP flooding, UDP flooding)

- Resource request flooding (eg. HTTP request flooding, Login request flooding, API request flooding)

A security tool that solely performs a remote query of your AWS asset to determine a software name and version, such as "banner grabbing," for the purpose of comparison to a list of versions known to be vulnerable to DoS, is NOT in violation of this policy.

Additionally, a security tool or service that solely crashes a running process on your AWS asset, temporary or otherwise, as necessary for remote or local exploitation as part of the security assessment, is NOT in violation of this policy. However, this tool may NOT engage in protocol flooding or resource request flooding, as mentioned above.

A security tool or service that creates, determines the existence of, or demonstrates a DoS condition in ANY other manner, actual or simulated, is expressly forbidden.

Some tools or services include actual DoS capabilities as described, either silently/inherently if used inappropriately or as an explicit test/check or feature of the tool or service. Any security tool or service that has such a DoS capability, must have the explicit ability to DISABLE, DISARM, or otherwise render HARMLESS, that DoS capability. Otherwise, that tool or service may NOT be employed for ANY facet of the security assessment.

It is the sole responsibility of the AWS customer to ensure the tools and services employed for performing a security assessment are properly configured and successfully operate in a manner that does not perform DoS attacks or simulations of such. It is the sole responsibility of the AWS customer to independently validate the tool or service employed does not perform DoS attacks, or simulations of such, PRIOR to security assessment of any AWS assets. This AWS customer responsibility includes ensuring contracted third-parties perform security assessments in a manner that does not violate this policy.

Furthermore, you are responsible for any damages to AWS or other AWS customers that are caused by your penetration testing activities.