![]() Luckily for us, vulnerable SHAREit versions create an easily distinguished open Wi-Fi hotspot which can be used not only to intercept traffic (since it uses HTTP with no SSL/TLS encryption) between the two devices (Both independently reported by SecureAuth Core Security Team), but to exploit the discovered vulnerabilities and have unrestricted access to vulnerable device storage. ![]() Newer versions turn off download server when not in use, this means to exploit the vulnerability, you need to find an active file exchange session around you. This means that only what attacker needs is to be with your SHAREit android device in the same network to have full unrestricted access to all your files. Older versions of SHAREit (< v4.0.X) used to keep the download server running regardless of whether an active file transfer session is running or not. The odd behavior occurs when unauthenticated user tries to fetch non-existing page, instead of a regular 404 page, the application responds with 200 status code empty page and adds user into recognized devices!! Making this the weirdest and simplest authentication bypass we ever seen :). Yes! a fully functional proof of concept would be as simple as Once a valid session is retrieved at least once, application adds the user to recognized devices and accepts any incoming download requests from this user. When a user with no valid session tries to download a file from the device using the previously mentioned URL, the application responds with 403 response code with an error message saying “The request is not from anyshare user!”. SHAREit <= v4.0.34 exhibited a very odd behavior that lead to authentication bypass. So we can download whatever files we want from victim’s device but getting a valid session would trigger the alarms when they see unusual session and limiting it only to people we exchanged files before would dramatically decrease success rate, so what is next? 2. For example to download a file from user’s device, all you need to do is to have a valid SHAREit session with this user at least once to be added to recognized devices then go to This will download /data/data//shared_prefs/Settings.xml which is the settings file for SHAREit application. The problem occurs mainly because the application fails to validate msgid parameter enabling a malicious client with a valid session to download any resource by directly referencing its identifier. msgid: Is a unique identifier for each request to make sure that download request was originally initiated by the sender.As the name suggests, thumbnail would fetch a preview of the resource (small image of a video or a photo, application icon, …etc.) and raw would fetch the original file. ![]() filetype: the file type parameter accepts one of the following values thumbnail, raw, data, external.metdataid: The identifier for the resource we are trying to download, in case of a photo, video or a sound clip it is an incremented number representing asset id in Android MediaStore, for applications it would be package name and for files it would be the full path of the file.metadatatype: is the parameter that defines what resource we are trying to download, is it a photo, a video, a music file, an application or just a regular file (accepts any of the following values music, video, photo, app, game, file, doc, zip, ebook, contact.The requested URL looks like the following When a download request is initiated, SHAREit client sends a GET request to sender’s HTTP server. If “receiver” decided that it is not a duplicate file, it goes to download channel and fetches sent file using information from previous control message. The regular file transfer session starts with a regular device authentication/identification, then “sender” sends a control message to the “receiver” indicating that it has a file to share and required information to initiate download request. This is mainly used by other clients to download shared files. Download Channel (Port 2999): SHAREit application’s own HTTP server implementation.This includes device identification, handling file transmission requests, checking connection health…etc. This channel is used to communicate with other SHAREit instances running on other devices. Command Channel (Port 55283): A regular TCP channel where application exchanges messages with different devices using raw socket connections.For the use of this post, we are interested only in two distinct services: To serve its purpose, SHAREit application hosts multiple services on the device.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |