Cloud Security
&
Best practice in AWS

About Myself:
● Ankit Giri (@aankitgiri)
● Associate Security Consultant | TO THE NEW Digital
● Web and Mobile Application Security Researcher
● Bug Hunter (Hall of Fame: EFF, GM, HTC,Sony, Mobikwik, Pagerduty and some
more )
● Blogger, Orator and an active contributor to OWASP and null Community
● The Most Viewed Writer in Web application Security, Network Security and
Penetration Testing on Quora

About Today's Talk:
● Cloud Security:
● Some interesting instances of breach
● Best practices to protect AWS account from unauthorized access and usage
● What and How to look for security loopholes
● Audit scripts
● What one should learn to safeguard Cloud application?

Few instances of breach (Live examples)
Account compromise via leak of AWS Keys on GitHub :
I woke up one morning, only to find few emails and a missed phone call from an ISD Number (it was
from Amazon AWS) - something about 140 servers running on my AWS account.

Few instances of breach (Live examples)
Account compromise via leak of AWS Keys on GitHub :
What was my mistake in this case?
"I only had keys in some of my scripts I had written for some client. And we had a habit of pushing
the code to GitHub. And they were gone within five minutes!!
"As it turns out, through the API calls you can actually spin up EC2 instances, and my key had been
spotted by a bot that continually searches GitHub for API keys."
Amazon support staff told me that such bot exploits were increasingly common with hackers running
algorithms to perpetually search for GitHub for API keys.
Once it finds one it spins up max instances of EC2 servers to farm itself Bitcoins.

The root cause :
The secret keys are issued by Amazon Web Services when users open an account and provide
applications access to AWS resources.
When opening an account, users are told to “store the keys in a secure location” and are warned that
the key needs to remain “confidential in order to protect your account”.
AWS reminds subscribers that "anyone who has your access key has the same level of access to your
AWS resources that you do. Consequently, we go to significant lengths to protect your access keys,
and in keeping with our shared-responsibility model, you should as well."
However, a search on GitHub reveals thousands of results where code containing AWS secret keys
can be found in plain text, which means anyone can access those accounts.
Search it on your own (But after this presentation gets over :) )

Another Case where this happened!
Dev Factor founder Andrew Hoffman said he used Figaro to secure Rails apps which published his
Amazon S3 keys to his GitHub account.
He noticed the blunder and pulled the keys within five minutes, but that was enough for a bot to
pounce and spin up instances for Bitcoin mining.
"When I woke up the next morning, I had four emails and a missed phone call from Amazon AWS -
something about 140 servers running on my AWS account," Hoffman said.
"I only had S3 keys on my GitHub and they were gone within five minutes!"
"As it turns out, through the S3 API you can actually spin up EC2 instances, and my key had been
spotted by a bot that continually searches GitHub for API keys."
Amazon (he said) told him such bot exploits were increasingly common with hackers running
algorithms to perpetually search for GitHub for API keys.

Few instances of breach (Live examples)
❖ Several bloggers have admitted getting a shock after receiving a large bills for bandwidth usage
they didn't initiate. For example, Luke Chadwick was hit with a US$3493 (A$3842) bill in
December, because of unauthorised activity. To his relief, this was later refunded by AWS.
❖ Earlier this year, AWS contacted Rich Mogull, analyst and CEO of Securosis after three days of
unusual activity on his account had run up US$500 in charges. In a blog post from January,
Mogull said he had mistakenly published his AWS secret key on GitHub.
"I did not completely scrub my code before posting to GitHub. I did not have billing alerts enabled ...
This was a real mistake ... I paid the price for complacency," he admitted in his blog.

What AWS thinks of these breaches?
In a statement, AWS told iTnews it "takes security very seriously and provides many resources,
guidelines and mechanisms to help customers configure AWS services and develop applications using
security best practices."
"However, developers are responsible for following our guidance and utilising those mechanisms.
When we become aware of potentially exposed credentials, we proactively notify the affected
customers and provide guidance on how to secure their access keys," the statement said.

