OEMs Considered Harmful: Hello New 0Days!

Um second okay it works okay so thank you very much for coming um today I'm going to present to you a research that we have conducted on OM's code so the agenda for today um first we'll talk about OM in general their position in the Android ecosystem how they affect how they affect our devices and the differences between the OEMs then we will analyze two different zero day vulnerabilities that we found in OM code and finally Finally, we will give out conclusions and see how we go for them further from here. So, just a little bit about myself and my name is Adam Dunfeld. I've been a security researcher for years both in the mobile and in the PC field. I've

mainly done vulnerability assessment and exploitation. Uh, currently I work at Checkpoint Software Technologies as a security researcher for Android and in my free time I also study German. So let's talk about our devices. What do we actually get when we buy a new Android device? So first we have the Linux kernel with a few modifications for Android like the binder wakes uh power management modifications. Then we have the Android project abbrevated AOSP Android opensource project which is maintained by Google and can be viewed by anyone. It contains frameworks to expand the Android functionality on our devices and essential user mode code for the operating system. Next, we have the chipset code uh which brings both uh current drivers

for the hardware like drivers for the camera or for the GPU but also use mode code for communication with the hardware. Next, we have uh the OEMs which brings uh which bring unique customizations into our devices. Uh these unique features come both in the form of hardware modifications such as um edge screen in new Samsung Android or the power bottom on on the back of LG devices but also in the form of software modifications such as differences between the UI or different pre-built applications. Now it's important to mention that some devices share the same feature with a different implementations. And finally we have the carrier with sometimes partial billing application rebrand the device friendly log on it but nothing so special in man

of code. Okay so the market share in the United States is fragmented unequally there are few large OEMs which show the marketplace among themselves. So it's enough to find a vulnerability in a major OEM to affect a large portion of the market. Now over the years OEMs were OEMs were known to have a low standard of security and therefore the code was addited in the search of new vulnerabilities. However, as the time passed, this problem received more and more awareness and efforts were made to improve the security of the OEMs. These efforts came both from third party contributors, the OM themselves and from Google. So Google started to enforce new security mechanisms into Android which

greatly increased the security standard of all the OEMs. An example for security mechanism that I personally really liked is CTS or compatibility testing suit. CTS is a unique testing framework for vulnerability for vulnerabilities. So once a vulnerability is published a new test is written to check whether the vulnerability still presents on a device or not. Now all the devices must pass this test and if they don't pass it they won't receive a certification from Google and therefore they will lack many essential features like Google Play, Google Hangouts and many other features. So Google is protecting us. Uh third party developers contribute to the security of Android and OM are getting better and better. Android is

safe or not. Um, according to android vulnerabilities.org, LG received the highest score for being a secure OEM. We decided to see whether this score is is justified or not. So, we started a short uh bug hunting project on LG devices. So, um when we want to attack a mobile device, there are two main attack vectors that we have local attacks vector and remote attacks vector. Local attacks vector means that I have an application installed on a device and using a vulnerability I can elevate my privileges to grind capabilities which I'm not supposed to get. For instance, a tic-tac-toe game or an innocent flashlight application are not supposed to be able to read our contact list or

our call history. Now it's for the local attacks. Lum attacks vector means that I have unique identifier of of a device. It can be a phone number, IMEI, it can be IMSI, it can even be an email address that is that is associated with the device and I can coordinate my attack specifically against this identifier and therefore against the device. Now usually the user interaction in this kind of attacks is from minimal to nothing and therefore this attack vector is considered much more dangerous. However, with that said, and these attacks are not so are much more complicated and therefore they are not so common. So, let's start with the local attacks. Uh we start with the

point that we have an application installed on a device and there are many ideas that we can work on from this point. For example, privileged services that have no bind permission, native memory corruptions, non-star services like unique sockets that accept connections and can be attacked and there are many others. So let's talk about bind permissions. Uh Android allows applications to export functionality to other apps using services. uh but obviously an app will not want everyone to access its sometimes privileged uh uh capabilities. So uh the bind permission feature allows application to restrict the use of this exported functionality. Now this feature is used both by Android native apps, OEM internal services and even by third party applications. An

example for use for use of this service. Let's say that you want to read the call history of the phone or the contact list. Uh the service that provides this information is protected by a bind permission. So only if you have the newest permission the only if you have the spec the specific permission can access and read this data. So how does this actually work on a device? Let's take Facebook and messenger for example. uh Facebook exports a service called cross process logout service that allows other applications to log the user ad from Facebook. Now let's say that we use messenger and we log out from messenger. Messenger will attempt to connect to the service use its capability is capability

