Issue 125: iPhone call recorder API flaw, Burp and OpenAPI, GraphQL pentesting, FAPI 💱

Anand Prakash found an API vulnerability in one of the most popular call recording apps for iPhone – Automatic call recorder. The application has many users and is #15 in the Business Category worldwide in iPhone’s app store.

The vulnerability allowed attackers to get access to any user’s phone recording – thus was extremely sensitive.

Here’s how the vulnerability worked:

1. Researchers decompiled the app and found sensitive details, including S3 buckets and hostnames.

2. They observed the app’s API traffic. The mobile app made a call to the /fetch-sinch-recordings.php API in the cloud:

POST /fetch-sinch-recordings.php HTTP/1.1
Host: 167.88.123.157:80
Content-Type: application/json
Connection: close
Accept: */*
User-Agent: CallRecorder/2.25 (com.arun.callrecorderadvanced; build:1; iOS 14.4.0) Alamofire/4.7.3
Accept-Language: en-IN;q=1.0, kn-IN;q=0.9, hi-IN;q=0.8, hi-Latn-IN;q=0.7
Content-Length: 72
Accept-Encoding: gzip, deflate

{
  "UserID": "xxxxxx",
  "AppID": "xxx"
}

2. The API was not protected with authentication or authorization. An attacker just had to intercept the call and issue their own, changing UserID to the victim’s phone number.

3. The API responded with information about recorded calls of that user, including the AWS S3 URL of the recording:

HTTP/1.1 200 OK
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 413
Connection: close
Content-Type: application/json

[
  {
    "start_time": "1604681",
    "start_time_iso": "2019-10-01T17:58:54+0100",
    "caller_number": "xxxxxxx",
    "callee": "+xxxxxxxxx",
    "marked_as_deleted": "0",
    "user_id": "xxxxxxxxxx",
    "sinch_app_id": "xxxxxxxxxxxx",
    "call_id": "xxxxxxx",
    "s3_key": "call_recordings/1011101/xyzrecording.wav"
  }
]

Lessons learned:

• Your APIs are your attack surface.
• Make sure your APIs require authentication (API2:2019 — Broken authentication)
• Make sure there are authorization checks so one user cannot access data belonging to another (API1:2019 — Broken object-level authorization)
• Returning links to storage obviously means that now that cloud storage access also needs to be protected with both authentication and authorization.

Burp Scanner has added support for API crawling and OpenAPI v3 import.

The blog post referenced above talks about the Burp team’s design decisions when adding REST API support to their crawler. Like in the case of web page crawling, Burp wants to find the system’s attack surface, now including its APIs.

The Burp team is taking advantage of the structured REST API OpenAPI v3 contracts. The tool parses the contract and then uses the following rules to generate “representative” calls. Quoting the blog post:

• Every combination of server (as long as it is in scope) and path methods (GET, POST, etc.). So if we have three servers and an endpoint with a GET and POST method, this would be 3 x 2 = 6 total endpoint locations.
• If optional parameters are defined, the crawler will send at least two requests to that endpoint: one request containing only the mandatory parameters and another request that includes all of the optional parameters as well.
• In the case of enumerated types, the crawler will send a separate request for each of the parameter’s permitted values.
• In the case of numeric values we use the maximum and minimum values as specified.
• If example sets of parameters are provided we use the final provided example.
• If the parameters are not defined in one of the ways listed above we revert back to using Guess and Canary Keys as we do for HTML forms.

Want to practice some GraphQL pentesting? Check out this Generic University lab from Katie Paxton-Fear: https://github.com/InsiderPhD/Generic-University

If you want to learn some theory behind the lab and see it in action, here is Katie’s OWASP London user group talk on that topic:

If you ever used financial applications for your tax returns, financial planning, credit reports, money transfers, and so on, you likely were prompted to give them access to your bank accounts. Doing that by sharing your all-powerful username and password and then letting them scrape the bank web portal is a bad idea. Username and password give full access, beyond your likely much more narrow intent. And scraping easily breaks with any change of the website.

Financial-grade API (FAPI) working group in the OpenID Foundation aims to solve this problem by standardizing APIs that financial institutions use to communicate. The standard describes how OAuth is used to delegate and protect the access, and the JSON schemas for data exchange.

This week, the group reached its major milestone: FAPI 1.0 Part 1 and Part 2 are now Final Specifications.