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.

Transcript

1. In your favourite framework Surprise Features
2. 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
3. Andrew Kampjes - @akampjes -- Writes code Mike Haworth - Aura -- Breaks his code
4. Features and Corner Cases 1. Social Login 2. Regex 3. Server Side Request Forgery (SSRF) 4. Mass Assignment 5. Storing Application State
5. Oauth2 Social Login
6. 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
7. Oauth2 Authorization Flow
8. Step 1 cats.com facebook.com facebook.com joe user browser joe requests access, gets redirected to facebook
9. Step 2 cats.com facebook.com facebook.com joe user browser “cats.com wants access to your facebook” joe authorizes cats.com
10. 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
11. Step 4 cats.com facebook.com facebook.com joe user browser cats.com requests access token from facebook
12. Step 5 cats.com facebook.com facebook.com joe user browser cats.com recieves access token
13. OmniAuth Example What if we can CSRF step 3?
14. 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
15. 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
16. Authorization flow vs Implicit flow Note step 4: Access token is sent from app to auth server
17. Oauth2: Implicit Flow Note step 4: Access token is now seen by client (redirected)
18. 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/
19. Regex
20. Regex Most regex parsers work a little differently
21. Ruby Regex Lets validate that links are links: <a href=”http://blah.com”>homepage</a>
22. Ruby Regex Don’t allow: <a href=”javascript: alert(1)”>homepage</a>
23. Ruby Regex Validate URL (loosely) /^https?:\/\/[^\n]+$/i Matches http://blah.com
24. Ruby Regex /^https?:\/\/[^\n]+$/i javascript: alert(1);/* http://blah.com */
25. Ruby Regex Woops <a href=”javascript: alert(1)/* http://blah.com*/”>homepage</a>
26. Ruby Regex ^......$ matches start-end of line \A…\z matches start-end of string /\Ahttps?:\/\/[^\n]+\z/i Not every language supports \A,\z
27. Ruby Regex Good news though! Rails gives warnings on launch.
28. SSRF Server Side Request Forgery
29. SSRF Example: API test page - User provides URL for remote API - Server makes request to API - Displays response to user
30. SSRF
31. SSRF: Bottle app @post('/fetch') def fetch(): url = request.forms.get('url') req = urllib2.Request(url) response = urllib2.urlopen(req) return response.read()
32. SSRF: Bottle app
33. SSRF Attacker with SSRF could: - access services on localhost - access other hosts in DMZ - bypass host based security restrictions
34. 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...
35. 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!
36. 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()
37. SSRF and Python Libs pycurl accepts gopher:// THATS RIGHT, GOPHER! Can send any data (except 0x00) just URL encode it
38. 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
39. SSRF memcached memcached speaks a plaintext protocol accessible without auth on port 11211 http://www.slideshare.net/d0znpp/ssrf-workshop
40. 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
41. SSRF and memcache gopher://127.0.0.1:11211/2get%20mykey%0Aquit
42. Preventing SSRF
43. Preventing SSRF
44. Mass Assignment
45. Mass Assignment Affects many MVC frameworks... not just a Rails issue Django, Spring, Struts, CakePHP, .NET MVC...
46. Scenario <input name="user[name]" value="Andrew"> <input name="user[address]" value="......">
47. Scenario <input name="user[name]" value="Andrew"> <input name="user[address]" value="......"> <input name="user[is_admin]" value="true">
48. Github
49. Scenario <input name="public_key[key]" value="ssh-rsa AAAA...">
50. Scenario <input name="public_key[key]" value="ssh-rsa AAAA..."> <input name="public_key[user_id]" value="1234">
51. Mass Assignment: Example POST /user user[password]=derp2&user[user_car_attributes[0][dollar_value]=1] user user_car has_many name: mike name: toyota dollar_value: 100 password: derp
52. Mass Assignment Solved problem in Rails tho’ right? Most frameworks have some sort of approarch to deal with mass assignemnt
53. Mass Assignment prevention Blacklisting Whitelisting Form tampering prevention (via signing)
54. Mass Assignment Summary Use defences provided by your framework but be aware of their limitations
55. … with the client Storing Application State
56. Example of Storing Application State Traditionally server keeps track of state Cookies only contained a session_id
57. Example of Storing Application State 1. Signed Cookies • Rails Cookiestore • Django cookie-based-store 2. ViewState • ASP.NET • JSF Viewstate
58. Advantages 1. Don’t need to do database lookups 2. Low memory cost 3. Very scalable
59. Common Implementation HMAC Serialized Objects
60. Common issues 1. Replay attack 2. Lack of server side logout 3. Sensitive data 4. Encryption fails 5. Deserialisation woes
61. 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...
62. 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
63. Defending against replay But then we’re back where we were, we have to store the nonce somewhere.
64. 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/
65. Server side logout
66. 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
67. Adding server side logout We could keep a blacklist of disallowed sessions. Back where we started with keeping state on server again
68. 3) Storing Sensitive Data BAh7C0kiD3Nlc3Npb25faWQGOgZFRkkiJTJlN zMxMjZlYzAyMDQyMzk2NDIwMDQ3OWZlOTk 1OGY5BjsAVEkiBngGOwBGaQZJIh13YXJkZ W4udXNlci5jdXN0b21lci5rZXkGOwBUWwdbB mkCUZ9JIiIkMmEkMTAkdnlZRmE0U2ZlZWYy S2t1Zy8vYk1VLgY7AFRJIhBfY3NyZl90b2tlbgY 7AEZJIjEzSGt0NGZMY0NuUG1VV1gweTl6eV U3eFR0ejZ4eWN2cUlhWVJBeW5aWEFBPQY
69. 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
70. Base64 decode... {I"session_id:EFI"% 2e73126ec020423964200479fe9958f9;TI"x;FiI" warden.user.customer.key;T [[iQ�I""$2a$10$vyYFa4Sfeef2Kkug//bMU.;TI" _csrf_token;FI" 13Hkt4fLcCnPmUWX0y9zyU7xTtz6xycvqIaYR AynZXAA=;FI"2factor_token;Fi|"2847;
71. Defending against sensitive data Don’t put sensitive data in client data OR
72. Common Implementation HMAC Serialized Objects Crypto Dust
73. 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)
74. 4) Encrypting State TL;DR encrypting things goes wrong too Don’t roll your own etc.
75. 5) Deserialisation woes Rails: Marshal Python: Pickle etc...
76. 5) Deserialisation woes Serialisation: Object -> Serialized -> Base64 Deserialisation: Base64 -> Serialized -> Object Deserializing untrusted objects may to RCE
77. 5) Deserialisation woes If the application secret is compromised Deserializing untrusted objects may to RCE
78. 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/
79. 5) Deserialisation woes Django 1.6 switched to JSON but... Some Python Frameworks still using pickle: - Bottle - Pylons/Pyramid - Werkzeug - Beaker
80. 5) Deserialisation woes Rails Marshall --same shit Rails 4.1+ uses JSON by default
81. 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
82. 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
83. Aura is Hiring Pentesting Challenges http://tinyurl.com/h4ckit