WEBVTT

00:00:00.782 --> 00:00:05.786
[Translated by Jouko Voutilainen (KYBS2001 course assignment at JYU.FI)]

00:00:18.231 --> 00:00:29.299
Vasemmallani on Omer Gull, ja hän puhuu meille aiheesta "SELECT code_execution FROM * USING SQLite".

00:00:29.299 --> 00:00:33.381
Omer, Omer Gull, sinun esityksesi, sinun lavasi, pidä hauskaa!

00:00:33.381 --> 00:00:34.728
Kiitos. Kiitos.

00:00:34.728 --> 00:00:39.233
[Yleisö taputtaa]

00:00:39.259 --> 00:00:40.459
Hei kaikille.

00:00:40.459 --> 00:00:46.329
Tervetuloa esitykseeni "SELECT code_execution FROM * USING SQLite",

00:00:46.329 --> 00:00:51.849
jossa saavutamme koodin suorittamisen (code execution) haavoittuvaisia SQLite-tietokantoja käyttäen.

00:00:52.113 --> 00:00:55.850
Nimeni on Omer Gull. Olen haavoittuvuuksien tutkija Tel Avivista.

00:00:55.850 --> 00:01:00.905
Olen työskennellyt Check Point Researchissa viimeiset kolme vuotta

00:01:00.905 --> 00:01:05.346
ja olen äskettäin siirtynyt uuteen startupiin nimeltä Hunters.AI.

00:01:05.738 --> 00:01:07.554
Agendamme tänään:

00:01:07.554 --> 00:01:12.332
Aloitamme pienellä motivaatiolla ja taustatarinan kertomisella tästä tutkimuksesta.

00:01:12.332 --> 00:01:21.100
Sen jälkeen meillä on lyhyt SQLite-johdanto ja tutkimme haitallisten tietokantojen hyökkäyspintaa.

00:01:21.485 --> 00:01:28.559
Käsittelemme myös aiempaa työtä SQLite-hyödyntämisessä ja mietimme,

00:01:28.559 --> 00:01:33.948
miten käyttää muistin korruptiohäiriöitä pelkästään SQL:n avulla.

00:01:33.948 --> 00:01:41.007
Sitten esittelemme oman innovatiivisen tekniikkamme nimeltä "Query Oriented Programming" tai QOP,

00:01:41.007 --> 00:01:44.240
ja demonstroimme sitä muutamassa esimerkissä.

00:01:44.320 --> 00:01:50.513
Käärimme asiat yhteen tulevaisuuden mahdollisuuksien ja johtopäätösten kanssa.

00:01:50.598 --> 00:01:55.415
Motivaatio tälle tutkimukselle on melko ilmeinen.

00:01:55.415 --> 00:02:00.346
SQLite on yksi eniten käytetyistä ohjelmistoista.

00:02:00.346 --> 00:02:04.527
Olipa kyse PHP 5:stä, PHP 7:stä, Androidista, iOS:stä,

00:02:04.527 --> 00:02:08.009
Mac OS:stä, se on nyt sisäänrakennettu Windows 10:een.

00:02:08.009 --> 00:02:10.947
Sitä on Firefoxissa ja Chromessa.

00:02:11.517 --> 00:02:13.704
Tämä luettelo voisi jatkua loputtomiin.

00:02:13.704 --> 00:02:16.923
Kuitenkin SQLite-tietokannan kyselyä pidetään

00:02:16.923 --> 00:02:21.044
turvallisena. Toivottavasti tämän puheen lopussa tajuat,

00:02:21.044 --> 00:02:23.855
miksi tämä ei välttämättä ole totta.

00:02:24.410 --> 00:02:27.917
Kaikki alkoi salasanavarkaista,

00:02:27.917 --> 00:02:35.276
mikä on melko outoa, ja niitä on paljon, paljon vapaana, mutta tarina on yleensä sama.

00:02:35.567 --> 00:02:38.601
Ensinnäkin tietokone saa tartunnan.

00:02:39.311 --> 00:02:42.500
Sitten haittaohjelma kerää tallennettuja käyttäjätunnuksia,

00:02:42.500 --> 00:02:45.453
sillä niitä on tallennettuna eri asiakasohjelmistoihin.

00:02:45.642 --> 00:02:50.782
Jotkut näistä asiakasohjelmista tallentavat salaisuutesi SQLite-tietokantoihin.

00:02:51.434 --> 00:02:59.934
Haittaohjelma lähettää SQLite-tietokantoja C2-palvelimelle, jossa salaisuudet
poimitaan

00:02:59.934 --> 00:03:02.295
ja tallennetaan yhteiseen tietokantaan

00:03:02.295 --> 00:03:03.875
muun saaliin kanssa.

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.

00:03:12.613 --> 00:03:20.123
Ajattelimme: "Nämä kaverit vain keräävät tietokantojamme ja parsivat ne omaan back-endiinsä.

00:03:20.333 --> 00:03:27.446
Voimmeko todella hyödyntää luotettamattoman tietokannan latausta ja kyselyä?"

00:03:27.446 --> 00:03:31.215
Ja jos voimme, sillä voisi olla paljon suuremmat vaikutukset,

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.

00:03:42.093 --> 00:03:50.088
SQLite. Toisin kuin useimmat SQL-tietokannat, SQLite:llä ei ole asiakas-palvelinarkkitehtuuria.

00:03:50.088 --> 00:03:55.527
Sen sijaan se lukee ja kirjoittaa tiedostoja suoraan tiedostojärjestelmään.

00:03:55.527 --> 00:04:02.258
Joten sinulla on yksi täydellinen tietokanta, jossa on useita taulukoita, indeksejä, laukaisimia ja näkymiä,

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.

00:04:12.144 --> 00:04:17.074
Tämä on palanen koodia erittäin tunnetusta salasanavarkaasta,

00:04:17.074 --> 00:04:23.388
ja meillä on kaksi tärkeintä kiinnostuksen kohdetta: Ensinnäkin meillä on sqlite3_open,

00:04:23.388 --> 00:04:26.942
jossa potentiaalisesti haitallisen tietokanta ladataan,

00:04:26.942 --> 00:04:29.492
ja jotain parsimista tapahtuu.

00:04:29.492 --> 00:04:34.362
Ja ilmeisesti meillä on itse kysely. SELECT-lauseke.

00:04:34.362 --> 00:04:37.427
Huomaa kuitenkin, että meillä ei ole hallintaa siitä lausekkeesta.

00:04:37.427 --> 00:04:39.780
Se on kovakoodattu kohteeseemme.

00:04:39.780 --> 00:04:42.908
Se yrittää poimia salaisuudet tietokannastamme.

00:04:42.908 --> 00:04:48.990
Mutta me hallitsemme sisältöä, joten meillä voi olla vaikutusta siihen, mitä siellä tapahtuu.

00:04:49.864 --> 00:04:53.278
Ensimmäinen asia on sqlite3_open,

00:04:53.278 --> 00:04:56.399
joka on vain joukko asetus- ja kokoonpanokoodia.

00:04:56.399 --> 00:05:01.692
Seuraavaksi siirrymme suoraviivaiseen otsikkotiedoston parsimiseen,

00:05:01.692 --> 00:05:05.425
otsikkotiedosto itse ei ole kovin pitkä, vain 100 tavua.

00:05:05.425 --> 00:05:09.445
Kolmanneksi, se on jo fuzzattu kuoliaaksi AFL:llä.

00:05:09.445 --> 00:05:13.776
Joten se ei ehkä ole kovin lupaava polku jatkaa.

00:05:14.476 --> 00:05:18.939
Mutta Sqlite3_query saattaa olla hieman mielenkiintoisempi,

00:05:18.939 --> 00:05:27.178
koska SQLite:n tekijän mukaan "SELECT-lauseke on SQL-kielen monimutkaisin käsky".

00:05:28.138 --> 00:05:33.788
Voit tietää, että taustalla SQLite on virtuaalikone.

00:05:33.788 --> 00:05:39.751
Joten jokainen kysely on ensin käännettävä joksikin tavukoodin muotoon.

00:05:39.751 --> 00:05:42.968
Tätä kutsutaan myös valmisteluvaiheeksi.

00:05:43.278 --> 00:05:46.851
Joten sqlite3_prepare kulkee ja laajentaa tuon kyselyn.

00:05:46.851 --> 00:05:50.174
Esimerkiksi joka kerta, kun valitset asteriskin,

00:05:50.174 --> 00:05:53.683
se kirjoittaa tämän asteriskin kaikkien sarakkeiden nimiksi.

00:05:56.003 --> 00:05:59.758
Joten sqlite3LocateTable() varmistaa,

00:05:59.758 --> 00:06:06.454
että kaikki kyselyssä käytetyt taulut ja sarakkeet todella olemassa ja sijaitsevat muistissa.

00:06:06.454 --> 00:06:08.412
Mistä se löytää ne?

00:06:08.412 --> 00:06:12.921
Jokaisella SQLite-tietokannalla on taulu nimeltään sqlite_master,

00:06:12.921 --> 00:06:17.980
joka määrittelee tietokannan skeeman.

00:06:17.980 --> 00:06:19.990
Ja tämä on sen rakenne.

00:06:19.990 --> 00:06:23.527
Joten jokaiselle tietokannan objektille sinulla on merkintä,

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.

00:06:33.019 --> 00:06:38.550
Ja SQL on itse asiassa DDL, joka kuvaa objektia.

00:06:38.975 --> 00:06:46.016
DDL tarkoittaa datamäärittelykieltä, ja sitä voidaan verrata C-kielen otsikkotiedostoihin.

00:06:46.016 --> 00:06:52.881
Ne määrittelevät tietokannan objektien rakenteen, nimet ja tyypit.

00:06:52.881 --> 00:06:57.227
Lisäksi ne näkyvät selkokielisinä tiedostossa.

00:06:57.272 --> 00:07:05.264
Annan esimerkin. Avasin SQLite-tulkin, loin taulun ja lisäsin siihen arvoja.

