SHAREit App Flaws Allow Hackers to Steal Files

Two high-severity flaws in the SHAREit Android app allow an attacker to bypass the file transfer application’s device authentication mechanism – and ultimately download content and arbitrary files from the victim’s device, along with a raft of data such as Facebook tokens and cookies.

SHAREit is an app allowing users to transfer their video, music, files and apps across various devices. The app has been downloaded by more than 500 million users, according to its website. The vulnerabilities, which now have a patch available, were disclosed Monday by the researchers at Redforce who discovered them.

Here SHAREit MediaStore database containing interesting information about files in the system including file name, type, size, path, and more other information.

SHAREit App

“Although the vulnerability was originally discovered in December 2017 and officially fixed in March 2018, we decided not to disclose vulnerability details before today given the impact of the vulnerability, its big attack surface and ease of exploitation,” said Abdulrahman Nour, security engineer at Redforce, in a post. “We wanted to give as many people as we can the time to update and patch their devices before disclosing such critical vulnerability.”

The flaws, which could be exploited by an attacker on a shared WiFi network, have a CVSS 3.0 score of 8.2, meaning they are high-severity

An attacker on the same WiFi network as the victim could see if the victim’s device is running SHAREit server by simply checking if two designated ports are open: Port 55283 and Port 2999.

The former is a regular TCP channel where the app exchanges messages with other SHAREit instances on different devices – including device identification and file transmission requests. Port 2999 meanwhile is the app’s HTTP server implementation used by other clients to download shared files.

“What makes it even of greater risk is that vulnerable SHAREit application create an ‘open’ WiFi hotspot with an easily distinguished name (SSID) in order to share files,” Nour told  “Identifying such open WiFi networks is a strong indicator of a SHAREit device [existing] around an attacker.”

Once a SHAREit user has been identified, it’s relatively simple to compromise the system, researchers said.

When someone uses SHAREit to send a file, the regular file transfer session starts with the authentication of a device, then the “sender”  transfers a control message to the “receiver” to indicate that it has a file to send, researchers said. If “receiver” decides that it is not a duplicate file, it goes to download channel and fetches the sent file, using information from the previous control message.

However, the team discovered that when a user with no valid session tries to fetch a non-existent page – which could be as simple as [curl http://shareit_sender_ip:2999/DontExist] — a glitch in the app causes it to authenticate the user, “making this the weirdest and simplest authentication bypass we ever have seen.”

That’s because the app fails to validate the msgid parameter – a unique identifier for each request to make sure that the downloaded request was originally initiated by the sender.

“The odd behavior occurs when an unauthenticated user tries to fetch the non-existing page, instead of a regular 404 page, the application responds with a 200 status code empty page and adds the user into recognized devices!!” said Nour.

The glitch essentially means that bad actors could be added to a victim’s trusted devices by just sending them a request trying to fetch a non-existent page.

 “if the device still does not authorize the attacker’s download requests, it completes the normal SHAREit device handshake in order to add the device into trusted devices (but this requires that the victim has already initiated file transfer session and it appears on user’s screen), so the first method is tried first to stay stealthy,”

From there, if attackers know the exact location of the file they would like to retrieve, they can send a curl command, which references the path of the target file to retrieve and download it.

This is easier than it sounds, because several files with known paths already are publicly available, including the SHAREit history database, which contains records of all files exchanged using SHAREit application; and the SHAREit MediaStore Database, which contains records of most of the media files on the device, said Nour.

“There are other files that contain juicy information such as user’s Facebook token, Amazon Web Service user’s key, auto-fill data and cookies of websites visited using SHAREit webview and even the plaintext of user’s original hotspot (the application stores it to reset the hotspot settings to original values) and much more,” said researchers

A proof of concept video of the hack is below.

https://www.youtube.com/watch?v=xzoJXBCznWc

This vulnerability was originally discovered on back to December 2017 and the silent fix was done but SHAREit team refusing to disclose the exact patched version nor assign CVE numbers to discovered vulnerabilities. Exploit can be downloaded from our GitHub repository.

Leave a Comment

Your email address will not be published. Required fields are marked *

eight + 8 =