and functionality and log out user also from the main Facebook app. However, if we are a flashlight application we're not supposed to be able to access this service. So what happens if we try to access it? We get the permission denied exception. How do we obtain this permission? In order to get it, we we have to be signed by the same developer key like Facebook's uh key. So since fa since Facebook and messenger do share the same key, Messenger can access then can obtain this permission and access this service. So with this in mind, time to start research. So uh we decided to go uh for all the LG applications that um export some sort of functionality but does not

protect this functionality using bind permissions. Now this is common because not all the exported functionality is privileged. So it doesn't have it was it doesn't always have to be protected by bind permissions. And we found this service uh LGATCMD service that is present on all the LG application on all the LG devices. And this is a very high privileged service. No application should be able to access it especially not a tic-tac-toe game or a fleshed application. So if as you have seen before if you will try to access it we will receive a permission denied exception but we don't any permission any application regardless of its origin of its permission can access this service use its high capabilities and

attack this system. So what can we actually do once we are connected to this service uh we can start communicating with ATD or at demon. So what is 80 demon? 80 demon is a user mode demon written by Qualcomm and therefore present on all Qualcomm based devices. Now it's a hyperledge demon and unfortunately there is no source code available for this. So we had to reverse engineer it to understand how to communicate with it. Now it's the main gateway communication to the firmware. We're talking mainly about the network. So, Wi-Fi, Bluetooth, GSM, but also to something called MiniOS, which is an internal interface to test the device. And the most important thing about it, it receive

commands from uh LG CMD service, which we are connected to. Thanks to the missing bind permission. So, what can you actually do once you're connected to this demon? We can read private identifiers like IMEI, serial number and etc. And it can help us coordinate our attacks against the device. We can also override this private identifiers which are supposed to be read only. uh we can reboot the device without any prompt or notification and we can therefore we can prevent the user from doing stuff we don't want him to do like deleting us and we can switch between the different USB modes and therefore we can prevent for example uh communication with the computer so we can prevent backups or a

firmware upgrade using the USB and we can even go more offensive we can wipe the device completely again without any uh prompt or notification to the user. We can read the device if wiping it isn't enough. And my favorite, we can permanently lock the devices GSA modem. And this is also persistent after a wipe. And we sent our device to a lab and they couldn't fix it. So shouldn't it's not safe to test it. Now combining all these features together, uh we can create a very harmful type of viruses at the cost of no permissions. So uh the exploit flow we have malicious application an unprivileged application installed on an LG device and we want to

connect to LGAT CMD service. Now since LGAT CMD service is not protected by bind permission we can do that and start communicate with it. And now let's say that we want to issue a log GSM modem command. So we send this command to LGAT SIM service which passed this command to ATD which eventually locks the device. Now uh we responsibly disclosed this vulnerability to LG and they fixed it. We received the CV number for it and if you have the newest version of LG you are protected otherwise uh don't install malicious tic tac toe games. Okay, so we're done with the local attacks. Let's aim higher. As I've said before, remote attacks are much more

complicated and the attack vector is really now. So, how do we actually start? Uh we decided to go for all the LG applications which we can remotely communicate with knowing just the phone number of the device. So, I was talking before about a unique a unique identifier of a device. So, in this case, we took the phone number. Now these applications can be identified because they must have some remote related permissions like the ones we see here and from all the permissions here W push is the most interesting one because there's there's lots of binary data that has to be processed h on our victim and comparison to other communication ways. So before we talk about woo we have to

understand first how text messages work. So all the text messages are based on a protocol called PDU. A p this protocol defines many properties in a text message in a text message not just the text itself. For instance the sender the receiver is the text is the text asy is it uni code what is the length of the text and etc. Now an advantage for us in this kind of of communication the mobile carrier doesn't run any verification checks on the PDO that we send other than checking the sender and the existence of the destination number. It means that lots of binary data will be processed on our victim. Here is here is an example of a

PDU message. Um I'm not trying to teach you how PU is fact exactly. I'm trying to convey here that PU is a complicated protocol and nobody likes it and therefore we think that it could be we thought that it could be an interesting place to search for new vulnerabilities. So now let's talk about WAP. Um W is the B way to transfer binary data over the mobile wireless network. Uh whether you know it or not you use or you used it a lot. MMS are based on WAP. Uh carrier connectivity information. When you switch the new carrier and you you plug in new SIM and you receive this message, it's also based on WAP. Uh vcards, the old vards

that were popular a decade ago are also based on WAP. And the old mobile websites were also based on WAP. And in order to access them, another WA based protocol called Wush was invented. So what can we actually do with W push? We can transfer URLs to the device um to these old websites. We can transfer expiration dates for these URLs because all the websites meant to be expired somewhere. And since these messages were only meant to be sent by the mobile carrier, two important features came in this protocol, an update feature and a delete feature. The update feature allows us to update the the expiration dates and the URL because sometimes they wanted to prolong the

