1.
Are You Ready
For a Cloud Pentest?
Teri Radichel | @teriradichel

2.
Pentesting is cool!
People seem to be in awe of hackers.
Many people aspire to be pentesters.
In reality, hacking is easier than defending.
We should be in awe of defenders, but I digress.
© 2nd Sight Lab, 2019

3.
What this talk is about
Getting the most from a pentest.
Being prepared.
Cloud vs. On-Premises.
NOT about lots of nifty hacking tricks.
© 2nd Sight Lab, 2019

4.
Why might you need a pentest?
Compliance. It’s required explicitly, or implicitly.
Often testing by a third party.
Prove the system can be broken into.
(Not that it can’t be.)
© 2nd Sight Lab, 2019

5.
Pentest preparation
Mutual NDA - protects you and the pentester
Define scope - what is in scope, what is not, objectives
Rules of engagement - contacts, time of testing
Contract - time, cost, ownership, data protection, and more
© 2nd Sight Lab, 2019

6.
What you do not have to do
All three cloud providers have discontinued upfront approval.
You no longer have to submit a request.
You may want to, in order to ensure your test isn’t terminated.
A funny thing happened….
© 2nd Sight Lab, 2019

7.
My last request
I made a request to allow my students to pentest in class
I received an email saying requests were no longer required
I posted it on Twitter - it wasn’t even on the AWS web site yet
It went viral...
© 2nd Sight Lab, 2019

8.
The infamous response
© 2nd Sight Lab, 2019

9.
Then
GeekWire
wrote
about it
© 2nd Sight Lab, 2019

10.
You still need permission!
Not having to submit a form does not mean anything goes.
You can only test systems for which you have permission.
You can’t test anything that is off limits per the cloud provider.
But for basic testing, no more pentest request forms.
© 2nd Sight Lab, 2019

11.
May still want to send a request
Let the cloud provider know you are testing.
Make sure your test doesn’t get shut down.
Your testing exceeds the base permission…
AWS only allows testing of 8 services by default.
© 2nd Sight Lab, 2019

12.
For example...
© 2nd Sight Lab, 2019

13.
What’s different in the cloud?
Dynamic resources and moving parts - scope changes
Layer 4 and up - and only what is allowed by the provider.
New technologies and configuration considerations.
Underlying platform may cause traditional methods to fail.
© 2nd Sight Lab, 2019

14.
Dynamic resources
The IP address for a system may change during the test.
The IP address may then be assigned to a different customer.
What about AWS Lambda, Azure and Google Functions?
Use domain names instead of IP addresses, or Elastic IPs.
© 2nd Sight Lab, 2019

15.
Layer 4 + in AWS, Azure, GCP
Layer 4 and up on infrastructure as a service clouds.
If you’re used to testing routers and switches, sorry no.
As for layer 4 and up, most of the same attacks apply.
Pentesting your web applications will be mostly the same.
© 2nd Sight Lab, 2019

16.
Layer 4 + in AWS, Azure, GCP
© 2nd Sight Lab, 2019
Responsibility # Layer Examples
Customer 7 Application Web requests, documents, application load balancers, WAF, DNS
6 Presentation Translation between network and application layers
5 Session Stateful firewall – tracks all the packets in a particular session.
4 Transport TCP, UDP protocols (with ports), load balancers, stateless firewalls
Cloud Provider 3 Network IP Protocol (no ports), IP routers
2 Data Link Ethernet, 802.11, Mac Layer
1 Physical Network interface card and other hardware

17.
But only what is allowed
Each cloud provider has pentesting requirements.
You need abide by the terms of service (TOS).
Also acceptable use policy (AUP).
You still need permission from the resource owner!
© 2nd Sight Lab, 2019

18.
Actions and resource sizes
Certain types of tests cannot be performed.
The cloud provider may limit throughput.
Resource sizes may be limited or at least recommended.
Scope documentation should be aligned accordingly.
© 2nd Sight Lab, 2019

19.
Not allowed
AWS does not allow the following
Azure: No Denial of Service attacks
© 2nd Sight Lab, 2019

20.
Pre-authorized tools
Some tools may be pre-authorized by the cloud provider.
Using these tools may ensure you’re following the rules.
These tools are available in the marketplace.
The cloud provider may also offer tools directly.
© 2nd Sight Lab, 2019

21.
Like this one: Nessus
© 2nd Sight Lab, 2019

22.
New Configurations
Have you heard of an S3 Bucket?
It’s all about the configurations inside the cloud.
Lots of new services to configure ...or misconfigure.
Pentesters will check these new types of services.
© 2nd Sight Lab, 2019

23.
New Technology Stacks
Serverless - Lambda, Google and Azure functions.
Containers - often misunderstood and misconfigured.
Container management - Docker, Kubernetes, ECS
New types of storage - DynamoDB, CosmosDB, BigTable
© 2nd Sight Lab, 2019

24.
New Cloud Provider Tools
Cloud platforms offer SDKs and CLIs.
These powerful new tools call cloud APIs.
They make changes in your accounts.
These same tools can be used and abused by pentesters!
© 2nd Sight Lab, 2019

25.
Cloud Platform Differences
Under the hood where you can’t see things may be different.
AWS doesn’t use ARP. They created a Mapping Service.
They wrap packets leaving a VM NIC in custom headers.
What does that mean? No more ARP Spoofing.
© 2nd Sight Lab, 2019

26.
Why Arp Spoofing doesn’t work
© 2nd Sight Lab, 2019