00:07:05.264 --> 00:07:10.003
Sitten lopetin tulkin ja nyt avaamme tiedoston heksadesimaalimuodossa.

00:07:10.003 --> 00:07:18.260
Voit nähdä keltaisella korostettuna näkyvän DDL-lauseke, joka on osa pääskeemaa.

00:07:18.260 --> 00:07:21.004
Alhaalla voit myös nähdä arvot.

00:07:21.439 --> 00:07:23.900
Palataan kyselyn valmisteluun.

00:07:24.382 --> 00:07:33.219
Meillä on sqlite3LocateTable, joka yrittää löytää taulun rakenteen, jota haluamme kysellä.

00:07:33.219 --> 00:07:39.030
Se lukee skeeman sqlite_masterista, jonka juuri kuvailimme.

00:07:39.030 --> 00:07:41.534
Ja jos se tekee sen ensimmäistä kertaa,

00:07:41.534 --> 00:07:47.097
sillä on joitakin takaisinkutsufunktioita jokaiselle näistä DDL-lausekkeista.

00:07:47.097 --> 00:07:56.723
Takaisinkutsufunktio validoi DDL:n ja rakentaa sen jälkeen sisäiset rakenteet kyseisestä objektista.

00:07:56.723 --> 00:08:00.944
Sitten ajattelimme DDL:n paikkaamista.

00:08:00.944 --> 00:08:05.941
Entä jos vain korvaamme SQL-kyselyn DDL:ssä?

00:08:05.941 --> 00:08:09.036
Tämä johtaa kuitenkin pieneen ongelmaan.

00:08:09.036 --> 00:08:13.883
Tämä on aiemmin mainitsemani takaisinkutsufunktio, ja kuten näet,

00:08:13.883 --> 00:08:23.158
DDL tarkistetaan ensin aloittavan "create ":lla. Vasta sen jälkeen valmistelu jatkuu.

00:08:23.158 --> 00:08:25.249
Tämä on ehdottomasti rajoitus, eikö niin?

00:08:25.249 --> 00:08:27.981
Meidän DDL:n on aloitettava "create ":lla.

00:08:27.981 --> 00:08:31.750
Mutta tämä jättää jonkin verran tilaa joustavuudelle,

00:08:31.750 --> 00:08:37.216
sillä SQLite-dokumentaation perusteella monia asioita voidaan luoda.

00:08:37.216 --> 00:08:42.154
Voimme luoda indeksejä, taulukoita, laukaisimia, näkymiä ja jotain,

00:08:42.154 --> 00:08:45.874
mitä emme vielä täysin ymmärrä, nimeltä virtuaaliset taulukot.

00:08:45.874 --> 00:08:54.556
Niinpä ajattelimme "CREATE VIEW":ta, koska näkymä on vain esipakattu SELECT-lauseke,

00:08:54.556 --> 00:08:58.637
ja näkymiä kysytään hyvin samalla tavalla kuin taulukoita.

00:08:58.637 --> 00:09:05.669
Joten, taulukosta sarakkeen valitseminen on semanttisesti sama asia kuin sarakkeen valitseminen näkymästä.

00:09:06.509 --> 00:09:10.264
Sitten, kun ajattelimme kyselyn kaappaamisen käsitettä.

00:09:10.264 --> 00:09:15.338
Aiomme paikata sqlite_master DDL:n näkymillä taulukoiden sijaan.

00:09:15.338 --> 00:09:20.074
Nyt paikatut näkymät voivat olla mitä tahansa SELECT-alilauseketta, jonka haluamme.

00:09:20.074 --> 00:09:25.506
Ja nyt tällä alilausekkeella voin yhtäkkiä käyttää SQLite-tulkintaa.

00:09:25.506 --> 00:09:30.986
Ja tämä on valtava askel eteenpäin! Muutimme juuri hallitsemattoman kyselyn joksikin,

00:09:30.986 --> 00:09:32.997
jota voimme jonkin verran hallita.

00:09:32.997 --> 00:09:36.775
Joten anna minun näyttää sinulle esimerkki kyselyn kaappaamisesta.

00:09:36.775 --> 00:09:41.138
Sanotaan, että joissakin alkuperäisissä tietokannoissa oli yksi taulu,

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.

00:09:46.535 --> 00:09:51.616
Joten ilmeisesti mikä tahansa kohdesovellus yrittäisi kysyä sitä seuraavasti:

00:09:51.616 --> 00:09:55.587
Se vain yrittäisi valita nämä sarakkeet taulukosta, eikö niin.

00:09:55.587 --> 00:09:59.197
Mutta seuraava näkymä voi todella kaapata tämän kyselyn.

00:09:59.197 --> 00:10:04.104
Luon näkymän, se on juuri samanniminen ja sillä on sama määrä sarakkeita,

00:10:04.104 --> 00:10:07.225
ja jokainen sarake on nimetty samalla tavalla, ja voit nähdä,

00:10:07.225 --> 00:10:10.252
että nyt jokainen sarake voi sisältää minkä tahansa alilausekkeen,

00:10:10.252 --> 00:10:13.789
jonka haluan, korostettuna sinisellä alareunassa.

00:10:13.789 --> 00:10:16.509
Joten anna minun näyttää sinulle käytännön esimerkki siitä.

00:10:16.509 --> 00:10:20.688
Tässä olen luonut näkymän nimeltä "dummy" col A ja col B:llä,

00:10:20.688 --> 00:10:26.308
ja ensimmäinen sarake käyttää sqlite_version()-funktiota, ja se on sisäänrakennettu funktio,

00:10:26.308 --> 00:10:29.136
joka palauttaa SQLite-version, ilmeisesti.

00:10:29.356 --> 00:10:35.496
Toinen sarake käyttää SQLite:n omaa toteutusta printf:stä.

00:10:35.496 --> 00:10:39.650
Juuri näin, niillä on kaikki nämä todella yllättävät ominaisuudet ja kyvyt.

00:10:39.650 --> 00:10:44.013
Joten katsotaan sitä nyt oletetusti - kohdesivulta.

00:10:44.013 --> 00:10:47.993
Joten kuka tahansa, joka yrittää valita näistä sarakkeista,

00:10:47.993 --> 00:10:50.971
suorittaa yhtäkkiä meidän funktioitamme.

00:10:50.971 --> 00:10:56.628
Vasemmalla voit nähdä SQLite-version, ja oikealla voit nähdä printf:n,

00:10:56.628 --> 00:11:01.806
joka suoritettiin kohdesivulla. Joten taas tämä on valtava edistysaskel.

00:11:01.806 --> 00:11:05.509
Me saavutimme juuri jonkin verran kontrollia sen kyselyn yli, eikö niin?

00:11:05.509 --> 00:11:10.018
Ja kysymys kuuluu, mitä voimme tehdä tällä kontrollilla.

00:11:10.018 --> 00:11:13.257
Onko SQLite:llä mitään järjestelmäkomentoja?

00:11:13.257 --> 00:11:18.454
Voimmeko ehkä lukea ja kirjoittaa jotain muita tiedostoja tiedostojärjestelmässä?

00:11:21.274 --> 00:11:26.460
Joten tämä oli hyvä kohta pysähtyä ja tarkastella jo tehtyä työtä alalla,

00:11:26.460 --> 00:11:29.220
koska ilmeisesti emme ole ensimmäiset,

00:11:29.220 --> 00:11:34.117
jotka ovat huomanneet SQLite:n valtavan potentiaalin hyväksikäytössä.

00:11:34.117 --> 00:11:37.765
Järkevä paikka aloittaa on SQLite-injektio,

00:11:37.765 --> 00:11:40.497
koska tämä on jonkinlainen vastaava tilanne, eikö niin?

00:11:40.497 --> 00:11:45.106
Jollakulla haitallisella on jonkinlainen kontrolli SQL-kyselyssä.

00:11:45.106 --> 00:11:50.440
Joten, on olemassa muutama tunnettu temppu SQL-injektiossa SQLite:llä.

00:11:50.440 --> 00:11:54.420
Ensimmäisellä on tekemistä toisen tietokannan liittämisen kanssa

00:11:54.420 --> 00:11:58.457
ja sen jälkeen taulun luomisen ja joitain merkkijonoja sen sisään laittamisen.

00:11:58.457 --> 00:12:03.163
Ja koska, kuten mainitsin aiemmin, jokainen tietokanta on vain tiedosto,

00:12:03.163 --> 00:12:08.200
tämä on jonkinlainen mielivaltainen tiedosto, tiedostojärjestelmässä.

00:12:08.200 --> 00:12:11.703
Kuitenkin meillä on tämä rajoitus, muistattehan, että emme voi liittää,

00:12:11.703 --> 00:12:14.776
koska DDL:n on aloitettava "CREATE"-sanalla.

00:12:15.436 --> 00:12:19.497
Toinen hieno temppu on käyttää load extension -funktiota väärin.

00:12:19.497 --> 00:12:24.995
Ja tässä voit nähdä, kuinka voit mahdollisesti ladata etä-DLL:n.

00:12:24.995 --> 00:12:26.863
Tässä tapauksessa meterpreter.dll,

00:12:26.863 --> 00:12:31.293
mutta ilmeisesti tämä erittäin vaarallinen funktio on oletuksena pois käytöstä.

00:12:31.293 --> 00:12:36.514
Joten se taas ei onnistu. Entä muistin korruptio SQLite:ssä,

00:12:36.514 --> 00:12:41.849
koska SQLite on todella monimutkainen ja se on kaikki kirjoitettu C:llä.

00:12:42.478 --> 00:12:47.343
Hänen hämmästyttävässä blogikirjoituksessaan "Virheiden löytäminen SQLite:ssä helposti",

00:12:47.343 --> 00:12:50.098
Michal Zalewski, AFL:n tekijä, kuvasi,

00:12:50.098 --> 00:12:55.635
kuinka hän löysi 22 bugia alle 30 minuutissa fuzzingilla

00:12:55.635 --> 00:12:58.246
Ja itse asiassa, sen jälkeen,

