News quickly spread about a vulnerable call recording app for iPhone named “Call Recorder,” or “Acr call recorder,” as its listing in the Apple App Store states. TechCrunch was the first outlet to flag a design flaw with the mobile application’s API when it obtained call recordings from AWS S3 cloud storage to prove it was insecure and therefore open to API-based attacks. The weaknesses exhibited by the mobile app represent a vital shift occurring in cybersecurity towards the importance of the protection and hardening of APIs. From this instance alone, we can learn a number of valuable lessons as API attacks are set to rise drastically this year.

Most of the issues in the Call Recorder vulnerability map directly to the OWASP API Security Top 10, a list that captures the most common API mistakes. This document is a great reference for DevOps and security teams that are looking to implement strong API security that can be applied to both web and mobile application systems, including those in the cloud.

Call Recorder Security Issues

To users’ benefit, it is not clear if any malicious parties found these issues prior to TechCrunch publicly disclosing information about the API flaws. The issue seemed to arise only after security researcher Anand Prakash of Pingsafe AI discovered it by reverse engineering the iOS mobile binary, located within the iOS App Store package (IPA). Techniques and tooling to do such reverse engineering are readily available on the Internet.

Unlike common assumption, a mobile application binary is not a “black box,” and practitioners should not consider it protected by default. Attackers can put the same tools to use to reverse engineer mobile code, which can result in theft of intellectual property and the harvesting of API keys. Similarly, tools used to intercept proxies, such as Charles Web Debugging Proxy and OWASP Zed Attack Proxy, are used by both researchers and attackers to expose application communication issues and/or manipulate them. 

In the case of the Call Recorder application, a number of issues exposed users to risk (which are all resolved now):

• Broken authentication – It is clear by reviewing the POST request that Prakash sent through the mobile app that its endpoint was not enforcing authentication. He found that the HTTP headers that were present lacked any type of cookie or token to mitigate against this.
• Broken object level authorization (BOLA) – Prakash’s ability to alter the value of the User ID, demonstrates that the app system returned the location of recordings for another user, once again failing to enforce authorization and demonstrating another weakness in the API endpoint.
• Lack of encrypted transport – It is critical that developers implement HTTPS rather than HTTP, the latter of which was the case for Call Recorder, to ensure transported data is encrypted and not intercepted or manipulated as traffic flows between the mobile application and back end services.
• Excessive data exposure – In Call Recorder, the HTTP response from the API endpoint contained the URL of recordings in an AWS S3 bucket in the “s3_key” value, which could have easily been pulled by an attacker using this information. In addition, metadata about the caller and callee phone numbers were able to be accessed. This form of personally identifiable information (PII) is also considered regulated data. It is essential that organizations implement controls to make sensitive data pseudonymized, masked, tokenized, encrypted, or not used at all.
• Lack of pseudonymous identifiers – Record and object identifiers should not be predictable or sequential, nor should they allow an attacker to infer the identity of an individual. With the Call Recorder application, the “UserID” was directly correlated to a user’s phone number, which could have been identified through a reverse phone number lookup.
• Unsecured cloud storage – A common oversight for AWS-base storage, even in public Git repositories, is that its Simple Storage Service (S3) buckets may not be locked down. In Call Recorder, reporter Zack Whittaker from TechCrunch was able to see that the bucket used by the app contained 130,000 recordings and more than 300 GB of data.

Lessons Learned

While the iPhone Call Recorder application, again, caused no noticeable harm, the case is a prime example of why application security and particularly API security should be top of mind for any developer. It also presents a number of valuable lessons and best practices:

1. ‍Harden your mobile application code: Developers and security experts should always assume that mobile code will be reverse engineered – it’s typically the starting point for an attacker. Intellectual property or authentication material should never be stored there. ‍
2. Set up both authentication and authorization: Authentication and authorization must always be accounted for. If we consider the entire Call Recorder application system end to end, it is clear that authentication was not present in the API calls made by the mobile app, authorization was non-existent, and access to AWS S3 buckets where call recordings were kept was not controlled. ‍
3. Use unique identifiers: Using unique, non-predictable and non-sequential identifiers is key to reducing enumeration attacks. In the case of Call Recorder, the identifiers used directly impact privacy since a phone number is a form of PII. App developers should have created new identifiers instead of using a phone number as the unique identifier. ‍
4. Protect API data at all costs: Encrypted transports are key for application traffic to securely exchange sensitive data, like phone numbers or other regulated data types. IT teams are experiencing more API-based attacks than ever before. Only data necessary for the app to function should be returned, especially if it contains sensitive information – obscuring or masking such data in the user interface (UI) is not effective!

Securing Our Apps for the Future

The Call Recorder application’s impacts are immediately evident. Should an attacker succeed and obtain a highly sensitive recorded conversation, that user’s privacy is immediately gone, and critical information could be at stake. On the developer front, this “case study” also highlights the implications of insecurely hardening an application from end-to-end, such as exposing call recordings and user data, and the regulatory impacts of exposed PII in the metadata in traffic. 

 IT teams that are building applications should document security processes and disclose policies, which unfortunately are uncommon practices to see in public mobile app stores or from individual developers. With the barrier to entry for building and publishing mobile applications so low, customers will appreciate the added protection and transparency. 

Apple or Google may seem like the culprits for not setting strict enough regulations for the applications in their respective app stores, but the OS vendors are doing what they can. They deal with thousands of app submissions daily and employ a mix of automated scanning with static and dynamic analysis tools, augmented of course with manual review from in-house subject matter experts as appropriate.

In alignment with the growing “shift-left” culture, Call Recorder is an example of an application that could have been properly secured from day zero, as it was being designed. However, it is also a weakness of scanners as they are limited in finding exploitable business logic of APIs.  Efficacy only worsens as these scanning tools are integrated and automated within build pipelines. Apple and Google face a balancing act: they opt for what is “good enough” with security scanning measures to make users feel safe while satisfying developers who want to quickly publish their apps to the public app stores.

Most organizations acknowledge that automatically scanning all code pre-deployment with full test coverage (and expecting to catch all types of issues) is unrealistic. They will regularly augment with internal manual review, externally sourced application assessments, bug bounty programs, and more importantly, behavior analysis in runtime. Still, IT teams should be aware of the constant threat of someone attacking their applications and increasingly their APIs – and they can learn a lot from cases like the Call Recorder incident to better prepare for the future.