Published in


2021 App data breaches

In this post, we present our team’s analysis of some of the principal mobile application vulnerabilities of 2021. We are complementing available public information with our team’s expertise.

Twenty years ago, we couldn’t have imagined what cell phones would become. Nowadays, they let us do anything a computer does and are an indispensable device for our everyday lives. As a result, the last decade has seen a growth in the diversity and complexity of mobile application development for different use cases.

The accelerated evolution of mobile software engineering implies a security challenge. While the field’s rapid growth spins the interest for malicious uses, it’s not easy to find experts with the right skillset to analyze applications’ security.

Applications of massive reach become the main focus for teams searching for vulnerabilities due to the high impact of potential exploits.

1.Amazon Ring App Leaks Data: The exact location of users was leaked.

Neighbor is an app that lets users notify crime and safety issues to their neighbors anonymously. The app was developed by Ring, owned by Amazon, and had a bug that threatened all anonymity.

The exact location of every post was stored in Ring’s servers. The app’s API could retrieve this hidden data given certain calls and parameters.

Posts were identified by a counter which incremented every time a new post was created. This IDOR (insecure direct object reference) allowed for easy access to all the app’s post history.

2. Slack Mobile App Exposes User Credentials

On the client-side, user credentials were stored in the application log, unencrypted.

The team could not identify if the app’s logs were sent to android’s standard log services (which would be visible using Logcat), or if they were stored on other files. In the first case, attacks would be limited because user-level applications may only access their logs since Android 4.1. In this case, attackers should meet one of these conditions:

  • Access to another application running with system or root privileges.
  • Access to an RCE bug on the application (in which case logs could be forcefully stored in reachable memory).

As logs are not stored in the device’s hardware, victims should execute the operation that keeps the passwords in the logfile (most probably a login).

In the second case, several possibilities emerge. Methods for leaking files are plentiful and dependent on the application’s logic:

A good presentation of this bug on android can be found here.

  • RCE on the application (easier to exploit, as there is no dependence on an event which accesses the logfile).

3. SHAREbit File Sharing App vulnerable to RCE

Here is a technical detail.

There are three high impact vulnerabilities to analyze.

  1. The component which might develop an RCE is a broadcast receiver called com.lenovo.anyshare.app.DefaultReceiver. It receives messages and calls other components (activities) with the messages it receives. If the application contained a vulnerable activity (which could be used to execute commands through its parameters), the broadcast receiver could be exploited to execute the RCE.
  2. Arbitrary file read/write. The vulnerability allows r/w access to arbitrary files within the application. Android’s permit models don’t authorize access from external applications to SHAREit private files.
  3. Main in the disk. This is a well-known Android vulnerability. The victim application downloads an update or an executable file to the external storage (which can be accessed by any application with the READ_EXTERNAL_STORAGE permit). The attacker must have a running application on the victim’s device for the attack to work: this attacking application is used to monitor the directories in which the executable is being downloaded and replaces every new file it detects. Once the victim finishes their download and opens the file, they execute the exploit instead of the update.

It’s not easy to perform this technique reliably, because of the race condition between the attacker and the victim applications. The attacker must modify the update file before the victim reads it. However, if it’s successfully achieved, the attacker may accomplish a persistent RCE (as the update is executed, the code will remain in the application).

4. Zero-Day in Apple iMessage Affects 900 Million Devices.

The application that holds the vulnerability is iMessage, which is installed by default in OSX.

Attackers found that as a GIF was sent in a message, the application parsed the file in an internal component, which accepted several file types, including PDF.

This component identified if a file should be parsed by reading the name extension, but how to parse it by reading the content of the file. Therefore, attackers could send a .gif file designed to be parsed as a PDF.

Within PDF compression algorithms stands JBIG2. Although its use is no longer recommended, its code is still present in some software. This algorithm has an integer overflow vulnerability.

Details on how this vulnerability was exploited may be found here.

For more information about Faraday products and our new version 🚀⚡, click here




Faraday Platform helps you perform security engineering by maximizing your team’s resources, increasing risk visibility by converting all your data into valuable information https://www.faradaysec.com/

Recommended from Medium

How to Set Up AWS SES and Avoid Spam Folders

Weekly Update 3/8/2022

Cyber Security Strategy

Windows Privilege Escalation: Startup Folder

CoinOne Token Listed on CMC & CG

XUMM Announces Upcoming Integration of FIO Protocol

Offensive Msfvenom: From Generating Shellcode to Creating Trojans

A Look Into DEFCON 201 In 2020

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Faraday Team

Faraday Team

More from Medium

Why Is IoT Security Important? — Informer

Cyber Vault Discovery Part 3 — Difference Analysis

Lets Defend — SOC145 Ransomware Detected

Security Automation — Learning to SOAR