00:12:58.246 --> 00:13:01.583
kun kyseessä oli versio 3.8.10 vuonna 2015,

00:13:01.583 --> 00:13:07.306
SQLite alkoi käyttää AFL:ää osana huomattavaa testisarjaa.

00:13:07.306 --> 00:13:15.081
Nämä muistin korruptiovirheet osoittautuivat kuitenkin erittäin vaikeiksi hyödyntää ilman sopivaa ympäristöä.

00:13:15.081 --> 00:13:19.834
Turvallisuustutkimusyhteisö löysi kuitenkin pian täydellisen kohteen,

00:13:19.834 --> 00:13:22.400
ja se oli nimeltään WebSQL.

00:13:22.660 --> 00:13:28.402
Joten WebSQL on periaatteessa API tietojen tallentamiseen tietokantoihin,

00:13:28.402 --> 00:13:33.835
ja sitä kysytään JavaScriptistä, ja sillä on SQLite-tausta.

00:13:33.835 --> 00:13:37.305
Lisäksi se on saatavana Chromessa ja Safarissa.

00:13:37.305 --> 00:13:43.475
Tässä voit nähdä hyvin yksinkertaisen esimerkin siitä, miten voit käyttää WebSQL:ää JavaScriptistä.

00:13:46.525 --> 00:13:49.523
Mutta toisin sanoen, mitä täällä luulen, on se,

00:13:49.523 --> 00:13:53.248
että meillä on joitakin luottamattomia syötteitä SQLite:lle,

00:13:53.248 --> 00:13:56.992
ja se on saavutettavissa mistä tahansa Internetin verkkosivustosta

00:13:56.992 --> 00:13:59.596
kahdessa maailman suosituimmassa selaimessa.

00:13:59.596 --> 00:14:02.265
Ja yhtäkkiä nämä virheet,

00:14:02.265 --> 00:14:10.449
nämä muistin korruptiot, voidaan nyt hyödyntää JavaScript-hyväksikäytön tiedosta ja mukavuudesta.

00:14:10.499 --> 00:14:14.875
JavaScript-tulkin hyväksikäyttö, jossa olemme tulleet varsin hyviksi vuosien varrella.

00:14:14.875 --> 00:14:22.066
Joten WebSQL:stä on julkaistu useita vaikuttavia tutkimuksia,

00:14:22.066 --> 00:14:23.870
jotka vaihtelevat todella helppoista kohteista,

00:14:23.870 --> 00:14:26.933
kuten CVE-2015-7036,

00:14:26.933 --> 00:14:31.556
joka oli luottamattoman osoittimen purku fts3_tokenizer()-funktiossa,

00:14:31.556 --> 00:14:33.978
monimutkaisempiin hyökkäyksiin,

00:14:33.978 --> 00:14:42.593
kuten Blackhat 2017:ssä esitelty Chaitin-tiimin löytämä tyyppisekoittumisongelma FTS-optimoinnissa,

00:14:42.593 --> 00:14:46.225
sekä hiljattain Magellan-bugit, jotka Tencent löysi,

00:14:46.225 --> 00:14:50.842
jotka löysivät kokonaisluvun ylivuodon FTS-segmentinlukijassa.

00:14:50.842 --> 00:14:53.911
Ja jos kiinnität nyt edes hieman huomiota,

00:14:53.911 --> 00:14:57.598
niin näet mielenkiintoisen kaavan nousevan esiin.

00:14:57.598 --> 00:15:01.677
Kaikki nämä haavoittuvat funktiot alkavat FTS:llä.

00:15:01.677 --> 00:15:03.087
Joten mikä on FTS?

00:15:03.087 --> 00:15:04.573
En ole koskaan kuullut siitä.

00:15:04.573 --> 00:15:05.826
Ja kun etsin sitä Googlesta,

00:15:05.826 --> 00:15:08.063
se vain hämmensi minua vielä enemmän.

00:15:09.565 --> 00:15:10.820
Jonkin ajan kuluttua tajusin,

00:15:10.820 --> 00:15:19.104
että FTS tarkoittaa "täysi tekstihaku" ja se on jotain nimeltään virtuaalinen taulukkomoduuli,

00:15:19.104 --> 00:15:23.999
joka mahdollistaa todella hienovaraisen tekstin haun dokumenttien joukosta.

00:15:23.999 --> 00:15:27.269
Tai kuten SQLite-tekijät kuvasivat sitä,

00:15:27.269 --> 00:15:29.748
se on "kuin Google SQLite-tietokannoillesi".

00:15:29.748 --> 00:15:34.970
Joten virtuaalitaulukot mahdollistavat joitain todella hienoja toimintoja SQLite:ssa,

00:15:34.970 --> 00:15:39.574
olipa kyseessä tämä vapaa tekstin haku tai virtuaalitaulukkomoduuli nimeltään RTREE,

00:15:39.574 --> 00:15:42.652
joka tekee todella fiksua maantieteellistä indeksointia,

00:15:42.652 --> 00:15:44.922
tai virtuaalitaulukko nimeltään CSV,

00:15:44.922 --> 00:15:47.967
joka antaa sinun käsitellä tietokantaasi CSV-tiedostona.

00:15:47.967 --> 00:15:52.395
Ja näitä virtuaalitaulukoita kysytään itse asiassa ihan kuin normaaleja taulukoita.

00:15:52.395 --> 00:15:56.534
Kuitenkin taustalla tapahtuu joitain pimeitä taikoja.

00:15:56.534 --> 00:16:01.112
Ja jokaisen kyselyn jälkeen, kutsutaan jonkinlaista takaisinkutsufunktiota,

00:16:01.112 --> 00:16:05.736
joka toimii niin kutsuttua shadow-taulukkoa vastaan.

00:16:05.736 --> 00:16:09.172
Varjotaulukot olisi parasta selittää esimerkin avulla.

00:16:09.172 --> 00:16:15.774
Joten sanotaan, että luon virtuaalitaulukon käyttäen sitä FTS-virtuaalitaulukkomoduulia

00:16:15.774 --> 00:16:18.081
ja lisään siihen merkkijonon.

00:16:18.081 --> 00:16:22.974
Ilmeisesti tehokkaan haun sallimiseksi minulla täytyy olla joitain metatietoja, okei?

00:16:22.974 --> 00:16:26.823
Minun täytyy olla joitain offsetteja tai indeksejä tai merkkejä tai jotain sellaista.

00:16:26.823 --> 00:16:29.117
Ja ilmeisesti kaikki ne ovat tekstiä, eikö niin?

00:16:29.117 --> 00:16:34.037
Joten yksi virtuaalitaulukko on itse asiassa raakatekstiä,

00:16:34.037 --> 00:16:37.704
ja metatiedot tallennetaan kolmen varjoshadow-taulukon joukkoon.

00:16:37.704 --> 00:16:43.339
Joten raakateksti menisi vt_contentiin ja metatiedot menisivät vt_segmentsiin ja vt_segdiriin.

00:16:44.078 --> 00:16:49.379
Ajan myötä nämä varjotaulukot ovat liittymäpintoja,

00:16:49.379 --> 00:16:51.521
jotka siirtävät tietoa toistensa välillä.

00:16:51.521 --> 00:16:54.075
Koska metatieto tallentaa kaikki nämä osoittimet,

00:16:54.075 --> 00:16:56.528
sinun on siirrettävä ne toistensa välillä.

00:16:56.528 --> 00:16:59.464
Ja nämä liittymäpinnat osoittautuivat todella,

00:16:59.464 --> 00:17:02.083
todella luottavaisiksi luonteeltaan.

00:17:02.083 --> 00:17:06.997
Ja se tekee niistä todella otollisen maaperän bugin metsästykseen.

00:17:06.997 --> 00:17:13.433
Näytän teille nyt bugin, jonka löysin RTREE-virtuaalitaulukkomoduulista.

00:17:14.639 --> 00:17:18.841
RTREE-virtuaalitaulumoduuli on nyt saatavilla MacOS- ja iOS-laitteille,

00:17:18.841 --> 00:17:22.504
ja se on todella hieno, koska se on nyt myös osa Windows 10:ää.

00:17:22.504 --> 00:17:27.617
Ja kuten mainitsin, se tekee todella fiksua maantieteellistä indeksointia.

00:17:27.617 --> 00:17:34.032
DDL:n tulisi olla seuraava. Minkä tahansa RTREE-virtuaalitaulun tulisi alkaa "id":llä,

00:17:34.032 --> 00:17:39.448
jonka täytyy olla kokonaisluku. Sen jälkeen sinulla on joitakin X- ja Y-koordinaatteja.

00:17:39.448 --> 00:17:44.591
Joten jokainen RTREE-liitäntä odottaisi "id":n olevan kokonaisluku.

00:17:44.591 --> 00:17:48.716
Mutta jos luon virtuaalitaulun ja lisään "id":hen jotain,

00:17:48.716 --> 00:17:54.662
joka ei ole kokonaisluku, ja käytän yhtä näistä RTREE-liitännäisistä,

00:17:54.662 --> 00:17:59.150
rtreenode, näet alhaalla, että saamme tämän kaatumisen,

00:17:59.150 --> 00:18:03.328
tämän kekomuistin ulkopuolisen lukemisen.

00:18:03.328 --> 00:18:07.499
Ja tämä esimerkki on kaatuminen Windows 10:ssä.

00:18:07.499 --> 00:18:11.128
Joten se on aika hyvä. Olemme havainneet,

00:18:11.128 --> 00:18:13.978
että virtuaalitaulussa on bugeja.

00:18:13.978 --> 00:18:16.992
Ja nyt, käyttämällä kyselyn kaappaustekniikkaa,

00:18:16.992 --> 00:18:21.313
voimme yhtäkkiä laukaista nämä bugit kohteellamme,

00:18:21.313 --> 00:18:25.832
joka on salasanavaras C2, ja se kaatuu (segfault).

00:18:25.832 --> 00:18:30.050
Ja tämä on hienoa, mutta varsinaisen ohjauksen saaminen kohteestamme

