Samsung Galaxy phone hack: Making sense of the “Samsung” RCE vulnerability

The Samsung Galaxy phone hack was not caused by "one bug.” It was due to a chain of several failures, which makes it difficult to say who is at fault and how the Samsung hack could have been avoided. Don't jump to conclusions!

How did the Samsung Galaxy get hacked?

Issue 1: Samsung uses a white-label version of the popular SwiftKey 3rd-party keyboard app as the default keyboard in recent Android devices. In order to do that, it repackages it and installs it into the system partition. This gives the keyboard app “system” privileges.

Issue 2: Android's ZIP library is vulnerable to a directory traversal vulnerability, similar to what described at CERT's Secure Coding Guidelines IDS04-J. Many researchers believe that other platforms, like iOS, suffer from the same issue, but I have not personally confirmed this. How does this work? An attacker constructs a malicious zip file in which the name of an included file contains a directory traversal. The extraction code follows the traversal and places the file in a directory that the app developer wouldn't expect.

Issue 3: SwiftKey downloads certain zip files over HTTP. These are typically files that contain extra languages. It must be noted that these are application assets, not executable code. Just as most apps download image files over HTTP, this app downloads some ZIP files with text in them. There is no vulnerable update mechanism in place. SwiftKey would probably not find a flaw during code audits, penetration tests or design reviews because downloading an asset over HTTP is not normally a flaw.

The combination of all three issues allowed the researcher to achieve remote code execution. He did this by performing a man-in-the-middle attack on the cleartext traffic [due to Issue 3] and replacing the downloaded ZIP with a malicious one. Upon extraction, this new ZIP overwrote an executable file [due to Issue 2], enabling the execution of malicious code included in the ZIP. The location of the overwritten file had filesystem permissions that prevented access to normal users, but this was possible due to the keyboard app having system privileges [Issue 1].

How does this apply to normal apps?

What is interesting is that normal, non-system apps are vulnerable to Element 2 and Element 3.

An attacker can replace a downloaded ZIP file with a malicious one and overwrite any file a normal application has access to.

The impact of this type of attack is related to the chosen target. Here are a few examples:

• Overwriting some critical app files would cause an application DoS until the app is re-installed.
• Some apps do funny things like enable debug functionality if a certain file is present somewhere. This could be abused without elevated privileges.
• Due to a platform bug, many apps that use native libraries follow a code pattern where the native libraries are (or can be) loaded from the app-private storage. This could be abused to achieve code execution.
• Because apps that use multiple DEX files extract and load the secondary DEX file from the app-private storage, they are vulnerable to remote code execution by default.
• If an app uses dynamic code loading itself, it would be vulnerable to RCE. There are many apps that download and load DEX, APK, JAR and SO files. Of course in this case, an attacker could also replace that file during download, but the ZIP option would work as well.
• Any file on the SD card could be overwritten (given correct app permissions).

How can Samsung fix the Galaxy hack?

Samsung could fix this via a SELinux policy update, pushed to devices urgently. Read Samsung's response to the issue.

How can similar hacks be prevented in the future?

If you are a device manufacturer like Samsung, a device integrator, or a network carrier and you create your own system images, you should be very careful.

You'll need to add processes to your Software Development Life Cycle (SDLC) that minimize a device's attack surface—for example, letting as few apps as possible to be signed using the system certificate. There are alternative options that you could use to handle apps like SwiftKey. You could fine-tune the SELinux policy of the device so that individual apps are further restricted, even if they hold elevated privileges. This would limit the attack's impact severely. For the few apps that need to be system-privileged, you should implement extensive security audits as well.

If you are the Android Security team, you should probably work to fix the ZIP extraction–file traversal issue. Same goes for Apple, if vulnerable.

Developers like SwiftKey should probably not attempt to download ZIP files over HTTP, even if they are just static asset files. Developers should seriously consider converting all traffic to HTTPS. Both Android and iOS platforms are starting to offer robust infrastructure that incentivizes developers into switching to secure communications.