Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Attacking Cloud Services with Source Code

Attacking Cloud Services with Source Code

This talk was presented at SOURCE Boston 2013 and THOTCON 0x4. I talk about some basic development processes, my perspectives as an opensource contributor, and how hosted (cloud-based) CI/CD services make my life so much easier. I also take a look at some different attack vectors to consider on CI/CD deployments in general and what the potential impacts could be if leveraged successfully. Lastly, I announce a soon to be released tool that I developed to help test CI/CD servers for security weaknesses.

Recorded Presentation - https://www.youtube.com/watch?v=i5REko2mYBk&feature=c4-overview&list=UUbIJ5eQhfXgdGwEqDs3F86A

Demo #1 - https://vimeo.com/65071592 (Pop a Reverse Shell using Continuous Integration)

Demo #2 - https://vimeo.com/65071593 (Make an Unauthorized Commit to Master using Continuous Integration)

RottenApple - https://github.com/claudijd/rotten_apple

Blog Post:
http://blog.spiderlabs.com/2013/05/securing-continuous-integration-services.html

Jonathan Claudius

April 16, 2013
Tweet

More Decks by Jonathan Claudius

Other Decks in Technology

Transcript

  1. © 2012 Who, Me? •  Jonathan Claudius –  Trustwave SpiderLabs

    •  Senior Security Researcher •  Vulnerability Assessment Team –  Open Source Contributor •  Mostly Ruby, some other stuff
  2. © 2012 Agenda •  Basic Terminology & Concepts •  OpenSource

    Development Woes •  Cloud Services to the Rescue •  Attacking Cloud Services •  Demo(s) •  Questions
  3. © 2012 Continuous Integration (CI) •  “A practice, in software

    engineering, of merging all developers workspaces into a shared mainline several times a day.” ~Wikipedia •  Popular Example: –  Jenkins CI –  Every time I commit new code… •  project is built & tested
  4. © 2012 Unit-testing •  “In computer programming, unit testing is

    a method by which individual units of source code … are tested to determine if they are fit for use” ~ Wikipedia •  A Ruby Example
  5. © 2012 OpenSource Dev as a Hobby •  I write

    code… –  after work –  on the weekend –  while “watching tv” •  I do it because… –  I enjoy solving problems –  I like to learn stuff –  I meet interesting people
  6. © 2012 The “down-side” •  Limited Time & Resources • 

    Everyone can Contribute •  Worried about Code Quality •  No Fancy CI Infrastructure
  7. © 2012 Hosted Cloud CI Providers •  Have been popping

    up over the past couple years •  Some Examples:
  8. © 2012 Ben’s Talk Got Me Thinking… •  Assumptions… – 

    Social Engineering –  Obfuscation •  What if I could... –  Guarantee Code Execution –  Hide Nothing –  Control When Things Happened
  9. © 2012 What’s happening on CI Servers? •  In Ruby…

    –  A CI server executes “rake spec” –  Translates to “run all my unit tests” •  Crazy thought… –  Ruby Unit-Tests (aka: specs) are just plain Ruby –  What if I added malicious code to my specs?
  10. © 2012 I built my own CI Server… •  Why?

    –  To emulate these CI servers –  To avoid pissing people off –  To not feel guilty when I did bad things •  Used Jenkins-CI
  11. © 2012 Break Out of Build Root •  Basic Directory

    Traversal •  Limited Sandboxing –  Discover/Access other projects built on this server
  12. © 2012 Scanning the Local Segment •  Perform an NMAP

    scan of neighboring hosts •  We’re now behind the firewall •  Potential for pivoting?
  13. © 2012 Authenticate Back to SCM •  Check to see

    if I can ssh key-auth back to GitHub •  R/RW SSH Key-auth •  Trojan project on SCM?
  14. © 2012 Reverse Shell •  Get a command shell on

    the CI server •  Source –  http://pentestmonkey.net/cheat-sheet/shells/reverse- shell-cheat-sheet
  15. © 2012 Demo #1 •  Background –  I’m a malicious

    person –  I have commit access to your project –  I want to attack your CI •  Target –  Get a shell on the CI server
  16. © 2012 Demo #2 •  Background –  I’m a really

    bad person –  Send Malicious Pull Request –  Get Code Exec on CI –  Leverage SSH key auth fail •  Target –  Use CI to perform unauthorized commit to project(s)
  17. © 2012 rotten_apple •  I created a project on GitHub

    –  http://github.com/claudijd/rotten_apple •  Built on Unit-test Concept –  Pass/Fail Tests •  Two Name Spaces –  RottenApple::Attack –  RottenApple::Audit “Build me on your CI”
  18. © 2012 Target Audiences for rotten_apple •  Developers •  Quality

    Assurance •  System Administrators •  CI Providers (Cloud and non-Cloud) •  Net/App Penetration Testers –  Metasploit payloads/module(s)?
  19. © 2012 Parting Thoughts •  CI servers are open by

    design •  Trust Relationships Exist & Can Be Abused •  Demos –  #1 - CI’s can be used as an Attack Pivot –  #2 - Using GitHub integrated CI’s prevent key trust issues (be wary of user keys vs. deploy keys) •  We should test our CI services for weaknesses