O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Are You Ready for a Cloud Pentest?

Próximos SlideShares
AWS Security Strategy
AWS Security Strategy
Carregando em…3

Confira estes a seguir

1 de 51 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Are You Ready for a Cloud Pentest? (20)


Mais de Teri Radichel (13)

Mais recentes (20)


Are You Ready for a Cloud Pentest?

  1. 1. Are You Ready For a Cloud Pentest? Teri Radichel | @teriradichel
  2. 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. 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. 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. 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. 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. 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. 8. The infamous response © 2nd Sight Lab, 2019
  9. 9. Then GeekWire wrote about it © 2nd Sight Lab, 2019
  10. 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. 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. 12. For example... © 2nd Sight Lab, 2019
  13. 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. 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. 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. 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. 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. 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. 19. Not allowed AWS does not allow the following Azure: No Denial of Service attacks © 2nd Sight Lab, 2019
  20. 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. 21. Like this one: Nessus © 2nd Sight Lab, 2019
  22. 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. 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. 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. 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. 26. Why Arp Spoofing doesn’t work © 2nd Sight Lab, 2019
  27. 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. 28. Pentesting Resources on GitHub © 2nd Sight Lab, 2019
  29. 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. 30. Considering Scope © 2nd Sight Lab, 2019
  31. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 51. Thank you! https://2ndsightlab.com https://medium.com/cloud-security Teri Radichel | @teriradichel

Notas do Editor

  • #ebf3fe
  • #ebf3fe