00:18:30.050 --> 00:18:33.593
vaatii jonkinlaista skriptausta, eikö niin?

00:18:33.593 --> 00:18:37.003
Haluamme ohittaa ASLR:n ja tehdä kaikenlaisia hulluja asioita.

00:18:37.003 --> 00:18:39.079
Meillä ei kuitenkaan ole JavaScriptiä,

00:18:39.079 --> 00:18:43.787
meillä ei ole JavaScript-taulukoita ja muuttujia ja logiikkalauseita,

00:18:43.787 --> 00:18:50.369
kuten if ja and silmukoita ja sellaisia. Kuitenkin muistamme jostain kuulleemme,

00:18:50.369 --> 00:18:53.257
että SQL on Turing-täydellinen.

00:18:53.257 --> 00:18:58.880
Joten päätimme testata sitä hyökkäysnäkökulmasta

00:18:58.880 --> 00:19:03.622
ja aloimme luoda omaa primitiivista toivelistaa hyökkäystä varten.

00:19:03.622 --> 00:19:06.490
Joten jos se voisi luoda täyden hyökkäyksen,

00:19:06.490 --> 00:19:09.712
jossa hyödynnetään muistin korruptiobugeja pelkästään SQL:llä,

00:19:09.712 --> 00:19:11.896
mitä kyvykkyyksiä haluamme?

00:19:11.896 --> 00:19:15.208
Joten ilmeisesti ohittaaksemme ASLR:n ja nämä asiat,

00:19:15.208 --> 00:19:16.659
tarvitsemme vuodon muistista.

00:19:16.659 --> 00:19:18.777
Meidän täytyy saada tietovuoto.

00:19:18.777 --> 00:19:20.955
Jos olet tehnyt pwningia menneisyydessäsi,

00:19:20.955 --> 00:19:24.051
sinun täytyy olla tuttu todella yleisten tehtävien suhteen,

00:19:24.051 --> 00:19:29.339
kuten 64-bittisten osoittimen purkamisesta ja joitakin osoitinlaskutoimituksia, eikö niin?

00:19:29.339 --> 00:19:33.126
Koska meillä oli tietovuoto, muunnamme - luemme tämän osoittimen,

00:19:33.126 --> 00:19:35.412
ja se on little-endian, joten meidän täytyy kääntää se,

00:19:35.412 --> 00:19:38.867
ja nyt haluamme laskea, missä on libsqlite-tiedoston perusta,

00:19:38.867 --> 00:19:40.959
jotta voimme löytää ehkä lisää funktioita.

00:19:40.959 --> 00:19:43.869
Joten tarvitsemme joitakin osoitinlaskutoimituksia.

00:19:43.869 --> 00:19:48.042
Luonnollisesti, kun olemme lukeneet osoittimet ja manipuloineet niitä,

00:19:48.042 --> 00:19:52.424
haluamme pakata ne uudelleen ja kirjoittaa ne jonnekin.

00:19:52.424 --> 00:19:55.959
Yhden osoittimen kirjoittaminen ei koskaan riitä.

00:19:55.959 --> 00:19:59.370
Haluamme luoda väärennettyjä objekteja muistissa,

00:19:59.370 --> 00:20:04.514
monimutkaisempia kuin yksi osoitin. Lopuksi, haluaisimme heap sprayn,

00:20:04.514 --> 00:20:06.551
koska se voi olla todella hyödyllinen.

00:20:06.551 --> 00:20:09.317
Joten, kysymys kuuluu,

00:20:09.317 --> 00:20:13.427
voiko kaikki tämä hyödyntäminen tehdä pelkästään SQL:llä?

00:20:13.427 --> 00:20:16.075
Vastaus on "kyllä, se on mahdollista".

00:20:16.075 --> 00:20:21.231
Ja esittelen teille ylpeänä Kysely-orientoitunut ohjelmointi tai QOP.

00:20:21.231 --> 00:20:30.153
Demonstroidakseni QOP:ia hyväksikäytämme haavoittuvuutta CVE-2015-7036.

00:20:33.273 --> 00:20:34.580
Ja saatatte kysyä itseltänne:

00:20:34.580 --> 00:20:38.685
Miten neljä vuotta vanha bugi on edelleen korjaamatta?

00:20:38.685 --> 00:20:42.473
Ja tämä on hieno asia argumenttiimme.

00:20:42.473 --> 00:20:48.962
Tämä CVE koettiin vaaralliseksi vain luottamattomien Web-SQL:n suhteen.

00:20:48.962 --> 00:20:51.274
Se siis kierrettiin oikein.

00:20:51.274 --> 00:20:55.820
Se on blacklistattu ja SQL on käännetty tietyllä lipulla.

00:20:55.820 --> 00:20:59.299
Joten selkeästi selaimet eivät enää ole kääntäneet tällä lipulla.

00:20:59.299 --> 00:21:00.504
Mutta anna minun näyttää sinulle,

00:21:00.504 --> 00:21:02.362
minkä kanssa nämä liput on käännetty.

00:21:02.362 --> 00:21:04.678
Joten meillä on PHP 5 ja PHP 7,

00:21:04.678 --> 00:21:06.397
jotka ovat vastuussa suurimmasta osasta Internetiä,

00:21:06.397 --> 00:21:10.000
sekä iOS ja MacOS ja todennäköisesti niin monia muita kohteita,

00:21:10.000 --> 00:21:14.275
joita emme vain ehtineet käydä läpi.

00:21:14.275 --> 00:21:16.698
Joten selitetään hieman tätä haavoittuvuutta.

00:21:16.698 --> 00:21:19.591
Olen maininnut, että se on FTS-tokenizerissa.

00:21:19.911 --> 00:21:24.658
Joten tokenizer on vain joukko sääntöjä dokumenttien

00:21:24.658 --> 00:21:26.751
tai kyselyjen termeistä erottamiseksi.

00:21:26.751 --> 00:21:30.938
Ja oletustokenizeri, jota kutsutaan "yksinkertaiseksi",

00:21:30.938 --> 00:21:33.918
vain jakaa merkkijonot tyhjien merkkien perusteella.

00:21:33.918 --> 00:21:38.637
Kuitenkin, jos haluat, voit rekisteröidä oman mukautetun tokenizerin.

00:21:38.637 --> 00:21:42.429
Voit vain siirtää C-funktion ja oikeastaan rekisteröit

00:21:42.429 --> 00:21:47.763
tämän mukautetun tokenizerin fts3_tokenizer() -funktiolla SQL-kyselyssä.

00:21:48.793 --> 00:21:51.125
Tässä on jonkin verran asiaa, mutta sanon sen hitaasti.

00:21:51.125 --> 00:21:55.514
Siirrät riviosoittimen C-funktioon SQL-kyselyssä.

00:21:55.514 --> 00:21:57.448
Tämä on täysin mielipuolista.

00:21:57.448 --> 00:22:00.641
Rehellisesti sanottuna, vaikka olen tutkinut tätä jonkin aikaa,

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.

00:22:05.515 --> 00:22:12.663
[Yleisö taputtaa]

00:22:15.826 --> 00:22:20.277
fts3_tokenizer() on ylikuormitettu funktio,

00:22:20.277 --> 00:22:22.243
ja jos kutsut sen yhdellä argumentilla,

00:22:22.243 --> 00:22:27.303
joka on tokenizerin nimi, saat takaisin kyseisen tokenizerin osoitteen.

00:22:27.303 --> 00:22:33.760
Teemme sen hieman ihmiselle luettavammaksi käyttämällä heksadesimaalimuunnosta.

00:22:33.760 --> 00:22:38.916
Voit nyt nähdä, että saimme tietovuodon libsqlite3:een.

00:22:38.916 --> 00:22:42.970
Koska se on little-endian, meidän on käännettävä se ympäri,

00:22:42.970 --> 00:22:44.755
mutta tämä on jo melko hienoa.

00:22:44.755 --> 00:22:48.326
Jos kutsut fts3_tokenizer():ia kahdella argumentilla,

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..

00:22:55.022 --> 00:22:58.010
voit kirjoittaa kyseisen tokenizerin osoitteen uudelleen.

00:22:58.010 --> 00:23:01.748
Joten aina kun joku yrittää käyttää virtuaalitaulua

00:23:01.748 --> 00:23:08.188
ja se instantisoi oletusarvoisen tokenizerin, se kaatuu.

00:23:08.188 --> 00:23:10.739
Tämä on melko hämmästyttävää.

00:23:10.739 --> 00:23:14.174
Lyhyt kertaus: olemme vahvistaneet,

00:23:14.174 --> 00:23:18.140
että SQLite on ihana yhden maalin kohde monille, eikö niin?

00:23:18.140 --> 00:23:19.741
Se on kaikkialla.

00:23:19.741 --> 00:23:23.652
Ja se on monimutkainen C:llä kirjoitettu kone.

00:23:23.652 --> 00:23:27.458
Nyt, kyselyn kaappaamisen avulla voimme alkaa laukaista näitä bugeja

00:23:27.458 --> 00:23:35.231
ja tavoitella täydellistä hyökkäystä käyttämällä SQL-kyselyjä.

00:23:35.631 --> 00:23:40.698
Hyökkäysstrategiamme on seuraava: vuodatamme joitakin osoittimia

00:23:40.698 --> 00:23:44.708
ja sitten laskemme joitakin funktio-osoitteita.

00:23:44.708 --> 00:23:47.519
Luomme sitten väärennetyn tokenizer-objektin,

00:23:47.519 --> 00:23:50.414
jolla on jokin osoitin system()-funktioon.

00:23:50.414 --> 00:23:55.161
Ylikirjoitamme oletusarvoisen tokenizerin ja laukaisemme pahantahtoisen tokenizerimme.

00:23:55.161 --> 00:24:02.684
Sitten tapahtuu jotain, ja lopussa meidän pitäisi pystyä hyötymään jotenkin, eikö niin?

