0:00:00.000,0:00:00.958
[Translated by {Iikka}{Yli-Kuivila}[br](ITKST56 course assignment at JYU.FI)]
0:00:00.958,0:00:13.699
33C3 preroll music
0:00:13.699,0:00:17.760
Herald: The Max is a security researcher[br]at Lookout has been doing this about 10
0:00:17.760,0:00:22.780
years, he spent a lot of time in[br]obfuscation, exploit development, security
0:00:22.780,0:00:28.160
research, previous Black Hat speaker,[br]currently focused on mobile security
0:00:28.160,0:00:33.579
research and working on his PhD. He'll be[br]telling you about some of the internals of
0:00:33.579,0:00:38.210
Pegasus malware today. With that, I will[br]turn over to Max to take it away.
0:00:38.210,0:00:39.529
Max: Thank you.
0:00:39.529,0:00:47.090
applause
0:00:47.090,0:00:51.660
M: Hi, everyone, say my name[br]is Max Bazaliy, and today we'll talk about
0:00:51.660,0:00:57.609
the Pegasus Internals. I'm from Kiev,[br]Ukraine, currently work as a security
0:00:57.609,0:01:02.370
researcher at Lookout and last few years[br]focused on a jailbreak techniques. So
0:01:02.370,0:01:06.540
that's why I co-founded the Fried Apple[br]team and we're working on a various
0:01:06.540,0:01:12.979
iOS jailbreak, including eight and nine.[br]So Pegasus. Pegasus is a high quality
0:01:12.979,0:01:19.704
espionage software that can be used for[br]complete surveillance of a device. Just
0:01:19.704,0:01:23.710
everything from stealing your personal[br]data up to remotely activating a
0:01:23.710,0:01:30.870
microphone or camera on a device without[br]any indication it's really happening. So
0:01:30.870,0:01:35.820
in order Pegasus to work, it need to[br]jailbreak a device first because the iOS
0:01:35.820,0:01:40.570
sandbox prevents application from spying[br]on each other. So that's why Pegasus rely
0:01:40.570,0:01:49.320
on a trident exploit chain to completely[br]own a device and install persistence that
0:01:49.320,0:01:55.250
can be used on each device. Here's a[br]really terrifying list of targeted apps,
0:01:55.250,0:02:03.102
including even the known as most secure[br]ones, like Telegram, WhatsApp, Viber. And
0:02:03.102,0:02:08.259
I'm pretty sure you can find your favorite[br]messenger in this list. Before going into
0:02:08.259,0:02:12.150
a deep technical analysis of the[br]vulnerabilities used, I want to tell a
0:02:12.150,0:02:18.300
story how we get it - a Pegasus sample. So[br]police met Ahmed Mansoor, who's mostly
0:02:18.300,0:02:23.239
known for his job as a human right[br]defender. He's even a recipient of Martin
0:02:23.239,0:02:29.459
Ennals award, sometimes called the Nobel[br]Prize for Human Rights. So I understand
0:02:29.459,0:02:39.530
this year Ahmed received a message with a[br]text that someone in a state prison got -
0:02:39.530,0:02:45.640
someone is imprisoned in a state prison.[br]So and he received another text with a
0:02:45.640,0:02:52.300
similar thing the next day. But previously[br]he was targeted by hacking team in 2012
0:02:52.300,0:02:58.910
and got FinFisher in 2011. So now, instead[br]of clicking on the link, he contacted the
0:02:58.910,0:03:03.040
Citizen Lab because he was working with[br]those guys before. So he sent a link for
0:03:03.040,0:03:09.469
Citizen Lab to analysis and we are in[br]Lookout research team. We get initial
0:03:09.469,0:03:13.989
sample and a link from a Citizen Lab. So[br]in this story, I mostly will focusing
0:03:13.989,0:03:23.840
about technical, part. So in order to work[br]- Pegasus rely on the Trident exploit
0:03:23.840,0:03:29.819
chain and it uses three stages. So on the[br]first stage, it uses a memory corruption
0:03:29.819,0:03:34.659
to achieve a remote code execution in a[br]Safari context. After that, it jumps -
0:03:34.659,0:03:38.549
after this on a device - it jumps to a[br]second stage and uses two vulnerabilities
0:03:38.549,0:03:42.299
to exploit the kernel. One is used for by[br]- by the Kernel Address Space layout
0:03:42.299,0:03:47.590
randomisation and another to achieve[br]kernel - a remote - a kernel code
0:03:47.590,0:03:51.510
execution kernel level code execution.[br]And finally, on the third stage it
0:03:51.510,0:03:57.950
installs espionage software and uses a[br]special trick to achieve on device
0:03:57.950,0:04:03.040
persistence. So I will focus on each stage[br]more detailed. The first stage, as they
0:04:03.040,0:04:08.920
say, is a single use spear-phish url that[br]will be invalidated after the first click.
0:04:08.920,0:04:13.629
It contains obfuscated JavaScript that[br]first thing it do it checking for a device
0:04:13.629,0:04:20.340
type: Is it iPhone, is it iPad, is it 32[br]or 64 bit. And based on information about
0:04:20.340,0:04:25.730
device processor type the different[br]versions of shellcode will be downloaded.
0:04:25.730,0:04:30.380
Which is in stage two. And finally[br]exploits remote code execution
0:04:30.380,0:04:34.525
vulnerability in a webkit in order to[br]execute the shellcode. So what
0:04:34.525,0:04:42.600
vulnerability will it use it? CVE 4657[br]remote code execution in WebKit. Basically
0:04:42.600,0:04:46.910
the vulnerability is use after free that[br]achieved by using two bugs and in a sample
0:04:46.910,0:04:52.940
that we got it's not stable because it[br]relies on WebKit garbage collector. The
0:04:52.940,0:04:57.760
problem itself lives in a -[br]MarkedArgumentBuffer that can be exploited
0:04:57.760,0:05:02.030
by usage of the defined properties. So[br]defined properties is a method that
0:05:02.030,0:05:07.870
defines new or modified properties[br]directly on object. It takes a few
0:05:07.870,0:05:13.540
arguments and the object itself and the[br]properties objects which can have
0:05:13.540,0:05:20.910
descriptors that constitute the property[br]to be defined or modified. It have a
0:05:20.910,0:05:26.070
pretty simple algorithm, it contain few[br]loops on the very first iteration of each
0:05:26.070,0:05:30.090
property descriptor checking for a[br]formatting and after that get appended to
0:05:30.090,0:05:35.790
a descriptor's vector and to make sure[br]that the reference to property descriptors
0:05:35.790,0:05:40.020
do not become stale, they need to be[br]protected from being garbage collected.
0:05:40.020,0:05:44.740
For this purpose MarkedArgumentBuffer is[br]used. We see it at the very very end,
0:05:44.740,0:05:49.530
MarkedArgumentBuffer append. So[br]MarkedArgumentBuffer prevents objects from
0:05:49.530,0:05:59.250
being deallocated. And after each property[br]-get has been validated and it's okay, the
0:05:59.250,0:06:03.240
defineOwnProperty associate each user[br]supplied property with a target object.
0:06:03.240,0:06:08.150
And here is a problem, because it's possi-[br]ble when the defineProperty will be called
0:06:08.150,0:06:13.610
it's possible to call any user defined[br]JavaScript methods. If in these JavaScript
0:06:13.610,0:06:19.810
methods garbage collection can be[br]triggered, it will deallocate any unmarked
0:06:19.810,0:06:26.410
heap-backed object. I will go a little bit[br]deeply in the details. First of all, a few
0:06:26.410,0:06:30.390
words about MarkedArgumentBuffer and[br]JavaScript garbage collector. So
0:06:30.390,0:06:33.640
JavaScript garbage collector is respon-[br]sible for deallocating an object from
0:06:33.640,0:06:37.900
a memory when they are no longer[br]referenced. It runs at a - random
0:06:37.900,0:06:42.670
intervals and based on the current memory[br]pressure, the current device types and so
0:06:42.670,0:06:48.550
on. And when garbage collector checking if[br]objects should be deallocated, it walks
0:06:48.550,0:06:53.190
through the stack and check for reference[br]to an object. A reference to an object
0:06:53.190,0:06:57.500
also may exist in the application heap,[br]but in this case an alternative is used
0:06:57.500,0:07:04.140
called the slowAppend. So[br]MarkedArgumentBuffer is initial inline
0:07:04.140,0:07:10.510
stack contains eight values. Well, that's[br]mean when the ninth value will be added to
0:07:10.510,0:07:15.570
the MarkedArgumentBuffer the capacity will[br]be expanded. It will be moved from a stack
0:07:15.570,0:07:25.840
memory to a heap memory. This is what the[br]slowAppend is doing. SlowAppend move stack
0:07:25.840,0:07:31.810
from a - move buffer from a stack to a[br]heap, and now object not automatically
0:07:31.810,0:07:37.060
protected from a garbage collection. And[br]to make sure they were not deallocated,
0:07:37.060,0:07:45.650
they need to be added to heap's[br]markListSet. This is what we see here. So
0:07:45.650,0:07:50.170
slowAppend trying to acquire heap context[br]and it can be acquired adding an object
0:07:50.170,0:07:59.639
like, marking an object into markListSet.[br]And here is a problem, because when the
0:07:59.639,0:08:02.940
heap context can be acquired, it can be[br]acquired for a complex object, only for a
0:08:02.940,0:08:08.110
complex object. So this mean for primitive[br]types like integer, booleans and so on,
0:08:08.110,0:08:14.450
they're not heap backed object and they'll[br]be not marked as a markListSet. And there
0:08:14.450,0:08:20.480
is a bug in the slowAppend. We should be[br]able to call it just once. So this mean
0:08:20.480,0:08:27.720
when the buffer will be moved from a stack[br]memory to a heap memory and one of the
0:08:27.720,0:08:31.750
properties will be a simple type, like an[br]integer, so they're not automatically
0:08:31.750,0:08:35.959
protected by garbage collection and all[br]the next corresponding values will be not
0:08:35.959,0:08:41.610
protected as well because of the bug in[br]the slowAppend. Here is a picture that's
0:08:41.610,0:08:46.820
illustrating it and in reality the[br]reference to JavaScript objects still
0:08:46.820,0:08:53.330
exist. But if, uh, in a in a call to[br]definedOwnProperty method, any of the user
0:08:53.330,0:08:57.360
supplied methods will be called, they[br]can remove this reference and object will
0:08:57.360,0:09:03.460
be deallocated. So to summarize, all the[br]information here is how it can be
0:09:03.460,0:09:09.620
exploited. So we specify an props object[br]which contain 12 descriptors and first
0:09:09.620,0:09:16.401
nine of them values are simple typed, like[br]zeroes, eight. Which mean that p8, which
0:09:16.401,0:09:22.510
is the ninth value bit will be added to[br]markListSet. It will trigger the
0:09:22.510,0:09:28.690
slowAppend and the buffer will be moved[br]from a stack to a heap. And the next
0:09:28.690,0:09:34.090
corresponding value is just - length and[br]which not_number and array will be not
0:09:34.090,0:09:37.390
marked by markListSet and not[br]automatically protected by garbage
0:09:37.390,0:09:44.010
collection. What happened next, when[br]different properties will be called on the
0:09:44.010,0:09:49.370
length property and you'll try to convert[br]not_number to a number which for that
0:09:49.370,0:09:54.371
user's defined it toString method will be[br]called. The toString method remove the
0:09:54.371,0:09:58.400
last reference for an array and forces the[br]garbage collection cycle by allocating a
0:09:58.400,0:10:04.070
large amount of memory. Which leads that[br]object will be deallocated by garbage
0:10:04.070,0:10:08.450
collector. The very next thing it is doing[br]is reallocate the new object over a stale
0:10:08.450,0:10:14.180
one. So this is how specially crafted use[br]after free was used in Safari to achieve
0:10:14.180,0:10:19.650
remote code execution and to execute a[br]shellcode. The shellcode exist in a second
0:10:19.650,0:10:25.100
stage, which is a payload which contained[br]the shellcode and compressed data. The
0:10:25.100,0:10:28.460
most interesting for us is the shellcode[br]because it's used for a kernel
0:10:28.460,0:10:33.770
exploitation in Safari context and the[br]compressed data basically is a loader
0:10:33.770,0:10:38.980
that downloads and decrypts the next[br]stage. One of the vulnerabilities used is
0:10:38.980,0:10:45.820
a CVE 4655, which is a info leak that's[br]used to bypass a kernel address layout
0:10:45.820,0:10:51.050
randomization. It exploits the information[br]that constructor and OSUnseralizeBinary
0:10:51.050,0:10:58.140
method they miss bound checking. So that[br]mean that attacker can create OSNumber
0:10:58.140,0:11:02.070
object with a really high number of bits[br]and call it within the application sandbox
0:11:02.070,0:11:05.670
where[br]io_registry_entry_get_property_bytes.
0:11:05.670,0:11:10.790
Here's how it looked like. So[br]OSUnseralizeBinary method to handle binary
0:11:10.790,0:11:16.250
serializations in a kernel. It converts a[br]binary format to basic kernel data object.
0:11:16.250,0:11:21.960
It supports different container types,[br]sets, dictionaries, array, object types,
0:11:21.960,0:11:26.720
strings, numbers and the point of interest[br]in this is the OSNumber. So as we see
0:11:26.720,0:11:34.200
here, it passed two arguments: value and[br]length and there is no real check that for
0:11:34.200,0:11:39.950
- for length property. So this mean we can[br]control the length that is passed to an
0:11:39.950,0:11:45.440
object. And why it is a problem, because[br]here is a constructor for OSNumber:init
0:11:45.440,0:11:51.770
and as we see the length property passed[br]here is newnNumberOfBits and it
0:11:51.770,0:11:56.060
overrides the size variable. And the[br]problem that size is used in other
0:11:56.060,0:12:02.040
methods, in a case that OSNumber[br]numberOfBytes, which leads it return value
0:12:02.040,0:12:08.370
of numberOfBytes is now fully controlled[br]by attacker. Which is real bad because
0:12:08.370,0:12:12.400
it's used next in[br]io_registry_entry_get_property_bytes which
0:12:12.400,0:12:17.920
handle OSNumbers and its use numberOfBytes[br]to calculate the object's length, the
0:12:17.920,0:12:24.330
OSNumber length. But unfortunately it use[br]a stack based buffer to parse and save
0:12:24.330,0:12:31.600
OSNumber value. And what happened next, it[br]is copying memory from kernel stack to
0:12:31.600,0:12:37.420
heap used the attacker controlled length.[br]Which mean we can specify how many bytes
0:12:37.420,0:12:43.960
will be copied from a kernel stack and[br]returned to user land. This is what
0:12:43.960,0:12:52.800
happens: the first thing we are doing, we[br]are create a properties array that have a
0:12:52.800,0:12:59.950
dictionary which have a OSNumber with a[br]high length in our case, is 256. Next, we
0:12:59.950,0:13:04.560
need to spawn the user client by calling[br]IOService open extended, which will
0:13:04.560,0:13:11.000
deserialize this OSNumber object and crea-[br]te this object in the - in the kernel. And
0:13:11.000,0:13:16.089
now we need to read it by calling the[br]IORegistryEntryGetProperty, which leads it
0:13:16.089,0:13:22.590
- we copied the 256 bytes of the kernel[br]stack memory and the kernel stack memory
0:13:22.590,0:13:26.960
will contain kernel pointers. And from a[br]kernel pointer, we can determine the
0:13:26.960,0:13:32.850
kernel base. So now we get a kernel base[br]and we can jump to the next vulnerability,
0:13:32.850,0:13:40.110
which is CVE 4656 it is use-after-free to[br]achieve kernel level code execution. It
0:13:40.110,0:13:44.180
exploits information because the[br]setAtIndex macro does not really retain an
0:13:44.180,0:13:48.420
object and we can trigger it within the[br]application sandbox from
0:13:48.420,0:13:56.940
OSUnserializeBinary. Again the[br]OSUnserializeBinary it's a function that
0:13:56.940,0:14:01.940
parse and deserialize objects in the[br]kernel - it support different data types -
0:14:01.940,0:14:06.550
different container types. And the[br]interesting thing it supports kOSSerialize
0:14:06.550,0:14:12.490
object. It means that we can create a[br]reference to another object. Really
0:14:12.490,0:14:18.270
useful in the future, because in a way of[br]deserializing and parsing objects
0:14:18.270,0:14:24.490
OSUnserializeBinary saved object pointer[br]to a special objects array. And using
0:14:24.490,0:14:29.170
setAtIndex for it. And as we see[br]setAtIndex just save object pointer to
0:14:29.170,0:14:37.410
array with some index not retaining it.[br]It's bad, because the next code, which
0:14:37.410,0:14:44.200
casting OSString to a OSSymbol it is[br]releasing the object pointer. What does it
0:14:44.200,0:14:48.790
mean? We still have an array that holds[br]all the object pointers, which is objects
0:14:48.790,0:14:55.770
array, and we just released one of the[br]objects but still hold the pointer. If we
0:14:55.770,0:15:00.200
can create a reference to an object we can[br]exploit use-after-free. This is what
0:15:00.200,0:15:03.560
happens because kOSSerializeObject allows[br]us to create a reference and we will just
0:15:03.560,0:15:09.410
call retain on already deserialized,[br]already deallocated object. This is how
0:15:09.410,0:15:14.490
exploit look like. So first of all, we[br]create OSdictionary and it will contain a
0:15:14.490,0:15:19.530
string that due the bug will be[br]deallocated. So now we need to reallocate
0:15:19.530,0:15:27.510
it with our controlled object to fit in[br]the same memory spot. It's OSString in our
0:15:27.510,0:15:34.580
case, OSString class in a memory will be[br]32 bytes. We need to allocate the same
0:15:34.580,0:15:39.930
size. For this purpose OSData is a perfect[br]candidate because we can control OSData
0:15:39.930,0:15:46.460
buffer, buffer size and buffer content. So[br]what we can do, we can create a fake
0:15:46.460,0:15:50.860
OSString with a fake vtable and this fake[br]vtable will point to some digits in the
0:15:50.860,0:15:55.630
kernel. The very last thing we need to do[br]is trigger a user-after-free by adding a
0:15:55.630,0:16:01.630
kOSSerializeObject. So once again,[br]OSString got deserialized, deallocated,
0:16:01.630,0:16:05.290
reallocated to a new object, which is[br]OSData buffer, which will point to the
0:16:05.290,0:16:12.649
same memory spot: we've got a use-after-[br]free. So after getting use-after-free,
0:16:12.649,0:16:20.290
Pegasus uses some kernel patches to[br]disable security checks like setuid to
0:16:20.290,0:16:26.190
easily escalate the privileges, bypass[br]amfi checks by patching out
0:16:26.190,0:16:31.570
amfi_get_out_of_my_way, disable code[br]signment enforcement by patching
0:16:31.570,0:16:36.060
cs_enforcement_disable variable and[br]finally, a remount the system partition to
0:16:36.060,0:16:41.720
be readable, & writable so it can execute[br]a loader for the next stage to download
0:16:41.720,0:16:50.990
and decrypt the next stage. The next stage[br]contain the real espionage stuff that will
0:16:50.990,0:16:58.910
be used to sniff all the like SMS, all the[br]calls, all the like personal data. It have
0:16:58.910,0:17:09.350
a three groups. One is a process group[br]which have a main process: sniffing
0:17:09.350,0:17:14.850
services model that use a SIP protocol to[br]communicate with command control like a
0:17:14.850,0:17:20.370
process manager and so on. The next[br]interesting thing is a group of the
0:17:20.370,0:17:24.919
dylibs, because Pegasus rely on the Cydia[br]substrate - the jailbreak framework called
0:17:24.919,0:17:29.410
- they renamed it as libdata. It uses[br]Cydia substrate to inject dynamic
0:17:29.410,0:17:34.429
libraries into application process. So in[br]our case, we have a dynamic libraries for
0:17:34.429,0:17:38.202
Viber, for Whatsapp which can be injected[br]into the application space to install
0:17:38.202,0:17:44.990
application hooks. And the last thing is[br]com.apple.itunesstored file. Which is a
0:17:44.990,0:17:53.870
JavaScript that contain code and the[br]shellcode that will execute - that can
0:17:53.870,0:18:00.480
execute unsigned code. I will focus on it[br]next. So the bug exists in a JSC binary.
0:18:00.480,0:18:06.870
JSC binary is like a helper for JavaScript[br]core, JavaScript and in Apple. And
0:18:06.870,0:18:12.330
it can lead to unsigned code execution. In[br]combination with rtbyddyd trick it can be
0:18:12.330,0:18:18.780
used to completely gain persistence on the[br]device. It exploits that it is a bad cast
0:18:18.780,0:18:24.929
in setEarlyValue method and fortunately it[br]can be triggered only from Jesty
0:18:24.929,0:18:32.030
application context. So what is a problem?[br]It exploits the problem in JavaScript
0:18:32.030,0:18:37.190
binding SetImpureGetterDelegate which have[br]in C++ for function
0:18:37.190,0:18:40.880
SetImpureGetterDelegate. This function[br]takes a few arguments - one is the
0:18:40.880,0:18:47.890
impureGetter and the second one is a[br]generic isObject that will be set as this
0:18:47.890,0:18:54.790
impureGetter delegate. The problem will be[br]next slide - so we just parse two
0:18:54.790,0:18:59.370
arguments and call a setDelegate. The[br]setDelegate called set which finally
0:18:59.370,0:19:05.080
called setEarlyValue. Here is a problem,[br]because there is no real check that the
0:19:05.080,0:19:10.670
object type passed to[br]setImpureGetterDelegate is really
0:19:10.670,0:19:15.950
ImpureGetter. So this means that if any[br]other object type will be passed, it will
0:19:15.950,0:19:21.050
be improperly downcasted as ImpureGetter[br]pointer. That's what happened here. So
0:19:21.050,0:19:28.180
it's a bad cast that have no real check[br]for object type and which lead that we can
0:19:28.180,0:19:33.200
overwrite on those object fields. Here are[br]the same function, but now decompiled in IDA
0:19:33.200,0:19:39.620
Pro. So in our case ImpureGetter is a base[br]variable here and the delegate is this
0:19:39.620,0:19:46.020
generic JS object. We see that the[br]pointer, which is base plus 16, can be
0:19:46.020,0:19:50.910
overridden with a pointer to a delegate.[br]Which lead - you see on the right
0:19:50.910,0:19:55.760
JSArrayBufferView class - if I pass[br]JSArrayBufferView class as a first
0:19:55.760,0:20:01.620
argument, the m_vector field will be[br]overwritten with a pointer to a delegate.
0:20:01.620,0:20:09.720
Which is really bad, because it can lead[br]to readable, writeable primitives. To
0:20:09.720,0:20:14.429
exploit that Pegasus uses two dataviews. I[br]will call them dataview one and dataview
0:20:14.429,0:20:20.860
two. And to call and[br]setImpureGetterDelegate on both, which
0:20:20.860,0:20:24.910
leads it m_vector field in the first[br]dataview will be overwritten with the
0:20:24.910,0:20:31.080
pointer for the second dataview. And now[br]by setting and reading the values on the
0:20:31.080,0:20:36.400
first dataview we can override object[br]fields in the second. While we need it, we
0:20:36.400,0:20:42.500
can map the second dataview as entire[br]process memory by overwriting the second
0:20:42.500,0:20:46.580
dataview arraybuffer offset to be zero by[br]overwriting the second dataview length to
0:20:46.580,0:20:52.460
be four gigabytes in a case of 32 bit[br]process and set type as fast array type.
0:20:52.460,0:20:56.630
So basically the second dataview now is[br]mapped to the entire process space and we
0:20:56.630,0:21:05.390
can getint, setint to get arbitrary read[br]and write anywhere in the process memory.
0:21:05.390,0:21:09.950
The same thing can be used even to get[br]execution primitive. But in this case, we
0:21:09.950,0:21:16.400
can call setImpureGetterDelegate twice and[br]instead of exposing the entire process
0:21:16.400,0:21:21.380
memory, we can leak just an object[br]address. If you can leak an object
0:21:21.380,0:21:26.530
address, we can produce a function that[br]have like hundreds of try - empty try-
0:21:26.530,0:21:33.230
catch constructions and force JIT to[br]compile it. And in a - in this process, a
0:21:33.230,0:21:38.580
special, readable, writeable, executable[br]memory segment will be allocated. We can
0:21:38.580,0:21:45.270
leak address of this JIT segment,[br]overwrite it with a shellcode and execute.
0:21:45.270,0:21:51.790
So this is how the bad cast can be used to[br]like re-exploit even a kernel on each
0:21:51.790,0:21:58.040
boot. It is used with a persistence[br]mechanism which is rtbuddyd. So the
0:21:58.040,0:22:03.730
problem is that System spawning rtbuddyd[br]service with a special early-boot
0:22:03.730,0:22:10.500
argument. This mean if you take any other[br]binary signed by Apple and name it as
0:22:10.500,0:22:14.820
rbuddyd, it will be spawned on a boot.[br]That is what the Pegasus is doing. So they
0:22:14.820,0:22:20.700
take JSC binary which is signed by Apple,[br]name it as rtbuddyd, then take a
0:22:20.700,0:22:26.900
JavaScript that contain exploit. Make it a[br]sym link, call it early-boot which leads
0:22:26.900,0:22:31.500
to when the rtbuddyd will be spawned it[br]with early-boot it will call JSC with the
0:22:31.500,0:22:37.130
js-exploit instead. So with this trick and[br]the bad cast it re-exploits kernel on
0:22:37.130,0:22:46.480
each device boot. There is some tricks[br]the Pegasus use to make it harder to
0:22:46.480,0:22:51.540
reverse engineer, like use one time links.[br]So after you click on any of the link
0:22:51.540,0:22:57.490
they'll be invalidated and now redirect to[br]Google or other sites. It re-encrypts all
0:22:57.490,0:23:02.920
the payloads each time they are downloaded[br]just on the fly. And of course, they are
0:23:02.920,0:23:09.900
trying to hide itself to make it look like[br]a system component. Um, of course, it
0:23:09.900,0:23:15.100
blocks iOS system updates to make sure you[br]can't - you cannot batch your device just
0:23:15.100,0:23:22.510
on the fly, to clear all the evidence:[br]clear Safari history and caches and we
0:23:22.510,0:23:30.290
found a self-destruct mechanism that can[br]be triggered remotely or on a time out. So
0:23:30.290,0:23:35.510
in addition to this terrifying list of[br]supported applications, it records any
0:23:35.510,0:23:40.710
microphone usage, any camera usage, GPS,[br]location, keychain passwords, even
0:23:40.710,0:23:47.250
including the Wi-Fi and the router one.[br]Why they need router - I don't know.
0:23:47.250,0:23:51.280
Application hooking. So how how it[br]operates. As I mentioned earlier, it use
0:23:51.280,0:23:57.299
Cydia substrate and with the help of Cydia[br]substrate it preloads dynamic libraries
0:23:57.299,0:24:04.809
into application process and intercept[br]some critical functions. It uses Cynject
0:24:04.809,0:24:10.870
to run into already - into already running[br]processes. So this is like a high level
0:24:10.870,0:24:18.130
picture of how it looks like. So all the[br]application level critical functions and
0:24:18.130,0:24:21.940
the framework level critical functions are[br]intercepted by Pegasus. So now Pegasus can
0:24:21.940,0:24:27.570
control them, can collect them, can back[br]them, can send Command & Control and so
0:24:27.570,0:24:36.150
on. To summarize, Pegasus is a remote[br]jailbreak spotted in the wild. It's pretty
0:24:36.150,0:24:42.059
scary because it doesn't require any user[br]interaction. And the last similar thing
0:24:42.059,0:24:47.753
was like five years ago when the comex[br]released his jailbreakme 3. This year Luca
0:24:47.753,0:24:52.920
Todesco used one of the Trident[br]vulnerabilities for his jailbreaking.
0:24:54.290,0:24:59.870
I want to say a special thanks to Citizen[br]Lab for helping out with achieving a
0:24:59.870,0:25:05.289
Pegasus sample. All the Lookout research &[br]response team, the Divergent security guys
0:25:05.289,0:25:11.310
and all the individual researchers who was[br]involved in the research. So last some
0:25:11.310,0:25:17.470
useful links which contain a 44 page PDF[br]report with a really, really deep details
0:25:17.470,0:25:23.710
on the vulnerabilities that is used even[br]with the difference between 32 and 64 bit
0:25:23.710,0:25:31.059
ones. So if you're interested in. Please[br]take a look. I think this is it do you
0:25:31.059,0:25:33.280
guys have any questions?
0:25:33.290,0:25:41.562
applause
0:25:44.682,0:25:48.432
M: Mm hmm.[br]H: OK, please keep it brief. We only have
0:25:48.432,0:25:50.470
some minutes left for the questions, and[br]if there are any questions, please go to
0:25:50.470,0:25:56.830
the microphones in the hall. And we start[br]with the Signal Angel from the Internet.
0:25:56.830,0:26:03.530
SA: Thank you. Is there any way to build[br]your app, protect it from this exploit?
0:26:03.530,0:26:13.160
M: Yes, it is, because the Pegasus use[br]some of the known jailbreak techniques it
0:26:13.160,0:26:18.480
is possible to detect for example that[br]system partition is remounted as readable
0:26:18.480,0:26:23.650
& writable. It could be one of the[br]indicators that some generic jailbreak is
0:26:23.650,0:26:29.900
running on a device. Or like check for[br]especially file that Pegasus use but like
0:26:29.900,0:26:33.870
better check it in general for jailbreak[br]pages, the kernel pages.
0:26:33.870,0:26:37.540
audience shuffling noise[br]H: Please try to stay a bit quiet. We are
0:26:37.540,0:26:40.170
still in the middle of the Q & A. If you[br]don't have to leave now, please stay
0:26:40.170,0:26:47.100
seated until afterwards and if you have to[br]leave now, please do not talk. Microphone
0:26:47.100,0:26:50.200
three, please.[br]M3: What's the user experience during
0:26:50.200,0:26:53.480
this?[br]M: User experience, I mean - you mean -
0:26:53.480,0:26:59.071
you mean when you get a device infected by[br]Pegasus? Well, there is it's scary there
0:26:59.071,0:27:07.110
is no real indicators on a device that you[br]get something. That you click on the link,
0:27:07.110,0:27:13.080
the mobile web browser opens and just[br]closes and crashes. There is no new
0:27:13.080,0:27:19.340
applications spotted on your on visible[br]applications and so on. But in a real it's
0:27:19.340,0:27:26.390
running like three new system services,[br]but they are not visible to a user.
0:27:26.390,0:27:29.370
H: Thank you. And please, another question[br]from the Internet.
0:27:29.370,0:27:33.300
SA: Thank you. Have you any idea how[br]active this exploit is in the world?
0:27:33.300,0:27:39.590
M: Say it again please?[br]SA: Have you any idea how active this
0:27:39.590,0:27:46.580
exploit is in the wild?[br]M: I'm sure it was a very targeted attack
0:27:46.580,0:27:51.860
because, uh, these exploits are pretty[br]expensive. For example, uh, Zerodium now
0:27:51.860,0:27:59.770
pays 1,5 million for remote jailbreaks[br]like these so I don't think that actors of
0:27:59.770,0:28:06.860
this like spyware, want to like - want to[br]deal malware accessible for everyone. So I
0:28:06.860,0:28:11.960
think it's a very very targeted attacks.[br]It is hard to predict how many devices was
0:28:11.960,0:28:19.690
infected by Pegasus. Now we know about the[br]Mansoor one. So, again, I think it's very,
0:28:19.690,0:28:22.480
very targeted thing because it's very[br]expensive.
0:28:22.480,0:28:26.590
H: Thank you for this answer. Microphone[br]number five, please.
0:28:26.590,0:28:33.300
M5: Do you have any more information on[br]the NSO or the group that's behind it? Are
0:28:33.300,0:28:38.720
they using any other software? And how[br]spread is this in the wild again?
0:28:38.720,0:28:42.919
M: Yeah. So in this case, we focused[br]mostly on the technicalities of the
0:28:42.919,0:28:49.809
Pegasus itself, but Citizen Lab made their[br]investigation on NSO and the like the
0:28:49.809,0:28:56.600
NSO is like cyber arms dealer. So please[br]take a look about in a Citizen Lab report
0:28:56.600,0:29:00.140
on that. So they have much more[br]information.
0:29:02.280,0:29:07.750
H: Do we have a question from the[br]Internet? Am I overlooking anyone? No,
0:29:07.750,0:29:10.150
then this is it, thank you for your talk.
0:29:10.150,0:29:14.480
applause
0:29:15.091,0:29:24.670
postroll music
0:29:24.670,0:29:37.610
Subtitles created by c3subtitles.de[br]in the year 2022. Join, and help us!
0:29:37.610,0:29:39.000
[Translated by {Iikka}{Yli-Kuivila}[br](ITKST56 course assignment at JYU.FI)]