1
00:00:00,782 --> 00:00:05,786
[Translated by Jouko Voutilainen (KYBS2001 course assignment at JYU.FI)]

2
00:00:18,231 --> 00:00:29,299
Vasemmallani on Omer Gull, ja hän puhuu meille aiheesta "SELECT code_execution FROM * USING SQLite".

3
00:00:29,299 --> 00:00:33,381
Omer, Omer Gull, sinun esityksesi, sinun lavasi, pidä hauskaa!

4
00:00:33,381 --> 00:00:34,728
Kiitos. Kiitos.

5
00:00:34,728 --> 00:00:39,233
[Yleisö taputtaa]

6
00:00:39,259 --> 00:00:40,459
Hei kaikille.

7
00:00:40,459 --> 00:00:46,329
Tervetuloa esitykseeni "SELECT code_execution FROM * USING SQLite",

8
00:00:46,329 --> 00:00:51,849
jossa saavutamme koodin suorittamisen (code execution) haavoittuvaisia SQLite-tietokantoja käyttäen.

9
00:00:52,113 --> 00:00:55,850
Nimeni on Omer Gull. Olen haavoittuvuuksien tutkija Tel Avivista.

10
00:00:55,850 --> 00:01:00,905
Olen työskennellyt Check Point Researchissa viimeiset kolme vuotta

11
00:01:00,905 --> 00:01:05,346
ja olen äskettäin siirtynyt uuteen startupiin nimeltä Hunters.AI.

12
00:01:05,738 --> 00:01:07,554
Agendamme tänään:

13
00:01:07,554 --> 00:01:12,332
Aloitamme pienellä motivaatiolla ja taustatarinan kertomisella tästä tutkimuksesta.

14
00:01:12,332 --> 00:01:21,100
Sen jälkeen meillä on lyhyt SQLite-johdanto ja tutkimme haitallisten tietokantojen hyökkäyspintaa.

15
00:01:21,485 --> 00:01:28,559
Käsittelemme myös aiempaa työtä SQLite-hyödyntämisessä ja mietimme,

16
00:01:28,559 --> 00:01:33,948
miten käyttää muistin korruptiohäiriöitä pelkästään SQL:n avulla.

17
00:01:33,948 --> 00:01:41,007
Sitten esittelemme oman innovatiivisen tekniikkamme nimeltä "Query Oriented Programming" tai QOP,

18
00:01:41,007 --> 00:01:44,240
ja demonstroimme sitä muutamassa esimerkissä.

19
00:01:44,320 --> 00:01:50,513
Käärimme asiat yhteen tulevaisuuden mahdollisuuksien ja johtopäätösten kanssa.

20
00:01:50,598 --> 00:01:55,415
Motivaatio tälle tutkimukselle on melko ilmeinen.

21
00:01:55,415 --> 00:02:00,346
SQLite on yksi eniten käytetyistä ohjelmistoista.

22
00:02:00,346 --> 00:02:04,527
Olipa kyse PHP 5:stä, PHP 7:stä, Androidista, iOS:stä,

23
00:02:04,527 --> 00:02:08,009
Mac OS:stä, se on nyt sisäänrakennettu Windows 10:een.

24
00:02:08,009 --> 00:02:10,947
Sitä on Firefoxissa ja Chromessa.

25
00:02:11,517 --> 00:02:13,704
Tämä luettelo voisi jatkua loputtomiin.

26
00:02:13,704 --> 00:02:16,923
Kuitenkin SQLite-tietokannan kyselyä pidetään

27
00:02:16,923 --> 00:02:21,044
turvallisena. Toivottavasti tämän puheen lopussa tajuat,

28
00:02:21,044 --> 00:02:23,855
miksi tämä ei välttämättä ole totta.

29
00:02:24,410 --> 00:02:27,917
Kaikki alkoi salasanavarkaista,

30
00:02:27,917 --> 00:02:35,276
mikä on melko outoa, ja niitä on paljon, paljon vapaana, mutta tarina on yleensä sama.

31
00:02:35,567 --> 00:02:38,601
Ensinnäkin tietokone saa tartunnan.

32
00:02:39,311 --> 00:02:42,500
Sitten haittaohjelma kerää tallennettuja käyttäjätunnuksia,

33
00:02:42,500 --> 00:02:45,453
sillä niitä on tallennettuna eri asiakasohjelmistoihin.

34
00:02:45,642 --> 00:02:50,782
Jotkut näistä asiakasohjelmista tallentavat salaisuutesi SQLite-tietokantoihin.

35
00:02:51,434 --> 00:02:59,934
Haittaohjelma lähettää SQLite-tietokantoja C2-palvelimelle, jossa salaisuudet
poimitaan

36
00:02:59,934 --> 00:03:02,295
ja tallennetaan yhteiseen tietokantaan

37
00:03:02,295 --> 00:03:03,875
muun saaliin kanssa.

38
00:03:04,596 --> 00:03:12,283
Eräänä päivänä kollegani Omri ja minä tutkimme erittäin tunnetun salasanavarkaan vuodattamia lähdetiedostoja.

39
00:03:12,613 --> 00:03:20,123
Ajattelimme: "Nämä kaverit vain keräävät tietokantojamme ja parsivat ne omaan back-endiinsä.

40
00:03:20,333 --> 00:03:27,446
Voimmeko todella hyödyntää luotettamattoman tietokannan latausta ja kyselyä?"

41
00:03:27,446 --> 00:03:31,215
Ja jos voimme, sillä voisi olla paljon suuremmat vaikutukset,

42
00:03:31,215 --> 00:03:40,653
koska SQLiteä käytetään lukemattomissa skenaarioissa. Ja niin alkoi tähänastisen elämäni pisin CTF-haaste.

43
00:03:42,093 --> 00:03:50,088
SQLite. Toisin kuin useimmat SQL-tietokannat, SQLite:llä ei ole asiakas-palvelinarkkitehtuuria.

44
00:03:50,088 --> 00:03:55,527
Sen sijaan se lukee ja kirjoittaa tiedostoja suoraan tiedostojärjestelmään.

45
00:03:55,527 --> 00:04:02,258
Joten sinulla on yksi täydellinen tietokanta, jossa on useita taulukoita, indeksejä, laukaisimia ja näkymiä,

46
00:04:02,258 --> 00:04:11,794
ja kaikki sisältyvät yhteen tiedostoon. Tutkitaan siis hyökkäyspintaa, jonka potentiaalisesti haitallinen SQLite-tietokanta antaa.

47
00:04:12,144 --> 00:04:17,074
Tämä on palanen koodia erittäin tunnetusta salasanavarkaasta,

48
00:04:17,074 --> 00:04:23,388
ja meillä on kaksi tärkeintä kiinnostuksen kohdetta: Ensinnäkin meillä on sqlite3_open,

49
00:04:23,388 --> 00:04:26,942
jossa potentiaalisesti haitallisen tietokanta ladataan,

50
00:04:26,942 --> 00:04:29,492
ja jotain parsimista tapahtuu.

51
00:04:29,492 --> 00:04:34,362
Ja ilmeisesti meillä on itse kysely. SELECT-lauseke.

52
00:04:34,362 --> 00:04:37,427
Huomaa kuitenkin, että meillä ei ole hallintaa siitä lausekkeesta.

53
00:04:37,427 --> 00:04:39,780
Se on kovakoodattu kohteeseemme.

54
00:04:39,780 --> 00:04:42,908
Se yrittää poimia salaisuudet tietokannastamme.

55
00:04:42,908 --> 00:04:48,990
Mutta me hallitsemme sisältöä, joten meillä voi olla vaikutusta siihen, mitä siellä tapahtuu.

56
00:04:49,864 --> 00:04:53,278
Ensimmäinen asia on sqlite3_open,

57
00:04:53,278 --> 00:04:56,399
joka on vain joukko asetus- ja kokoonpanokoodia.

58
00:04:56,399 --> 00:05:01,692
Seuraavaksi siirrymme suoraviivaiseen otsikkotiedoston parsimiseen,

59
00:05:01,692 --> 00:05:05,425
otsikkotiedosto itse ei ole kovin pitkä, vain 100 tavua.

60
00:05:05,425 --> 00:05:09,445
Kolmanneksi, se on jo fuzzattu kuoliaaksi AFL:llä.

61
00:05:09,445 --> 00:05:13,776
Joten se ei ehkä ole kovin lupaava polku jatkaa.

62
00:05:14,476 --> 00:05:18,939
Mutta Sqlite3_query saattaa olla hieman mielenkiintoisempi,

63
00:05:18,939 --> 00:05:27,178
koska SQLite:n tekijän mukaan "SELECT-lauseke on SQL-kielen monimutkaisin käsky".

64
00:05:28,138 --> 00:05:33,788
Voit tietää, että taustalla SQLite on virtuaalikone.

65
00:05:33,788 --> 00:05:39,751
Joten jokainen kysely on ensin käännettävä joksikin tavukoodin muotoon.

66
00:05:39,751 --> 00:05:42,968
Tätä kutsutaan myös valmisteluvaiheeksi.

67
00:05:43,278 --> 00:05:46,851
Joten sqlite3_prepare kulkee ja laajentaa tuon kyselyn.

68
00:05:46,851 --> 00:05:50,174
Esimerkiksi joka kerta, kun valitset asteriskin,

69
00:05:50,174 --> 00:05:53,683
se kirjoittaa tämän asteriskin kaikkien sarakkeiden nimiksi.

70
00:05:56,003 --> 00:05:59,758
Joten sqlite3LocateTable() varmistaa,

71
00:05:59,758 --> 00:06:06,454
että kaikki kyselyssä käytetyt taulut ja sarakkeet todella olemassa ja sijaitsevat muistissa.

72
00:06:06,454 --> 00:06:08,412
Mistä se löytää ne?

73
00:06:08,412 --> 00:06:12,921
Jokaisella SQLite-tietokannalla on taulu nimeltään sqlite_master,

74
00:06:12,921 --> 00:06:17,980
joka määrittelee tietokannan skeeman.

75
00:06:17,980 --> 00:06:19,990
Ja tämä on sen rakenne.

76
00:06:19,990 --> 00:06:23,527
Joten jokaiselle tietokannan objektille sinulla on merkintä,

77
00:06:23,527 --> 00:06:33,019
jossa on sen tyyppi, taulu tai näkymä, sen nimi ja aivan alareunassa jotain, jota kutsutaan SQL:ksi.

78
00:06:33,019 --> 00:06:38,550
Ja SQL on itse asiassa DDL, joka kuvaa objektia.

