Breaking Google Home: Exploit It with SQLite(Magellan)
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 335 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/48421 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
DEF CON 2739 / 335
8
9
12
14
32
38
41
58
60
61
72
75
83
87
92
96
108
115
128
132
143
152
158
159
191
193
218
230
268
271
273
276
278
295
310
320
321
335
00:00
ExploitGoogolComputersicherheitCross-site scriptingCodeFokalpunktSharewareSystemplattformPunktwolkeUnrundheitComputersicherheitFlächeninhaltPlastikkarteSoftwareschwachstelleMereologieFlächentheorieInternet der DingeKontrollstrukturProgrammfehlerQuaderExploitPunktwolkeBrowserSatellitensystemKurvenanpassungSystemplattformFamilie <Mathematik>Computeranimation
02:30
PlastikkarteCodeWurzel <Mathematik>KontrollstrukturFamilie <Mathematik>DatenfeldProxy ServerComputersicherheitPlastikkarteDiagramm
03:03
GoogolHardwareBenutzeroberflächeFlash-SpeicherFirmwareFamilie <Mathematik>SoftwaretestMereologieHardwareFlash-SpeicherBefehlsprozessorAnalysisFirmwareBus <Informatik>Computeranimation
03:39
FirmwareSpeicherabzugTrägheitsmomentLogarithmusLangevin-GleichungPersönliche IdentifikationsnummerDigitaltechnikSpeicherabzugDifferenteSoftwaretestWhiteboardFunktionalPASS <Programm>ProgrammProdukt <Mathematik>Computeranimation
04:27
SpeicherabzugFirmwareKanal <Bildverarbeitung>Graphische BenutzeroberflächeProzess <Informatik>Flash-SpeicherSpezialrechnerZustandsdichteLesen <Datenverarbeitung>Produkt <Mathematik>ProgrammFlash-SpeicherBildgebendes VerfahrenPhysikalisches SystemUmwandlungsenthalpieFirmwareTrigonometrieComputeranimationProgramm/QuellcodeXMLFlussdiagramm
05:05
Physikalisches SystemGraphische BenutzeroberflächeFunktion <Mathematik>BrowserGoogolNabel <Mathematik>Physikalisches SystemGraphische BenutzeroberflächeFunktionalBrowserGewicht <Ausgleichsrechnung>MereologieComputeranimation
05:42
Mechanismus-Design-TheorieComputersicherheitGoogolOpen SourceQuellcodeMereologieHIP <Kommunikationsprotokoll>FirmwareBinärcodeComputersicherheitFirmwareProgrammRelativitätstheorieBootenKernel <Informatik>Open SourceGoogolAttributierte GrammatikComputeranimation
06:31
E-MailSpezialrechnerProgrammverifikationLastPhysikalisches SystemPartitionsfunktionBootenGoogolComputersicherheitGewicht <Ausgleichsrechnung>RSA-VerschlüsselungKonsistenz <Informatik>BootenMechanismus-Design-TheorieBildgebendes VerfahrenComputersicherheitInternet der DingeGoogolMathematische LogikPhysikalisches SystemEinflussgrößeIntegralProgrammverifikationComputeranimation
07:21
Graphische BenutzeroberflächeMechanismus-Design-TheorieComputersicherheitNamensraumBootenAdditionProgrammMechanismus-Design-TheorieAuswahlverfahrenNamensraumGraphische BenutzeroberflächeFlächentheorieHalbleiterspeicherFirmwarePhysikalisches SystemNabel <Mathematik>VerzeichnisdienstSchnitt <Mathematik>Minkowski-MetrikComputeranimation
07:58
FlächentheorieGoogolRechnernetzDrahtloses lokales NetzHardwareFirmwareWurzel <Mathematik>Flash-SpeicherBootenProxy ServerServerHackerKeller <Informatik>UmwandlungsenthalpieWeb-SeiteGraphische BenutzeroberflächeBrowserProtokoll <Datenverarbeitungssystem>Lokales NetzServerGoogolComputersicherheitProtokoll <Datenverarbeitungssystem>Nichtlinearer OperatorMultiplikationOffene MengeFlächentheorieComputeranimation
08:35
HardwareWurzel <Mathematik>Drahtloses lokales NetzFlächentheorieGoogolRechnernetzFlash-SpeicherProxy ServerBootenHackerGraphische BenutzeroberflächeKeller <Informatik>Protokoll <Datenverarbeitungssystem>UmwandlungsenthalpieBrowserWeb-SeiteSoftwareentwicklerApp <Programm>Protokoll <Datenverarbeitungssystem>CADFlächentheorieURLSpeicher <Informatik>Kartesische KoordinatenGraphische BenutzeroberflächeSoftwareschwachstelleLokales NetzGanze FunktionGoogolFirmwareBootenGarbentheorieComputerarchitekturInternet der DingeApp <Programm>InstantiierungAuswahlverfahrenLastBimodulComputeranimation
09:56
KonfigurationsdatenbankFlächentheorieProtokoll <Datenverarbeitungssystem>BrowserGoogolWeb-SeiteComputersicherheitKartesische KoordinatenSpeicher <Informatik>AdressraumApp <Programm>Interrupt <Informatik>Protokoll <Datenverarbeitungssystem>Graphische BenutzeroberflächeBrowserURLAuswahlverfahrenRouterWeb-SeiteInteraktives FernsehenVolumenvisualisierungCADComputeranimation
10:40
URLDatentypFlächentheorieSoftwareentwicklerGoogolGraphische BenutzeroberflächeLokales NetzApp <Programm>Protokoll <Datenverarbeitungssystem>RouterWeb-SeiteURLKartesische KoordinatenAuswahlverfahrenApp <Programm>Protokoll <Datenverarbeitungssystem>ProzessautomationLokales NetzVolumenvisualisierungGraphische BenutzeroberflächeSoftwareschwachstelleGoogolRPCSprachsyntheseVorzeichen <Mathematik>CADExploitSichtenkonzeptNotepad-ComputerComputeranimation
11:46
Graphische BenutzeroberflächeGoogolSoftwareschwachstelleSoftwareschwachstelleMereologieFuzzy-LogikDigitaltechnikXMLComputeranimationJSON
12:15
GoogolGoogle ChromeGraphische BenutzeroberflächeEinfache GenauigkeitSoftwareSoftwareschwachstelleProgrammbibliothekGoogolCodeFunktionalGraphische BenutzeroberflächeMereologieFuzzy-LogikDigitaltechnikSoftwareschwachstelleComputeranimation
13:02
SoftwareEinfache GenauigkeitSystemzusammenbruchTabelleSchlüsselverwaltungVirtuelle RealitätInhalt <Mathematik>SoftwareschwachstelleDigitaltechnikSchnittmengeProjektive EbeneCodeCASE <Informatik>Elektronische PublikationGraphische BenutzeroberflächeTabelleMathematikBefehl <Informatik>HalbleiterspeicherZeiger <Informatik>SummierbarkeitSoftwaretestSystemzusammenbruchProgrammbibliothekSchlüsselverwaltungInhalt <Mathematik>Fuzzy-LogikComputeranimationBesprechung/Interview
14:06
DatenbankAbschattungTabelleInhalt <Mathematik>TopologieBefehl <Informatik>StatistikAbschattungSoftwareTabelleVerzweigendes ProgrammGraphische BenutzeroberflächeCodeRechenschieberTypentheorieMultifunktionProgrammierumgebungArithmetisches MittelInhalt <Mathematik>DatenflussKonditionszahlFlächentheorieAggregatzustandDigitaltechnikExploitComputeranimation
15:20
Wurzel <Mathematik>Ganze ZahlTabelleVirtuelle RealitätZahlenbereichSchlüsselverwaltungKorrelationInhalt <Mathematik>p-BlockAbschattungTermURLSchnittmengeDatenfeldWort <Informatik>TabelleInhalt <Mathematik>Inverter <Schaltung>Mapping <Computergraphik>BinärcodeRechenschieberAutomatische IndexierungEindeutigkeitTypentheorieAbfrageArithmetisches MittelXML
15:54
p-BlockTopologieSelbstrepräsentationBinärdatenTabelleAbschattungDatenstrukturGanze ZahlSchlüsselverwaltungKnotenmengeTermDickeDateiformatZahlenbereichSoftwareschwachstelleHalbleiterspeicherBildschirmmaskeDatenstrukturEinfache GenauigkeitVarianzVersionsverwaltungTermBitGanze ZahlNichtlinearer OperatorCodeGarbentheorieInnerer PunktFigurierte ZahlDivergente ReiheFlächeninhaltSerielle SchnittstelleDateiformatComputeranimation
17:34
InformationROM <Informatik>SchlüsselverwaltungKnotenmengeFunktion <Mathematik>TopologieSystemzusammenbruchInhalt <Mathematik>Dreiecksfreier GraphFunktionalSoftwareschwachstelleHalbleiterspeicherMatchingSoftwareMAPTabelleExploitOrtsoperatorBinärcodeNichtlinearer OperatorAbfragePräkonditionierungDickeKomplex <Algebra>KreisflächeDivergente ReiheComputeranimation
19:02
Proxy ServerAbschattungInformationKontrollstrukturFunktion <Mathematik>TermLemma <Logik>SoftwareschwachstelleSchnittmengeHalbleiterspeicherInformationOpen SourceBinärcodeZeiger <Informatik>ParametersystemMailing-ListeXMLComputeranimation
19:44
Gebundener ZustandRandwertStrom <Mathematik>PunktDickeMailing-ListeCodeGanze ZahlBinärcodeResultanteFunktionalInhalt <Mathematik>CursorMinkowski-MetrikDatenfeldDickeLesen <Datenverarbeitung>RandwertAlgorithmusComputeranimation
20:28
SpeicherverwaltungPufferspeicherLesen <Datenverarbeitung>ROM <Informatik>LeckTabelleRohdatenZeiger <Informatik>FunktionalPufferüberlaufMailing-ListeHalbleiterspeicherCodePuffer <Netzplantechnik>GeradeXML
20:58
CodeTabelleAbschattungProxy ServerGanze ZahlHalbleiterspeicherROM <Informatik>Protokoll <Datenverarbeitungssystem>VektorraumFunktion <Mathematik>Virtuelle MaschineKeller <Informatik>InformationMessage-PassingPufferüberlaufComputersicherheitExogene VariableClientLeckPufferspeicherVersionsverwaltungNotepad-ComputerWeb logDatentypKonditionszahlCodeSpeicherabzugHalbleiterspeicherMessage-PassingLeckTabelleFunktionalPufferüberlaufFlächentheorieWeb logRPCSoftwareschwachstellePräkonditionierungAbfrageSchaltnetzTopologieKonstanteAbschattungGeradeSoftwaretestTelekommunikationInteraktives FernsehenTypentheorieAdressraumNavigierenVariableServerClientVersionsverwaltungResultanteSoftware EngineeringDatenstrukturProgrammbibliothekKeller <Informatik>Protokoll <Datenverarbeitungssystem>ComputeranimationBesprechung/Interview
23:39
StrebeGanze ZahlFunktionalMessage-PassingPufferüberlaufGeradeLokales MinimumCodeE-MailSoftwareschwachstelleTypentheorieProgrammfehlerInformationVariableHalbleiterspeicherPuffer <Netzplantechnik>Ganze ZahlBitGebundener ZustandDickeSchnittmengeResultanteProgrammierumgebungXML
24:31
Keller <Informatik>PufferspeicherDatentypExogene VariableCILGradientCodeGeradePufferüberlaufGanze ZahlLesen <Datenverarbeitung>Exogene VariableCompilerFunktionalMailing-ListeMessage-PassingResultanteOrdnung <Mathematik>Puffer <Netzplantechnik>DickeHalbleiterspeicherZahlenbereichServerClientKeller <Informatik>Vorzeichen <Mathematik>AuswahlverfahrenTypentheorieAutorisierungMakrobefehlSpeicherabzugXML
26:07
Funktion <Mathematik>BaumechanikCompilerVariablePufferspeicherKeller <Informatik>Operations ResearchGravitationsgesetzGüte der AnpassungPufferüberlaufProgrammOrtsoperatorPuffer <Netzplantechnik>Nichtlinearer OperatorFunktionalKeller <Informatik>VariableSpeicherverwaltungHalbleiterspeicherCodePolygonnetzCodierungDatenflussMereologieCookie <Internet>Computeranimation
26:48
GoogolExploitPufferüberlaufHalbleiterspeicherKontrollstrukturSpeicherverwaltungDickeSoftwareschwachstellePuffer <Netzplantechnik>Delisches ProblemMereologieFlächeninhaltLesen <Datenverarbeitung>TermersetzungssystemAggregatzustandGruppenoperationÜberlagerung <Mathematik>VariableSpeicherverwaltungHalbleiterspeicherSchlüsselverwaltungFunktionalEinfügungsdämpfungSpeicher <Informatik>TypentheorieSechseckGraphfärbungSchreiben <Datenverarbeitung>PufferüberlaufGarbentheorieComputeranimation
28:22
Funktion <Mathematik>Zeiger <Informatik>GoogolDatenstrukturDatenstrukturToken-RingPunktFunktionalZeiger <Informatik>SpeicherverwaltungTopologiePolarkoordinatenOffene MengeDefaultAdressraumEndliche ModelltheorieVariableTabelleAttributierte GrammatikComputeranimation
29:36
SpywareHydrostatikGoogolROM <Informatik>Operations ResearchPufferüberlaufOrdnung <Mathematik>SystemzusammenbruchTabelleHalbleiterspeicherNichtlinearer OperatorMathematische LogikFunktionalSpeicherverwaltungEinfügungsdämpfungCodeOffene MengePolarkoordinatenVariableKonditionszahlZeiger <Informatik>SpywareMAPComputeranimation
30:40
KontrollstrukturWurm <Informatik>SpeicherverwaltungGoogolTropfenTabelleDigital Rights ManagementAlgorithmusOperations ResearchGruppoidMathematische LogikFeasibility-StudieToken-RingDatenstrukturForcingHalbleiterspeicherWurm <Informatik>Endliche ModelltheorieCodeTabelleMultiplikationNabel <Mathematik>Nichtlinearer OperatorMathematikTropfenFunktionalComputeranimation
31:51
GoogolLeckROM <Informatik>AdressraumLeckAuswahlverfahrenSpeicherverwaltungAdressraumInformationNabel <Mathematik>Proxy ServerGarbentheorieCachingMailing-ListeGamecontrollerHalbleiterspeicherComputeranimation
32:42
GoogolRechenwerkSpeicherverwaltungStatistikBildschirmmaskeVakuumPrimzahlzwillingeEndliche ModelltheorieRechter WinkelAdressraumToken-RingDatenstrukturTouchscreenGeradeTabelleNabel <Mathematik>AuswahlverfahrenSpeicherverwaltungProgrammVariableCachingExploitSymboltabelleRechenwerkOffene MengeVolumenvisualisierungStichprobenumfangAggregatzustandComputeranimation
33:50
GoogolCodeCodep-BlockOpen SourceTouchscreenCodierungBildgebendes VerfahrenFunktionalNavigierenCachingResultanteURLNabel <Mathematik>E-Funktion
34:45
URLGoogolRPCTypentheorieInteraktives FernsehenSchnitt <Mathematik>LeckLokales NetzProzess <Informatik>Kartesische KoordinatenProtokoll <Datenverarbeitungssystem>E-FunktionLastGamecontrollerVektorraumGoogolApp <Programm>BenutzerbeteiligungMultiplikationsoperatorComputeranimationDiagramm
35:37
GoogolFahne <Mathematik>AbschattungOpen SourceTabelleDefaultGraphische BenutzeroberflächeGraphische BenutzeroberflächeTabelleKartesische KoordinatenSoftwareschwachstelleSoftwareOpen SourceFahne <Mathematik>RouterLokales NetzAbschattungDefaultURLGoogolDifferenz <Mathematik>Güte der AnpassungTotal <Mathematik>StapeldateiSoftwarewartungVerkehrsinformationComputeranimation
37:07
ComputersicherheitWeb-SeiteFacebookIntelProdukt <Mathematik>CodeROM <Informatik>Ein-AusgabeSupremum <Mathematik>EindringerkennungMechanismus-Design-TheorieProgrammbibliothekSoftwaretestProgrammbibliothekComputersicherheitTopologieSoftwareschwachstelleUmwandlungsenthalpieEinsSoftwaretestFacebookDifferentePhysikalisches SystemProgrammMechanismus-Design-TheorieMessage-PassingMultiplikationsoperatorComputeranimationXML
Transkript: Englisch(automatisch erzeugt)
00:00
These gentlemen have come all the way from China to talk to you guys about breaking Google Home and exploiting it with SQLite. Let's give them a gigantic round of applause. Have a great time. Smile, I'm gonna take pictures. Have fun. Thank you. Hello everyone. Thank
00:22
you for coming. We are very excited to share our search at DevCon 27. The title of our talk today is Breaking Google Home, Exploit it with Soil and Imagine and Vulnerability. First, let me introduce my teammates and myself. We are senior security research at
00:45
Tensorplay team and this is my teammate Chen Yunxiang. Now he is focusing on brother security and IoT security and this is Niu Xiam. He is focusing on mobile security and IoT security and my name is Wu Hee. I'm a bug hunter and a ping pong runner. I also
01:04
speak of uh DevCon and POC. Next, I will introduce the Tensorplay team. Our team was funded by Tensor security platform department at 2017 and now we are focusing on the
01:23
security research in areas such as AI, IoT devices, mobile devices, cloud and blockchain. In the past uh years, we have reported more than 200 security vulnerabilities to many companies such as Google, Apple, Amazon, Microsoft and so on. Last year, we
01:45
shared how to break Amazon echo at the DevCon 26 so come again, so we come again this year. And you can connect us at blade.tenson.com. Next, let's take a brief look at the
02:07
outline. First, we will introduce the attack surface of Google Home smart speaker. Then, we will share the details on how to find and explore satellite and the curve. Finally, we will
02:21
summarize our research. Okay, let's start with the first part. Smart speaker are the most popular smart home devices of the past few years. Amazon, Google and some Chinese companies are the main player in this field. In the fourth quarter of 2018, Amazon and
02:49
Google, after we shared uh after we shared how to break Amazon echo and Xiaomi AI speaker in DevCon 26, we began to study the security of Google Home smart speaker. The Google Home
03:06
family include 4 devices, all of which have similar hardware. We choose the best selling Google Home Mini as the main tester devices. The first part is about hardware
03:20
analysis. We found that the Google Home Mini used the one way CPU and the TOSI bus flash chip but we did not did not find any debugging and flashing interface. So, we can only choose to extract the firmware directly from the flash chip. Similar to the Amazon
03:43
echo, we first use a heat gun to solder the chip from the board. By aligning the dead sheet of the chip, we find the test circuit of BGA67 chip. And the difference is that
04:01
the pins of BGA67 chip are very thin. So, we have not found the adapter that can connect the test circuit to the programmer. So, we designed a new adapter. The main function is to export the pins of the test circuit to a notch pitch. The pins are
04:23
so that we can easily connect the chip to the programmer. And this is the finished product that we finally produce it. We connect it to the RT908H programmer which is a universal programmer that supports reading and writing most of flash chips. Finally, we
04:49
got the RAM image data in Google Home's uh flash chip. We also needed to pass the OOB data and the ECC trick piece according to the specification in the dead sheet. And
05:02
the extract the company system firmware. By aligning the system first, you can know that Google Home is using a net Chromium OS. The main, the main function are implemented by the Chromium OS, by the Chromium browser. And the update speed will
05:24
be a-a little slower than the Chromium browser. Okay, my part ends here. And, and my teammate Ni Yu Xiang will continue to share the next part. Uh, thanks for your
05:47
introductions. Next, uh, let's introduce the security overviews of Google Home. Uh, firstly, let's look at the security overviews of Google Home. On the OTI mechanisms, the firmware-related resource of Google Home is open to public. This resource include
06:05
bootloader kernels and related binaries programs and some even has samples. Google Home uses the HTTP request to download the firmware. We can also simulate the request for device update. The latest OTI package can be obtained by the curse command in
06:24
the pictures, uh, below. So, we can easy to gather firmware and then try to analyze the firmware. Um, through the analyze of firmware and related resource, we believe that the
06:41
security mechanism adopt by Google Home is worth learning. About LANs, enabling security boot on IoT devices in, is a good example. The bootloader, boot imager, system imager is protected by the security mechanism throughout the boot process. The details as follows. The bootloader and boot imager use the sense nectures methods and, uh,
07:04
in place with SHAs and ISAs nectures. The bootloader seen that there is no logic to provide unlocking. Uh, in addictions, Google Home also pro, uh, profound, uh, integrities, uh, veri, verifications on system image. Uh, let's look at the, uh, main
07:26
programs in the firmware. The firmware has, uh, memory directories as shown in these pictures. That's contain the main program called cut shell. The program just like Chrome, so it's program is protected by sandbox. On Chrome OS, the sandbox
07:44
mechanisms mainly includes that ready, uh, UNN space and sitcom BPF. In addictions, the system also enable ASLRs and the cut shells also add annex and, uh, uh, uh, uh, stack galleries. Next, we will introduce the attack surface on Google Homes. Combined with
08:05
existing security research and our attack things, Google Homes, uh, attack surface include the following, uh, four aspects. Go, Google Home has multiple, multiple parts, uh, port opens. One of the port is the A0A0A. It's an HTTP service. Uh, we
08:22
can control some basic operations of Google Homes through these ports in the land. There is also a port of A0009. The port is the target of our attacks using the CAD protocol. We will destroy in the following sections. And the wireless protocol is also an attack surface. Google Home used a mobile chip. Some idea about mobile Wi-Fi and VRE firmware
08:45
attack can be tried. It is also possible to try to, uh, find, uh, vulnerabilities of the boot loaders and let it load malicious firmware. Finally, we can try to find another, uh, other, uh, hardware interface. In these sections, we will show you how to extend the
09:07
attack surface of Google Homes. First, let's introduce the basic knowledge about the CAD protocol. Uh, Google allows developers to develop CAD APIs and publish it to every store. In general, the CAD APIs include senders and receivers. Sender devices may be
09:24
mobile devices or PC running on Chrome. Uh, receiver is, uh, Google's IoT devices such as Google Home. The entire architecture is as follows. The user assess the sender application URL and the sender application use the CAD protocol to find the
09:41
receivers in the LAN. When the receiver, uh, is discarded, the sender application will communicate directly with the URLs, uh, with the, uh, reader applications on the receivers with the CAD protocol. Uh, in detail, the Google Homes will prove the URL of each
10:01
receiver application according to the CAD IP ID and accept the receiver application through the Chrome renders. After our attempt, we found that, uh, CAD protocol will have the following, uh, security, uh, security risk including the CAD IP can be any web page. The CAD IP is the IP store may be malicious. Uh, and, uh, senders can select the
10:25
directly triggers, uh, CAD protocol which may even require no user interaction. Based on this, uh, this security risk, we can govern an attack on our Chrome, uh, Google Home into an attack on our browser. Let's take a look at some special states. The attackers is
10:47
registered as the CAD developers. CAD application can be developed and distributed. When you publish an application, you need to speak safe, uh, CAD receiver URL. However, Google does not audio link, uh, CAD IPPs. Then we can specific it as a web page in any
11:03
context. Remotely trigger the Google Home to accept any web page. If, if the attackers and Google Homes are in the, in the land, the attackers can also send a CAD protocol such as the launch IPPs request. This request view directly triggers Google Home accept to the CAD receiver URL. To make matters worse, if the routers in the victims
11:25
house, homes, uh, turn on the UPnP port forwarding, the attacker can also complete a remote sign attacks on the internet. The attackers modify the CAD receiver URL web page to a malicious, uh, page. Land Google Homes may assist in vendors after visiting the
11:44
page. So, now we only need to, uh, Chrome assist vulnerability to exploit Google Homes. Now, Wenjian Chen will introduce, uh, Macros and other vulnerabilities. Um, okay, thank you
12:06
for, uh, the introduction. Now, I will continue with, uh, part 3. Um, fuzzing and, uh, manual auditing, circuit lights and lab curve. Uh, first, why do I audited these two libraries? Um, because third part libraries are always sweet. They have less code and, uh,
12:25
focused functions. And almost every device has them installed. And the most important thing is Google Home or Google Chrome are using them too. Uh, before introducing the code audit part, I would like to mention some previous researches. Uh, first, Michael
12:44
Zavitsky's fuzzing has significantly improved the, uh, circuit lights quality. And then there's a talk on black hat in 2017, which also explains the idea of exploiting circuit lights. Uh, after that, there doesn't seem to be a lot of news about the
13:02
vulnerabilities of circuit lights, but we have found some. In the next part, we will introduce the code auditing and the exploiting of Magellan, which is a set of vulnerabilities in circuit lights. And Diaz, which is a set of vulnerabilities, vulnerabilities in lab curve. The Chromium project come with a father for circuit
13:25
lights. Uh, we have made some simple changes to it, uh, such as adding some text-based fuzz. When we look back, we found that there are, uh, was a lot of crash files generated. However, these test cases can only trigger empty pointer dereferencing. One of
13:43
these test crashes is caused by duplicate primary keys. And when I was bugging, I typed the first three create table statements to see what was going on in memory. However, I surprised to find that the dot tables command shows six tables. The question is, uh, what's
14:02
those content secdr segments stand for? The circuit light manual shows that the tables are called shadow tables. There are five types of shadow tables. Content secdr segments are for FTS 3 or 4. And state and doc size are FTS 4 only. However, because of those
14:25
tables are treated like standard tables, you can create corresponding state and doc size table even you are operating on an FTS 3 table. Uh, you can create state and doc size by simple, uh, by simple create a table statement because the circuit light itself is doing
14:42
this too. And FTS 3 and 4 is sharing some code which means state and doc size might change the code flow in some conditions. For example, one of our exploits are simulating an FTS 4 table on FTS 3 environment. Uh, this is useful because some software
15:02
like Chromium use only FTS 3 and explicitly disabled FTS 4. This would extend the attack surface by entering some code branch that should never be entered. The shadow table is used as a container to store the contents of the full text search metadata. What is
15:22
shown on this slide is the definition and meaning of each shadow table. We can see that almost every shadow table has a field of type blob. That's because to support full text queries, FTS maintains an inverted index that maps from each unique term or word that appears in the data set to the loc- locations in which it appears within the table
15:44
contents. It is complicated but all we know is that compared to other fields, those blobs may have some important influence on FTS queries. In Circulite, the raw binary data is typically represented in the form of X, single quotation mark and hexadecimal
16:03
numbers. However, the blobs here are binary data to represent the entire B-tree. Since it represents such a complex structure, is it possible to create a memory corruption vulnerability by destroying the data of the structure? Let's read about the documents of the serialized data structure first. You can check the Circulite manual to
16:26
easily get the definition. I will show you a simplified version so you can understand what I'm modifying when I'm trying to exploit them. Basically, I'm modifying the bytes with the different functional sections to mislead the code flow. The first segment B-tree
16:40
leaves nodes. The first term stored on each node, which is term one in the figure above, is the stored verbatim. Each subsequent term is prefix compressed with respect to its predecessor. In the real nodes, non-leaf nodes have different structure. And then the
17:00
doclist format. A doclist consists of an array of 64 bit signed integers, serialized using the FTS var int format. Each doclist entry is made up of a series of two or more integers as follows. One the docid value and two the zero or more term offset list. In
17:21
general, those blobs are just serialized B-tree data. When the Circulite wants to perform operations on those tables, it will simply deserialize or parse those blobs and get a complete B-tree. Then I have found some problems. The problems are mainly treated to merge and match because they are deeply related to the B-tree. Two of them merge the node of
17:45
the tree and other is to traverse the nodes of the tree to try to find the match of the content. Also, the last one is the crash I have mentioned before. It was that brought this series of problems into my attention. And software must enable FTS3 support and
18:01
support external circle query to trigger these problems. Okay, the first one and two oh three four six, which is also the main vulnerability we use later to exploit Google Home. It requires a lot of complex preconditions, that is we have to carefully construct a lot of tables and content. But once the preconditions are met,
18:23
vulnerability explosion will be very simple and stable. The vulnerability is located in the function FTS3 append to node. It can be triggered with a special semantic, the merge equals one two, which means the level to be merged. As you can see, this
18:41
function will try to append a node to another. The node is stored in the blob, so this function and other function will first parse in the B-tree and then get the start position and the length of binary data of the node that will be processed. And last, perform the memory copy operation to copy them into a new blob that represents a new
19:01
tree. Okay, let's go to this caller function, uh, turnkey node. It will get the binary offset and learns from the blob data that will describe the node being processed. Then the node information is returned in our reader object, passed to the vulnerable, uh, uh, FTS3 append to node. To control the memory copy in append to node, we need to
19:25
control a ADOC list and a NDOC list, which is returned from node reader next. The ADOC list is the source of the char pointer to the blob data and NDOC list is a node size, which are second and third parameter of memory copy, respectively. To control them
19:43
is not a difficult thing. Let's read the code, then you will know why I'm saying that it's easy. To save the space of storing an integer, CircleLite uses a variant integer algorithm. You can just consider fs get variant 32 as a function to convert a bunch of
20:01
bytes into an integer. It will store the result in N suffix, then it move the current cursor by adding the content of bytes and re-read it to eye off. The data for a node is stored as a length following by corresponding data with exactly size of length. Normally they should appear in pairs, but we can modify the blob to make the end of the
20:23
blob boundary has only the length field but no data field. Okay, let's go to the append to node. Since, uh, in the last step ADOC list and NDOC list is controlled, we can now overflow the buffer of P node A in line 3 1 0. Or we can copy some raw memory
20:42
data to it as long as it does not exceed the aligned value. Then we can query the new table to get the leaked raw memory. By setting up adjacent tables, we can overflow the function pointers of the table very uh accurately to exploit a code execution. And here's
21:00
another one, uh 506 in functions to get into real node and the precondition of this one is rather simpler. All you need to do is to modify the shadow table, set a node in secdr to non root node. You can change the blob data to change the code flow. Query the modified table by keyword match, then the code will scan every node inside the B tree.
21:23
Then the code will trigger memory corruption because it has many constrained conditions. It was considered to be very hard to exploit. Um, but this one is, is, is possible anyway. Uh, you can check the wonderful write up by a Korean researcher named Anki Chen. And last, uh 2 0 0 5 0 5. This one is very like to a combination of the
21:44
previous two. The vulnerable function is secdr next. You can modify the shadow table and mislead the code flow. All these three vulnerabilities can be modified to leak raw memories. So we can also use this to leak address of for example functions, structures,
22:02
global variables, constant variables to bypass the ASLR. And here's another one, lab core. Um, our target, our target is a remote code execution but the lab core has already been used by a lot of users and their code iterates very quickly too. To find a
22:22
vulnerable function, here are some guidelines for finding problems by reading the code quickly. The first, find the big functions. Most functions with a lot of lines is not recommended in software engineering and functions that are too long should be refactored into shorter function fragments. Usually such a large function is difficult to test and
22:43
there will be a lot of attack surface. And most of the functions enabled in lab core is related to remote interactions and communicates with the remote server more than once. After carefully sifting through the protocols, we confirm that NTLM over HTTP was what we wanted to test. And here are those problems we have found in lab core. We named them as
23:07
DS, uh, name of another famous navigator. The first one, um, 890 is a vulnerability in NTLM type 2 message. It can leak at most 16 4 kilobytes client memory per request to
23:21
attacker. The result is very light to the heart bleed but is the client version. And the second one, 3822 is a vulnerability in type 3 message. It will result in a stuck buffer overflow. Lab core also wrote this in his blog and saw this very bad security issue. Ok, let me show you how this happened. The first one, the vulnerable
23:45
function is in decoder type 2 target. It reads 32 bit integer from the type 2 message header. Then we know we can set target info offset with a larger value. And target info length to a crafted value which if you add them together, an integer overflow will
24:02
happen. The overflow result is very small and will pass the check in line 185. And next, memory copy will copy data out of bounds. For example, if we use the value above, it will actually copies data from the front of variable buffer in 32 bit environment. And then
24:22
the data will be sent to the attacker in type 3 message, leaking maximum, uh, 64 kilobytes data per request to the attacker. And let's go to 3822. This vulnerability is located in a big function named core auth create an NTLM type 3 message. In the beginning, this
24:42
function declares a lot of variable on stack memory. The NTLM buffer is a big buffer which has around, uh, uh, 4 kilobytes memory. Then the function tries to read the anti-response length from the type 2 response which is sent from the server. Attack could return a value bigger than the buffer size to client. And next, in line 779, this
25:07
check should check if the size of the data is bigger than NTLM buffs remaining size. But the in-explete sign unsigned cast prevents the check from operating correctly. This check compares two unsigned variable and a macro NTLM buff size which simply defines a
25:25
number 1024. But this value is a signed integer in the view of compiler. When unsigned and, and signed are compared in the same place, some of them must be casted in order to compare correctly. And this is a problem. The compiler prefers to convert signed to
25:45
unsigned numbers. So if we have anti-response length greater than the NTLM buff size, the result will be a large unsigned number. And it is of course bigger than the remaining size. We'll pass a check. In line 781, because anti-response length is bigger than the
26:02
remaining size of NTLM buff, hence here will be a stack buffer overflow. When the code triggers a stack buffer overflow, the overflow variant is in the middle of a lot of stack variables. Although the program may have stack cookies, an attacker could choose not to
26:20
overflow that mesh bytes, but instead override stack variants and control the flow of the code. I am marked the position where the, where it triggers the buffer overflow. You can see in this big function, there are, there are almost 18 lines after it. And many of them are operating heap or stack memory and the operating is based on the value of those stack
26:42
variables. That's the reason why I say big function is never a good coding practice. Okay, my part is done. And uh, Li-Xiang will go ahead to introduce how to exploit. Uh, thank you
27:04
for my partner's introductions. Now, uh, let's review the following, uh, vulnerabilities. The keys to the vulnerability trigger is how to use the insert state to control the variables used by our memory, memory copy function in group PN, uh, P node A, P node
27:22
N, and A double X, N double X. The insert data is as follow. The insert data is as first, the entire data is stored in the buffer of P node A. Uh, we can control the size of the P node A buffers by modifying the length of the insert state. Uh, in heap functions, we
27:42
are able to allow P node A to the appreciate areas to cover the, uh, target memory. In this state, uh, the all injury callers in that, indicate that the size of P node N and P, uh, N double X, which is, we are in type. N double X is used to control the length to be
28:07
overflow. Uh, P node N, which is the offsets of the right, overwriting memory areas. The green part is the A, A double X status, which can be used for our read or rewrite.
28:24
The next sessions, uh, we will, we will introduce the ideas of using these vulnerabilities. We expect, expect to find, uh, uh, function pointers that can be used on the heap. When creating our FTS3 tables, the tokenizer is created by default. And the
28:43
tokenizer default is simple tokenizers. Uh, as shown in, uh, following pictures, simple tokenizer is a structures on the heap where is, uh, members base points to the SQL trees tokenizer structures. The members P models or the SQL trees tokenizer
29:06
structure points to the tokenizer models. The tokenizer models contain the same interesting function, uh, callback function, such as the X create, X opens. Among that, when inserting the FTS3 tables, the X open callback functions will be
29:24
triggers. Uh, if a function address of X opens can be modified to the, uh, attribute, expertise address, the PCs can be hijacked. Uh, how to use the, uh, variables functions, pointers for PC hijacking? Uh, here's two conditions need to be
29:46
met. The first, after his overflow is necessary to be able to operate the FTS3 table. In order to be complete before the memory is released, otherwise the crash will be
30:01
interrupt. By analyzing the logical, uh, memory copy to freeze, we find an interesting function, uh, which perform, uh, uh, SQL update operation before re-releasing the memory, as shown in the, the blue text code. Finally, we use the SQL triggers to
30:23
perform the FTS3 table insert operation before the SQL update operations and free memories. Since, uh, triggering the X open callback functions so that the PCs can be hijacked. The next step is to make a memory, uh, layout. The SQL logical of the
30:47
castle shell use TMLock, a feasible memory layout idea as follows. The first, by creating a multiple, first, uh, FTS3 tables, we will create a multi, multiple simple
31:01
tokenizer structures. Drop the previous, uh, created FTS3 tables at a appreciated time, uh, the simple tokenizer structures will be free. The, uh, resiling payloads of the same size as simple tokenizers, it, it has the high, uh, prob, probabilities
31:22
that payloads will be allowed to the previous release simple tokenizer structures. So, our payloads has a greater chance of writing the simple tokenizer structures of existing FTS3 tables. With, uh, SQL triggers that perform the operations of FTS3 tables
31:41
before the free, that is a chance that the tokenizer model callback functions, uh, will be triggers to hijack the PC. Uh, when we have the ability to hijack the PCs and control the R0 registers, we only need to be able to list information and bypass ASLRs.
32:06
The previous sections, uh, uh, also introduced, uh, we can try to, uh, adjust the, the underlist P node A and list memory after heap. We need to disclose the following 2 types of address. Leaking the address of cache shells based on, uh, based on this address and
32:26
offsets, calculate the required ROP guidance. Uh, leading the address of the last heap, according to this address and offsets, the probabilities of calculating the address of the heap's spread. The latest is the heap's spread and ROPs. After these 3 steps, we can
32:50
ask this in Google Home's renders. Uh, cache shell is, uh, large binary program that contains many of the, uh, available ROP guidance. So, the ROP guidance used cache shell is
33:03
more stable and convenient. In the, uh, in the pictures on the right, the realized, uh, marks, the red lines mark the heap's spread units which face tokenizer models and ROP guidance. The X create, X open address in the face tokenizer model structures will be aside
33:26
the state pivot address. The blue lines marks our face symbol structure, uh, tokenizer structures. When the FTS3 tables operate can be triggered. X create will be get a
33:41
magicians X open through the structures of sample tokenizers and then I see. Uh, above, uh, above is the screen source of our RC in cache shells. The red blocks on the left show that the register we can control. That, that they are R0, uh, 11. The function of
34:04
JET is read from the R11 and finally is go to BLX. Then, as a result, we have been able to hijack the PC. The image on the right, uh, show, show the result of our shell codes. We execute, uh, Java 3 codes for fetch URLs and, uh, navigators ABP name in the
34:28
exp.html code. Normally, uh, negoti- uh, navigators ABP name is read only and, uh, and is next skip but our shell codes change the ABP name to AA. Uh, let's look at some
34:48
actual attack sense. There are 3 types of attack vectors that attack Google Homes remotely. The first, the attacker is located in the LAN. The attacker send the launch
35:01
ABP ID 1 command through, uh, a cut protocol and Google Homes will prove the leak doc HTMLs on the application, application stop, AB stops according to the ABP ID and control it. At this time, the leak days can be obtained by the attackers. The second, the
35:24
attacker send the launch ABP ID 2 command, uh, Google Homes loads the exp.html, so that's the RCE happen. The entire process does not require URL interaction. In the other 2 sense, you don't need to be on the same, uh, on the same LANs to start the attacks. The
35:46
attacker inducts the victims to assess the URLs of the same application and we can scan the networks on the routers that, uh, if the router have the UPnP forwarding, try, uh, we can
36:01
try to launch remote, remote attacks on the internet. Conclusion. Here the, uh, here is the timelines of the maintenance. We have report LANs in, uh, November and is quickly fixed by SQLite and, uh, Chrome use. In the December, Google's decide to get us a
36:24
total 10,000 rewards for the batch of vulnerabilities. And they have, uh, uh, an, an LAN have, uh, in, enhancements, there is the defense in diff flag. This allowing modifying shadow tables from untrusted source. For backwards compatibility, is default
36:46
off in the SQLite. So, if you are using SQLite with FTS, you may want to enable this one up to prevent the attacker from the modifying your shadow table. But, uh, the good news is, is default on in, in Chrome from commit in the last November. Here is the, uh,
37:10
timelines of Dias. These quickly fixed and released by lab crews in 2 week. Uh, we also, uh, uh, also, we have, uh, not if the sensor to urge vendors to disable the
37:27
vulnerabilities, vulnerable FTS trees of that SQL before the patch come out. If they don't use these features. And, uh, we have not notified the security teams of Apple's
37:41
interest, Facebook's and Microsoft about how to fix the program and how to mitigate the phrase in the center of their products. Uh, the guidelines, the securities otherwise, the ones enhance your systems with the newest available defense in different mechanism in a time.
38:04
To keep your, uh, the, the third pass libraries up to date. Please improve the qualities of security auditing, auditing and testing of the third pass libraries. For, first introduce security specifications into the developments and testings. Thank you.