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

Suprise Features in your Favorite Framework

Suprise Features in your Favorite Framework

Authors: Andrew Kampjes & Mike Haworth

Modern web frameworks allow developers to be productive, however they are feature rich and not every feature is well understood. Some of these features can work in unexpected ways and can be leveraged by attackers. This talk will look at some of the gotchas in popular frameworks. We'll also look at the ways popular features such as social logins can go wrong.

Andrew Kampjes

February 27, 2015
Tweet

More Decks by Andrew Kampjes

Other Decks in Programming

Transcript

  1. Features and Corner Cases We rely on frameworks to do

    a lot of security heavy lifting But, there are still often edge cases to deal with
  2. Features and Corner Cases 1. Social Login 2. Regex 3.

    Server Side Request Forgery (SSRF) 4. Mass Assignment 5. Storing Application State
  3. Oauth2 Woes Unlike Oauth1a each request is not individually signed

    against tampering. This opens the door for Cross Site Request Forgery (CSRF). In some setups, if your site has an open redirect, you could leak access_token
  4. Step 2 cats.com facebook.com facebook.com joe user browser “cats.com wants

    access to your facebook” joe authorizes cats.com
  5. Step 3 cats.com facebook.com facebook.com joe user browser cats.com recieves

    authorization code code sent by redirecting from facebook to cats.com
  6. OmniAuth: CVE-2013-4562 1. Attacker enables cats.com to auth with facebook,

    this triggers a redirect to cats.com 2. Attacker grabs that redirect before it hits cats.com 3. Attacker uses this request CSRF user 4. Attacker’s facebook account is now connected to cats.com https://github.com/mkdynamic/omniauth-facebook/wiki/CSRF-vulnerability:-CVE-2013-4562
  7. Attacker’s facebook auth is now bound to Joe’s cats.com account

    Facebook account of attacker Facebook account of Joe User cats.com account of attacker cats.com account of Joe User
  8. Social Login Summary 1. Use ‘state’ parameter to check for

    CSRF 2. Open redirects can leak tokens 3. Implicit flow is hard to secure, as user can see access_token 4. If you have a choice, consider saml2 or oauth1a (its not a downgrade!) Oauth2 security cheat sheet: http://www.oauthsecurity.com/
  9. Ruby Regex ^......$ matches start-end of line \A…\z matches start-end

    of string /\Ahttps?:\/\/[^\n]+\z/i Not every language supports \A,\z
  10. SSRF Example: API test page - User provides URL for

    remote API - Server makes request to API - Displays response to user
  11. SSRF: Bottle app @post('/fetch') def fetch(): url = request.forms.get('url') req

    = urllib2.Request(url) response = urllib2.urlopen(req) return response.read()
  12. SSRF Attacker with SSRF could: - access services on localhost

    - access other hosts in DMZ - bypass host based security restrictions
  13. SSRF Services that rely on host based auth: - memcached

    - Docker’s REST API (not enabled by default) - mongod REST API (read only) - CouchDB - lots more...
  14. SSRF and Python Libs urllib3 and requests libs only accept

    http(s):// - Attacker can’t change a GET to a POST urllib, urllib2 and pycurl support file:// - Can read a local file!
  15. Local file read from urllib2 @post('/fetch') def fetch(): url =

    request.forms.get('url') req = urllib2.Request(url) response = urllib2.urlopen(req) return response.read()
  16. SSRF and Python Libs pycurl accepts gopher:// THATS RIGHT, GOPHER!

    Can send any data (except 0x00) just URL encode it
  17. Forging a POST to internal host Forging a request to

    an internal host with gopher: gopher://192.168.43.235:8888/2%50%4f%53%54%20%2f%61%64%64%75%75%73%65%72%20% 48%54%54%50%2f%31%2e%31%0a%48%6f%73%74%3a%20%69%6e%74%65%72%6e%61 … The receiver sees POST to API from allowed host: POST /internal-api/adduser HTTP/1.1 Host: internal-api.server.local Content-Type: application/x-www-form-urlencoded Content-Length: 49 username=hax0r&password=hax0r
  18. SSRF memcached memcached speaks a plaintext protocol accessible without auth

    on port 11211 http://www.slideshare.net/d0znpp/ssrf-workshop
  19. SSRF memcached Example telnet session with memcache $ telnet localhost

    11211 set mykey 0 0 6 mydata STORED get mykey VALUE mykey 0 6 mydata END
  20. Mass Assignment Affects many MVC frameworks... not just a Rails

    issue Django, Spring, Struts, CakePHP, .NET MVC...
  21. Mass Assignment Solved problem in Rails tho’ right? Most frameworks

    have some sort of approarch to deal with mass assignemnt
  22. Example of Storing Application State 1. Signed Cookies • Rails

    Cookiestore • Django cookie-based-store 2. ViewState • ASP.NET • JSF Viewstate
  23. Common issues 1. Replay attack 2. Lack of server side

    logout 3. Sensitive data 4. Encryption fails 5. Deserialisation woes
  24. 1) Replay attacks What if my shopping app was to

    store my discount (one use) modifier in the cookie (remember its signed so can’t tamper) I can use the discount code, then replay an old cookie to apply code again, and again...
  25. Defending against replay Ask: If we trust the client with

    state, do we use a nonce to prevent replay? i.e. does each state include a non predictable number thats included when signing
  26. 2) No server side logout Client storage means no server

    side logout This could result in a compromised app granting a malicious user a cookie that never expires. “Golden Ticket” https://www.trustwave.com/Resources/SpiderLabs-Blog/Jamming-With-WordPress-Sessions/
  27. Wordpress Session Example Session id is not stored in DB

    Cookie format: user|timestamp|hash Where hash is depends on 2 secrets 4 chars of password hash + site secret So if site is ever compromised, attacker could create a cookie that never expires
  28. Adding server side logout We could keep a blacklist of

    disallowed sessions. Back where we started with keeping state on server again
  29. Storing Sensitive Data What if the application requires 2FA? Enter

    username/password, app sends 2FA SMS -- Yay security! App stores 2FA token in session -- facepalm
  30. 4) Encrypting State Laravel: encrypted and signed cookie Failed to

    include IV when checking signed cookie, user id can be forged Type juggling madness leads to fail in signature check and padding oracle allows extraction of ciphertext https://labs.mwrinfosecurity.com/blog/2014/04/11/laravel-cookie-forgery-decryption-and-rce/ (2014)
  31. 5) Deserialisation woes Serialisation: Object -> Serialized -> Base64 Deserialisation:

    Base64 -> Serialized -> Object Deserializing untrusted objects may to RCE
  32. Unpickling user data class Exploit(object): def __reduce__(self): return (os.system, ('touch

    /tmp/pwnd',)) # this is run when obj is created pickled = pickle.dumps(Exploit()) print pickled pickle.loads(pickled) https://blog.nelhage.com/2011/03/exploiting-pickle/
  33. 5) Deserialisation woes Django 1.6 switched to JSON but... Some

    Python Frameworks still using pickle: - Bottle - Pylons/Pyramid - Werkzeug - Beaker
  34. 5) Deserialization summary 1. Don’t deserialize data from the user

    2. Protect your unique server side secret, don’t commit it to github 3. Use a low risk serialisation format like JSON
  35. Take aways At some point we have to trust that

    the framework does it ‘right’ ..but... Insight into the framework ‘magic’ helps when making security decisions