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.
“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, researchers told Threatpost.
Nour told Threatpost that first of all, 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 a greater risk is that vulnerable SHAREit applications create an ‘open’ WiFi hotspot with an easily distinguished name (SSID) in order to share files,” Nour told Threatpost. “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 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 unauthenticated user tries to fetch 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.
Alternatively, “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 victim has already initiated file transfer session and it appears on user’s screen), so the first method is tried first to stay stealthy,” the researcher told Threatpost.
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 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
Researchers discovered the flaws in December 2017, and it was fixed March 2018. Users should update their apps as soon as possible.
While the vulnerability was patched, the app-maker did not provide researchers with exact patched versions, vulnerability CVE numbers or any comments for the public disclosure: “Communication with SHAREit team was not a good experience at all; not only they took too long to respond to our messages, they also were not cooperative in any means and we did not feel that our work or efforts were appreciated at all,” said Nour.
SHAREit has not yet responded to a request for comment from Threatpost.
