1 00:00:00,000 --> 00:00:00,958 [Translated by {Iikka}{Yli-Kuivila} (ITKST56 course assignment at JYU.FI)] 2 00:00:00,958 --> 00:00:13,699 *33C3 preroll-musiikkia* 3 00:00:13,699 --> 00:00:17,760 Heralnd: Max on turvallisuustutkija Look- out:lla, hän on tehnyt tätä noin 10 vuotta 4 00:00:17,760 --> 00:00:22,780 hän on viettänyt paljon aikaa hämäämisen, hyväksikäyttömenetelmien kehittämisen ja 5 00:00:22,780 --> 00:00:28,160 turvallisuustutkinna parissa, hän on puhu- nut Black Hat:issä, hän keskittyy nykyisin 6 00:00:28,160 --> 00:00:33,579 mobiiliturvallisuuteen ja hänen väitös- kirjaansa. Hän kertoo teille Pegasus- 7 00:00:33,579 --> 00:00:38,210 haittaohjelman sisuksista tänään. Ja nyt annetaan Maxille vuoronsa. 8 00:00:38,210 --> 00:00:39,529 Max: Kiitokset. 9 00:00:39,529 --> 00:00:47,090 *aplodeja* 10 00:00:47,090 --> 00:00:51,660 M: Terve kaikki, nimeni on Max Bazaliy, ja tänään juttelemme Pegasuksen sisus- 11 00:00:51,660 --> 00:00:57,609 värkeistä. Olen Kiovasta, Ukrainasta, työskentelen nyt turvallisuustutkijana 12 00:00:57,609 --> 00:01:02,370 Lookout:illa ja viimeisen parin vuoden aikana olen keskittynyt jailbreak-teknii- 13 00:01:02,370 --> 00:01:06,540 koihin. Sen vuoksi olin mukana perustamas- sa Fried Apple-tiimiä ja olen työskenellyt 14 00:01:06,540 --> 00:01:12,979 monien iOS-jailbreakkien parissa, ml. 8 ja 9. Niin, Pegasus. Pegasus on korkean 15 00:01:12,979 --> 00:01:19,704 laadun vakoiluohjelmisto, jota voi käyttää laitteen täydelliseen vakoiluun. Mitä ta- 16 00:01:19,704 --> 00:01:23,710 hansa henkilökohtaisen datan varastami- sesta mikrofonin tai kameran etäaktivoin- 17 00:01:23,710 --> 00:01:30,870 tiin laitteella ilman mitään indikaatiota siitä että jotain tapahtuu. Jotta Pegasus 18 00:01:30,870 --> 00:01:35,820 voi toimia, sen pitää jailbreakata laite ensin, koska iOS:n hiekkalaattikko-ominai- 19 00:01:35,820 --> 00:01:40,570 suus estää sovelluksia vakoilemasta toi- siaan. Sen vuoksi Pegasus nojaa Trident 20 00:01:40,570 --> 00:01:49,320 haavoittuvuusketjuun saadakseen koko lait- teen hallintaansa, ja asentaakseen pysy- 21 00:01:49,320 --> 00:01:55,250 vyyskomponentin, jota voidaan käyttää laitteella. Tässä on todella pelottava 22 00:01:55,250 --> 00:02:03,102 lista maalitetuista sovelluksista, joista osa tunnetaan hyvin turvallsiina, kuten 23 00:02:03,102 --> 00:02:08,259 Telegram, WhatsApp, Viber ja olen melko varma että löydätte tuosta listasta suo- 24 00:02:08,259 --> 00:02:12,150 sikkiviestimenne. Ennen kuin mennään sy- vään tekniseen analyysiin käytetyistä haa- 25 00:02:12,150 --> 00:02:18,300 voittuvuuksista, hlauan kertoa teille kui- nka tähän päästiin, Pegasus-näytteeseen. 26 00:02:18,300 --> 00:02:23,239 Poliisi tapasi Ahmed Mansoorin, joka tun- netaan ihmisoikeuksien puolustajana. Hän 27 00:02:23,239 --> 00:02:29,459 on saanut jopa Martin Ennal-palkinnon, jo- ta pidetään ihmisoikeuksien Nobelin pal- 28 00:02:29,459 --> 00:02:39,530 kintona. Joten, ymmärtääkseni Ahmed vas- taanotti tänä vuonna tekstiviestin, jossa 29 00:02:39,530 --> 00:02:45,640 sanottiin että joku on valtion vankilassa. Hän ja joku muu saivat toisen samankal- 30 00:02:45,640 --> 00:02:52,300 taisen tekstarin seuraavan päivänä. Mutta hän oli ollut hakkeroinnin kohteena 2012 31 00:02:52,300 --> 00:02:58,910 ja hänelle tartutettiin FinFisher 2011. Joten nyt linkin klikkaamisen sijaan hän 32 00:02:58,910 --> 00:03:03,040 kontaktoi Citizen Labia, koska hän oli työskennellyt heidän kanssaan aiemmin. 33 00:03:03,040 --> 00:03:09,469 Hän lähetti linkin Citizen Labille analyy- siä varten ja me Lookoutin tutkimustiimis- 34 00:03:09,469 --> 00:03:13,989 sä saimme tämän ensimmäisen näytteen ja linkin Citizen Labilta. Tässä puheessa 35 00:03:13,989 --> 00:03:23,840 keskityn enimmäksene tekniseen osioon. Toimiakseen Pegasus nojaa Trident-haavoit- 36 00:03:23,840 --> 00:03:29,819 tuvuusketjuun, joka toimii kolmessa vai- heessa. Ensimmäisessä vaiheessa se kor- 37 00:03:29,819 --> 00:03:34,659 ruptoi muistia saavuttaakseen koodin etä- ajamista Safarin kontekstissa. Sen jälkeen 38 00:03:34,659 --> 00:03:38,549 se hyppää laitteella toiseen vaiheeseen ja käyttää kahta haavoittuvuutta hyväksikäyt- 39 00:03:38,549 --> 00:03:42,299 tääkseen kerneliä. Toinen hyödyntää yti- men Address Space Layout Randomisationia, 40 00:03:42,299 --> 00:03:47,590 ja toinen hankkii ytimen tasolla tapahtu- van koodin etäajokyvykkyyden, RCE:n. 41 00:03:47,590 --> 00:03:51,510 Lopuksi kolmannessa vaiheessa se asentaa vakoiluohjelmiston ja 42 00:03:51,510 --> 00:03:57,950 käyttää erikoista temppua saavuttakseen laitteella pysyvyyttä. 43 00:03:57,950 --> 00:04:03,040 Keskityn jokaiseen vaiheeseen yksityis- kohtaisesti. Ensimmäisessä vaiheessa tulee 44 00:04:03,040 --> 00:04:08,920 kertakäyttöinen spear-phish URL, joka in- validoidaan ensimmäisen klikkauksen jäl- 45 00:04:08,920 --> 00:04:13,629 keen. Se sisältää peiteltyä JavaScriptiä, joka ensimmäiseksi tarkistaa laitteen tyy- 46 00:04:13,629 --> 00:04:20,340 pin: onko se iPhone, iPad, 32- vai 64-bit- tinen. Ja perustuen tietoon, minkä tyyppi- 47 00:04:20,340 --> 00:04:25,730 nen prosessori laitteella on, siihen lada- taan tietty versio höykkäyskoodista. Mikä 48 00:04:25,730 --> 00:04:30,380 on vaihe kakkosessa. Ja lopuksi se hyväk- sikäyttää RCE-haavoittuvuutta WebKit:ssä 49 00:04:30,380 --> 00:04:34,525 suorittaakseen tuon hyökkäys (shell) -koodin. Niin, mitä haavoittuvuuttaa se 50 00:04:34,525 --> 00:04:42,600 käyttää? CVE 4657 etäkäyttöhaavoittuvuutta WebKitissä. Periaatteessa haavoittuvuus on 51 00:04:42,600 --> 00:04:46,910 Use-After-Free, joka saavutetaan kahdella bugilla ja näytteessä, jonka me saimme 52 00:04:46,910 --> 00:04:52,940 se ei ollut vakaa, koska se nojaa WebKit:n automaattiseen roskienkeräykseen. 53 00:04:52,940 --> 00:04:57,760 Ongelma asustaa MarkedArgumentBuffer:issa, jota voidaan hyväksikäyttää määriteltyjen 54 00:04:57,760 --> 00:05:02,030 ominaisuuksien avulla (defined properties) Defined properties on metodi, joka määrit- 55 00:05:02,030 --> 00:05:07,870 tää uusia tai muuttuneita ominaisuuksia suoraan oliossa. Se ottaa vastaan muutamia 56 00:05:07,870 --> 00:05:13,540 argumentteja, olion itsessään, ja ominai- suudet-olioita, joilla voi olla deskripto- 57 00:05:13,540 --> 00:05:20,910 reita, jotka muodostavat ominaisuuden jota määritellään tai muokataan. Sillä on aika 58 00:05:20,910 --> 00:05:26,070 yksinkertainen algoritmi, se sisältää muu- tamia silmukoita ensimmäisellä iteraatio- 59 00:05:26,070 --> 00:05:30,090 lla jokaiselle ominaisuus-deskriptorille jolla se tarkistaa alustuksen, ja sen 60 00:05:30,090 --> 00:05:35,790 jälkeen se liittää sen deskriptorin vekto- riin ja varmistaakseen ettei viittaukset 61 00:05:35,790 --> 00:05:40,020 ominaisuuksien deskriptoreihin happane, niitä suojellaan automaattiselta roskien- 62 00:05:40,020 --> 00:05:44,740 keruulta. Tätä tarkoitusta varten Marked- ArgumentBufferia käytetään. Näemme tässä 63 00:05:44,740 --> 00:05:49,530 lopussa MarkedArgumentBuffer append:n. MarkedArgumentBuffer estää olioita tuhou- 64 00:05:49,530 --> 00:05:59,250 tumasta. Ja jokaisen property-get:n onnis- tuneen validoinnin jälkeen tuo defineOwn- 65 00:05:59,250 --> 00:06:03,240 Property assosioi jokaisen käyttäjän anta- man ominaisuuden kohde-oliolle. 66 00:06:03,240 --> 00:06:08,150 Ja tässä on ongelma, koska kun definePro- pertyä kutsutaan on mahdollista kutsua 67 00:06:08,150 --> 00:06:13,610 mitä tahansa käyttäjän määrittelemää Java- Script-metodia. Ja jos näissä JavaScript- 68 00:06:13,610 --> 00:06:19,810 metodeissa roskienkeruu saadaan laukaistua se tulee de-allokoimaan kaikki merkitse- 69 00:06:19,810 --> 00:06:26,410 mättömät heapissä (keossa) olevat oliot. Menen vähän syvemmälle yksityiskohtiin: 70 00:06:26,410 --> 00:06:30,390 ensinnäkin pari sanaa MarkedArgumentBuffer :sta ja JavaScriptin roskienkeruusta. 71 00:06:30,390 --> 00:06:33,640 JavaScriptin roskienkeruu on vastuussa olioiden de-alolokoinnista muistista, kun 72 00:06:33,640 --> 00:06:37,900 niihin ei enää viitata. Se ajetaan satun- naisin väliajoin perustuen silloiseen 73 00:06:37,900 --> 00:06:42,670 muitipaineeseen, laitetyyppiin ja niin edelleen. Kun roskienkeruu on tarkis- 74 00:06:42,670 --> 00:06:48,550 tanut pitääkö olio deallokoida, se menee pinon (stack) lävitse ja tarkistaa 75 00:06:48,550 --> 00:06:53,190 viittaukset objekteihin. Viittaus objektiin voi olla olemassa myös sovellus- 76 00:06:53,190 --> 00:06:57,500 keossa, mutta tässä tapauksessa vaihtehto- ista tapaa käytetään, jota kutsutaan slow- 77 00:06:57,500 --> 00:07:04,140 Appendiksi. Joten, MarkedArgumentBuffer koostuu ensimmäisistä pinossa sijaitse- 78 00:07:04,140 --> 00:07:10,510 vista kahdeksasta arvosta. Se tarkoittaa, että kun yhdeksäs arvo lisätään, Marked- 79 00:07:10,510 --> 00:07:15,570 ArgumentBufferin kapasiteettia laajenne- taan. Se tullaan siirtämään pinomuistista 80 00:07:15,570 --> 00:07:25,840 kekomuistiin. Tätä slowAppend tekee. Slow- Append siirtää puskurissa olevan pinon 81 00:07:25,840 --> 00:07:31,810 kekoon ja nyt olio ei olekaan automaatti- sesti suojeltu roskienkeruulta. Jotta 82 00:07:31,810 --> 00:07:37,060 varmistetaan, että noita olioita ei deallokoida, ne pitää lisätä 83 00:07:37,060 --> 00:07:45,650 keon markListSet:iin. Tämän me näemme tässä. Joten, 84 00:07:45,650 --> 00:07:50,170 slowAppend yrittää saada kekokontekstia ja se voidaan saada lisäämällä olio, esim. 85 00:07:50,170 --> 00:07:59,639 merkitsemällä olio markListSet:iin. Ja tässä on ongelma, sillä kun keko-kontek- 86 00:07:59,639 --> 00:08:02,940 stia hankitaan, se voidaan hankkia pelkäs- tään monimutkaiselle oliolle. Tämä tarkoit 87 00:08:02,940 --> 00:08:08,110 taa, että perustyypit kuten integer, bool- ean tai muut, ne eivät ole keossa olevia 88 00:08:08,110 --> 00:08:14,450 olioita ja niitä ei merkitä markListSet:iin. 89 00:08:14,450 --> 00:08:20,480 Ja slowAppendissa on bugi. Meidän pitäisi pystyä kutsumaan sitä vain kerran. Eli kun 90 00:08:20,480 --> 00:08:27,720 puskuri siirretään pinomuistista kekomuis- tiin ja jokin ominaisuuksista on yksinker- 91 00:08:27,720 --> 00:08:31,750 tainen tietotyyppi, esim. integer, niitä ei automaattisesti suojella roskienker- 92 00:08:31,750 --> 00:08:35,959 uulta, ja kaikki sitä seuraavat arvot ei- vät myöskään tule olemaan suojeltuja 93 00:08:35,959 --> 00:08:41,610 koska slowAppendissa on tuo bugi. Tässä on kuva, joka havainnollistaa sitä ja todel- 94 00:08:41,610 --> 00:08:46,820 lisuudessa viittaus JavaScript-olioon on yhä vieläkin olemassa. 95 00:08:46,820 --> 00:08:53,330 Mutta jos kutsuttaessa definedOwnProperty- metodia yksikään käyttäjän antamista 96 00:08:53,330 --> 00:08:57,360 metodeista kutsutaan, ne voivat poistaa tämän viittauksen ja olio deallokoidaan. 97 00:08:57,360 --> 00:09:03,460 Yhteenvetääkseni kaikki tieto on tässä, kuinka sitä voi hyväksikäyttää. 98 00:09:03,460 --> 00:09:09,620 Me määrittelemme props-olion, joka sisäl- tää 12 deskriptoria ja niistä ensimmäiset 99 00:09:09,620 --> 00:09:16,401 yhdeksän ovat yksinkertaisia tyypiltään, kuten 0:sta 8:aan. Joten p8, joka on 100 00:09:16,401 --> 00:09:22,510 yhdeksäs arvobitti, tullaan lisäämään markListSeti:in. Se laukaisee slowAppendin 101 00:09:22,510 --> 00:09:28,690 ja puskuri siirretään pinosta kekoon. Ja seuraava arvo on pelkkä pituus, tyypillä 102 00:09:28,690 --> 00:09:34,090 not_number, ja seuraava taulukko niitä ei tulla merkitsemään markListSet:iin ja 103 00:09:34,090 --> 00:09:37,390 niitä ei automaattisesti suojella roskien- keruulta. 104 00:09:37,390 --> 00:09:44,010 Mitä tapahtui seuraavaksi, kun erilaisia ominaisuuksia kutsutaan length-ominaisuu- 105 00:09:44,010 --> 00:09:49,370 delle ja siinä yritetään muuttaa not_- number:ia numeroarvoksi käyttäjän määri- 106 00:09:49,370 --> 00:09:54,371 tettyä, että toString-metodi kutsutaan tuossa tapauksessa. ToString-metodi pois- 107 00:09:54,371 --> 00:09:58,400 taa viimeisen viittauksen taulukkoon ja pakottaa roskienkeruusyklin päälle allo- 108 00:09:58,400 --> 00:10:04,070 koimalla ison määrän muistia. Joka johtaa siihen, että olio deallokoidaan roskien- 109 00:10:04,070 --> 00:10:08,450 keruun toimesta. Seuraavaksi se uudelleen- allokoi olion hapantuneen päälle. Tämä oli 110 00:10:08,450 --> 00:10:14,180 miten tätä erityisesti rakennettua use- after-free:tä käytetiin Safarissa koodin 111 00:10:14,180 --> 00:10:19,650 etäajokyvykkyyden saavuttamiseksi ja shell -koodin ajamiseksi. Shell-koodi on mukana 112 00:10:19,650 --> 00:10:25,100 toisessa vaiheessa, missä hyötykuorma koostuu shell-koodista ja tiivistetystä 113 00:10:25,100 --> 00:10:28,460 datasta. Mielenkiintoisin seikka meille on shell-koodi koska sitä käytetään kernelin 114 00:10:28,460 --> 00:10:33,770 hyväksikäyttööön Safari-kontekstissa, ja tiivistetty data on periaatteessa lataaja, 115 00:10:33,770 --> 00:10:38,980 joka lataa ja purkaa salauksen seuraavassa vaiheessa. Yksi haavoittuvuus, jota käy- 116 00:10:38,980 --> 00:10:45,820 tettiin oli CVE 4655 mikä on tiedonvuoto- haavoittuvuus, jota käytettiin kernelin 117 00:10:45,820 --> 00:10:51,050 osoiteavaruussatunnaisuuden päihittämiseen Se hyväksikäyttää sitä, että konstruktori 118 00:10:51,050 --> 00:10:58,140 ja OSUnserializeBinary-metodi eivät tar- kista rajoja. Eli hyökkääjä voi luoda OS- 119 00:10:58,140 --> 00:11:02,070 Number-olion todella suurella bittimää- rällä ja kutsua sitä sovellushiekkalaati- 120 00:11:02,070 --> 00:11:05,670 kossa io_registry_entry_get_property_bytes :lla. 121 00:11:05,670 --> 00:11:10,790 Tältä se näytti. Eli OSUnseralizeBinary- metodi käsittelee binäärin jaksotuksia 122 00:11:10,790 --> 00:11:16,250 kernelille. Se konvertoi binääriformaatin kernelin perus-dataobjektiksi. 123 00:11:16,250 --> 00:11:21,960 Se tukee useita eri tietotyyppejä, listoja , sanakirjoja, tualukkoja, oliotyyppejä, 124 00:11:21,960 --> 00:11:26,720 stringejä, numeroita ja tässä kiinnostava on siis OSNumber. Kuten näeme tässä, sille 125 00:11:26,720 --> 00:11:34,200 annetaan kaksi argumenttia: arvo ja pituus eikä siinä ole oikeaa tarkistusta pituus- 126 00:11:34,200 --> 00:11:39,950 arvolle. Se tarkoittaa että voimme hallita oliolle annettua pituutta. Ja miksi 127 00:11:39,950 --> 00:11:45,440 se on ongelma? Koska tässä on OSNumber: init-konstruktori ja kuten nähdään niin 128 00:11:45,440 --> 00:11:51,770 pituus-arvo, joka annetaan tässä, on new- NumberOfBits ja se ylikirjoittaa pituus- 129 00:11:51,770 --> 00:11:56,060 arvo-muuttujan. Ja ongelma muodostuu siitä, että tuota kokoa käytetään muissa 130 00:11:56,060 --> 00:12:02,040 metodeissa, esimerkiksi OSNumber number- OfBytes:issa, joka johtaa siihen että 131 00:12:02,040 --> 00:12:08,370 paluuarvo numberOfBytes:ille on nyt täysin hyökkääjän hallussa. Mikä on erittäin paha 132 00:12:08,370 --> 00:12:12,400 sillä sitä käytetään seuraavaksi io_regis- try_entry_get_property_bytes:issa, joka 133 00:12:12,400 --> 00:12:17,920 käsittelee OSNumber:eita ja se käyttää tuota numberOfBytes:ia laskeakseen olion 134 00:12:17,920 --> 00:12:24,330 pituuden, OSNumber:n pituuden. Valitetta- vasti se käyttää pinoperustaista puskuria 135 00:12:24,330 --> 00:12:31,600 parsintaan ja tallentaa OSNumber-arvon. Mitä tapahtui seuraavaksi, se kopioi muis- 136 00:12:31,600 --> 00:12:37,420 tin kernelin pinosta kekoon, käyttäen hyök -kääjän hallinnassa olevaa pituutta. Mikä 137 00:12:37,420 --> 00:12:43,960 tarkoittaa että voimme kertoa kuinka mon- ta tavua kopioidaan kernelin pinosta ja 138 00:12:43,960 --> 00:12:52,800 palautetaan käyttäjäavaruuteen. Käy näin: einsimmäiseksi luodaan ominaisuus-taulukko 139 00:12:52,800 --> 00:12:59,950 jossa on sanakirja, jossa on OSNumber pit- källä pituudella, meidän tapauksessa 256. 140 00:12:59,950 --> 00:13:04,560 Seuraavaksi luodaan käyttäjän asiakasoh- jelma kutsumalla IOService open extend:iä 141 00:13:04,560 --> 00:13:11,000 joka deserialisoi tämän OSNumber-olion ja luo tämän olion ytimessä. Ja nyt meidän 142 00:13:11,000 --> 00:13:16,089 täytyy lukea se kutsumalla IORegistry- EntryGetPropertyä, joka johtaa että: 143 00:13:16,089 --> 00:13:22,590 kopioimme 256 tavua kernelin pinomuistia ja tämä ytimen pinomuisti sisältää kernel- 144 00:13:22,590 --> 00:13:26,960 osoittajia. Kernel-osoittajilla voidaan määrittää kernelin perusta. Joten nyt 145 00:13:26,960 --> 00:13:32,850 saamme kernelin perustan selville ja voimme hypätä seuraavaan haavoittuvuuteen, 146 00:13:32,850 --> 00:13:40,110 joka on CVE 4656, use-after-free jolla saavutetaan kernel-tasoinen koodiajo. Se 147 00:13:40,110 --> 00:13:44,180 hyävksikäyttää tietoa, koska setAtIndex- makro ei oikeasti säilytä oliota, ja me 148 00:13:44,180 --> 00:13:48,420 voimme laukaista sen myös sovellushiekka- laatikon sisältä OSUnSerializeBinaryllä. 149 00:13:48,420 --> 00:13:56,940 Ja kertaukseksi, OSUnSerializeBinary on funktio, joka parsii ja deserialisoi 150 00:13:56,940 --> 00:14:01,940 olioita kernelissä. Se tukee erilaisia tietotyyppejä, erilaisia sisältötyyppejä. 151 00:14:01,940 --> 00:14:06,550 Ja mikä on milenkiintoista on se, että se tukee kOSSerialize-oliota. 152 00:14:06,550 --> 00:14:12,490 Se tarkoittaa että voimme luoda viittauk- sen toiseen olioon. Erittäin hyödyllinen 153 00:14:12,490 --> 00:14:18,270 tulevaisuudessa, koska olioiden deseria- lisoinnin ja parsinnan yhteydessä OSUnse- 154 00:14:18,270 --> 00:14:24,490 rializeBinary tallensi olio-osoittimen erityiseen oliotaulukkoon. Ja käyttämällä 155 00:14:24,490 --> 00:14:29,170 setAtIndex:iä siihen. Ja kuten näemme set- AtIndex vain tallentaa olio-osoittimen 156 00:14:29,170 --> 00:14:37,410 taulukkoon johonkin kohtaan, tallentamatta oliota. Se on huono asia, sillä seuraavas- 157 00:14:37,410 --> 00:14:44,200 sa koodissa OSString tyyppimuunnetaan OS- Symbol:iksi se vapauttaa olio-osoittimen. 158 00:14:44,200 --> 00:14:48,790 Mitä se meinaa? Meillä on vieläkin tauluk- ko jossa on kaikki olio-osoittimet joka on 159 00:14:48,790 --> 00:14:55,770 oliotaulukko ja me juuri vapautimme olion, mutta säilytimme olio-osoittimen. Jos me 160 00:14:55,770 --> 00:15:00,200 voimme luoda viittauksen objektiin, voimme hyväskikäyttää use-after-free:tä. Tämä 161 00:15:00,200 --> 00:15:03,560 tapahtuu, sillä kOSSerializeObject sallii meidän luoda viittauksen ja me kutsumme 162 00:15:03,560 --> 00:15:09,410 säilytystä jo valmiiksi deserialisoidulle, deallokoidulle oliolle. Tältä tämä exploit 163 00:15:09,410 --> 00:15:14,490 näyttää. Joten ensimmäiseksi, luomme OS- dictionary:n joka sisältää stringin, joka 164 00:15:14,490 --> 00:15:19,530 tämän bugin vuoksi deallokoidaan. Joten nyt meidän täytyy uudelleenallokoida se 165 00:15:19,530 --> 00:15:27,510 meidän hallinnassa olevalla oliolla, jotta se mahtuu samaan muistipaikkaan. Meidän 166 00:15:27,510 --> 00:15:34,580 tapauksessamme se on OSString, ja muistis- sa oleva OSString-luokka vie 32 tavua. 167 00:15:34,580 --> 00:15:39,930 Meidän täytyy allokoida sama koko. Tähän tarkoitukseen OSData on täydellinen kandi- 168 00:15:39,930 --> 00:15:46,460 taatti sillä me hallitsemme OSData-pusku- ria: sen kokoa ja sisältöä. Me voimme luo- 169 00:15:46,460 --> 00:15:50,860 da tekaistun OSStringin tekaistulla vtab- lella: vtable osoittaa joihinkin numeroi- 170 00:15:50,860 --> 00:15:55,630 hin kernelissä. Viimeiseksi meidän täytyy laukaista use-after-free lisäämällä kOS- 171 00:15:55,630 --> 00:16:01,630 SerializeObject. Joten: OSString deseria- lisoitiin, deallokoitiin, uudelleenallo- 172 00:16:01,630 --> 00:16:05,290 koitiin uuteen olioon joka on OSData-pus- kurissa, joka osoittaa samaan muisti- 173 00:16:05,290 --> 00:16:12,649 paikkaan: Saimme aikaan use-after-free:n. Saavutettuamme use-after-free:n, Pegasus 174 00:16:12,649 --> 00:16:20,290 tekee jotain kernel-paikkauksia kytkeäk- seen pois päältä turvakontrolleja, kuten 175 00:16:20,290 --> 00:16:26,190 setuid:n asettamisen käyttöoikeuksein laa- jentamiseksi, amfi-tsekkausten ohituksen, 176 00:16:26,190 --> 00:16:31,570 poistamalla amfi_get_out_of_my_way:n, kyt- kemällä pois koodin allekirjoitusvaadinnan 177 00:16:31,570 --> 00:16:36,060 ylikirjoittamalla cs_enforcement_disable- muuttujan ja lopulta se uudelleenmounttaa 178 00:16:36,060 --> 00:16:41,720 järjestelmäosion niin, että se on luetta- vissa ja kirjoitettavissa, jotta se voi 179 00:16:41,720 --> 00:16:50,990 suorittaa lataajan jollla se lataa ja pur- kaa seuraavan vaiheen. Seuraavassa vai- 180 00:16:50,990 --> 00:16:58,910 heessa on oikeat vakoiluasiat, joita käy- tetään esim. tekstiviestien, puheluiden ja 181 00:16:58,910 --> 00:17:09,350 henkilökohtaisen datan kuunteluun. Siinä on kolme ryhmää. Yksi on prosessiryhmä, 182 00:17:09,350 --> 00:17:14,850 jossa pääprosessina on kuuntelupalvelu- malli, joka käyttää SIP-protokollaa C2- 183 00:17:14,850 --> 00:17:20,370 kommunikointiin, prosessimanageri ja niin edelleen. Seuraava kiinnostava ryhmä on 184 00:17:20,370 --> 00:17:24,919 dylibs-ryhmä, koska Pegasus nojaa Cydia substrate-jailbreak framework:iin, jonka 185 00:17:24,919 --> 00:17:29,410 he uudelleennimesivät libdata:ksi. Se käyttää Cydia substratea injektoidakseen 186 00:17:29,410 --> 00:17:34,429 dynaamisia kirjastoja sovellusprosessiin. Meidän tapauksessamme meillä oli kirjasto- 187 00:17:34,429 --> 00:17:38,202 ja Viberille, WhatsAppille, joita voitiin injektoida sovellusavaruuteen jotta saa- 188 00:17:38,202 --> 00:17:44,990 tiin sovellushookit asennettua. Ja viimei- senä on com.apple.itunesstored-tiedosto. 189 00:17:44,990 --> 00:17:53,870 Se on JavaScriptiä, joka sisältää shell- koodin joka suoritetaan ja joka voi suo- 190 00:17:53,870 --> 00:18:00,480 rittaa allekirjoittamatonta koodia. Kes- kityn siihen seuraavaksi. Bugi on olemassa 191 00:18:00,480 --> 00:18:06,870 JSC-binäärissä. JSC-binääri on apuri Java- Scripitin ytimelle Apple:lla. Se voi joh- 192 00:18:06,870 --> 00:18:12,330 taa allekirjoittamattoman koodin ajami- seen. Yhdistämällä se rtbuddyd-temppuun 193 00:18:12,330 --> 00:18:18,780 sitä voidaan käyttää saavuttamaan täysi pysyvyys laitteella. Se hyväksikäyttää 194 00:18:18,780 --> 00:18:24,929 huonoa tyyppimuunnosta setEarlyValue-meto- dissa, joka onneksi voidaan laukaista vain 195 00:18:24,929 --> 00:18:32,030 Jesty-sovelluskontekstissa. Joten mikä on ongelmana? Se hyväksikäyttää JavaScript: 196 00:18:32,030 --> 00:18:37,190 issä olevaa ongelmaa sitomalla SetImpure- GetterDelegate:n C++:n funktioon SetImpu- 197 00:18:37,190 --> 00:18:40,880 reGetterDelegate. Tämä funktio ottaa pari argumenttia: yksi on impureGetter ja toi- 198 00:18:40,880 --> 00:18:47,890 nen on geneerinen isObject, joka asetetaan täksi impureGetter-delegaatiksi. 199 00:18:47,890 --> 00:18:54,790 Ongelma on - seuraava dia - että me parsimme kaksi argumenttia ja sitten kut- 200 00:18:54,790 --> 00:18:59,370 sutaan setDelegate:a. SetDelegate kutsuu set:iä, joka lopulta kutsuu setEarlyValuen 201 00:18:59,370 --> 00:19:05,080 Tässä on ongelma, sillä tässä ei ole var- sinaista tarkistusta sille, että olio, 202 00:19:05,080 --> 00:19:10,670 joka annetaan setImpureGetterDelegate:lle on oikeasti ImpureGetter. 203 00:19:10,670 --> 00:19:15,950 Se tarkoittaa, että jos sille annetaan mikä tahansa muu olio, niin sille tehdään 204 00:19:15,950 --> 00:19:21,050 huono tyyppimuunnos ImpureGetter-osoitti- mena. Näin tässä kävi. Eli se on huono 205 00:19:21,050 --> 00:19:28,180 tyyppimuunnos, jossa ei ole varsinaista tarkistusta olion tyypille, mikä johtaa 206 00:19:28,180 --> 00:19:33,200 olion kenttien ylikirjoittamiseen. Tässä on sama funktio, mutta takaisinkäännet- 207 00:19:33,200 --> 00:19:39,620 tynä IDA Pro:lla. Meidän tapauksessa Impu- reGetter on perusmuuttuja tässä, ja dele- 208 00:19:39,620 --> 00:19:46,020 gaatti on tämä geneerinen JS-olio. Näemme, että osoitin joka on perus +16, voidaan 209 00:19:46,020 --> 00:19:50,910 ylikirjoittaa osoittimella delegaattiin. Joka johtaa - näette oikealla JSArray- 210 00:19:50,910 --> 00:19:55,760 BufferView-luokan - jos välitän JSArray- BufferView-luokan ensimmäisenä argument- 211 00:19:55,760 --> 00:20:01,620 tina, m_vector-kenttä ylikirjoitetaan osoittimella delegaattiin. 212 00:20:01,620 --> 00:20:09,720 Mikä on hyvin huono, sillä se voi johtaa luettaviin, kirjoitettaviin primitiiveihin 213 00:20:09,720 --> 00:20:14,429 Hyväksikäyttääkseen tuota, Pegasus käyttää kahta dataview:iä. Minä kutsun niitä data- 214 00:20:14,429 --> 00:20:20,860 view1:ksi ja dataview2:ksi. Niile kutsu- taan ja suoritetaan setImpureGetterDele- 215 00:20:20,860 --> 00:20:24,910 gate molempiin, mikä johtaa dataview1:sen m_vector-kentän ylikirjoittamiseen osoit- 216 00:20:24,910 --> 00:20:31,080 timella dataview2:seen. Ja nyt, asettamal- la ja lukemalla arvot ensimmäisestä data- 217 00:20:31,080 --> 00:20:36,400 view:stä voimme ylikirjoittaa toisen data- view:n tietokentät. Kun tarvitsemme, voim- 218 00:20:36,400 --> 00:20:42,500 me asettaa toisen dataview:n koko prosessi -muistiin ylikirjoittamalla toisen data- 219 00:20:42,500 --> 00:20:46,580 view:n taulukkopuskurin offset:n olemaan 0 ja ylikirjoittamalla toisen dataview:n 220 00:20:46,580 --> 00:20:52,460 pituuden olemaan 4 gigatavua 32-bittisellä prosessilla ja asettamalla tyypiksi fast 221 00:20:52,460 --> 00:20:56,630 array-tyypin. Joten periaatteesas toinen dataview sisältää nyt koko prosessiavaruu- 222 00:20:56,630 --> 00:21:05,390 den ja voimme getint:ata, setint:ata, lukea ja kirjoittaa minne tahansa prosessi 223 00:21:05,390 --> 00:21:09,950 -muistissa. Samaa asiaa voidaan käyttää jopa suoritusprimitiivien hankkimiseen. 224 00:21:09,950 --> 00:21:16,400 Tässä tapauksessa me kutsumme setImpure- GetterDelegate:a kahdesti ja sen sijaan, 225 00:21:16,400 --> 00:21:21,380 että paljastamme koko prosessimuistin me vain vuodamme olion osoitteen. Jos voi- 226 00:21:21,380 --> 00:21:26,530 daan vuotaa olioiden osoitteita, voimme tehdä funktion jolla on satoja tyhjiä try- 227 00:21:26,530 --> 00:21:33,230 catch lauseita ja pakottaa JIT kääntämään se. Ja tässä prosessissa erikoinen luet- 228 00:21:33,230 --> 00:21:38,580 tava, kirjoitettava, suoritettava muisti- alue allokoidaan. Voimme vuotaa tämän 229 00:21:38,580 --> 00:21:45,270 JIT-osion osoitteen, ylikirjoittaa sen shell-koodilla ja suorittaa sen. 230 00:21:45,270 --> 00:21:51,790 Joten tämä on miten huonoa tyyppimuunnosta voidaan käyttää kernelin uudelleenhyväksi- 231 00:21:51,790 --> 00:21:58,040 käyttöön jokaisen buutin yhteydessä. Sitä käytetään pysyvyysmekanismi rtbuddyd:n 232 00:21:58,040 --> 00:22:03,730 kanssa. Ongelmana on että System luo rtbuddyd-palvelun erikoisella early-boot 233 00:22:03,730 --> 00:22:10,500 argumentilla. Eli voidaan ottaa ottaa mikä tahansa toinen binääri, jonka allekirjoit- 234 00:22:10,500 --> 00:22:14,820 tajana on Apple, nimetä se rtbuddyd:ksi ja se ajetaan buutin yhteydessä. Tätä Pegasus 235 00:22:14,820 --> 00:22:20,700 tekee. He ottivat JSC-binäärin, joka on Applen allekirjoittama, nimesivät sen rt- 236 00:22:20,700 --> 00:22:26,900 buddyd:ksi, ja sitten otetaan JavaScript joka sisältää hyväksikäyttökoodin, tehdään 237 00:22:26,900 --> 00:22:31,500 siitä symbolinen linkki, kutsutaan sitä early-boot:illa joka johtaa siihen että: 238 00:22:31,500 --> 00:22:37,130 rtbuddyd ajetaan early-boot:illa, se kut- suu JSC:n sijaan js-exploittia. Tällä 239 00:22:37,130 --> 00:22:46,480 tempulla ja huonolla tyyppimuunnoksella saadaan kernelin hyväksikäytöt jokaisella 240 00:22:46,480 --> 00:22:51,540 bootilla. Pegasus käyttää muutamia kik- koja tehdäkseen takaisinmallinnuksesta 241 00:22:51,540 --> 00:22:57,490 vaikeampaa: se käyttää kertakäyttöisiä linkkejä. Joten klikkauksen jälkeen ne in- 242 00:22:57,490 --> 00:23:02,920 validoidaan ja ne johtavat enää Googleen tai vastaaville sivustoille. Se uudelleen- 243 00:23:02,920 --> 00:23:09,900 salaa kaikki höytykuormat joka latauksella lennosta. Ja tietenkin se yrittää piilou- 244 00:23:09,900 --> 00:23:15,100 tua näyttäen järjestelmäkomponentilta. Tietenkin se myös estää iOS järjestelmä- 245 00:23:15,100 --> 00:23:22,510 päivitykset, varmitaen että laitteita ei voi lennosta päivittää ja korjata. Se 246 00:23:22,510 --> 00:23:30,290 hävittää todisteita: tyhjentämällä Safari- historiaa ja cacheja, ja löysimme itsetuho 247 00:23:30,290 --> 00:23:35,510 -mekanismin joka voidaan aktivoida etänä tai jaastettuna. Sen pelottavan tuettujen- 248 00:23:35,510 --> 00:23:40,710 sovellusten listan lisäksi se tallentaa kaiken mikforonin käytön, kameran käytön, 249 00:23:40,710 --> 00:23:47,250 GPS:n, sijainnin, keychain-salasanat, jopa WiFin ja reitittimen salasanat. Mihin he 250 00:23:47,250 --> 00:23:51,280 tarvitsevat reitittimen salasana? En tiedä Sovellushookkaus. Miten se toimii: kuten 251 00:23:51,280 --> 00:23:57,299 mainitsin ennemmin, se käyttää Cydia sub- stratea ja sen avulla se esilataa dynaami- 252 00:23:57,299 --> 00:24:04,809 sia kirastoja sovellusprosessiin ja saa siepattua kriittiset funktiot. Se 253 00:24:04,809 --> 00:24:10,870 käyttää Cynjectiä injektoituakseen jo käynnissä oleviin prosesseihin. Tässä on 254 00:24:10,870 --> 00:24:18,130 korkean tason kuva, miltä se näyttää. Pegasus saa siepattua kaikki sovellus- ja 255 00:24:18,130 --> 00:24:21,940 kehystason kriittiset funktiot. Joten nyt Pegagus voi hallita niitä, voi kerätä 256 00:24:21,940 --> 00:24:27,570 niitä, voi suorittaa niitä, voi varmistaa niitä, voi lähettää hallintayhteyttä jne. 257 00:24:27,570 --> 00:24:36,150 Yhteenvedoksi: Pegasus on etäkäyttöinen jailbreak jota on havaittu maailmalta. Se 258 00:24:36,150 --> 00:24:42,059 on hyvin pelottava, sillä se ei vaadi mi- tään käyttäjävuorovaikutusta. Viimeksi 259 00:24:42,059 --> 00:24:47,753 nähty samanlainen asia oli viisi vuotta sitten kun comex julkaisi hänen jailbreak- 260 00:24:47,753 --> 00:24:52,920 me 3:sen. Tänä vuonna Luca Todesco käytti yhtä Trident-haavoittuvuuksista hänen jail 261 00:24:54,290 --> 00:24:59,870 -breakissään. Haluan erityisesti kiittää Citizen Labia heidän avustaan Pegasus- 262 00:24:59,870 --> 00:25:05,289 näytteen saamisessa. Kaikkia Lookout:n tutkinta- ja vastetiimissä, Divergent Secu 263 00:25:05,289 --> 00:25:11,310 -rityn tyyppejä ja kaikkia yksityisiä tut- kijoita, jotka olivat mukana. Viimeiseksi 264 00:25:11,310 --> 00:25:17,470 muutamia höydyllisiä linkkejä, joista yksi on 44-sivuinen PDF-raportti hyvin, hyvin 265 00:25:17,470 --> 00:25:23,710 syvillä yksityiskohdilla liittyen haavoit- tuvuuksiin, joita käytettiin, jopa erotel- 266 00:25:23,710 --> 00:25:31,059 len 32- ja 64-bittiset keskenään. Jos olette kiinnostuneita, tsekatkaa ne. 267 00:25:31,059 --> 00:25:33,280 Tämä oli tässä luullakseni, onko teillä mitään kysymyksiä? 268 00:25:33,290 --> 00:25:41,562 *aplodeja* 269 00:25:44,682 --> 00:25:48,432 M: Mmm hmm. H: Ok, pitäkää tämä lyhyenä. Meillä on 270 00:25:48,432 --> 00:25:50,470 vain muutama minuutti aikaa kysymyksille, jos teillä on niitä menkää hallissa ole- 271 00:25:50,470 --> 00:25:56,830 ville mikrofoneille. Ja me aloitamme Sig- naalienkelillä Internetistä. 272 00:25:56,830 --> 00:26:03,530 SE: Kiitos, onko mitään tapaa rakentaa sovellus niin, että se on suojeltu tältä? 273 00:26:03,530 --> 00:26:13,160 M: Kyllä ,koska Pegasus käyttää joitain tunnettuja jailbreak-tekniikoita, on mah- 274 00:26:13,160 --> 00:26:18,480 dollista havaita esimerkiksi että järjes- telmäosio on uudelleenmountattu luettavana 275 00:26:18,480 --> 00:26:23,650 ja kirjoiettavana. Se voi olla yksi indi- kaattori että jokin geneerinen jailbreak 276 00:26:23,650 --> 00:26:29,900 on ajossa laitteella. Tai esim. tsekata Pegasuksen käyttämien tiedostojen varalta, 277 00:26:29,900 --> 00:26:33,870 mutta parempi tapa on tsekata geneerisen jailbreak-pagejen, kernel-pagejen varalta. 278 00:26:33,870 --> 00:26:37,540 *yleisön liikkeen ääniä* H: Voitteko yrittää olla vähän hiljempaa. 279 00:26:37,540 --> 00:26:40,170 Meillä on yhä Q&A kesken. Jos teidän ei täydy lähteä nyt, jääkää istuutumaan tai 280 00:26:40,170 --> 00:26:47,100 jos teidän täytyy lähteä nyt, älkää puhuko. Mikrofoni kolme, olkaa hyvät. 281 00:26:47,100 --> 00:26:50,200 M3: Mikä on käyttäjän kokemus tästä? 282 00:26:50,200 --> 00:26:53,480 M: Käyttäjän kokemus? Tarkoitatteko siis - tarkoitatteko että kun laite saastuu 283 00:26:53,480 --> 00:26:59,071 Pegasuksella? Pelottavaa tässä itse asiassa on se ettei siitä oikein ole 284 00:26:59,071 --> 00:27:07,110 mitään jälkiä, mitään indikaattoreita että jotain on käynyt. Klikkaat linkkiä, 285 00:27:07,110 --> 00:27:13,080 laitteen web-selain aukeaa ja kaatuu sulkeutuen. Ei ole mitään uusia sovelluk- 286 00:27:13,080 --> 00:27:19,340 sia joita voi nähdä näkyvistä sovelluksis- ta, vaikka oikeasti laitteella on kolme 287 00:27:19,340 --> 00:27:26,390 uutta järjestelmäpalvelua, mutta ne eivät näy käyttäjälle. 288 00:27:26,390 --> 00:27:29,370 H: Kiitos. Ja seuraavaksi toinen kysymys Internetistä. 289 00:27:29,370 --> 00:27:33,300 SE: Kiitos. Onko teillä mitään käsitystä, kuinka aktiivinen tämä on maailmalla? 290 00:27:33,300 --> 00:27:39,590 M: Toistaisitteko, kiitän? SE: Onko teillä mitään käsitystä, kuinka 291 00:27:39,590 --> 00:27:46,580 aktiivinen tämä exploit on maailmalla? M: Olen varma että se on hyvin kohdistettu 292 00:27:46,580 --> 00:27:51,860 hyökkäys, koska nämä ovat erittäin, erit- täin kalliita hyävksikäyttömenetelmiä. 293 00:27:51,860 --> 00:27:59,770 Zerodium esimerkiksi maksaa nyt 1,5 mil- joonaa tällaisesta etä-jailbreakistä joten 294 00:27:59,770 --> 00:28:06,860 en luule, että nämä toimijat tämän vakoilu -ohjelmiston takana halua tehdä tästä 295 00:28:06,860 --> 00:28:11,960 haittaohjelmasta helpommin saavutettavaa kiakille. Joten se on hyvin, hyvin kohdis- 296 00:28:11,960 --> 00:28:19,690 tettu hyökkäys. Tiedämme Mansoorin tapauk- sesta, joten ajattelen että se on hyvin, 297 00:28:19,690 --> 00:28:22,480 hyvin kohdistettua, koska se on erittäin kallista. 298 00:28:22,480 --> 00:28:26,590 H: Kiitokset tästä vastauksesta. Mikrofoni numero viisi, kiitos. 299 00:28:26,590 --> 00:28:33,300 M5: Onko teillä mitään lisätietoa NSO:sta tai ryhmästä, joka on sen takana? Käyttä- 300 00:28:33,300 --> 00:28:38,720 vätkö he muita ohjelmistoja? Ja onko tämä kuinka paljon levinnyt maailmalla? 301 00:28:38,720 --> 00:28:42,919 M: Joo, eli tässä tapauksessa keskityimme lähinnä Pegasuksen teknisiin yksityis- 302 00:28:42,919 --> 00:28:49,809 kohtiin, mutta Citizen Lab on suorittanut tutkinnan NSO:hon liittyen ja NSO on taval 303 00:28:49,809 --> 00:28:56,600 -laan kyberasetoimittaja. Tutustukaa Citi- zen Labin raporttiin aiheesta. 304 00:28:56,600 --> 00:29:00,140 Heillä on paljon enemmän tietoa siinä. 305 00:29:02,280 --> 00:29:07,750 H: Onko meillä kysymyksiä Internetistä? Enkö näe jotakuta? Ei, no sitten tämä oli 306 00:29:07,750 --> 00:29:10,150 tässä. Kiitoksia puheestanne. 307 00:29:10,150 --> 00:29:14,480 *aplodeja* 308 00:29:15,091 --> 00:29:24,670 *jälkimusiikkia* 309 00:29:24,670 --> 00:29:37,610 Tekstitykset luotu c3subtitles.de:llä vuonna 2022. Liity ja auta meitä! 310 00:29:37,610 --> 00:29:39,000 [Translated by {Iikka}{Yli-Kuivila} (ITKST56 course assignment at JYU.FI)]