79
00:06:38,975 --> 00:06:46,016
DDL tarkoittaa datamäärittelykieltä, ja sitä voidaan verrata C-kielen otsikkotiedostoihin.

80
00:06:46,016 --> 00:06:52,881
Ne määrittelevät tietokannan objektien rakenteen, nimet ja tyypit.

81
00:06:52,881 --> 00:06:57,227
Lisäksi ne näkyvät selkokielisinä tiedostossa.

82
00:06:57,272 --> 00:07:05,264
Annan esimerkin. Avasin SQLite-tulkin, loin taulun ja lisäsin siihen arvoja.

83
00:07:05,264 --> 00:07:10,003
Sitten lopetin tulkin ja nyt avaamme tiedoston heksadesimaalimuodossa.

84
00:07:10,003 --> 00:07:18,260
Voit nähdä keltaisella korostettuna näkyvän DDL-lauseke, joka on osa pääskeemaa.

85
00:07:18,260 --> 00:07:21,004
Alhaalla voit myös nähdä arvot.

86
00:07:21,439 --> 00:07:23,900
Palataan kyselyn valmisteluun.

87
00:07:24,382 --> 00:07:33,219
Meillä on sqlite3LocateTable, joka yrittää löytää taulun rakenteen, jota haluamme kysellä.

88
00:07:33,219 --> 00:07:39,030
Se lukee skeeman sqlite_masterista, jonka juuri kuvailimme.

89
00:07:39,030 --> 00:07:41,534
Ja jos se tekee sen ensimmäistä kertaa,

90
00:07:41,534 --> 00:07:47,097
sillä on joitakin takaisinkutsufunktioita jokaiselle näistä DDL-lausekkeista.

91
00:07:47,097 --> 00:07:56,723
Takaisinkutsufunktio validoi DDL:n ja rakentaa sen jälkeen sisäiset rakenteet kyseisestä objektista.

92
00:07:56,723 --> 00:08:00,944
Sitten ajattelimme DDL:n paikkaamista.

93
00:08:00,944 --> 00:08:05,941
Entä jos vain korvaamme SQL-kyselyn DDL:ssä?

94
00:08:05,941 --> 00:08:09,036
Tämä johtaa kuitenkin pieneen ongelmaan.

95
00:08:09,036 --> 00:08:13,883
Tämä on aiemmin mainitsemani takaisinkutsufunktio, ja kuten näet,

96
00:08:13,883 --> 00:08:23,158
DDL tarkistetaan ensin aloittavan "create ":lla. Vasta sen jälkeen valmistelu jatkuu.

97
00:08:23,158 --> 00:08:25,249
Tämä on ehdottomasti rajoitus, eikö niin?

98
00:08:25,249 --> 00:08:27,981
Meidän DDL:n on aloitettava "create ":lla.

99
00:08:27,981 --> 00:08:31,750
Mutta tämä jättää jonkin verran tilaa joustavuudelle,

100
00:08:31,750 --> 00:08:37,216
sillä SQLite-dokumentaation perusteella monia asioita voidaan luoda.

101
00:08:37,216 --> 00:08:42,154
Voimme luoda indeksejä, taulukoita, laukaisimia, näkymiä ja jotain,

102
00:08:42,154 --> 00:08:45,874
mitä emme vielä täysin ymmärrä, nimeltä virtuaaliset taulukot.

103
00:08:45,874 --> 00:08:54,556
Niinpä ajattelimme "CREATE VIEW":ta, koska näkymä on vain esipakattu SELECT-lauseke,

104
00:08:54,556 --> 00:08:58,637
ja näkymiä kysytään hyvin samalla tavalla kuin taulukoita.

105
00:08:58,637 --> 00:09:05,669
Joten, taulukosta sarakkeen valitseminen on semanttisesti sama asia kuin sarakkeen valitseminen näkymästä.

106
00:09:06,509 --> 00:09:10,264
Sitten, kun ajattelimme kyselyn kaappaamisen käsitettä.

107
00:09:10,264 --> 00:09:15,338
Aiomme paikata sqlite_master DDL:n näkymillä taulukoiden sijaan.

108
00:09:15,338 --> 00:09:20,074
Nyt paikatut näkymät voivat olla mitä tahansa SELECT-alilauseketta, jonka haluamme.

109
00:09:20,074 --> 00:09:25,506
Ja nyt tällä alilausekkeella voin yhtäkkiä käyttää SQLite-tulkintaa.

110
00:09:25,506 --> 00:09:30,986
Ja tämä on valtava askel eteenpäin! Muutimme juuri hallitsemattoman kyselyn joksikin,

111
00:09:30,986 --> 00:09:32,997
jota voimme jonkin verran hallita.

112
00:09:32,997 --> 00:09:36,775
Joten anna minun näyttää sinulle esimerkki kyselyn kaappaamisesta.

113
00:09:36,775 --> 00:09:41,138
Sanotaan, että joissakin alkuperäisissä tietokannoissa oli yksi taulu,

114
00:09:41,138 --> 00:09:46,535
ja tämä on DDL, joka määrittelee sen. Joten se on nimeltään "dummy" ja sillä on kaksi saraketta.

115
00:09:46,535 --> 00:09:51,616
Joten ilmeisesti mikä tahansa kohdesovellus yrittäisi kysyä sitä seuraavasti:

116
00:09:51,616 --> 00:09:55,587
Se vain yrittäisi valita nämä sarakkeet taulukosta, eikö niin.

117
00:09:55,587 --> 00:09:59,197
Mutta seuraava näkymä voi todella kaapata tämän kyselyn.

118
00:09:59,197 --> 00:10:04,104
Luon näkymän, se on juuri samanniminen ja sillä on sama määrä sarakkeita,

119
00:10:04,104 --> 00:10:07,225
ja jokainen sarake on nimetty samalla tavalla, ja voit nähdä,

120
00:10:07,225 --> 00:10:10,252
että nyt jokainen sarake voi sisältää minkä tahansa alilausekkeen,

121
00:10:10,252 --> 00:10:13,789
jonka haluan, korostettuna sinisellä alareunassa.

122
00:10:13,789 --> 00:10:16,509
Joten anna minun näyttää sinulle käytännön esimerkki siitä.

123
00:10:16,509 --> 00:10:20,688
Tässä olen luonut näkymän nimeltä "dummy" col A ja col B:llä,

124
00:10:20,688 --> 00:10:26,308
ja ensimmäinen sarake käyttää sqlite_version()-funktiota, ja se on sisäänrakennettu funktio,

125
00:10:26,308 --> 00:10:29,136
joka palauttaa SQLite-version, ilmeisesti.

126
00:10:29,356 --> 00:10:35,496
Toinen sarake käyttää SQLite:n omaa toteutusta printf:stä.

127
00:10:35,496 --> 00:10:39,650
Juuri näin, niillä on kaikki nämä todella yllättävät ominaisuudet ja kyvyt.

128
00:10:39,650 --> 00:10:44,013
Joten katsotaan sitä nyt oletetusti - kohdesivulta.

129
00:10:44,013 --> 00:10:47,993
Joten kuka tahansa, joka yrittää valita näistä sarakkeista,

130
00:10:47,993 --> 00:10:50,971
suorittaa yhtäkkiä meidän funktioitamme.

131
00:10:50,971 --> 00:10:56,628
Vasemmalla voit nähdä SQLite-version, ja oikealla voit nähdä printf:n,

132
00:10:56,628 --> 00:11:01,806
joka suoritettiin kohdesivulla. Joten taas tämä on valtava edistysaskel.

133
00:11:01,806 --> 00:11:05,509
Me saavutimme juuri jonkin verran kontrollia sen kyselyn yli, eikö niin?

134
00:11:05,509 --> 00:11:10,018
Ja kysymys kuuluu, mitä voimme tehdä tällä kontrollilla.

135
00:11:10,018 --> 00:11:13,257
Onko SQLite:llä mitään järjestelmäkomentoja?

136
00:11:13,257 --> 00:11:18,454
Voimmeko ehkä lukea ja kirjoittaa jotain muita tiedostoja tiedostojärjestelmässä?

137
00:11:21,274 --> 00:11:26,460
Joten tämä oli hyvä kohta pysähtyä ja tarkastella jo tehtyä työtä alalla,

138
00:11:26,460 --> 00:11:29,220
koska ilmeisesti emme ole ensimmäiset,

139
00:11:29,220 --> 00:11:34,117
jotka ovat huomanneet SQLite:n valtavan potentiaalin hyväksikäytössä.

140
00:11:34,117 --> 00:11:37,765
Järkevä paikka aloittaa on SQLite-injektio,

141
00:11:37,765 --> 00:11:40,497
koska tämä on jonkinlainen vastaava tilanne, eikö niin?

142
00:11:40,497 --> 00:11:45,106
Jollakulla haitallisella on jonkinlainen kontrolli SQL-kyselyssä.

143
00:11:45,106 --> 00:11:50,440
Joten, on olemassa muutama tunnettu temppu SQL-injektiossa SQLite:llä.

144
00:11:50,440 --> 00:11:54,420
Ensimmäisellä on tekemistä toisen tietokannan liittämisen kanssa

145
00:11:54,420 --> 00:11:58,457
ja sen jälkeen taulun luomisen ja joitain merkkijonoja sen sisään laittamisen.

146
00:11:58,457 --> 00:12:03,163
Ja koska, kuten mainitsin aiemmin, jokainen tietokanta on vain tiedosto,

147
00:12:03,163 --> 00:12:08,200
tämä on jonkinlainen mielivaltainen tiedosto, tiedostojärjestelmässä.

148
00:12:08,200 --> 00:12:11,703
Kuitenkin meillä on tämä rajoitus, muistattehan, että emme voi liittää,

149
00:12:11,703 --> 00:12:14,776
koska DDL:n on aloitettava "CREATE"-sanalla.

150
00:12:15,436 --> 00:12:19,497
Toinen hieno temppu on käyttää load extension -funktiota väärin.

151
00:12:19,497 --> 00:12:24,995
Ja tässä voit nähdä, kuinka voit mahdollisesti ladata etä-DLL:n.

152
00:12:24,995 --> 00:12:26,863
Tässä tapauksessa meterpreter.dll,

153
00:12:26,863 --> 00:12:31,293
mutta ilmeisesti tämä erittäin vaarallinen funktio on oletuksena pois käytöstä.

154
00:12:31,293 --> 00:12:36,514
Joten se taas ei onnistu. Entä muistin korruptio SQLite:ssä,

155
00:12:36,514 --> 00:12:41,849
koska SQLite on todella monimutkainen ja se on kaikki kirjoitettu C:llä.