00:24:02.684 --> 00:24:07.281
Aloittaen muistivuodosta ja tietovuodosta libsqliteen.

00:24:07.281 --> 00:24:09.780
Tiedät jo, miten tehdään, eikö niin?

00:24:09.780 --> 00:24:16.480
Näimme fts3_tokenizer():in, mutta meillä on vielä pieni ongelma little-endian osoittimen kanssa.

00:24:16.480 --> 00:24:18.051
Joten meidän on käännettävä se ympäri.

00:24:18.051 --> 00:24:20.745
Varmaan voimme käyttää SUBSTR-funktiota

00:24:20.745 --> 00:24:25.473
ja lukea tämän osoittimen kaksi merkkiä kerrallaan käänteisessä järjestyksessä

00:24:25.473 --> 00:24:29.212
ja yhdistää kaiken koko osoittimen läpi.

00:24:29.212 --> 00:24:32.957
Joten saamme SELECT-kyselyn, joka näyttää seuraavalta,

00:24:32.957 --> 00:24:35.410
mutta nyt meillä on osoitin.

00:24:35.410 --> 00:24:36.801
Tämä on hienoa.

00:24:36.801 --> 00:24:38.796
Entä tietovuoto kekomuistiin?

00:24:38.796 --> 00:24:40.856
Haluamme tietää, missä keko sijaitsee.

00:24:40.856 --> 00:24:43.375
Aloitetaanpa tekemään temppua,

00:24:43.375 --> 00:24:46.588
joka on melko samankaltainen kuin RTREE-bugi, jonka olemme löytäneet.

00:24:46.588 --> 00:24:50.736
Joten jälleen kerran, aiomme sekoittaa joitakin shadow-taulukkojen käyttöliittymiä.

00:24:50.736 --> 00:24:56.023
Luomme siis virtuaalitaulukon ja lisäämme siihen joitakin arvoja.

00:24:56.023 --> 00:24:59.718
Nyt aiomme hämmentää match-käyttöliittymää.

00:24:59.718 --> 00:25:02.921
Match-käyttöliittymä tekee monia asioita,

00:25:02.921 --> 00:25:09.193
mutta taustalla se vain palvelee osoittimen muistissa, jossa tekstin sijainti sijaitsee.

00:25:09.193 --> 00:25:12.546
Se on tätä metadataa, hienoja asioita, joita virtuaalitaululla on.

00:25:12.546 --> 00:25:14.657
Joten aiomme hämmentää sitä ja sen sijaan,

00:25:14.657 --> 00:25:17.892
että siirtäisimme sen toiselle virtuaalitaulun käyttöliittymälle,

00:25:17.892 --> 00:25:21.194
siirrämme sen yksinkertaisesti heksadekooderille,

00:25:21.194 --> 00:25:23.519
joten puramme tämän raakanosoittimen.

00:25:23.519 --> 00:25:25.708
Ja voit nähdä, jälleen kerran little-endianin,

00:25:25.708 --> 00:25:28.036
mutta nyt meillä on linkki kekoon.

00:25:28.526 --> 00:25:30.691
Voimme yliviivata sen listalta.

00:25:30.691 --> 00:25:34.110
Ja ennen kuin siirrymme eteenpäin tämän osoittimen purkamiseen,

00:25:34.110 --> 00:25:37.493
meillä on hyvin perustavanlaatuinen ongelma.

00:25:37.493 --> 00:25:39.870
Kuinka edes tallennamme näitä asioita?

00:25:39.870 --> 00:25:44.888
Koska toisin kuin selaimen WebSQL:ssä, meillä ei ole JavaScript-muuttujia tai taulukoita,

00:25:44.888 --> 00:25:46.699
joita voimme käyttää ja hyväksikäyttää myöhemmin,

00:25:46.699 --> 00:25:49.668
mutta meidän on luotava joitakin monimutkaisia logiikoita, eikö niin?

00:25:49.668 --> 00:25:55.465
Meidän on laskettava funktio-osoite ja luotava asioita muistissa, mutta kuinka voimme tehdä sen?

00:25:55.465 --> 00:25:58.037
Ilmeisesti SQLite:llä, kun haluat tallentaa joitakin arvoja,

00:25:58.037 --> 00:26:04.801
sinun on oltava insert-lausekkeita, mutta voimme vain luoda tauluja, näkymiä, indeksejä ja laukaisimia.

00:26:05.901 --> 00:26:11.754
Sitten ajattelimme ketjuttaa tämän näkymän yhteen käyttääksemme niitä jonkinlaisena pseudomuuttujana.

00:26:11.754 --> 00:26:13.908
Joten jälleen kerran, anna minun näyttää sinulle esimerkki.

00:26:13.908 --> 00:26:18.147
Tässä luon näkymän, jota kutsutaan "little-endian leak", okei?

00:26:18.147 --> 00:26:21.873
Ja taas hyväksikäytän fts3_tokenizer() -funktiota.

00:26:21.873 --> 00:26:25.153
Nyt luon toisen näkymän sen päälle, ja tätä kutsutaan "leakiksi"

00:26:25.153 --> 00:26:27.775
ja kääntyy käyttämällä SUBSTR-temppua,

00:26:27.775 --> 00:26:29.148
jonka tiedät jo aikaisemmasta.

00:26:29.148 --> 00:26:33.095
Mutta huomaa, kuinka viittasin ensimmäiseen näkymään, viittasin "little-endian leak":iin.

00:26:33.095 --> 00:26:40.419
Joten teen sen koko osoittimen läpi, ja lopulta minulla on pseudomuuttuja nimeltä "leak".

00:26:40.419 --> 00:26:44.847
Kun valitsen sen, saan odotetun tuloksen.

00:26:45.131 --> 00:26:47.666
Joten nyt voimme todella edetä.

00:26:47.666 --> 00:26:51.761
Nyt voimme aloittaa monimutkaisempien asioiden rakentamisen tämän logiikan perusteella.

00:26:52.491 --> 00:26:54.934
Ja nyt voimme siirtyä purkamaan osoittimia.

00:26:55.474 --> 00:27:01.211
Haluamme esimerkiksi laskea kuvan perustan tai löytää keon alun.

00:27:01.211 --> 00:27:05.677
Joten ensinnäkin haluamme muuntaa osoittimemme kokonaisluvuiksi.

00:27:05.677 --> 00:27:11.740
Joten jälleen kerran aloitamme lukemalla nämä osoittimet yhden merkin kerrallaan

00:27:11.740 --> 00:27:14.821
ja käänteisessä järjestyksessä käyttäen SUBSTRia.

00:27:14.821 --> 00:27:20.835
Ja saadaksemme heksadesimaalimerkin arvon, käytämme INSTR-funktiota,

00:27:20.835 --> 00:27:27.207
joka on kuin strchar, ja käyttämällä seuraavaa merkkijonoa saamme heksadesimaalimerkin arvon.

00:27:27.207 --> 00:27:32.238
Koska se on yksipohjainen, on oikealla miinus yksi.

00:27:32.238 --> 00:27:36.577
Sitten minun täytyy tehdä hieman siirtämistä, kuten jotain pimeää magiaa,

00:27:36.577 --> 00:27:42.332
ja sitten yhdistän kaiken yhteen osoittimessa.

00:27:42.332 --> 00:27:45.100
Joten tulos on tämä hirviömäinen kysely.

00:27:45.100 --> 00:27:53.060
Mutta kun kaikki tämä on tehty, saan kokonaisluvun, joka on purkamaton versio alkuperäisestä vuodosta.

00:27:53.060 --> 00:27:56.621
Joten onnistuin purkamaan tämän osoittimen,

00:27:56.621 --> 00:28:01.093
ja meillä on nyt käsillä kokonaislukuja, joten voimme yliviivata sen listalta myös.

00:28:01.093 --> 00:28:03.948
Tiedämme nyt, miten muuntaa osoittimet kokonaisluvuiksi.

00:28:04.198 --> 00:28:10.886
Nyt osoitinlaskentaa, koska haluamme saada joitain toimintojen osoitteita muistissa,

00:28:10.886 --> 00:28:14.430
ja itse asiassa kokonaislukuilla tämä on erittäin yksinkertaista.

00:28:14.430 --> 00:28:17.658
Kaikki mitä meidän tarvitsee tehdä on käyttää joitakin alikyselyjä.

00:28:17.658 --> 00:28:21.199
Vasemmalla voit nähdä, että viittaan nyt pseudomuuttujiin,

00:28:21.199 --> 00:28:23.990
joita meillä on nyt, vuotanut tieto,

00:28:23.990 --> 00:28:29.572
ja oikealla voin joko vähentää hölmön vakion kuten tein täällä,

00:28:29.572 --> 00:28:37.688
tai voin todella käyttää toista pseudomuuttujaa tehdäkseni sen hieman dynaamisemmaksi ja luotettavammaksi.

00:28:37.688 --> 00:28:45.327
Lopulta, mihin päädyin, on libsqlite-perusta kokonaislukumuodossa.

00:28:45.327 --> 00:28:50.272
Joten, olemme lukeneet joitakin osoittimia ja manipuloineet niitä.

00:28:50.272 --> 00:28:55.740
Nyt on hyvä aika kirjoittaa ne takaisin. Ja tietysti olemme tottuneet siihen,

00:28:55.740 --> 00:28:59.101
että "char" on täysin päinvastainen kuin "hex".

00:28:59.101 --> 00:29:03.840
Ja voit nähdä, että se toimii melko hyvin useimmilla arvoilla,

00:29:03.840 --> 00:29:08.928
mutta suuremmat kokonaisluvut todella käännettiin niiden kahden tavun koodipisteisiin.

00:29:08.928 --> 00:29:12.016
Joten tämä oli suuri este meille.

00:29:15.196 --> 00:29:20.186
Joten, kun olimme viettäneet dokumentaation parissa jonkin aikaa,

00:29:20.186 --> 00:29:22.642
yhtäkkiä meille valkeni kummallinen oivallus.

00:29:22.642 --> 00:29:25.919
Tajusimme, että hyökkäyksemme on itse asiassa tietokanta.

