Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Sonatype DevSecOps Leadership forum 2020

Cargando en…3

Eche un vistazo a continuación

1 de 52 Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a Sonatype DevSecOps Leadership forum 2020 (20)


Más de Daniel Garcia (a.k.a cr0hn) (20)

Más reciente (20)


Sonatype DevSecOps Leadership forum 2020

  1. 1. How Hackers Can Break Your CI/CD Infrastructure

  2. 2. WHO WE ARE Security research. Hacking tools developer, DevSecOps. Python developer. Daniel García (cr0hn) Can’t define myself. I go where my curiosity drives to. Most of the time goes bad. I process TeraBytes for breakfast. César Gallego @ggdaniel @CesarGallegoR
  3. 3. Disclaimer! Any opinions expressed are personal opinions and don’t represent our employer’s view in any way
  4. 4. Shared vocabulary Core Concepts
  6. 6. Legacy Systems
  7. 7. No CD Ops Dev
  8. 8. No CI/CD Ops Dev
  9. 9. Hell Dev
  10. 10. STEPS IN BUILDING SOFTWARE CONSTRUCTION User Code Building step Deployment step Production
  11. 11. Follow us down the rabbit hole Starting the journey
  12. 12. In source code
  13. 13. IN THE SOURCE CODE User Code Building step Deployment step Production
  14. 14. No all StackOverflow people are good persons (or even humans) In STACK OVERFLOW Works Great!
  15. 15. ● Are your developers using safe libraries? ● Are you check the libraries they use? ● Even more… they ask you for advice when choice a new library? All Libraries Allowed! wallets/ You trust all libraries? so you know that all libraries are malware / vulnerabilidades free?
  16. 16. ● Passwords ● API keys ● Private keys ● …. SECRETS & LEAKS
  17. 17. In the building step
  18. 18. IN THE BUILDING STEP User Code Building step Deployment step Production
  19. 19. ● What if an user can execute anything in a Pipeline? ● What if the C.I. has not limited the output traffic? A reverse Shell in the Pipeline Limit user permissions and output destinations
  20. 20.
  21. 21. ● Do you control what can download a developer when they runs in a pipeline? ● Do you control which command can launch a developer in a C.I. / C.D. configuration file? (Jenkinsfile, gitlab.yaml…) ● Is your C.I / C.D. in different network? Are you sure? The EVIL AGENT (1 / 3)
  22. 22. The EVIL AGENT (3 / 3) ➔ Limit internet access in the pipeline. ➔ Perform a correct hardening of the infrastructure ➔ Fix the execution permissions
  23. 23. ● Is your company using free tier services? ● Has your company GitHub Business account? The Greedy Service consumer! Keep in mind that free tier has limits by IP . Like GitHub, Google Maps… If your deploy rely on this services may be stuck if someone exceed the IP quota.
  24. 24. A git Bomb cannot be cloned. Only a problem with old git versions. Be aware in your older systems. The Git BOMB! ● Are your commits PGP signed? ● You know who can access rights? ● Are you using third party repositories?
  25. 25. Allow only some agents to publish images. Check docker layers contents. Check Dockerfile. The DOCKER HUB Leak! ● You have your own container registry? ● Do you check your Dockerfiles? ● Your pipelines has permissions and access to publish in docker hub?
  26. 26. A very fat container can spend all free space and avoid new docker builds. A fat container make deploy a slow and error prone process. The Fat DOCKER! ● Do you inspect your Dockerfiles? ● Do you have Docker builds correctly configured? ● Do you control where layers are built?
  27. 27. In the deployment step
  28. 28. IN THE DEPLOYMENT STEP User Code Building step Deployment step Production
  29. 29. Modify a Jar to add a trojan is very easy. Hard to detect and can be unbelievable persistent. The Trojan Jar! ● Do you suffer the Jar Hell? ● Your servers has outdated Java stuff? ● Your company has no java artefact repo?
  30. 30. ● ZIP Bomb is an old attack. ● The attack is very simple but very useful ● Some of system has basic routines to detect these kinds of attacks. The ZIP BOMB (1 / 4)
  31. 31. ● Major of packaged software is packed as a ZIP file: .jar, .war, .docx, .xlsx…. ● Some Application Servers auto deploy them when put files in specific path ● What if we put a ZIP bomb renamed as a valid packed Application for a Tomcat? The ZIP BOMB (2 / 4)
  32. 32. Perform a correct hardening of host and set conservative limits of files, CPU and memory that a processes can get The ZIP BOMB (4/ 4)
  33. 33. ● Memory bomb is type of attack that aims to fill all system memory. ● Not only RAM also SWAP is affected. ● If you don’t have limits in your host it can consume all of your HD space as a SWAP space. Memory BOMB (1 / 5)
  34. 34. ● What if you can run a memory bomb in a C.I. / C.D. system? ● What if the C.I. is deployed as multi- agent? Memory BOMB (2 / 5)
  35. 35. Jenkins agent 1 Jenkins agent 1 Jenkins agent 1 Jenkins behavior: 1 - You put a memory bomb in your Jenkinsfile Memory BOMB (3 / 5) 2 - The Jenkins Master send to the job to an Jenkins agent and it runs the pipeline and the memory bomb. So the Jenkins agent host break down Jenkins master 3 - Jenkins Master detect that the jobs was not finished. So the send the same job to another Jenkins Agent 4 - Jenkins agent runs memory bomb and… break down 5 - Go to step 2
  36. 36. ➔ Less Known but more effective in Docker. ➔ Today powerful computers can die very fast with no clue who pipeline is responsible. ➔ You can lost all your agents before you find where the problem is. Memory BOMB (5 / 5)
  37. 37. ● Fork bomb is type of attack that aims exhaust a system by creating new processes recursively ● It very difficult to detect if you don’t have a very good log system configured ● Run in a Pipeline is so easy ● In multi-agent system the results are the same that with Memory Bomb Fork BOMB! (1 / 2)
  38. 38. In production
  39. 39. The API contract must be fulfilled. No less, No more. The more is more problematic. Is your API Honest!? ● Do you use thread model on you APIs? ● How do you know all the endpoints that you have deployed? ● Are debug url opened in production?
  40. 40. Containers are just a bunch o deltas on a file storage and a lot of genius around. Don’t forget that layers can be accessed. keep SECRETS safe! ● Do you store secrets in your containers? ● Do you store security configurations on your containers? ● Do you store intellectual property on your containers? ● Where are your containers published?
  41. 41. In the infrastructure
  42. 42. IN THE DEPLOYMENT STEP User Code Building step Deployment step Production
  43. 43. ● Old hack attack but useful ● Alias commands could be the best trojan in a system. ● There are very complicated to detect The Evil Alias! Perform a well hardening of your host systems & be careful with the bot users
  44. 44. ● Do you deploy the C.I. software in your infrastructure? ● Do you have a network isolation from the building software to the production machine? ● Do you remember the scan by using Jenkins? Can you imagine use that with Metasploit to Production machines? The Shared infra! ➔ PLEASE use isolated networks (VPC, VLAN o something applicable to your infrastructure) ➔ If your C.I. system need to access to the production machines use LIMITED access API keys.
  45. 45. Keep this in mind Conclusions
  46. 46. ➔ Who will watch the watchers? Manage your CI/ CD as a critical software (because it is). ➔ Assume that you have a lot of potential insiders attackers. ➔ Protect your C.I. as your production systems. ➔ Monitoring. Always monitoring. Not only in the building step. QUIS CUSTODIET IPSOS CUSTODES?
  47. 47. We’re working on free online book this controls of this presentation