156
00:12:42,478 --> 00:12:47,343
Hänen hämmästyttävässä blogikirjoituksessaan "Virheiden löytäminen SQLite:ssä helposti",

157
00:12:47,343 --> 00:12:50,098
Michal Zalewski, AFL:n tekijä, kuvasi,

158
00:12:50,098 --> 00:12:55,635
kuinka hän löysi 22 bugia alle 30 minuutissa fuzzingilla

159
00:12:55,635 --> 00:12:58,246
Ja itse asiassa, sen jälkeen,

160
00:12:58,246 --> 00:13:01,583
kun kyseessä oli versio 3.8.10 vuonna 2015,

161
00:13:01,583 --> 00:13:07,306
SQLite alkoi käyttää AFL:ää osana huomattavaa testisarjaa.

162
00:13:07,306 --> 00:13:15,081
Nämä muistin korruptiovirheet osoittautuivat kuitenkin erittäin vaikeiksi hyödyntää ilman sopivaa ympäristöä.

163
00:13:15,081 --> 00:13:19,834
Turvallisuustutkimusyhteisö löysi kuitenkin pian täydellisen kohteen,

164
00:13:19,834 --> 00:13:22,400
ja se oli nimeltään WebSQL.

165
00:13:22,660 --> 00:13:28,402
Joten WebSQL on periaatteessa API tietojen tallentamiseen tietokantoihin,

166
00:13:28,402 --> 00:13:33,835
ja sitä kysytään JavaScriptistä, ja sillä on SQLite-tausta.

167
00:13:33,835 --> 00:13:37,305
Lisäksi se on saatavana Chromessa ja Safarissa.

168
00:13:37,305 --> 00:13:43,475
Tässä voit nähdä hyvin yksinkertaisen esimerkin siitä, miten voit käyttää WebSQL:ää JavaScriptistä.

169
00:13:46,525 --> 00:13:49,523
Mutta toisin sanoen, mitä täällä luulen, on se,

170
00:13:49,523 --> 00:13:53,248
että meillä on joitakin luottamattomia syötteitä SQLite:lle,

171
00:13:53,248 --> 00:13:56,992
ja se on saavutettavissa mistä tahansa Internetin verkkosivustosta

172
00:13:56,992 --> 00:13:59,596
kahdessa maailman suosituimmassa selaimessa.

173
00:13:59,596 --> 00:14:02,265
Ja yhtäkkiä nämä virheet,

174
00:14:02,265 --> 00:14:10,449
nämä muistin korruptiot, voidaan nyt hyödyntää JavaScript-hyväksikäytön tiedosta ja mukavuudesta.

175
00:14:10,499 --> 00:14:14,875
JavaScript-tulkin hyväksikäyttö, jossa olemme tulleet varsin hyviksi vuosien varrella.

176
00:14:14,875 --> 00:14:22,066
Joten WebSQL:stä on julkaistu useita vaikuttavia tutkimuksia,

177
00:14:22,066 --> 00:14:23,870
jotka vaihtelevat todella helppoista kohteista,

178
00:14:23,870 --> 00:14:26,933
kuten CVE-2015-7036,

179
00:14:26,933 --> 00:14:31,556
joka oli luottamattoman osoittimen purku fts3_tokenizer()-funktiossa,

180
00:14:31,556 --> 00:14:33,978
monimutkaisempiin hyökkäyksiin,

181
00:14:33,978 --> 00:14:42,593
kuten Blackhat 2017:ssä esitelty Chaitin-tiimin löytämä tyyppisekoittumisongelma FTS-optimoinnissa,

182
00:14:42,593 --> 00:14:46,225
sekä hiljattain Magellan-bugit, jotka Tencent löysi,

183
00:14:46,225 --> 00:14:50,842
jotka löysivät kokonaisluvun ylivuodon FTS-segmentinlukijassa.

184
00:14:50,842 --> 00:14:53,911
Ja jos kiinnität nyt edes hieman huomiota,

185
00:14:53,911 --> 00:14:57,598
niin näet mielenkiintoisen kaavan nousevan esiin.

186
00:14:57,598 --> 00:15:01,677
Kaikki nämä haavoittuvat funktiot alkavat FTS:llä.

187
00:15:01,677 --> 00:15:03,087
Joten mikä on FTS?

188
00:15:03,087 --> 00:15:04,573
En ole koskaan kuullut siitä.

189
00:15:04,573 --> 00:15:05,826
Ja kun etsin sitä Googlesta,

190
00:15:05,826 --> 00:15:08,063
se vain hämmensi minua vielä enemmän.

191
00:15:09,565 --> 00:15:10,820
Jonkin ajan kuluttua tajusin,

192
00:15:10,820 --> 00:15:19,104
että FTS tarkoittaa "täysi tekstihaku" ja se on jotain nimeltään virtuaalinen taulukkomoduuli,

193
00:15:19,104 --> 00:15:23,999
joka mahdollistaa todella hienovaraisen tekstin haun dokumenttien joukosta.

194
00:15:23,999 --> 00:15:27,269
Tai kuten SQLite-tekijät kuvasivat sitä,

195
00:15:27,269 --> 00:15:29,748
se on "kuin Google SQLite-tietokannoillesi".

196
00:15:29,748 --> 00:15:34,970
Joten virtuaalitaulukot mahdollistavat joitain todella hienoja toimintoja SQLite:ssa,

197
00:15:34,970 --> 00:15:39,574
olipa kyseessä tämä vapaa tekstin haku tai virtuaalitaulukkomoduuli nimeltään RTREE,

198
00:15:39,574 --> 00:15:42,652
joka tekee todella fiksua maantieteellistä indeksointia,

199
00:15:42,652 --> 00:15:44,922
tai virtuaalitaulukko nimeltään CSV,

200
00:15:44,922 --> 00:15:47,967
joka antaa sinun käsitellä tietokantaasi CSV-tiedostona.

201
00:15:47,967 --> 00:15:52,395
Ja näitä virtuaalitaulukoita kysytään itse asiassa ihan kuin normaaleja taulukoita.

202
00:15:52,395 --> 00:15:56,534
Kuitenkin taustalla tapahtuu joitain pimeitä taikoja.

203
00:15:56,534 --> 00:16:01,112
Ja jokaisen kyselyn jälkeen, kutsutaan jonkinlaista takaisinkutsufunktiota,

204
00:16:01,112 --> 00:16:05,736
joka toimii niin kutsuttua shadow-taulukkoa vastaan.

205
00:16:05,736 --> 00:16:09,172
Varjotaulukot olisi parasta selittää esimerkin avulla.

206
00:16:09,172 --> 00:16:15,774
Joten sanotaan, että luon virtuaalitaulukon käyttäen sitä FTS-virtuaalitaulukkomoduulia

207
00:16:15,774 --> 00:16:18,081
ja lisään siihen merkkijonon.

208
00:16:18,081 --> 00:16:22,974
Ilmeisesti tehokkaan haun sallimiseksi minulla täytyy olla joitain metatietoja, okei?

209
00:16:22,974 --> 00:16:26,823
Minun täytyy olla joitain offsetteja tai indeksejä tai merkkejä tai jotain sellaista.

210
00:16:26,823 --> 00:16:29,117
Ja ilmeisesti kaikki ne ovat tekstiä, eikö niin?

211
00:16:29,117 --> 00:16:34,037
Joten yksi virtuaalitaulukko on itse asiassa raakatekstiä,

212
00:16:34,037 --> 00:16:37,704
ja metatiedot tallennetaan kolmen varjoshadow-taulukon joukkoon.

213
00:16:37,704 --> 00:16:43,339
Joten raakateksti menisi vt_contentiin ja metatiedot menisivät vt_segmentsiin ja vt_segdiriin.

214
00:16:44,078 --> 00:16:49,379
Ajan myötä nämä varjotaulukot ovat liittymäpintoja,

215
00:16:49,379 --> 00:16:51,521
jotka siirtävät tietoa toistensa välillä.

216
00:16:51,521 --> 00:16:54,075
Koska metatieto tallentaa kaikki nämä osoittimet,

217
00:16:54,075 --> 00:16:56,528
sinun on siirrettävä ne toistensa välillä.

218
00:16:56,528 --> 00:16:59,464
Ja nämä liittymäpinnat osoittautuivat todella,

219
00:16:59,464 --> 00:17:02,083
todella luottavaisiksi luonteeltaan.

220
00:17:02,083 --> 00:17:06,997
Ja se tekee niistä todella otollisen maaperän bugin metsästykseen.

221
00:17:06,997 --> 00:17:13,433
Näytän teille nyt bugin, jonka löysin RTREE-virtuaalitaulukkomoduulista.

222
00:17:14,639 --> 00:17:18,841
RTREE-virtuaalitaulumoduuli on nyt saatavilla MacOS- ja iOS-laitteille,

223
00:17:18,841 --> 00:17:22,504
ja se on todella hieno, koska se on nyt myös osa Windows 10:ää.

224
00:17:22,504 --> 00:17:27,617
Ja kuten mainitsin, se tekee todella fiksua maantieteellistä indeksointia.

225
00:17:27,617 --> 00:17:34,032
DDL:n tulisi olla seuraava. Minkä tahansa RTREE-virtuaalitaulun tulisi alkaa "id":llä,

226
00:17:34,032 --> 00:17:39,448
jonka täytyy olla kokonaisluku. Sen jälkeen sinulla on joitakin X- ja Y-koordinaatteja.

227
00:17:39,448 --> 00:17:44,591
Joten jokainen RTREE-liitäntä odottaisi "id":n olevan kokonaisluku.

228
00:17:44,591 --> 00:17:48,716
Mutta jos luon virtuaalitaulun ja lisään "id":hen jotain,

229
00:17:48,716 --> 00:17:54,662
joka ei ole kokonaisluku, ja käytän yhtä näistä RTREE-liitännäisistä,

230
00:17:54,662 --> 00:17:59,150
rtreenode, näet alhaalla, että saamme tämän kaatumisen,

231
00:17:59,150 --> 00:18:03,328
tämän kekomuistin ulkopuolisen lukemisen.

232
00:18:03,328 --> 00:18:07,499
Ja tämä esimerkki on kaatuminen Windows 10:ssä.

233
00:18:07,499 --> 00:18:11,128
Joten se on aika hyvä. Olemme havainneet,

234
00:18:11,128 --> 00:18:13,978
että virtuaalitaulussa on bugeja.

235
00:18:13,978 --> 00:18:16,992
Ja nyt, käyttämällä kyselyn kaappaustekniikkaa,

236
00:18:16,992 --> 00:18:21,313
voimme yhtäkkiä laukaista nämä bugit kohteellamme,