00:29:25.919 --> 00:29:28.929
Ja jos haluan minkä tahansa muunnoksen tapahtuvan,

00:29:28.929 --> 00:29:33.986
voin yksinkertaisesti luoda etukäteen tämän avain-arvo-kartan ja yksinkertaisesti

00:29:33.986 --> 00:29:41.297
kysyä sitä käännettäväksi millä tahansa arvolla toiseksi arvoksi alikyselyillä.

00:29:41.297 --> 00:29:43.405
Tämä on se Python-funktio, jonka olen käyttänyt,

00:29:43.405 --> 00:29:45.808
ja voit nähdä, että siinä on hyvin yksinkertainen for-silmukka,

00:29:45.808 --> 00:29:49.705
joka menee 0:sta FF:ään ja vain lisää arvoja tauluun,

00:29:49.705 --> 00:29:52.416
jota kutsutaan "hex_map", sen avain-kartan arvoilla.

00:29:52.416 --> 00:29:58.782
Ja nyt muunnoksemme käyttävät alikyselyjä. Joten anna minun jälleen näyttää esimerkki.

00:29:59.732 --> 00:30:02.310
Voit nähdä, että valitsen "val" heksakartasta,

00:30:02.310 --> 00:30:06.702
tästä avain-arvo-kartasta, jossa "int" on yhtä suuri kuin,

00:30:06.702 --> 00:30:11.368
ja sitten teen hieman enemmän kaikenlaista, kuten siirtämistä ja modulo pimeää magiaa,

00:30:11.368 --> 00:30:17.059
mutta lopulta päädyin pakattuun versioon libsqlite-tietokannasta.

00:30:17.059 --> 00:30:23.304
Nyt meillä on pakattu little-endian osoitin, joten sen voi ruksata listalta pois.

00:30:24.644 --> 00:30:29.929
Kuten mainitsin, yksittäisen osoittimen kirjoittaminen on ehdottomasti hyödyllistä,

00:30:29.929 --> 00:30:31.020
mutta se ei riitä.

00:30:31.295 --> 00:30:34.272
Haluamme väärentää kokonaisia objekteja, eikö niin?

00:30:34.272 --> 00:30:38.046
Kaikki coolit tyypit tekevät niin, ja se on melko voimakas primitiivi.

00:30:38.046 --> 00:30:40.897
Ja jos muistat, meidän on tehtävä se,

00:30:40.897 --> 00:30:46.086
koska fts3_tokenizer() edellyttää meidän määrittävän tokenizer moduulin.

00:30:46.086 --> 00:30:51.454
No, mikä on tokenizer-moduuli? Miltä se näyttää? Joten tämä on sen rakenteen alku,

00:30:51.454 --> 00:30:54.483
ja siinä on "iVersion", joka on kokonaisluku alussa,

00:30:54.483 --> 00:30:56.456
meillä ei ole oikeastaan mitään tekemistä sen kanssa,

00:30:56.456 --> 00:30:59.273
mutta sen jälkeen on kolme funktio-osoitinta.

00:30:59.573 --> 00:31:06.237
Meillä on "xCreate", joka on jakelijan rakentaja, ja "xDestroy", joka on purkaja.

00:31:06.237 --> 00:31:11.538
Meidän on tehtävä molemmat kelvollisiksi, jotta sovellus ei kaadu hyökätessämme.

00:31:11.538 --> 00:31:15.198
Kolmas funktio-osoitin on todella mielenkiintoinen, koska tämä on se,

00:31:15.198 --> 00:31:16.645
joka todella jakaa merkkijonon osiksi.

00:31:16.645 --> 00:31:20.784
Joten meillä on funktio-osoitin, johon ohjataan hallittavissa oleva merkkijono.

00:31:20.784 --> 00:31:25.620
Tämä olisi täydellinen paikka laittaa system-vimpaimemme, eikö niin.

00:31:26.510 --> 00:31:31.737
Tähän mennessä olen käyttänyt melkoisesti SQL-osaamistani, eikö niin?

00:31:31.737 --> 00:31:37.251
Mutta minulla on vielä yksi temppu hihassani ja se on JOIN-kyselyt, eikö niin?

00:31:37.251 --> 00:31:40.663
Koska olen oppinut siitä menneessä ajassa.

00:31:40.663 --> 00:31:44.217
Joten nyt luomme väärennetyn tokenizer-näkymän

00:31:44.217 --> 00:31:48.887
ja yhdistämme joukon "A"-kirjaimia ja sitten käyttäen JOIN-kyselyä

00:31:48.887 --> 00:31:53.900
ja yhdistämme sen osoittimeen simple_create ja osoittimeen simple_destroy

00:31:53.900 --> 00:31:58.951
ja sitten joukon "B":itä. Nyt tarkistetaan se alhaisen tason debuggerissa

00:31:58.951 --> 00:32:03.394
ja voit itse asiassa nähdä, että jossain muistipaikassa meillä on joukko "A":ita,

00:32:03.394 --> 00:32:05.537
jonka perässä on osoitin simple_createen,

00:32:05.537 --> 00:32:10.045
jonka perässä on osoitin simple_destroyiin ja sitten joukko "B":iä.

00:32:10.815 --> 00:32:16.314
Joten olemme melkein valmiit. Mutta tarvitsemme vielä yhden primitiivin tätä hyödyntääksemme.

00:32:16.314 --> 00:32:20.865
Ja tämä johtuu siitä, että meillä on jo haitallinen tokenizerimme,

00:32:20.865 --> 00:32:26.217
ja tiedämme, missä keko sijaitsee, mutta emme ole aivan varmoja, missä tokenizerimme sijaitsee.

00:32:26.217 --> 00:32:29.654
Tämä on hieno aika heap sprayinglle, eikö olekin.

00:32:29.654 --> 00:32:35.204
Ja ihanteellisesti tämä olisi jonkin toistuva muoto meidän fakeobj -primitiivistämme.

00:32:35.204 --> 00:32:44.031
Olemme siis ajatelleet toistoa, mutta valitettavasti SQLite ei ole toteuttanut sitä kuten mySQL.

00:32:44.031 --> 00:32:45.599
Joten kuten kuka tahansa muukin,

00:32:45.599 --> 00:32:50.346
menimme Stack Overflowiin ja löysimme tämän todella elegantin ratkaisun.

00:32:50.346 --> 00:32:57.886
Käytämme siis zeroblob-funktiota, joka yksinkertaisesti palauttaa nollista koostuvan läjän.

00:32:57.886 --> 00:33:02.641
Sitten korvaamme jokaisen nollan väärennetyllä tokenisaattorillamme.

00:33:02.641 --> 00:33:05.721
Ja teemme sen kymmenentuhatta kertaa, kuten näette yllä.

00:33:05.861 --> 00:33:08.764
Uudelleen, varmistaaksemme sen debuggerilla,

00:33:08.764 --> 00:33:12.024
näet paljon "A":ita ja se on vähän vaikea nähdä,

00:33:12.024 --> 00:33:16.414
koska nämä ovat todella huonoja värejä, mutta meillä on myös täydellinen johdonmukaisuus,

00:33:16.414 --> 00:33:20.842
koska nämä rakenteet toistuvat joka 20. heksadesimaalitavussa.

00:33:21.222 --> 00:33:25.823
Joten loimme melko hyvät heap-spraying -kyvyt,

00:33:26.773 --> 00:33:30.952
ja olemme valmiit exploitti -toiveluettelomme kanssa,

00:33:30.952 --> 00:33:34.489
joten voimme palata alkuperäiseen kohteeseemme.

00:33:34.489 --> 00:33:39.709
Tämä on koodisegmentti erittäin tunnetusta salasanavarkaasta,

00:33:39.709 --> 00:33:42.646
ja lopussa voit nähdä, että se yrittää valita

00:33:42.646 --> 00:33:50.414
ja poimia salaisuuksia valitsemalla sarakkeen nimeltä "BodyRich" taulusta nimeltä "Notes".

00:33:50.414 --> 00:33:54.203
Joten valmistelemme hänelle pienen yllätyksen, okei?

00:33:54.397 --> 00:33:56.811
Luomme näkymän, jota kutsutaan nimellä "Notes".

00:33:56.811 --> 00:34:00.766
Ja siinä on kolme alikyselyä sarakkeessa nimeltä "BodyRich".

00:34:00.766 --> 00:34:05.193
Jokainen näistä alikyselyistä on itse asiassa QOP-ketju.

00:34:05.193 --> 00:34:08.598
Jos muistat hyökkäyssuunnitelmani,

00:34:08.598 --> 00:34:14.137
aloitamme heap-spray sitten korvaamme oletustokenisaattorin

00:34:14.137 --> 00:34:17.148
ja laukaisemme lopuksi haitallisen tokenisaattorin.

00:34:17.148 --> 00:34:20.408
Ja sinä saatat kysyä itseltäsi, mikä on heap_spray?

00:34:20.408 --> 00:34:26.735
Ilmeisesti heap_spray on QOP-ketju, joka hyödyntää heap-spraying -kykyjämme, eikö niin.

00:34:26.735 --> 00:34:32.856
Me ruiskutamme kymmenentuhatta esimerkkiä väärennetystä tokenizeristamme,

00:34:32.856 --> 00:34:39.564
joka on JOIN-kysely joukosta "A":ita ja joitain osoittimia, kuten p64_simple_create.

00:34:40.044 --> 00:34:47.601
Ja bileet jatkuvat, koska p64_simple_create on itse asiassa peräisin u64_simple_createsta, oikein,

00:34:47.601 --> 00:34:51.218
käyttäen osoittimenpakkauskykyjämme.

00:34:51.218 --> 00:34:54.646
Ja tämä on kuin maatuska-nukke,

00:34:54.646 --> 00:35:02.059
koska sinulla on u64_simple_create, joka on peräisin libsqlite_basesta plus joistakin vakioista.

00:35:02.059 --> 00:35:06.573
Ja tämä menee takaisin purkamattomaan vuotoversioon,

