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

API = Auth Poorly Implemented

Zach Lanier
January 27, 2015

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

Zach Lanier

January 27, 2015
Tweet

More Decks by Zach Lanier

Other Decks in Technology

Transcript

  1. API = Auth Poorly
    Implemented
    AppSec California 2015

    View full-size slide

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

    View full-size 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 full-size 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 full-size slide

  5. "LEGACY" API
    INTEGRATION
    5

    View full-size 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 full-size 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 full-size slide

  8. BUG INHERITANCE
    12

    View full-size slide

  9. 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 full-size slide

  10. 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 full-size slide

  11. CLIENT-SIDE
    ENFORCEMENT
    15

    View full-size slide

  12. 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 full-size slide

  13. 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 full-size slide

  14. INFORMATION
    EXPOSURE
    18

    View full-size slide

  15. 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 full-size slide

  16. 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 full-size slide

  17. INSECURE
    COMMUNICATIONS
    21

    View full-size slide

  18. 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 full-size slide

  19. 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 full-size slide

  20. ALTERNATE PATHS/
    CHANNELS
    24

    View full-size slide

  21. 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 full-size slide

  22. 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 full-size slide

  23. STATIC / SHARED
    CREDENTIALS
    28

    View full-size slide

  24. 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 full-size slide

  25. 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 full-size slide

  26. FAILURE TO RESTRICT
    PRIVILEGED
    FUNCTIONALITY
    31

    View full-size slide

  27. 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 full-size slide

  28. 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 full-size slide

  29. 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 full-size slide

  30. 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 full-size slide

  31. 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 full-size slide

  32. 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 full-size slide

  33. Swagger testing UI
    39

    View full-size slide

  34. 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?
    [email protected]
    [email protected]
    @quine

    View full-size slide