The document discusses a security breach of an AWS cloud account, detailing the author's process of discovering and exploiting vulnerabilities through SQL injection. It outlines lessons learned regarding cybersecurity practices and personal growth, emphasizing the importance of never blindly trusting frameworks and the need for proactive security measures. The author concludes by stressing that security should be viewed as an ongoing process rather than a one-time product.

1. AWS Cloud Account Hacked!
Lesson to learn

2. Agenda
1. Introduction
2. Security Breach Levels - My View
3. Security Breach Mindset - My Recipe
4. AWS Cloud Account Hack
5. Lesson to Learn
6. Conclusion

3. Introduction
Now a days security is as import as development.
Cybercrime is on its peak. I recently takeover an AWS
cloud account of a company (I Will not reveal company due to ethical
boundaries. Reporting is in process). Motivation and purpose to
share this security breach use case is to highlight the
lesson which I learn and the serious need of cyber security
P.S: I didn’t hurt any infrastructure of company.

4. Security Breach Levels - My View
I categorize security on three levels:
1. Customer facing applications (e.g: websites, mobile apps)
2. Networks (e.g: internet communication protocols like TCP, UDP)
3. Infrastructures (e.g: machines on which application has deployed)
Security breach can be occur on any level and
consequences can vary level to level

5. Security Breach Mindset - My Recipe (1)
I always compare security research with crime case
investigation.
Broader steps of Crime investigation can be:
● Think like a criminal
● Find leads from crime spot
● Follow leads
● If you work smartly and you are bit lucky then you’ll get
culprit

6. Security Breach Mindset - My Recipe (2)
I follow same crime investigation steps and do following
things:
● Think like a nerd software engineer
● Find leads from available views like websites, mobile
apps, networks, secret keys (If I get from any source)
● Follow them and exploit every possible dimensions
● If I work smartly and I was lucky than I got vulnerability

7. AWS Cloud Account Hack : Lead
A bad day for an eCommerce website that I visit them and
inspired from their UI design. There was no intention as
well as time to breach them but I want to check framework
so that I can find that theme or template and that was the
unlucky time for them that I spotted a “GET” query string
and I just place a single inverted comma, BANG: SQL
Injection

8. AWS Cloud Account Hack : Exploit
So I take out some time and start my criminal case steps
as I already get lead and I was think like a nerd software
engineer. I use some SQL injection vectors and start
digging into it but this takes time and vulnerability was
confirmed by some SQL vectors so I decided to run my
favorite tool: SQLMAP
It gets all DB tables and I was like “Wow! It was too easy”.

9. AWS Cloud Account Hack : Curiosity
But still I’m curious to know that either It’s a framework or
custom web and HTML source code is indicating towards a
framework because resources paths are like decorated
framework (xyzwebsite.com/catalog/sites/images/xxx). So I search
the part of URL after “.com” (/catalog/sites) and google leads
me to three search results who has this path pattern and
out them one has “Open Directory”. I started digging into it
and hence find that It’s a private framework by a software
company.

10. AWS Cloud Account Hack : A final lead
After an hour of digging into folders, I found a folder
containing settings XML file, as a cache, in that “Open
Directory” vulnerable website and since it’s not my target I
get back to that culprit website and try to open that
settings and I got a real break through. Every secret key
and settings was in that file including AWS S3 Key. I
connect that AWS key with a software name S3Browser
and I got their S3 bucket access which has CRUD rights.

11. AWS Cloud Account Hack : Takeover
Since I’m unaware of AWS key management so I think S3
takeover as my success point which is actually not bad. A
nightmare for that company arrives after 1 month when I
was aware with AWS key management (thanks to Disrupt A.K.A
GADITEK, my career kickstart employer). I test that AWS S3 key of that
company with an open source tool (Nimbostratus) which I
read on this link. This tool test the AWS access key rights
on AWS resources and I got final takeover because that
AWS access key has ROOT rights. BANG!

12. Lesson to Learn (1)
I learn following lessons:
Security Dimension:
● Never trust on framework blindly.
● Don’t add credentials on any file or INI instead use
environment variables
● Don’t give extra access rights to any resource.
● Spend little bucks on security inspection at-least once
specially in case of third party framework.

13. Lesson to Learn (2)
Personal Dimension:
● Never give up until your own satisfaction
● Never take win as an END instead consider win as a
NEW BEGINNING
● Always keep learning from circumstances (I didn’t learn AWS
access key management when I got that S3 key. It was employer’s work
which made me learn that part which strikes me with embarrassment
that why I didn’t learn at that time)

14. Conclusion
Never take cyber world for-granted and take every
possible security majors on every level. You may face an
unlucky day if somebody breach your product because:
Security is not a product, but a process
-Bruce Schneier

15. Thank You![Every opinion is solely my mindset and can be differ from others - Rational correction is highly
appreciable]
(Sorry for any english grammar or spelling mistakes)