API = Auth Poorly Implemented

Who doesn’t love a robust, easy-to-use, well-documented API? The ability to plug right into an application, a service, an infrastructure, especially in a secure way, is a marvelous feeling. But, what about those mild (and not so mild) oversights? Implementation flaws? Security bugs? Legacy APIs being “integrated” with new, flashy RESTful APIs?

In this talk, we’ll highlight some real-world examples of web-related API security problems, notably surrounding authentication and authorization issues in targets ranging from a big online payment shop to an embedded device’s backend infrastructure (and a slew of things in between).

Transcript

1. API = Auth Poorly Implemented AppSec California 2015
2. AGENDA • Intro • Issues & Examples • Solutions • Conclusion 2
3. About Me • Senior Research Scientist, Applied Research, Accuvant Labs R&D • Previously Senior Security Researcher at Duo Security • Hence a presentation about authentication security ;) • Old net/web/app/mobile pen tester type • Co-author of "Android Hacker's Handbook" (Wiley, April 2014) 3
4. About This Talk • Discussing common issues either directly related to or otherwise affecting authentication and authorization security in various APIs • Some of these findings are mine; some were discovered/disclosed by others (credit given where due) • Suffice to say, certainly not an exhaustive list of issues, examples, or solutions
 • Obligatory disclaimer: views in this presentation may not be those of my employer; solutions listed herein should not necessarily be considered "endorsements" 4
