We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Your Watch Can Watch You! Gear Up for the Broken Privilege Pitfalls in the Samsung Gear Smartwatch

00:00

Formal Metadata

Title
Your Watch Can Watch You! Gear Up for the Broken Privilege Pitfalls in the Samsung Gear Smartwatch
Title of Series
Number of Parts
322
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
You buy a brand-new smartwatch. You receive emails and send messages, right on your wrist. How convenient, this mighty power! But great power always comes with great responsibility. Smartwatches hold precious information just like smartphones, so do they actually fulfill their responsibilities? In this talk, we will investigate if the Samsung Gear smartwatch series properly screens unauthorized access to user information. More specifically, we will focus on a communication channel between applications and system services, and how each internal Tizen OS components play the parts in access control. Based on the analysis, we have developed a new simple tool to discover privilege violations in Tizen-based products. We will present an analysis on the Gear smartwatch which turns out to include a number of vulnerabilities in system services. We will disclose several previously unknown exploits in this presentation. They enable an unprivileged application to take over the wireless services, the user’s email account, and more. Further discussions will center on the distribution of those exploits through a registered application in the market, and the causes of the vulnerabilities in detail.
CAN busGradientAkkumulator <Informatik>Computer virusInformation securityGoodness of fitMultiplication signUniverse (mathematics)Default (computer science)
System callMobile appSmart DeviceTrailFitness functionEmailInformation securityProduct (business)InformationFirmwareSource codeComponent-based software engineeringPlastikkarteError messageFocus (optics)CodeValue-added networkSmartphoneMultiplication signFirmwareSource codeCodeProduct (business)Error messageConnectivity (graph theory)Information securityRevision controlSeries (mathematics)Mobile appInformationOpen sourceHypermediaExtension (kinesiology)Topological vector spaceKälteerzeugungVulnerability (computing)Uniform resource locatorProper mapRight angleClosed setObject (grammar)EmailSheaf (mathematics)Metropolitan area networkVideoconferencingServer (computing)MereologyClient (computing)Fitness functionPlastikkarteComputer animation
Web serviceService (economics)DemonAuthorizationObject (grammar)Level (video gaming)Computer networkInternetworkingSmartphoneDiscrete element methodService (economics)Cartesian coordinate systemType theoryTouchscreenString (computer science)DatabaseComputer fileSoftwareInformation securityMobile appMechanism designSign (mathematics)Installation artFocus (optics)Game controllerSoftware developerSinc functionDirectory serviceSocket-SchnittstelleUtility softwareSoftware frameworkLatent heatSensitivity analysisQuicksortAndroid (robot)Physical systemDemonSlide ruleInternetworkingProgram flowchart
Rule of inferenceDatabaseDemonSpacetimeData managementZugriffskontrolleDigital-to-analog converterSystem identificationKernel (computing)Control flowContext awarenessInformation securityMechanism designWeb serviceValue-added networkSampling (statistics)Type theoryMechanism designLatent heatBitRevision controlComplex analysisMobile appTesselationContext awarenessOcean currentObject (grammar)2 (number)DatabaseCartesian coordinate systemData managementSpacetimeRule of inferenceCurveConfiguration spaceComputer fileInformation securityKernel (computing)Axiom of choiceFile systemService (economics)DemonUniqueness quantificationGroup actionComputer animation
Web serviceProcess (computing)Uniqueness quantificationInterprozesskommunikationTelecommunicationPhysical systemFunction (mathematics)Client (computing)Message passingDemonOvalStatement (computer science)VirtualizationInterprozesskommunikationLogical constantSystem callFunktionalanalysisCartesian coordinate systemPhysical systemMessage passingService (economics)Right angleClient (computing)Computer animation
Uniformer RaumClient (computing)Process (computing)Physical systemInterprozesskommunikationWeb serviceFunction (mathematics)Uniqueness quantificationProcess (computing)Object (grammar)Client (computing)Service (economics)Uniqueness quantificationCASE <Informatik>Message passingBus (computing)Set (mathematics)Connectivity (graph theory)Computer configurationFlash memoryInterface (computing)Computer animation
Physical systemWeb serviceUniqueness quantificationClient (computing)Process (computing)Element (mathematics)Context awarenessComputer-generated imageryZugriffskontrolleMessage passingDemonInterface (computing)Task (computing)Client (computing)Process (computing)Service (economics)Object (grammar)Configuration spaceBus (computing)Computer fileStatement (computer science)Message passingArithmetic meanElement (mathematics)Validity (statistics)Personal digital assistantDemonInterface (computing)Attribute grammarProgram flowchart
Context awarenessPhysical systemDiskreter LogarithmusUltraviolet photoelectron spectroscopyWeb serviceBlogPrincipal ideal domainProcess (computing)Library (computing)ChainHacker (term)Reverse engineeringProxy serverString (computer science)LogarithmValue-added networkError messageMessage passingRule of inferenceInterface (computing)Library (computing)Client (computing)Process (computing)CodeResultantUniform resource locatorLocation-based serviceGastropod shell2 (number)ChainService (economics)Data managementProper mapFunktionalanalysisString (computer science)LogicPrincipal ideal domainSystem callError messagePatch (Unix)Semiconductor memoryMeasurementPhysical lawCartesian coordinate systemDemo (music)Server (computing)Message passingMathematicsStatement (computer science)Mobile appRight angleInheritance (object-oriented programming)Computer animation
DemonWeb serviceVector potentialPoint (geometry)Process (computing)DemonMultiplication signClient (computing)Uniform resource locatorPoint (geometry)Sheaf (mathematics)Service (economics)2 (number)Software developerLibrary (computing)Query languageGradient descentGraph (mathematics)Computer hardwareMalwareProgram flowchart
Value-added networkError messageMessage passingIdeal (ethics)OracleParameter (computer programming)Service (economics)Formal verificationFunction (mathematics)Scripting languageGastropod shellFile systemProcess (computing)Data structureCategory of beingMathematical analysisParameter (computer programming)SubsetError messageSoftware testingRoundness (object)Formal verificationProcess (computing)Data structureCategory of beingLocation-based serviceInterface (computing)Computer fileValidity (statistics)Service (economics)Server (computing)1 (number)Object (grammar)Exception handlingMathematical analysisBus (computing)Computer animation
Run time (program lifecycle phase)Service (economics)FirmwareLarge eddy simulationPhysical systemString (computer science)Hausdorff spaceUniqueness quantificationWeb serviceElectric currentComputer fileService (economics)Bus (computing)Medical imagingPhysical systemElectronic mailing listConfiguration spaceRun time (program lifecycle phase)Server (computing)CASE <Informatik>Shared memoryPulse (signal processing)XML
Object (grammar)Service (economics)Web serviceData structureInterface (computing)Standard deviationStandard deviationData structureObject (grammar)Physical systemService (economics)Latent heatRoutingDemo (music)Interface (computing)Parameter (computer programming)Dependent and independent variablesMessage passingRootkitXML
Standard deviationParsingFile formatValue-added networkParsingCategory of beingObject (grammar)Error messageString (computer science)Parameter (computer programming)Interface (computing)System callLogicRandom numberRight angleDefault (computer science)Interface (computing)Process (computing)MereologyCompilerString (computer science)Form (programming)Parameter (computer programming)Flow separationStandard deviationUtility softwareObject (grammar)Error messageMessage passingLogicDependent and independent variables
Letterpress printingRootkitDefault (computer science)Interface (computing)Performance appraisalObject (grammar)Vulnerability (computing)Default (computer science)ResultantService (economics)Bus (computing)System callPosition operatorError messagePoint (geometry)Right angleInterface (computing)Mereology
TouchscreenEmailWeb serviceDemonOpen sourceImplementationComputer networkValue-added networkTrailMalwareInformationElectric currentForceService (economics)Physical systemMalwareBitTouchscreenEmailTheory of relativity1 (number)SoftwareUniform resource locatorFreewareTotal S.A.Source codeDatabaseGraph coloringConnectivity (graph theory)Port scannerInterface (computing)Personal identification numberRadio-frequency identificationCategory of beingDemonStatement (computer science)Peer-to-peerCore dumpBus (computing)XMLComputer animation
SmartphoneForceAsynchronous Transfer ModeProgrammable read-only memoryBeer steinoutputMalwareForcing (mathematics)Inheritance (object-oriented programming)MalwareType theoryPhysical systemPersonal identification numberService (economics)Product (business)Asynchronous Transfer ModeInterface (computing)SubsetSmartphoneMultiplication signRight angleMedical imagingProjective planeCore dump
Link (knot theory)Network socketRevision controlUtility softwareInformationForceCore dumpCountingDigital filterInformationMalwareCore dumpDemonUtility softwareProjective planeStack (abstract data type)Link (knot theory)Inheritance (object-oriented programming)Key (cryptography)Table (information)Computer animation
InformationValue-added networkAxiom of choiceCore dumpComputer fileWindowTouchscreenAxiom of choiceProjective planeComputer fileData managementCore dumpView (database)XML
MalwareTransmitterData managementCartesian coordinate systemService (economics)TouchscreenMalwareTap (transformer)ResultantEmailMessage passingCASE <Informatik>
MalwareMessage passingEmailAddress spaceMobile appMessage passingEmailMalwareAddress spaceTheory of relativitySmartphoneComputer animation
Internet service providerString (computer science)EmailSystem callWeb serviceDemo (music)Proper mapError messageInformation securityString (computer science)Demo (music)Instant MessagingService (economics)EmailRight angleCodeMatching (graph theory)Computer animation
Group actionMalwareContent (media)TransmitterRight angleMalwareCartesian coordinate systemComputer animation
MalwareMobile appBitMalwareEmailCodeConnectivity (graph theory)Core dumpComputer animationLecture/Conference
MalwareCore dumpProcess (computing)Link (knot theory)Connectivity (graph theory)Computer-generated imageryEmailTouchscreenDecimalSerial portString (computer science)InformationLink (knot theory)MalwareConnectivity (graph theory)EmailMedical imagingCodeTouchscreenWindowMereologyComputer fileComputer animation
ParsingData structureMessage passingLink (knot theory)Field (computer science)MereologyObject (grammar)PasswordComputer fileGreatest elementService (economics)Message passingLink (knot theory)Demo (music)Berner Fachhochschule / Technik und InformatikKey (cryptography)Source code
Context awarenessCASE <Informatik>DemonComputer musicValue-added networkDuality (mathematics)DemonConfiguration spaceCartesian coordinate systemComputer fileDiagramRight angleHierarchyBus (computing)Element (mathematics)WikiService (economics)WeightCASE <Informatik>MiddlewareExistenceMessage passingComputer animation
Client (computing)Mobile appMalwarePhysical systemComputer networkInternetworkingDistribution (mathematics)Server (computing)Server (computing)Mobile appString (computer science)Client (computing)InternetworkingData storage deviceFormal verificationSinc functionProcess (computing)Proof theoryMalwareMultiplication signXML
Information security10 (number)Mobile WebExplosionService (economics)Patch (Unix)Repository (publishing)DreizehnDependent and independent variablesValue-added networkObject (grammar)OracleEmailTraffic reportingOpen sourcePatch (Unix)Client (computing)Process (computing)Service (economics)Vector potentialData storage deviceTouchscreenPhysical systemEmailKälteerzeugungDemo (music)Mobile appObject (grammar)Distribution (mathematics)Error messageInformation securityTopological vector spaceOracleComputer animation
DecimalComputer animation
Transcript: English(auto-generated)
All right, again, let's welcome Kim, it's first time. DEFCON, welcome. Hello. Let's hear it. That's it. Wow. Good afternoon. Thank you for coming to the session.
I'm very excited to talk to you about our research, your watch from WatchU, the broken privilege pitfalls in the Samsung Gear smartwatch. Before we begin, let me introduce us. My name is Dongseong Kim, and we are a security research lab called HIT
from Songyonggwa 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 smartwatch products. But apparently, a few days ago, they changed the name to the Galaxy Watch. So, for now, let's just pretend that it didn't happen.
They are advertised as offering many useful features, including like tracking fitness, or receiving or finding calls, texts, 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 contacts, your calendars, your locations, your emails, notifications, and 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 firmware for this kind of Gear smartwatch consists of two parts. So, one is the wearable version of Tizen OS, open source components. And the other is Samsung's closed source components
built on top of vanilla Tizen. So, Tizen, 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 Tizen. In 2015, Abraham revealed many problems
with Tizen at the time. In 2017, Letterman disclosed 40 zero-day vulnerabilities, and which made some media splashes. PVS Studio also analyzed a portion of the Tizen open source code base.
So, they claimed there would be more over 20,000 code errors. But this research served around the Tizen as a 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 Tizen's security concepts. In this section, we will highlight Tizen version three, 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 privileged daemons, each dedicated to a specific resource, like WiFi 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, Tizen achieves this by introducing the privilege. Services must validate if the calling app
has this proper once. So, similar to Android, app developer type in privileged strings in the manifest file. For example, on 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, after 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 these kind of privileges, to enforce these kind of policies, Tizen implements three plus one security mechanisms.
The first is the classic DEC, 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 DEC, SMAC, Sinara can recognize them. Now, let's talk about how applications actually talk to services.
Dbus is a widely implemented IPC system for Linux-like OS that also offers useful built-in functions, like discoverability or inspection. To put it simply, each service statement registers itself to the Dbus statement, then clients dispatch request messages
over a virtual channel. Tizen relies heavily on Dbus for IPCs, asterisk. So let me give you some Dbus concepts using an example on the right, a typical Dbus message call, it works like this.
So we wanna send a request from a client to a service, as 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 the service name. Then the request is to invoke set through 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, get foo, and finally, the service responds with a message, oh, sorry. So to recap, in one sentence, the client process has 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 DBUS is Sinara-aware, meaning it is patched
to natively perform privilege checks. So upon receiving a message, the DBUS statement in the middle asks Sinara for validation. So this approach allows DBUS statement to control access on messages. On the right example shows the Bixby assistant
bus configuration, bus configuration file. And you can see there is a check element with destination, interface, never message, and importantly, privileged attribute, Bixby agent.
So whenever DBUS 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 call sends a request to service
and its privilege gets validated. So we're gonna start with location manager API with proper location privilege. So last upper code shows that the privilege string is in the manifest, so the client process logic function below creates a manager 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 the same thing.
Then the result will come out negative 13, a failure. The log shows within the same PID, the process ID written within the parenthesis, shows a failure. Sinara check failed. Location library, a 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 DBUS access denied message, still within the same PID is printed out in violation of the privilege, HTTP something location. So, we can see the DBUS library, LBS DBUS client sends a request to LBS server,
and the error shows the request access is denied by DBUS 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, DBUS request is sent, then the DBUS 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 and that can actually secure the service. The second point, DBUS daemon on request in the 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 DBUS Analyzer. The idea is simple. So, let's say we send a DBUS request to a safe service like the 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 the non-privileged request
to all of them, all of the possible methods, then the other ones that return any other errors that is not access denied, that would imply the policies, at least the DBUS policies, accept non-privileged request, which could lead to violations.
So, we developed DAN. DAN automatically evaluates privileged verification of DBUS services. It spawns a test process on a remote device and then recursively scans the DBUS 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 DBUS structure flattened into JSON file, and the others are properties and methods that require further attention.
Now, 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 on the user share DBUS one. So, as shown on the left image of system D1, 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, colon something, something, and some are well-known, like some, in this case, or org, parse, pulse audio server, that config. Second, we recursively introspect the services.
That means gathering their structure, objects, interface, method, et cetera. Per the DBUS specifications, each service can respond with its object structure when the DBUS 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 in child objects.
Now, in this step, we try to read every property value. To do that, we use the DBUS standard method, get all on every object, but then uses the utility called the DBUS standard, which is one of the default utilities, but however, the responses from get all method,
as shown on the left, 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 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, so it's a generous thing, so that the actual logic 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 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 call all 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 then 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 D bus error, so then the tool categorized them callable. At this point, we started manually examine 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 wifi, 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 D bus API for WPA supplicant 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 statements on top of WPA supplicant. So we found every method is callable, and every property is readable. That includes create interface, remove interface, scan, WPS scan, software PS start, get pin, peer-to-peer find, connect, and more.
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 coordinates, which is our lab. Next, we have Bluetooth. The Project X.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 a pin. However, if the user sees the UI without any initiation, or without even entering the Bluetooth discovery mode,
then user will 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, and so on.
There is a bonus, though, 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 packets
with no super user privilege. Now, by combining the two, a malware can start dumping HCI packets, and force the pair of devices to disconnect, which will automatically reconnect with a new link key, and then extract the key from the dump.
Needless to say, this problem violates Tizen's Bluetooth-related, also private, privilege. Next, we take over the screen, too. Tizen'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 Tizen'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 this service actually handles private messages.
Actually, sending an email request does get rejected, but how? On the right, you have the code. First, we have the string vmail private sendmail noti. Then, it does a 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 are 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 Hangout certification,
then the data is handed over to the watch. 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 packets for a while. Then, yes. Then, the connection will reestablish 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 PCAP 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 PCAP 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 WiFi, we can get a clue from the Tizer Wiki. The left diagram shows how it was designed. On top of WPA supplicant, there are Tizer's conman daemon and net config 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.
VBUS 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 VBUS client APIs 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 watch face app only has internet-related privileges,
but it dumps the notification internal data, then 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 down. 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 released.
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 validated. We talked about the three checkpoints, the client process, the Sonata-aware demo statement,
and the service process. Then we discussed DAN, 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 geared 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 diverse systems like Linux? We can also think about some more advanced work-around techniques to bypass phishing mitigations enforced by Galaxy apps, SOAR.
That's it for the session. I would like to thank Professor Yung Vitred for his guidance. Joseph Lee for the insurance research. Betty Bea for the proofreading. And Goan Hong, Xinyu Park, and John Steinbach for the advice. And that's it. If you have any questions, I would like to answer them. Thank you for listening.