27.
Pentesting Tools…old and new
Tried and true pentesting tools may be limited (Metasploit).
New tools like PACU from Rhino Security Cloud built for AWS.
In some cases, the provider CLI is very powerful by itself.
In most cases, use a combination of old and new techniques.
© 2nd Sight Lab, 2019

28.
Pentesting Resources on GitHub
© 2nd Sight Lab, 2019

29.
How all that affects a Pentest
Hire someone that understands the cloud.
Define Domain Names, not IP addresses.
Understand the cloud provider requirements.
Include someone technical in the scoping process, if possible.
© 2nd Sight Lab, 2019

30.
Considering Scope
© 2nd Sight Lab, 2019

31.
Network access to your cloud
Traffic no longer stays in your network.
Developers may be calling APIs from your environment.
People are logging into the console.
The network equipment could be attacked.
© 2nd Sight Lab, 2019

32.
Mashup of connected services
Many systems in the cloud integrate with other systems.
If you are leveraging any third party systems - need permission.
Make sure any and all are listed as in or out of scope.
May not be able to test - you’ll have to get their pentest.
© 2nd Sight Lab, 2019

33.
Cloud Platform is out of scope
Whatever the cloud platform, AWS, Azure, Google
The platform is out of scope for your test
You will have to rely on their pentesting or compliance results
Some services, like Cognito, will be out of scope as well
© 2nd Sight Lab, 2019

34.
Web applications in the cloud
Recommendation: Include web app penetration testing.
Often can leverage a old and new technologies.
Also include credentials. Once authorized more attack surface.
Pentesters can check for lateral access and elevated access.
© 2nd Sight Lab, 2019

35.
Optimizing Your Results
Have you had an assessment? That may be a place to start.
Are you already following best practices?
Can you do basic pentesting yourself?
Why giving read-only access may be beneficial.
© 2nd Sight Lab, 2019

36.
Assessment vs. pentest
An assessment involves a review of best practices.
It does not include exploitation and pivoting.
An assessment may actually find more problems.
A simple assessment can be faster and cost less.
© 2nd Sight Lab, 2019

37.
Do you follow Best Practices?
Before calling in a pentester have you read the best practices?
AWS well-architected framework, Azure Scaffold, CIS...
If you implement those first will save some pages in the report.
If you have a network team, have they reviewed the network?
© 2nd Sight Lab, 2019

38.
Best practices: CIS Benchmarks
Have you evaluated your systems against CIS Benchmarks?
Best practices for many systems:
AWS, Azure, GCP, Docker, Kubernetes, Windows, more…
Evaluate and fix issues you find before your test.
© 2nd Sight Lab, 2019

39.
Are Cloud Security Services on?
Have you enabled all the cloud security services?
Some will tell you if resources are misconfigured.
Review and fix any findings.
Also make sure logging has been turned on for all services.
© 2nd Sight Lab, 2019

40.
What about a vulnerability scan
Have you run a vulnerability scanner over your systems?
That’s one of the first thing the pentester will do.
Any vulnerabilities may be leveraged in an attack.
Vulnerability scanners report known software flaws.
© 2nd Sight Lab, 2019

41.
Credentials and Segregation
Credentials are a critical point of failure in cloud security.
Do you have MFA on all critical credentials?
Are permissions segregated to reduce the blast radius?
If developers have broad access, might want to fix that first.
© 2nd Sight Lab, 2019

42.
Credential Attacks and cloud
Standard credential attacks can apply in and out of cloud.
Mimikatz, brute force attacks on passwords, SMB.
Once credentials are obtained, see what can access.
Phishing and social engineering still apply as well.
© 2nd Sight Lab, 2019

43.
Developers and Networking
Did the developers get their first?
Did they build the network? With no network training?
In that case, may be using default network rules...
Open outbound access, default CIDR blocks and ports.
© 2nd Sight Lab, 2019

44.
Is your system Complete?
You can have a pentester test early to get initial results.
Security up front and early is always a good idea.
However if your system is not complete - expect to test again.
Likely things will break in ways that limit test coverage.
© 2nd Sight Lab, 2019

45.
Can you do Basic Pentesting?
Running web scanning tools is not rocket science.
You’ll need permission from your organization (C-Level)
Burp Suite doesn’t cost much and Zed Attack Proxy is free.
Fix the basics and let your pentester know risks you accept.
© 2nd Sight Lab, 2019

46.
Read-only access for pentesters
Pentesters can save time with read-only access in the cloud.
The same results (or better) as a network scan in less time.
Testers can verify they are attacking your resources.
Testers can verify they are not breaking provider rules.
© 2nd Sight Lab, 2019

47.
Assessing Best-Practices
With read-only access testers can assess best practices.
For example, testers can quickly assess S3 buckets.
Additionally paths can be mapped out to attack resources.
Tests can focus on more advanced attacks.
© 2nd Sight Lab, 2019

48.
Cloud Architecture Review
Possible with read-only access and related experience.
Get an architecture review that spans cloud, app and network.
Reviews can also include team structure and processes.
For best results include documentation and interviews.
© 2nd Sight Lab, 2019

49.
Are you ready to fix it?
After the test, you may need to go back and fix things.
Do you have the capacity and approval to fix the findings?
Will you need a follow-on penetration test to verify the fixes?
A new test may may produce new findings.
© 2nd Sight Lab, 2019

50.
Let’s pentest!
Now let’s get busy and pentest.
Defining your scope properly is most important to get started.
Hopefully after you’ve prepared for all of the above…
Your pentest will produce more meaningful results.
© 2nd Sight Lab, 2019

51.
Thank you!
https://2ndsightlab.com
https://medium.com/cloud-security
Teri Radichel | @teriradichel