237
00:18:21,313 --> 00:18:25,832
joka on salasanavaras C2, ja se kaatuu (segfault).

238
00:18:25,832 --> 00:18:30,050
Ja tämä on hienoa, mutta varsinaisen ohjauksen saaminen kohteestamme

239
00:18:30,050 --> 00:18:33,593
vaatii jonkinlaista skriptausta, eikö niin?

240
00:18:33,593 --> 00:18:37,003
Haluamme ohittaa ASLR:n ja tehdä kaikenlaisia hulluja asioita.

241
00:18:37,003 --> 00:18:39,079
Meillä ei kuitenkaan ole JavaScriptiä,

242
00:18:39,079 --> 00:18:43,787
meillä ei ole JavaScript-taulukoita ja muuttujia ja logiikkalauseita,

243
00:18:43,787 --> 00:18:50,369
kuten if ja and silmukoita ja sellaisia. Kuitenkin muistamme jostain kuulleemme,

244
00:18:50,369 --> 00:18:53,257
että SQL on Turing-täydellinen.

245
00:18:53,257 --> 00:18:58,880
Joten päätimme testata sitä hyökkäysnäkökulmasta

246
00:18:58,880 --> 00:19:03,622
ja aloimme luoda omaa primitiivista toivelistaa hyökkäystä varten.

247
00:19:03,622 --> 00:19:06,490
Joten jos se voisi luoda täyden hyökkäyksen,

248
00:19:06,490 --> 00:19:09,712
jossa hyödynnetään muistin korruptiobugeja pelkästään SQL:llä,

249
00:19:09,712 --> 00:19:11,896
mitä kyvykkyyksiä haluamme?

250
00:19:11,896 --> 00:19:15,208
Joten ilmeisesti ohittaaksemme ASLR:n ja nämä asiat,

251
00:19:15,208 --> 00:19:16,659
tarvitsemme vuodon muistista.

252
00:19:16,659 --> 00:19:18,777
Meidän täytyy saada tietovuoto.

253
00:19:18,777 --> 00:19:20,955
Jos olet tehnyt pwningia menneisyydessäsi,

254
00:19:20,955 --> 00:19:24,051
sinun täytyy olla tuttu todella yleisten tehtävien suhteen,

255
00:19:24,051 --> 00:19:29,339
kuten 64-bittisten osoittimen purkamisesta ja joitakin osoitinlaskutoimituksia, eikö niin?

256
00:19:29,339 --> 00:19:33,126
Koska meillä oli tietovuoto, muunnamme - luemme tämän osoittimen,

257
00:19:33,126 --> 00:19:35,412
ja se on little-endian, joten meidän täytyy kääntää se,

258
00:19:35,412 --> 00:19:38,867
ja nyt haluamme laskea, missä on libsqlite-tiedoston perusta,

259
00:19:38,867 --> 00:19:40,959
jotta voimme löytää ehkä lisää funktioita.

260
00:19:40,959 --> 00:19:43,869
Joten tarvitsemme joitakin osoitinlaskutoimituksia.

261
00:19:43,869 --> 00:19:48,042
Luonnollisesti, kun olemme lukeneet osoittimet ja manipuloineet niitä,

262
00:19:48,042 --> 00:19:52,424
haluamme pakata ne uudelleen ja kirjoittaa ne jonnekin.

263
00:19:52,424 --> 00:19:55,959
Yhden osoittimen kirjoittaminen ei koskaan riitä.

264
00:19:55,959 --> 00:19:59,370
Haluamme luoda väärennettyjä objekteja muistissa,

265
00:19:59,370 --> 00:20:04,514
monimutkaisempia kuin yksi osoitin. Lopuksi, haluaisimme heap sprayn,

266
00:20:04,514 --> 00:20:06,551
koska se voi olla todella hyödyllinen.

267
00:20:06,551 --> 00:20:09,317
Joten, kysymys kuuluu,

268
00:20:09,317 --> 00:20:13,427
voiko kaikki tämä hyödyntäminen tehdä pelkästään SQL:llä?

269
00:20:13,427 --> 00:20:16,075
Vastaus on "kyllä, se on mahdollista".

270
00:20:16,075 --> 00:20:21,231
Ja esittelen teille ylpeänä Kysely-orientoitunut ohjelmointi tai QOP.

271
00:20:21,231 --> 00:20:30,153
Demonstroidakseni QOP:ia hyväksikäytämme haavoittuvuutta CVE-2015-7036.

272
00:20:33,273 --> 00:20:34,580
Ja saatatte kysyä itseltänne:

273
00:20:34,580 --> 00:20:38,685
Miten neljä vuotta vanha bugi on edelleen korjaamatta?

274
00:20:38,685 --> 00:20:42,473
Ja tämä on hieno asia argumenttiimme.

275
00:20:42,473 --> 00:20:48,962
Tämä CVE koettiin vaaralliseksi vain luottamattomien Web-SQL:n suhteen.

276
00:20:48,962 --> 00:20:51,274
Se siis kierrettiin oikein.

277
00:20:51,274 --> 00:20:55,820
Se on blacklistattu ja SQL on käännetty tietyllä lipulla.

278
00:20:55,820 --> 00:20:59,299
Joten selkeästi selaimet eivät enää ole kääntäneet tällä lipulla.

279
00:20:59,299 --> 00:21:00,504
Mutta anna minun näyttää sinulle,

280
00:21:00,504 --> 00:21:02,362
minkä kanssa nämä liput on käännetty.

281
00:21:02,362 --> 00:21:04,678
Joten meillä on PHP 5 ja PHP 7,

282
00:21:04,678 --> 00:21:06,397
jotka ovat vastuussa suurimmasta osasta Internetiä,

283
00:21:06,397 --> 00:21:10,000
sekä iOS ja MacOS ja todennäköisesti niin monia muita kohteita,

284
00:21:10,000 --> 00:21:14,275
joita emme vain ehtineet käydä läpi.

285
00:21:14,275 --> 00:21:16,698
Joten selitetään hieman tätä haavoittuvuutta.

286
00:21:16,698 --> 00:21:19,591
Olen maininnut, että se on FTS-tokenizerissa.

287
00:21:19,911 --> 00:21:24,658
Joten tokenizer on vain joukko sääntöjä dokumenttien

288
00:21:24,658 --> 00:21:26,751
tai kyselyjen termeistä erottamiseksi.

289
00:21:26,751 --> 00:21:30,938
Ja oletustokenizeri, jota kutsutaan "yksinkertaiseksi",

290
00:21:30,938 --> 00:21:33,918
vain jakaa merkkijonot tyhjien merkkien perusteella.

291
00:21:33,918 --> 00:21:38,637
Kuitenkin, jos haluat, voit rekisteröidä oman mukautetun tokenizerin.

292
00:21:38,637 --> 00:21:42,429
Voit vain siirtää C-funktion ja oikeastaan rekisteröit

293
00:21:42,429 --> 00:21:47,763
tämän mukautetun tokenizerin fts3_tokenizer() -funktiolla SQL-kyselyssä.

294
00:21:48,793 --> 00:21:51,125
Tässä on jonkin verran asiaa, mutta sanon sen hitaasti.

295
00:21:51,125 --> 00:21:55,514
Siirrät riviosoittimen C-funktioon SQL-kyselyssä.

296
00:21:55,514 --> 00:21:57,448
Tämä on täysin mielipuolista.

297
00:21:57,448 --> 00:22:00,641
Rehellisesti sanottuna, vaikka olen tutkinut tätä jonkin aikaa,

298
00:22:00,641 --> 00:22:05,098
en vieläkään ymmärrä, miten käyttää tätä ominaisuutta hyväksi muualla kuin hyökkäyksessäni.

299
00:22:05,515 --> 00:22:12,663
[Yleisö taputtaa]

300
00:22:15,826 --> 00:22:20,277
fts3_tokenizer() on ylikuormitettu funktio,

301
00:22:20,277 --> 00:22:22,243
ja jos kutsut sen yhdellä argumentilla,

302
00:22:22,243 --> 00:22:27,303
joka on tokenizerin nimi, saat takaisin kyseisen tokenizerin osoitteen.

303
00:22:27,303 --> 00:22:33,760
Teemme sen hieman ihmiselle luettavammaksi käyttämällä heksadesimaalimuunnosta.

304
00:22:33,760 --> 00:22:38,916
Voit nyt nähdä, että saimme tietovuodon libsqlite3:een.

305
00:22:38,916 --> 00:22:42,970
Koska se on little-endian, meidän on käännettävä se ympäri,

306
00:22:42,970 --> 00:22:44,755
mutta tämä on jo melko hienoa.

307
00:22:44,755 --> 00:22:48,326
Jos kutsut fts3_tokenizer():ia kahdella argumentilla,

308
00:22:48,326 --> 00:22:55,022
joista ensimmäinen on tokenizerin nimi ja toinen on raakaosoitin, ja tämä on täysin mielipuolista..

309
00:22:55,022 --> 00:22:58,010
voit kirjoittaa kyseisen tokenizerin osoitteen uudelleen.

310
00:22:58,010 --> 00:23:01,748
Joten aina kun joku yrittää käyttää virtuaalitaulua

311
00:23:01,748 --> 00:23:08,188
ja se instantisoi oletusarvoisen tokenizerin, se kaatuu.

312
00:23:08,188 --> 00:23:10,739
Tämä on melko hämmästyttävää.

313
00:23:10,739 --> 00:23:14,174
Lyhyt kertaus: olemme vahvistaneet,

314
00:23:14,174 --> 00:23:18,140
että SQLite on ihana yhden maalin kohde monille, eikö niin?

315
00:23:18,140 --> 00:23:19,741
Se on kaikkialla.

316
00:23:19,741 --> 00:23:23,652
Ja se on monimutkainen C:llä kirjoitettu kone.

317
00:23:23,652 --> 00:23:27,458
Nyt, kyselyn kaappaamisen avulla voimme alkaa laukaista näitä bugeja

318
00:23:27,458 --> 00:23:35,231
ja tavoitella täydellistä hyökkäystä käyttämällä SQL-kyselyjä.

319
00:23:35,631 --> 00:23:40,698
Hyökkäysstrategiamme on seuraava: vuodatamme joitakin osoittimia

320
00:23:40,698 --> 00:23:44,708
ja sitten laskemme joitakin funktio-osoitteita.

321
00:23:44,708 --> 00:23:47,519
Luomme sitten väärennetyn tokenizer-objektin,

322
00:23:47,519 --> 00:23:50,414
jolla on jokin osoitin system()-funktioon.

