Skip to main content

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 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.


Popular posts from this blog

Hacking Windows 10 UWP App: DLL Injection & common Vulnerabilities

I recently started working on  widows 10 Apps( Apps not Applications) security. Before diving deep in hacking terms lets try to understand what's new in Windows 10 UWP( Universal Platform) as compared to old Apps. Lets begin with how apps actually work on windows 10(desktop/tablet). Now windows 10 comes with a container only for running apps inside the isolated environment. By default, /APPCONTAINER(Linker Flag) is off. This option modifies an executable to indicate whether the app must be run in the appcontainer process-isolation environment. Specify /APPCONTAINER for an app that must run in the appcontainer environment—for example, a Windows Store app. (The option is set automatically in Visual Studio when you create a Windows Store app from a template.) For a desktop app, specify /APPCONTAINER:NO or just omit the option. The /APPCONTAINER option was introduced in Windows 8. Now there is no registry entry concept for these app in the System HIVE rather they install they own hiv

Installing vmware-11.0 on Ubuntu 15.04 Using kernel Patch

curl -o /tmp/vmnet-3.19.patch cd /usr/lib/vmware/modules/source tar -xf vmnet.tar patch -p0 -i /tmp/vmnet-3.19.patch tar -cf vmnet.tar vmnet-only rm -r *-only vmware-modconfig --console --install-all References:

SSI Injection Attack

SSIs are directives present on Web applications used to feed an HTML page with dynamic contents. They are similar to CGIs, except that SSIs are used to execute some actions before the current page is loaded or while the page is being visualized. In order to do so, the web server analyzes SSI before supplying the page to the user. The Server-Side Includes attack allows the exploitation of a web application by injecting scripts in HTML pages or executing arbitrary codes remotely. It can be exploited through manipulation of SSI in use in the application or force its use through user input fields. It is possible to check if the application is properly validating input fields data by inserting characters that are used in SSI directives, like:  Code: < ! # = / . " - > and [a-zA-Z0-9] Another way to discover if the application is vulnerable is to verify the presence of pages with extension .stm, .shtm and .shtml. However, the lack of these type of pages does not mean that th