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
   

   View Slide

2. AGENDA
   • Intro
   • Issues & Examples
   • Solutions
   • Conclusion
   2
   

   View Slide

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
   

   View Slide

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
   

   View Slide

5. "LEGACY" API
   INTEGRATION
   5
   

   View Slide

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
   

   View Slide

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
   

   View Slide

8. View Slide

9. View Slide

10. View Slide

11. View Slide

12. BUG INHERITANCE
    12
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

15. CLIENT-SIDE
    ENFORCEMENT
    15
    

    View Slide

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
    

    View Slide

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
    

    View Slide

18. INFORMATION
    EXPOSURE
    18
    

    View Slide

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
    

    View Slide

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
    

    View Slide

21. INSECURE
    COMMUNICATIONS
    21
    

    View Slide

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.)
    

    View Slide

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
    

    View Slide

24. ALTERNATE PATHS/
    CHANNELS
    24
    

    View Slide

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
    

    View Slide

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
    

    View Slide

27. View Slide

28. STATIC / SHARED
    CREDENTIALS
    28
    

    View Slide

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
    

    View Slide

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
    

    View Slide

31. FAILURE TO RESTRICT
    PRIVILEGED
    FUNCTIONALITY
    31
    

    View Slide

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
    

    View Slide

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
    

    View Slide

34. SOLUTIONS
    34
    

    View Slide

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
    
    pattern="http://www.w3.org/ns/wsdl/in-out"
    style="http://www.w3.org/ns/wsdl/style/iri"
    wsdlx:safe="true">
    
    This operation returns a list of books.
    
    
    
    
    
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

39. Swagger testing UI
    39
    

    View Slide

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
    

    View Slide