323
00:23:50,414 --> 00:23:55,161
Ylikirjoitamme oletusarvoisen tokenizerin ja laukaisemme pahantahtoisen tokenizerimme.

324
00:23:55,161 --> 00:24:02,684
Sitten tapahtuu jotain, ja lopussa meidän pitäisi pystyä hyötymään jotenkin, eikö niin?

325
00:24:02,684 --> 00:24:07,281
Aloittaen muistivuodosta ja tietovuodosta libsqliteen.

326
00:24:07,281 --> 00:24:09,780
Tiedät jo, miten tehdään, eikö niin?

327
00:24:09,780 --> 00:24:16,480
Näimme fts3_tokenizer():in, mutta meillä on vielä pieni ongelma little-endian osoittimen kanssa.

328
00:24:16,480 --> 00:24:18,051
Joten meidän on käännettävä se ympäri.

329
00:24:18,051 --> 00:24:20,745
Varmaan voimme käyttää SUBSTR-funktiota

330
00:24:20,745 --> 00:24:25,473
ja lukea tämän osoittimen kaksi merkkiä kerrallaan käänteisessä järjestyksessä

331
00:24:25,473 --> 00:24:29,212
ja yhdistää kaiken koko osoittimen läpi.

332
00:24:29,212 --> 00:24:32,957
Joten saamme SELECT-kyselyn, joka näyttää seuraavalta,

333
00:24:32,957 --> 00:24:35,410
mutta nyt meillä on osoitin.

334
00:24:35,410 --> 00:24:36,801
Tämä on hienoa.

335
00:24:36,801 --> 00:24:38,796
Entä tietovuoto kekomuistiin?

336
00:24:38,796 --> 00:24:40,856
Haluamme tietää, missä keko sijaitsee.

337
00:24:40,856 --> 00:24:43,375
Aloitetaanpa tekemään temppua,

338
00:24:43,375 --> 00:24:46,588
joka on melko samankaltainen kuin RTREE-bugi, jonka olemme löytäneet.

339
00:24:46,588 --> 00:24:50,736
Joten jälleen kerran, aiomme sekoittaa joitakin shadow-taulukkojen käyttöliittymiä.

340
00:24:50,736 --> 00:24:56,023
Luomme siis virtuaalitaulukon ja lisäämme siihen joitakin arvoja.

341
00:24:56,023 --> 00:24:59,718
Nyt aiomme hämmentää match-käyttöliittymää.

342
00:24:59,718 --> 00:25:02,921
Match-käyttöliittymä tekee monia asioita,

343
00:25:02,921 --> 00:25:09,193
mutta taustalla se vain palvelee osoittimen muistissa, jossa tekstin sijainti sijaitsee.

344
00:25:09,193 --> 00:25:12,546
Se on tätä metadataa, hienoja asioita, joita virtuaalitaululla on.

345
00:25:12,546 --> 00:25:14,657
Joten aiomme hämmentää sitä ja sen sijaan,

346
00:25:14,657 --> 00:25:17,892
että siirtäisimme sen toiselle virtuaalitaulun käyttöliittymälle,

347
00:25:17,892 --> 00:25:21,194
siirrämme sen yksinkertaisesti heksadekooderille,

348
00:25:21,194 --> 00:25:23,519
joten puramme tämän raakanosoittimen.

349
00:25:23,519 --> 00:25:25,708
Ja voit nähdä, jälleen kerran little-endianin,

350
00:25:25,708 --> 00:25:28,036
mutta nyt meillä on linkki kekoon.

351
00:25:28,526 --> 00:25:30,691
Voimme yliviivata sen listalta.

352
00:25:30,691 --> 00:25:34,110
Ja ennen kuin siirrymme eteenpäin tämän osoittimen purkamiseen,

353
00:25:34,110 --> 00:25:37,493
meillä on hyvin perustavanlaatuinen ongelma.

354
00:25:37,493 --> 00:25:39,870
Kuinka edes tallennamme näitä asioita?

355
00:25:39,870 --> 00:25:44,888
Koska toisin kuin selaimen WebSQL:ssä, meillä ei ole JavaScript-muuttujia tai taulukoita,

356
00:25:44,888 --> 00:25:46,699
joita voimme käyttää ja hyväksikäyttää myöhemmin,

357
00:25:46,699 --> 00:25:49,668
mutta meidän on luotava joitakin monimutkaisia logiikoita, eikö niin?

358
00:25:49,668 --> 00:25:55,465
Meidän on laskettava funktio-osoite ja luotava asioita muistissa, mutta kuinka voimme tehdä sen?

359
00:25:55,465 --> 00:25:58,037
Ilmeisesti SQLite:llä, kun haluat tallentaa joitakin arvoja,

360
00:25:58,037 --> 00:26:04,801
sinun on oltava insert-lausekkeita, mutta voimme vain luoda tauluja, näkymiä, indeksejä ja laukaisimia.

361
00:26:05,901 --> 00:26:11,754
Sitten ajattelimme ketjuttaa tämän näkymän yhteen käyttääksemme niitä jonkinlaisena pseudomuuttujana.

362
00:26:11,754 --> 00:26:13,908
Joten jälleen kerran, anna minun näyttää sinulle esimerkki.

363
00:26:13,908 --> 00:26:18,147
Tässä luon näkymän, jota kutsutaan "little-endian leak", okei?

364
00:26:18,147 --> 00:26:21,873
Ja taas hyväksikäytän fts3_tokenizer() -funktiota.

365
00:26:21,873 --> 00:26:25,153
Nyt luon toisen näkymän sen päälle, ja tätä kutsutaan "leakiksi"

366
00:26:25,153 --> 00:26:27,775
ja kääntyy käyttämällä SUBSTR-temppua,

367
00:26:27,775 --> 00:26:29,148
jonka tiedät jo aikaisemmasta.

368
00:26:29,148 --> 00:26:33,095
Mutta huomaa, kuinka viittasin ensimmäiseen näkymään, viittasin "little-endian leak":iin.

369
00:26:33,095 --> 00:26:40,419
Joten teen sen koko osoittimen läpi, ja lopulta minulla on pseudomuuttuja nimeltä "leak".

370
00:26:40,419 --> 00:26:44,847
Kun valitsen sen, saan odotetun tuloksen.

371
00:26:45,131 --> 00:26:47,666
Joten nyt voimme todella edetä.

372
00:26:47,666 --> 00:26:51,761
Nyt voimme aloittaa monimutkaisempien asioiden rakentamisen tämän logiikan perusteella.

373
00:26:52,491 --> 00:26:54,934
Ja nyt voimme siirtyä purkamaan osoittimia.

374
00:26:55,474 --> 00:27:01,211
Haluamme esimerkiksi laskea kuvan perustan tai löytää keon alun.

375
00:27:01,211 --> 00:27:05,677
Joten ensinnäkin haluamme muuntaa osoittimemme kokonaisluvuiksi.

376
00:27:05,677 --> 00:27:11,740
Joten jälleen kerran aloitamme lukemalla nämä osoittimet yhden merkin kerrallaan

377
00:27:11,740 --> 00:27:14,821
ja käänteisessä järjestyksessä käyttäen SUBSTRia.

378
00:27:14,821 --> 00:27:20,835
Ja saadaksemme heksadesimaalimerkin arvon, käytämme INSTR-funktiota,

379
00:27:20,835 --> 00:27:27,207
joka on kuin strchar, ja käyttämällä seuraavaa merkkijonoa saamme heksadesimaalimerkin arvon.

380
00:27:27,207 --> 00:27:32,238
Koska se on yksipohjainen, on oikealla miinus yksi.

381
00:27:32,238 --> 00:27:36,577
Sitten minun täytyy tehdä hieman siirtämistä, kuten jotain pimeää magiaa,

382
00:27:36,577 --> 00:27:42,332
ja sitten yhdistän kaiken yhteen osoittimessa.

383
00:27:42,332 --> 00:27:45,100
Joten tulos on tämä hirviömäinen kysely.

384
00:27:45,100 --> 00:27:53,060
Mutta kun kaikki tämä on tehty, saan kokonaisluvun, joka on purkamaton versio alkuperäisestä vuodosta.

385
00:27:53,060 --> 00:27:56,621
Joten onnistuin purkamaan tämän osoittimen,

386
00:27:56,621 --> 00:28:01,093
ja meillä on nyt käsillä kokonaislukuja, joten voimme yliviivata sen listalta myös.

387
00:28:01,093 --> 00:28:03,948
Tiedämme nyt, miten muuntaa osoittimet kokonaisluvuiksi.

388
00:28:04,198 --> 00:28:10,886
Nyt osoitinlaskentaa, koska haluamme saada joitain toimintojen osoitteita muistissa,

389
00:28:10,886 --> 00:28:14,430
ja itse asiassa kokonaislukuilla tämä on erittäin yksinkertaista.

390
00:28:14,430 --> 00:28:17,658
Kaikki mitä meidän tarvitsee tehdä on käyttää joitakin alikyselyjä.

391
00:28:17,658 --> 00:28:21,199
Vasemmalla voit nähdä, että viittaan nyt pseudomuuttujiin,

392
00:28:21,199 --> 00:28:23,990
joita meillä on nyt, vuotanut tieto,

393
00:28:23,990 --> 00:28:29,572
ja oikealla voin joko vähentää hölmön vakion kuten tein täällä,

394
00:28:29,572 --> 00:28:37,688
tai voin todella käyttää toista pseudomuuttujaa tehdäkseni sen hieman dynaamisemmaksi ja luotettavammaksi.

395
00:28:37,688 --> 00:28:45,327
Lopulta, mihin päädyin, on libsqlite-perusta kokonaislukumuodossa.

396
00:28:45,327 --> 00:28:50,272
Joten, olemme lukeneet joitakin osoittimia ja manipuloineet niitä.

397
00:28:50,272 --> 00:28:55,740
Nyt on hyvä aika kirjoittaa ne takaisin. Ja tietysti olemme tottuneet siihen,

398
00:28:55,740 --> 00:28:59,101
että "char" on täysin päinvastainen kuin "hex".

399
00:28:59,101 --> 00:29:03,840
Ja voit nähdä, että se toimii melko hyvin useimmilla arvoilla,

400
00:29:03,840 --> 00:29:08,928
mutta suuremmat kokonaisluvut todella käännettiin niiden kahden tavun koodipisteisiin.

401
00:29:08,928 --> 00:29:12,016
Joten tämä oli suuri este meille.

402
00:29:15,196 --> 00:29:20,186
Joten, kun olimme viettäneet dokumentaation parissa jonkin aikaa,

