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)]