Samsung S5 Arbitary File Retrieval during SBeam Transfer
CVE-2015-4033
A vulnerability was discovered within the Samsung S5 SBeam file transfer process which allowed the retrieval of arbitrary files from the phone’s filesystem while the SBeam transfer was taking place.
Description
The DirectShareManager application is used when transferring files between two Samsung devices using the SBeam feature. A vulnerability was found whereby both devices would start an HTTP server from the root of the filesystem on all interfaces for the duration of the transfer. If the attacker could access this service and knew the name of the file, they could retrieve the file without authentication or user interaction.
Impact
An attacker who was sending the victim a file via SBeam, or was on the same network as the victim during the use of SBeam can retrieve any media from the external storage (e.g. the SD card) of the victim as long as they knew the file name.
Cause
It was possible to download any file from the phone’s filesystem for which the full path is known and the DirectShareManager application has read permission. This was due to the launching of an unauthenticated HTTP server listening on all interfaces during the SBeam transfer process.
Interim Workaround
The SBeam application should not be used to transfer images with untrusted sources or whilst connected to untrusted networks.
Solution
Upgrade to the latest version via an OTA (over the air) update.
Technical Details
Users can share files using the SBeam feature by opening the file and then putting their phone against another Samsung phone. The process begins over NFC whereby the receiver is given credentials for a peer to peer (p2p) Wi-Fi network which is then used to securely transfer data between the two devices. Once this network has been established, both the sender and receiver start an HTTP service on TCP port 15000 on every interface
This HTTP service is used by the requesting device to retrieve the file using the path they have been given during the initial SBeam setup. However the web server allows access to any file that the DirectShareManager application has permission to read, which includes all media on the external storage. Further, both devices start the service, which means that even though a user was intending to only receive a file from another person, the other person is free to retrieve files from their device too.
The web server runs from the root directory, but does not allow directory listings. This means that the attacker must know the exact path and file name of the file that they wish to retrieve. Photos taken on the device are saved using a filename that is based on a timestamp in the following format:
/sdcard/DCIM/camera/yyyymmdd_hhmmss.jpg
It is therefore possible to try every possible filename in a brute force attack. However an easier method is to query the image cache of the gallery app found here:
http://"+probableOtherDevice+":15000/sdcard/Android/data/com.sec.android.gallery3d/cache/imgcacheMicro.0
This means that if the image has been viewed by the gallery app, then the exact filename can be discerned from this cache file, and then requested from the web server.
The DirectShareManager application code responsible for starting the web service on all interfaces serving from the root directory is shown below:
./com/sec/android/directshare/DirectShareService.java
private boolean StartWebServer(String arg9) {
boolean v0_1;
try {
if(this.mHttpServerThread != null) {
goto label_30;
}
this.fileScan();
this.mHttpServerThread = new RequestListenerThread(this, this, arg9, 15000, "/", null);
this.mHttpServerThread.setDaemon(true);
this.mHttpServerThread.start();
v0_1 = true;
goto label_18;
}
catch(Exception v0) {
Log.e("[SBeam]", "DirectShareService: StartWebServer: errmsg=[" + v0.getMessage() + "]");
}
label_30:
v0_1 = false;
label_18:
return v0_1;
}