403
00:29:20,186 --> 00:29:22,642
yhtäkkiä meille valkeni kummallinen oivallus.

404
00:29:22,642 --> 00:29:25,919
Tajusimme, että hyökkäyksemme on itse asiassa tietokanta.

405
00:29:25,919 --> 00:29:28,929
Ja jos haluan minkä tahansa muunnoksen tapahtuvan,

406
00:29:28,929 --> 00:29:33,986
voin yksinkertaisesti luoda etukäteen tämän avain-arvo-kartan ja yksinkertaisesti

407
00:29:33,986 --> 00:29:41,297
kysyä sitä käännettäväksi millä tahansa arvolla toiseksi arvoksi alikyselyillä.

408
00:29:41,297 --> 00:29:43,405
Tämä on se Python-funktio, jonka olen käyttänyt,

409
00:29:43,405 --> 00:29:45,808
ja voit nähdä, että siinä on hyvin yksinkertainen for-silmukka,

410
00:29:45,808 --> 00:29:49,705
joka menee 0:sta FF:ään ja vain lisää arvoja tauluun,

411
00:29:49,705 --> 00:29:52,416
jota kutsutaan "hex_map", sen avain-kartan arvoilla.

412
00:29:52,416 --> 00:29:58,782
Ja nyt muunnoksemme käyttävät alikyselyjä. Joten anna minun jälleen näyttää esimerkki.

413
00:29:59,732 --> 00:30:02,310
Voit nähdä, että valitsen "val" heksakartasta,

414
00:30:02,310 --> 00:30:06,702
tästä avain-arvo-kartasta, jossa "int" on yhtä suuri kuin,

415
00:30:06,702 --> 00:30:11,368
ja sitten teen hieman enemmän kaikenlaista, kuten siirtämistä ja modulo pimeää magiaa,

416
00:30:11,368 --> 00:30:17,059
mutta lopulta päädyin pakattuun versioon libsqlite-tietokannasta.

417
00:30:17,059 --> 00:30:23,304
Nyt meillä on pakattu little-endian osoitin, joten sen voi ruksata listalta pois.

418
00:30:24,644 --> 00:30:29,929
Kuten mainitsin, yksittäisen osoittimen kirjoittaminen on ehdottomasti hyödyllistä,

419
00:30:29,929 --> 00:30:31,020
mutta se ei riitä.

420
00:30:31,295 --> 00:30:34,272
Haluamme väärentää kokonaisia objekteja, eikö niin?

421
00:30:34,272 --> 00:30:38,046
Kaikki coolit tyypit tekevät niin, ja se on melko voimakas primitiivi.

422
00:30:38,046 --> 00:30:40,897
Ja jos muistat, meidän on tehtävä se,

423
00:30:40,897 --> 00:30:46,086
koska fts3_tokenizer() edellyttää meidän määrittävän tokenizer moduulin.

424
00:30:46,086 --> 00:30:51,454
No, mikä on tokenizer-moduuli? Miltä se näyttää? Joten tämä on sen rakenteen alku,

425
00:30:51,454 --> 00:30:54,483
ja siinä on "iVersion", joka on kokonaisluku alussa,

426
00:30:54,483 --> 00:30:56,456
meillä ei ole oikeastaan mitään tekemistä sen kanssa,

427
00:30:56,456 --> 00:30:59,273
mutta sen jälkeen on kolme funktio-osoitinta.

428
00:30:59,573 --> 00:31:06,237
Meillä on "xCreate", joka on jakelijan rakentaja, ja "xDestroy", joka on purkaja.

429
00:31:06,237 --> 00:31:11,538
Meidän on tehtävä molemmat kelvollisiksi, jotta sovellus ei kaadu hyökätessämme.

430
00:31:11,538 --> 00:31:15,198
Kolmas funktio-osoitin on todella mielenkiintoinen, koska tämä on se,

431
00:31:15,198 --> 00:31:16,645
joka todella jakaa merkkijonon osiksi.

432
00:31:16,645 --> 00:31:20,784
Joten meillä on funktio-osoitin, johon ohjataan hallittavissa oleva merkkijono.

433
00:31:20,784 --> 00:31:25,620
Tämä olisi täydellinen paikka laittaa system-vimpaimemme, eikö niin.

434
00:31:26,510 --> 00:31:31,737
Tähän mennessä olen käyttänyt melkoisesti SQL-osaamistani, eikö niin?

435
00:31:31,737 --> 00:31:37,251
Mutta minulla on vielä yksi temppu hihassani ja se on JOIN-kyselyt, eikö niin?

436
00:31:37,251 --> 00:31:40,663
Koska olen oppinut siitä menneessä ajassa.

437
00:31:40,663 --> 00:31:44,217
Joten nyt luomme väärennetyn tokenizer-näkymän

438
00:31:44,217 --> 00:31:48,887
ja yhdistämme joukon "A"-kirjaimia ja sitten käyttäen JOIN-kyselyä

439
00:31:48,887 --> 00:31:53,900
ja yhdistämme sen osoittimeen simple_create ja osoittimeen simple_destroy

440
00:31:53,900 --> 00:31:58,951
ja sitten joukon "B":itä. Nyt tarkistetaan se alhaisen tason debuggerissa

441
00:31:58,951 --> 00:32:03,394
ja voit itse asiassa nähdä, että jossain muistipaikassa meillä on joukko "A":ita,

442
00:32:03,394 --> 00:32:05,537
jonka perässä on osoitin simple_createen,

443
00:32:05,537 --> 00:32:10,045
jonka perässä on osoitin simple_destroyiin ja sitten joukko "B":iä.

444
00:32:10,815 --> 00:32:16,314
Joten olemme melkein valmiit. Mutta tarvitsemme vielä yhden primitiivin tätä hyödyntääksemme.

445
00:32:16,314 --> 00:32:20,865
Ja tämä johtuu siitä, että meillä on jo haitallinen tokenizerimme,

446
00:32:20,865 --> 00:32:26,217
ja tiedämme, missä keko sijaitsee, mutta emme ole aivan varmoja, missä tokenizerimme sijaitsee.

447
00:32:26,217 --> 00:32:29,654
Tämä on hieno aika heap sprayinglle, eikö olekin.

448
00:32:29,654 --> 00:32:35,204
Ja ihanteellisesti tämä olisi jonkin toistuva muoto meidän fakeobj -primitiivistämme.

449
00:32:35,204 --> 00:32:44,031
Olemme siis ajatelleet toistoa, mutta valitettavasti SQLite ei ole toteuttanut sitä kuten mySQL.

450
00:32:44,031 --> 00:32:45,599
Joten kuten kuka tahansa muukin,

451
00:32:45,599 --> 00:32:50,346
menimme Stack Overflowiin ja löysimme tämän todella elegantin ratkaisun.

452
00:32:50,346 --> 00:32:57,886
Käytämme siis zeroblob-funktiota, joka yksinkertaisesti palauttaa nollista koostuvan läjän.

453
00:32:57,886 --> 00:33:02,641
Sitten korvaamme jokaisen nollan väärennetyllä tokenisaattorillamme.

454
00:33:02,641 --> 00:33:05,721
Ja teemme sen kymmenentuhatta kertaa, kuten näette yllä.

455
00:33:05,861 --> 00:33:08,764
Uudelleen, varmistaaksemme sen debuggerilla,

456
00:33:08,764 --> 00:33:12,024
näet paljon "A":ita ja se on vähän vaikea nähdä,

457
00:33:12,024 --> 00:33:16,414
koska nämä ovat todella huonoja värejä, mutta meillä on myös täydellinen johdonmukaisuus,

458
00:33:16,414 --> 00:33:20,842
koska nämä rakenteet toistuvat joka 20. heksadesimaalitavussa.

459
00:33:21,222 --> 00:33:25,823
Joten loimme melko hyvät heap-spraying -kyvyt,

460
00:33:26,773 --> 00:33:30,952
ja olemme valmiit exploitti -toiveluettelomme kanssa,

461
00:33:30,952 --> 00:33:34,489
joten voimme palata alkuperäiseen kohteeseemme.

462
00:33:34,489 --> 00:33:39,709
Tämä on koodisegmentti erittäin tunnetusta salasanavarkaasta,

463
00:33:39,709 --> 00:33:42,646
ja lopussa voit nähdä, että se yrittää valita

464
00:33:42,646 --> 00:33:50,414
ja poimia salaisuuksia valitsemalla sarakkeen nimeltä "BodyRich" taulusta nimeltä "Notes".

465
00:33:50,414 --> 00:33:54,203
Joten valmistelemme hänelle pienen yllätyksen, okei?

466
00:33:54,397 --> 00:33:56,811
Luomme näkymän, jota kutsutaan nimellä "Notes".

467
00:33:56,811 --> 00:34:00,766
Ja siinä on kolme alikyselyä sarakkeessa nimeltä "BodyRich".

468
00:34:00,766 --> 00:34:05,193
Jokainen näistä alikyselyistä on itse asiassa QOP-ketju.

469
00:34:05,193 --> 00:34:08,598
Jos muistat hyökkäyssuunnitelmani,

470
00:34:08,598 --> 00:34:14,137
aloitamme heap-spray sitten korvaamme oletustokenisaattorin

471
00:34:14,137 --> 00:34:17,148
ja laukaisemme lopuksi haitallisen tokenisaattorin.

472
00:34:17,148 --> 00:34:20,408
Ja sinä saatat kysyä itseltäsi, mikä on heap_spray?

473
00:34:20,408 --> 00:34:26,735
Ilmeisesti heap_spray on QOP-ketju, joka hyödyntää heap-spraying -kykyjämme, eikö niin.

474
00:34:26,735 --> 00:34:32,856
Me ruiskutamme kymmenentuhatta esimerkkiä väärennetystä tokenizeristamme,

475
00:34:32,856 --> 00:34:39,564
joka on JOIN-kysely joukosta "A":ita ja joitain osoittimia, kuten p64_simple_create.

476
00:34:40,044 --> 00:34:47,601
Ja bileet jatkuvat, koska p64_simple_create on itse asiassa peräisin u64_simple_createsta, oikein,

477
00:34:47,601 --> 00:34:51,218
käyttäen osoittimenpakkauskykyjämme.

478
00:34:51,218 --> 00:34:54,646
Ja tämä on kuin maatuska-nukke,

479
00:34:54,646 --> 00:35:02,059
koska sinulla on u64_simple_create, joka on peräisin libsqlite_basesta plus joistakin vakioista.

480
00:35:02,059 --> 00:35:06,573
Ja tämä menee takaisin purkamattomaan vuotoversioon,