What is SSRF Attack ?
Server Side Request Forgery (SSRF) is a vulnerability
that appears when an attacker has the ability to create
requests from the vulnerable server.
Usually, Server Side Request Forgery (SSRF) attacks
target internal systems behind the firewall that are
normally inaccessible from the outside world (but using
SSRF it’s possible to access these systems). With SSRF
it’s also possible to access services from the same server
that is listening on the loopback interface.
Using Server Side Request Forgery attacks it’s
possible to:
➢ Scan and attack systems from the internal network
that are not normally accessible
➢ Enumerate and attack services that are running on
these hosts
➢ Exploit host-based authentication services

SSRF Attack (Live Example)
Recently a client got a mail from some organization complaining about random request on their
servers from one of the client’s IP. On investigating the issue, we found out that the complaint was
correct. And there have been a increased number of Network Out data from our instances, and hence
resulting in high billing on the account.
The approach followed was:
● Search for the unrecognised Process in the server as at this time "chaos" named process was
found
● Run the command: http://freecode.com/projects/lsof/
● lsof -p <pid of that process>
● Look whether this process is hitting some IP on the network.
● Now look for IP on the Net, at this time IP was found and the IP was of Hong Kong Trade
Center.
● Don't try to kill the process as this process will restart again as, this copies of this process would
be present anywhere on the server.
● Just Terminate this instance and launch a new server.
● Look for the Security Group
● Close all the ports except 80 which are opened for all

A similar issue was reported in “Pocket”
Here is the link:
https://news.ycombinator.com/item?id=10078967

There's a Hole in 1,951 Amazon S3 Buckets
We discovered 12,328 unique buckets with the following breakdown:
Public: 1,951
Private: 10,377
Approximately 1 in 6 buckets of the 12,328 identified were left open for the perusal of anyone that's
interested.
These 12,328 buckets were skewed towards those we could identify based on domain name, word list,
or use within web sites. From the 1,951 public buckets we gathered a list of over 126 billion files. The
sheer number of files made it unrealistic to test the permissions of every single object, so a random
sampling was taken instead. All told, we reviewed over 40,000 publicly visible files, many of which
contained sensitive data.

❖ Some specific examples of the data found are listed below:
➢ Personal photos from a medium-sized social media service
➢ Sales records and account information for a large car dealership
➢ Affiliate tracking data, click-through rates, and account information for an ad company’s
clients
➢ Employee personal information and member lists across various spreadsheets
➢ Unprotected database backups containing site data and encrypted passwords
➢ Video game source code and development tools for a mobile gaming firm
➢ PHP source code including configuration files, which contain usernames and passwords
➢ Sales “battlecards” for a large software vendor

Root Cause :
The root of the problem isn't a security hole in Amazon's storage cloud, according to Vandevanter.
Rather, he credited Amazon S3 account holders who have failed to set their buckets to private -- or to
put it more bluntly, organizations that have embraced the cloud without fully understanding it. The
fact that all S3 buckets have predictable, publicly accessible URLs doesn't help, though.
What makes it a common vulnerability?
Just because a file is listed in a bucket doesn't mean it can be downloaded, buckets and objects have
their own access control lists (ACLs). However, if a user does lock down files within a public bucket,
a data thief could still glean potentially sensitive information from the file names, including
customer names or the frequency which with applications are backed up
Contributing to the problem may be the fact that all S3 buckets have a unique, predictable, and
publicly accessible URL, which makes it easy to track down buckets and determine which are private
and which are public. By default this URL will be either
http://s3.amazonaws.com/[bucket_name]/ or http://[bucket_name].s3.amazonaws.com/.
If you enter the URL and receive an Access Denied response, the bucket is private. If it's public, you'll
be presented with the first 1,000 objects stored therein.

Publicly accessible S3 Bucket, folders
and files :

Publicly accessible S3 Bucket, folders
and files :
Hi All,
I know that hackerone-attachments is used for file uploads on reports and so I did a quick
scan for similar buckets and found ████████████████. While I can't confirm if you
own it or not, it appears that it is publicly writable using the aws cli.
When I tried to write to hackerone-attachments, I get:
"move failed: ./test.txt to s3://hackerone-attachements/test.txt A client error
(AccessDenied) occurred when calling the PutObject operation: Access Denied.
However, when I write to ████████████████, I get:
move: ./test.txt to s3://████████████████/test.txt
Hopefully the bucket is yours and this isn't a waste of time. If you do own it, a good thing
is the bucket is not publicly readable and the file appears private by default after being
written. However, assuming you own it, the security issue would be someone writing
something malicious and someone on your team unknowingly opening it.
Pete
Security Researcher
https://hackerone.com/reports/128088

Publicly accessible S3 Bucket, folders
and files :
HackerOne rewarded yaworsk with a $2,500 bounty. Apr 4th (6 days
ago)
Thanks again for the great report, @yaworsk.
It's always great to see researchers thinking outside the normal web app confines and
considering other parts of technical infrastructure that could affect a company. While you
weren't able to read any contents from that bucket (and even if you would, everything is
encrypted using AES-256), an attacker could theoretically post a file into that bucket that
may at some point be accessed by a HackerOne staff member, thinking it's been
uploaded by another staff member or some automated system.
This issue also led us to audit some of our additional S3 buckets (we have quite a few),
and we found some similar issues among several of them. As such, we are increasing the
bounty to take those additional mitigations into account, even though they weren't
discovered by you.
Look forward to seeing what you find next! Happy hacking. :-)