00:35:06.573 --> 00:35:07.792
miinus joitain vakioita.

00:35:07.792 --> 00:35:12.764
Joten jälleen kerran käytämme osoitinlaskentakykyjämme.

00:35:13.354 --> 00:35:18.485
Voimme jatkaa u64_leak:illa, joka on peräisin lähes alkuperäisestä vuodosta.

00:35:18.485 --> 00:35:21.802
Ja me päätämme näyttämällä,

00:35:21.802 --> 00:35:27.869
kuinka vuoto on itse asiassa peräisin alkuperäisestä haavoittuvuudesta käyttäen fts3_tokenizeria.

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ä.

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.

00:35:38.533 --> 00:35:41.443
Ja ollakseni rehellinen, tämä on juurikin mitä tunnen.

00:35:41.443 --> 00:35:44.721
Mutta onneksi teidän ei tarvitse näyttää tai tuntea samalta kuin minä,

00:35:44.721 --> 00:35:49.892
koska loimme QOP.py:n, ja se on saatavilla Checkpoint Researchin GitHubissa.

00:35:49.892 --> 00:35:56.825
Ja yhtäkkiä nämä hullun pitkät ketjut voidaan luoda neljällä helpolla Python-rivillä.

00:35:56.825 --> 00:35:59.818
Ja tuntuu pwntoolsilta, jos olet perehtynyt siihen,

00:35:59.818 --> 00:36:04.757
joten voit mennä eteenpäin ja leikkiä sillä etkä näytä hullulta lavalla.

00:36:05.377 --> 00:36:07.751
Siirrymme ensimmäiseen demoomme.

00:36:07.751 --> 00:36:12.684
Ownaamme salasanan varastavaa taustapalvelinta, joka toimii uusimmalla PHP 7:llä.

00:36:12.684 --> 00:36:16.983
Tietenkin tämä on malli, jonka loimme vuotaneista lähteistä,

00:36:16.983 --> 00:36:20.354
ja näet kaikki tartunnan saaneet uhrit

00:36:24.535 --> 00:36:25.295
Coolia

00:36:25.295 --> 00:36:28.245
Nyt yritämme mennä web-shelliin, p.php:hen.

00:36:28.765 --> 00:36:31.871
Tietenkään sitä ei vielä ole olemassa, saamme 404.

00:36:32.239 --> 00:36:34.878
Siirrymme hyökkääjän tietokoneelle.

00:36:34.878 --> 00:36:37.524
Näemme täällä kaksi skriptiä.

00:36:37.524 --> 00:36:43.650
Ensin käytämme QOP.py:ä, joka luo ilkeämielisen tietokannan.

00:36:43.650 --> 00:36:46.510
Katsotaanpa, tietokanta luotiin.

00:36:46.510 --> 00:36:49.149
Nyt emuloimme saastuttamisen.

00:36:49.149 --> 00:36:52.537
Aloitamme lähettämällä ilkeämielisen tietokantamme C2-palvelimelle

00:36:52.537 --> 00:36:54.939
kuin olisimme tartunnan saaneet salasanavarkaan kautta.

00:36:54.939 --> 00:37:00.078
Koska tämä prosessi vie hieman aikaa, voimme tarkastella kaikkia hienoja DDL-lauseita, oikein?

00:37:00.078 --> 00:37:05.059
Näet siis, että aloitimme jonkin bin-vuodon ja heap-vuodon kanssa ja sitten purimme ne.

00:37:05.059 --> 00:37:11.623
Ja aivan lopussa voit nähdä, että ohjelmamme luo yksinkertaisen webshellin p.php:lle.

00:37:11.623 --> 00:37:15.019
Ja tämä on sama sivu, jota juuri yritimme tavoittaa.

00:37:15.019 --> 00:37:21.784
Joten toivottavasti, joo - hienoa, se on tehty.

00:37:21.784 --> 00:37:26.004
Nyt palaamme salasanavarkaan back-endiin.

00:37:26.004 --> 00:37:28.157
Menemme p.php:hen ja saamme vastauksen 200.

00:37:28.157 --> 00:37:34.006
Nyt suoritamme jotain koodia siinä. whoami. www-data.

00:37:34.006 --> 00:37:37.174
Ja ilmeisesti meidän täytyy mennä /etc/passwordiin.

00:37:39.994 --> 00:37:41.193
Jippii.

00:37:42.253 --> 00:37:50.683
[Yleisö taputtaa]

00:37:50.683 --> 00:37:55.304
Joten mitä juuri tapahtui, on se, että osoitimme,

00:37:55.304 --> 00:38:00.315
että annetun kyselyn avulla ilkeämielisessä tietokannassa,

00:38:00.315 --> 00:38:04.004
voimme suorittaa koodia kyselyprosessissa.

00:38:04.004 --> 00:38:07.199
Nyt, kun otetaan huomioon, että SQLite on niin suosittu,

00:38:07.199 --> 00:38:11.344
tämä todella avaa oven laajalle valikoimalle hyökkäyksiä.

00:38:11.344 --> 00:38:15.878
Tutkitaan toista täysin erilaista käyttötapaa. Joka on täysin erilainen

00:38:15.878 --> 00:38:20.252
Seuraava kohde on iOS pysyvyys.

00:38:21.462 --> 00:38:27.433
iOS käyttää SQLiteä laajalti ja pysyvyyden saavuttaminen on todella vaikeaa,

00:38:27.433 --> 00:38:32.322
koska kaikkien suoritettavien tiedostojen on oltava allekirjoitettuja.

00:38:32.322 --> 00:38:36.478
Silti SQLite-tietokantoja ei ole allekirjoitettu, eikö niin, ne ovat vain dataa.

00:38:36.478 --> 00:38:38.346
Niitä ei tarvitse allekirjoittaa.

00:38:38.346 --> 00:38:43.259
Ja iOS ja MacOS ovat molemmat käännetty käyttäen ENABLE_FTS3_TOKENIZER:ia.

00:38:43.259 --> 00:38:45.507
Se on se vaarallinen käännöshetken lippu.

00:38:45.507 --> 00:38:50.581
Suunnitelmani on saada koodin suoritus uudelleenkäynnistyksen

00:38:50.581 --> 00:38:53.912
jälkeen korvaamalla mielivaltainen SQLite-tietokanta.

00:38:53.912 --> 00:39:01.160
Tämän saavuttamiseksi aion kohdistaa hyökkäyksen "AddressBook.sqlite" -nimiseen yhteystietokantaan.

00:39:01.160 --> 00:39:05.506
Alkuperäisessä tietokannassa on kaksi taulua,

00:39:05.506 --> 00:39:09.050
joilla ei ole merkittävää merkitystä, vaan ne ovat esimerkkejä.

00:39:09.050 --> 00:39:16.831
Aion luoda haitallisen yhteystietokannan, ja aloitan kahdella haitallisella DDL-lausekkeella,

00:39:16.831 --> 00:39:19.227
jotka ovat teille jo tuttuja.

00:39:19.227 --> 00:39:24.696
Ensin korvaamme oletustokenizerin "simple" joukolla "A":ita.

00:39:24.816 --> 00:39:31.117
Sitten toinen DDL-lauseke toteuttaa tämän haitallisen laukaisimen,

00:39:31.117 --> 00:39:35.387
joten se kaataa ohjelman, koska joka kerta, kun luodaan virtuaalitaulumoduuli,

00:39:35.387 --> 00:39:39.341
joku yrittää mennä tokenizerin rakentajan luokse.

00:39:39.341 --> 00:39:41.094
Joten se kaatuu.

00:39:41.094 --> 00:39:46.584
Seuraavaksi käyn läpi jokaisen alkuperäisen taulun

00:39:46.584 --> 00:39:50.462
ja kirjoitan ne uudelleen käyttäen kyselykaappauksen tekniikkaa.

00:39:50.462 --> 00:39:53.890
Sen sijaan että käytämme odotettuja sarakkeita,

00:39:53.890 --> 00:39:58.895
ohjaamme suorituksen ylikirjoituslauseeseen ja kaatumislauseeseen.

00:39:58.895 --> 00:40:01.740
Teimme sen yhdelle taululle, teemme sen myös muille.

00:40:02.503 --> 00:40:06.218
Nyt käynnistämme uudelleen ja voilà,

00:40:06.218 --> 00:40:09.822
saamme seuraavan CVE:n ja turvallinen käynnistys ohitettiin.

00:40:09.822 --> 00:40:12.168
Ja jos kiinnität huomiota tarkasti, tämä on todella hienoa,

00:40:12.168 --> 00:40:18.088
koska näemme että kaatuminen tapahtui osoitteessa 0x414141...49.

00:40:18.088 --> 00:40:24.136
Tämä on juuri mitä odotimme tapahtuvan, koska tässä pitäisi olla konstruktorimme,

00:40:24.136 --> 00:40:28.304
kahdeksan tavua version ensimmäisen kokonaisluvun jälkeen.

00:40:29.064 --> 00:40:32.196
Mutta todellisuudessa tässä on enemmän. Saamme pienen bonuksen tässä.

00:40:32.196 --> 00:40:37.749
Koska yhteystietokanta on itse asiassa käytössä monien eri prosessien kautta.

00:40:37.749 --> 00:40:44.716
Joten Yhteystiedot, FaceTime, Springboard, WhatsApp, Telegram, XPCProxy ja monet muut.

00:40:44.716 --> 00:40:48.219
Ja monilla näistä prosesseista on enemmän oikeuksia kuin toisilla.

00:40:48.219 --> 00:40:52.735
Ja olemme osoittaneet, että voimme nyt suorittaa koodia prosessissa,

00:40:52.735 --> 00:40:54.965
joka kysyy ilkeämielistä tietokantaamme.

00:40:54.965 --> 00:40:58.621
Joten saimme myös oikeuksen kohottamisen tässä prosessissa.

00:40:58.621 --> 00:41:03.233
Tämä on todella hienoa. Ja yhteystietokannassa ei ole mitään erityistä.