validity of the website and a delete feature if in case that the website was expired prior to its expiration date. So Wapush was imple most of the OEMs implemented Wapush in the same way. It was some native library but LG on the other hand they had a complete different implementation. They implemented purely in Java in a package called Wervice.apk and as their unique implementation so was their unique vulnerability. So let's examine the code in web in web service APK that processes this message and handles handles it. So uh this is the code from the manifest of the application. As you can see uh the component that handles the W push messages is called pushp push receiver

and it handles all the W push messages. And now let's see the code that handles it. So h eventually it goes to sender validity check main. I'll just summarize it for you. Uh we get to two main different functions. Process SI message and process SL message. Both are sub implementation implementations of the W push protocol and they contain the same vulnerability. So, I'm going to show you the vulnerable code now and give you a few seconds to see if you can find it yourself. Uh, the vulnerable code is both in the update and in the delete features. This is the delete feature, the implementation, and this is the update implementation. Take like 15 seconds to see if you can find it

yourself.

eight. Okay. So, uh push handler si is the unique identifier of the message and if we don't supply any unique identifier, our URL becomes the identifier. Now um what happens if I send this URL? So there is SQL injection vulnerability which can remotely be exploited. We can delete or update any text message on the device even if it's not a push push message sorry if and even if we didn't send it. So any text message on the device. So, how do we exploit this vulnerability? Um, in order to send the update or the delete uh message there, the device must already have a pre-existing W push message. Now, we don't want to take any risk. So, we will

first send a normal W push message. Now, uh now we're sure that there is a W push message on the device. So we can send our malicious update or delete message against any existing normal message. So we do that and then we update or delete any content that we want. Now we responsibly also disclose this vulnerability to LG and they issue we received the CV number for it and they fixed it and unless you have the newest version of LG I can start deleting your text messages right now. So, uh, let's see a demo of the exploit. Now, we're going to see a the delete primitive. So, on the right, we have the victim. Uh, we just have to know the

phone number of the victim. And the victim has to be connected to a GSM network. So, any SIM will do the job. And the attacker is on the left. The attacker is connected to a GSM. Uh, so we can send raw PDUs to the device. So, as I've said before, uh the device must already have a W push message. So, let's just send

one. Okay. So, from this point and on, we can start exploiting the vulnerability immediately. But just out of curiosity, let's see how the message looks when we read

it. Okay. So service me message since this protocol was only was mainly intended to be to be used by the mobile carrier. There is no phone number here. It only shows service message. A new update is available is a text that I chose. I could send any text I wanted. I just told that this text looks genuine. So that's what I chose. Now let's see how it looks when we open

it. So obviously you won't receive a phone update from metri.org. Again I can choose the URL. And now once we know that there is a W message, a W push message on the device, let's start deleting some

messages. Okay. So unless you have the newest version of LG, if you want to protect yourself against this attack, you have to turn on airplane mode, take out your SIM, plug it into a nonLG Android device, receive the text messages there, and then plug your SIM back to your LG Android phone, which is pretty much unpractical. Now, using this vulnerability, there are lots of malicious activities that we can do. Uh, for example, let's say that I hacked your bank account and I change your password. So, I can just delete this your bank account password has been changed message that you usually receive. And we can even aim higher and use it for remote ransomware. So, let's

say that I delete all your text messages and then I send you a new one. If you want your text back, pay me. Otherwise, I will wipe your entire device. I didn't try it, but it might. Sorry, I didn't try it, but it might work. And updating the inbox text messages is also very powerful. We can it is possible to craft sophisticated fishing attacks. For instance, let's say that your bank sends you a text message with a link to download their application. Um I can just modify this tag to look like this. And I can like change the URL. I can point it to my malicious application. I can point it to a new website and my new malicious

website can look just like the homepage of Bank of America and hope hopefully or hopefully not. You will put in your valid credentials and our bankers like GMBBO and ACER do that a lot locally. So doing this remotely is even much more powerful. So uh we found a local locally exploit exploitable vulnerability and a remotely exploitable one. How much time do you think that this entire research took us? It took us just 5 days. This is ridiculous. I mean it's 2016. OM are still not doing a good job enough securing their devices and unfortunately we still can't trust them and better solution for security is still required. But with that said, if you compare the

situation to five or six years ago, we're in a much better much better position. We are stepping into a really much more secure world, but some work has still some work has yet to be done. So, thank you very much and if you have questions, you have to take the microphone and go ahead.