Another Case where this happened!
Recently an Amazon S3 bucket (http://shopify.com.s3.amazonaws.com/) was
unintentionally left with directory listing enabled. Even though the files in the bucket were
all publicly accessible, it was not intended for the directory listing to be visible
https://hackerone.com/reports/57505

Bucket Finder script :
How to use and exploit scenario:
http://hackoftheday.securitytube.net/2013/04/finding-publicly-readable-files-in-your.html
https://digi.ninja/projects/bucket_finder.php

I was recently searching for something on Google and came across this instance of what might be a logical
vulnerability prevailing across multiple web applications. I was searching for publicly accessible Jenkins
console through Google Dorking. My search query listed some of the websites that had Jenkins as a part of
their domain name. Although this itself is not a security issue but it reveals the fact that Jenkins is being
used as a CI (Continuous Integration) tool and it’s console is publicly accessible. The following
information may be used to plan a chain of attacks.
Jenkins can lead to a disaster?

What took me by surprise is that I found many Jenkins console with no authentication mechanism enabled
on them. I can easily open the console, read the usernames, the build history, logs of builds and much
more. This made me think about the necessity of having proper security implemented on a Jenkins
console. So, this blog post will be covering the devastating effect of a compromised Jenkins server and
how to protect this from happening.
Jenkins can lead to a disaster?

Treasure of credentials such as AWS Access keys and Secret key.
Impact: Anyone can use the AWS account linked to the Access keys and Secret keys to launch resources
which will lead to the owner getting billed for it. A person possessing these credentials gets full access to
the AWS account
The server’s pem files, IP addresses, usernames, email address etc.
Impact: The disclosure of the above mentioned information will lead to logging into the server
(remember there may be a hundred of servers accessible from this console), running arbitrary commands
on it, getting access to users and their respective password ( and what not! ).
The revealed username and email address will also enable the attacker to plan much more sophisticated
attacks on the organization as he is now much more aware of the developer and other accounts that are
present. This can also result in him brute forcing other applications such as the Admin, CMS portal of the
application.
Why compromised Jenkins can
lead to a disaster?

GitHub SSH Key
SSH keys are used to identify trusted computers, without involving passwords. Since, Jenkins has
availability of Git plugin which enables us to run Git commands from the Jenkins console itself. So, the
publicly accessible Jenkins console will enable an attacker to view, modify, update the code of the
production application. In the worst scenario possible, the attacker can issue a “git branch -m production”
command and delete all the existing code and thus bring the application down by deleting the
“production” branch containing the code of the application.
S3 Bucket
The Jenkins console might have access to private S3 buckets containing content such as images, log files,
code backups etc. This access to essential data can be abused to delete important files and folders.

A public cloud is one based on the standard cloud computing model, in which a service provider makes
resources, such as applications and storage, available to the general public over the Internet. Public cloud
services may be free or offered on a pay-per-usage model.
The main benefits of using a public cloud service are:
# Easy & inexpensive set-up because hardware, application & BW costs are covered by provide
# Scalability to meet needs.
# No wasted resources because you pay for what you use.
AWS - Public Cloud

The term "public cloud" arose to differentiate between the standard model and the private
cloud, which is a proprietary network or data center that uses cloud computing technologies,
such as virtualization. A private cloud is managed by the organization it serves. A third
model, the hybrid cloud, is maintained by both internal and external providers.
Examples of public clouds include Amazon Elastic Compute Cloud (EC2), IBM's Blue Cloud,
Sun Cloud, Google AppEngine and Windows Azure Services Platform.
AWS - Public Cloud

Amazon VPC
•Amazon Virtual Private Cloud (Amazon VPC) lets you provision a logically isolated section of the
Amazon Web Services (AWS) Cloud where you can launch AWS resources in a virtual network that
you define. You have complete control over your virtual networking environment, including selection
of your own IP address range, creation of subnets, and configuration of route tables and network
gateways.
•You can easily customize the network configuration for your Amazon Virtual Private Cloud. For
example, you can create a public-facing subnet for your webservers that has access to the Internet, and
place your backend systems such as databases or application servers in a private-facing subnet with no
Internet access. You can leverage multiple layers of security, including security groups and network
access control lists, to help control access to Amazon EC2 instances in each subnet.
•Additionally, you can create a Hardware Virtual Private Network (VPN) connection between your
corporate datacenter and your VPC and leverage the AWS cloud as an extension of your corporate
datacenter.

● Disable root access key and secret key.
● Enable MFA tokens for each IAM user.
● Have minimum IAM users with Admin rights.
● Use Roles for EC2 instances for access permissions wherever possible.
● Provide least privileges and limit IAM entities actions with strong/explicit policies.
● Rotate all the keys on a regular basis (say 60 days).
● Use IAM roles with STS AssumeRole wherever possible.
● Do not allow 0.0.0.0/0 for any EC2/ELB security group.
● Apply proper S3 bucket policies with public access to only files instead of sharing a
bucket/folder.
● Create all resources within a VPC.
● Make sure only required ports are open.
Best practices to protect AWS account from unauthorized
access and usage:

●Ensure all Back-end servers i.e. database servers are accessible via web servers only.
●Having separate IAM user for each team member.
●Attach all policies on groups and include users in a group as per access requirement.
●Avoid making server_Status page accessible publicly.
●Ensure all SSL certificates follow SHA2 encryption.
●For details about migrating to SHA2 :
Set alarms on billing using Amazon CloudWatch.
This practice can be very useful to detect DDoS attacks and high data transfer occurrences.
For steps to set alerts on billing:
http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-alarms.html
Some more Best practices to protect AWS account

● Make sure bash terminal on all servers are ShellShock proof.
● Following is a command test to check if our Bash is vulnerable to ShellShock:
○ env var='() { ignore this;}; echo vulnerable' bash -c /bin/true
○ A vulnerable version of bash will give a output “vulnerable”.
● If any patch has been applied, the same command test will return:
○ bash: warning: var: ignoring function definition attempt
bash: error importing function definition for 'var'

•Using AWS WAF to block malicious requests
Best practices to protect AWS account from
unauthorized access and usage:

● There is an Audit script that scans our AWS infrastructure for Security loopholes.
● Description and its need
● Center for Internet Security compliance and best practices
● Hardened AMIs provided by CIS:
https://aws.amazon.com/marketplace/search/results/ref=dtl_navgno_search_box?page=1&s
earchTerms=center+for+internet+security
● AWS Whitepaper
Some in-house solutions:

Best practices to protect AWS account
from unauthorized access and usage:

Thankyou….