00:41:03.233 --> 00:41:05.835
Itse asiassa mitä tahansa jaettua tietokantaa voidaan käyttää.

00:41:05.835 --> 00:41:08.930
Tarvitsemme vain jotain, joka on kirjoitettavissa heikolla käyttäjällä

00:41:08.930 --> 00:41:15.570
ja jota vahvempi käyttäjä sitten kysyy. Ja ilmeisesti kaikki nämä tekniikat

00:41:15.570 --> 00:41:18.563
ja virheet ilmoitettiin Applelle, ja ne kaikki on korjattu.

00:41:18.563 --> 00:41:21.832
Ja tässä ovat CVE:t, jos haluat lukea siitä myöhemmin.

00:41:22.102 --> 00:41:27.423
Nyt, ynnätäkseni asioita, jos haluat oppia jotain tästä esityksestä,

00:41:27.423 --> 00:41:33.371
en halua sen olevan hullua SQL-voimistelua tai joukko CVE-numeroita.

00:41:33.371 --> 00:41:35.055
Haluan sen olevan seuraavaa.

00:41:35.055 --> 00:41:40.365
Tietokannan kysely ei välttämättä ole turvallista, oli kyse sitten käynnistyksen yli,

00:41:40.365 --> 00:41:43.185
käyttäjien välillä tai prosessien välillä,

00:41:43.185 --> 00:41:47.616
tietokannan kysely ei välttämättä ole turvallista kyselyn kaappauksen vuoksi.

00:41:47.616 --> 00:41:51.307
Ja nyt, kun on kyse kyselyjen kaappauksesta ja kyselykeskeisestä ohjelmoinnista,

00:41:51.307 --> 00:41:57.478
nämä muistin korruptiot, joita voimme laukaista, voidaan todella hyödyntää luotettavasti pelkällä SQL:llä.

00:41:57.478 --> 00:42:00.758
Emme tarvitse enää JavaScriptiä. Emme tarvitse WebSQL:ää.

00:42:00.758 --> 00:42:04.827
Ja uskomme todella, että tämä on vain jäävuoren huippu.

00:42:04.827 --> 00:42:07.370
Tähän mennessä SQLite on ollut erittäin suosittu,

00:42:07.370 --> 00:42:12.842
mutta sitä on arvioitu vain WebSQL:n kapealta alueelta,

00:42:12.842 --> 00:42:19.319
ja vaikka selaimen pwnaus on jännittävää, SQLite:lla on paljon enemmän potentiaalia.

00:42:19.319 --> 00:42:24.347
Meillä on siis joitain ajatuksia mahdollisesta tulevasta työstä tämän kanssa.

00:42:24.717 --> 00:42:31.070
Ilmeisesti todella hienoa olisi laajentaa primitiivejämme joitain vahvempia primitiivejä kohti, oikein.

00:42:31.070 --> 00:42:35.607
Haluamme saada asioita, kuten absoluuttinen luku- ja kirjoituskyky.

00:42:35.607 --> 00:42:40.851
Ja minun hatara POC-hyökkäykseni oli melko typerä,

00:42:40.851 --> 00:42:44.371
koska siinä oli paljon vakioita, kuten olette nähneet,

00:42:44.371 --> 00:42:49.026
mutta itse asiassa jos käytät SQLite:n sisäistä toimintoa,

00:42:49.026 --> 00:42:52.967
jos hyökkäyksen aikana käytät funktiota kuten sqlite3_version(),

00:42:52.967 --> 00:42:57.316
voit kysyä tulkilta, mikä versio sinulla on, millä käännösvalinnoilla se on käännetty,

00:42:57.316 --> 00:43:00.824
voit dynaamisesti rakentaa näitä QOP-ketjuja

00:43:00.824 --> 00:43:06.591
ja kohdistaa ne tiettyyn kohdeympäristöön, jota hyökkäät.

00:43:06.591 --> 00:43:09.792
Itse asiassa hyödyntämällä sitä tosiasiaa, että hyökkäyksemme on tietokanta,

00:43:09.792 --> 00:43:14.140
voimme luoda tämän todella coolin hyökkäyspolyglotin, ja ajattelemme,

00:43:14.140 --> 00:43:18.903
että näitä tekniikoita voidaan käyttää oikeuksien kohottamiseen monissa tilanteissa,

00:43:18.903 --> 00:43:22.404
koska kehittäjät eivät koskaan ajatelleet,

00:43:22.404 --> 00:43:27.529
että nyt voimme ottaa minkä tahansa tietokannan, jota heikko käyttäjä voi kirjoittaa,

00:43:27.529 --> 00:43:32.906
ja jota vahva käyttäjä voi kysyä, ja yhtäkkiä voimme yrittää kohottaa oikeuksiamme.

00:43:33.236 --> 00:43:38.858
Toisaalta olisi todella mielenkiintoista huomata, että monet niistä primitiiveistä,

00:43:38.858 --> 00:43:42.194
joita olen teille näyttänyt, eivät ole yksinomaan SQLite:n omaisuutta, eikö niin?

00:43:42.194 --> 00:43:45.839
Osoitinpakkaus ja -purku sekä heap spraying

00:43:45.839 --> 00:43:48.800
ja kaikki nämä asiat eivät ole yksinomaan SQLite:n omaisuutta.

00:43:48.800 --> 00:43:51.945
Olisi todella mielenkiintoista ottaa nämä primitiivit ja nähdä,

00:43:51.945 --> 00:43:58.939
voimmeko mennä eteenpäin ja hyödyntää muita muistin korruption bugia eri tietokanta-moottoreissa.

00:44:00.109 --> 00:44:01.419
Kiitos paljon.

00:44:02.248 --> 00:44:08.858
[Yleisö taputtaa]

00:44:09.766 --> 00:44:11.973
Omer Gull, kiitos paljon.

00:44:11.973 --> 00:44:14.425
Siinä oli paljon aikaa kysymyksille.

00:44:14.425 --> 00:44:17.301
Meillä on kolme mikrofonia täällä salissa:

00:44:17.301 --> 00:44:19.460
Numero yksi, Numero kaksi ja Numero kolme.

00:44:19.460 --> 00:44:22.153
Jos sinulla on kysymyksiä, ole hyvä ja jonota.

00:44:22.153 --> 00:44:24.774
Onko meillä joitakin kysymyksiä verkosta?

00:44:28.220 --> 00:44:29.560
Ei ole. Ookei.

00:44:29.560 --> 00:44:32.016
Aloittakaamme sitten mikrofonista numero kaksi.

00:44:32.016 --> 00:44:39.442
Joo. Kysymys koskee sitä "CREATE-jotakin" kaappaamista.

00:44:39.442 --> 00:44:44.147
Mainitsit, että alussa tutkimus oletti,

00:44:44.147 --> 00:44:49.656
että CREATE oli ensimmäinen tarkistusjärjestys

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.

00:44:55.474 --> 00:44:59.690
Nyt kysymykseni on: Jos se muuttui raporttisi jälkeen,

00:44:59.690 --> 00:45:08.233
koska tämä vaikuttaa tavalta altistaa suurempi hyökkäyspinta kuin useimmat muut bugit.

00:45:08.233 --> 00:45:09.779
Joten haluaisin tietää, jos he muuttivat sitä.

00:45:09.779 --> 00:45:14.102
Ja mitä oli lopulta se lieventäminen, jos sitä oli?

00:45:14.102 --> 00:45:19.078
Joo. Niin, meidän escalate-henkilöt ovat enemmän huolissaan tiettyjen virheiden

00:45:19.078 --> 00:45:21.462
kuin hyökkäystekniikoiden suhteen.

00:45:21.462 --> 00:45:23.976
Tämä on todella surullista, koska tiedämme kaikki,

00:45:23.976 --> 00:45:26.688
että virheet voidaan korjata, mutta hyökkäystekniikat jäävät käyttöön.

00:45:26.688 --> 00:45:29.470
Joten ei, he eivät muuttaneet tätä tarkistusta.

00:45:29.470 --> 00:45:36.735
Itse asiassa tämä "create "-validoinnin lisäys tehtiin vasta äskettäin.

00:45:36.735 --> 00:45:40.043
Sitä ennen pystyit käyttämään mitä tahansa DDL-lauseketta haluat.

00:45:40.043 --> 00:45:42.915
Joten tilanne ei ole todella hyvä siellä.

00:45:42.915 --> 00:45:45.167
Hyvä heille ja onnea tulevaisuudelle.

00:45:45.787 --> 00:45:46.738
Ja siinä oli kysymys.

00:45:48.030 --> 00:45:50.667
Okei. Sitten siirrymme mikrofoni ykköseen, kiitos.

00:45:50.667 --> 00:45:56.205
Oletko ehkä vahingossa hyökännyt palvelimelle, jota käytetään salasanan varastamiseen?

00:45:56.205 --> 00:45:58.143
Ei, tietenkään en tekisi niin.

00:45:58.143 --> 00:46:00.171
En hyökkäisi kenenkään kimppuun.

00:46:00.171 --> 00:46:03.968
Tämä on vain meidän laboratoriossamme POC:na. Okei.

00:46:03.968 --> 00:46:04.963
Kiitos.

00:46:04.963 --> 00:46:08.004
Salasanasi ovat turvassa varkailta.

00:46:08.074 --> 00:46:10.154
[Naurua] . Noniin

00:46:10.154 --> 00:46:10.973
Kukaan ei enää jonota.

00:46:10.973 --> 00:46:14.894
Onko meillä kysymyksiä verkosta? Ei mitään siellä.

00:46:14.894 --> 00:46:15.622
No, tästä lähdetään.

00:46:15.622 --> 00:46:16.122
Kiitos.

00:46:16.122 --> 00:46:17.232
Omer Gull, kiitos paljon.

00:46:17.232 --> 00:46:19.842
[Yleisö taputtaa]

00:46:22.237 --> 00:46:31.641
[Translated by Jouko Voutilainen (KYBS2001 course assignment at JYU.FI)]