Breaking Smart Speaker: We are Listening to You
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
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 | 10.5446/39697 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
00:00
PlastikkarteHill differential equationDependent and independent variablesAndroid (robot)Information securityWeb browserPresentation of a groupValidity (statistics)PlastikkarteInformation securityVulnerability (computing)Boss CorporationSoftware bugWeb browserObservational studyMedical imagingLine (geometry)Metropolitan area networkComputer animation
01:29
Information securityMobile WebGoogolCurvaturePlastikkarteSurfaceMobile WebInternet der DingeVulnerability (computing)PlastikkarteRemote procedure callInformation securitySurfacePresentation of a groupPlanning
02:33
PlastikkartePlastikkarteProduct (business)FamilyInformation security
03:08
Mobile WebPlastikkarteTelecommunicationCommunications protocolSurfaceMessage passingExploit (computer security)DemosceneSoftwareSurfaceCommunications protocolMereologyCartesian coordinate systemComputer architectureInformation securityChromosomal crossoverGame controllerPoint cloudVulnerability (computing)PlastikkarteRemote procedure call
04:22
FirmwareUDP <Protokoll>Direct numerical simulationMechanism designHypermediaCommunications protocolInformation securityService (economics)FirmwarePhysical systemTelecommunicationSoftwareMetropolitan area networkRadon transformMereologyAdditionComputer animation
05:00
Communications protocolPoint cloudService (economics)Client (computing)DatabaseAdvanced Encryption StandardAuthorizationMIDIRootArmFirmwareUser interfaceCommunications protocolKey (cryptography)Connected spacePlastikkarteOrder (biology)Vulnerability (computing)Line (geometry)Computer simulationCountingCartesian coordinate systemAuthorizationToken ringString (computer science)Game controllerAuthenticationRoutingMereologyNetwork topologyAssociative propertyEmailMetropolitan area networkInterface (computing)Numbering schemeConfiguration spaceMusical ensembleXML
06:38
Local area networkRootHydraulic jumpPasswordAuthenticationConfiguration spaceCommunications protocolDrop (liquid)RootLoginJSONXML
07:28
Message passingPoint cloudServer (computing)Mobile WebServer (computing)Cartesian coordinate systemInterface (computing)TelecommunicationVulnerability (computing)Service (economics)User interfaceMessage passingComputer programPoint cloudPhysical systemCloud computingPersonal digital assistantBus (computing)Remote procedure callFunctional (mathematics)AdditionGame controllerDiagram
08:29
ParsingPhysical systemState diagramMessage passingExploit (computer security)Keyboard shortcutNumberVulnerability (computing)Identity managementSpeech synthesisChainUser interfaceHTTP cookieFunctional (mathematics)CodeRootCellular automatonPhysical systemCodeService (economics)Diagram
09:30
DemosceneVulnerability (computing)VideoconferencingDemo (music)MereologyLine (geometry)Application service providerUniform resource locatorArithmetic meanGodRemote administrationPlastikkarte
10:35
DemosceneEinheitswurzelFirmwareExploit (computer security)Server (computing)BootingUDP <Protokoll>SynchronizationVideoconferencingAndroid (robot)FamilyMereologyPersonal digital assistantInterface (computing)Electric generatorOrder (biology)Physical systemSheaf (mathematics)Computer hardwareUniformer RaumSimilarity (geometry)Software testingCanonical ensembleDot productBootingPort scannerSoftwareDemo (music)Computer animation
11:48
Civil engineeringFirmwareFlash memoryOrder (biology)Computer hardwareShape (magazine)Curvature
12:21
Demoscene2 (number)VideoconferencingDemo (music)Entropie <Informationstheorie>
15:03
Content (media)Entropie <Informationstheorie>Universe (mathematics)FirmwareMiniDisc
15:42
Insertion lossIdentity managementData typeFile systemBootingComputer-generated imageryPhysical systemEinheitswurzelFirmwareBootingInformationFlash memoryMiniDiscPartition (number theory)Order (biology)Dot productScripting languageMultiplication signInterface (computing)Closed setUniverse (mathematics)Field (computer science)Operator (mathematics)Medical imagingGastropod shellRootFirmwareFunctional (mathematics)Physical systemBinary codeBinary fileDemosceneRoutingOvalDrag (physics)Source codeJSONXML
16:58
DemosceneVideoconferencingDemo (music)Flash memoryMultiplication signArea
18:05
EinheitswurzelFirmwareSoftwareBasis <Mathematik>Operator (mathematics)RootDot productMereologyBasis <Mathematik>Computer hardwareSoftware
19:00
Connected spaceHacker (term)FirmwareModemPhysical systemIntegrated development environmentInformationBinary codeWeb 2.0SynchronizationPoint cloudPublic key certificateTable (information)Server (computing)Memory cardComputer programWordFirewall (computing)Client (computing)Connected spaceComputer animation
20:22
Server (computing)RootDemonCache (computing)Control flowUDP <Protokoll>SynchronizationWeb 2.0Server (computing)InformationMereologyGame controllerRootJSONXMLComputer animation
21:05
Server (computing)Public key certificateClient (computing)Function (mathematics)InformationTransport Layer SecurityPublic-key cryptographyClient (computing)Server (computing)Functional (mathematics)Public key certificateInformationCurveComputer animation
21:48
Group actionService (economics)MultilaterationKeyboard shortcutGroup actionWebsiteResultantDigital rights managementHTTP cookieMultiplication signXMLComputer animation
22:46
LoginTime domainWebsiteParameter (computer programming)Rule of inferenceVulnerability (computing)WebsiteMultiplication signLoginWeb pagePublic key certificateOpen setGradientDomain nameComputer animation
23:42
EmulationTime domainLocal area networkAddress spaceGoogolExplosionIP addressDomain nameWebsite2 (number)Electronic mailing listAddress spacePreconditionerLocal ringTraffic reportingXML
24:21
Row (database)Local area networkAddress spaceServer (computing)HTTP cookieDirect numerical simulationRootServer (computing)Address spaceMobile appWeb 2.0Hacker (term)HTTP cookieWeb browserService (economics)Domain nameLattice (order)
24:55
LoginHTTP cookieSynchronizationPublic key certificateKey (cryptography)Function (mathematics)InformationPoint cloudWeb pageHTTP cookieWordInformationKeyboard shortcutPublic key certificateFunctional (mathematics)Domain namePublic-key cryptographyWebsiteLoginServer (computing)Parameter (computer programming)NeuroinformatikKey (cryptography)Group actionComputer architectureService (economics)Computer animation
26:42
Core dumpKey (cryptography)AlgorithmComplex (psychology)Assembly languagePublic key certificateKey (cryptography)WordAlgorithmFunctional (mathematics)Computer fileSinc functionMathematicsComputer animation
27:15
Server (computing)Public key certificateClient (computing)Core dumpFunction (mathematics)Key (cryptography)Information managementMIDIFirewall (computing)AuthenticationSynchronizationCodeWeb pageIntegrated development environmentWordComputer programClient (computing)AuthenticationFunctional (mathematics)Multiplication signVulnerability (computing)Public-key cryptographyComputer animation
28:04
CodeRevision controlBinary fileRevision controlLibrary (computing)Binary codeInformation securityVulnerability (computing)CodeXMLComputer animation
28:49
CodeFunction (mathematics)SequenceServer (computing)Address spaceDirected setVulnerability (computing)Game controllerRootExploit (computer security)CodeFunctional (mathematics)Software testingLibrary (computing)Server (computing)Web 2.0CausalityFunktionalanalysisMultiplication signSynchronizationCondition numberWordSequenceComputer animation
29:38
Data bufferIntegerBuffer overflowUser interfaceChainInformationLeakString (computer science)outputMemory managementContent (media)Shape (magazine)Control flowContent (media)Buffer solutionComputer chessoutputParameter (computer programming)Vector potentialNumberReading (process)IntegerWeightComputer virusConnected spaceEmailSign (mathematics)Position operatorPoisson-KlammerLine (geometry)CodeKey (cryptography)Host Identity ProtocolLeakWeb 2.0InformationString (computer science)Negative numberMenu (computing)ResultantMetadataMemory managementDataflowSemiconductor memoryBuffer overflowFunctional (mathematics)Interior (topology)AlgorithmElectronic mailing listPhysical systemLengthReal numberNetwork socketXML
32:45
Proxy serverResource allocationRead-only memoryMemory managementAddress spaceContent (media)Host Identity ProtocolMemory managementVulnerability (computing)Buffer solutionMultilaterationWeb pageResource allocationCASE <Informatik>Thread (computing)ArmSemiconductor memoryAddress spaceElectronic mailing listGastropod shellCodeAreaAlgorithmMereologyLevel (video gaming)Computer programGoodness of fitThresholding (image processing)Slide ruleComputer animationXML
34:02
InformationLeakComputer networkFile Transfer ProtocolVulnerability (computing)RootFile Transfer ProtocolCartesian coordinate systemConnected spaceCore dumpVulnerability (computing)ResultantCASE <Informatik>LeakTouchscreenSoftware testingBuffer solutionInformationSoftwareInternet der DingeComputer animation
34:55
Computer fileFile Transfer ProtocolExtension (kinesiology)Server (computing)Address spaceCodeModul <Datentyp>High-level programming languageVulnerability (computing)Computer fileCurveObject (grammar)Game controllerFunctional (mathematics)Communications protocolConnected spaceMultiplication signExtension (kinesiology)CodeLogic programmingFile Transfer ProtocolPoint (geometry)Parsing2 (number)Branch (computer science)PLS (file format)Cache (computing)Address spaceComputer animation
36:15
Function (mathematics)Computer wormLeakAddress spaceCalculationComputer wormAddress spaceLengthFunctional (mathematics)Library (computing)AreaHost Identity ProtocolSequenceScripting languageCurvePoint (geometry)Memory management
36:55
Function (mathematics)Pointer (computer programming)Revision controlEmailCodeWeb 2.0Object (grammar)Source codePointer (computer programming)WritingForm (programming)Visualization (computer graphics)Functional (mathematics)Server (computing)CodeRevision controlClient (computing)Dependent and independent variablesRight angleComputer animation
37:47
InformationLeakMemory managementType theoryIdeal (ethics)Digital object identifierWordException handlingCASE <Informatik>Multiplication signPrimitive (album)CodeRemote procedure callAddress spaceLeak
38:20
Thread (computing)Software testingReal numberBit rateHacker (term)Condition numberStress (mechanics)Thread (computing)AverageHecke operatorConnected spaceCrash (computing)Dependent and independent variablesSemiconductor memoryObject (grammar)Multiplication signVideo gameMemory managementBit rateReal numberSoftware testing
39:34
Physical systemRevision controlThread (computing)Web pageSocial classLibrary (computing)File formatStructural loadInfinityLoop (music)Process (computing)LengthMetadataFunctional (mathematics)Semiconductor memoryDemo (music)Address spaceVideoconferencingComputer programStress (mechanics)Row (database)
40:48
DemosceneVideoconferencingCodeMusical ensembleMereologyScripting languageLattice (order)Server (computing)Source codeJSONXML
41:25
Asynchronous Transfer ModeDemosceneVideoconferencingRemote Access ServiceSource codeExploit (computer security)FirmwareBinary fileComputer programLattice (order)Disk read-and-write headWeb pageInformationSoftware developerFirmwareCode refactoringCodeRemote procedure callInformation securityVulnerability (computing)Web 2.0Binary codeComputer animationDiagram
Transcript: English(auto-generated)
00:00
Hello everyone, thank you for coming, and we are very excited to share our research at DevCon. Our presentation today is to talk about the security of smart speakers. We found and exploited some vulnerabilities to attack some smart speakers, such as Xiaomi AI Speaker and Amazon Echo.
00:27
First, please let me introduce my teammate and myself. Ni Rui Xian is a security researcher at Tencent Blade Team. He has found several vulnerabilities in Android, and he was the speaker of Haging Boss, and he worked with us to complete all the work of whole study.
00:46
Unfortunately, he is not home work today. And this is my teammate Chen Yunxian. He is also a security researcher from Tencent Blade Team, and he is one of the top 100 what-have-nots of AMSRC.
01:00
He wrote a book named what-have to talk about web browser security. My name is Yu-Hui Yu, and you can communicate. I'm a security researcher at Tencent Blade Team. I'm also a bug hunter, winner of Geek Palm, and speaker of Haging Boss and POC. And here we would like to thank some people,
01:24
especially NAGA2 and Gmail XP. They gave us a lot of support. Next, let me introduce the Tencent Blade Team. Our team comes from Tencent Security Plan Fund Department. Now, we are focusing on the security research of AI, IoT devices, mobile devices.
01:46
In the past two years, we have found more than 17 security vulnerabilities for many companies, such as Google and Apple. And you can contact us at blade.tencent.com.
02:05
Before we start our presentation, let's take a brief look at the outline. First, we will give an introduction to smart speaker, and then we will talk about the attack surface of smart speakers. Then we will share the details of remote attack Xiaomi AI speaker
02:24
and how to break in Amazon Echo. At last, we will summarize our research. Smart speakers is the most popular smart home devices in the past two years. Amazon, Google, Apple, and some Chinese vendors
02:43
have released their own smart speaker products. The Amazon Echo family is the most popular smart speaker on the market. It has more than 13 million users, and many people are very interested in its security,
03:03
so we choose our research target. Another research target is Xiaomi AI speaker. Xiaomi AI speaker is very popular in China because it can control many smart devices in Xiaomi ecosystem.
03:23
Next, let's briefly analyze the attack surface of the smart speaker. In smart speaker architecture, many include three parts. The first part is smart speaker device, the second is the cloud server, and the last is mobile phone application.
03:42
The attack surface of this architecture contains many parts. The first part is the hardware interface and the network worth of the smart speaker device. The second part is the security of the mobile phone application. The third part is the security of the cloud server,
04:02
and the last part is the security of the communication protocol between them. Then, I will talk about how we can explore multi-temporal vulnerabilities to remote attack Xiaomi AI speaker. These include five parts.
04:25
Xiaomi AI speaker had a built-in system based on OpenWRT. Its SSH service was disabled, and the firmware of the speaker can be downloaded easily by an HTTP request, but we cannot replace the firmware with many media attacks
04:44
because of its security mechanism. In addition, it opens up the network ports and the 54321 is the communication port of the MiIO protocol.
05:02
MiIO protocol is used to configure and control smart home devices made by Xiaomi. It is an encrypted binary protocol. After analyzing the firmware of Xiaomi AI speaker, we found that the data included in the MiIO package was passed into U-Bus commanders
05:22
and executed by Xiaomi AI speaker with root permission. So, if we can simulate Xiaomi smart devices to communicate with Xiaomi AI speaker, we can use this protocol to execute root commander, which is root commander execution vulnerability in line.
05:47
In order to explore this vulnerability, we first need to establish a connection with the speaker and pass the authentication of MiIO protocol. This will require us to obtain an AES key for connection.
06:02
We call this key as a token. This token is 16 beta string to get this token. We need to use the Mi Home application to rebind the speaker to attack the ARM count. Then, extract the token from the application's database.
06:22
We found a web interface authority vulnerability, so we can only need to get the device ID to unbend any speaker device. And we found the device ID can be obtained by sniffing in the line. After we got the token,
06:42
we can use some tools to connect the Xiaomi AI speaker by MiIO protocol. Then, we can send some U-Bus commanders to the speaker. The first commander is used to modify the drop beer configuration, and the second commander is to turn off the drop beer password authentication.
07:05
Finally, we need to start the drop beer. After executing these U-Bus commanders, we can successfully access the SSH of MiIO's speaker and log in without passwords.
07:22
And it means we have obtained the root permission of the speaker. In addition, we found another vulnerability in a program called Message Agent, which is used to MQTT communication between the speaker and cloud servers.
07:42
When a user controls the speaker's function in a mobile phone, the application communicates with the cloud server first. Then, the cloud server sends the device ID and commander to the message agent. Then, the message agent will execute the commander.
08:03
We found two special web interfaces. One is remote U-Bus, which can call the U-Bus service remotely, and another is remote OTA. The commander sent by calling this interface will be executed using the system function,
08:24
which is a remote system commander execution vulnerability. There are two pieces of the vulnerability code that are analyzed using Adapro. One that finally calls the U-Bus service,
08:42
and the second finally works the system function. Since these two vulnerable web interfaces have identity authentication, if we want to explore these vulnerable remotely,
09:01
we have to get the user's cookie for the speaking binding. In the natural research, we found two access vulnerabilities in account.xiaomi.com, which allows us to remotely steal a large number of Mi AI speakers' users' cookies. So now, we can explore these vulnerabilities to complete the attack chain
09:25
of remotely obtaining the root permission of a Mi AI speaker. Now, let's take a brief look at the first demo video. This video demonstrates the two vulnerabilities we mentioned.
09:45
The first part of the video demonstrates connecting to the speaker via SSH in the line and controlling a piece of audio.
10:14
Because Xiaomi AI speaker doesn't speak English, so we control the Chinese meaning winner winner chicken dealer.
10:24
In the second video, the victim's smart speaker is remotely controlled by the attack after cleaning the URL. Okay, now we will finish the section on Xiaomi AI speaker.
10:42
Let's talk about how to break an Amazon echo. These include six parts. And now, we will quickly talk about the previous four parts and the explore detail and demo video will be shared by my teammates.
11:01
First, let's have a brief look at the Amazon echo. In the newly released second-generation echo family, all of the Amazon echo devices use similar hardware and systems, so we choose the Echo Dot as our test devices.
11:22
Amazon Echo Dot has built-in Fire OS, which is actually a system based on Android. It turns on AC Unix and ASR, locks the port loader and it has a USB interface but can only be used for charging.
11:43
We also found some network ports by scanning. At the beginning, we tried to get the firmware for a long time, but we got nothing. So, we choose to start with the hardware and extract the firmware directly from the flash chip.
12:04
In order to extract the firmware from the flash chip, we need to prepare a lot of hardware to us, which includes hot air gun, soldering, error, rebalancing tools and so on.
12:22
This is the second demo video. This video shows how to disorder the chip from the PCB in six minutes and then rebalancing the chip.
12:41
To save time, we doubled the video speed. The most important skill is to choose a suitable temperature and be careful.
15:04
When we disorder and rebalancing the chip, we need to choose a suitable chip adapter according to the chip's datasheet. Amazon Echo uses the BGA221 package EMCP chip,
15:21
which we can easily buy an adapter on Taobao or eBay. We also can buy a universal EMMC reader and connect the adapter to the USB reader device, so that we can read and write the firmware content in the EMCP chip easily.
15:43
This is the disk partition information we extracted from the flash chip. It contains many parts, such as preloader, bootloader, boot image, system, and so on.
16:01
When we got the firmware, we had another important thing to do, that is to modify the firmware to create an Amazon Echo Dot with root permission. This can help us quickly debug some vulnerabilities. Because the Amazon Echo Dot turned on the AC universe and locked the bootloader,
16:21
we cannot directly modify the boot image to root. We need to close AC universe and then add the superuser binary field to the system and start. And then we need to open the system ADB function. We add these operations to a shell script that starts the make-turning,
16:46
so that every time the system boots, it can make sure we can collect the Echo Dot from its USB interface and get the root permission.
17:02
This is the third demo video to show how to solder the chip. After completing this modification, we need to re-soar the flash chip back to the PCB.
17:23
This video demonstrates how to re-soar the chip back to the PCB in three minutes. To save time, we also doubled the video speed.
18:11
Before we complete these operations, we have got a rooted Echo Dot. My part is over. Thank you for listening.
18:24
Now, please welcome my teammate, Chen Wenxiang. Hello everyone. Now I'm going to give a talk about how to turn Amazon Echo to an eavesdropping device on the basis of software.
18:46
Earlier, my partner has given a great talk about how to hack into the Echo device on the basis of hardware. The physical hack is very important. Without that, exploiting will be much difficult for me.
19:01
So, how many steps would it take to hack into a device? The first attacker exploits it, and then the victim connects to the hacker, and then the hacker does whatever he or she wants to do. Yes, the step is simple, but on a well-protected system, things will get a little complicated.
19:21
Since we already got the firmware and debug environment, we are able to check the restrictions that Amazon has set up for us. So first, please allow me to introduce protections we need to bypass first. There are three firewall-like things. The system uses IP tables to allow only a few ports from accepting connections,
19:46
and the SELinux is also enabled. We managed to find a binary with high privileges to bypass it. This binary is a vulnerable program, as shown in the picture, and it has a web server activated.
20:03
To communicate with it, we must pass a client-authenticated TLS handshake. That means we must get the certificates and other things. But those certs are obtained from the cloud synchronizing. In other words, we need to get the cloud synchronizing information of other devices.
20:23
So a attacker is always happy to see there's a web server available. That explains why we choose this binary to be our target. In the next few slides, please allow me to introduce some background information so we can go through these things more clearly.
20:41
The WORD, W-H-A-D, which is a whole-home audio daemon, it is a huge binary runs at the root and with network access and is able to record voice. Also, the most exciting part is it would open a web server. The HTTPS server runs on port 55443, and it accepts control commands.
21:06
But things are not going as we wish it to be. The HTTPS server introduces client-authenticated TLS handshake. That means we must have a server certificate, client certificate,
21:20
and a private key to communicate with it. That sounds difficult, but we have also noticed that the physically rooted device can also pass a check and communicate with other devices. So the information must be stored somewhere. By reading the document of libcurl, we know we can extract all certificates
21:43
and private key from libcurl's negotiate function on a rooted device. To do the trick, the first thing we need to do is to bind our rooted device into a victim's account. I'll explain why we do this later.
22:02
By auditing Amazon's website, we have found two XSS, and both need two steps of user's action, so we decide not to use them. But the XSS here is fatal. You can steal privacy or control the device with a cookie obtained from XSS because Alexa dashboard is lack of modern protections,
22:24
such as CSP, which is content security policy, and HTTP online protects. Yes, by using the XSS, you can get the same results of what we'll talk later. But we also found another method which is the quickest and easiest way for us.
22:43
That is to spoof an Amazon website. We have found that every time when we log into the Alexa, there's an OpenID login page, and there's also a redirect parameter in the URL. By modifying that parameter, it will redirect to any domain,
23:02
which is a subdomain of amazon.com in HTTPS. Since we want to mimic Amazon's website, so we don't want to mess up with an HTTPS certificate, we'd like to have an HTTPS downgrade redirect. Luckily, we have found the site associated with redirect.amazon.com.
23:23
Its validating rule allows us to downgrade to HTTP. It also has some vulnerabilities that could be redirected to other sites, which is not belongs to Amazon and leaking some token from OpenID. But now the only thing we need is the downgrade.
23:44
Okay, we want to spoof Amazon's website inside victim's LAN, but there are two preconditions. The first one is the attacker need to be joined the victim's LAN, and the second is we need to find an Amazon domain which resolves to a local address.
24:01
An attacker can be joined into the LAN with that IP address, and both are not hard to be satisfied. You can get a list of subdomains from Google transparency reports. Then you can disable DHCP to use a static IP address to join into the LAN.
24:23
We have found the app service which resolves to a local address. If attacker could join the LAN of victim with that address, then start a web server. When victim tries to visit appservice.amazon.com in his or her browser, actually the victim is visiting the hacker's website.
24:45
Also, because it has a root domain of amazon.com, the cookie will be sent to the attacker automatically from the browser. To sum up, first the attacker joins the LAN,
25:00
and when victim logs in from the Alexa login page with a redirect parameter set to associate with redirect.amazon.com, and when victim finishes the login, the page will redirect to associate with redirect.amazon.com. Then this site will downgrade and redirect to appservice.amazon.com.
25:23
This domain resolves to attacker's computer, and the user will finally visit the attacker's website with a cookie sent to it. Then the attacker binds his device into victim's account using the cookie. And finally, we can communicate with other devices of victim.
25:42
And the first problem is solved. We have got a device that could pass the first check. Then we will use that device to extract certificates and private keys from negotiate function. But first, I'd like to show you a simple picture about the architecture,
26:02
which shows how Word gets the device info when it starts, and why we need to bind it into victim's account first. If you have many devices in your account, they will group as a cluster automatically. When lxrd starts, it will obtain information from Amazon server,
26:24
and when Word starts, it will get those information from lxrd. And when a device wants to update something, the lxrd will notify the Amazon server, and the server will later notify all other devices in that cluster to synchronize.
26:43
Because the key will change when Word starts, to automate the exploiting later, we choose to patch the Word. The Word will periodically send an https request to other devices to know if they are still online. By replacing the negotiate function to the assembly code written by us,
27:04
we can dump the certificates to a local file. It is simple and violent, but anyhow, it works. So we don't need to crack the complex algorithm. Since everything is taking place on attacker's device, to simplify the environment,
27:22
we have disabled all protections on the physically hacked device. The code is a little complicated, so we are not going to talk about this now. You may check our GitHub page to get the full code in assembly. So in another Word, we try to dump those things to three files and use them later in the attack.
27:44
Now we have dealt with a client authentication problem. Every time before we want to perform an attack, we run the patched Word to get the third and private key. Then we can go to the last step to break the vulnerable program, Word, on victim's device.
28:07
Since we are going to attack it, there must be vulnerabilities to be exploited. So let's go back to the binary auditing. So we have audited almost every binary and we found the binary written by Amazon themselves
28:21
are secured by design. But we have also noticed that Echo is using the very old version of the third-party libraries. They are all nearly four years old. You can see the picture. It shows they are using some code of year 2014. So also, Amazon tries to apply security patches to them.
28:43
There are still many end days and zero-day vulnerabilities. They are gold mine. Okay, it's time to dig the gold. That is to attack the web server and get control of Word. And how's the feeling for you to audit some code
29:02
written from four years ago? Maybe a little relaxed, I guess, because old code with poor tests often leads to serious problems. It took me a week to find the treasure, but when we first found the exploitable function, nobody involved caused it. Luckily, Amazon updated the binary two months later
29:22
and we have found that a lot of functions are referencing this function. The root cause of the vulnerability is the library has failed a condition check and thus a lot of vulnerabilities happen in sequence. Let's take a look at the questionable code.
29:43
First, you can see the content length is a user-supplied code and CV2Web tries to get the value from HTTP header and convert it into an integer. The ATOI accepts negative numbers as input and will return a signed integer.
30:01
What I don't quite understand is why they convert the value from signed integer to unsigned here. If the variant is unsigned, the code if content length is greater than zero is actually equal to if content length is not zero. So maybe the unsigned here is a typo.
30:20
And next, the if check. Negative one equals to the biggest number of unsigned int so we will also pass a check and then the number plus one is again an integer overflow. The result is zero. MLOG zero is valid because echo system is using DLMLOG as a MLOG algorithm.
30:45
As the menu says, even input is zero, it can still allocate a small buffer for you to write in. Next, in the mgread call, there's a heap buffer overflow. We'll talk about this soon. And there's a minor one. The post data bracket content length assigned to zero
31:03
will write zero at negative one position. Leave the string not zero terminated. That is a potential information leak because this function is used to get the parameter's value. So it's just like the chess. A bad move might lead to a total loss.
31:22
Okay, let's go back to the heap buffer overflow. The dogliest MLOG, DLMLOG zero will allocate 16 bytes. That means 8 bytes of metadata plus 8 bytes buffer where we can write our data to. In the mgread, data read from HTTP request
31:40
is written into buffer. The good thing is this function will fix the input length, so if we are giving the huge number as we did, it will fix the length till real data length remains in the socket buffer. Then it will copy the data from socket to MLOG buffer. So if we try to post a string longer than 8 bytes,
32:03
there will be a heap buffer overflow. So do you remember the size of MLOG is controlled by user? We can send content length to control it. If we don't send the full HTTP request by omitting the terminating written carriage and new line,
32:22
the MLOG heap buffer will remain in the memory without being freed. When we need to free the buffer, we could simply send the remaining written carriage and new line. Then the connection is closed and the buffer is freed. By the way, the mgread will write anything including zero charts to buffer,
32:41
so it is very convenient for us to exploit. Since we can control the content of heap, one thing we wanted most is the vulnerability to bypass ASLR. That will be good for us to do the heap buffer overwrite and heap spray later.
33:02
First, let's talk about the heap spray part. If we want to exploit it, we must try to control area to put our shellcode in. The anonymous memory is a good place. Large heap allocation requests that cause the MLOG to use MMAP anonymous memory
33:21
is controlled by the MMAP threshold variant of dmlog. Although there's a hundred of threads running in the background, there's only we want to allocate such huge memory. Because the algorithm of the MMAP, the address is started from a predictable range, even when ASLR is enabled.
33:42
You may check the article in our reference in the last page of this slide to know the detail. In our case, we have got an address that has a good chance to be allocated. We have got this value by just running the program again and again, and it is an experience value.
34:03
So after we have got a buffer to put our shellcode, we may also need an information leak to do the rest of things. The IoT device is different from the desktop applications. There's no screen for us to know the results, so if the leaked data is sent to us through the network,
34:22
that will be great. Finally, an information leak of libcurl in FTP connection is proved to be exploitable. By the way, this is an end-day vulnerability, so libcurl don't give the POC, but we try to reproduce this problem from libcurl's patch and test cases.
34:43
We see to trigger this vulnerability, we need to reuse a curl handle. That means we need to use the same handle to connect to the same FTP server, not less than twice. Okay, let's back to the program logic of WAD.
35:01
We have found the control command. Its name is download audio. Normally, it would download only a single file and the curl handle is closed. But we have dug into the code deeper and found that if the extension is pls, it will parse the pls file and use the same curl object to download every file in it.
35:23
And from the second connection, curl will reuse the FTP handle and trigger the vulnerability. The picture shows the detail of the file. We use PHP redirect to bypass the protocol restriction of WAD. Also, if the pls downloaded successfully,
35:42
WAD will use the cache and will not accept the same request twice. That means if curl's FTP function fails to leak any bytes, unless it is restarted, WAD will not accept our downloaded request again. And we don't want to see this happen, so we check the code branch
36:02
and found if one of the URL points to a file that doesn't exist, there will be no cache. So we can send the same request as many times as we want until we leak an address. We use a Python script to automatically adjust the payload
36:21
and finally we have found the size 103 where we use a freed heap area which contains an address pointing to a function of curl. And based on this address, we can calculate the loading address of curl and furthermore address of every libraries. Because the LD.so will load
36:43
DT needed libraries in sequence, so you can simply calculate the next or previous libraries address by plus or minus the length of adjacent SO library. So we have everything we need, so how do we execute the code?
37:02
The web server is powered by OpenSSL. An SSL object is created when a request is coming. So if you happen to read the source code, you will find there are many function pointers in that object. When libcvtweb wants to respond something to the client SSL write is called.
37:23
So all we need to do is to overwrite the SSL write pointer. And to simplify, we have found a faster way to trigger SSL write. It will send more form HTTP version. While this is a code in the older version of libcvtweb, this code only works safely in Linux.
37:42
You may try whatever happens if you compile it in Visual Studio. In summary, we have got six attacking primitives. The first one is to restart the word so we can cause an exception in words in case we can't leak the address
38:00
or start for a long time. We may want to restart the program and give it another try. And other five primitives are also listed here. So now all we need to do is to compile them to get a remote code execution. So now it's time to pump.
38:22
I have to say it has a possibility to fail because the background threads are messing up the heap. And another reason is in the last step, the memory condition is a little like to fall into a risk condition problem. We have a connection to overwrite the SSL object of another connection.
38:41
If anything of the thread being written is called before the overwriting is done, it will fail. Or if any background thread caused a zigzag-v, that's a fail too. For a full bias testing gadget, we have 14% chance to set the PC value to it. But the real-life gadget is six times longer
39:02
and the success rate is down to about 8%. But the good news is what will respond after it will, sorry, the good news is what will be respond after crash automatically. So we can do the exploit again and again.
39:22
That is to entrust the hack to time. The average success time is about 13 minutes in our laboratory with about 10 tries. If we can control the PC, we need the last thing to start the eavesdropping.
39:41
That means a shellcode. We use function offset from library plus leaked library's load address to get the function address in memory. We added two handler for zigzag-v and zigabot with infinite loop in our shellcode to prevent any background threads from crashing the process.
40:02
We have also now the length of metadata of the memory page where shellcode are placed to prevent this page from being freed. We try to use the class audio recorder to record the voice and send it by TCP to attacker. And the voice is recorded in PCM format.
40:23
And the shellcode could be found in our GitHub page too. And finally, you can see we have dealt with every problems what is now turning to eavesdropping program. It's eavesdropping in the background and sending every voice data to the attacker.
40:42
Do you want to watch the video? Of course, we have prepared a demo video which shows the whole story. Yeah, this is a normal echo dot. And the left part is the attacker server
41:00
and the right part is the exploiting script. When the exploit success, the victim will connect to us and you can see the log is shown on the left. Any meeting tomorrow? Yes.
41:35
Do we have any meeting tomorrow? Yes. Yeah, that's it.
41:51
So you don't need to worry about this. The vulnerabilities we have found have all reported to the developers and fixed in June 2018.
42:01
Amazon has already automatically updated echo devices with security patches and the vulnerabilities we have mentioned are already all fixed. And you can find the code and contact information on our GitHub page. And last, a little head tips from our experience.
42:21
The first, to hack an IoT device you need to get the firmware first and it is good to master all kinds of soldering and firmware extraction methods. And web plus binary vulnerabilities often equals to remote code execution. And the most important thing is to be patient. Your hard work will finally piss off.
42:44
And so thank you for listening and thanks to my partner too.