 Right, again, let's welcome Kim his first time. Defconn, welcome. Hello. Let's hear it. That's it. Good afternoon. Thank you for coming to the session. I'm very excited to talk to you about our research here, watch and watch you. The broken privilege defaults in the Samsung Gear smart watch. Before we begin, let me introduce us. My name is Dongson Kim, and we are a security research lab called HIT from Songinpo University from South Korea. If you have any questions or comments, not the other one, please feel free to contact. So, yeah. First and foremost, let's start with why we did this research and the motivation behind. As you may well know, the Gear series includes Samsung's smart watch products, but apparently a few days ago, they changed the name to the Galaxy Watch. So, for now, just let's pretend it didn't happen. They are advertised as offering many useful features, including like tracking fitness, or receiving or replying to calls, tax emails, and even paying for stuff using your NFC. Well, typically you pair it with your smartphone and via Bluetooth, and it comes with Wi-Fi or even LTE. Samsung also operates an app marketplace for the Gear within Samsung Galaxy Apps, where anyone can just develop for the watch using the SDKs. To achieve all this, we share our highly sensitive information with the watch, your contact, your calendar, your locations, emails, notifications, it's more all come from your smartphone or vice versa. And access to such privileged resources must be permitted based on proper access rights. So, the former for Gear smart watch consists of two parts. So, one is the wearable version of Python OS, open source components. And the other is Samsung's closed source components built on top of vanilla Python. So, Python, probably most of you don't know, is a Linux-based open source OS developed by Samsung. Since the OS was envisioned to serve all kinds of devices, it has been shipped with many of Samsung's products, including your watches, including your smartphones probably, TVs, cameras, and even refrigerators. Previously, many researchers actually took a look at Python. In 2015, Abram revealed many problems with Python at the time. In 2017, Netherman disclosed 40 zero-day vulnerabilities and which made some media splashes. PVS Studio also analyzed a portion of the Python open source code base. So, they claimed there would be more over 20,000 code errors. But this research circled around the Python as an OS. However, we decided to take a look at the Gear as a smartwatch where the smart things actually happen as an extension to your smartphone. So, that was the motivation. So, we need to get right into the internals of Python's security concepts. In this section, we will highlight Python version three, in the latest version, publicly shipped with the Gear smartwatch products. The first concept is objects, obviously. So, since Tizen is based on Linux, there are typical stuff like files and directories and sockets and utilities. But in this talk, however, we're gonna focus on two types, applications and services. So, applications use Tizen's public or private APIs to access the subsystems, including framework and services. And services are special privilege, and Tizen's statements each dedicated to a specific resource like Wi-Fi or Bluetooth and GPS and messaging sensors, et cetera. These resources are, by nature, sensitive. So, some sort of control should be in place to reject unauthorized access. So, Python achieves this by introducing the privilege. Services must validate if the calling app has this proper want. So, similar to Android, app developer type in privileged strings in the manifest file. For example, the right side of the slide, you can see the manifest file. And there are some privileges, like HTTP, Tizen, ORG, privilege, internet, or alarm set, these are the privilege. The app market, or Samsung, signs the TPK application package and sells it. On installation, user accepts the permissions on the screen and then the installer checks and registers the policy in the database, and finally, at the runtime, access is controlled by the policies. Well, Tizen defines many privileges, internet, Bluetooth, network set, or more. However, only some of them are public to app developers. There are also partner and platform-level privileges, not for public use. So, to enforce this kind of privileges, to enforce this kind of policies, Tizen implements three plus one security mechanisms. The first is the classic deck, the UNIX user ID, group ID, that you probably are familiar with. The second is SMAC. SMAC is Tizen's choice of kernel space mechanism, like SE Linux. The specifics are a bit complex, but conceptually, they work like this. An app receives a unique label at installation, like user package sample app. And for every kernel object access, the current label or context is checked against the rules in SMAC database. The third is Sinara. Sinara is Tizen's user space privilege management daemon. Services ask Sinara to check if the calling application has the privilege. Sinara identifies the application by its SMAC label, then validates it against the policies within its own Sinara database. And finally, the plus one security manager is a policy configurator, and it reads the policies from the file system and the manifest file, and here and there, and it fills the database as we talked about. So, deck, SMAC, Sinara can recognize them. Now, let's talk about how applications actually talk to services. Debus is a widely implemented IPC system for Linux-like OS that also offers useful built-in functions like discoverability or insurrection. To put it simply, each service daemon registers itself to the Debus daemon, then clients dispatch request messages over a virtual channel. Tizen relies heavily on Debus for IPCs, as a risk. So, let me give you some Debus concepts using an example on the right, a typical Debus method call. It works like this, so we wanna send a request from a client to a service, but the service process already has a set registered in this case, and the client process opens a connection to the bus and the connection gets assigned a unique bus name. It looks like colon something 1.7 in this case. So, now the client sends a request message to the bus, and that message reaches the service whose connection also has a unique bus name, but also an optional well-known bus name, ORG, example, service. This is a service name. Then, the request is to invoke set foo method of the object slash ORG slash example slash object one. The object implements the interface ORG example interface which specifies methods like set foo and get foo. And finally, the service responds with a message, oh, sorry. So, to recap in one sentence, the client process sends a request from a bus name colon 1.7 via the bus to a bus name ORG example service to invoke set foo method of the object ORG example object one of the interface ORG example interface. Yes. So, the asterisk, that's because Tizen's Debus is Sinara aware, meaning it is patched to natively perform privileged checks. So upon receiving a message, the Debus statement in the middle asks Sinara for validation. But this approach allows the Debus statement to control access on messages. On the right example shows the Bixby assistant bus configuration file. And you can see there is a check element with destination, interface, member method, and importantly, privilege attribute, Bixby agent. So whenever Debus statement receives a message, it calls Sinara to see if the sender has the privilege then decide to accept or deny the message. Let's dig a little deeper with an actual code example, how an API calls sends a request to service and its privilege gets validated. So we're gonna start with location manager API with proper location privilege. So let's separate code shows that the privilege string is in the manifest. So the client process logic function below creates a measure handle, starts the manager and then prints out the result to the log. On the right in the shell of the actual device, we can see the result is zero as expected, which is a success. Then what happens if there is no privilege? Then let's try this the same thing. Then the result will come out negative 13, a failure. The log shows within the same PID, the process ID with written within the parenthesis shows a failure, Sinara check failed. Location library LBS location is responsible for this log by calling location check Sinara function. Now this is the first privilege check down the chain of a service request. Now this happens within the same PID. So by reverse engineering the location library, we can pinpoint where this happens. Since the library is linked to the client within the same process ID, client can simply live patch the instructions. So remove the code and write zero to register zero. Then we bypass the first check. The left code shows the live patch and protect to enable write then simply just overwrite the memory. When we run this, the result is still negative 13. However, the log changes. A D-Bus access denied message. Still within the same PID is printed out in violation of the privilege, HTTP, something location. So we can see the D-Bus library LBS D-Bus client sends a request to LBS server and the error shows the request access is denied by D-Bus statement, which of course Sinara in the middle. This is the second privilege check down the chain. So to recap, on the top on app using location API, links, the location library, then the library queries Sinara for the first time. If that passes D-Bus request sent then the D-Bus daemon in the middle queries Sinara for the second time. If that passes the location daemon receives a request which could potentially queries Sinara for the third time. Then finally the request reaches the hardware below. Now we didn't discuss the third check. We'll talk more about this in the next section. So what if the client is malware? So if the client is malware, there is no first check anymore. So there are two points that can pinpoint that can actually secure the service. The second point D-Bus daemon on request is a middle and the third point service daemon after receiving the request. If the OS or service developer fails to implement both of them then the violation can happen. Now we know the background. Let's move on to actually finding violations. To do so let me introduce a simple tool developed named Dan, the D-Bus Analyzer. The idea is simple. So let's say we send a D-Bus request to a safe service like LBS server we saw with no argument given without a privilege then access denied is gonna get returned. But with the privilege though invalid arguments is returned then when you think about it the error suggests privilege validations always happen first ahead of any other validation of the request. Then how about we send a non-privileged request to all of them, all possible methods then gather ones that return any other errors that is not access denied that would imply the policies, at least the D-Bus policies accept non-privileged request which could lead to violations. So we developed Dan. Dan automatically evaluates privilege verification of D-Bus services. It spawns a test process on a remote device and then recursively scans the D-Bus structure it then tries to read every property of every object also calling every method of every interface. After one round of analysis, Dan writes three files. One is the whole D-Bus structure flattened into JSON file and the others are properties and messes that require further attention. Let's discuss how this works step by step. So first we gather all possible bus names of services. Notice that as we discussed, we one service can have multiple bus names one unique or one or more well-known names. So from the extractive farmer, we gather all names from files under user share D-Bus one. So as shown on the left image of system D-1, the service. From the runtime, we call the built-in method list names to list all currently available bus names as shown on the right image. You can see some are unique, some are unique, colon, something, something and some are well-known like some in this case who are board, parse, pulse audio server that can't think. Second, we recursively introspect the services that means gathering their structure, objects, interface, method, et cetera. Per the D-Bus specifications, each service can respond with its object structure when the D-Bus standard method introspect is requested. The response is well-formatted XML as shown on the right example. And this is the root object of system D and you can see the interfaces, methods and method arguments and child objects. Now in this step, we try to read every property value. To do that, we use the D-Bus standard method get all on every object, but then uses the utility called the D-Bus send it which is one of the default utilities. But however, the responses from get all method as shown on the left, they are not quite well-formatted for an easy processing. So we made a custom bison parser, basically a compiler, get all that JSON to convert the strings to into JSON compliant form as shown on the upper right. Next step, the most important one, we try to call every method of every interface for all the objects. When doing this, we use random arguments, it's the worst thing so that the actual logic is not get executed, is not executed. As shown above, something like several strings of just one. Then an error would be returned. As we discussed, since the privilege gets validated, the validated first, we ignore the methods that return access denied. So they are actually checking, so they are safe. But with any other error, we assume the methods are callable. Finally, we hash every object to remove duplicates, then print out the readable properties and callable methods. That was then. Now we got that out of the way, let's move on to the fun part, the vulnerabilities. We ran our Dan with the target device, Samsung Gear Sport. It took about an hour, then the results are like this. And there were 269 bus names from which there were over 130,000 readable properties and over 2,000 callable methods. This does not include the default interfaces such as the bus. That's a lot of methods, but we do have some false positives because of the third check we mentioned. The log shows some services check Sinara, some services themselves explicitly check Sinara. You can see on the right Sinara check fail. But the method call itself does not return any debas error, so then the tool categorized them callable. At this point, we started manually examining each method, the 2,000 of them, and it turns out it was worth it. So we discovered many system services that allow privileged violations. A malware without any privilege could take over Wi-Fi, Bluetooth, screen, notification, email, and so many more. Sounds a bit scary, so now let's take a look at them one by one. First, we found the debas API for WPA subsequent was fully exposed. For those who don't know, this is a free software implementation for 802.11i, which can be easily found on Linux systems. Python builds its own APIs and daemons on top of WPA subsequent. So we found every method is callable and every property is readable. That includes create interface, removing interface, scan WPS, start, get pin, P2P fine, connect, and more. Now this exposure violates Tizen's many network-related privileges and also location-related private ones too. Now let me give you some more example on that. Well, many companies run a database from which GPS coordinates can be publicly obtained if two components are known, BSSID of nearby Wi-Fi networks, and their signal values. So even though location privilege isn't granted or even the location daemon is itself completely turned off, the malware can track the device by taking over Wi-Fi. On the right example, we acquire the BSSID of the first known Wi-Fi network, starting with 98D78, and the signal value of negative 51. So using Google's geolocation API, we have the GPS core or coordinate, which is our lab. Next, we have Bluetooth. The project X dot BT and project X BT core are two of Tizen's own services for controlling Bluetooth. And these services partially expose methods where a malware can silently accept incoming Bluetooth pair requests or silently force Bluetooth discovery mode or prompt a pairing request system UI to do phishing. Now on the right, we have an example. So whenever a malware calls the method in the background or at any time the UI in the first image pops up. So when the user scrolls down, they see the actual name of the paired smartphone. This system interface is supposed to be one of the Bluetooth pairing methods where the user manually types in the pin. However, if the user sees the UI without any initiation or without even entering the Bluetooth discovery mode, then user would think like, that's weird. What does this pin mean? Well, that's my phone, that's the name of my phone. So I guess I should punch in my pin. Then the value just gets returned to the malware. Now besides project X, there is another daemon for Bluetooth, BlueZ. BlueZ is the underlying Bluetooth stack for Linux and we found that its APIs are partially exposed as well. A malware can silently force devices to disconnect, gather information as one. There is a bonus though, then that's HCI dump. We found on some devices, there is no restriction on HCI dump utility as you can see on the right. What that means is that any malware or any user can simply dump the incoming outgoing Bluetooth packet with no super user privilege. Now by combining the two, a malware can start dumping HCI packets and force the paired device to disconnect which will automatically reconnect with a new link key and then extract the key from the dump. But this list to say, this problem is violated as Bluetooth related, also private privilege. Next we take over the screen too. Tyson's choice of Windows Manager is the Enlightenment Project. Among many exposure methods, dump top view wins. Somehow, this method dumps the Windows into PNG files as you can see on the right. Now this problem violates Tyson's screenshot, private privilege. And then we have the notification service. This service doesn't only manage notification data, but also can do stuff on behalf of users, tap on the screen. So this service is also partially exposed. As a result, a malware can remove all the notifications or launch an application on the phone, read all the incoming messages, internal data, and so on. Now in this case, privilege like notification and push are violated, but there is no privilege assigned to this kind of invasive behavior. No application should actually be able to do this. Then finally we have emails. The email consumer manages the user's mailbox data just like the notification. It also lets anyone do stuff. A malware can launch the email app on the smartphone, modify email messages, and most importantly, send any email using the user's email address. So messaging and email related private privileges are violated, but the most problematic thing is how the service actually handles private messages. Actually sending an email request does get rejected, but how? On the right we have the code. First we have the string we mail, private send mail, no T. Then it does string compare and nothing more. If it's not a match, the error shows up, ID is different, but if it's a match, then we're through. There is no proper privilege check in place, and the only security here is that one string check. Now let me give you an actual demo that combines many of the problems we discussed into one neat little package. Here you can see our malware has no privilege. Then we are building it and launching it on the target device on the right. The package is being loaded and the malware will look like a simple watch face application. There you go. Now the phone receives a Google Hangouts notification that the data is handed over to the watch, that. Then let's say the user puts the app in the background and after a bit of waiting, the malware will start to run the code. Then the user is now checking the email. It's waiting for a while. Then the first, it disconnects the Bluetooth connection to the phone, then executes HCI dump for Bluetooth package for a while. Then, yes. Soon the connection will re-establish with a new link key. Then the malware will log the data like that. Then it also acquires the notification data. Now it starts to send the data to the attacker's email using the user's email account. It also captures the screen then sends the image data. Now we are at the attacker's screen. Emails should arrive soon, there you go. It's taking a while. And one thing to notice is that the emails are coming from the phone. You can see the notifications start to pop up on top of the phone and the watch. Like that, and the watch, yes. Now we are receiving the images. Each image is a window, this one, and there's a code. And this data is one part HCI pick up file and the other part a JSON object. So let's just parse it. The JSON object is the internal data of the notification service. So you can see the message in the middle. So my room password is something in the middle. Now, finally, examining the HCI pick up file shows the new link key, like at the bottom. And that's the demo. Then why did all this happen? So we went through the configuration files to get a glimpse of it. First, we have the notification service. You can see there are only three checks elements listed. They try something, but many other messages are simply missing. In the case of Wi-Fi, we can get a clue from the Tizer wiki. The left diagram shows where, how it was designed. On top of WPA supplicant, there are Tizen's Conman daemon and NetConfig daemon. And then on top of that, there's the application. While the middleware is protected by their configuration files, WPA supplicant configuration simply doesn't exist. And why is that? Because how it actually works is on the right diagram. The bus is not in hierarchy, like the supposed design on the left. The services are on the same bus, so they all need to be secured. And it was neglected. Finally, we went to the Galaxy app store. Since Diva's client API are officially supported through the Enlightenment, we were able to develop a proof of concept. We were able to submit an app called BitWatch. The app watch face app only has internet-related privileges, but it dumps the notification internal data and sends it to a remote server. The app was submitted with some obfuscation to hide some strings and went through the verification process undetected as a malware. It went on sale for a brief amount of time until we took it out. We reported this research to Samsung in April. They were quick to respond with many patches committed to the Tizen open-source repository and some firmware updates were leased. Now, let's wrap up. To recap, in this session, we discussed the Tizen security internals. And around the objects and privileges, we focused on where they are valid. We talked about the three checkpoints, the client process, the scenario-aware demo statement, and the service process. Then we discussed then, which uses access denied, error message as an oracle to discover potential privilege violations. And finally, we disclosed the privilege violations that impact many system services of the Gear Smartwatch, Wi-Fi Bluetooth, screen notification, and email. Additionally, we showed up the possibility of distribution via the official store. So where can we go from here? There may be some questions. Can this tool be applied to other Tizen systems like TVs or refrigerators? Or how about other Diva systems like Linux? We can also think about some more advanced workaround techniques to bypass future mitigations enforced by Galaxy apps soar. That's it for the session. I would like to thank Professor Humpley-Tread for his guidance to us, Lee, for the insurance research, Betty Bae for the proofreading, and Goan Hong for the part into Steinbach for the advice. And that's it. If you have any questions, I would like to answer them. Thank you for listening.