481
00:35:06,573 --> 00:35:07,792
miinus joitain vakioita.

482
00:35:07,792 --> 00:35:12,764
Joten jälleen kerran käytämme osoitinlaskentakykyjämme.

483
00:35:13,354 --> 00:35:18,485
Voimme jatkaa u64_leak:illa, joka on peräisin lähes alkuperäisestä vuodosta.

484
00:35:18,485 --> 00:35:21,802
Ja me päätämme näyttämällä,

485
00:35:21,802 --> 00:35:27,869
kuinka vuoto on itse asiassa peräisin alkuperäisestä haavoittuvuudesta käyttäen fts3_tokenizeria.

486
00:35:27,869 --> 00:35:33,350
Ja tämä oli vain yksi kolmesta QOP-ketjusta, joita käytimme tässä hyökkäyksessä.

487
00:35:33,350 --> 00:35:38,533
Ja tällä hetkellä joka kerta, kun kuvaan tätä hyökkäystä, tämä on miltä minä varmasti näytän.

488
00:35:38,533 --> 00:35:41,443
Ja ollakseni rehellinen, tämä on juurikin mitä tunnen.

489
00:35:41,443 --> 00:35:44,721
Mutta onneksi teidän ei tarvitse näyttää tai tuntea samalta kuin minä,

490
00:35:44,721 --> 00:35:49,892
koska loimme QOP.py:n, ja se on saatavilla Checkpoint Researchin GitHubissa.

491
00:35:49,892 --> 00:35:56,825
Ja yhtäkkiä nämä hullun pitkät ketjut voidaan luoda neljällä helpolla Python-rivillä.

492
00:35:56,825 --> 00:35:59,818
Ja tuntuu pwntoolsilta, jos olet perehtynyt siihen,

493
00:35:59,818 --> 00:36:04,757
joten voit mennä eteenpäin ja leikkiä sillä etkä näytä hullulta lavalla.

494
00:36:05,377 --> 00:36:07,751
Siirrymme ensimmäiseen demoomme.

495
00:36:07,751 --> 00:36:12,684
Ownaamme salasanan varastavaa taustapalvelinta, joka toimii uusimmalla PHP 7:llä.

496
00:36:12,684 --> 00:36:16,983
Tietenkin tämä on malli, jonka loimme vuotaneista lähteistä,

497
00:36:16,983 --> 00:36:20,354
ja näet kaikki tartunnan saaneet uhrit

498
00:36:24,535 --> 00:36:25,295
Coolia

499
00:36:25,295 --> 00:36:28,245
Nyt yritämme mennä web-shelliin, p.php:hen.

500
00:36:28,765 --> 00:36:31,871
Tietenkään sitä ei vielä ole olemassa, saamme 404.

501
00:36:32,239 --> 00:36:34,878
Siirrymme hyökkääjän tietokoneelle.

502
00:36:34,878 --> 00:36:37,524
Näemme täällä kaksi skriptiä.

503
00:36:37,524 --> 00:36:43,650
Ensin käytämme QOP.py:ä, joka luo ilkeämielisen tietokannan.

504
00:36:43,650 --> 00:36:46,510
Katsotaanpa, tietokanta luotiin.

505
00:36:46,510 --> 00:36:49,149
Nyt emuloimme saastuttamisen.

506
00:36:49,149 --> 00:36:52,537
Aloitamme lähettämällä ilkeämielisen tietokantamme C2-palvelimelle

507
00:36:52,537 --> 00:36:54,939
kuin olisimme tartunnan saaneet salasanavarkaan kautta.

508
00:36:54,939 --> 00:37:00,078
Koska tämä prosessi vie hieman aikaa, voimme tarkastella kaikkia hienoja DDL-lauseita, oikein?

509
00:37:00,078 --> 00:37:05,059
Näet siis, että aloitimme jonkin bin-vuodon ja heap-vuodon kanssa ja sitten purimme ne.

510
00:37:05,059 --> 00:37:11,623
Ja aivan lopussa voit nähdä, että ohjelmamme luo yksinkertaisen webshellin p.php:lle.

511
00:37:11,623 --> 00:37:15,019
Ja tämä on sama sivu, jota juuri yritimme tavoittaa.

512
00:37:15,019 --> 00:37:21,784
Joten toivottavasti, joo - hienoa, se on tehty.

513
00:37:21,784 --> 00:37:26,004
Nyt palaamme salasanavarkaan back-endiin.

514
00:37:26,004 --> 00:37:28,157
Menemme p.php:hen ja saamme vastauksen 200.

515
00:37:28,157 --> 00:37:34,006
Nyt suoritamme jotain koodia siinä. whoami. www-data.

516
00:37:34,006 --> 00:37:37,174
Ja ilmeisesti meidän täytyy mennä /etc/passwordiin.

517
00:37:39,994 --> 00:37:41,193
Jippii.

518
00:37:42,253 --> 00:37:50,683
[Yleisö taputtaa]

519
00:37:50,683 --> 00:37:55,304
Joten mitä juuri tapahtui, on se, että osoitimme,

520
00:37:55,304 --> 00:38:00,315
että annetun kyselyn avulla ilkeämielisessä tietokannassa,

521
00:38:00,315 --> 00:38:04,004
voimme suorittaa koodia kyselyprosessissa.

522
00:38:04,004 --> 00:38:07,199
Nyt, kun otetaan huomioon, että SQLite on niin suosittu,

523
00:38:07,199 --> 00:38:11,344
tämä todella avaa oven laajalle valikoimalle hyökkäyksiä.

524
00:38:11,344 --> 00:38:15,878
Tutkitaan toista täysin erilaista käyttötapaa. Joka on täysin erilainen

525
00:38:15,878 --> 00:38:20,252
Seuraava kohde on iOS pysyvyys.

526
00:38:21,462 --> 00:38:27,433
iOS käyttää SQLiteä laajalti ja pysyvyyden saavuttaminen on todella vaikeaa,

527
00:38:27,433 --> 00:38:32,322
koska kaikkien suoritettavien tiedostojen on oltava allekirjoitettuja.

528
00:38:32,322 --> 00:38:36,478
Silti SQLite-tietokantoja ei ole allekirjoitettu, eikö niin, ne ovat vain dataa.

529
00:38:36,478 --> 00:38:38,346
Niitä ei tarvitse allekirjoittaa.

530
00:38:38,346 --> 00:38:43,259
Ja iOS ja MacOS ovat molemmat käännetty käyttäen ENABLE_FTS3_TOKENIZER:ia.

531
00:38:43,259 --> 00:38:45,507
Se on se vaarallinen käännöshetken lippu.

532
00:38:45,507 --> 00:38:50,581
Suunnitelmani on saada koodin suoritus uudelleenkäynnistyksen

533
00:38:50,581 --> 00:38:53,912
jälkeen korvaamalla mielivaltainen SQLite-tietokanta.

534
00:38:53,912 --> 00:39:01,160
Tämän saavuttamiseksi aion kohdistaa hyökkäyksen "AddressBook.sqlite" -nimiseen yhteystietokantaan.

535
00:39:01,160 --> 00:39:05,506
Alkuperäisessä tietokannassa on kaksi taulua,

536
00:39:05,506 --> 00:39:09,050
joilla ei ole merkittävää merkitystä, vaan ne ovat esimerkkejä.

537
00:39:09,050 --> 00:39:16,831
Aion luoda haitallisen yhteystietokannan, ja aloitan kahdella haitallisella DDL-lausekkeella,

538
00:39:16,831 --> 00:39:19,227
jotka ovat teille jo tuttuja.

539
00:39:19,227 --> 00:39:24,696
Ensin korvaamme oletustokenizerin "simple" joukolla "A":ita.

540
00:39:24,816 --> 00:39:31,117
Sitten toinen DDL-lauseke toteuttaa tämän haitallisen laukaisimen,

541
00:39:31,117 --> 00:39:35,387
joten se kaataa ohjelman, koska joka kerta, kun luodaan virtuaalitaulumoduuli,

542
00:39:35,387 --> 00:39:39,341
joku yrittää mennä tokenizerin rakentajan luokse.

543
00:39:39,341 --> 00:39:41,094
Joten se kaatuu.

544
00:39:41,094 --> 00:39:46,584
Seuraavaksi käyn läpi jokaisen alkuperäisen taulun

545
00:39:46,584 --> 00:39:50,462
ja kirjoitan ne uudelleen käyttäen kyselykaappauksen tekniikkaa.

546
00:39:50,462 --> 00:39:53,890
Sen sijaan että käytämme odotettuja sarakkeita,

547
00:39:53,890 --> 00:39:58,895
ohjaamme suorituksen ylikirjoituslauseeseen ja kaatumislauseeseen.

548
00:39:58,895 --> 00:40:01,740
Teimme sen yhdelle taululle, teemme sen myös muille.

549
00:40:02,503 --> 00:40:06,218
Nyt käynnistämme uudelleen ja voilà,

550
00:40:06,218 --> 00:40:09,822
saamme seuraavan CVE:n ja turvallinen käynnistys ohitettiin.

551
00:40:09,822 --> 00:40:12,168
Ja jos kiinnität huomiota tarkasti, tämä on todella hienoa,

552
00:40:12,168 --> 00:40:18,088
koska näemme että kaatuminen tapahtui osoitteessa 0x414141...49.

553
00:40:18,088 --> 00:40:24,136
Tämä on juuri mitä odotimme tapahtuvan, koska tässä pitäisi olla konstruktorimme,

554
00:40:24,136 --> 00:40:28,304
kahdeksan tavua version ensimmäisen kokonaisluvun jälkeen.

555
00:40:29,064 --> 00:40:32,196
Mutta todellisuudessa tässä on enemmän. Saamme pienen bonuksen tässä.

556
00:40:32,196 --> 00:40:37,749
Koska yhteystietokanta on itse asiassa käytössä monien eri prosessien kautta.

557
00:40:37,749 --> 00:40:44,716
Joten Yhteystiedot, FaceTime, Springboard, WhatsApp, Telegram, XPCProxy ja monet muut.

558
00:40:44,716 --> 00:40:48,219
Ja monilla näistä prosesseista on enemmän oikeuksia kuin toisilla.

559
00:40:48,219 --> 00:40:52,735
Ja olemme osoittaneet, että voimme nyt suorittaa koodia prosessissa,

560
00:40:52,735 --> 00:40:54,965
joka kysyy ilkeämielistä tietokantaamme.

561
00:40:54,965 --> 00:40:58,621
Joten saimme myös oikeuksen kohottamisen tässä prosessissa.

562
00:40:58,621 --> 00:41:03,233
Tämä on todella hienoa. Ja yhteystietokannassa ei ole mitään erityistä.

