Dave Bittner: [00:00:03] Hello everyone, and welcome to the CyberWire's Research Saturday, presented by the Hewlett Foundation's Cyber Initiative. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities, and solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.
Dave Bittner: [00:00:26] And now, a moment to tell you about our sponsor, the Hewlett Foundation's Cyber Initiative. While government and industry focus on the latest cyber threats, we still need more institutions and individuals who take a longer view. They're the people who are helping to create the norms and policies that will keep us all safe in cyberspace. The Cyber Initiative supports a cyber policy field that offers thoughtful solutions to complex challenges, for the benefit of societies around the world. Learn more at hewlett.org/cyber.
Dave Bittner: [00:01:02] And thanks also to our sponsor, Enveil, whose revolutionary ZeroReveal solution closes the last gap in data security: protecting data in use. It's the industry's first and only scalable commercial solution enabling data to remain encrypted throughout the entire processing lifecycle. Imagine being able to analyze, search, and perform calculations on sensitive data, all without ever decrypting anything. All without the risks of theft or inadvertent exposure. What was once only theoretical is now possible with Enveil. Learn more at enveil.com.
Jonathan Shimonovich: [00:01:42] Here in the research group, we investigate many attack vectors on mobile.
Dave Bittner: [00:01:47] That's Jonathan Shimonovich. He's the Mobile Research Group Manager at Check Point. The research we're discussing today is titled "Remote Code Execution Vulnerability on LG Smartphones."
Jonathan Shimonovich: [00:01:59] One of the attack vectors is malware that we investigate, and the other is the OS itself. So, specifically here, we're talking about an application that comes with the--a system application--that comes with the LG phone. We have an automatic big data system that scans all the apps that we see, all known apps, and search for interesting things, interesting phenomenons, interesting vulnerabilities. If we see something interesting, then we might decide to hand it over to a researcher who might do further investigation of this application. What we did here is we scanned many, many system apps from many, many different vendors. We came across a couple of interesting ones and the LG Keyboard is one of them.
Dave Bittner: [00:02:52] So, the first vulnerability you discovered had to do with the LG Keyboard app's supporting of handwriting modes. Describe to us, what is that, and what did you discover?
Jonathan Shimonovich: [00:03:02] Okay, so basically, LG patched it in May, a security update, as a single vulnerability. But actually, it's a set of vulnerabilities that can be exploited together in order to gain remote code execution in the LG Keyboard. Basically, what we found is a breach in the update or install of handwriting languages within the built-in LG Keyboard. We've tested it on many LG devices. Specifically, we confirmed it exists on the LG G4, G5, and G6, the flagship devices of LG, and we saw it on a variety of Android OS versions, from Android 4.4 to Android 8.0.
Dave Bittner: [00:03:56] And what exactly is the vulnerability here?
Jonathan Shimonovich: [00:03:58] Let's first talk about what the vulnerability allows. So, it allows an attacker to gain what is called RCE, which is a remote code execution, which means that an attacker will be able to, if exploited correctly, will be able to run their own code payload within the LG Keyboard application context. Since the LG Keyboard is a preinstalled system application, it runs with system privileges.
Jonathan Shimonovich: [00:04:31] So, basically, the code will have, it's not root privileges, but it's pretty close, and it will have permissions to install other applications or to record all of your typing in the keyboard. I mean, that alone is very serious, because he can wiretap everything that you type, including your secret credentials, username, passwords to banking sites, take all of your pictures from your phone. I mean, a high set of capabilities, same as an advanced spy phone can be used. So, this is under what can be accessed. Now, if it's okay, we can talk about, a little bit technically, about the "how," the vulnerability itself.
Dave Bittner: [00:05:20] Sure.
Jonathan Shimonovich: [00:05:20] Actually, this vulnerability is composed of a set of, let's say, programming malpractices, of bad security practices, when combined together can be joined to something very dangerous.
Jonathan Shimonovich: [00:05:36] One more additional thing is that it's not, let's say, the known type of buffer overflow, or memory overflow, in the memory. It's more of a logical problem in the update mechanism of the languages that allows an attacker to use it in a malicious way.
Jonathan Shimonovich: [00:05:57] So, it starts with unsecured HTTP connection. So, this is the first building block for the attack, because the update process is done over an unsecured channel, HTTP instead of HTTPS, which means that anybody that can serve as a proxy to your phone, or hijack your traffic, or create a fake access point, can see your traffic, and the basic assumption is that you use a secured connection. So, using an unsecured connection is already a bit serious by itself, but it still doesn't give us running-code abilities, just wiretapping to your traffic. So this is the first one, and this allows an attacker to interfere with the update process.
Jonathan Shimonovich: [00:06:43] The second malpractice here is the lack of path traversal verification. So, I'll talk in a minute about the specific tech details here. But, basically, when the set of files to be updated is sent to the device, no one verifies they're supposed to be written to a certain destination directory, and the code doesn't check for directory traversal. So, I can write "../../" and put the files in a different directory. This is the second problem.
Jonathan Shimonovich: [00:07:22] And the third problem is that the LG Keyboard allows dynamic code execution. So, this is probably part of the handwriting languages, as they probably require some more complex, or machine learning code, in order to recognize the handwriting and transfer it text. So, the keyboard allows dynamic code loading, which means it gets precompiled libraries from the code library from the server, and it runs it.
Jonathan Shimonovich: [00:07:57] So, this already is a bad practice, specifically in Android, where an Android application is called an APK, and each APK is signed by the developer's certificate, so each part of the code is verified. And this is a workaround to update code without updating the application. So, this is already not a good practice.
Jonathan Shimonovich: [00:08:19] But, additionally, no verification is done on the code, on the dynamically loaded code. So, this code is not signed in any way, it's not verified. Moreover, you can also push a configuration to the application that tells it which code to run. So, basically, you can manipulate the entire dynamic code loading process. So, if you'd like, I can dive into a bit more technical details.
Dave Bittner: [00:08:48] Yeah. Please, go ahead.
Jonathan Shimonovich: [00:08:50] The update or installation of a new language pack starts with the downloading of a file called "files.txt," files dot txt.
Jonathan Shimonovich: [00:09:02] This file is a text file containing a list, basically, where every file to be loaded as part of the language back is a new line. So, basically, this file is downloaded first, and then it is parsed, and then all the files listed in this file are downloaded in the following step. So, although each of these files has a cryptographic hash that signs each of them, the files.txt, the first file in the process, is not signed.
Jonathan Shimonovich: [00:09:36] So, an attacker using a man-in-the-middle can manipulate the files.txt by adding new records, or replace it entirely with his own file. For instance, the attacker can add his own files as a new record to the files.txt file, and then they will be downloaded by the keyboard. So, this is the first stage.
Jonathan Shimonovich: [00:09:59] Now, the files that you want to add are two files. First, you want to add the, let's call it, the attacker wants to add the malicious payload. So he'll add an additional record to the files.txt with his native library, a ".so" file. And this file will be downloaded and saved to the device.
Jonathan Shimonovich: [00:10:22] This already enables the attacker to push a malicious code to the device, but this is not enough, because we need to take care of loading. I mean, just putting the code in some directory is not enough. You need to make sure someone calls it, someone loads it to memory and runs it.
Jonathan Shimonovich: [00:10:43] Luckily, for the attacker, there is an additional configuration file called "Engine.properties," which is part of the LG Keyboard configuration. This file is not in the download directory, but, as we previously mentioned, there is this matter of directory traversal. So, if you write "../../" and then the relevant path, you can override the Engine.properties file of the keyboard.
Jonathan Shimonovich: [00:11:17] Within this file, there is a list of the libraries, the code libraries, that should be loaded on keyboard restart. So, if the attacker will manipulate not only the files.txt, I mean, he can manipulate the files.txt and, in addition, two other codes. One is the malicious payload, and the other is the configuration file, run over the configuration file telling the LG Keyboard to load the payload.
Jonathan Shimonovich: [00:11:50] So, this is sufficient to execute the code, the malicious payload. As the malicious payload, as we mentioned earlier, is not signed or verified in any way, and even, it's enough for the malicious payload to end with ".so" for the keyboard to think that it is a code intended to be running, and it automatically gives it running permissions, to the file.
Jonathan Shimonovich: [00:12:17] Repeating the steps, first file to be downloaded is the files.txt, which contained a list of the following files for the specific language pack. So, the attacker can add two records. One for the malicious payload ".so" file, and the other for running over the properties file, which is possible due to directory traversal. Then, all that needs to be done is restart the phone or the keyboard process, whichever one is more comfortable. But whichever one will be rebooted first, on the next load the malicious payload will be loaded into the LG Keyboard memory and executed.
Dave Bittner: [00:13:02] And so, given the permissions that they have there, I mean, I guess, the sky's the limit with the types of things they could do on the phone.
Jonathan Shimonovich: [00:13:10] Yes. So, as I mentioned at the beginning of the conversation, I mean, just access to the keyboard already gives them access to everything that you're writing, including your private messages and banking credentials, your password, and everything. But, in addition, it can also silently install additional apps, access images on the phone, and, I mean, as you said, it can do pretty harmful things.
Dave Bittner: [00:13:37] Now, in your research, was there any evidence that anyone was actually doing this out in the wild, or was this more theoretical that you discovered in the lab?
Jonathan Shimonovich: [00:13:45] We haven't seen it exploited in the wild. We discovered in the lab and the first thing that we do is disclose it with LG. And only after LG issued the patch did we publicly disclose this vulnerability.
Dave Bittner: [00:14:02] And has LG released patches for some of the legacy devices? You know, going back as far as this goes?
Jonathan Shimonovich: [00:14:09] We haven't checked for every device, but I think, for a lot of devices, yes. Because the patch is easier, you don't have to update the entire OS, it's sufficient to update the LG Keyboard. And we did see they issued new versions for this specific app.
Dave Bittner: [00:14:27] So, what's your recommendation for folks to protect themselves against this? Is it as simple as making sure that you've got all your patches up to date?
Jonathan Shimonovich: [00:14:35] Yeah, so, in this case, it's even simpler. You need to see that, if you have an LG phone, that all your LG or system apps are up to date and updated. This is the first thing. If you're not sure, you can go to the setting and try to force update instantly, and that should resolve that. I mean, until you do it, what else you can do is just avoid installing new languages, specifically handwriting languages, on your LG Keyboard, until you update.
Dave Bittner: [00:15:07] I see. Yeah, so it's actually that, it's when you reach out to try to update your languages or install a new language, that's when the vulnerability gets exposed.
Jonathan Shimonovich: [00:15:17] Yes.
Dave Bittner: [00:15:22] Our thanks to Jonathan Shimonovich for joining us. The research is titled "Remote Code Execution Vulnerability on LG Smartphones." You can find it on the Check Point Research website.
Dave Bittner: [00:15:34] Thanks to the Hewlett Foundation's Cyber Initiative for sponsoring our show. You can learn more about them at hewlett.org/cyber.
Dave Bittner: [00:15:42] And thanks to Enveil for their sponsorship. You can find out how they're closing the last gap in data security at enveil.com.
Dave Bittner: [00:15:50] The CyberWire Research Saturday is proudly produced in Maryland, out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technology. It's produced by Pratt Street Media. The coordinating producer is Jennifer Eiben, editor is John Petrik, technical editor is Chris Russell, executive editor is Peter Kilpe, and I'm Dave Bittner. Thanks for listening.