5. "LEGACY" API INTEGRATION 5
6. "Legacy" API Integration • "Legacy" APIs (e.g. SOAP, XML RPC, etc.) integrated or • Inconsistent enforcement of AuthC/AuthZ between APIs • Inadequate support for current standards • Or fall back to least common, likely-insecure denominator 6
7. Example: PayPal 2FA Bypass • Initially discovered/reported by Daniel Saltman of Everydaycarry.com in March 2014 • RCA & "refinement" by some jerk named Zach Lanier (while at Duo Security) • Due to discrepancy between RESTful mobile API and "legacy" (SOAP) transaction API, primary credentials alone were sufficient to access 2FA enabled accounts 7
12. BUG INHERITANCE 12
13. Bug Inheritance • Vulnerabilities in underlying/backend components give rise to (unanticipated) security issues in APIs • e.g. databases, libraries, runtimes, frameworks, etc. • "Castles built on sand" 13
14. Example: MySQL Typecasting Vuln • Integer and string comparison issue in MySQL • Discovered/reported by Joernchen of Phenoelit in February 2013 • Allowed for an auth bypass in GitHub API 14 mysql> SELECT 123 FROM dual WHERE 1=1; +-----+ | 123 | +-----+ | 123 | +-----+ 1 row in set (0.00 sec) mysql> SELECT 123 FROM dual WHERE 1="1"; +-----+ | 123 | +-----+ | 123 | +-----+ 1 row in set (0.00 sec) mysql> SELECT 123 FROM dual WHERE 1="1somestring"; +-----+ | 123 | +-----+ | 123 | +-----+ 1 row in set, 1 warning (0.00 sec) mysql> SELECT 123 FROM dual WHERE 1="somestring"; Empty set, 1 warning (0.00 sec) mysql> SELECT 123 FROM dual WHERE 0="somestring"; +-----+ | 123 | +-----+ | 123 | +-----+ 1 row in set, 1 warning (0.00 sec)
15. CLIENT-SIDE ENFORCEMENT 15
16. Client-side Enforcement • Enforcement or control of a process or a significant element occurs solely within the client • e.g. a counter; session "termination" / logout • Server/API intrinsically trusts "decision" by client in some operation • All too common in mobile ¬_¬ 16
17. Example: Toymail Credit API • Reported by Mark Stanislav in December 2013 • Purchasing in-app credits for use with the device via the app store lets the mobile application dictate that a purchase occurred: • Pick a number… any number • Make an API call with that number • Gain that many “credits” for your account 17
18. INFORMATION EXPOSURE 18
19. Information Exposure • API / server response reveals more information than necessary • e.g. session or state information; sensitive or internal endpoints; user IDs or keys • Information often used to facilitate privilege escalation 19
20. Example: Toymail "Friend" AuthZ issue • Reported by Mark Stanislav in December 2013 • Sensitive details about a user were provided prior to authorization from said user: • Send "friend" request • Initial server response contains enough information to invoke other methods on target user -- regardless of whether user accepts/denies "friend" request • Fix: Don’t transmit data ahead of authorization, even if the UI won’t expose it. If it goes over the wire, it’s out of your control now. 20
21. INSECURE COMMUNICATIONS 21
22. Insecure Comms • Complete lack of encryption for transmitted data • Yes, this still happens • Weakly encrypted data in transit • Falling back to plain text after failures 22 (Of course this is not unique to API auth security.)
23. Example: IZON IP Camera • API calls for third-party services were done without SSL/ TLS & used an MD5-sum of the user’s IZON password as a secret • Hypothetical Exploit: • Go to Starbucks • MITM network traffic • Wait for someone to check their video camera • Retrieve their MD5’ed password, crack, repeat 23
24. ALTERNATE PATHS/ CHANNELS 24
25. Alternate Paths/Channels • Exercising a different code path could allow for sidestepping some auth or entitlement check • Ex. setting a particular flag or hitting an alternate entry point / login form • This happens to be CWE-288 ;PpPPpPPppP • Could also be an inherited / underlying issue... 25
26. Example: WordPress Plugin API Issue • WordPress plugin API • Hooks for adding additional AuthC and AuthZ steps • Root cause: • No direct ability to enforce/check second factor flag/ state for users in multisite deployment who log into a different site (where 2FA is not enabled) • Discovered by Omar Abdul-Jabbar of Duo Security in February 2014 • Allowed for bypass of 2FA in nearly all vendors' plugins 26
28. STATIC / SHARED CREDENTIALS 28
29. Shared / Static API Credentials • Application uses the same username & password or key across multiple principals or users • Shared API keys often used for identifying a particular developer or for inter- service/inter-API interaction • e.g. Flickr, Google Maps, etc. • Also, hardcoded creds as deliberate or unintentional backdoor 29
30. Example: Moonpig API • Disclosed by Paul Price in August 2013 (disclosed in January 2015 [wtf?]) • Static (HTTP Basic Auth) credentials sent for every API request • Only truly "unique" value was customerId • Allowed for impersonating any Moonpig customer 30 GET /rest/MoonpigRestWebservice.svc/addresses? &customerId=5379382&countryCode=9424 HTTP/1.1 Authorization: Basic aXBjiS5lOk1vb25QHjimvF58DEw Host: api.moonpig.com Connection: Keep-Alive
31. FAILURE TO RESTRICT PRIVILEGED FUNCTIONALITY 31
32. Failure To Restrict Privileged Functionality • Lower-privileged principals (roles, users, etc.) have unrestricted access to API actions/methods that provide privileged functionality • Colloquial example: creating new user accounts; adding existing account(s) to administrative groups • External authorities (OpenID, OAuth, other federation), could exacerbate privilege discrepancies • Confused deputy? 32
33. Example: Liferay API Privesc • Disclosed by Danilo Massa & Enrico Cinquini in August 2012 • Unrestricted access to the updateOpenId method allowed for setting arbitrary OpenID identifier/user on target Liferay accounts • Massa's and Cinquini's steps: • Create an OpenID user on some provider • Call getUserById iteratively to enumerate users • Call getUserRole against users to find an admin • Call updateOpenId and set target admin's OpenID attribute to your OpenID 33
34. SOLUTIONS 34
35. WSDL 2.0 • Web Services Definition Language v2.0 adds in support for describing RESTful services • Elements include: • types (defines schema and web service's messages) • interface (input, output, faults, and their order) • binding (how client communicates w/service) • service (associates address to interface & binding) 35 <wsdl:interface name="BookListInterface"> <wsdl:operation name="getBookList" pattern="http://www.w3.org/ns/wsdl/in-out" style="http://www.w3.org/ns/wsdl/style/iri" wsdlx:safe="true"> <wsdl:documentation> This operation returns a list of books. </wsdl:documentation> <wsdl:input element="msg:getBookList"/> <wsdl:output element="msg:bookList"/> </wsdl:operation> </wsdl:interface>
36. WADL • Web Application Description Language • tl;dr - WSDL for REST • Describes resources, inputs, parameters, expected responses (including expected Content-Type) • Submitted to W3C in 2009, but not standardized • Ex. Apache CXF JAX-RS supports WADL for service definitions 36
37. Swagger • Originally by Wordnik, maintained by Reverb • Specification and interface for RESTful APIs • "Define" API (to Swagger spec), then generate documentation, code, and a testing sandbox • Think "IDL" for REST • Numerous libraries • Python, Ruby, PHP, .NET, and more 37 { "swaggerVersion": "1.2", "basePath": "http://localhost:8000/greetings", "apis": [ { "path": "/hello/{subject}", "operations": [ { "method": "GET", "summary": "Greet our subject with hello!", "type": "string", "nickname": "helloSubject", "parameters": [ { "name": "subject", "description": "The subject to be greeted.", "required": true, "type": "string", "paramType": "path" } ] } ] } ] } Example Swagger definition
38. Swagger • Supports APIs with various security schemes (and respective requirements) such as HTTP Basic Auth, generic API Keys, and OAuth2 • "Testing sandbox" assists with ensuring security requirements are met and enforced • NOT a panacea - developers must still build API definitions (including security requirements) 38
39. Swagger testing UI 39
40. Conclusion / Q&A • Certainly not a new nor an exhaustive (or unique) list of issues or solutions • Barely scratched the surface here • What's old is new again / all this has happened before, etc. etc. 40 Greetz: aloria, schenette, k8em0, zane, cmiller, russ gideon, peleus, dildog, jhaddix, ceng, casey, ilja Questions? zach@n0where.org zlanier@accuvant.com @quine