563
00:41:03,233 --> 00:41:05,835
Itse asiassa mitä tahansa jaettua tietokantaa voidaan käyttää.

564
00:41:05,835 --> 00:41:08,930
Tarvitsemme vain jotain, joka on kirjoitettavissa heikolla käyttäjällä

565
00:41:08,930 --> 00:41:15,570
ja jota vahvempi käyttäjä sitten kysyy. Ja ilmeisesti kaikki nämä tekniikat

566
00:41:15,570 --> 00:41:18,563
ja virheet ilmoitettiin Applelle, ja ne kaikki on korjattu.

567
00:41:18,563 --> 00:41:21,832
Ja tässä ovat CVE:t, jos haluat lukea siitä myöhemmin.

568
00:41:22,102 --> 00:41:27,423
Nyt, ynnätäkseni asioita, jos haluat oppia jotain tästä esityksestä,

569
00:41:27,423 --> 00:41:33,371
en halua sen olevan hullua SQL-voimistelua tai joukko CVE-numeroita.

570
00:41:33,371 --> 00:41:35,055
Haluan sen olevan seuraavaa.

571
00:41:35,055 --> 00:41:40,365
Tietokannan kysely ei välttämättä ole turvallista, oli kyse sitten käynnistyksen yli,

572
00:41:40,365 --> 00:41:43,185
käyttäjien välillä tai prosessien välillä,

573
00:41:43,185 --> 00:41:47,616
tietokannan kysely ei välttämättä ole turvallista kyselyn kaappauksen vuoksi.

574
00:41:47,616 --> 00:41:51,307
Ja nyt, kun on kyse kyselyjen kaappauksesta ja kyselykeskeisestä ohjelmoinnista,

575
00:41:51,307 --> 00:41:57,478
nämä muistin korruptiot, joita voimme laukaista, voidaan todella hyödyntää luotettavasti pelkällä SQL:llä.

576
00:41:57,478 --> 00:42:00,758
Emme tarvitse enää JavaScriptiä. Emme tarvitse WebSQL:ää.

577
00:42:00,758 --> 00:42:04,827
Ja uskomme todella, että tämä on vain jäävuoren huippu.

578
00:42:04,827 --> 00:42:07,370
Tähän mennessä SQLite on ollut erittäin suosittu,

579
00:42:07,370 --> 00:42:12,842
mutta sitä on arvioitu vain WebSQL:n kapealta alueelta,

580
00:42:12,842 --> 00:42:19,319
ja vaikka selaimen pwnaus on jännittävää, SQLite:lla on paljon enemmän potentiaalia.

581
00:42:19,319 --> 00:42:24,347
Meillä on siis joitain ajatuksia mahdollisesta tulevasta työstä tämän kanssa.

582
00:42:24,717 --> 00:42:31,070
Ilmeisesti todella hienoa olisi laajentaa primitiivejämme joitain vahvempia primitiivejä kohti, oikein.

583
00:42:31,070 --> 00:42:35,607
Haluamme saada asioita, kuten absoluuttinen luku- ja kirjoituskyky.

584
00:42:35,607 --> 00:42:40,851
Ja minun hatara POC-hyökkäykseni oli melko typerä,

585
00:42:40,851 --> 00:42:44,371
koska siinä oli paljon vakioita, kuten olette nähneet,

586
00:42:44,371 --> 00:42:49,026
mutta itse asiassa jos käytät SQLite:n sisäistä toimintoa,

587
00:42:49,026 --> 00:42:52,967
jos hyökkäyksen aikana käytät funktiota kuten sqlite3_version(),

588
00:42:52,967 --> 00:42:57,316
voit kysyä tulkilta, mikä versio sinulla on, millä käännösvalinnoilla se on käännetty,

589
00:42:57,316 --> 00:43:00,824
voit dynaamisesti rakentaa näitä QOP-ketjuja

590
00:43:00,824 --> 00:43:06,591
ja kohdistaa ne tiettyyn kohdeympäristöön, jota hyökkäät.

591
00:43:06,591 --> 00:43:09,792
Itse asiassa hyödyntämällä sitä tosiasiaa, että hyökkäyksemme on tietokanta,

592
00:43:09,792 --> 00:43:14,140
voimme luoda tämän todella coolin hyökkäyspolyglotin, ja ajattelemme,

593
00:43:14,140 --> 00:43:18,903
että näitä tekniikoita voidaan käyttää oikeuksien kohottamiseen monissa tilanteissa,

594
00:43:18,903 --> 00:43:22,404
koska kehittäjät eivät koskaan ajatelleet,

595
00:43:22,404 --> 00:43:27,529
että nyt voimme ottaa minkä tahansa tietokannan, jota heikko käyttäjä voi kirjoittaa,

596
00:43:27,529 --> 00:43:32,906
ja jota vahva käyttäjä voi kysyä, ja yhtäkkiä voimme yrittää kohottaa oikeuksiamme.

597
00:43:33,236 --> 00:43:38,858
Toisaalta olisi todella mielenkiintoista huomata, että monet niistä primitiiveistä,

598
00:43:38,858 --> 00:43:42,194
joita olen teille näyttänyt, eivät ole yksinomaan SQLite:n omaisuutta, eikö niin?

599
00:43:42,194 --> 00:43:45,839
Osoitinpakkaus ja -purku sekä heap spraying

600
00:43:45,839 --> 00:43:48,800
ja kaikki nämä asiat eivät ole yksinomaan SQLite:n omaisuutta.

601
00:43:48,800 --> 00:43:51,945
Olisi todella mielenkiintoista ottaa nämä primitiivit ja nähdä,

602
00:43:51,945 --> 00:43:58,939
voimmeko mennä eteenpäin ja hyödyntää muita muistin korruption bugia eri tietokanta-moottoreissa.

603
00:44:00,109 --> 00:44:01,419
Kiitos paljon.

604
00:44:02,248 --> 00:44:08,858
[Yleisö taputtaa]

605
00:44:09,766 --> 00:44:11,973
Omer Gull, kiitos paljon.

606
00:44:11,973 --> 00:44:14,425
Siinä oli paljon aikaa kysymyksille.

607
00:44:14,425 --> 00:44:17,301
Meillä on kolme mikrofonia täällä salissa:

608
00:44:17,301 --> 00:44:19,460
Numero yksi, Numero kaksi ja Numero kolme.

609
00:44:19,460 --> 00:44:22,153
Jos sinulla on kysymyksiä, ole hyvä ja jonota.

610
00:44:22,153 --> 00:44:24,774
Onko meillä joitakin kysymyksiä verkosta?

611
00:44:28,220 --> 00:44:29,560
Ei ole. Ookei.

612
00:44:29,560 --> 00:44:32,016
Aloittakaamme sitten mikrofonista numero kaksi.

613
00:44:32,016 --> 00:44:39,442
Joo. Kysymys koskee sitä "CREATE-jotakin" kaappaamista.

614
00:44:39,442 --> 00:44:44,147
Mainitsit, että alussa tutkimus oletti,

615
00:44:44,147 --> 00:44:49,656
että CREATE oli ensimmäinen tarkistusjärjestys

616
00:44:49,656 --> 00:44:55,474
ja sitten välilyönti CREATE-sanalla ja sen jälkeen se voisi luoda kaikki muut asiat.

617
00:44:55,474 --> 00:44:59,690
Nyt kysymykseni on: Jos se muuttui raporttisi jälkeen,

618
00:44:59,690 --> 00:45:08,233
koska tämä vaikuttaa tavalta altistaa suurempi hyökkäyspinta kuin useimmat muut bugit.

619
00:45:08,233 --> 00:45:09,779
Joten haluaisin tietää, jos he muuttivat sitä.

620
00:45:09,779 --> 00:45:14,102
Ja mitä oli lopulta se lieventäminen, jos sitä oli?

621
00:45:14,102 --> 00:45:19,078
Joo. Niin, meidän escalate-henkilöt ovat enemmän huolissaan tiettyjen virheiden

622
00:45:19,078 --> 00:45:21,462
kuin hyökkäystekniikoiden suhteen.

623
00:45:21,462 --> 00:45:23,976
Tämä on todella surullista, koska tiedämme kaikki,

624
00:45:23,976 --> 00:45:26,688
että virheet voidaan korjata, mutta hyökkäystekniikat jäävät käyttöön.

625
00:45:26,688 --> 00:45:29,470
Joten ei, he eivät muuttaneet tätä tarkistusta.

626
00:45:29,470 --> 00:45:36,735
Itse asiassa tämä "create "-validoinnin lisäys tehtiin vasta äskettäin.

627
00:45:36,735 --> 00:45:40,043
Sitä ennen pystyit käyttämään mitä tahansa DDL-lauseketta haluat.

628
00:45:40,043 --> 00:45:42,915
Joten tilanne ei ole todella hyvä siellä.

629
00:45:42,915 --> 00:45:45,167
Hyvä heille ja onnea tulevaisuudelle.

630
00:45:45,787 --> 00:45:46,738
Ja siinä oli kysymys.

631
00:45:48,030 --> 00:45:50,667
Okei. Sitten siirrymme mikrofoni ykköseen, kiitos.

632
00:45:50,667 --> 00:45:56,205
Oletko ehkä vahingossa hyökännyt palvelimelle, jota käytetään salasanan varastamiseen?

633
00:45:56,205 --> 00:45:58,143
Ei, tietenkään en tekisi niin.

634
00:45:58,143 --> 00:46:00,171
En hyökkäisi kenenkään kimppuun.

635
00:46:00,171 --> 00:46:03,968
Tämä on vain meidän laboratoriossamme POC:na. Okei.

636
00:46:03,968 --> 00:46:04,963
Kiitos.

637
00:46:04,963 --> 00:46:08,004
Salasanasi ovat turvassa varkailta.

638
00:46:08,074 --> 00:46:10,154
[Naurua] . Noniin

639
00:46:10,154 --> 00:46:10,973
Kukaan ei enää jonota.

640
00:46:10,973 --> 00:46:14,894
Onko meillä kysymyksiä verkosta? Ei mitään siellä.

641
00:46:14,894 --> 00:46:15,622
No, tästä lähdetään.

642
00:46:15,622 --> 00:46:16,122
Kiitos.

643
00:46:16,122 --> 00:46:17,232
Omer Gull, kiitos paljon.

644
00:46:17,232 --> 00:46:19,842
[Yleisö taputtaa]

645
00:46:22,237 --> 00:46:31,641
[Translated by Jouko Voutilainen (KYBS2001 course assignment at JYU.FI)]