# Media

url: https://www.youtube.com/watch?v=Eyl_0YxfnpQ
title: DEF CON 32 - Using ALPC security features to compromise RPC services - WanJunJie Zhang, Yisheng He
type: video
author: DEFCONConference
ingestion_date: 2024-11-10
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=Eyl_0YxfnpQ",
  "title": "DEF CON 32 - Using ALPC security features to compromise RPC services - WanJunJie Zhang, Yisheng He",
  "description": "Advanced Local Procedure Call (ALPC) is an Inter Process Communication method in the Windows kernel. In the past few years, Windows ALPC and RPC vulnerabilities have emerged in an endless stream. These vulnerabilities are mainly based on TOCTOU file operations, memory corruption vulnerabilities in RPC services and ALPC syscalls in ntoskrnl.\n\nWindows kernel provides a variety of security measures to ensure that the data and context accepted by the ALPC and RPC servers are safe. We noticed the attack surface in the security mechanism of the ALPC kernel, and we found a security flaw in this mechanism (magic) and successfully obtained the system privilege from unauthorized users (defeating magic by magic).\n\nIn this talk, we will first overview the communication mechanism of ALPC and RPC services. We will discuss the details of ALPC and RPC in the marshal/unmarshal process that has not been disclosed before. We'll also talk about the kernel security mechanism in ALPC syscalls. Then we will analyze some historical bugs in ALPC and RPC, and disclose the details of the vulnerability we found, discussing how we bypassed the security mechanism through a small security flaw in security mechanisms. Later we'll discuss the exploitation, you will learn about the multiple ways. Finally, We'll make conclusions and share our opinions on this attack surface, including some tips and opinions on how to find these kinds of bugs.\n\nA view into ALPC-RPC by Clement Rouault and Thomas Imbert Hack.lu 2017\nExploiting Errors in Windows Error Reporting - Gal De Leon\nWindows Internals, Part 2, 7th Edition",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2637,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

1.07s - 4.75s | This text was transcribed using whisper model: large-v2

 I can start?
4.75s - 8.66s |  Okay.
8.66s - 9.66s |  Yeah.
9.66s - 10.66s |  Yeah.
10.66s - 11.66s |  Yeah.
11.66s - 14.07s |  Yeah.
14.07s - 15.07s |  Thank you.
15.07s - 16.07s |  It's good to be here.
16.07s - 17.07s |  Yeah.
17.07s - 18.07s |  I'm Wang Junjie Zhang.
18.07s - 19.07s |  Yeah.
19.07s - 28.19s |  I'm a security researcher from the Hailstone Networks.
28.19s - 34.59s |  My research direction is Windows vulnerability research, including the user mode and the
34.59s - 36.83s |  kernel mode.
36.83s - 44.91s |  And also, I've been listed as the most valuable researcher of the Microsoft 2020, 2022, and
44.91s - 46.91s |  2023, 2024.
46.91s - 47.91s |  Yeah.
47.91s - 48.91s |  Okay.
48.91s - 55.63s |  So, let's just start my talk.
55.63s - 56.63s |  And this is...
56.63s - 62.43s |  I already introduced myself and our colleague here.
62.43s - 67.51s |  Firstly, let's see our agenda today.
67.51s - 70.71s |  It mainly consists of four parts.
70.71s - 74.51s |  We'll introduce architecture of the LPC and RPC.
74.51s - 81.15s |  So we will have a deeper understanding of it, and then look at some common vulnerabilities
81.15s - 84.83s |  inside LPC and RPC.
84.83s - 89.35s |  And we will study some root cause of the vulnerabilities.
89.35s - 94.59s |  And then I will share some details of the vulnerabilities I found by myself and my team,
94.59s - 99.63s |  and which can bypass the LPC, RPC security mechanism.
99.63s - 106.99s |  I will show you step-by-step to use this small security flaw to bypass the security mitigations
106.99s - 111.99s |  like ACR, DEP, XFG, and finally, get system shell.
111.99s - 114.43s |  You won't get it from anywhere else.
114.43s - 115.43s |  So...
115.43s - 119.71s |  And that's the way I make a conclusion.
119.71s - 120.71s |  Yeah.
120.71s - 124.23s |  So it's architecture, yeah.
124.23s - 131.99s |  We already know LPC was introduced to replace the ARPC.
131.99s - 140.95s |  It's called Lightweight Procedure Core, mainly used in Windows system, inside the Windows
140.95s - 143.47s |  system services.
143.47s - 152.40s |  And it's concerned by many researchers for its huge attack service.
152.40s - 158.20s |  And this is a LPC and RPC architecture.
158.20s - 168.76s |  And why we combine the ARPC and RPC together?
168.76s - 171.02s |  Why we combine it together?
171.02s - 177.10s |  For reason listed below, most RPC services is based on the ARPC or NAND pipe.
177.10s - 181.50s |  So it's almost based on the same security mechanism.
181.50s - 189.62s |  And the security flaw inside the ARPC can affect the security of RPC services.
189.62s - 194.70s |  And this is also the architecture of the ARPC, RPC from Windows internal.
194.70s - 199.46s |  You can see the communication module inside it.
199.46s - 204.46s |  And it also supports some message queries and some share section.
204.46s - 210.77s |  Also supports share section to pass the message.
210.77s - 214.95s |  Why we use section here?
214.95s - 220.45s |  Because it's a more effective data passing mechanism on Windows section object.
220.45s - 222.17s |  More efficient and fast.
222.17s - 223.17s |  And what about the region?
223.17s - 224.17s |  Why region?
224.17s - 229.29s |  It's a representative range of the shared memory that can be opened within the context
229.29s - 231.17s |  of a given port.
231.17s - 237.41s |  The section can be shared access by one process, which only have right access.
237.41s - 242.49s |  And meanwhile, the client only have the right access.
242.49s - 245.89s |  This picture describe the relationship between the section.
245.89s - 246.89s |  Yeah.
246.89s - 251.45s |  We can split up the whole section into different region.
251.45s - 255.81s |  One piece is represented by one region object.
255.81s - 261.09s |  We have a set size, which is representing the map of the set and the size of the set
261.09s - 262.09s |  section.
262.09s - 263.09s |  Yeah.
263.09s - 271.61s |  I see some historical vulnerabilities, yeah.
271.61s - 279.49s |  First kind of bug is kind of logical bug in ARPC when, you know, there's too much research
279.49s - 289.61s |  on the internet related to doing when the service doing some file operations, is a need
289.61s - 295.05s |  to impersonate the colors or token and doing some operations on file.
295.05s - 300.73s |  However, you know, sometimes the fellows will probably handle the file operation with a
300.73s - 303.33s |  file like a symbol link.
303.33s - 310.65s |  It may be resulting the service being able to modify, or write, or delete, and even create
310.65s - 315.45s |  some files when client should not have the permission on these operations.
315.45s - 325.05s |  So this vulnerability, CVE-2020 and 0911 is an example of the using users device map
325.05s - 333.81s |  and impersonating users and the service will operate on malicious MSAI files in the user's
333.81s - 338.37s |  device map installer directory, and it was directed to another path.
338.37s - 344.01s |  So when the service revert to the system privilege, it also trust the content to read from the
344.01s - 348.21s |  client installer directory and source.
348.21s - 355.01s |  The privilege exhalation happen, yeah.
355.05s - 361.25s |  So this kind of bug exhalation have much articles and research on the internet by using tricks
361.25s - 370.25s |  of firstly, I think it's discovered by Google research by using tricks like NTFS junctions,
370.25s - 374.85s |  higher link or object symbol links, and opportunities locks.
374.85s - 381.53s |  You can easily write exhortations on this kind of bugs.
381.53s - 388.85s |  The second example is malicious memory corruption bug inside the LPC RPC kernel in recent years.
388.85s - 395.57s |  We have seen a lot of memory corruption issues inside the LPC RPC kernel.
395.57s - 400.45s |  So the following code snippet is a part of the vulnerability and is associated with the
400.45s - 407.81s |  LPC section blob object where we create a LPC section in the map legacy port view function.
407.81s - 412.97s |  And there's a race window before the function with the view port, view object.
412.97s - 421.85s |  During this race window, attacker can destroy the LPC port object causing it LPC section
421.85s - 426.13s |  view function access 3D pointer.
426.13s - 432.05s |  The picture describe the race window in the connect port function.
432.05s - 440.33s |  The kernel creates the first LPC port and we can try to close the handle table in the second thread.
440.33s - 445.77s |  If this moment, close moment, between the create section and the create view port function,
445.77s - 447.73s |  you can get a blue screen.
447.73s - 453.13s |  But however, this kind of issue is, I think it's a little bit hard to exploit because you need to
453.13s - 456.33s |  win the race first.
456.37s - 462.93s |  What we observe is that most of these memory corruption bug inside LPC kernel or RPC services,
462.93s - 468.93s |  and most of them are traditionally memory corruption bugs due to the server side lack of check
468.93s - 474.13s |  when RPC services handle data from the client side.
474.13s - 479.97s |  And last example is, I think it's very interesting, logical fallback in LPC RPC discovered in
480.81s - 482.09s |  2017.
482.09s - 487.01s |  Research found that the kernel doesn't protect the share memory privilege when using it to pass
487.01s - 489.49s |  the message data.
489.49s - 495.65s |  In theory, the kernel changed the share section protection in client-side to read-only,
495.65s - 500.85s |  preventing the client-side changing the memory while server-side calling stop code that may be
500.85s - 504.17s |  causing double fetch flaws in server-side.
504.21s - 511.09s |  You can use the virtual protect function to change the share memory from read-only to read-write
511.09s - 513.97s |  and causing data race condition in server-side.
513.97s - 517.57s |  It's pretty doable, right?
517.57s - 524.77s |  Imagine we already have a RPC function, accepts a string parameter and print it twice with a
524.77s - 527.49s |  sleep between these two options.
527.49s - 532.53s |  We write a POC and send a string and try to call the virtual protect and change the content of
532.53s - 533.57s |  the string.
533.61s - 538.65s |  We can see the server-side printed two different strings.
538.65s - 545.49s |  It means that we can change a parameter while the server-side perform any other operation.
545.49s - 553.29s |  Although this vulnerability has been fixed, I decided to learn more from it.
553.29s - 557.85s |  Maybe we can find more interesting stuff.
557.85s - 565.11s |  So, first question is, is it really secure after a patch?
565.15s - 576.07s |  Yeah, from all of the research results I know, share memory is available for almost any RPC
576.07s - 577.91s |  over ARPC services.
577.91s - 585.35s |  So, I decided to write a custom RPC services and try to change the memory protection again,
585.35s - 588.95s |  but finally get virtual protect EX error.
588.95s - 593.07s |  So, what happened after the patch?
593.07s - 597.35s |  So, I decided to learn more from the reverse engineering.
597.35s - 601.39s |  First, N2S kernel try to secure the view of the section.
601.39s - 604.99s |  It doesn't allow to change the memory attribute from the user space.
604.99s - 613.03s |  And secondly, both N2S and RPC RT4 module DLL enable secure mode in mode check.
613.03s - 617.47s |  It means that the server will not manipulate the share memory when it detected the share
617.47s - 621.59s |  memory is unsafe.
622.55s - 624.63s |  This is the technique details.
624.63s - 629.67s |  The security mechanism will handle share memory from client-side.
629.67s - 634.79s |  Kernel use map view, secure view of section function to create a security view.
634.79s - 768.27s |  So, you secure virtual memory and you can't change attribute.
768.27s - 773.51s |  And when sending the attribute, sending message to the server, it's check the RPC section
773.51s - 777.87s |  and the region we use to send the message to see if it's safe.
777.87s - 782.15s |  And the region can't bind with more than two view objects.
782.15s - 787.91s |  It's trying to change the attributes of the share memory address to read only.
787.91s - 794.67s |  If this step falls, then the server-side will be marked with unsafe and the RPC RT4.DLL
794.67s - 800.47s |  will use the share memory to unmarshal the server-side.
800.47s - 805.19s |  And this is the code pieces from the user mode in RPC RT4.
805.19s - 812.55s |  It will acquire the RPC message attributes, including the security flag of the RPC region.
812.55s - 816.95s |  If the region is unsecure, you can see it will lock its heap buffer.
816.95s - 821.31s |  It's managed by pcache object and copying the share memory to the heap buffer.
821.31s - 824.83s |  So it will not cause double fish vulnerability.
824.83s - 829.19s |  So when the server detect the region is unsafe.
830.19s - 837.63s |  I also take a look at the virtual protect ES function to see how the kernel patch protects
837.63s - 838.63s |  the share memory.
838.63s - 848.83s |  As you know, I found a special bad event object to secure the bad object is a security view
848.83s - 849.83s |  or not.
849.83s - 857.07s |  So we know that Windows kernel use MMBad object to describe one virtual address in user space.
857.07s - 862.03s |  It is describe the start and the ending of the virtual page.
862.03s - 867.71s |  When changing the memory of a production, it will check if the bad event object is in
867.71s - 874.67s |  the virtual address, uh, distribute the object, check if it had a bad event object in the
874.67s - 875.67s |  event list.
875.67s - 881.59s |  Unfortunately, the bad event structure symbol was deleted from Windows 11, so I can only
881.59s - 885.27s |  use the old symbol from Windows 10.
885.27s - 890.59s |  And digging into it, there's two key function for address protection.
890.59s - 897.87s |  One is MSSLE protection and revert valid PTE function.
897.87s - 906.39s |  This is the output from the debug in the right picture, and you can see before and after
906.39s - 913.59s |  the MSSLE protection, it's changed a bit of the MSSLE protection from 4 to 1.
913.59s - 919.63s |  I guess it's mean to read-write when the value is 4 and no access value is 1.
919.63s - 925.99s |  Left picture describe the PTE content about Intel, which also, you know, is the page table
925.99s - 926.99s |  structure.
926.99s - 933.07s |  After the function of the MI revert valid PTE, the R and the right bit were set to 0,
933.07s - 940.03s |  so the whole page in the kernel side will change to the read-only.
940.03s - 944.59s |  And the server side will use another page table.
944.59s - 947.35s |  So what about the WLC protection?
947.35s - 955.55s |  I think this bit from 60 to 62 is reversed according to Intel's documentation, so I guess
955.55s - 960.23s |  Microsoft used it for some special purpose, yeah.
960.23s - 965.47s |  And when changing the address protection, it's called MMCheckSecuritySecureVal to check
965.47s - 970.75s |  if there's a special value event, as we talked before.
970.75s - 977.15s |  And when we call the comparePTEProtection, it will compare the page table.
977.15s - 984.27s |  Finally, compare the page table protection with the desired protection mask.
984.27s - 996.35s |  We process the – we pass to the virtualprotect.ex to see a return change attribute if two value
996.35s - 997.35s |  is the same.
997.35s - 1001.99s |  If it's not equal to the virtualprotect.ex, it will return error.
1001.99s - 1007.15s |  Unfortunately, WLC protection now is 1, so it's not the same as before.
1007.15s - 1013.47s |  It really has some weird details you see when changing the protection from the address.
1013.47s - 1019.23s |  It's really not the same as we thought.
1019.23s - 1024.71s |  I should actually try to bypass this function.
1024.71s - 1047.81s |  So it's changing the – so it's changing – oh, now it's okay, yeah.
1047.81s - 1053.97s |  So I tried to bypass this function, and it changed the protection one page.
1053.97s - 1058.73s |  So if you are lucky to share memory for more than two page, and you only write data to
1058.73s - 1065.85s |  the first page without doing any other operations, so the operation will fail.
1066.09s - 1072.65s |  The security function, you know, because the rest of the page doesn't even have the page
1072.65s - 1076.17s |  table, so you can't change the attributes.
1076.17s - 1084.84s |  Okay, let's see the vulnerability details we found in the region.
1084.84s - 1091.40s |  You can always try to align the allocation size to one page.
1091.40s - 1093.52s |  You can split the session object.
1093.52s - 1101.80s |  The starting offset section actually is auto-increased based on the last region and the offset.
1101.80s - 1104.24s |  However, the allocation size is unchecked.
1104.24s - 1111.00s |  So what about this small security flaw?
1111.00s - 1116.40s |  What is small undiscovered issue can cause afterwards?
1116.40s - 1118.80s |  But you still remember the previous picture.
1119.80s - 1127.64s |  Assuming we already allocated four regions, the size of the first region is 0x1000.
1127.64s - 1135.72s |  So the starting offset of the second region essentially will be 0x1000.
1135.72s - 1141.28s |  Based on the info in the picture, we can know the starting offset of the region three is
1141.28s - 1147.56s |  0x4000, which is pretty easy to understand and calculate.
1147.56s - 1155.48s |  So based on this info we know, we can see how unchecked section size we can do in the
1155.48s - 1158.16s |  following.
1158.16s - 1169.40s |  If we allocate the region with extremely big size, 0x002 is actually minus 0xFFFFE.
1169.40s - 1175.56s |  Based on the region and the view granularity, the final offset of region two is actually
1175.56s - 1177.16s |  will be zero.
1177.16s - 1180.44s |  So the allocation size will be still zero.
1180.44s - 1184.00s |  So what does this mean?
1184.00s - 1188.88s |  This means that the region two will overlap with the region one, and they will be mapping
1188.88s - 1192.88s |  to the same physical address.
1192.88s - 1198.64s |  We can use the view one to send and receive the LLPC message, and this view will be protected
1198.64s - 1203.64s |  by the LLPC kernel by using secure view against the write function.
1203.64s - 1207.72s |  The second view will be left, and the kernel will do nothing on it.
1207.72s - 1214.32s |  So because we don't even use it, so we can use the address of the second region to actually
1214.32s - 1217.60s |  change the content.
1217.60s - 1221.16s |  It's writable, so the double fish will happen again.
1221.16s - 1227.32s |  The secure view write against the write function can't protect you anymore.
1227.32s - 1232.72s |  So there will be still many questions for you.
1232.72s - 1237.04s |  As you see in the previous page, the region allocation size is zero.
1237.04s - 1243.36s |  So while you still can change the content of the shared memory, because the map view
1243.36s - 1249.96s |  function support mapping size of zero, you allocate a page with size one page by default,
1249.96s - 1252.44s |  so we don't need to worry about it.
1252.44s - 1260.68s |  And the second, if you set the map view function, it can accept zero size?
1260.68s - 1262.96s |  Why don't you pass zero size?
1262.96s - 1263.96s |  Because it's unacceptable.
1263.96s - 1273.00s |  There's a check before the allocation, allocate the view, create section view function.
1273.00s - 1280.24s |  It's also the region object can use it in more than two views, but the situation I never
1280.24s - 1283.92s |  encountered until now.
1283.92s - 1288.04s |  So let's rest again on the Windows 11 again.
1288.04s - 1295.16s |  Based on the custom LLPC service, we created two views with the same section offset.
1295.16s - 1300.08s |  So the overlap happened, and the kernel only secured the first view, leaving the second
1300.08s - 1301.40s |  view address writable.
1301.40s - 1306.88s |  So you can see we successfully changed the content of the service parameter without changing
1306.88s - 1310.56s |  the protection of the first view.
1310.56s - 1313.60s |  The LLPC services will be vulnerable again.
1313.60s - 1316.96s |  So we have already won the race.
1316.96s - 1323.92s |  So from the page table entry, from the win debug, I can see two address pointed to same
1323.92s - 1326.36s |  pages from a page frame number.
1326.36s - 1330.96s |  It means that it pointed to the same physical memory.
1330.96s - 1335.68s |  And we can see from the protection, we built into the debug when server trying to print
1335.68s - 1336.72s |  the stream from client.
1336.72s - 1344.76s |  So the first page is read only, and it's writable, but the second page is writable on the same
1344.76s - 1352.29s |  physical memory, which resulted from our ideas, and the result is the result from the terminal.
1352.29s - 1358.95s |  So from the exploitation analyze.
1358.95s - 1362.43s |  So let's discuss some possible exploitation.
1362.43s - 1367.75s |  From the assessment before, there's two ways to export.
1367.75s - 1374.91s |  One is you can use Windows services or third-party services using file operations and for exploitation
1374.91s - 1384.79s |  techniques created by James Fosho, a change to write system DLL and get any system privilege,
1384.79s - 1391.87s |  or bypass some security check and access some functions which admin user can access, or
1391.87s - 1398.43s |  bypass UAC on the Windows 11.
1398.43s - 1404.95s |  On the other side, we can also use memory corruption exploitation techniques.
1404.95s - 1413.51s |  Firstly, I can almost crush any RPG services or ARPC services, and even can get system shell.
1413.51s - 1420.71s |  So I must admit that I'm lazy sometimes, just want to make the exploitation as easy as possible.
1420.75s - 1425.39s |  So unfortunately, Microsoft is not stupid.
1425.39s - 1432.75s |  They were deleted the services code, which several years ago that Thomas used to exploit them,
1432.75s - 1435.11s |  to exploit this type of issue.
1435.11s - 1438.23s |  We need to find another possible way.
1438.23s - 1443.31s |  But however, it's actually possible to find the RPC services meet these conditions.
1443.31s - 1445.31s |  It's impossible, I think.
1445.31s - 1450.31s |  First, the service need to use the shell memory without copying it to another address.
1450.31s - 1454.55s |  And also need to have some sensitive operations on the file.
1454.55s - 1459.91s |  So consider this situation, it's almost impossible to find this kind of service.
1459.91s - 1462.75s |  At least, I didn't find one.
1462.75s - 1464.19s |  You can try it.
1464.19s - 1472.13s |  But I think it's possible on some third-party services.
1472.13s - 1476.61s |  Next, we should know what kind of argument we use to double fish.
1476.65s - 1481.97s |  A simple structure, or a pointer, like an integer, a pointer, a string, or a double string,
1481.97s - 1483.97s |  use shell memory.
1483.97s - 1490.73s |  The context structure, which also you may know is called the longest structure,
1490.73s - 1493.09s |  when copying to heap buffer.
1493.09s - 1498.21s |  You may be confused about what is the complex or simple structure.
1498.21s - 1502.69s |  To put it simple, you just remember, if a structure contains a pointer,
1506.86s - 1510.86s |  this is an example of the simple complex structure we've seen.
1510.86s - 1514.86s |  And they are treated differently when RPC unmatches them.
1514.86s - 1521.86s |  And above is the bombi structure, which was never used in the shell memory,
1521.86s - 1525.86s |  which below is an example of the simple structure.
1525.86s - 1532.30s |  We need to understand RPC format and the type format first.
1532.30s - 1536.30s |  And the proc format is one server function in force,
1536.30s - 1542.30s |  parameter type, and it's stored offset inside the parameter.
1542.30s - 1547.30s |  For example, if we have an output one function in server side,
1547.30s - 1553.30s |  the proc format will generate an IDL compiler from the compiler,
1553.30s - 1556.30s |  storing the parameter into the parameter type offset,
1556.30s - 1559.30s |  and the location info of the parameter.
1559.30s - 1562.30s |  And the IDL compiler also generates the comment for every...
1677.71s - 1681.31s |  Oh, it's okay now?
1681.31s - 1685.31s |  And we can see the difference between the simple and the complex structure
1685.31s - 1689.97s |  in the type format.
1689.97s - 1693.97s |  Okay, the proc mark gives us where the parameter type definition
1693.97s - 1695.97s |  located in the type format string,
1695.97s - 1700.97s |  so we can see difference between the simple and the complex structure.
1700.97s - 1703.97s |  In the header flag, you can see them in the comment.
1706.97s - 1710.97s |  There's three situation buffer flow I can cause.
1710.97s - 1714.97s |  I tried to find the exportation services by code auditing
1714.97s - 1716.97s |  or faster contents,
1716.97s - 1722.97s |  but one condition is inside the RPC string Marshall function.
1722.97s - 1724.97s |  The pre-memory content we can control,
1724.97s - 1728.97s |  so one service has multiple output string result sending to the client,
1728.97s - 1732.97s |  so it also will use the shell memory to send to the client
1732.97s - 1734.97s |  so we can fill the whole shell memory
1734.97s - 1736.97s |  and the argument gap.
1736.97s - 1740.97s |  Assuming the first string is 0x50 lens,
1740.97s - 1743.97s |  and the second is 0x500 lens,
1743.97s - 1747.97s |  so we can fill the argument gap in the memory
1747.97s - 1749.97s |  after the server finishes the subcode
1749.97s - 1752.97s |  and returns to the RPC-84,
1752.97s - 1756.97s |  and the client size will be over 0x1000,
1756.97s - 1759.97s |  so it's the maximum size in shell memory
1759.97s - 1764.31s |  will cause the crash of the service.
1764.31s - 1768.31s |  And also another heap operation,
1768.31s - 1773.31s |  which means the size of the string store inside a pointer,
1773.31s - 1776.31s |  so it's not easy to find this part of the server,
1776.31s - 1778.31s |  so we can change the size of the string
1778.31s - 1779.31s |  when the server on Marshall,
1779.31s - 1784.31s |  the server resulting the string sending to the client.
1784.31s - 1788.31s |  However, it's still possible, not possible to exploit.
1788.31s - 1792.31s |  You can only cause the shell memory output out on the read,
1792.31s - 1794.31s |  so when calling the P memory function,
1794.31s - 1796.31s |  so it's a pity.
1796.31s - 1802.31s |  And the third exploitation is spool service,
1802.31s - 1803.31s |  spool server service.
1803.31s - 1805.31s |  When it open a printer,
1805.31s - 1808.31s |  it will double-check access the name of the printer,
1808.31s - 1812.31s |  and the first time the server will cause WCs,
1812.31s - 1816.31s |  a string result offset can be a large offset,
1816.31s - 1819.31s |  and then allocate a string again,
1819.31s - 1821.31s |  and recalculate the string length,
1821.31s - 1824.31s |  so this time the string can be small size,
1824.31s - 1826.31s |  so you will cause out of a bound write,
1826.31s - 1829.31s |  a null pointer, a null byte,
1829.31s - 1831.31s |  but this issue is hard to exploit,
1831.31s - 1834.31s |  so we also need to win the race,
1834.31s - 1839.31s |  and doing heap function to construct some useful target,
1839.31s - 1840.31s |  so it's really a huge challenge,
1840.31s - 1843.31s |  so what should I do?
1843.31s - 1847.31s |  So I decide to try to do some easy stuff first.
1847.31s - 1850.31s |  Let's see.
1850.31s - 1852.31s |  Bypassing UIC.
1852.31s - 1854.31s |  How this works,
1854.31s - 1858.31s |  the key function inside application information service,
1858.31s - 1862.31s |  in UIC service,
1862.31s - 1864.31s |  luckily the service access the command line argument
1864.31s - 1866.31s |  from the shell memory,
1866.31s - 1868.31s |  without copying it to the heap buffer,
1868.31s - 1873.31s |  so we can have a chance to use this,
1873.31s - 1877.31s |  and also the program name and the cmd line argument
1877.31s - 1880.31s |  are also stored in the shell memory.
1880.31s - 1882.31s |  The UIC has a special feature,
1882.31s - 1885.31s |  when the client executes some special program,
1885.31s - 1887.31s |  it will not launch the save confirm window,
1887.31s - 1891.31s |  so we can use the feature to launch the arbitrary program,
1891.31s - 1893.31s |  without any launch any confirm window,
1893.31s - 1895.31s |  from app info service,
1895.31s - 1898.31s |  so we can bypass it.
1898.31s - 1901.31s |  It's also not that easy as we analyzed,
1902.31s - 1905.31s |  there's a whitelist inside the service,
1905.31s - 1908.31s |  you should know that there's also argument whitelist,
1908.31s - 1911.31s |  for some special program,
1911.31s - 1918.31s |  which not need to launch the confirm window,
1918.31s - 1920.31s |  so also the new process,
1920.31s - 1922.31s |  launched by app info service,
1922.31s - 1924.31s |  will suspend first,
1924.31s - 1927.31s |  that means we still cannot execute our payload,
1927.31s - 1929.31s |  so server will check the process image section,
1929.31s - 1931.31s |  with the program file section,
1931.31s - 1934.31s |  means although we have a launch malicious program,
1934.31s - 1935.31s |  without confirm window,
1935.31s - 1937.31s |  the app info service,
1937.31s - 1941.31s |  will also launch the confirm window,
1941.31s - 1944.31s |  because the two image are not the same,
1944.31s - 1947.31s |  so Microsoft is not stupid,
1947.31s - 1949.31s |  really a good solution to prevent,
1949.31s - 1952.31s |  a launching from any malicious program,
1952.31s - 1953.31s |  but unfortunately,
1953.31s - 1956.31s |  they doesn't check the argument program,
1957.31s - 1959.31s |  after the launching the program,
1959.31s - 1962.31s |  it doesn't check the argument,
1962.31s - 1965.31s |  so we still have to change,
1965.31s - 1967.31s |  the good thing is,
1967.31s - 1970.31s |  we can create a malicious mscc file,
1970.31s - 1972.31s |  and there's a research on mscc file,
1972.31s - 1976.31s |  when mscc open and auto-launch the CMD shell,
1976.31s - 1978.31s |  with a malicious strip,
1978.31s - 1981.31s |  you know service.msc is in there,
1981.31s - 1985.31s |  whitelist of the USC services,
1985.31s - 1988.31s |  so we can see,
1988.31s - 1991.31s |  we can launch a high integrated command line shell,
1991.31s - 1993.31s |  without any other problem,
1993.31s - 1997.31s |  but I'm not satisfied in doing this,
1997.31s - 1999.31s |  it's even not a vulnerability to Microsoft,
1999.31s - 2003.31s |  so you should be an administrator first,
2003.31s - 2005.31s |  and I mean system to the system,
2005.31s - 2006.31s |  it's not a security boundary,
2006.31s - 2009.31s |  as we seen from the Microsoft,
2009.31s - 2014.30s |  so last is get system privilege,
2014.30s - 2016.30s |  another good thing is,
2016.30s - 2019.30s |  it's truly exploitable,
2019.30s - 2022.30s |  I found a service in DCOM launch,
2022.30s - 2025.30s |  the key is a key service in Windows system,
2025.30s - 2026.30s |  interface,
2026.30s - 2028.30s |  normal user can access,
2028.30s - 2030.30s |  I have a list,
2030.30s - 2031.30s |  the service dual ID,
2031.30s - 2033.30s |  service pass,
2033.30s - 2036.30s |  so and the service function,
2036.30s - 2038.30s |  I used to exploit,
2038.30s - 2039.30s |  it's a game,
2039.30s - 2041.30s |  get game name config,
2041.30s - 2042.30s |  yeah,
2042.30s - 2043.30s |  it's truly,
2043.30s - 2044.30s |  and it's true,
2044.30s - 2046.30s |  three parameter with simple structure,
2046.30s - 2048.30s |  means the service can use the shell memory,
2048.30s - 2052.30s |  you will obviously get the execution from the start point,
2052.30s - 2057.22s |  and the first parameter is a dual ID stream,
2057.22s - 2059.22s |  it's come from the registry,
2059.22s - 2062.22s |  representing a game as you know,
2062.22s - 2064.22s |  dual ID in the picture,
2064.22s - 2066.22s |  this dual ID represent the battlefield,
2066.22s - 2070.22s |  I think some of you might played it before,
2070.22s - 2072.22s |  but most importantly,
2072.22s - 2074.22s |  the key is fully controlled by the current user,
2075.22s - 2077.22s |  because every user in the system,
2077.22s - 2081.22s |  have the independent game store configuration,
2081.22s - 2082.22s |  in the user hive,
2082.22s - 2084.22s |  so you can just traverse the key,
2084.22s - 2087.22s |  current key and the final one,
2087.22s - 2088.22s |  next we may thought,
2088.22s - 2090.22s |  what can we do in the service,
2090.22s - 2094.22s |  because we can now pass in the parameters,
2094.22s - 2095.22s |  through the shell memory,
2095.22s - 2097.22s |  so we can pretty lucky,
2097.22s - 2099.22s |  we can do memory leak,
2099.22s - 2102.22s |  and array overflow in this function,
2102.22s - 2105.22s |  so first the function directly write the stream,
2105.22s - 2106.22s |  pointer to the shell memory,
2106.22s - 2108.22s |  which means we can leak the shell memory address,
2108.22s - 2110.22s |  mapped in the server side,
2110.22s - 2112.22s |  although the memory is unmapped,
2112.22s - 2114.22s |  after the request,
2114.22s - 2116.22s |  but the address will never change,
2116.22s - 2118.22s |  so we can use the shell memory,
2118.22s - 2121.22s |  to construct our fake object,
2121.22s - 2122.22s |  and the V tables,
2122.22s - 2125.22s |  and plus this stack array buffer floor,
2125.22s - 2126.22s |  upon access,
2126.22s - 2128.22s |  and after the information leak,
2128.22s - 2129.22s |  on the shell memory,
2129.22s - 2131.22s |  you can see the function directly,
2131.22s - 2133.22s |  use the index from the shell memory,
2133.22s - 2135.22s |  and write a shell memory address,
2135.22s - 2137.22s |  a pointer out of a bound on the stack,
2137.22s - 2139.22s |  this means that we can do info leak,
2139.22s - 2141.22s |  and stack buffer overflow,
2141.22s - 2143.22s |  just in one function,
2143.22s - 2145.22s |  and it's a good and really,
2145.22s - 2149.69s |  and a good primitive,
2149.69s - 2152.69s |  this is a strategy I use,
2152.69s - 2155.69s |  first I need to leak the shell memory address,
2155.69s - 2159.69s |  and we just call the server function,
2160.69s - 2163.69s |  to repeatedly read the shell memory,
2163.69s - 2165.69s |  so we can get the pointer,
2165.69s - 2167.69s |  and when we get the shell memory,
2167.69s - 2168.69s |  we can create a fake object,
2168.69s - 2169.69s |  the V table,
2169.69s - 2171.69s |  based on the leaked information,
2171.69s - 2172.69s |  in step one,
2172.69s - 2173.69s |  and finally,
2173.69s - 2175.69s |  we can try to change index of the shell memory,
2175.69s - 2177.69s |  to trick the stack array,
2177.69s - 2179.69s |  buffer overflow,
2179.69s - 2181.69s |  to load our evil DLL to the service,
2181.69s - 2184.69s |  and get system shell,
2184.69s - 2186.69s |  I'll show you one step by step,
2186.69s - 2190.69s |  and this is output from the win debug window,
2190.69s - 2192.69s |  we can see server write the shell memory pointer,
2192.69s - 2193.69s |  on the shell memory,
2193.69s - 2195.69s |  we just read it repeatedly from the kind,
2195.69s - 2199.69s |  until we read the pointer,
2199.69s - 2201.69s |  shell pointer,
2201.69s - 2202.69s |  and next the real problem came,
2202.69s - 2204.69s |  so we can get a stack array,
2204.69s - 2205.69s |  buffer overflow,
2205.69s - 2208.69s |  but how and where to write,
2208.69s - 2210.69s |  and what to write,
2210.69s - 2212.69s |  I choose to write the RPC message object,
2212.69s - 2214.69s |  on the stack,
2214.69s - 2215.69s |  so first,
2215.69s - 2217.69s |  RPC message is a member in MID,
2217.69s - 2218.69s |  or stack message,
2218.69s - 2220.69s |  and the object is allocated on the stack,
2220.69s - 2222.69s |  so before RPC call the server,
2222.69s - 2224.69s |  it's easy to override it,
2224.69s - 2227.69s |  and the shell memory is not executable,
2227.69s - 2229.69s |  so we can just override,
2229.69s - 2233.69s |  and if we choose to override the return address,
2233.69s - 2238.69s |  we cannot directly do the ROP,
2238.69s - 2239.69s |  let's see what we write,
2239.69s - 2241.69s |  from the view of the win debug,
2241.69s - 2243.69s |  RCX is the array index,
2243.69s - 2244.69s |  we can fully control it,
2244.69s - 2247.69s |  RCX is shell memory address,
2247.69s - 2249.69s |  and we also can fully control it,
2249.69s - 2251.69s |  so you can see,
2251.69s - 2253.69s |  we easily override RPC message pointer,
2253.69s - 2254.69s |  on the stack,
2254.69s - 2256.69s |  so when the server return to RPC core engine,
2256.69s - 2260.69s |  it will be operated on the fake object,
2260.69s - 2263.69s |  so we can see from the engine call,
2263.69s - 2264.69s |  NDR get buffer,
2264.69s - 2267.69s |  RCX already been the shell memory address,
2267.69s - 2270.69s |  and this is a layout of the shell memory,
2270.69s - 2272.69s |  there's also some type check,
2272.69s - 2274.69s |  because we can fully control it,
2274.69s - 2275.69s |  so it's not a problem,
2275.69s - 2279.69s |  I choose to construct the fake RPC binding handle,
2279.69s - 2282.69s |  in the shell memory,
2282.69s - 2284.69s |  real problem came,
2284.69s - 2286.69s |  you can see finally,
2286.69s - 2288.69s |  you arrive to the virtual function calling,
2288.69s - 2290.69s |  so it is XFG check,
2290.69s - 2295.69s |  the first available,
2295.69s - 2298.69s |  and I want to actually,
2298.69s - 2300.69s |  directly call to the load library,
2301.69s - 2303.69s |  but you can see the V table,
2303.69s - 2305.69s |  and the first parameter is overlapped,
2305.69s - 2310.69s |  so we cannot directly call the load library,
2310.69s - 2315.69s |  so we can always find a way,
2315.69s - 2317.69s |  if I can directly call load library,
2317.69s - 2319.69s |  I can find a legal callable function,
2319.69s - 2321.69s |  to reduce the pivoting,
2321.69s - 2324.69s |  so we know there's a technique,
2324.69s - 2326.69s |  called stack pivoting,
2326.69s - 2328.69s |  in CTF exportation techniques,
2328.69s - 2331.69s |  where you can directly RP on the current stack,
2331.69s - 2333.69s |  so for the register pivoting,
2333.69s - 2334.69s |  I just need to find a function,
2334.69s - 2338.69s |  which can exchange the content of the register RCX,
2338.69s - 2342.69s |  and then the register will point you to the DLL path,
2342.69s - 2345.69s |  and luckily I found this kind of a function,
2345.69s - 2349.69s |  which can exchange the register,
2349.69s - 2351.69s |  it's inside the com-based DLL,
2351.69s - 2354.69s |  I can directly call bypass the XFG check,
2354.69s - 2356.69s |  it's a callback function,
2356.69s - 2359.69s |  and this is a layout,
2359.69s - 2362.69s |  RCX is before we call into the callback,
2362.69s - 2364.69s |  it's pointing to bind handle object,
2364.69s - 2366.69s |  and the value in the purple color,
2366.69s - 2368.69s |  is the type of information,
2368.69s - 2370.69s |  and the callback function,
2370.69s - 2373.69s |  we can call load libraries with login function,
2373.69s - 2376.69s |  to with the DLL path in the second parameter,
2376.69s - 2378.69s |  so luckily before the control flow check,
2378.69s - 2380.69s |  the validity of the callback function,
2380.69s - 2382.69s |  the function is not first member of the V table,
2382.69s - 2384.69s |  it's at the 0x70,
2384.69s - 2386.69s |  so the start location of the V table,
2386.69s - 2388.69s |  we can use to put our DLL paths,
2388.69s - 2391.69s |  so without worrying about the function validity,
2391.69s - 2394.69s |  because it was never used,
2394.69s - 2396.69s |  so then we can load our custom DLL,
2396.69s - 2399.69s |  without any resistance,
2399.69s - 2402.69s |  and I will show you the demo,
2402.69s - 2411.14s |  I use a normal user,
2411.14s - 2413.14s |  it's in user group,
2413.14s - 2419.31s |  and I write it in all the POC in the person,
2419.31s - 2424.01s |  and you can see it's a normal user,
2424.01s - 2426.01s |  with medium privilege,
2426.01s - 2428.01s |  it's not in administrator group,
2428.01s - 2433.34s |  and then we check the d.com service,
2433.34s - 2437.34s |  to see if we can load our malicious DLL,
2437.34s - 2443.29s |  okay we can see the shared memory,
2443.29s - 2445.29s |  and the compass,
2445.29s - 2448.29s |  and we see we already loaded our evil DLL,
2448.29s - 2451.29s |  and there's the shell coming,
2451.29s - 2453.29s |  and we type who am I,
2453.29s - 2455.29s |  and we get a system privilege,
2455.29s - 2457.29s |  with all the privilege,
2457.29s - 2462.93s |  thank you,
2462.93s - 2463.93s |  thank you,
2463.93s - 2472.26s |  thank you,
2472.26s - 2479.15s |  and a conclusion,
2479.15s - 2482.15s |  so to be continue,
2482.15s - 2488.46s |  I think there's still some research,
2488.46s - 2490.46s |  I need to do in the future,
2490.46s - 2492.46s |  I like the automation,
2492.46s - 2496.46s |  info extract from the RPC interface,
2496.46s - 2499.46s |  I need to find this exportation service,
2499.46s - 2502.46s |  and the argument which made the exportation bar,
2503.46s - 2505.46s |  if you have any good ideas,
2505.46s - 2507.46s |  and you can please share it to me,
2507.46s - 2509.46s |  I also want to know some good ideas,
2509.46s - 2512.46s |  for the tool developing,
2512.46s - 2514.46s |  and there's a much special more,
2514.46s - 2516.46s |  special features in RPC,
2516.46s - 2519.46s |  and the need to be examined,
2519.46s - 2522.46s |  and the more effective exportation techniques,
2522.46s - 2524.46s |  if you have any other any good ideas,
2524.46s - 2526.46s |  feel free to contact me,
2526.46s - 2529.32s |  yeah,
2529.32s - 2530.32s |  and the right Bob,
2530.32s - 2532.32s |  this is our bank hunting experience,
2532.32s - 2534.32s |  I want to share with you,
2534.32s - 2535.32s |  and the first don't trust,
2535.32s - 2537.32s |  any patches from the render,
2537.32s - 2538.32s |  it may still not patch,
2538.32s - 2540.32s |  the vulnerability effectively,
2540.32s - 2542.32s |  and also the patch analyze,
2542.32s - 2545.32s |  is still more effect in bug hunting,
2545.32s - 2547.32s |  you should be more creative,
2547.32s - 2550.32s |  and the criticism when bug hunting,
2550.32s - 2551.32s |  yeah,
2551.32s - 2553.32s |  you should dare to do it,
2553.32s - 2555.32s |  and we should be patient,
2555.32s - 2559.32s |  but bug hunting is a long way marathon,
2559.32s - 2560.32s |  and at last,
2560.32s - 2562.32s |  don't meet any miss,
2562.32s - 2564.32s |  any other,
2564.32s - 2565.32s |  any side effect,
2565.32s - 2568.32s |  this effect may cause security flaw,
2568.32s - 2571.60s |  afterwards,
2571.60s - 2572.60s |  yeah,
2572.60s - 2575.60s |  and for this type of service,
2575.60s - 2577.60s |  we mentioned in the talk,
2577.60s - 2580.60s |  there's still much special feature in the RPC,
2580.60s - 2582.60s |  we need to examine,
2582.60s - 2584.60s |  and the security of RPC,
2584.60s - 2587.60s |  is actually affect the security of the RPC,
2587.60s - 2589.60s |  for Microsoft we can see,
2589.60s - 2592.60s |  it's really done a great tireless work,
2592.60s - 2594.60s |  on the security of the RPC services,
2594.60s - 2596.60s |  although we cause the double fish,
2596.60s - 2597.60s |  in the RPC services,
2597.60s - 2599.60s |  we need to still find,
2599.60s - 2601.60s |  export both service,
2601.60s - 2603.60s |  and the parameters still meet,
2603.60s - 2607.60s |  very strict bars,
2607.60s - 2610.60s |  and this is a reference of our talk,
2610.60s - 2612.60s |  and thank you,
2612.60s - 2613.60s |  is there another questions,
2613.60s - 2614.60s |  because there is a microphone,
2614.60s - 2615.60s |  has any problems,
2615.60s - 2616.60s |  and sorry for that,
2616.60s - 2617.60s |  yeah,
2617.60s - 2631.53s |  thank you.


url: https://www.youtube.com/watch?v=GwwxeY11xMI
title: DEF CON 32 - Outlook Unleashing RCE Chaos CVE 2024 30103 - Michael Gorelik, Arnold Osipov
type: video
author: DEFCONConference
ingestion_date: 2024-11-10
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=GwwxeY11xMI",
  "title": "DEF CON 32 - Outlook Unleashing RCE Chaos  CVE 2024 30103 - Michael Gorelik, Arnold Osipov",
  "description": "Did you ever receive an empty email and immediately think it might be a reconnaissance attack? What if opening such an email in your Outlook client could trigger remote code execution through an invisible form? Yes, all forms are COM objects, and CVE-2024-21378 has flung open the gates to Outlook RCE chaos.\n\nIn our session, \"Outlook Unleashing RCE Chaos: CVE-2024-30103\" we'll dive into how this seemingly innocuous vulnerability can lead to mayhem. This vulnerability paved the way for us to discover a series of new remote code execution vulnerabilities in Outlook, including CVE-2024-30103. But we\u2019re not stopping there.\n\nAdditionally, we'll uncover other vulnerabilities that can cause NTLM leaks from your domain-joined devices.\n\nSo, how did we get here? Join us as we construct an evolution timeline of this attack surface. From the origins of these exploits to their current incarnations, we'll cover it all. And because we believe in building a safer digital world, we'll conclude with specific, actionable recommendations on how to minimize these threats.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2470,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

1.74s - 3.74s | This text was transcribed using whisper model: large-v2

 Hey, good evening to everyone
4.98s - 6.98s |  Okay
10.61s - 12.61s |  Thank you, thank you, thank you
13.25s - 15.25s |  okay, so
15.65s - 17.65s |  What do you expect from patches?
17.99s - 19.55s |  security updates
19.55s - 26.13s |  You expect them to be a fort knox security update right that solves fully the vulnerability all the control flows
26.81s - 31.98s |  Is it really in reality? This is what we usually get
33.96s - 36.40s |  Yep, so we all been there
37.08s - 42.16s |  Expecting that one patch solves it all right, but essentially it's kind of a bullet
43.16s - 46.18s |  Patch to a bullet or there's a better phrase to that
46.82s - 48.44s |  we will be
48.44s - 53.72s |  sharing insights about what happens when the patch not quite do the trick and
55.32s - 57.32s |  Sometimes you also find new vulnerabilities
57.56s - 64.60s |  So this talk will be sharing new details about vulnerabilities that we discovered and we're patched during June and July
65.48s - 67.48s |  those are two out of
68.24s - 70.24s |  bigger number of vulnerabilities
70.28s - 73.24s |  Let's not be too harsh with the vendors
73.64s - 80.88s |  There's a reason why this happens many time just couple of weeks ago. We all saw the mega crush from a CrowdStrike update
81.40s - 86.56s |  It's not exactly security update nevertheless the impact is obvious right blue screens all over
86.72s - 91.88s |  And this is exactly the reason why many vendors are kind of trying to solve only the specific problem
92.72s - 94.72s |  while the doing so also
95.24s - 96.96s |  kind of
96.96s - 103.02s |  Share with us the investigative researchers on additional vulnerabilities that are within the code
104.16s - 106.32s |  So just very shortly about
107.04s - 112.00s |  Ourself my name is Michael Grelick. I'm the chief technology officer and founder of Morphi sec
112.00s - 115.36s |  I have around 20 years of experience in cyber security
116.00s - 121.72s |  Was the one to discover one of the largest supply chain attacks the C cleaner in history
122.88s - 127.52s |  have a lot of experience in the reverse engineering red teaming and blue teaming and
128.28s - 130.28s |  Go ahead Arnold
130.40s - 136.72s |  Hey guys. My name is Arnold. I'm leading the malware research efforts at Morphi sec and
137.24s - 142.72s |  For some time now. I am poking with some patch analysis for fan and profit and
143.52s - 145.52s |  Product of course
146.28s - 149.98s |  Thanks, I don't know okay
150.94s - 152.94s |  So just starting with a disclaimer
153.58s - 155.58s |  With great power comes greater responsibility
156.34s - 158.34s |  Use your powers for the good
158.78s - 164.20s |  So now about the talk itself a bit about the motivation
165.04s - 171.76s |  Some of our work that we're doing in Morphi sec. We are going and reviewing the most critical vulnerabilities
172.36s - 175.68s |  That exist especially those that lead to remote code executions
176.48s - 184.32s |  The latest vulnerabilities that we were reviewing were ones that discovered by the net spy group done an amazing work
185.28s - 192.24s |  On the form injection category basically a category of vulnerabilities that lead to remote code execution
193.20s - 196.16s |  But do require authentication prior authentication
196.84s - 203.76s |  Additional category that Arnold will be sharing is about compound monikers also lead to remote code execution
204.52s - 210.40s |  Checkpoint done a great research and a great work discovering some vulnerabilities during the year
210.40s - 217.56s |  We will also show how the patch doesn't really do the trick and how we discover the additional vulnerabilities by purely looking at the patch
220.35s - 223.35s |  Okay, so let's start talking about the forms
223.35s - 230.11s |  I mean every of those categories can go a full lecture, so we'll be kind of covering very quickly
230.87s - 235.15s |  On the introduction, but you are welcome to see additional details and documentation
236.59s - 243.03s |  In the world again on the internet so forms exactly as you would see you get the message
244.39s - 247.75s |  You're sending a message. It's eventually based on forms
248.35s - 252.07s |  Now message email message is not the only thing that is based on force
252.47s - 256.15s |  essentially there is a quite a significant mechanism that works behind and
256.63s - 260.59s |  Imagine you are sending a recall message on the message that you sent to your boss
260.99s - 266.75s |  What happens behind what happens when the recall being sent so essentially it's something there
267.11s - 271.63s |  Activates and starts to delete the email from the inboxes of your manager
272.15s - 277.39s |  It's a rendering mechanism that is based on again the synchronization of forms
277.83s - 284.03s |  And we'll be covering that and we'll share basically how we utilize that to inject malicious forms
284.99s - 290.47s |  We'll get back to recall on the coming slides, but let's first talk a bit a bit about
291.03s - 292.95s |  forms and custom forms
292.95s - 298.11s |  so forms overall can be of two different types now if you
298.83s - 304.51s |  Integrate the developer mode in outlook you can see that you can modify existing forms
305.35s - 307.35s |  into your own kind of
307.59s - 310.47s |  Purpose so if you get a nice message
310.47s - 317.15s |  maybe you want to add some button there or some sound you can definitely do that and even change the
317.47s - 319.47s |  structure of the forms by
319.47s - 320.59s |  basically
320.59s - 325.59s |  Opening the built-in Microsoft form and starting moving stuff now
325.59s - 329.51s |  We will not be talking about that because we are looking into inject a full form
329.51s - 332.23s |  But this is one of the ways to create the form
332.83s - 336.47s |  We'll talk about the creation of the form in the next slide
336.91s - 339.99s |  What is outside of the scope of this presentation is
340.67s - 346.47s |  Talking about visual basic execution within the form. It was well well covered by Etienne Stevens
346.63s - 351.79s |  You've done a lot of research in 2017 a lot of presentations. You are welcome to
352.35s - 354.15s |  Check them out
354.15s - 356.07s |  Microsoft introduced a lot of
356.07s - 363.19s |  Hardening to avoid the default execution of visual basic inside forms, so this is outside of the scope
365.16s - 373.04s |  Okay, so I already mentioned that we have one way to create a custom form this one way is by modifying existing built-in forms
373.28s - 380.44s |  But what is interesting for us in this category of form injection is the way you can programmatically create new forms?
380.64s - 386.00s |  And if you look at the documentation of Microsoft, this is actually a snapshot from Microsoft documentation
386.36s - 392.32s |  There is a way to create your own form by basically generating a configuration file called CFG
392.84s - 400.84s |  Within this configuration file you basically define the different properties of the same form that you see like a message or appointment or calendar
400.84s - 402.24s |  It's all forms
402.24s - 409.36s |  And you can also specify a form server in this case you see the example is helpdesk.exe
409.60s - 416.60s |  That is responsible to render the form so upon receiving that message in your outlook you want to do something about that
416.72s - 419.72s |  this is the executable that eventually spawned and
420.36s - 427.24s |  Does something about that and we will share a couple of examples now. It doesn't have to be executable you can use a different
428.04s - 431.60s |  DLL or any other ways we'll share that as well
432.28s - 434.60s |  but again, there is a very nice way to
435.72s - 444.52s |  Run that form now. It's we'll not get into too much details about the whole mechanism of forms because we don't have enough time
445.52s - 452.60s |  Nevertheless, it's important to understand one of the most interesting things in forms is the synchronization mechanism
452.80s - 459.84s |  So exactly like you would open a draft email and it's suddenly existing all your clients behind them
459.84s - 465.88s |  There is a mechanism that basically synchronizes all those forms across the different clients through the exchange server
466.04s - 468.64s |  This is not the only thing that obviously synchronized
468.96s - 470.08s |  But in this case
470.08s - 478.20s |  We will leverage that mechanism to inject and execute the forms on any of the clients that there are victim basically using
478.72s - 480.72s |  Now the mechanism involves
481.00s - 486.28s |  Form libraries that represent properties. It will represent also include form service, etc
487.00s - 488.44s |  and
488.44s - 494.48s |  There's also important to understand that not all forms are synchronized if you put your form
494.76s - 500.44s |  Into a personal library, it will not be synchronized across the different clients. But if you for example
501.56s - 504.96s |  Install it in the inbox. It will definitely be synced by the
505.60s - 509.20s |  Microsoft protocol
509.20s - 513.24s |  So shortly how forms are loading and and registered
513.32s - 519.44s |  So if you take in this example a simple built-in modified form, this is not a programmatically created form
519.92s - 521.92s |  Nevertheless, this is the same mechanism
522.48s - 527.04s |  So if you look at the your registry hive under the class ID you will find
527.36s - 532.24s |  Again based on whether you have outlook 32-bit or 64-bit you have the wow there
532.64s - 539.36s |  But you will find a lot of those class IDs and each class ID many of those class IDs basically represent the different forms
539.88s - 540.96s |  now
540.96s - 543.96s |  As soon as you find the class ID you will find also
544.20s - 549.28s |  What is the name of the form and you will find what is the location of that form on your disk?
549.92s - 554.88s |  Those forms when they are synchronized they are saved in a special folder many times
555.32s - 557.40s |  in the app data local that
558.16s - 564.92s |  Under the forms folder and the built-in forms are saved within the program files office also special
565.44s - 567.20s |  folder there
567.20s - 570.40s |  essentially those form libraries are a com objects and
571.64s - 574.04s |  those are can be rendered and
575.52s - 577.52s |  instantiated like any other comb
578.00s - 580.00s |  As we said the
580.16s - 582.08s |  original kind of oily
582.08s - 587.24s |  form library is a bit outside of the scope of this lecture nevertheless, I
588.84s - 589.96s |  strongly
589.96s - 594.72s |  recommend people here to try and play with it because you can modify the streams and
594.96s - 599.92s |  Also lead to malicious behavior by basically modifying the properties of the oily itself
600.84s - 604.08s |  But we will be talking about programmatically created forms
605.08s - 606.56s |  Through the
606.56s - 607.76s |  configuration files
607.76s - 610.72s |  This is a great example of a built-in
611.08s - 619.16s |  Recall message form that is basically exist on any of the computers that are installed with outlook whether it's 32-bit or 64-bit
619.48s - 624.40s |  We can go to this specified directory and find those CFG files
624.80s - 629.44s |  Now you identify that there is a special file called a rack CFG
629.68s - 637.80s |  This is an example of the recall message form you see also that the CFG itself also include the rendering file the recall
638.48s - 643.20s |  DLL basically instantiated automatically through the in proc server 32
644.16s - 649.76s |  Now if you are not using your recall your cloud recall which is kind of the latest thing in through Azure
650.16s - 654.00s |  This is kind of the default built-in if you are sending a special message
655.00s - 661.24s |  You basically identify the class message and the recall DLL is loaded within the context of the outlook and
661.52s - 663.76s |  basically starts to delete from your inbox the
665.56s - 667.56s |  Message that you want to remove
667.72s - 673.72s |  So we want to achieve the same thing we want to exploit the same behavior and define our own CFG
673.72s - 680.40s |  Right with our own DLL that will be put automatically into the victim environment, but can we do that?
681.16s - 682.64s |  So
682.64s - 689.16s |  And here is an example again from this recall call, which is which is a column object, but can we do that?
689.80s - 692.44s |  Well, not exactly. There is a special
693.32s - 695.20s |  mechanism basically
695.20s - 698.52s |  Allow form let's say what's called the bypass
699.20s - 706.32s |  Outlook and by default it's disabled now if it would be enabled you can definitely define such a CFG
706.48s - 713.88s |  You can load it and then you have a form automatically synchronized to your victim environment and you can send a special message that will
714.48s - 717.04s |  Trigger the initiation initiation of the form
717.60s - 724.36s |  But if this flag is basically disabled, which is by default your form goes through a special
724.88s - 730.32s |  Matching algorithm which validates that you are not using special keywords like in proc server
730.80s - 736.92s |  Local handler, which basically automatically instantiate those comb objects or those malicious
737.44s - 740.56s |  DLLs that or executables that are put in this folder
741.20s - 746.60s |  Now one of the problems with this matching algorithm is well, it's noise noisy
747.60s - 754.24s |  So one of the problems with this matching algorithm is that it it is an exact matching it checks for an exact words
754.44s - 760.36s |  Not less not more but an exact words within the keys that are specified in the configuration file
761.88s - 763.88s |  So somehow
764.20s - 770.52s |  We lead basically to the first vulnerability that was discovered by net spy which done amazing work
771.36s - 776.48s |  They introduced into this registry file an additional relative path
824.60s - 826.60s |  Okay, so it's kind of a temporary solution
827.48s - 831.72s |  So, I hope we will finish the presentation till then but again
831.92s - 837.84s |  it's a great finding basically the net spy group added a relative class ID and
838.28s - 840.92s |  It's also documented in Microsoft documentation
841.44s - 844.76s |  That they are clearly say that you can provide a relative path
845.60s - 849.92s |  for your form server rendering and they added that and
850.76s - 854.68s |  Surprisingly because the algorithm of the the checks for the forbidden words
854.96s - 861.44s |  Does an exact matching the algorithm fails and you have automatically instantiated form malicious form?
862.20s - 865.08s |  With a fully controlled class ID of your own
866.12s - 867.96s |  beside that
867.96s - 869.96s |  Vulnerability, they also discovered
870.36s - 872.36s |  kind of a directory traversal
872.92s - 877.80s |  Vulnerability in which basically allows to install that form anywhere on the file disk
878.64s - 885.20s |  Because you can play with this one of the properties, but this property is less interesting for us. It was a nicely patched by
885.72s - 890.84s |  Microsoft, but I will be talking specifically about the bypass algorithm
891.48s - 898.44s |  So now is the interesting part how Microsoft patched that vulnerability and what led us basically to discover new vulnerabilities
898.76s - 904.72s |  Following that patch. So as we see in the patch that was introduced by Microsoft
905.56s - 912.32s |  Microsoft said, okay, you have a problem with the relative path. Let's remove relative path. They didn't update the documentation yet
913.00s - 919.56s |  But they basically removed that functionality. You cannot put a backslash anymore in the property of the form
919.88s - 926.56s |  So great. Okay, it solved the problem, but they didn't change the matching algorithm. The algorithm is still the same
927.12s - 929.12s |  So as you would expect
929.16s - 934.84s |  We were looking for additional control flows that allow us to still instantiate the same forms
935.04s - 938.44s |  By abusing the failure in the matching algorithm
940.26s - 948.10s |  So I have to commend to Microsoft because they have done it quite quickly. We reported on them in April. They patched in June
948.82s - 950.82s |  So nice work
952.27s - 958.39s |  but again before we are diving in to how we created additional control flow we need to
958.95s - 966.91s |  Understand how a Windows core API function works now when you basically register a form
968.51s - 971.99s |  It goes through a process in which they use recreate
972.91s - 980.39s |  XA function. It's also utilized in most of the applications today. It's one of the most popular functions that exist today
980.83s - 984.03s |  One of the properties of this function, which is interesting
984.03s - 991.27s |  You can supply to this function a parameter that composed of multiple keys by separating them through backslashes
991.83s - 998.51s |  Now I think it's limited to 32 keys. So if you are basically using that function with
999.39s - 1003.29s |  31 backslashes as they will create a nested directory structure
1004.55s - 1011.75s |  Automatically and one of the additional properties is that if you provide a registry key with the backslash trailing backslash
1011.83s - 1017.95s |  It will be removed to maintain consistency. It's correct to any reg X a and
1018.47s - 1020.47s |  This will be probably
1020.75s - 1022.75s |  interesting to investigate other applications
1023.59s - 1026.35s |  That may be vulnerable to do the same reason
1027.07s - 1029.07s |  so as you would probably
1029.79s - 1035.87s |  Guess we just added this backslash at the end. So as soon as you add the backslash at the end
1036.87s - 1041.63s |  Obviously it goes through the matching algorithm which does the exact matching
1042.19s - 1049.15s |  It goes through because again, we have the backslash and when the red create reg X create
1049.99s - 1056.67s |  Creates the registry it removes the trailing backslash. And while I you have a fully executing form
1058.15s - 1065.63s |  Written automatically synchronized by Microsoft to any of the victim environments. And what do we need to basically execute?
1066.11s - 1070.47s |  Just to send the message a simple email with the message class of that form
1070.99s - 1074.39s |  so very quickly
1074.39s - 1076.39s |  Just a demonstration
1077.19s - 1091.30s |  Let's see. Okay. I hope you see the video so in this video we will know
1092.98s - 1104.43s |  Okay, it's a problem maybe we can push it here, okay
1106.11s - 1108.63s |  Solution so we'll try to do a play like that
1110.19s - 1112.19s |  Maybe this work
1112.23s - 1113.55s |  Okay
1113.55s - 1114.67s |  remotely
1114.67s - 1115.87s |  Nice
1115.87s - 1123.03s |  Okay. So essentially we are working here on updated outlook. This was recorded in June just before the
1124.07s - 1126.07s |  Patch was introduced by Microsoft
1126.79s - 1134.47s |  We are using a tool by Etienne Stevens called the ruler which basically allows us to utilize the MAPI
1135.47s - 1137.47s |  MAPI API to
1137.59s - 1140.95s |  Synchronize and then create a new form. We didn't have to use that
1140.95s - 1145.35s |  we just could open a client in our environment use the credentials and
1146.11s - 1151.43s |  Create the same form here. We are utilizing and creating the property with the backslash
1152.27s - 1153.75s |  and
1153.75s - 1158.15s |  With the next step. We will be sending right now and authenticated
1159.15s - 1161.73s |  Token that allows us basically to
1162.51s - 1167.35s |  Upload the form and to synchronize it across the different victims
1168.71s - 1171.63s |  So in the next step as soon as it would be sent
1171.63s - 1177.71s |  We will see that the form suddenly appeared on the victim environment. It takes a bit
1178.67s - 1180.67s |  a couple of seconds
1181.27s - 1183.74s |  Okay
1183.74s - 1187.28s |  Good
1187.28s - 1191.24s |  Okay. So here we receive the message. We're still not opening that message
1191.60s - 1198.12s |  The opening of the message will instantiate the execution of the form, but the form was already written
1199.24s - 1204.60s |  Synchronized into the folder. So this is a way in which you can also use the advanced button
1204.60s - 1209.76s |  You can check out the forms or you can simply go to the folder of the forms and identify it
1209.76s - 1214.12s |  So was written as soon as I open that the form
1214.76s - 1220.08s |  Form server is executed as you see it's executed within the context of the outlook process
1220.80s - 1227.84s |  Now the same if you would use not in proc server 32, but let's say local handler it would execute an external application
1228.68s - 1230.68s |  executable the same way
1231.40s - 1233.72s |  Now we need to pull it back somehow
1236.52s - 1240.03s |  No, maybe I just close it
1240.79s - 1242.79s |  Okay
1243.15s - 1245.89s |  Okay
1245.89s - 1251.01s |  Okay, good. So this was a very nice demonstration for a form
1251.05s - 1253.05s |  But again, it's assumed that we have
1253.85s - 1261.81s |  Authentication beforehand. We will show later on how easy it can we can get the authentication the tokens from the environment and have a full RC
1262.69s - 1267.71s |  Non-authenticated again in this case. We do require the credentials of the victim
1269.49s - 1271.49s |  Let's continue
1272.09s - 1277.49s |  Okay, so what do we have here we have a patch to this vulnerability now
1277.49s - 1284.77s |  It's interesting because we just bypassed one patch and this patch was introduced to solve the vulnerability that we discovered
1285.01s - 1289.69s |  Now if you look at the patch again for those that are reversing here
1290.81s - 1298.37s |  They it's probably more clear. But essentially they didn't change the function that checks for the exact strings. They
1298.89s - 1301.81s |  Just decided to remove the trailing backslashes
1302.09s - 1310.13s |  So basically they introduced additional loop that goes over the key and removes all the trailing backslashes and then continue with the same
1310.37s - 1314.69s |  exact matching algorithm instead of looking for a contain etc
1314.77s - 1321.01s |  So I definitely welcome you guys to check out what additional control flows you can find out
1321.65s - 1325.06s |  And maybe you will
1325.06s - 1328.02s |  But it's not all when they introduced that patch
1328.66s - 1333.14s |  They also introduced additional extension for the blocking list
1333.58s - 1337.14s |  Now, it's also interesting those that you identify
1338.54s - 1343.18s |  those special key attributes those key allows hijacking and
1344.62s - 1347.10s |  execution of additional comments or
1348.50s - 1354.46s |  Com hijacking etc. So definitely an interesting additional path to investigate
1354.66s - 1360.70s |  This just shows that there were additional vulnerability in place that could be utilized by an adversary
1362.81s - 1364.81s |  okay, so just
1364.85s - 1366.85s |  to put things
1366.89s - 1370.61s |  In the right order there are more vulnerabilities that were discovered
1371.69s - 1374.13s |  next week there will be patch and
1375.29s - 1377.29s |  for additional vulnerabilities and
1378.09s - 1385.01s |  Well, I suppose we will share the details somewhere month or two months after but we do recommend you to patch your outlook lines
1385.01s - 1388.17s |  Because it's not very difficult. The exploit is very trivial
1390.16s - 1395.22s |  Now again form injection. It's nice for remote code execution
1395.34s - 1398.78s |  But it's not the only way to utilize that type of vulnerabilities
1399.02s - 1403.86s |  Now we can obviously do a persistency with that. We can also escalate privileges
1405.06s - 1408.74s |  If you for example hijack the credentials of an exchange admin
1408.82s - 1415.70s |  We can propagate the same forms across the all the inboxes and do much more damage than just a simple
1416.78s - 1417.78s |  victim
1417.78s - 1425.01s |  So let's talk about for a second about the other part which is missing the authentication
1425.29s - 1428.09s |  Now I'm talking about until the
1429.29s - 1432.61s |  Authentication sorry only in two slides, but there is a nice presentation
1433.49s - 1437.45s |  Tomorrow by someone else that is only talking about NTLM
1438.53s - 1445.53s |  And I trust that it will be great presentation, but NTLM is essentially as a or anti-hash if you would say
1446.21s - 1448.21s |  if you would for example
1448.65s - 1450.57s |  send an email and
1450.57s - 1455.61s |  Send a link to a file and the victim will double-click on those link
1456.45s - 1461.69s |  behind that there will be SMB protocol that will requires basically and
1462.21s - 1469.57s |  response challenge response algorithm that will require authentication and if you are by default not doing a Kerberos authentication a
1469.81s - 1472.01s |  Rock server will take your anti-hash
1472.77s - 1477.09s |  Automatically and the file doesn't have to exist there just you pressing the link
1477.61s - 1479.61s |  but aside of that
1479.89s - 1486.29s |  There were a lot of vulnerabilities that were discovered in 2023 in 2024 it was I think one of the
1487.37s - 1490.37s |  significant years for NTLM leaks all across
1491.01s - 1498.29s |  With zero clicks, so you didn't need to press or get in the warning that there is a SMB file. You just needed to
1498.97s - 1500.61s |  Have an appointment
1500.61s - 1508.57s |  reminder that is sent with a nice kind of link to a sound that it will be sound when the appointment is being sent or
1509.61s - 1515.25s |  Some kind of Windows performance analyzer that is being directed and all kind of additional
1515.97s - 1518.85s |  Exploits that lead to the same NTLM leak, so it's not very
1519.57s - 1523.97s |  Difficult to get NTLM leaks will get into recommendation how it can be blocked
1524.57s - 1529.73s |  Going forward, but one of them is interesting the last one especially
1530.93s - 1535.97s |  NTLM leaks that are led through execution of monikers or compiled monikers
1535.97s - 1539.21s |  And this is a great time to move to Arnold
1539.61s - 1545.45s |  Which will be talking about compound a compound monikers that lead to remote coding code executions and NTLM
1547.76s - 1549.76s |  Okay, then. Thank you Michael
1552.50s - 1555.38s |  So before we diving into the next
1555.90s - 1558.74s |  Marcy vulnerability we discovered in outlook
1558.90s - 1566.70s |  We first need to get at least some high-level understanding of what monikers are and I highly encourage you to dig deeper into the subject
1567.02s - 1567.94s |  as
1567.94s - 1575.06s |  Multiple vulnerabilities in outlook involve moniker on in office applications involve monikers in some way or another
1575.82s - 1576.98s |  now
1576.98s - 1578.82s |  Actually, we are all using
1578.82s - 1585.46s |  monikers will with our daily work with office applications one example is when you try to send an email and
1585.98s - 1588.06s |  in the body of that email you
1588.78s - 1591.54s |  Attach an Excel chart as a link
1592.14s - 1597.90s |  Well a moniker is used to point to that specific Excel chart using a string understood by the
1598.86s - 1602.14s |  moniker mechanism and the monikers involved now
1602.90s - 1606.30s |  the general idea of a moniker is to provide you with some way to
1607.02s - 1611.98s |  locate and identify this specific com object using strings or
1613.66s - 1620.58s |  Instead of writing a custom mechanism to do that and in order to achieve it all monikers must implement
1621.06s - 1623.06s |  the I moniker interface
1623.22s - 1625.22s |  well
1625.42s - 1630.02s |  Microsoft actually provides several implementations of monikers
1630.34s - 1635.70s |  Some of them related to the OLE objects and most notably used in office applications
1636.46s - 1638.46s |  some of these monikers include the
1639.42s - 1641.42s |  file moniker item moniker
1641.94s - 1643.94s |  URL moniker and few more
1645.63s - 1653.27s |  One additional example is using the get object method within the visual basic programming language or its
1653.39s - 1660.75s |  Windows API equivalent the call get object. This is basically a helper function that simplifies the way of
1661.31s - 1662.51s |  converting
1662.51s - 1669.15s |  The moniker string the display name into a moniker and then binding to that named object now
1669.15s - 1674.31s |  It does that by encapsulating calls to the com library functions the create bind
1674.83s - 1677.59s |  MK parts display name and bind to object
1679.39s - 1680.91s |  Okay, so
1680.91s - 1682.91s |  moving back to Outlook
1682.91s - 1690.31s |  Imagine receiving an email with an hyperlink points to a file located on an SMB share if you would click on that file
1690.59s - 1692.59s |  or on that link
1692.91s - 1694.91s |  You won't get a pop-up notification
1694.91s - 1701.83s |  Asks you whether you are sure you want to click on that link clicking on links from untrusted source can do this and that
1702.95s - 1707.59s |  Instead a warning message is displayed in the Windows notification center
1708.11s - 1715.95s |  Stating that something unexpected went wrong with the URL and the file on that SMB share would never be accessed
1716.55s - 1718.51s |  We would expect it to be good, right?
1718.51s - 1724.67s |  so if the file would have been accessed at least the local NTLM credentials would have been leaked as
1725.07s - 1732.79s |  Accessing the file would go through the SMB protocol which relies on the local NTLM credentials to authenticate
1735.02s - 1736.30s |  well
1736.30s - 1740.02s |  earlier this year checkpoint researcher found a vulnerability in
1740.42s - 1747.06s |  Outlook that bypasses that warning message by simply adding an exclamation mark at the end of that of that link
1748.06s - 1750.54s |  Apparently this turns the hyperlink from
1751.54s - 1753.02s |  simple
1753.02s - 1755.46s |  hyperlink that points to a file moniker
1756.18s - 1761.74s |  Into a generic composite moniker that is composed from a file moniker and an item moniker
1762.30s - 1764.38s |  clicking on such a link results in
1764.90s - 1771.14s |  Accessing the file leaking the local NTLM credentials and potentially allow for remote code execution
1772.86s - 1775.46s |  So let's dive in and understand how this is happening
1776.42s - 1780.70s |  Most Microsoft Office applications load the MSO DLL
1780.70s - 1787.34s |  Which is a core component used by multiple office applications and the DLL contains essential
1787.70s - 1789.70s |  functionalities that is splitted between
1790.54s - 1795.70s |  Multiple DLL some of them are presented the one we are interested with the
1796.34s - 1800.50s |  Vulnerability discovered by checkpoint is the MSO 30 DLL
1800.82s - 1805.50s |  Which handles things related to links and links parsing and to be more specific
1806.34s - 1812.94s |  The MSO HR link rate from string function. That is a wrapper for H link rate from string
1813.46s - 1819.62s |  That basically creates hyperlink object from strings that represents the hyperlink target
1820.26s - 1822.26s |  if you would look at the
1822.66s - 1828.86s |  Documentation for H link rate from string we see that it starts with the security warning that states
1829.70s - 1835.38s |  Never pass strings from a non-trusted source when creating hyperlinks with H link rate from string
1835.50s - 1839.14s |  The target parameter is passed to MK parse display name
1839.66s - 1843.62s |  Now you might be wondering what is wrong with MK parse display name
1843.62s - 1844.94s |  We'll get it in a second
1844.94s - 1847.34s |  But before that take a look at the second paragraph
1847.86s - 1855.50s |  You can see that it is mentioned that if a string of the form suggested in the checkpoints vulnerability a composite moniker
1856.14s - 1862.30s |  Is passed it will instantiate the object registered with the specific prog ID and
1863.06s - 1865.54s |  If it implements the I moniker interface
1866.50s - 1869.06s |  It can in turn run unexpected code
1870.34s - 1876.54s |  And it doesn't stop just there looking at the documentation for MK parse display name
1877.30s - 1882.98s |  We see that it states that calling MK parse display name with a display name parameter
1883.58s - 1888.22s |  From an untrusted source is unsafe and it can lead to some moniker
1888.62s - 1892.26s |  Implementations to act on the string during the parsing of it
1894.25s - 1898.61s |  Well, if you take a closer look at how it happens in the code
1898.81s - 1904.93s |  We see that when there is a character indicated that the string is a composite moniker
1905.81s - 1912.17s |  And by the way, not only by the exclamation mark, but also the opening square bracket and colon
1912.53s - 1915.37s |  The parsing of that composite moniker
1915.81s - 1920.49s |  Would go through the MK parse display name for handling with of course
1921.17s - 1924.37s |  Composite monikers instead of creating a file moniker
1924.89s - 1929.81s |  now when MK parse display name is called it will call the
1930.45s - 1932.45s |  bind to object method which
1933.33s - 1940.77s |  eventually involves the relevant com object responsible for handling with the specific file type pointed to by the
1942.17s - 1947.85s |  File moniker. For instance, if the file pointed to by the file moniker is an RTF
1948.41s - 1951.73s |  WinWord will be spawned in the background without displaying the UI
1952.09s - 1956.37s |  it will access the file pointed to by the file moniker and
1956.77s - 1964.17s |  If that and sorry and will try to access the object low and pointed to by the item moniker
1965.53s - 1967.53s |  Let's move on
1967.81s - 1971.77s |  Now this behavior leads to two significant issues first
1972.33s - 1977.61s |  The file is being accessed. So we have an NTLM credential leak and
1978.21s - 1980.01s |  Second the file is being parsed
1980.01s - 1987.81s |  So any RC involved in the parsing will never be in the parsing routine can be chained to gain full RC
1988.53s - 1990.57s |  Now one important note
1990.57s - 1998.17s |  I want to point is that characters other than the exclamation mark can trigger this vulnerability and it's important
1999.01s - 2003.57s |  From a detection and prevention standpoint as it wasn't mentioned anywhere else
2005.79s - 2009.75s |  Now before we diving into the patch analysis and how we bypassed it
2010.11s - 2015.67s |  We first need to understand how Microsoft patches some vulnerabilities in office applications
2016.47s - 2023.11s |  Surprisingly or not they use hooks which are installed from the in editors function within the MSO DLL
2024.07s - 2026.07s |  apparently each office application
2026.23s - 2033.99s |  As its own application ID and before the hook is installed the in editors function checks that
2034.51s - 2042.03s |  The current process has a valid application ID and well this techniques kind of reminds us hot patching, right?
2043.03s - 2045.83s |  pinpointing a specific API in a specific location
2046.99s - 2050.15s |  only by a specific processes and
2050.79s - 2054.39s |  As well, these API's are being used system wide
2055.03s - 2057.03s |  Across many other applications
2059.24s - 2063.40s |  Now moving on to the patch itself as you can see Microsoft
2063.60s - 2069.12s |  Updated the in editors function to add hooks for the MK parse display name API's
2071.64s - 2078.64s |  the hook simply checks if a flag named block MK parse display name on current thread is set to true and
2079.16s - 2086.64s |  If that's the case as the name suggests MK parse display name would not be invoked and it will return an error instead
2089.31s - 2094.31s |  now you might be wondering where that flag is being set if you recall the
2095.03s - 2097.39s |  MSO HR link create from string that
2098.07s - 2100.95s |  responsible for creating hyperlink objects from strings
2101.55s - 2109.43s |  Sets the flag to true at the beginning of the function and it only does that if the application ID equals outlook
2111.77s - 2114.85s |  looking at the patch analysis and a
2115.77s - 2121.83s |  Few questions comes in mind. Well, I'm sure that some of you already asking yourselves these questions
2121.89s - 2130.01s |  Well, the whole hyperlinks creation goes through the MSO HR link create from string where that flag was being set to true
2130.97s - 2137.89s |  What about other code flows that may reach the unsafe API the MK parse display name?
2139.81s - 2141.81s |  What about the
2142.01s - 2147.25s |  Application ID we've seen comparison to outlook only what about other apps
2147.89s - 2152.50s |  To answer these questions. I want to do a quick recap
2153.06s - 2154.74s |  the following diagram
2154.74s - 2160.54s |  Demonstrates the interesting API calls when clicking on a composite moniker hyperlink within
2161.06s - 2163.68s |  an email before the patch was
2164.34s - 2166.34s |  employed and
2166.82s - 2169.02s |  This is how it looks after the patch
2169.78s - 2173.82s |  We have the addition of the block MK parse display name flag
2174.66s - 2178.06s |  that is being set to true at the beginning as we said and
2179.10s - 2183.02s |  The deterred functions checks that flag and acts accordingly
2184.06s - 2192.04s |  We were looking for ways to get to the unsafe API the MK parse display name
2192.64s - 2194.64s |  without going through the
2195.04s - 2200.20s |  AP the function that sets that flag to true and we found a candidate
2200.88s - 2203.20s |  the HR payment from URL
2204.28s - 2206.28s |  we found that doing some
2206.52s - 2214.12s |  cross referencing through the relevant API calls and we've seen that this one may reach the unsafe API and
2215.16s - 2220.92s |  As a matter of fact, this is how we got to discover the RC vulnerability and outlook
2222.85s - 2229.93s |  when you pass a composite moniker within an image tag the parsing of that composite moniker won't go through the
2230.13s - 2236.57s |  MSO HR link rate from string that was patched instead. It will invoke the HR payment from URL that
2238.21s - 2242.61s |  Handles things and those the parsing of the URLs from image tags
2242.61s - 2247.77s |  and it will directly call the H link parse display name that
2248.41s - 2255.61s |  Will eventually got the same code flow that reaches to the unsafe API MK parse display name
2256.61s - 2263.09s |  And now that we are familiar with how Microsoft patches some vulnerabilities in office applications
2263.73s - 2265.73s |  The patch is quite obvious, right?
2266.45s - 2269.69s |  setting the infamous flag to true, but this time from
2270.89s - 2277.07s |  HR payment from URL and again only if the application ID equals outlook
2278.05s - 2284.45s |  Now to sum up these two patches we saw that Microsoft only addresses specific code flows
2285.21s - 2287.69s |  And specific scenarios that leads to the
2288.77s - 2295.73s |  unsafe API the MK parse display name and we left some questions open for you to investigate and
2296.25s - 2298.25s |  We are certain that there are
2298.77s - 2303.37s |  More applications and more code flows that leads to that unsafe API
2306.87s - 2308.71s |  okay, just
2308.71s - 2310.47s |  some additional note
2310.47s - 2317.67s |  As Arnold shared and thank you Arnold Microsoft patch the remote the code execution by introducing this additional
2318.71s - 2325.27s |  Hook and turning on the flag through this control flow. It didn't solve the NTLM leak
2325.95s - 2332.03s |  now we obviously didn't want to publish it, but we got a response from Microsoft that there is a
2333.39s - 2337.23s |  medium risk and for Microsoft it's not in the urgency and
2337.27s - 2338.51s |  And
2338.51s - 2342.75s |  The fact that the image cannot be automatically downloaded
2343.83s - 2347.51s |  Because you have a kind of a preview mode if the sender is not trusted
2348.15s - 2352.19s |  And they are right if it's lender is not trusted the image will not be automatically
2352.47s - 2356.39s |  Downloaded and the compound moniker will not be automatically executed
2356.71s - 2358.99s |  But if the sender is trusted
2359.59s - 2361.03s |  again someone in the
2361.07s - 2367.47s |  Organization let's say it was compromised and you utilizing his credential to send to the other victim within the same
2367.71s - 2372.79s |  Organization the same link the image will be automatically downloaded or previewed
2373.31s - 2377.43s |  And the NTLM will happen and this is unfortunately wasn't patched
2378.71s - 2384.95s |  So let's let's just finalize. We have a couple of minutes left some recommendations
2386.47s - 2388.31s |  Some of them are obvious
2388.35s - 2395.99s |  Microsoft basically writes a lot about some of the recommendations obviously in forest care boroughs Windows 11 introduces
2396.39s - 2402.99s |  I think an update already introduced update in which by default NTLM authentication will
2403.35s - 2409.15s |  Will not be possible. I suppose it will not hold for a long due to backward compatibilities, etc
2410.63s - 2412.63s |  Definitely enable SMB signing
2413.23s - 2420.71s |  And manage your outbound SMB you don't want that kind of let's say network communication going outside of your organization
2421.35s - 2425.19s |  And there are definitely additional recommendations that can follow
2426.15s - 2427.71s |  now just
2427.71s - 2432.75s |  Before we kind of end that presentation some credit references again as we mentioned
2433.23s - 2436.47s |  Net spy is doing great work discovering new stuff
2437.47s - 2440.03s |  Check point also as well and so as
2440.55s - 2443.63s |  Etienne Stevens, I'm sure I'm missing a lot of other folks
2444.27s - 2449.03s |  Because a lot of work is being invested you guys are welcome to ask our questions
2449.95s - 2454.11s |  We will be waiting here behind at the entry door for like 10 minutes
2454.75s - 2460.55s |  But overall we are done. We it's an honor to present them at the DEF CON
2460.63s - 2465.27s |  We are thanking you to come here to see our presentation
2465.27s - 2467.51s |  Thank you


url: https://www.youtube.com/watch?v=KnCp5K51IEA
title: DEF CON 32 - Cultivating M4D SK1LLZ In the DEF CON Community - Yan Shoshitaishvili, Perri Adams
type: video
author: DEFCONConference
ingestion_date: 2024-11-10
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=KnCp5K51IEA",
  "title": "DEF CON 32 - Cultivating M4D SK1LLZ In the DEF CON Community - Yan Shoshitaishvili, Perri Adams",
  "description": "DEF CON is a siren song for the hacker mind. Clever people around the world hear it and are pulled, every year, to Las Vegas. They mass by the tens of thousands, streaming through the halls of DEF CON to watch talks given by absolute legends about incredible escapades, to gaze in wonder as true wizards bend bytes to their will in the CTF room, and to dream about one day reaching to those heights themselves.\n\nSome have the critical combination of grit, perseverance, raw talent, and (let's face it) privilege to push through to those dreams of greatness. But among even the clever and the motivated, it is rare for n00bs to rise to l33tness without support. Some find this support in inspiring classes in college. Others, among friends or mentors. But many don't find it at all, and remain in the hallways, dreaming.\n\nDo you want to leave the hallways and hack the planet? We are hackers, educators, and learners who are creating DEF CON Academy, a concerted effort to maximize hacker potential by providing open, clear, approachable, and inclusive practical resources for budding hackers to transcend and rule cyberspace. Through extensive DEF CON event presence and year-round hacking resources, we will pro up the noobs of the world and bring the community, at scale, to the next level of skill.\n\nCome, listen, and learn how we can help!",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2565,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.02s - 6.50s | This text was transcribed using whisper model: large-v2

 Alright. Welcome to the sneak peek for uh something you're super excited about. Barry and I
6.50s - 13.50s |  have been working on this for a little while now. Um along with the amazing people you see
13.50s - 18.50s |  on stage here. We'll talk about everybody in turn. But first we'll talk about Defcon Academy.
21.18s - 26.18s |  So. Uh is there a can people see the slides somewhere? Oh they can. Oh great perfect. Alright.
27.18s - 32.18s |  So first things first. On the slide there's a URL. CTF dot Defcon Academy. While we talk go
37.62s - 42.62s |  there. CTF dot Defcon Academy. On the bottom there's a link to get started with a little
46.00s - 52.80s |  challenge race. It's not extraordinarily hard stuff. It's it's test your Linux knowledge. How
52.80s - 59.26s |  much Linux do you know? At the end we're gonna do a little award ceremony for the people
59.26s - 63.34s |  farthest ahead in that race. We'll just see how many people we have time to give challenge
63.34s - 68.24s |  points to. It's gonna be awesome. And we'll check in throughout the the talk if we have time.
68.24s - 73.24s |  Awesome. Okay. Welcome. Let's talk about us. Yes. I think that's a great idea. Uh Barry take it
75.62s - 82.26s |  away. I don't know why I'm first. But. Hi. My name is Perry Adams. I'm currently a uh special
82.28s - 87.62s |  assistant to the director at DARPA. But before that I was as you can see on the screen a uh
87.62s - 93.96s |  CTF player. That picture in the middle is proof that at one point in time I did know how to use a
93.96s - 98.96s |  computer. Uh the jury's still out on if that's still the case. Uh oh. Uh case in point.
103.00s - 108.00s |  Computers. How do they even work? Uh but I played for uh the CTF team RPI sec and that picture
108.96s - 113.96s |  is of us playing at DEF CON finals uh in 2018. And uh RPI sec and CTF was really how I got
118.96s - 124.34s |  started playing uh I got started in computer security. And that's really what we're gonna be
124.34s - 129.74s |  talking about today. The kind of uh education that that provided me and how we want to give
129.74s - 135.12s |  that to the rest of you. As I was putting together these slides uh what was next to all those
135.14s - 140.18s |  pictures was a picture of my cat and because it's DEF CON I thought it was appropriate to at
140.18s - 145.72s |  least have one of those in the slides. Uh after I played CTF for a while I ran DEF CON CTF
145.72s - 151.46s |  for a little bit. Uh that is uh from one of the years where we were writing challenges. That
151.46s - 158.26s |  picture is of uh three uh two of my uh uh fellow challenge authors the year that our challenge
158.26s - 163.20s |  melted the infrastructure just a little bit which goes to show that computers are hard and
163.22s - 168.92s |  I'm not sure if I know how to use them correctly. And now in my day job I am at DARPA where
168.92s - 174.80s |  one of the things that I have done is create AICC which if you haven't seen yet I really
174.80s - 180.56s |  encourage you to go check it out over there. We're very proud of what we've been able to do.
180.56s - 187.08s |  And the kind of software security challenges that AICC is working to address is exactly what
187.12s - 193.96s |  we hope to educate people about with DEF CON Academy. And uh finally I have this picture up
193.96s - 200.70s |  here because I talked about how I learned about computer security by playing CTF but what was
200.70s - 207.08s |  so formative for me was having my teammates on RPISEC to help me learn. When I first got
207.08s - 213.08s |  started they told me that I could not have hypothetically let's say they told me I could not
213.08s - 218.10s |  have IDA until I had learned how to solve a CTF challenge using OBJDUMP. And if you haven't
221.10s - 227.20s |  seen the output of OBJDUMP that's what a binary looks like. It's much less pretty than IDA and
227.20s - 233.28s |  this was of course before we had Ghidra. But when I was doing this I had people I could call
233.28s - 238.18s |  I had uh I could phone a friend I could get help and that's really what we're trying to do.
238.18s - 242.46s |  What they've been trying to do with DEF CON Academy.
242.46s - 248.50s |  Thanks Mary. So before I talk about myself which I love doing I want to uh check on one
248.50s - 254.20s |  terrifying thing. Oh this is counting upwards. Okay thank God. Alright. Awesome. So then we can
254.20s - 264.20s |  just calmly continue. Alright. I'm Zardis and I am uh I can say with some trepidation that I'm
265.08s - 273.80s |  that I'm way too loud. Um that I've been coming to DEF CON since DEF CON 9. This is super cool
273.80s - 285.84s |  DEF CON 9. Is that my feedback? You gotta keep them separated. DEF CON 9 was it's this guy.
286.72s - 311.43s |  That's what it's like working with Jan. Every day. Alright. You wanna. Every time.
317.22s - 327.30s |  Ladies and gentlemen the Dark Tangent. Honorary AV uh maestro. Okay cool. So um I've been coming
327.30s - 336.50s |  to DEF CON since DEF CON 9. Right. This was a long long time ago. Um and uh from DEF CON 9 up
336.50s - 342.58s |  until DEF CON 17 I would come to DEF CON. I'd wander the halls. I'd look around at all this
342.58s - 349.78s |  incredible hacking. I'd get really amped up but I wasn't really making progress. I was slowly
349.78s - 354.50s |  very very slowly building up my skills over the course of eight years and then after eight years
354.50s - 362.26s |  an eternity in cyber security time I finally got into CTF. I started playing CTF with team
362.26s - 371.22s |  Shellfish and then my life as a hacker ah my life as a hacker accelerated rapidly. Uh within
371.22s - 378.02s |  a couple years from that I'd created with uh my uh colleagues one of the uh most powerful
378.02s - 388.02s |  binary analysis tools on the planet. Later with uh also amazing colleagues we started hosting
388.02s - 393.54s |  DEF CON CTF. We went from running it uh from playing in it to hosting it. Then I became a
393.54s - 402.98s |  professor. That's still us? I gotta get to my alright. Uh later we went from uh
403.54s - 407.54s |  playing to hosting and then I became professor at Arizona State University.
409.99s - 417.64s |  Dude I feel like I'm at a sci-fi. This is awesome. This is great. We can probably just turn this one
417.64s - 432.45s |  off. Awesome. Okay. So um and all of this happened relatively quickly once I started playing CTF and
432.45s - 440.45s |  once my security knowledge started getting ramped up very rapidly and there was this inflection point
440.45s - 448.21s |  in DEF CON 17 but that took eight years to get there right and what I've been thinking for a
448.21s - 454.21s |  long long time is how do we accelerate that? What was missing here? And Perry alluded to it.
455.17s - 466.13s |  When I started I didn't have a group that could mentor. I was a high schooler but that doesn't
466.13s - 471.81s |  stop people. I've seen high schoolers accelerate rapidly in cyber security skill when they have
471.81s - 481.51s |  the right environment to enable them right and so our question was our question was how do we
482.15s - 488.95s |  actually make this possible for the DEF CON community? Alright. Preview. It looks like a belt.
489.83s - 501.67s |  Alright. So DEF CON 17. Shellfish. DEF CON CTF. This is my view into what the difference was from
501.67s - 506.87s |  before I was a pro to after I was a pro and and spoiler alert I'm still not a pro but I would
506.87s - 513.91s |  tell all of my students if you want to get really great at cyber security you have to go play CTF
513.91s - 521.83s |  right and this is a picture for example of my students playing one of the CTFs that I hosted
521.83s - 531.59s |  with Adam who's sitting right here and they show up and they do awesome but this is the success
531.59s - 538.39s |  stories that you see what you don't see in the CTF community is the hundreds and hundreds of
538.39s - 547.27s |  students for every one that play CTF that try to play CTF and face the reality that
547.27s - 554.47s |  capture the flag competitions are not designed for education they're designed to test your skills
555.43s - 567.86s |  so this is intentional in CTF. A CTF competition is created by hackers for hackers to challenge
567.86s - 575.86s |  hackers specifically and no one wants to play a CTF where the answers are all obvious and the
575.86s - 582.74s |  challenges are easy and so on and and so CTFs basically by definition become a very boring
582.74s - 587.62s |  teaching tool. And when I got started playing CTF the thing that was fun about it was that I had a
588.26s - 594.10s |  team who I'd play with and we'd go and we'd spend 48 hours in a lecture hall that we certainly did
594.10s - 600.74s |  not we weren't allowed to actually be in overnight but that's what we would do and it felt very
600.74s - 605.70s |  collaborative and we could learn from each other but for many people they don't have that resource.
606.58s - 613.46s |  Yeah and so figuring out what a replacement resource is for that that's one of the challenges
613.46s - 620.66s |  that we kind of set to ourselves that resulted in DEFCON Academy. That's DEFCON Academy's first
620.66s - 628.50s |  goal. Our first goal is getting people from DEFCON 9 to DEFCON 17. Getting them to the point where
628.50s - 635.78s |  they can start have the skills to start playing CTF to start contributing actively in cyber
635.78s - 644.42s |  security and then we have a second question. Something that I've seen recently as I've
644.42s - 649.94s |  trained up more and more students with cyber security knowledge is that people learn this
649.94s - 656.26s |  knowledge they have the technical skills to dive into CTF competitions to really start accelerating
656.26s - 662.42s |  more and more and more but they there's still something missing. The competition part of a CTF
662.42s - 670.66s |  competition the chaotic environment the lack of educational resources specific to do with
670.66s - 677.22s |  cutting-edge CTF challenges that makes things hard and that is where the mentorship that Barry
677.22s - 684.18s |  mentioned comes in. So how do we streamline that process? Get people once they have technical skills
684.18s - 689.54s |  to actually engage with a community where they can test these skills and and interact with others
689.54s - 700.34s |  that are doing so. Then how do we keep pulling that talent back into DEFCON so that we can have a
701.94s - 707.30s |  kind of self-reinforcing loop that'll continue with the community continue building the community
707.30s - 720.60s |  more and more. A little louder? Then I get the if I do this hold on test all right we're still good
720.60s - 730.60s |  okay no uh you know tone of god over here okay so um and then of course once people go and they
730.60s - 734.76s |  they they learn all the cyber security stuff and they're cyber security master hackers how do we
734.76s - 741.64s |  get people to actually be able to use this as a living? How many of you make a living doing
741.64s - 751.72s |  cyber security? Awesome. How many don't but would like to? All right so how do we get you
752.84s - 758.60s |  to the place where you can make that living? And then how many of you are cyber security pros
759.24s - 767.83s |  master hackers? I see my students trying to raise their hands over there uh one day well we'll get
767.83s - 774.95s |  you there as well. All right so the answer of course DEFCON Academy and DEFCON Academy is going
774.95s - 781.75s |  to at least take steps to solve all of these problems. So Perry what do you hope to see out
781.75s - 789.35s |  of DEFCON Academy? Well so DARPA has a history of funding work in uh cyber security education but
789.35s - 797.03s |  specifically in things like binary exploitation vulnerability research etc uh things like DARPA
797.03s - 803.43s |  chess uh focus on uh improving computer human interactions that was something that you all
803.43s - 809.43s |  worked on. We actually have some other PMs in the office or in the audience who are leading some of
809.43s - 816.07s |  these efforts and so that was really what DEFCON Academy came out of for for DARPA was how can we
816.07s - 822.23s |  bring the cyber security education resources that we've been developing and open sourcing
822.23s - 828.15s |  uh with uh the many groups that DARPA works with including ASU and how do we bring them to the
828.15s - 835.51s |  community? And so what I really hope to get out of this is uh we've spent a decade more than that
835.51s - 841.67s |  uh researching how to best educate people in this space uh that combined with all of the expertise
841.67s - 847.91s |  that running DEFCON CTF playing DEFCON CTF and other kinds of CTFs have built up I I think there's
847.91s - 853.11s |  a huge amount of potential to revolutionize how we do cyber security education especially in
853.11s - 859.51s |  the vulnerability research binary exploitation memory safety space which is so fundamentally
859.51s - 867.35s |  important today. I agree and you know what I would build on that with is that whatever specific
868.31s - 877.43s |  first uh goal you set for students binary exploitation memory safety etc the if you can get
877.43s - 884.47s |  a hacker to skill up to that you can get them to skill up to web security you can get them to skill
884.47s - 893.43s |  up to network operations to threat hunting it all folds together and use a common uh process of
893.91s - 903.03s |  process of learning and thinking about our own experiences talking long long hours with
903.03s - 911.51s |  dark tangent we came up with this idea that hey let's actually make a part of DEFCON that is
912.07s - 917.99s |  hyper optimized to make this happen for students. So but I want to add one other thing too the other
917.99s - 922.79s |  part of this is is uh set up and the pain and suffering that goes into actually creating an
922.79s - 927.67s |  environment in which you can learn uh and the infrastructure part is boring and sometimes we
927.67s - 931.91s |  don't think about that as research but having played a lot of CTF I know that setting up an
931.91s - 936.55s |  environment is very annoying very painful and when I first started out that was the last thing I
936.55s - 941.75s |  wanted to learn how to do. I didn't know how to boot Linux when I joined RPISec that's very
941.75s - 947.83s |  embarrassing uh so I'm sharing it here today and we're not gonna spread that uh and so I think one
947.83s - 955.35s |  of the best aspects of this and one of the uh other pillars is that it removes the initial uh
955.35s - 961.03s |  pain from learning and it puts you into the fun environment immediately. So how can we
962.55s - 968.95s |  take a random DEFCON attendee grab them out of the hallway and once they start stop screaming and
968.95s - 977.51s |  hitting us actually give them an opportunity to just start learning immediately. No startup costs
978.23s - 986.39s |  no confusion just go and in other words how can we take this DEFCON 9 to DEFCON 17 eight years
987.27s - 993.99s |  and we narrow them down well. I actually think the best way to put it is how can we make Connor
993.99s - 1000.79s |  do all of the infrastructure set up for uh DEFCON attendees. Exactly it's uh basically uh
1001.19s - 1007.99s |  uh tasking all the way down um because the answer to that is Connor will find his own students.
1009.27s - 1015.27s |  All right so there's two parts to learning there's a lot of learning research learning
1015.27s - 1021.67s |  learning is is a thing that humans have done maybe for years maybe even decades. So
1022.55s - 1028.79s |  there's theory and practice right you might say well okay let's have a DEFCON academy that that
1028.79s - 1035.99s |  runs courses we'll like have uh you know our powerpoint slides we'll pull in hackers off the
1035.99s - 1041.59s |  out of the hallway and we'll uh have them viewing the powerpoint slides and I did this I do this a
1041.59s - 1046.31s |  lot this is a picture of my students from last semester. No I'm just kidding I pulled this off
1046.31s - 1052.47s |  the internet but because my students are all riveted in class but just like you all exactly
1053.27s - 1059.51s |  you have all been in classes throughout your life where things are boring people are rambling on
1059.51s - 1067.35s |  about the stack gets subtracted from when a function starts and you get a lot of information
1067.35s - 1072.79s |  and not a lot of it sticks right you might have like one or two practice problems but
1073.91s - 1079.27s |  the modern state unfortunately of cyber security education is actually pretty poor
1079.67s - 1085.59s |  and this is uh really interesting because it's understandable academically there's this thing
1085.59s - 1090.95s |  called the learning pyramid full of really awesome made-up numbers where you know you can say hey if
1090.95s - 1096.47s |  I go and I lecture to you you will learn like five percent of the material or retain five percent of
1096.47s - 1101.99s |  the material but if I you know have you read about it uh yourself you'll you'll learn more
1102.95s - 1109.67s |  and if I uh have you practice actually practice the stuff you will learn a majority you'll learn
1109.67s - 1115.75s |  75 percent of it and then of course this whole thing the bottom you got to teach someone to
1115.75s - 1121.91s |  learn it all but this is called the learning pyramid it's like all um a lot of actual
1122.47s - 1130.47s |  education research that has come into gone into building this and it really um showcases kind of
1130.47s - 1138.71s |  what's wrong with a lot of modern cyber security education and what you end up with most modern
1138.71s - 1145.51s |  coursework is you get an enormous amount of information you pump up your brain you get the
1145.51s - 1153.43s |  theoretical info but you can't really apply it in practice and it's like if in karate kid
1153.43s - 1159.91s |  mr miyagi made uh explained to the karate kid how to wash a car and they never actually did
1159.91s - 1164.39s |  the wax on wax off and then he throws him into the ring and the kid gets beat up and we don't
1164.39s - 1174.07s |  have our awesome uh ending all right so can't quite do existing coursework all right well that's
1174.07s - 1180.31s |  not a problem because there's a whole conference where every year for an entire weekend people
1180.31s - 1188.79s |  descend into las vegas and learn and and and and celebrate hacking and party which conference is
1188.79s - 1196.07s |  that yawn i forget the name escapes me at the moment jeff do you know sorry i'm unplugged
1198.23s - 1205.75s |  everyone has uh yeah i've heard rumors yeah exactly i i think it might be um penny arcade expo
1205.75s - 1215.57s |  no of course we're talking about you all about defcon but i went to a defcons it's very easy
1215.57s - 1219.89s |  to go to a defcon and wander around aimlessly who here has aimlessly wandered through defcon
1220.85s - 1227.01s |  yeah yeah me too and and and it's an incredible experience you have to of course aimlessly
1227.01s - 1234.29s |  wander through defcon for some amount of time but we also want to have a much more streamlined
1234.29s - 1242.05s |  optimized and guided path to learning available to the people that want it all right so then
1242.05s - 1249.33s |  when i started the professor i said okay i understand all this stuff now i see that ctf
1249.33s - 1254.29s |  is a problem because i keep sending my students to ctf and they keep you know just disappearing
1258.40s - 1269.12s |  yeah but there are these things called war games war games are these incredible collections of
1269.12s - 1276.64s |  challenges online i maintain a list at wargame.nexus if you're interested hundreds thousands
1276.64s - 1282.24s |  of hacking challenges available to anyone that wants them you can go and and and and start right
1282.24s - 1291.84s |  the problem is it's very similar to what plagues ctf from an educational perspective right perry
1291.84s - 1298.32s |  you've done war games i have and actually i think rpi sacks modern binary exploitation one of the
1298.32s - 1304.16s |  first uh online courses uh in this uh in this stuff is on that list and that was how i learned
1304.80s - 1310.40s |  it is and modern binary exploitation is an excellent example of a war game created
1310.40s - 1316.80s |  educationally because it has educational materials and it has challenges to reinforce this but the
1316.80s - 1324.08s |  majority of war games out on the internet are also made to show off the challenge writing skill of
1324.08s - 1332.64s |  the author which is awesome and test and and and challenge the people solving which it makes it
1332.64s - 1337.92s |  very difficult to actually learn with i'll say that i could not have done the course material i
1337.92s - 1342.80s |  did i could not have done the war games i did without having friends who could help me when i
1342.80s - 1348.24s |  got when i got stuck that was that was the defining factor and so what what i found when i would push
1348.24s - 1354.00s |  this war game idea is that it worked as long as i was there to mentor the students about once a week
1354.48s - 1362.32s |  the moment i disappeared the war game attempt broke down as a learning uh route at scale
1363.04s - 1369.84s |  right and you know you can't really blame people for this there you can only sit so long at a
1369.84s - 1374.72s |  computer confused and and lost look at this picture this guy's even thinking of going to
1374.72s - 1379.60s |  the beach down there on the top left for some reason um before it gets too old but
1379.92s - 1384.64s |  but as barry said there are good educational style
1386.24s - 1391.76s |  materials out there and we kind of ran with this and this is something we're bringing into
1391.76s - 1401.12s |  Defcon Academy we created Pwn College. Yon, what is Pwn College? Well Barry, I'm glad you asked.
1402.08s - 1410.80s |  Pwn College is a revolution in online security education but it's only one it's a paradigm shift
1410.80s - 1416.16s |  it's a paradigm shift Jeff understands the uh DoD language that i'm trying to bring to the talk
1416.16s - 1422.00s |  today exactly but the talk isn't necessarily about Pwn College we're using Pwn College
1422.00s - 1430.32s |  as an example here as one part of Defcon Academy uh Pwn College is an online teaching tool first
1431.44s - 1438.64s |  and challenge tool second and I'll show you what I mean the way that we teach in Pwn College is we
1438.64s - 1446.80s |  take a topic over here we have this this this guided path carefully curated through for real
1446.80s - 1452.56s |  we're 10 minutes late 10 minutes left I'm just starting to to talk 10 minutes until
1453.28s - 1459.52s |  till belting okay okay and I'd encourage you to visit uh Pwn.college uh right now Yon claims that
1459.52s - 1468.72s |  you can even do it on your phone yeah you can so quick thing Pwn.college guided materials it has
1470.24s - 1478.80s |  lectures that introduce the core of a topic that five percent and then to explore the edge cases
1478.80s - 1484.40s |  that you will be confused about if you only retain that five percent we have challenge problems
1485.36s - 1491.92s |  hundreds of challenge problems that will pull your knowledge wider and wider and wider and
1491.92s - 1497.92s |  let you understand the concept it's as if we took Mr. Miyagi and we put him in your web browser
1499.88s - 1504.60s |  Pwn.college starts at the very beginning which some of you are doing right now the Linux Luminarium
1504.60s - 1511.08s |  goes through incredibly advanced material where by the time you finish Pwn.college you will have
1511.16s - 1520.68s |  exploited uh JIT vulnerabilities in Chrome's v8 etc etc yeah and I want to interject and say that
1520.68s - 1525.88s |  this is all in your web browser like you just said and that is a fundamentally important concept
1525.88s - 1532.76s |  here uh when I uh showed that uh objjump earlier I was on my iPad and I needed a Linux terminal
1532.76s - 1537.32s |  and I just pulled up Pwn.college and I booted into it but when you say there's v8 challenges
1537.32s - 1543.08s |  when you say there's Linux kernel challenges that is the truly impactful thing students don't have
1543.08s - 1546.76s |  to stand up their Linux kernel they can go to the browser students don't have to stand up a Linux
1546.76s - 1552.60s |  environment they can go to the browser and it's an Ubuntu uh instance with Ghidra and Idafree
1552.60s - 1560.28s |  and all of the resources they might need that is very powerful. And in fact we can well let's see
1560.28s - 1566.92s |  if we have time to demo it we were going to demo it on stage but that's fine um there is an
1566.92s - 1572.44s |  enormous amount of material already we're building out more to pull DEF CON hackers
1573.24s - 1580.92s |  kicking and screaming through into having uh practical demonstrable skills that they can
1580.92s - 1592.20s |  then build up on we have uh let's uh actually talk about one thing here we have a set of material
1592.20s - 1598.60s |  where at every stage of your cyber security journey you get a reward you've gamified learning
1598.60s - 1604.60s |  and we've done it with belts over here in about 10 minutes we'll have a belting ceremony
1605.96s - 1609.64s |  where people that have gone through the material before will earn their belts
1611.08s - 1617.64s |  and walk out of here belted. Who uh. The first uh the first of a yearly ceremony something we'll
1617.64s - 1624.12s |  talk about very soon. Who uh who here is gonna get belted? Awesome you guys start lining up
1625.00s - 1633.16s |  and we'll give you all a hand in a second all right so uh and and and this is a uh
1633.16s - 1638.60s |  tradition now in Pwn College that goes back a long way this is uh me with with Connor and his PhD
1638.60s - 1644.12s |  defense um and he's uh. Sign up on the uh on this side of the stage. A bunch of belts here we send
1644.12s - 1652.92s |  them out all over the world and we drive you into these crazy experiences with Pwn College where
1652.92s - 1657.96s |  like we said earlier you're exploiting v8 you're exploiting the Linux kernel you understand all of
1657.96s - 1664.92s |  this ideally understand it well on a practical perspective when where you can demonstrably
1664.92s - 1670.52s |  carry out these exploits even though you might have come to Pwn College without knowing what
1670.52s - 1678.44s |  Linux is right. As Perry says this is all doable on the internet turnkey you just go to Pwn.college
1678.44s - 1685.08s |  and you start up. All right so that's Pwn College that's not Defcon Academy. What is Defcon Academy?
1686.04s - 1693.24s |  Defcon Academy will use Pwn College and other resources like Pwn College another amazing one
1693.24s - 1699.88s |  is CryptoHack. Who here has heard of CryptoHack? Awesome if you like Pwn College also check out
1699.88s - 1706.28s |  CryptoHack it is in a lot of ways extremely similar in philosophy but for cryptography
1706.28s - 1718.04s |  right. During the Defcon party event during this weekend we're going to have a dedicated space
1718.04s - 1725.88s |  where you can go and you can start Pwn College you can continue Pwn College you can earn belts
1726.60s - 1736.76s |  for your uh progress in Pwn College where we'll have dedicated tutors like Perry Adams
1737.48s - 1746.53s |  who will sit down and remember when she was doing her first buffer overflow. And Connor Nelson
1747.17s - 1749.57s |  and Adam Dupay. I don't know if you want me as your tutor.
1750.13s - 1759.09s |  Um we'll have skill demonstrations we'll have uh exploitation races between people that have
1759.09s - 1764.85s |  just learned the material we'll have a lot of hype it's going to be really really awesome right and
1764.85s - 1769.65s |  it's going to be a place at Defcon specifically created specifically dedicated toward learning
1771.25s - 1778.05s |  specifically dedicated toward taking people that don't have the skills but want them and turning
1778.05s - 1783.81s |  them into people who do have the skills and are ready to apply them and we'll have something going
1783.81s - 1791.41s |  year round year round we will have regular help sessions live on twitch or discord where we will
1791.97s - 1798.93s |  help people learn four minutes and these these guys so all right we've covered the first third
1798.93s - 1805.89s |  of the talk so far yeah don't worry it's our fault that's how we we start in but as I mentioned after
1805.89s - 1811.65s |  people build the skills there's still a bit of a gap in applying them in practice whether it's a
1811.65s - 1822.05s |  chaotic environment of a CTF or a um or a you know the real world of of cyber security and so for the
1822.05s - 1829.01s |  chaotic environment of the CTF we have a solution with Defcon Academy sorry with Defcon Academy
1829.01s - 1835.73s |  we are working with some of the top CTF teams in the world the people that you see most years
1836.69s - 1844.45s |  up there on the the Defcon CTF contest area hacking away their entire Defcon with crazy
1844.45s - 1852.21s |  difficult cutting edge challenges and we're working with them to create a CTF Academy
1852.21s - 1858.77s |  where as you graduate from those first eight years track which hopefully will be compressed a
1858.77s - 1866.29s |  lot as you graduate from Pwn College and similar platforms you will be apprenticed in CTF teams
1866.29s - 1871.01s |  with top hackers such as Clasm over there who lead you through
1873.09s - 1879.65s |  who will lead you through learning to actually dive into real security all right how will we
1879.65s - 1885.41s |  help Defcon itself with Defcon Academy not just the attendees but the the community well
1886.05s - 1893.41s |  we'll skip to one specific thing a couple days ago or yesterday I guess uh um
1895.41s - 1905.81s |  Jake Braun announced uh Defcon Franklin. Defcon Franklin is an initiative to help change the world
1905.81s - 1913.65s |  by facilitating the volunteering of Defcon resident expertise in places in the public world
1913.65s - 1918.77s |  where they're needed well they need the expertise and Defcon Academy will be creating a lot of
1918.77s - 1927.17s |  expertise we'll work to create a channel from Defcon Academy to Defcon Franklin to make this
1927.17s - 1933.73s |  a reality and give you who goes through Defcon Academy the output to show off those skills
1934.69s - 1944.61s |  all right um let's talk about who is part of Defcon Academy who is Defcon Academy
1944.61s - 1950.61s |  could you say that for a second first the Chancellor we have the Chancellor of Defcon
1950.61s - 1959.25s |  Academy the one and only the Dark Tangent then I forgot which order I have this in the Vice Chancellor
1960.21s - 1967.41s |  the Paribas the Provost of Defcon Academy yours truly
1968.21s - 1976.45s |  this is Artis we have the Dean of Binary Exploitation Adam Dupay elbow elbow wrist wrist
1977.73s - 1985.97s |  Adam Dupay is a uh uh master hacker who has hosted Defcon CTF right by my side you've seen
1986.85s - 1994.13s |  him with me uh at the closing ceremonies very very very lucky to have him supporting our binary
1994.13s - 2001.33s |  exploitation route the Dean of Reverse Engineering Fish if you know CTF you know this legend uh
2001.33s - 2008.61s |  probably one of the top reverse engineers in the world now teaching you how to be like him
2008.61s - 2014.05s |  which is a terrifying thought he can read straight assembly code like it's uh like
2014.05s - 2020.53s |  it's source code it's scary all right we got the Dean of Student Advocacy Rob Waas where are you
2020.53s - 2027.33s |  Rob Waas Rob Waas is advocating for uh students to get belts off stage over here and the Dean
2027.33s - 2036.29s |  of Educational Technologies Connor Nelson he is the reason that Pond College is usable over a browser
2036.29s - 2042.21s |  or usable at all really I wasn't joking when I said he's the one doing the infrastructure
2042.21s - 2047.49s |  all right that being said this is just what we're starting with the goal right now is to get a
2047.49s - 2053.81s |  minimum viable product of Defcon Academy because we're launching in full next year next year we'll
2053.81s - 2062.93s |  have in-person uh amazing uh area where you'll be able to learn etc etc etc and we'll have
2062.93s - 2067.49s |  kind of a proof of concept of all of it we'll have a proof of concept at least one CTF team
2068.45s - 2073.73s |  already shall we just sign up maybe at least two CTF teams that are ready to take and apprentice
2073.73s - 2081.17s |  awesome people we'll have multiple uh platforms like Pond College ready to go and we'll have
2081.81s - 2089.41s |  a couple of ways that you can go and help Defcon but as we extend we need more deans so if you
2089.41s - 2095.89s |  are interested in being a dean of Defcon Academy and are interested in spreading your knowledge
2096.53s - 2107.65s |  to budding hackers talk to us all right let's do the belts okay so Pond College has a set of
2107.65s - 2114.45s |  different steps and materials first students come in knowing nothing and they learn and they learn
2114.45s - 2120.85s |  introductory concepts in cyber security command injection in simple websites uh
2121.81s - 2127.73s |  uh file permission issues these sort of things after they learn that they earn the orange belt
2128.69s - 2135.97s |  they move on to learn about how the security of programs fail things like buffer overflows
2138.61s - 2144.93s |  things like how to reverse engineer programs to find issues etc they earned a yellow belt at that
2144.93s - 2150.93s |  stage they move on to system security talking about going from user space to kernel space
2152.21s - 2161.33s |  through a race condition uh uh vulnerability inside a kernel driver for example then they
2161.33s - 2169.25s |  earn the green belt and finally they go through crazy esoteric and advanced concepts in software
2169.25s - 2177.01s |  exploitation stuff like micro architectural uh side channel attacks and other just absolutely
2177.01s - 2182.85s |  wild things and they earn their blue belt so we'll be belting uh do we have blue belts today
2184.37s - 2191.33s |  wow three blue belts today all right awesome so we'll be belting all sorts of people right now
2191.33s - 2197.73s |  we'll go through them and dark tangent and the rest of the Defcon Academy team will confer
2198.21s - 2206.53s |  their new hacker ranks let's start with the orange okay awesome all right come on up
2208.85s - 2215.57s |  all right you can say your handle if you want uh gordon all right well congratulations
2218.05s - 2226.45s |  congrats and uh over here oh we'll get a picture all right and you are just john john just john
2226.45s - 2236.61s |  okay welcome yeah no all right up next we have i'm chloe chloe welcome congrats
2241.59s - 2253.16s |  jonathan jonathan welcome spicy dll spicy dll congratulations
2257.40s - 2261.96s |  oh dirac delta you're getting your blue belt no i'm giving yellow your yellow belt okay well
2261.96s - 2278.02s |  i recognize you anyways all right i'm such a noob sasha noobs josh l josh l josh l welcome
2287.48s - 2297.09s |  wherever i'm eddie eddie welcome all right these hackers have pushed through
2297.97s - 2308.69s |  increasingly insane material like material that really is is almost insane to have
2308.69s - 2314.05s |  in some educational contexts uh material where at the end of it these blue belts out there
2316.69s - 2322.13s |  yeah we'll do a picture we'll stand forever all right so the blue belts over here we're afraid
2322.13s - 2328.05s |  of them because i am a thousand percent sure that with their knowledge they're like one step away
2328.05s - 2341.04s |  from exploiting the punk college server itself all right let's honor these amazing hackers with
2341.04s - 2356.12s |  their achievement awesome all right good job guys so five minute mark okay so this is an event that
2356.12s - 2362.52s |  we're gonna get increasingly crazy about um in the in person now let's do the uh
2364.04s - 2368.68s |  yon is very sane he would never get crazy about anything yeah let's check out one more thing
2369.56s - 2387.08s |  ctf.defcon.academy we'll see the scoreboard oh oh it's not that's interesting yeah it's not one
2387.08s - 2395.56s |  sec i have to uh for us let me load out this up i think i have to hit escape nope
2398.04s - 2406.92s |  hit escape here yes perfect okay what's your password well the username is demo
2409.32s - 2416.76s |  all right actually right 404 file not found you gotta join that seems bad connor you gotta join
2417.72s - 2422.12s |  i don't want to join i just want to look at a scoreboard well you gotta join it's private okay
2424.90s - 2433.14s |  nice come on all right 20 people hacking now in the audience 24 people have solved things there's
2433.14s - 2443.30s |  603 total solves let's look at the rankings is our server melting absolutely not it's definitely
2443.38s - 2449.22s |  the defcon wi-fi it's not a live demo all right while while uh that's loading we'll just pull
2449.22s - 2455.94s |  this up on my phone have you tried refreshing it's spinning it's got i tried turning it on
2455.94s - 2464.42s |  and off again ctf oh this is this is probably it's loading it says loading there we go
2465.62s - 2472.02s |  okay awesome we have someone that solved the whole thing who is chi chesum right there
2472.98s - 2477.94s |  all right oh nice well you can come back up and get uh a challenge coin
2478.66s - 2481.78s |  do you have one who's oh where's knob knob goose knob knob goose is here
2482.34s - 2489.06s |  another name i recognize knob knob goose isn't here is are they just hacked in all right
2489.06s - 2493.86s |  knob knob goose you can come get a challenge called santa montes shunt derek delta if you
2493.86s - 2499.86s |  have solves on defcon academy run up get a challenge coin in the meantime
2500.66s - 2506.74s |  thank you for uh coming to this soft launch preview of defcon academy um
2508.02s - 2517.30s |  that started from the beginning we'll just fast forward here two minutes that's two more minutes
2517.30s - 2526.90s |  than we need my friend all right awesome so defcon academy wouldn't exist if it wasn't for
2527.78s - 2534.34s |  the awesome efforts of you all who dive into this educational stuff and make it worth it
2534.34s - 2539.86s |  and it wouldn't exist if it wasn't for the awesome efforts of the dark tangent
2539.86s - 2546.58s |  who supports these awesome sort of things and perry thank you because you your vision
2546.58s - 2555.94s |  made this actually possible you're welcome all right and all of these guys awesome thank you
2556.26s - 2558.82s |  and connor nelson and connor nelson
2561.38s - 2564.66s |  thank you hey you finished early


url: https://www.youtube.com/watch?v=KqKj_VY-AHY
type: video
author: DEFCONConference
ingestion_date: 2024-11-10
transcription_model: large-v2
chunking_status: completed
title:
DEF CON 32 - MobileMesh RF Network Exploitation Getting the Tea from goTenna - Erwin Karincic, Woody

content:
{
  "webpage_url": "https://www.youtube.com/watch?v=KqKj_VY-AHY",
  "title": "DEF CON 32 - MobileMesh RF Network Exploitation Getting the Tea from goTenna - Erwin Karincic, Woody",
  "description": "False sense of security in devices that guarantee security is worse than no security at all. One device used by personnel who require communication security is goTenna Pro radio that creates an \"off-the-grid\" encrypted mobile mesh network.This network does not require any traditional cellular or satellite infrastructure and they may be found locally in your community. The datasheet says it is using AES-256 encryption. Has anyone bothered to verify that it is being implemented in the most secure manner? We examined this device and found that it was possible to fingerprint and track every off-the-grid message regardless of encryption. We also identified vulnerabilities that result in interception and decryption of the most secure encryption algorithm AES-256 as well as injection of messages into the existing mesh network. We don\u2019t just trust what datasheets say, we verify it for you. We will explain our testing methodologies and demonstrate exploitation in a live demo. We will discuss the operational implications of these vulnerabilities and safe ways of using these devices that decrease the chance of a compromise. The tools developed as part of this research will be released open-source to inform what was possible to inspire future research against similar devices. We will discuss how we worked with goTenna to remedy these issues.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2599,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.05s - 4.05s | This text was transcribed using whisper model: large-v2

 Welcome to DEF CON. First speaker's up. Let's give him a big hand.
4.05s - 16.14s |  Thank all of you for being here. Really appreciate it.
16.14s - 20.14s |  So, the first thing we want to talk about is,
20.14s - 24.14s |  this whole talk has really been pushed because of how much
24.14s - 27.14s |  the technology out there is moving to mesh technology.
27.14s - 31.14s |  Everything's mesh. From cellular, we have mesh-tastic,
31.14s - 34.14s |  LoRa, all these different creations.
34.14s - 37.14s |  But one of the creations that has been around for quite a while
37.14s - 40.14s |  that we're going to talk about is Gotenna.
40.14s - 44.14s |  And we're going to talk about all three stages that we've seen it go through.
44.14s - 47.14s |  My name's Woody. This is Erwin.
47.14s - 50.14s |  Yeah, I'm Erwin Korenczyk. I go by Dollar Hyde.
50.14s - 53.14s |  And we also want to make sure that we give credit to Clayton Smith,
53.14s - 57.14s |  who really did a ton of work on the second generation
57.14s - 61.14s |  and made this talk possible. So, thank you very much for that.
61.14s - 68.26s |  Awesome. Yeah, thank you, Clayton.
68.26s - 71.26s |  Multiple mesh networks, the way that they typically work is,
71.26s - 74.26s |  one device will talk to another. You're able to go through and pivot.
74.26s - 77.26s |  And that way, you can get extended range.
77.26s - 80.26s |  You can have multiple people communicate at the same time.
80.26s - 82.26s |  There's a lot of things that you can do.
82.26s - 85.26s |  Now, one of the things with a traditional network is the way that your data
85.26s - 89.26s |  and your controls are handled versus the way that Gotenna mesh does it.
89.26s - 93.26s |  So, the Gotenna's capability of meshing is actually really efficient.
93.26s - 97.26s |  And that's one of the things that makes it fairly unique
97.26s - 101.26s |  is because they've combined that and made it pretty controllable.
101.26s - 106.82s |  So, some of you seven years ago may have seen the talk that I did
106.82s - 113.66s |  in the RF Hacker Sanctuary.
113.66s - 118.94s |  It was on Gotenna version 1, this one right here.
118.94s - 121.94s |  So, what you're seeing on the screen right now is as he goes through
121.94s - 126.94s |  and does the Gotenna or his script, this was our original exploit.
126.94s - 131.94s |  And what we figured out was the Gotenna is designed over Bluetooth
131.94s - 134.94s |  to communicate with a phone, at least the Gen 1 and 2 were.
134.94s - 139.94s |  Once that happens, then you can send a message that can be either open
139.94s - 144.94s |  in a broadcast or person-to-person or in a group, but you can encrypt it.
144.94s - 147.94s |  And that's what you're seeing here on the screen.
147.94s - 152.94s |  But we were able to see seven years ago that it was broadcasting
152.94s - 154.94s |  some things plain text.
154.94s - 158.94s |  And when it broadcasted things plain text, the things that you could see,
158.94s - 162.94s |  even in encrypted mode, were the unique identifier,
162.94s - 165.94s |  which for the unique identifier for the Gen 1 and 2 by default,
165.94s - 167.94s |  can anyone tell me what it was?
167.94s - 169.94s |  Your cell phone number.
169.94s - 174.94s |  So, this script is demonstrating how we could run against a Gotenna version 1
174.94s - 177.94s |  and pull your phone number out of the air,
177.94s - 179.94s |  even if you were using encrypted mode.
179.94s - 184.94s |  Now, they fixed that since, well, they've evolved since then.
184.94s - 188.94s |  And the new management has really made an effort to try to fix
188.94s - 190.94s |  some of the issues that have happened in the past.
190.94s - 193.94s |  But this on the screen is actually what it looks like
193.94s - 195.94s |  when we're able to come in here and pull this data.
195.94s - 198.94s |  Yeah, and you can see the phone number, call sign, and the message
198.94s - 200.94s |  in unencrypted mode.
200.94s - 203.94s |  In encrypted mode, payload is not visible, but the phone number still is.
203.94s - 205.94s |  So, this was Gen 1.
205.94s - 207.94s |  And if you want to see a live demo of this, come to RFHackers.
207.94s - 209.94s |  We're showing just the video here.
209.94s - 214.26s |  So, Gen 1, we see how it communicates.
214.26s - 218.26s |  Now, Gen 2, they changed some things.
218.26s - 221.26s |  Instead of using 2FSK, they moved to 4FSK.
221.26s - 224.26s |  But by default, there were still a couple things that were the same
224.26s - 227.26s |  that we were able to start exploiting.
227.26s - 230.26s |  Clayton specifically found some really great things
230.26s - 232.26s |  that were vulnerable here.
232.26s - 234.26s |  A lot of them were similar to version 1,
234.26s - 238.26s |  but you needed a 4FSK demodulator to do it.
238.26s - 240.26s |  But you could still find the phone number.
240.26s - 244.26s |  You could still find some of those unique identifiers.
244.26s - 246.26s |  And as we're going to discuss, those unique identifiers,
246.26s - 249.26s |  even if they're not your phone number, can be a bad day.
249.26s - 252.26s |  So, this is an example of exactly what we could pull
252.26s - 255.26s |  while you think you're doing encrypted messages.
255.26s - 257.26s |  And we start getting your phone number.
257.26s - 259.26s |  We can start seeing some of your messages,
259.26s - 262.26s |  depending how you're using it.
262.26s - 265.26s |  And we're going to talk how that can be effective
265.26s - 271.64s |  for other things as well.
271.64s - 276.64s |  Now, the current version of Gotenna, the Gotenna Pro,
276.64s - 278.64s |  we started working with.
278.64s - 281.64s |  One of the things that I do is I'm staffed in the RF Hacker Sanctuary,
281.64s - 285.64s |  the RF Village, so please come and try some of our challenges out later.
285.64s - 287.64s |  That's actually how a lot of these things get discovered,
287.64s - 290.64s |  is people trying them in challenges.
290.64s - 292.64s |  Some things that were fixed.
292.64s - 294.64s |  You did not have to connect via Bluetooth,
294.64s - 297.64s |  because we all know that Bluetooth by itself can be a unique identifier
297.64s - 300.64s |  that can be used to find somebody or come after them.
300.64s - 303.64s |  They improved it so you could use either Bluetooth
303.64s - 307.64s |  or you could actually hard line to your phone with the device.
307.64s - 310.64s |  And then the only thing that was communicating was either at, you know,
310.64s - 316.64s |  the 140 to 170 megahertz band or 445 to 480.
316.64s - 319.64s |  They also improved the channels you could use.
319.64s - 321.64s |  You had some bandwidth things you could control.
321.64s - 325.64s |  So, on initial viewing of this,
325.64s - 328.64s |  it looked like it was a much more secure device.
328.64s - 331.64s |  But this is what we're going to be talking about.
331.64s - 342.01s |  This is basically the Gen 3.
342.01s - 346.01s |  Why is it important for us to worry about what we give out?
346.01s - 349.01s |  Well, we have some representatives from Wiggle here,
349.01s - 352.01s |  and I'm sure that they can tell you how important it is
352.01s - 354.01s |  to protect your MAC addresses.
354.01s - 356.01s |  In fact, the industry has already started making sure
356.01s - 358.01s |  that unique identifiers start rolling
358.01s - 360.01s |  and that it's much more difficult to track them
360.01s - 363.01s |  because you can be tracked over space and time,
363.01s - 366.01s |  geographical location, and it can be used to fingerprint.
366.01s - 368.01s |  So that's why we're worried about this.
368.01s - 371.01s |  It also gives out unique identifiers about you.
371.01s - 375.01s |  What if I couldn't just tell that you were using that MacBook,
375.01s - 377.01s |  but I could tell you whether Tim was using it
377.01s - 380.01s |  or whether Jeff was using it, right?
380.01s - 382.01s |  That's even more refined,
382.01s - 384.01s |  and that's what we're going to start getting into in here.
384.01s - 386.01s |  And that is why, to us, it was so important.
386.01s - 389.01s |  Both of us, our primary jobs,
389.01s - 391.01s |  when we're not doing this stuff for fun,
391.01s - 394.01s |  is to actually help people protect their RF signature
394.01s - 397.01s |  and to help people have good cybersecurity
397.01s - 400.01s |  in vehicles, in equipment that they use,
400.01s - 402.01s |  and global travels.
402.01s - 409.79s |  So some of the problems that we started wondering about.
409.79s - 411.79s |  Is there any chance that we can find
411.79s - 413.79s |  some of the same vulnerabilities in a Gen 3
413.79s - 415.79s |  that we find in a Gen 1?
415.79s - 417.79s |  Yeah, so basically we're looking for those GIDs
417.79s - 418.79s |  for the call signs.
418.79s - 420.79s |  We're looking, are they present?
420.79s - 421.79s |  Have they fixed it?
421.79s - 422.79s |  Yeah.
422.79s - 424.79s |  Because it's been seven years,
424.79s - 425.79s |  we wanted to see whether or not
425.79s - 427.79s |  all those things had been fixed or not.
427.79s - 430.79s |  And some things had, and some things we found
430.79s - 432.79s |  were still somewhat vulnerable.
432.79s - 435.79s |  But having that base is what we moved from
435.79s - 437.79s |  to be able to do all the rest of this.
437.79s - 439.79s |  So having a good foothold,
439.79s - 442.79s |  and then from there, pushing out and finding new things.
442.79s - 448.73s |  So who are we? Erwin?
448.73s - 449.73s |  Yeah, so I'm Erwin.
449.73s - 451.73s |  I'm a security researcher.
451.73s - 453.73s |  I'm experienced in hardware and software reverse engineering
453.73s - 455.73s |  as well as RF exploitation.
455.73s - 458.73s |  My mission is essentially what's shown on the screen
458.73s - 460.73s |  as well as the overall mission
460.73s - 462.73s |  to protect this nation and its citizens
462.73s - 464.73s |  by identifying and mitigating threats
464.73s - 466.73s |  before those threats are even known to these people.
466.73s - 469.73s |  So this is one example of that mission
469.73s - 472.73s |  to protect the people that serve us.
472.73s - 473.73s |  My name's Woody.
473.73s - 475.73s |  I'm staff for the RF Hacker Sanctuary,
475.73s - 480.73s |  or the RF Village.
480.73s - 481.73s |  I was one of the co-authors
481.73s - 484.73s |  of the original Gotenna attack, Raptor Captor,
484.73s - 487.73s |  some other vehicle exploits, and some things like that.
487.73s - 489.73s |  I spent 20 years in special operations
489.73s - 492.73s |  before I started playing in this world.
492.73s - 495.73s |  And the reason that this is so important to both of us
495.73s - 498.73s |  is we work with law enforcement.
498.73s - 499.73s |  We work with government.
499.73s - 502.73s |  We work with corporations.
502.73s - 505.73s |  And we educate them on how to control
505.73s - 507.73s |  and understand all the different aspects,
507.73s - 509.73s |  not just the physical, but also the digital
509.73s - 512.73s |  and even the light aspects of what happens in your life
512.73s - 514.73s |  and why it's important.
514.73s - 517.73s |  So that's what got us to this point.
517.73s - 524.86s |  So just having encryption is not enough.
524.86s - 525.86s |  Configurations matter.
525.86s - 529.86s |  Imagine having an amazing router with WPA3,
529.86s - 533.86s |  an incredible password, and everything's good to go,
533.86s - 535.86s |  but you just leave it as an open network.
535.86s - 539.86s |  You still have encryption, but does it matter?
539.86s - 541.86s |  Not at that point.
541.86s - 544.86s |  Configurations, and that's what we're going to talk about.
544.86s - 546.86s |  Yeah, so this was our testing setup.
546.86s - 549.86s |  So we were testing in an anechoic chamber at the university
549.86s - 552.86s |  where I'm pursuing my PhD in electrical and computer engineering.
552.86s - 555.86s |  We used a representative sample of both iPhones and Androids
555.86s - 557.86s |  connected with Gotenna Pros.
557.86s - 559.86s |  And then we used just open-source hardware and software,
559.86s - 562.86s |  so HackRF1 connected with open-source software
562.86s - 564.86s |  running on an Ubuntu laptop.
564.86s - 567.86s |  So very simple.
567.86s - 569.86s |  So the first step of any sort of RF analysis
569.86s - 572.86s |  starts by identifying the frequency and capturing the signal.
572.86s - 575.86s |  This can be done either by analyzing FCC documentation,
575.86s - 576.86s |  by scanning the whole spectrum.
576.86s - 578.86s |  In this case, it was configurable.
578.86s - 579.86s |  We figured out where it was configurable,
579.86s - 581.86s |  so we set those frequencies,
581.86s - 583.86s |  and then we appropriately captured it in GQRX
583.86s - 585.86s |  as seen on the waterfall on the right.
585.86s - 587.86s |  And this doesn't take expensive equipment.
587.86s - 591.86s |  $30 TV dongle, some $100 radios.
591.86s - 594.86s |  You can really start moving along very quickly.
594.86s - 596.86s |  100%.
596.86s - 598.86s |  So then we started analyzing the signal
598.86s - 601.86s |  and figured out that Gotenna Pro was using 4FSK.
601.86s - 603.86s |  That is four-level frequency shift keying.
603.86s - 607.86s |  That's where the carrier shifted between four discrete frequencies.
607.86s - 608.86s |  As we can see on the screen,
608.86s - 612.86s |  it goes between negative 1.5 and positive 1.5.
612.86s - 614.86s |  We implemented a custom GNU radio flow graph
614.86s - 620.86s |  that can decode this exact type of 4FSK that Gotenna was using.
620.86s - 623.86s |  Once we were confident that our demodulation was successful,
623.86s - 626.86s |  we started analyzing raw bytes,
626.86s - 628.86s |  and their ASCII representation.
628.86s - 630.86s |  In this case, in Gen 1 and Gen 2,
630.86s - 634.86s |  we were able to see the GID, the call sign, and the payload
634.86s - 636.86s |  all unencrypted.
636.86s - 639.86s |  So this was sort of like we're seeing here.
639.86s - 643.86s |  It is encrypted somehow because we cannot see any of the data.
643.86s - 646.86s |  It's more of an obfuscation, really.
646.86s - 651.86s |  So then we sent two identical messages, and we compared them.
651.86s - 655.86s |  So we see that in yellow color, they're mostly the same.
655.86s - 657.86s |  They only differ in the red color,
657.86s - 660.86s |  and red only is the one that changes
660.86s - 662.86s |  if the same packet is being sent.
662.86s - 667.86s |  So this is very commonly some form of static encryption in use.
667.86s - 670.86s |  This observation is actually data whitening,
670.86s - 673.86s |  not to be confused with white shadowing.
673.86s - 679.36s |  Mainly because white shadows rarely work.
679.36s - 680.36s |  Yeah.
680.36s - 682.36s |  So data whitening is a technique that ensures
682.36s - 684.36s |  that there are no long sequences of zeros
684.36s - 687.36s |  that can cause drops in communication.
687.36s - 691.36s |  It uses XOR with a static set of bytes.
691.36s - 693.36s |  Those bytes are typically generated by something
693.36s - 695.36s |  called linear feedback shift register,
695.36s - 697.36s |  and we're going to talk about it later.
697.36s - 699.36s |  It's important to note that while this is similar
699.36s - 701.36s |  to XOR encryption, it is not cryptographically secure,
701.36s - 705.77s |  as we will demonstrate in the next few slides.
705.77s - 708.77s |  So our de-whitening process is shown in this algorithm.
708.77s - 711.77s |  We transmit a handful of As followed by a handful of Bs.
711.77s - 713.77s |  So for those who are not familiar with
713.77s - 716.77s |  ASCII representation in hex, capital A is 41,
716.77s - 718.77s |  so you'll see that a lot through our presentation,
718.77s - 720.77s |  and B will be 42.
720.77s - 723.77s |  So we transmit a handful of number of As,
723.77s - 726.77s |  we extract a byte from that transmission,
726.77s - 730.77s |  and we XOR it with 0x41, which is capital A,
730.77s - 733.77s |  and then that will give us our potential key stream.
733.77s - 736.77s |  We then use that key stream against the second message,
736.77s - 738.77s |  which is with Bs, and then we repeat that
738.77s - 740.77s |  for the length of the entire message.
740.77s - 742.77s |  And then we only keep the bytes that produce
742.77s - 745.77s |  the accurate result, i.e., we receive the Bs.
745.77s - 751.69s |  At that point, we found our offset at 42.
751.69s - 755.69s |  This means that Gotenna is offsetting this
755.69s - 757.69s |  like the entire, probably the header,
757.69s - 759.69s |  because we've seen in the beginning
759.69s - 761.69s |  that the header and data are combined.
761.69s - 764.69s |  So in this case, the payload will start off at 42,
764.69s - 767.69s |  and we found all of the green bytes in the first green line.
767.69s - 769.69s |  And when we apply that against the message,
769.69s - 772.69s |  we get 42s, and we translate that to ASCII.
772.69s - 773.69s |  Those are Bs.
773.69s - 776.69s |  So we have a partial whitening key.
776.69s - 778.69s |  Then we can use this against a different message.
778.69s - 781.69s |  So here we have the payload between 0 and 71.
781.69s - 784.69s |  We can de-whiten everything after 42,
784.69s - 786.69s |  so all part in orange, we de-whiten,
786.69s - 789.69s |  and then we can receive that, okay, we have seen 10As.
789.69s - 792.69s |  So we have 1041s and also the 0A
792.69s - 794.69s |  that's also represented as the lengths.
794.69s - 798.69s |  However, Gotenna is using a custom header,
798.69s - 801.69s |  so we do not know what the 0 to 41 is.
801.69s - 805.69s |  And the only way to find a whitening key for something
805.69s - 807.69s |  is you have to know what's there.
807.69s - 809.69s |  So we keep looking.
809.69s - 811.69s |  So we're investigating special conditions,
811.69s - 813.69s |  so we reiterate that we cannot,
813.69s - 816.69s |  we don't know what's below 42.
816.69s - 819.69s |  So we observe a special condition
819.69s - 821.69s |  when we set 100As.
821.69s - 823.69s |  What happens there is that the message splits.
823.69s - 825.69s |  As you can see here, our capture
825.69s - 827.69s |  received two different messages.
827.69s - 830.69s |  So then let's investigate that.
831.69s - 833.69s |  So we run the same exact strip
833.69s - 835.69s |  that was shown in that algorithm
835.69s - 836.69s |  against the second message,
836.69s - 839.69s |  and we see a potential XOR starting at byte 2
839.69s - 841.69s |  instead of 42.
841.69s - 843.69s |  So this means this is a fragment split,
843.69s - 844.69s |  the message split,
844.69s - 847.69s |  and the payload started at offset 42.
847.69s - 850.69s |  So we now have extra 40 bytes shown in green.
850.69s - 852.69s |  We combine them with the already existing key
852.69s - 856.69s |  that we found earlier between 42 and 96.
856.69s - 860.69s |  And then that gives us a key between 2 and 96.
860.69s - 862.69s |  Now we use that, we use that key,
862.69s - 864.69s |  so we take our packet,
864.69s - 866.69s |  we apply the key between 2 and 96,
866.69s - 867.69s |  and now we're seeing the payload,
867.69s - 869.69s |  but we're not only seeing the payload.
869.69s - 870.69s |  We're also seeing the call sign.
870.69s - 872.69s |  So my call sign is $hide,
872.69s - 874.69s |  and we can see that in blue.
874.69s - 876.69s |  That is very critical.
876.69s - 878.69s |  So another part that Gotenna was using
878.69s - 881.69s |  was Gotenna Identifier, or GID.
881.69s - 883.69s |  So in this case, we could not easily identify there.
883.69s - 885.69s |  It was not, like, easily seen.
885.69s - 887.69s |  So, but we do have a known value,
887.69s - 889.69s |  and this is very important against known values.
889.69s - 891.69s |  If we have a known value, i.e. in the app,
891.69s - 894.69s |  it told us the very bottom part at 1029,
894.69s - 895.69s |  that's our GID.
895.69s - 896.69s |  So we're looking for that.
896.69s - 898.69s |  So eventually, we discover it in the green,
898.69s - 901.69s |  in the orange part in the packet.
901.69s - 904.69s |  It is encoded in a very special way.
904.69s - 907.69s |  So first, the seven bits
907.69s - 909.69s |  that are containing the actual number,
909.69s - 910.69s |  and then the most significant bit
910.69s - 912.69s |  indicates where another byte is following.
912.69s - 915.69s |  So that's how they avoid the use of, essentially,
915.69s - 916.69s |  for example, as you can see,
916.69s - 919.69s |  the 0A in both the payload and the call sign,
919.69s - 920.69s |  that's the length.
920.69s - 922.69s |  That's how they can sort of avoid, like,
922.69s - 924.69s |  be more efficient of the use of the data stream
924.69s - 926.69s |  within the radio.
926.69s - 927.69s |  So that's simple enough.
927.69s - 929.69s |  We can write this Python decode script
929.69s - 930.69s |  to decode the GID,
930.69s - 932.69s |  and then we can take the orange bytes at the top
932.69s - 934.69s |  and get the orange bytes at the bottom.
934.69s - 936.69s |  Relatively simple.
936.69s - 938.69s |  So now, our next part was, like,
938.69s - 940.69s |  okay, let's discover the byte zero.
940.69s - 942.69s |  So FCC comes to the rescue.
942.69s - 944.69s |  They have a lot of useful information.
944.69s - 946.69s |  I highly recommend FCC documentation.
946.69s - 949.69s |  So that says, the FCC essentially says
949.69s - 952.69s |  that GOTEN is using SI4460 radio,
952.69s - 954.69s |  and that radio, based on its documentation,
954.69s - 957.69s |  adds length as byte zero.
957.69s - 958.69s |  So that means that we can find our node.
958.69s - 959.69s |  We take our packet.
959.69s - 960.69s |  We take the length.
960.69s - 962.69s |  We get that 69.
962.69s - 964.69s |  So then we have to subtract 1
964.69s - 965.69s |  because that is the length byte.
965.69s - 966.69s |  So we get 68.
966.69s - 969.69s |  We convert decimal 68 to hex,
969.69s - 970.69s |  and we get 44.
970.69s - 972.69s |  And then the ciphertext was 47.
972.69s - 974.69s |  We extort a 2, and we get 3.
974.69s - 979.69s |  So that is our widening byte at byte zero.
979.69s - 981.69s |  For byte one, we did a lot of testing,
981.69s - 983.69s |  and eventually we figured out it was 96.
983.69s - 985.69s |  So we'll kind of skip all the detail there
985.69s - 987.69s |  because it's a short presentation.
987.69s - 989.69s |  So in our current de-widening status,
989.69s - 991.69s |  we have pretty much everything from byte zero to 96.
991.69s - 994.69s |  We do not, unfortunately, know what last 10 are.
994.69s - 998.69s |  So, of course, we do more investigation.
998.69s - 1001.69s |  We find that the 2 bytes immediately following the message
1001.69s - 1005.69s |  are a result of CRC16 CCITT variant.
1005.69s - 1008.69s |  CRC16 stands for Cycle Redundancy Check.
1008.69s - 1011.69s |  It's used as error-correcting code
1011.69s - 1013.69s |  that is capable of determining
1013.69s - 1016.69s |  whether or not the payload has been corrupted in the transmission.
1016.69s - 1018.69s |  So that's a very quick way to determine that.
1018.69s - 1020.69s |  So we also do more analysis.
1020.69s - 1023.69s |  We figure out that this CRC is initialized with zeros,
1023.69s - 1025.69s |  and it uses 1021 as the polynomial.
1025.69s - 1028.69s |  So then we take the entire packet up to those 10 bytes,
1028.69s - 1030.69s |  and we compute the CRC16.
1030.69s - 1033.69s |  So here on this slide, you can see the Python script that we implemented.
1033.69s - 1037.69s |  So it's using zeros, and 1021 is the polynomial.
1037.69s - 1039.69s |  So then we run it through that function.
1039.69s - 1042.69s |  We put the packet that we saw earlier through that function,
1042.69s - 1046.69s |  and then we get the CRC16 value is DCD2.
1046.69s - 1049.69s |  And then our widened message, the ciphertext, was BCAA.
1049.69s - 1051.69s |  So then we take, we XOR the two,
1051.69s - 1055.69s |  and we get that the key at that offset is 6078.
1055.69s - 1056.69s |  Okay, pretty great.
1056.69s - 1058.69s |  So then the last eight bytes
1058.69s - 1061.69s |  are a result of Reed-Solomon error-correcting scheme.
1061.69s - 1064.69s |  So Gotenna is using both CRC and Reed-Solomon
1064.69s - 1066.69s |  for error detection and correction.
1066.69s - 1069.69s |  So a very powerful part about Reed-Solomon
1069.69s - 1072.69s |  is that it can not only detect the errors,
1072.69s - 1074.69s |  it can also correct them.
1074.69s - 1076.69s |  So they are using eight error-correction symbols
1076.69s - 1078.69s |  and first consecutive root set to one.
1078.69s - 1080.69s |  Using Reed-Solomon library and these four lines
1080.69s - 1082.69s |  to essentially compute the Reed-Solomon
1082.69s - 1084.69s |  against the packet we found earlier.
1084.69s - 1089.69s |  Once we do that, we get the line in the first bullet.
1089.69s - 1091.69s |  So those are those eight bytes.
1091.69s - 1093.69s |  We get the widened message, the ciphertext.
1093.69s - 1095.69s |  We XOR the two, and we have the entire key.
1095.69s - 1099.69s |  We have now the entire sequence from zero to the end.
1099.69s - 1101.69s |  So that's pretty awesome, right?
1101.69s - 1109.74s |  So now a big part here that we want to note
1109.74s - 1111.74s |  is that this entire sequence has been generated
1111.74s - 1113.74s |  by something called linear feedback shift register
1113.74s - 1115.74s |  or LFSR polynomial.
1115.74s - 1117.74s |  A very powerful thing about this algorithm
1117.74s - 1118.74s |  called Berlikamp-Massey.
1118.74s - 1121.74s |  So we can use this sequence within Berlikamp-Massey
1121.74s - 1122.74s |  to retrieve this polynomial.
1122.74s - 1125.74s |  The polynomial is shown at the bottom.
1125.74s - 1127.74s |  But there is more to here.
1127.74s - 1129.74s |  So in case that we could not determine something,
1129.74s - 1131.74s |  like byte one or any other part,
1131.74s - 1133.74s |  like we could have a very partial sequence,
1133.74s - 1136.74s |  we could use Berlikamp-Massey and mathematical techniques
1136.74s - 1140.74s |  to determine this polynomial and the associated sequence
1140.74s - 1141.74s |  even if we don't know things.
1141.74s - 1143.74s |  So we could technically, with enough time
1143.74s - 1145.74s |  and enough brute force, using Berlikamp-Massey,
1145.74s - 1148.74s |  only knowing the payload, figure out the header,
1148.74s - 1150.74s |  even if they were not being split.
1150.74s - 1152.74s |  So math is a pretty awesome thing.
1152.74s - 1155.74s |  So we can do that.
1155.74s - 1157.74s |  So, yeah, so this is the polynomial.
1157.74s - 1158.74s |  So they're using X to the 23.
1158.74s - 1161.74s |  So, you know, and this is not,
1161.74s - 1164.74s |  this is just meant to ensure that the receiver
1164.74s - 1166.74s |  and the transmitter do not lose connection.
1166.74s - 1168.74s |  So this is not meant as encryption.
1168.74s - 1171.74s |  Yeah, this is really acting almost like a form
1171.74s - 1173.74s |  of two-party authentication to make sure,
1173.74s - 1174.74s |  yes, they received the message,
1174.74s - 1176.74s |  yes, I've received the message,
1176.74s - 1180.74s |  and using that as a way to almost have a packet count.
1180.74s - 1184.79s |  So in our current decoding process,
1184.79s - 1185.79s |  so this is done in Green Radio,
1185.79s - 1187.79s |  and we're doing this essentially live,
1187.79s - 1190.79s |  and this is just a screen capture of my console.
1190.79s - 1192.79s |  So we get the raw bytes,
1192.79s - 1193.79s |  and we automatically extract the GID.
1193.79s - 1194.79s |  We apply the function.
1194.79s - 1196.79s |  We can translate that to ASCII.
1196.79s - 1198.79s |  We get the call sign, the payload,
1198.79s - 1200.79s |  including multi-fragmented messages.
1200.79s - 1201.79s |  So even in multi-fragmented,
1201.79s - 1204.79s |  we can still extract the payload.
1204.79s - 1205.79s |  So what GoTenor chose to encrypt.
1205.79s - 1208.79s |  So we played a bit with encryption,
1208.79s - 1209.79s |  and we see that it's only the payload.
1209.79s - 1211.79s |  So what does it mean, essentially,
1211.79s - 1213.79s |  once we can read all of the other signs?
1213.79s - 1215.79s |  Because in encrypted, unencrypted mode,
1215.79s - 1217.79s |  all of these are visible.
1217.79s - 1218.79s |  So everything you see in red here
1218.79s - 1222.79s |  means that at this point, where we currently are,
1222.79s - 1225.79s |  we are able to see the message length.
1225.79s - 1226.79s |  That can be pretty valuable.
1226.79s - 1228.79s |  That can definitely add up to things in the future,
1228.79s - 1232.79s |  especially with long-term collection techniques.
1232.79s - 1233.79s |  The GID.
1233.79s - 1235.79s |  The GID is gonna be your unique identifier,
1235.79s - 1237.79s |  which used to be your cell phone number,
1237.79s - 1239.79s |  and you had to pick for it to be a randomized one,
1239.79s - 1242.79s |  which we found out was just actually epoch.
1242.79s - 1245.79s |  But you now can still, with this,
1245.79s - 1246.79s |  they don't do the phone number.
1246.79s - 1248.79s |  So that's a much better improvement there.
1248.79s - 1251.79s |  But that GID tells me that is that exact same device.
1251.79s - 1253.79s |  And you can change it,
1253.79s - 1256.79s |  but understand that that GID is a unique identifier
1256.79s - 1258.79s |  like a MAC address that follows you.
1258.79s - 1260.79s |  Now, the call sign's a little bit different.
1260.79s - 1263.79s |  This goes back to my former community.
1263.79s - 1264.79s |  When you have call signs involved
1264.79s - 1266.79s |  that can be read in the clear,
1266.79s - 1270.79s |  now I possibly know how many people are in an organization
1270.79s - 1273.79s |  because typically they have a numerical sequence after it,
1273.79s - 1274.79s |  and I can start telling more
1274.79s - 1276.79s |  about that individual organization.
1276.79s - 1280.79s |  So by having the equipment and the call sign,
1280.79s - 1282.79s |  I can now start linking equipment
1282.79s - 1284.79s |  to not only organizations but individuals
1284.79s - 1287.79s |  to who was using the equipment at what time.
1287.79s - 1290.79s |  Payload length, again, much like message length,
1290.79s - 1292.79s |  that gives us really valuable things
1292.79s - 1295.79s |  to know what is it that we need to focus on
1295.79s - 1296.79s |  and what are they saying.
1296.79s - 1297.79s |  Is it short messages, long messages?
1297.79s - 1300.79s |  Are they using brevity?
1300.79s - 1302.79s |  And the CRC and the Reed-Solomon,
1302.79s - 1303.79s |  we're going to look and see
1303.79s - 1306.79s |  that those become fairly valuable in the end.
1306.79s - 1308.79s |  But these are the reasons this really concerned me.
1308.79s - 1310.79s |  100%.
1310.79s - 1311.79s |  So now, in this case,
1311.79s - 1313.79s |  we've shown what we've discovered so far,
1313.79s - 1315.79s |  so we go more in our analysis, right?
1315.79s - 1316.79s |  So that's what happens, right?
1316.79s - 1318.79s |  So we analyze the remaining fields.
1318.79s - 1319.79s |  We see the highlighted in blue.
1319.79s - 1321.79s |  We decode that and figure out that's the timestamp.
1321.79s - 1322.79s |  So you see here January 12th,
1322.79s - 1325.79s |  that's when we did the very initial capture,
1325.79s - 1326.79s |  so that's pretty awesome.
1326.79s - 1332.79s |  So we also discovered these tags.
1332.79s - 1339.54s |  So...
1339.54s - 1340.54s |  There we go.
1340.54s - 1341.54s |  And we knew we were on our way
1341.54s - 1344.54s |  to something great at this point.
1344.54s - 1346.54s |  So an additional thing with this presentation
1346.54s - 1348.54s |  that we want to do is we want to teach you
1348.54s - 1349.54s |  how we do reverse engineering.
1349.54s - 1352.54s |  So we discovered that this protocol is using tags.
1352.54s - 1355.54s |  So they're using tag 57, tag 24, and others.
1355.54s - 1357.54s |  So this is important to note.
1357.54s - 1359.54s |  So we'll use this in the rest of the presentation,
1359.54s - 1361.54s |  but it's important to note how we discovered that,
1361.54s - 1364.54s |  okay, so 57 or 39 hex,
1364.54s - 1369.54s |  after that, there is the UTC timestamp.
1369.54s - 1371.54s |  So then we use this in tag-based identification
1371.54s - 1372.54s |  in our script.
1372.54s - 1376.54s |  So we take the tag is equal to 57,
1376.54s - 1378.54s |  and then we appropriately apply the Python code
1378.54s - 1380.54s |  to decode that.
1380.54s - 1381.54s |  So that's what we're doing.
1381.54s - 1383.54s |  So at this point, we're a bit stuck, right?
1383.54s - 1385.54s |  So we could keep going the same things
1385.54s - 1386.54s |  over and over again,
1386.54s - 1388.54s |  and, like, eventually we'll get everything.
1388.54s - 1389.54s |  Maybe we won't.
1389.54s - 1391.54s |  But, you know, what happened in the V1 here?
1391.54s - 1394.54s |  So this is where I kind of fell back to the version 1
1394.54s - 1398.54s |  when I worked with Tim Kerster on that.
1398.54s - 1400.54s |  And he and I had kind of a light bulb moment.
1400.54s - 1401.54s |  He's an engineer.
1401.54s - 1402.54s |  I'm a knuckle dragger.
1402.54s - 1404.54s |  So we looked at it two totally different ways.
1404.54s - 1407.54s |  So he went home that night to start working on
1407.54s - 1411.54s |  an automatic demodulator for the FSK,
1411.54s - 1413.54s |  and I started seeing what I could find
1413.54s - 1415.54s |  so we could try to compare knowledge,
1415.54s - 1416.54s |  and he comes back the next day and goes,
1416.54s - 1419.54s |  Woody, I really hope that, you know,
1419.54s - 1421.54s |  this demodulator that I made is working.
1421.54s - 1422.54s |  I wish there was some way that I could check
1422.54s - 1425.54s |  against what the actual code that's coming out is
1425.54s - 1427.54s |  to make sure that everything's correct.
1427.54s - 1429.54s |  And I said, well, hey, we can just compare it
1429.54s - 1430.54s |  to the stuff that I've been looking at
1430.54s - 1433.54s |  through the UART, and then we'll just know, right?
1433.54s - 1434.54s |  At which point he said,
1434.54s - 1436.54s |  what do you mean you have UART?
1436.54s - 1439.54s |  I just assumed he'd check.
1439.54s - 1441.54s |  Yeah, so we don't have UART in this case
1441.54s - 1443.54s |  with Gotenna Pro, but we have something better.
1443.54s - 1445.54s |  So Clayton just casually mentions,
1445.54s - 1446.54s |  why don't you read from the app?
1446.54s - 1448.54s |  It was useful when I did Mesh.
1448.54s - 1449.54s |  Wait, what?
1449.54s - 1450.54s |  We had code the entire time?
1450.54s - 1451.54s |  Like, what?
1451.54s - 1452.54s |  I go online, and, like, I'm supposedly
1452.54s - 1454.54s |  this, like, reverse engineer, right?
1454.54s - 1455.54s |  And, like, I didn't look at the app.
1455.54s - 1456.54s |  What?
1456.54s - 1460.54s |  So everything in the app is plain text.
1460.54s - 1461.54s |  Yeah.
1461.54s - 1462.54s |  Look at this.
1462.54s - 1463.54s |  So we go in, decompile it.
1463.54s - 1464.54s |  Boom.
1464.54s - 1465.54s |  We can see the firmware in there.
1465.54s - 1466.54s |  We can see the source code.
1466.54s - 1467.54s |  Like, I was looking for this,
1467.54s - 1470.54s |  but, like, it's right there.
1470.54s - 1471.54s |  Wow.
1471.54s - 1473.54s |  Yeah, so companies really don't think like hackers.
1473.54s - 1475.54s |  So, like, hackers, like the guys in these pictures,
1475.54s - 1477.54s |  they can find full source code and firmware available
1477.54s - 1479.54s |  completely unencrypted and obfuscated.
1479.54s - 1481.54s |  It exists.
1481.54s - 1482.54s |  Yeah.
1482.54s - 1483.54s |  And this is where we said,
1483.54s - 1486.54s |  oh, I think things are going to be a little bit better now.
1486.54s - 1488.54s |  Because in version 1,
1488.54s - 1490.54s |  we just had to kind of bare knuckle through it
1490.54s - 1491.54s |  and hope we were close.
1491.54s - 1493.54s |  We just knew that our demodulation was working.
1493.54s - 1494.54s |  We didn't have tags yet,
1494.54s - 1496.54s |  which I think we're going to get to.
1496.54s - 1498.54s |  Yeah, so we go back, and we look through the source code.
1498.54s - 1499.54s |  We find these tags.
1499.54s - 1501.54s |  Remember that we were talking about reverse engineering tags?
1501.54s - 1502.54s |  We see 57 right here.
1502.54s - 1503.54s |  So we were spot on.
1503.54s - 1506.54s |  Our reverse engineering, like, methodology was very spot on.
1506.54s - 1508.54s |  So that's what we wanted to show you.
1508.54s - 1509.54s |  We find more tags, right?
1509.54s - 1510.54s |  PB broadcast.
1510.54s - 1512.54s |  We see key data coordinates.
1512.54s - 1514.54s |  So, you know, we have a bunch of tags, right?
1514.54s - 1517.54s |  So you're assuming that we use this Java source code
1517.54s - 1519.54s |  and essentially slowly update our script.
1519.54s - 1521.54s |  This may take, like, a couple months,
1521.54s - 1523.54s |  and eventually we'll have a better product.
1523.54s - 1524.54s |  Well, not quite.
1524.54s - 1527.54s |  Ain't nobody got time for that.
1527.54s - 1529.54s |  So we find an interesting observation.
1529.54s - 1531.54s |  There's a file descriptor,
1531.54s - 1533.54s |  and we find something called Proto 3.
1533.54s - 1535.54s |  Some of you are familiar with that already,
1535.54s - 1537.54s |  but we weren't, right?
1537.54s - 1539.54s |  So we looked this up, and it's a protocol buffers.
1539.54s - 1541.54s |  It's used as an open source library
1541.54s - 1544.54s |  developed by Google to help companies and other people
1544.54s - 1546.54s |  to develop custom protocols,
1546.54s - 1548.54s |  and they're supported by all kinds of languages,
1548.54s - 1552.54s |  Python, Java, C, like, all kinds of things, right?
1552.54s - 1556.54s |  So we go online, and we kind of take the string,
1556.54s - 1559.54s |  the binary string, and we kind of figure out,
1559.54s - 1561.54s |  okay, these may be the fields, right,
1561.54s - 1563.54s |  the sender, the call sign, and then let's try it, right?
1563.54s - 1565.54s |  So we put in the hex at the bottom,
1565.54s - 1568.54s |  and then, wow, the whole thing is there.
1568.54s - 1571.54s |  But literally, you just put it in the program on one side,
1571.54s - 1573.54s |  push a button, and it gives you everything on the other.
1573.54s - 1575.54s |  Like, it's automatic.
1575.54s - 1577.54s |  Like, this did not happen in V1 or Mesh.
1577.54s - 1580.54s |  Like, this is, like, way easier.
1580.54s - 1582.54s |  So, yeah, so we then go in,
1582.54s - 1584.54s |  and then let's do this for real.
1584.54s - 1587.54s |  So we go to all of the decompiled stuff.
1587.54s - 1589.54s |  We take the file extractors.
1589.54s - 1592.54s |  We put in our own custom file called Proto extraction,
1592.54s - 1594.54s |  and then we run, that will generate a binary file,
1594.54s - 1596.54s |  and then we use PBTK.
1596.54s - 1598.54s |  This is an open-source tool.
1598.54s - 1600.54s |  We use this against this binary file,
1600.54s - 1603.54s |  and that gives us all of these things at the bottom,
1603.54s - 1604.54s |  like all the proto files.
1604.54s - 1607.54s |  So the base header essentially sets up the message.
1607.54s - 1609.54s |  This imports the header protobuf.
1609.54s - 1611.54s |  The header protobuf was what we were doing
1611.54s - 1612.54s |  in reverse engineering in BlackboxRF, right?
1612.54s - 1614.54s |  So, like, it shows us all the things.
1614.54s - 1617.54s |  What's important here is this data type, right?
1617.54s - 1620.54s |  This enum would be very difficult to reverse engineer.
1620.54s - 1622.54s |  Like, we would have to take so many samples
1622.54s - 1624.54s |  and then hope that we can maybe figure out
1624.54s - 1626.54s |  the text is 3 and then ping is 5.
1626.54s - 1628.54s |  That would be very difficult.
1628.54s - 1630.54s |  So let's go back full circle.
1630.54s - 1631.54s |  What were those tags, right?
1631.54s - 1633.54s |  So if we compile this protobuf in Java,
1633.54s - 1635.54s |  because that's what Gotenna is using,
1635.54s - 1636.54s |  we can see these cases.
1636.54s - 1638.54s |  So these cases are used as different parts
1638.54s - 1641.54s |  of the protocol to essentially define different things.
1641.54s - 1643.54s |  So we were spot-on, right?
1643.54s - 1644.54s |  These tags were cases.
1644.54s - 1645.54s |  That's pretty awesome.
1645.54s - 1647.54s |  And we got 57 and the rest of them.
1647.54s - 1650.54s |  And you also noticed that you could see things
1650.54s - 1652.54s |  like when they requested, I don't know, keys.
1653.54s - 1655.54s |  You could see the code of how to request a key.
1655.54s - 1656.54s |  100%.
1656.54s - 1657.54s |  So, yeah.
1657.54s - 1659.54s |  So a cool part about protobuf
1659.54s - 1661.54s |  is they can be compiled for Python.
1661.54s - 1663.54s |  What else is using Python?
1663.54s - 1666.54s |  I believe there's a little thing called GNU radio.
1666.54s - 1667.54s |  Yeah, that might be cool.
1667.54s - 1669.54s |  It's so easy, even I can do it.
1669.54s - 1670.54s |  Yeah.
1670.54s - 1672.54s |  So we go in and we import a base message data type
1672.54s - 1674.54s |  and we make a blueprint statements
1674.54s - 1675.54s |  to associate everything.
1675.54s - 1678.54s |  And perfect decode.
1678.54s - 1683.07s |  Victory.
1683.07s - 1685.07s |  But wait, we haven't found a single vulnerability yet.
1685.07s - 1686.07s |  We just decoded the thing.
1686.07s - 1688.07s |  Like, there's 30 more slides of actual vulnerabilities.
1688.07s - 1691.07s |  So, you know, stay seated.
1691.07s - 1694.07s |  So with this decode, now that we can read things,
1694.07s - 1699.07s |  we can do frequency decoding, shared location.
1699.07s - 1702.07s |  We can do emergency messages, all kinds of things.
1702.07s - 1704.07s |  The only thing where we received the challenge
1704.07s - 1706.07s |  was in coordinate decoding.
1706.07s - 1709.07s |  So in the app, we can make, for example,
1709.07s - 1711.07s |  like around this island, we can make coordinates.
1711.07s - 1713.07s |  And then when we're capturing it,
1713.07s - 1716.07s |  we see binary data represented as Base64 and JSON.
1716.07s - 1719.07s |  And in this case, there isn't much, right?
1719.07s - 1721.07s |  So, like, we can't see here.
1721.07s - 1722.07s |  So we go back to proto.
1722.07s - 1723.07s |  They're defined as bytes.
1723.07s - 1726.07s |  So that means that decoding on our side has not been added.
1726.07s - 1727.07s |  So that's very simple.
1727.07s - 1730.07s |  We just use decode as little n, the n double double,
1730.07s - 1732.07s |  and then boom, we get the coordinates.
1732.07s - 1733.07s |  So that's fixed.
1733.07s - 1736.07s |  So now we found our true first vulnerability, right?
1736.07s - 1737.07s |  So, like, we encrypt the message
1737.07s - 1739.07s |  and we're just kind of looking at things.
1739.07s - 1742.07s |  So what can you do when somebody can capture yes or no
1742.07s - 1743.07s |  and tell the differences?
1743.07s - 1745.07s |  When you start dealing with organizations
1745.07s - 1747.07s |  that are using brevity for communication,
1747.07s - 1749.07s |  simple things like the length of a message
1749.07s - 1752.07s |  become very easy even without going into advanced steps
1752.07s - 1754.07s |  to be able to tell what kind of communication may be happening.
1754.07s - 1756.07s |  Are they only sending coordinates?
1756.07s - 1757.07s |  Are they sending commands?
1757.07s - 1759.07s |  Are they just sending comms checks?
1759.07s - 1761.07s |  So this starts becoming really important,
1761.07s - 1764.07s |  being able to understand these message lengths.
1764.07s - 1765.07s |  Yeah, so it's crucial.
1765.07s - 1768.07s |  So then let's go look at how they're doing encryption.
1768.07s - 1771.07s |  So one form of encryption is encrypting the broadcast.
1771.07s - 1773.07s |  So this is the process how it works in the app.
1773.07s - 1774.07s |  So we generate the new key.
1774.07s - 1775.07s |  We put in the name.
1775.07s - 1777.07s |  It can be either broadcast or QR code,
1777.07s - 1778.07s |  and we're going to get to that, right?
1778.07s - 1779.07s |  That's not important.
1779.07s - 1782.07s |  But what we go in is the validation thing.
1782.07s - 1783.07s |  It's kind of interesting, right?
1783.07s - 1784.07s |  We do this a bunch of times.
1784.07s - 1787.07s |  Like, they're kind of short.
1787.07s - 1792.07s |  So, and it's all lowercase or numbers, and that's it.
1792.07s - 1793.07s |  But there is a space.
1793.07s - 1796.07s |  So I guess we have nine, but the space is consistent.
1796.07s - 1798.07s |  So, nope, really just eight.
1798.07s - 1801.07s |  So you have lowercase numbers, or I'm sorry,
1801.07s - 1802.07s |  lowercase letters and numbers,
1802.07s - 1804.07s |  and that's all you have to figure out,
1804.07s - 1805.07s |  and you only have to figure out eight of them
1805.07s - 1808.07s |  and put a space in the middle for your dictionary.
1808.07s - 1809.07s |  Yeah, so very interesting.
1809.07s - 1810.07s |  So then we go in.
1810.07s - 1812.07s |  Okay, we capture this QR broadcast, right?
1812.07s - 1815.07s |  QR broadcast gets sent unencrypted over the air.
1815.07s - 1817.07s |  So this key data is actually encrypted, right?
1817.07s - 1819.07s |  So what we have here is encrypted.
1819.07s - 1821.07s |  But, you know, we do some of our analysis,
1821.07s - 1822.07s |  and then long story short,
1822.07s - 1824.07s |  to make the fit in the presentation,
1824.07s - 1826.07s |  we were able to decrypt it.
1826.07s - 1827.07s |  And the nice thing, too,
1827.07s - 1829.07s |  is it told us where the IV and the salt was
1829.07s - 1831.07s |  because we were able to find where they were.
1831.07s - 1835.07s |  So it made it much easier because we knew which was which.
1835.07s - 1839.07s |  So then, essentially, the key data is fed into the PBKDFHMAC
1839.07s - 1840.07s |  with 10,000 iterations.
1840.07s - 1841.07s |  This is a very good hashing,
1841.07s - 1844.07s |  but it's protected by a state character password.
1844.07s - 1846.07s |  So let's say password is known.
1846.07s - 1848.07s |  It's going to give us the encryption key.
1848.07s - 1851.07s |  And encryption key, along with the IV and the GID,
1851.07s - 1853.07s |  can decrypt the ciphertext.
1853.07s - 1856.07s |  GID as GCM will give us the plain text and HMAC.
1856.07s - 1859.07s |  We also, you know, to be good communications people,
1859.07s - 1860.07s |  we can compute our own HMAC
1860.07s - 1862.07s |  and verify that message was correct, right?
1862.07s - 1864.07s |  So now one may ask, like,
1864.07s - 1867.07s |  how complicated is it to get this password?
1867.07s - 1870.07s |  So in MD5, this will be very quick.
1870.07s - 1872.07s |  PBKDF2 is pretty strong.
1872.07s - 1876.07s |  So we do hashcat, and we essentially analyze.
1876.07s - 1878.07s |  This is an actual engineering analysis.
1878.07s - 1881.07s |  So with RTX4090, one card,
1881.07s - 1883.07s |  one can figure this out in 15.33 days.
1883.07s - 1886.07s |  A very common commercial cracking rig can have 12 of these.
1886.07s - 1889.07s |  So in 1.27 days, one can determine this password.
1889.07s - 1892.07s |  Now we look at more well-funded adversaries.
1892.07s - 1895.07s |  A100 is used by chat GPT, neural nets, AI.
1895.07s - 1897.07s |  That's the whole thing now, right?
1897.07s - 1899.07s |  This one card is actually worse, right?
1899.07s - 1901.07s |  But if you have 10,000 of them,
1901.07s - 1903.07s |  you can figure it out in 5.31 seconds.
1903.07s - 1905.07s |  It's important to know that all of these times here...
1905.07s - 1907.07s |  Minutes. 5.31 minutes.
1907.07s - 1908.07s |  It's important to know that all of these
1908.07s - 1910.07s |  are kind of worst-case scenarios.
1910.07s - 1912.07s |  That means that your script found the password
1912.07s - 1913.07s |  the very last time.
1913.07s - 1916.07s |  So it's likely it's going to be, like, about half the time.
1916.07s - 1919.07s |  So we go in, and we can essentially...
1919.07s - 1922.07s |  If we know the key, we wrote our little script,
1922.07s - 1923.07s |  and then we can decode it.
1923.07s - 1924.07s |  We can get the hex key,
1924.07s - 1927.07s |  and now we can add this to our automatic decoding script,
1927.07s - 1929.07s |  and now we can decrypt live.
1929.07s - 1930.07s |  Awesome.
1930.07s - 1931.07s |  And we can also decrypt everything
1931.07s - 1932.07s |  that happened in the past, so...
1932.07s - 1934.07s |  So now we have it all.
1934.07s - 1936.07s |  Yeah, but there's more.
1936.07s - 1939.07s |  So another form of communication
1939.07s - 1940.07s |  is point-to-point,
1940.07s - 1941.07s |  and that uses public-key encryption.
1941.07s - 1943.07s |  So public-key encryption on its own
1943.07s - 1944.07s |  is a lot more secure.
1944.07s - 1947.07s |  It uses PKI, or public-key encryption,
1947.07s - 1948.07s |  to share the symmetric key.
1948.07s - 1951.07s |  It doesn't require any of this manual key sharing.
1951.07s - 1953.07s |  However, in our code,
1953.07s - 1956.07s |  the message receiver class did not cleanly decompile,
1956.07s - 1958.07s |  so we could spend some time, do that,
1958.07s - 1961.07s |  but in help with some Craigslist, eBay, and Freedom,
1961.07s - 1963.07s |  maybe we can figure it out without it.
1963.07s - 1966.07s |  So initial conversation starts with public-key sharing.
1966.07s - 1968.07s |  So here we get the GIDs and the public keys.
1968.07s - 1970.07s |  Pretty cool.
1970.07s - 1972.07s |  So then we get to the source code.
1972.07s - 1976.07s |  We figure out that the public key and the private key
1976.07s - 1979.07s |  are generated using ECDH384R1 curve
1979.07s - 1981.07s |  to generate the shared key.
1981.07s - 1983.07s |  The shared key is used as first input
1983.07s - 1985.07s |  to HMAC SHA-256.
1985.07s - 1987.07s |  The second input is not known here,
1987.07s - 1989.07s |  so we could not figure out what are the parameters here.
1989.07s - 1991.07s |  So using Freedom,
1991.07s - 1994.07s |  we can essentially intercept this crypto-MACDU final.
1995.07s - 1999.07s |  So we essentially instrument this phone right here,
1999.07s - 2001.07s |  which is an Android phone.
2001.07s - 2003.07s |  This is connected with Gotenna,
2003.07s - 2005.07s |  and then we send a P2P,
2005.07s - 2007.07s |  and then we capture this.
2007.07s - 2009.07s |  And then from this kind of hex string,
2009.07s - 2011.07s |  we can figure out, okay, the second parameter
2011.07s - 2013.07s |  is actually concatenated GID, public key,
2013.07s - 2015.07s |  and the shared key.
2015.07s - 2017.07s |  We do know the public key and the GID.
2017.07s - 2019.07s |  We just found that in the slide earlier.
2019.07s - 2021.07s |  We don't know the shared key, so let's look for that.
2021.07s - 2023.07s |  So we go in the device, and we find the Gotenna folder
2023.07s - 2025.07s |  in that same phone,
2025.07s - 2028.07s |  and we find something called Gotenna Key Encryption.
2028.07s - 2031.07s |  I wonder if that's used for encryption.
2031.07s - 2033.07s |  So we go in, and, okay,
2033.07s - 2035.07s |  it's using private keys, shared keys,
2035.07s - 2037.07s |  but now, to, you know, the best of luck,
2037.07s - 2039.07s |  all of this is encrypted, right?
2039.07s - 2041.07s |  Fully encrypted. We can't read it.
2041.07s - 2043.07s |  But let's verify.
2043.07s - 2045.07s |  Okay.
2045.07s - 2047.07s |  So we go in, and we find the file that's using
2047.07s - 2049.07s |  Gotenna Key Encryption.
2049.07s - 2051.07s |  It's encrypted as an IV.
2051.07s - 2053.07s |  But we can't tell from that function,
2053.07s - 2055.07s |  so we track this over two different functions
2055.07s - 2057.07s |  and figure out it's not only used as a static,
2057.07s - 2060.07s |  as an IV, it's used as a static IV to AES-GCM.
2060.07s - 2063.07s |  So keys are AES-GCM encrypted,
2063.07s - 2066.07s |  but static IV allows complete encryption bypass.
2066.07s - 2068.07s |  This is when AES is doing what not,
2068.07s - 2070.07s |  what AES is not meant to do, right?
2070.07s - 2073.07s |  And then using the public key as a known plain text
2073.07s - 2075.07s |  and the encrypted public key,
2075.07s - 2077.07s |  we can XOR them to get the key stream,
2077.07s - 2079.07s |  and we can decrypt essentially everything else.
2079.07s - 2081.07s |  And what's stored in a database are public keys,
2081.07s - 2083.07s |  shared keys, broadcast keys,
2083.07s - 2086.07s |  the top two, the pin, pretty much everything.
2086.07s - 2088.07s |  So we have a lot of stuff here.
2088.07s - 2091.07s |  So then, yeah, there is AES.
2091.07s - 2095.07s |  There is. However, there's also
2095.07s - 2098.07s |  AES sitting here, and then implementation
2098.07s - 2100.07s |  or configuration sitting here.
2100.07s - 2102.07s |  This is kind of like having a really nice
2102.07s - 2105.07s |  blast-proof, bulletproof door at your house,
2105.07s - 2107.07s |  and then realizing that when the bad guys come,
2107.07s - 2109.07s |  they just cut a hole through the siding
2109.07s - 2111.07s |  and the drywall right next to it.
2111.07s - 2114.07s |  Yeah. So let's now summarize this
2114.07s - 2116.07s |  just so kind of everybody can be on the same page.
2116.07s - 2118.07s |  We get the public key and the public key ciphertext
2118.07s - 2121.07s |  in the XML. We XOR them to get the key stream,
2121.07s - 2123.07s |  and then we take the key stream and XOR that
2123.07s - 2125.07s |  with the private key ciphertext to get the private key.
2125.07s - 2128.07s |  Then when we have the public key and the private key,
2128.07s - 2130.07s |  we use ECDH to get the shared key.
2130.07s - 2133.07s |  Shared key is used within HMAC SHA-256
2133.07s - 2135.07s |  along with GID public key and the shared key
2135.07s - 2136.07s |  to get the encryption key.
2136.07s - 2138.07s |  That, along with the IV and the GID,
2138.07s - 2141.07s |  can decrypt the ciphertext of P2P encryption.
2141.07s - 2143.07s |  Group encryption is another form of encryption.
2143.07s - 2146.07s |  It's the last one that we'll talk about,
2146.07s - 2148.07s |  or the last one supported, really.
2148.07s - 2149.07s |  So it's using the very same method,
2149.07s - 2152.07s |  so same exact attack against P2P works against this,
2152.07s - 2154.07s |  and we can show here that we have done it.
2154.07s - 2157.07s |  So this is our true vulnerability summary, right,
2157.07s - 2158.07s |  of encryption summary finding.
2158.07s - 2160.07s |  So broadcast is vulnerable and allows unauthorized decryption.
2160.07s - 2163.07s |  Using setup QR message, which is captured over the air,
2163.07s - 2165.07s |  and brute force password, we can decrypt it.
2165.07s - 2167.07s |  We can also get it if the phone is compromised
2167.07s - 2169.07s |  and we get the key from there.
2169.07s - 2172.07s |  P2P and group are both vulnerable to unauthorized decryption
2172.07s - 2174.07s |  if, again, the phone is compromised
2174.07s - 2175.07s |  and we get some of these.
2175.07s - 2177.07s |  So if you want to know the feasibility,
2177.07s - 2179.07s |  you can check out our DEF CON talks and things like that
2179.07s - 2181.07s |  to sort of really know that.
2181.07s - 2182.07s |  There's no authentication public key,
2182.07s - 2184.07s |  so man-in-the-middling is possible.
2184.07s - 2185.07s |  Short messages, less than one fragment,
2185.07s - 2187.07s |  use less secure AES CTR,
2187.07s - 2189.07s |  so less than 35, 45 characters
2189.07s - 2191.07s |  depending on the message,
2191.07s - 2193.07s |  are using CTR, so that has integrity concerns
2193.07s - 2195.07s |  even though it is encrypted.
2195.07s - 2198.07s |  And then longer messages use more secure GCM,
2198.07s - 2201.07s |  but you need to be sending, like, 50 characters to get to that.
2201.07s - 2203.07s |  So we also, you know,
2203.07s - 2207.07s |  we could also transmit directly from our GNU radio.
2207.07s - 2209.07s |  We can spoof GID call sign, the message.
2209.07s - 2211.07s |  We can get into the existing...
2211.07s - 2216.07s |  So I could take a HackRF or an NS or a Blade
2216.07s - 2220.07s |  and I can actually make my own Gotenna out of it.
2220.07s - 2221.07s |  Yeah.
2221.07s - 2222.07s |  And just start using my computer.
2222.07s - 2225.07s |  We also added support for Wireshark,
2225.07s - 2228.07s |  so we have essentially that,
2228.07s - 2230.07s |  so all the messages are fed into Wireshark.
2230.07s - 2231.07s |  We don't have the decode there currently,
2231.07s - 2234.07s |  but we'll add it eventually.
2234.07s - 2236.07s |  So now let's get to live demos.
2236.07s - 2238.07s |  So if you have a Gotenna Pro,
2238.07s - 2240.07s |  then you can get the frequency on the left
2240.07s - 2242.07s |  and the encryption in the middle
2242.07s - 2243.07s |  and validation on the right.
2243.07s - 2246.07s |  So we have six minutes, so let's be quick.
2248.07s - 2249.07s |  I wouldn't scan it,
2249.07s - 2257.86s |  because we're both sketchy guys, but still.
2257.86s - 2258.86s |  So it's firing up live right now.
2258.86s - 2260.86s |  He's just turning the program on.
2260.86s - 2263.86s |  You can see it's already starting to sniff and listen.
2263.86s - 2265.86s |  We like to have a little waterfall
2265.86s - 2267.86s |  so we can see when we are or are not capturing.
2267.86s - 2269.86s |  Now he's going to send a message,
2269.86s - 2271.86s |  and there you go.
2271.86s - 2281.09s |  There we go.
2283.09s - 2284.09s |  We have enough time,
2284.09s - 2286.09s |  so let's see if we can decrypt something.
2287.09s - 2290.09s |  So now being able to do the same type of process
2290.09s - 2292.09s |  for an encrypted message.
2292.09s - 2293.09s |  So that was a broadcast.
2293.09s - 2294.09s |  Now broadcast means it's sent out
2294.09s - 2296.09s |  so that anyone that has one of these devices
2296.09s - 2298.09s |  is able to catch it.
2298.09s - 2300.09s |  It's meant for an emergency situation
2300.09s - 2302.09s |  or you're just looking for other people around you,
2302.09s - 2305.09s |  but the next step is
2305.09s - 2307.09s |  all those things we talked about
2307.09s - 2308.09s |  by combining that information,
2308.09s - 2311.09s |  can you take an encrypted message
2311.09s - 2313.09s |  for a group or a person-to-person
2313.09s - 2316.09s |  and actually decrypt and see it?
2316.09s - 2318.09s |  So when you think about this,
2318.09s - 2320.09s |  this is where everyone feels safe.
2320.09s - 2321.09s |  Oh, yeah.
2321.09s - 2324.14s |  One second here.
2324.14s - 2344.22s |  So while we're going through this,
2344.22s - 2345.22s |  he's going to set the demo up.
2345.22s - 2348.22s |  You're going to be able to see it.
2348.22s - 2353.84s |  And we'll go ahead.
2353.84s - 2355.84s |  Are there any questions right now
2355.84s - 2357.84s |  while he's setting this up?
2357.84s - 2358.84s |  We have a minute or so.
2358.84s - 2363.84s |  Any questions over anything that we've seen so far?
2363.84s - 2365.84s |  Okay.
2365.84s - 2369.22s |  Here we go.
2369.22s - 2371.22s |  Now one of the things that I want to make sure
2371.22s - 2372.22s |  that we cover in this is that
2372.22s - 2374.22s |  when we reached out to Gotenna
2374.22s - 2376.22s |  for the version 1 exploit,
2376.22s - 2379.22s |  they had zero response
2379.22s - 2380.22s |  other than the fact they said,
2380.22s - 2382.22s |  that's fine, we don't care.
2382.22s - 2383.22s |  Under the new management,
2383.22s - 2385.22s |  Gotenna was extremely receptive.
2385.22s - 2387.22s |  We got a call back within one day.
2387.22s - 2390.22s |  They were happy to take the advice
2390.22s - 2391.22s |  that we gave them
2391.22s - 2393.22s |  and they are actively working
2393.22s - 2395.22s |  to try to fix these issues.
2395.22s - 2397.22s |  That's why we are going to make sure
2397.22s - 2399.22s |  we wait at least two months from today
2399.22s - 2401.22s |  before we release the full code publicly,
2401.22s - 2403.22s |  but then we will.
2403.22s - 2404.22s |  Now for Gen 1 and 2,
2404.22s - 2407.22s |  the code's already out there.
2407.22s - 2408.22s |  Okay, so now we're ready.
2408.22s - 2410.22s |  So I'm going to send something encrypted
2410.22s - 2411.22s |  just so we can see that messages
2411.22s - 2412.22s |  are indeed encrypted.
2412.22s - 2415.22s |  So we can see they're encrypted now.
2415.22s - 2431.46s |  Now this part here decrypted.
2431.46s - 2434.46s |  So this was added to our local database.
2434.46s - 2436.46s |  So we're going to run our script again.
2436.46s - 2437.46s |  So this is going to now
2437.46s - 2440.46s |  pull the keys from there immediately.
2440.46s - 2442.46s |  And then we will transmit again.
2442.46s - 2449.74s |  Boom, this was encrypted.
2449.74s - 2453.05s |  So now it's full circle.
2453.05s - 2461.74s |  So, you know, live demos are something
2461.74s - 2463.74s |  that I'm a big fan of.
2463.74s - 2466.74s |  So Erwin did an amazing job
2466.74s - 2468.74s |  of writing all this crazy code.
2468.74s - 2471.74s |  I don't want anyone to misconstrue that.
2471.74s - 2473.74s |  The big thing that we want to make sure
2473.74s - 2475.74s |  that everyone takes away from this
2475.74s - 2479.74s |  is it is up to everyone in this community
2479.74s - 2481.74s |  to test equipment.
2481.74s - 2483.74s |  Just because something says it's secure,
2483.74s - 2484.74s |  don't believe it.
2484.74s - 2485.74s |  Challenge it.
2485.74s - 2486.74s |  And when you find it,
2486.74s - 2488.74s |  see if the manufacturer's willing to listen.
2488.74s - 2489.74s |  Occasionally they are.
2489.74s - 2490.74s |  Gotenna was.
2490.74s - 2492.74s |  Most of the ones I've dealt with aren't.
2492.74s - 2495.74s |  So if something's been done in the past,
2495.74s - 2497.74s |  don't be afraid to try to recreate it
2497.74s - 2498.74s |  when something new comes out.
2498.74s - 2500.74s |  You might find that they didn't change
2500.74s - 2501.74s |  a lot of the things
2501.74s - 2502.74s |  and then you can move forward
2502.74s - 2504.74s |  and do well with it.
2504.74s - 2507.74s |  Yep, so let's talk about join.
2507.74s - 2508.74s |  I mean, you already mentioned this,
2508.74s - 2510.74s |  so they were very receptive.
2510.74s - 2514.89s |  And yeah, the conclusion.
2514.89s - 2518.89s |  Yeah, so the big things we wanted to say about this is,
2518.89s - 2520.89s |  you know, we reached out to industry.
2520.89s - 2522.89s |  We were able to have a good relationship
2522.89s - 2523.89s |  with them doing this.
2523.89s - 2525.89s |  They took away key points,
2525.89s - 2527.89s |  acknowledgments of what we want to make sure
2527.89s - 2528.89s |  we talk about here.
2528.89s - 2530.89s |  So we want to reach out to White Shadow
2530.89s - 2531.89s |  who unfortunately couldn't be here
2531.89s - 2534.89s |  because he's actually doing some responsible things
2534.89s - 2535.89s |  for his family,
2535.89s - 2536.89s |  but he is going to be here later.
2536.89s - 2538.89s |  But don't tell him I said anything nice.
2538.89s - 2539.89s |  What the Freak,
2539.89s - 2541.89s |  which is the wireless CTF team
2541.89s - 2542.89s |  that-
2542.89s - 2543.89s |  Let's do a shout.
2543.89s - 2544.89s |  We got a win today.
2544.89s - 2546.89s |  Which I'm glad they're here
2546.89s - 2547.89s |  because now all the other teams
2547.89s - 2548.89s |  are jumping ahead of them.
2548.89s - 2549.89s |  Yep.
2549.89s - 2551.89s |  So we also want to thank EFF and CISA.
2551.89s - 2554.89s |  Both of them were amazing organizations
2554.89s - 2555.89s |  and very easy to work with.
2555.89s - 2557.89s |  The RF Hacker Sanctuary,
2557.89s - 2558.89s |  please go there.
2558.89s - 2559.89s |  Try some challenges.
2559.89s - 2561.89s |  It's everything from Wi-Fi,
2561.89s - 2562.89s |  Bluetooth,
2562.89s - 2563.89s |  tire pressure sensors,
2563.89s - 2564.89s |  Go Tennis.
2564.89s - 2566.89s |  All of these challenges will be there as well
2566.89s - 2567.89s |  for you to solve
2567.89s - 2568.89s |  for all the Go Tennis stuff.
2569.89s - 2570.89s |  We want to make sure that,
2570.89s - 2571.89s |  you know-
2571.89s - 2572.89s |  Yeah.
2572.89s - 2573.89s |  Jason Rojas and Cisco Systems.
2573.89s - 2574.89s |  I want to thank them
2574.89s - 2576.89s |  for making my trip here possible
2576.89s - 2577.89s |  and Potify Media
2577.89s - 2578.89s |  for making this team
2578.89s - 2579.89s |  for this presentation.
2579.89s - 2580.89s |  And Buffalo Trace
2580.89s - 2581.89s |  because without them
2581.89s - 2582.89s |  I probably wouldn't get done
2582.89s - 2583.89s |  as much work as I do.
2584.89s - 2588.10s |  Thank you for your time.
2588.10s - 2589.10s |  Are there any questions?
2590.10s - 2595.10s |  Well, thank you and enjoy the con.


url: https://www.youtube.com/watch?v=IUEjbuiAX18
title: DEF CON 32 - Fireside Chat - The Dark Tangent and National Cyber Director Harry Coker, Jr
type: video
author: DEFCONConference
ingestion_date: 2024-11-10
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=IUEjbuiAX18",
  "title": "DEF CON 32 - Fireside Chat - The Dark Tangent and National Cyber Director Harry Coker, Jr",
  "description": "The world increasingly appreciates how much we rely on space systems for our personal, economic, and national security needs. However, the nation-state cyber threat to government and commercial systems continues to grow at a time when the current landscape of cybersecurity policies and frameworks aren\u2019t readily applicable for space systems.\n\nIn this fireside chat, ONCD will have the opportunity to introduce our 2nd National Cyber Director to the research community and discuss some of his priorities, such as space cybersecurity. We will discuss how the White House has been working to tackle hard problems and challenges. In the instance of space cybersecurity, ONCD has been collaborating with federal space operators and the space industry to develop policy solutions, including by answering a tasking from the Vice President to develop minimum cybersecurity requirements for U.S. space systems.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2702,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.00s - 7.04s | This text was transcribed using whisper model: large-v2

 great to see everyone. Um, DEF CON noobs, keep drinking water, take care of yourself. Um, I'm
7.04s - 13.42s |  Jason Healy. I was asked to moderate this far side chat with the director of your United
13.42s - 18.32s |  States, um, Office of the National Cyber Director. So today we have, um, Director Harry
18.32s - 22.52s |  Coker, who we're going to be having a far side chat with. My name is Jason Healy. I get
22.52s - 27.96s |  asked to do this. Um, I've been on the DEF CON review board for about ten years. So we're
27.96s - 32.06s |  CFP and review all of the talks that come through. I've also been at the White House twice,
32.06s - 38.80s |  2003, 2005, and also to help set up the, um, the Office of the National Cyber Director. Um,
38.80s - 43.64s |  so Harry's gonna come out. He's got some, um, uh, some initial remarks and then we'll just
43.64s - 47.88s |  dive right into the comments. So, um, he's got an amazing bio we're not gonna cover, but
47.88s - 51.62s |  to, please do be checking it out. Um, and with that, Harry.
59.72s - 79.62s |  Thanks, Jerry. First things first, as I tell all the bartenders I work with, pour it like
79.62s - 85.22s |  you don't own it. So that's what I did. But that actually came from, uh, the military
85.22s - 93.14s |  cyber, uh, professional association. So that is cyber bourbon. Um, I have somewhere around
93.14s - 101.18s |  70. Uh, bought a barrel, but on to why we're here. Sorry. Uh, thanks, Jay. Um, it's a pleasure
101.18s - 106.50s |  to be here and actually it's my first time at DEF CON as you, um, you've noticed. Uh,
106.50s - 111.50s |  but as a scotch drinker myself, I'm a bit disappointed that all of my speeches don't
111.50s - 116.26s |  start this way. Um, but perhaps this will be another tradition that we, uh, bring forth
116.26s - 122.30s |  at, uh, ONCD. All right. Looking forward to our conversation, Jay, uh, where we'll dig
122.34s - 128.70s |  into memory safety, uh, BGP security, firmware, vulnerability, and open source software. All
128.70s - 135.14s |  of the nuanced and technical topics that make Hacker Summer Camp such a draw, even in this
135.14s - 140.54s |  new venue. Uh, but before we get into the hard problems that really define our work
140.54s - 144.30s |  at the, uh, White House Office of National Cyber Director, I want to say a few words
144.30s - 150.54s |  about the importance of this community to our effort to make our nation safer, um, more
151.18s - 157.62s |  innovative, and prosperous. Uh, this is my first DEF CON. Again, as you noticed, uh, by my
157.62s - 163.70s |  baptism, uh, by this bourbon. And actually it shouldn't be a tradition just for first timers.
163.70s - 168.54s |  Um, but while I have been thoroughly impressed by the people, the presentations, and
168.54s - 173.50s |  actually, uh, some policy proposals that I've seen over the past couple of days, uh, I
173.50s - 179.30s |  cannot say that I'm surprised. Uh, from my early exposure to coding as a computer science
179.30s - 186.10s |  graduate student, um, to my time collaborating with reverse engineers, uh, and colleagues
186.10s - 191.54s |  in the intelligence community, to arriving at the White House, I've known how special, uh,
191.54s - 198.46s |  the security research community is. Special, but often misunderstood. Uh, as a society, we
198.46s - 204.74s |  are predisposed to celebrate builders, uh, inventors, engineers, the titans of industries.
204.74s - 210.90s |  All are lauded for what they've designed and constructed. So it can be quite jarring to hear
210.90s - 217.98s |  about a culture where tinkering is turned to, to brick, turn toward breaking things, albeit to
217.98s - 224.58s |  make them stronger. Where rather than synthesis and cohesion, we talk about decompiling code
224.58s - 230.46s |  to find its weaknesses. Where manipulating people in the form of social engineering is
230.50s - 235.86s |  venerated as a way of finding the weak points in a system. And if there's one place in the
235.86s - 242.34s |  world where these concepts are particularly foreign, it's Washington, D.C. Our elected
242.34s - 248.34s |  officials and our civil servants swear an oath to protect and defend the Constitution, and
248.34s - 255.18s |  it is far from intuitive, uh, to how hacking could possibly be in that interest. I can see
255.18s - 260.90s |  where they're coming from, uh, but my personal experiences urge me to challenge them to think a
260.90s - 267.82s |  bit deeper. Uh, to understand that for folks in this community, the desire to make things, to
267.82s - 273.26s |  take things apart, is rooted in a hope that they will be made stronger. Uh, to recognize that the
273.26s - 280.26s |  internet, decentralized, governed largely by a simple set of rules written decades ago, is a
280.26s - 287.66s |  miracle of human ingenuity. And that miraculous, as it may be, the internet also needs
287.66s - 293.90s |  protecting. That ethos of trying to make the internet a safer place is what makes this
293.90s - 299.42s |  community so important and vital to our way of life. It's why it's so important for me to have
299.42s - 305.14s |  made this pilgrimage out to the desert, along with so many of our cyber colleagues. And I've got
305.14s - 311.34s |  good news for you. My voice is not alone in Washington. The chorus is growing. Jay, I know
311.34s - 316.70s |  that when you were actually serving on the National Security Council staff decades ago, uh, you
316.70s - 323.58s |  weren't even allowed to come to DEF CON. Today, not only are the feds here in force to learn and
323.58s - 330.52s |  to celebrate the work of this community, we are recruiting. One of the key projects that we
330.52s - 335.16s |  launched at the Office of the National Cyber Director, uh, was a white paper focused on memory
335.16s - 342.28s |  safety titled, Back to the Building Blocks. I will admit to being a, a bit surprised to see such a
342.28s - 347.32s |  technical product come out of the White House. Yet after reviewing the report and learning about
347.32s - 353.96s |  the research and consultation underlying it, I was completely convinced that it was vital that the
353.96s - 358.56s |  White House shine a spotlight on the need to adopt solutions on the most critical
358.56s - 365.54s |  vulnerabilities. The White House endorsing formal mess methods is now a bit of a meme, and I could
365.54s - 372.00s |  not be happier. These are outward signs of progress. At least as important, though, is a
372.00s - 377.84s |  cultural change happening in Washington. For the first time, we are seeing policymakers consider
377.84s - 383.36s |  how to leverage unique aspects of the security research community to solve some of the very
383.36s - 390.36s |  hardest problems in cyber security. Some of that is manifesting at the operational level as
390.36s - 397.96s |  collaboration, not simply information sharing. And that has been increasingly the norm at NSA's
397.96s - 404.80s |  Cyber Security Collaboration Center and CISA's Joint Cyber Defense Collaborative. And it does
404.80s - 411.94s |  extend to more strategic proposals, too. Just yesterday, ONCD and our partners in the
411.94s - 418.22s |  government's Open Source Software Security Initiative released a report summarizing key
418.22s - 424.38s |  findings from a request for information that we announced right here at last year's DEF CON.
424.38s - 430.74s |  Importantly, that summary also describes actions that we are taking in response to the feedback from
430.74s - 438.30s |  this community. Some of those actions are inherently governmental. For instance, we are proud to
438.30s - 444.82s |  announce that the Department of Homeland Security has committed $11 million from the bipartisan
444.82s - 451.42s |  infrastructure law to launch the Open Source Software Prevalence Initiative. Along with partners
451.42s - 456.70s |  at our national labs, the initiative will assess the prevalence of open source software in
456.70s - 462.58s |  operational technology used by critical infrastructure owners and operators. We know that
462.58s - 468.58s |  open source underlies our digital infrastructure, and it's vital that, as a government, we
468.58s - 475.22s |  contribute back to the community as part of our broader infrastructure efforts. But many more of the
475.22s - 481.38s |  recommendations go beyond what the government can do alone. And that's where you all come in.
481.38s - 487.30s |  These policy proposals rely on the dedication of security researchers and their willingness to
487.30s - 492.94s |  freely share their findings in order to work. In our conversations, we are developing a software
492.94s - 500.14s |  liability regime, too. We are increasingly aiming to leverage this unique community as part of
500.14s - 507.70s |  novel policy solutions. Our reliance on all of you does, however, come with a commensurate increase
507.70s - 514.02s |  in responsibility. In the President's National Cybersecurity Strategy, we call for more of the
514.02s - 521.14s |  responsibility for defending cyberspace to fall upon the more capable actors in the ecosystem.
521.14s - 527.34s |  That means technology producers, yes, and certainly the federal government, but it also means all of
527.34s - 535.10s |  you. I know that you all are up to it. And I know that the same value set that drives responsible
535.10s - 541.94s |  vulnerability disclosure will lead you to continue to step up for the protection of the Internet. I
541.94s - 547.94s |  know the Internet is a safer place today because of all of your efforts. But I hope you can
547.94s - 555.94s |  appreciate the magnitude and impact of the hard problems defending cyberspace. They may seem easy to
555.94s - 561.98s |  some of you, but the President can't simply issue an order and solve those problems. We've known
561.98s - 568.18s |  about vulnerabilities in the Border Gateway Protocol for decades. Still, much of the U.S.
568.18s - 573.90s |  Internet traffic is subject to hijacking. Memory-safe programming languages have similarly been
573.90s - 581.82s |  around for years. Still, critical software that underlies our society is written in C simply
581.82s - 588.14s |  because that's what's convenient. The tragedy of the commons around open-source software
588.14s - 595.22s |  development is a well-understood phenomenon. Still, vital packages are maintained by tiny bands of
595.22s - 603.46s |  volunteers operating on a less-than-shoestring budget. Policy can address some of these problems.
603.46s - 609.94s |  Now, I'll even go further. Policy is essential to addressing these problems, but policy does
609.94s - 615.30s |  require time. The people of the United States have entrusted their government with awesome
615.30s - 621.26s |  responsibilities. And as we work to use them to improve our cybersecurity posture, we must ensure
621.26s - 627.18s |  that we do so responsibly, with an eye towards outcomes that preserve the innovation and
627.18s - 632.94s |  decentralization that have made the Internet the miracle that it is today. Most important,
632.94s - 638.14s |  though, is that we continue to work together. At the core of our approach at the Office of the
638.14s - 644.22s |  National Cyber Director is partnership. We prioritize hearing and learning from a diverse
644.22s - 649.74s |  array of stakeholders, and you all are key constituents of ours. I know that Jay and I will
649.74s - 655.86s |  dig into some of the details on various initiatives, but we will also continue to seek your
655.86s - 661.10s |  feedback throughout the rest of this weekend and beyond. So thank you again for everything you're
661.10s - 668.26s |  doing every day to passionately protect our digital ecosystem. And thank you again for welcoming me to
668.26s - 668.86s |  DEF CON.
677.71s - 685.79s |  Okay, so to start with, Harry, be really careful about this table, because the previous speakers
685.79s - 690.99s |  are messy and there is booze all over this table, and if we touch it, we're going to stick to it. So
690.99s - 694.99s |  I would just be careful about that. Second, remember all those questions that we said we were
694.99s - 700.59s |  going to talk about? I'm not going to start with those. Yeah, so the ONCD staff here is starting to
700.59s - 708.59s |  panic a little bit. Because you said such, you know, a word that we don't use here at DEF CON
708.59s - 714.99s |  often enough, the Internet is a freaking miracle. And I mean that in two ways, and I'm going to ask
714.99s - 720.91s |  you to expand, but let me go into it. Because miracles are two things. One, the Internet is
720.91s - 729.31s |  probably the most transformative technology since Gutenberg. Since we came up with movable type, the
729.31s - 734.91s |  Internet and the things around it have probably transformed us as a species more than anything
734.91s - 741.35s |  else. And just imagine if the Pope, the petty princes of Europe could have known what was being
741.35s - 744.85s |  printed, who was printing it and to whom it was being passed. We wouldn't have had the
744.85s - 750.31s |  renaissance. The Internet is this real miracle that we often take advantage of. And it's a
750.31s - 756.81s |  miracle in another sense too. A lot of times a miracle is just something that is really, really,
756.81s - 764.71s |  really, really hard and still comes to be. And when I see this community, I think a lot of my
764.71s - 770.51s |  colleagues in academia and others just take for granted that the Internet is stable at large
770.51s - 778.51s |  scale. Like, oh, it just works. And I'm like, no, doofus. People are working weekends and
778.51s - 784.51s |  they're missing kids' birthdays and they're missing every holiday for years to keep it running.
784.51s - 791.47s |  You know Apollo 13, yay, nerds, right? It's one of our favorite movies, right? And what did
791.47s - 797.87s |  those NASA engineers have to do to get Apollo 13 running, right? They took all of their stuff and
797.87s - 803.91s |  they had to completely nerd how can we make this work. Y'all are Apollo 13ing every week to
803.91s - 808.91s |  keep the Internet up and it just gets taken for granted and a lot of times it ticks me off. So I
808.91s - 812.33s |  just wanted to say thank you very much for acknowledging and using that word that we don't
812.33s - 820.33s |  enough. Thank you for mentioning that. It's unfortunate that miracles like that are taken for
821.33s - 827.33s |  granted. I think if we take the time to reflect on the impact of our daily lives that the digital
830.99s - 837.71s |  foundation has, it won't be taken for granted. But we have become accustomed to a certain way of
837.71s - 843.49s |  life and we expect things to always be there without looking behind the curtain and seeing those
843.53s - 849.53s |  folks working. So let's dive in. We're wearing some bling here. So I got one because I asked and I
858.41s - 864.53s |  used to work in the office. Can you talk about the badge you have on top here? And how can people
864.53s - 869.45s |  get them? The badge is the Office of National Cyber Director. Hopefully you all got them last
869.49s - 876.29s |  year. And hopefully you'll get them this year. You ought to take a look at the open source
876.29s - 882.57s |  software security report that we issued yesterday. There are some clues there. Read it
882.57s - 889.91s |  carefully. That's the first clue I'm giving you. You can also take a look at our GitHub account to
889.91s - 895.79s |  get additional clues. But they are here and available. And again, I'm just going to call some
895.79s - 900.41s |  things out here. When I was at White House, I started in 2003. I had already been coming at
900.41s - 907.07s |  that point to Black Hat for DEF CON for a couple of years. And they wouldn't let me. And now
907.07s - 913.75s |  there's a White House GitHub page. White House is doing official badges. How many folks do you
913.75s - 919.75s |  have here? At least ten folks. That are all over. And when you do something like this in the
919.75s - 929.25s |  White House, this starts to become a presidential record. You can't imagine. I talked briefly
929.25s - 935.47s |  about the culture change that's ongoing in Washington. And it's required. The things that are
935.47s - 942.67s |  happening around the world require us to evolve with them. There are revolutions. But I think
942.67s - 947.41s |  human nature is only that we can evolve. But we have to try to keep pace. Culture change takes a
947.41s - 954.49s |  while. The White House and other government institutions recognize that we need to be able to
954.49s - 960.13s |  relate more broadly. And that's part of the culture change. We need to be able to trust more
960.13s - 966.85s |  broadly. That's part of the culture change. We need to be able to look at the community research
966.85s - 974.21s |  effort and bring that in. To recognize that it's part of our team. It's always been a part of our
974.21s - 977.57s |  team. But we have not always recognized it. That's part of that culture change.
977.57s - 983.45s |  And I love it because it's so much deeper relationship now. On this stage, in this chair, Jen
983.45s - 987.09s |  Easterly yesterday, I don't know how many saw Director Easterly. She was great. But she talked
987.09s - 993.97s |  about when she was more junior and she was helping prepare Keith Alexander for when he was coming to
993.97s - 999.85s |  Black Hat. And I know one of the leading hackers had brought eggs with him and was going to throw
999.89s - 1004.37s |  eggs and ended up not. Because this was right after Snowden. Because it was a very fragile
1004.37s - 1009.61s |  relationship then between the federal government and hackers. And now again, I remember one time I
1009.61s - 1014.73s |  was in your office. I was in the White House compound. And I turned a corner and there were all
1014.73s - 1020.61s |  these blue hairs. You had all of these hackers who were in their full blue haired regalia with
1020.61s - 1025.53s |  their tattoos and their stickers. And they were just there to review the National Cyber Security
1025.53s - 1026.53s |  Strategy and give their input.
1026.85s - 1032.73s |  Yeah. And that's actually a part of a broader culture change. So excuse me for going off script.
1033.77s - 1040.45s |  We need to get past how people look and how they act. If they're committed to getting things done.
1045.57s - 1050.37s |  If they're committed to getting things done for the good of this nation, they ought to be on the
1050.37s - 1059.25s |  team. And personally, I was challenged when a person I hold dearly came home with a Band-Aid over
1059.25s - 1065.49s |  the eye. And I'm like, oh, what happened? And I bumped my head at school. I'm like, okay. Then I
1065.49s - 1072.85s |  saw the prom picture. So there was an earring there. But I had to get over that. That was my
1072.85s - 1077.65s |  issue. Not my loved one's issue. And that's just a personal anecdote.
1077.97s - 1079.93s |  And it wasn't me, by the way, just to be clear.
1080.21s - 1085.41s |  On getting past how people look, where they're from, how they talk. If we're committed to
1085.41s - 1088.97s |  accomplishing the same outcomes, let's move out together.
1089.17s - 1092.81s |  So let's actually get to one of the questions that I said I was going to ask.
1092.81s - 1093.53s |  If you insist.
1093.57s - 1102.97s |  Because we've had, you know, hackers in general, we hate these bullshit requirements. We hate
1102.97s - 1108.29s |  these things that are put in the way. Because that's what the community is about, is saying,
1108.29s - 1113.01s |  wait a minute, that's security theater. This is bullshit. Let's bypass these. And one of those
1113.01s - 1117.97s |  that's held this community back, like, so much of what we have to do is positive action. But
1117.97s - 1123.49s |  sometimes what we have to do is just remove the bullshit. And often we would have these
1123.53s - 1129.33s |  educational and other requirements for jobs that, and this is tough for me to say as a
1129.33s - 1137.41s |  university professor, is we would have these requirements for degrees that just weren't
1137.41s - 1140.05s |  necessary. And I think we've made a lot of progress, right?
1140.25s - 1149.05s |  We have. But first off on the bullshit, throw a flag. If you see something that's not right,
1149.69s - 1157.85s |  throw a flag. We have thick skin at ONCD. We know that no entity gets it right the first time,
1157.85s - 1166.73s |  every time. So we want constructive feedback nonstop. So bring that on. We want to do that.
1167.89s - 1171.69s |  Skills based hiring. It looks like we've been filling out a lot of requirements.
1171.77s - 1180.65s |  Yeah. And I share your challenge on the four year degree requirement. One of the tangible
1180.89s - 1187.33s |  outcomes that our office has been able to accomplish with our partners, and you'll hear me
1187.33s - 1193.49s |  talk about with our partners a lot. Our office is about collaboration, leadership via
1193.49s - 1201.89s |  collaboration. We stood up to bring coherence to the federal cybersecurity ecosystem, not to be
1201.89s - 1207.73s |  in charge, but to lead. And you don't need to be in charge to lead. So we are leading via
1207.73s - 1215.13s |  collaboration. And one area with our partners is a skills based hiring approach. And we
1215.13s - 1222.97s |  recognized that it had been emerging in the private sector and other functional areas. And
1223.01s - 1231.69s |  given that there are roughly 500,000 open cyber jobs in this great nation, and that does not
1231.69s - 1240.81s |  imply we're 500,000 people short in talent. We have the talent. It's not a talent issue. It's a
1240.81s - 1248.01s |  recruiting issue. So we developed a national cyber workforce and education strategy to help
1248.33s - 1262.25s |  address that $500,000 gap in open cyber positions. And one of the focuses is removing barriers to
1262.25s - 1270.61s |  these good paying, purposeful cyber jobs. One of the barriers that we had seen is requirements for
1270.61s - 1277.93s |  four year degrees. And I'd imagine that just about everybody in here knows folks that don't have
1277.93s - 1285.69s |  four year degrees that are making substantial contributions to cybersecurity. Initially, when
1285.69s - 1292.41s |  our team took that on, we thought that needed to change a law or needed to change a regulation.
1292.97s - 1299.25s |  That's not the case. It was just a legacy bad practice. So the first step that our team has
1299.25s - 1306.93s |  taken on in concert with the Office of Management and Budget, OMB and others, is to reach out to the
1306.93s - 1313.25s |  departments and agencies, senior acquisition executives, to ensure that they know that they are
1313.25s - 1321.85s |  not being held to account by the federal government on this four year college degree. If there is a
1321.85s - 1327.13s |  requirement, it's a specific department and agency requirement, and it should not be there. Again,
1327.13s - 1333.57s |  it's a legacy bad practice. So we're getting that word out on the federal contractor side. On the
1334.05s - 1339.37s |  federal employee government civil servant side, we're working with our partners at the Office of
1339.37s - 1347.37s |  Personnel Management, OPM, to do the same thing, to go towards skills based hiring. Why? Because
1347.37s - 1352.25s |  it's not about the paper certification that we all frame and put up on our wall. It's about the
1352.25s - 1359.05s |  knowledge that we have. It's about the skill set that we can apply to the mission set. And, you know, the
1359.05s - 1365.53s |  example that's most near and dear to me, I spent several years at the National Security Agency,
1365.77s - 1374.09s |  working shoulder to shoulder with our colleagues at the US Cyber Command. And many, many of the
1374.17s - 1381.93s |  operators at NSA and Cyber Command are military members. And many of those military members do not
1381.93s - 1388.41s |  have four year college degrees. But they all have the skill set necessary to make significant
1388.41s - 1394.37s |  contributions to our nation's security in cyberspace. So we're working with OPM. They've taken on the
1394.37s - 1403.85s |  task to be completed by June 2025, to transition the largest IT occupation in the federal
1403.85s - 1410.65s |  government, the 2210 series to a skills based approach. And that's just the right thing to do.
1411.25s - 1416.01s |  That's going to remove some barriers, that's going to close that gap. And it's going to make us safer.
1420.01s - 1428.25s |  So especially for folks that don't necessarily know how DC works, right? I'll start with that would
1428.25s - 1435.13s |  include me. Right, when Harry talked about workforce, right, the very first workforce
1435.13s - 1442.73s |  recommendations came from the White House in 2000. So President Clinton's administration had come out
1442.73s - 1448.53s |  with the first, it wasn't quite a strategy, but it was, it was an implementation. And they said,
1448.53s - 1455.97s |  boy, we've got to solve this. Right. So it goes back to 2000. And it's not like DC was, the US
1455.97s - 1461.41s |  government wasn't trying to do this. It's just that there are hard problems that needed longer
1461.41s - 1465.65s |  than you could do in one administration and more than you could do. Because normally in the White
1465.65s - 1471.49s |  House, like when I was there, we had maybe four or six people that were looking at cyberspace,
1471.49s - 1476.49s |  especially on the defensive side. Right, even now out of the National Security Council, there may be
1476.49s - 1484.29s |  six or eight that are doing defense. And your team now is 85-ish, right? So now the National
1484.29s - 1488.61s |  Cyber, the Office of the National Cyber Director can say, we're going to have a special team of a
1488.61s - 1492.65s |  couple people led by an Assistant National Cyber Director to do workforce. And they're going to
1492.65s - 1499.49s |  stay on the problem year after year and make sure we actually make a difference to stay with it. And
1499.49s - 1506.25s |  because that's at the White House, oh, and some of her actually hired in as career civil servants
1506.25s - 1512.81s |  as part of the White House, those jobs are on USA Jobs, go look for them, that they will be able to
1512.81s - 1517.01s |  be there in between administrations. Because, because the director talked about hard problems.
1517.01s - 1522.25s |  Now in your, so Workforce is One, you brought, you really featured open source and you just had
1522.25s - 1528.53s |  this report came out this week, right? Yes, yesterday. Wow. Great. Yep. You let in with hard
1528.61s - 1534.49s |  problems. And that's one of the things that the Office of National Cyber Director is known for,
1534.49s - 1541.89s |  addressing the hard problems. And what's a hard problem? You mentioned workforce challenges were
1541.89s - 1546.45s |  brought to the forefront during the administration of President Clinton, a couple decades ago,
1546.45s - 1551.97s |  something like that. Years and years, problems lingering that have not been sufficiently
1551.97s - 1557.85s |  addressed. Those are hard problems. That's what we like to take on. The easy stuff we leave to
1557.85s - 1562.37s |  other entities, and that's fine. They're valued. But it's the hard problems that we take on.
1562.37s - 1569.01s |  Several of those hard problems, yes, include open source software. How do we address the
1569.01s - 1576.81s |  vulnerabilities? How do we value the folks that are keeping open source software as safe as they
1576.81s - 1584.81s |  have done? The report talks to how some of our open source folks feel. I think the quote was
1585.29s - 1594.37s |  unpaid hobbyists. Unpaid hobbyists. And that's accurate in many senses. But it's not accurate
1594.37s - 1604.37s |  when you couple unpaid with the impact that they have. We need to take a look at how to show how
1604.37s - 1609.53s |  much we value those folks. We value them, but we don't show it the way we should. So we need to
1609.53s - 1616.49s |  take advantage of that. I know earlier today we talked about the German tech fund that's in the
1616.49s - 1624.17s |  report. That's an investment made by the German government on some of their software. And some
1624.17s - 1631.49s |  of the recommendations into the RFI were for the U.S. federal government to make some
1631.49s - 1640.73s |  investments in the open source software. You mentioned the RFI. So one of the ways the U.S.
1640.73s - 1645.13s |  government works is by putting out, hey, we're thinking about making a new rule or we're
1645.13s - 1652.09s |  looking for new information. So ONCD has done two or three at least. So they did one on, hey,
1652.09s - 1658.05s |  what are your ideas in regulatory harmonization? That got maybe 85-ish responses. What are your
1658.05s - 1661.85s |  ideas on open source? So this came out, I think the responses were due in November.
1661.85s - 1665.53s |  On open source, we actually announced that here last year.
1665.53s - 1665.89s |  Oh, great.
1665.89s - 1673.53s |  Yeah. And actually, that's why we came back to announce it. It's great to take all these actions.
1673.53s - 1680.57s |  It's great to have RFIs to get input from the people who, frankly, may know more about these
1680.57s - 1686.85s |  items than we do. But it's not great if we don't take it on board and follow up with action. So we
1686.85s - 1692.77s |  have the summary reports and there will be a public and private sector working group that
1692.77s - 1699.05s |  stands up later this year to take on those recommendations on how to better protect open
1699.05s - 1703.21s |  source software and demonstrate how much we value that.
1703.21s - 1708.69s |  Yeah, great. Just a quick question. How many folks here have ever responded to one of these RFIs or
1708.69s - 1715.17s |  the like? So we've got a handful, but that's not a lot. So when you hear, if you say, man, the
1715.21s - 1721.61s |  stuff that Washington, D.C. is bullshit, they always get it wrong. Look for those RFIs, right?
1721.61s - 1728.37s |  Because that's the government. That's the White House going out and saying, what are we doing
1728.37s - 1736.05s |  wrong? What can we do better? What are your ideas? And you can just submit, right? You don't have to
1736.05s - 1742.09s |  be this tall to enter. You can submit your ideas directly on how we should be improving open
1742.13s - 1747.85s |  source or regulatory harmonization or whatever the next one is going to be. Because now ONCD has
1747.85s - 1752.85s |  made this a repeatable process. And I don't think NSC ever did this or OMB. I think this is very
1752.85s - 1754.69s |  much an ONCD thing, right?
1754.69s - 1760.61s |  Other agencies are doing it now and we are happy that they're doing it now. Again, the key is to
1760.61s - 1768.73s |  make it meaningful. And I'll just speak frankly. I have heard, we have heard from our partners in
1768.73s - 1774.97s |  the private sector that if we don't act upon the feedback, then the opportunity to contribute to
1774.97s - 1781.45s |  an RFI is not going to be nearly as meaningful. And to that end, Jay mentioned the RFI on
1781.61s - 1789.53s |  regulatory harmonization. And we had a lot of feedback, a lot of valuable feedback. And it came
1789.77s - 1797.81s |  in large part from 11 of the 16 critical infrastructure sectors. And that's great. But my
1797.81s - 1804.65s |  concern is the other five critical infrastructure sectors did not submit input to that RFI.
1805.77s - 1809.85s |  Just think about like critical infrastructure sectors, which are kind of by definition,
1809.85s - 1815.37s |  critical to this country, did not submit on their thoughts.
1815.37s - 1818.49s |  Yeah. And that's unfortunate. We're still reaching out to them.
1818.69s - 1820.33s |  Judge, judge, judge.
1820.33s - 1824.89s |  Yeah, we're still reaching out to them because we value their input. Maybe there's another means
1824.89s - 1831.21s |  that's more convenient for them. So we're not giving up on them. But they passed on that
1831.21s - 1832.85s |  opportunity, but we'll get with it.
1833.53s - 1838.09s |  So one of the ways that you can connect, one of the ways you can make policy better, hopefully we
1838.09s - 1843.37s |  might have time to talk about some other ones. But be on the lookout for those RFIs. Even if your
1843.37s - 1848.61s |  company is not going to let you submit, you can still submit just as an individual or grab a bunch
1848.61s - 1853.89s |  of friends. Okay, other hard problems. Where else are we working? I heard you talk about routing,
1853.89s - 1858.73s |  which we hardly ever talk about. So it was glad to hear you bring it up.
1858.81s - 1866.21s |  Yes, our team is working again with our partners in the federal government to include CISA, NIST,
1866.37s - 1873.77s |  the NSA, and plenty of others on securing the internet. As you all know, internet was created
1873.77s - 1881.53s |  decades ago, not envisioned to be what it is today, critical to the way each and every one of us and
1881.53s - 1887.21s |  our loved ones live. It was not envisioned to be that, but that's where we are right now. It was
1887.21s - 1895.93s |  not built to be as secure and safe and reliable as we need it to be. And as a former program
1895.93s - 1903.09s |  manager, I know how difficult it is to bolt these things on after the product has already been
1903.09s - 1908.17s |  built. Nevertheless, that's not enough reason to not take it on. So our team, again, working with
1908.17s - 1914.85s |  our federal partners, is looking at border gateway protocol, the means of transferring bulk
1914.85s - 1924.73s |  internet data, and how to secure that. What we are working on is a recommendation for RPKI as a
1924.77s - 1932.73s |  solution to that. And we realize that RPKI is not going to solve all of the problems on that border
1932.73s - 1941.25s |  gateway protocol. But we also realize need to start somewhere, sometime. And RPKI is a great place to
1941.25s - 1950.37s |  start. And we're still seeking input on how to address those challenges in BGP. And that's one of
1950.37s - 1957.97s |  the reasons we're here to seek you all's input on BGP. And again, another hard problem. It's been
1957.97s - 1964.93s |  around for years and years and years. We have known that the internet is not secure. But we
1964.93s - 1972.01s |  twiddled our thumbs and said it's not secure. And we have not taken secure action, sufficient
1972.01s - 1974.01s |  action. But we're doing that now.
1974.01s - 1980.53s |  Yeah. That's great. And two quick notes. So you said secure by design, we've known for a while. We
1980.53s - 1987.77s |  have actually known for almost 52 years. So hey, I'm a college professor by day. And so I've got
1987.77s - 1995.73s |  time to look at this. October 1972, the Anderson report came out and said security cannot be
1995.73s - 2002.25s |  included by retrofit. It has to be included by part of the design. So since 1972, we've known
2002.25s - 2007.41s |  that. The same report said basically the red team always gets through. Meaning the offense has the
2007.41s - 2012.49s |  advantage. The attackers are able to get through. So remember I talked about that miracle? We're
2012.49s - 2018.61s |  50 years into this. Our grandparents had these problems. Unless we can really tackle these hard
2018.61s - 2024.05s |  problems, our grandkids are going to be suffering through the same stuff as we are. And that's kind
2024.05s - 2028.13s |  of depressing, right? To think that they're like our grandkids are going daddy, daddy, we had a
2028.13s - 2029.13s |  DNS issue today.
2029.13s - 2037.73s |  But that's our reality. And that should be our impetus for action. And you talk about these
2037.73s - 2044.65s |  decades old problems. Another one is memory safe programming, or not memory safe programming
2044.65s - 2053.45s |  languages. We've known it for years and years. But we have been slow to address it. And when I read
2053.49s - 2058.21s |  our report that was released earlier this year, building blocks, please take a look at it,
2058.49s - 2064.65s |  critique it, and let us know what you think. I was surprised to learn that that problem has been
2064.65s - 2071.57s |  around for so long. And then I was surprised to learn that the software developers, the community
2071.57s - 2077.97s |  itself, knew about the problem and had been advocating us to make that transition. But for
2077.97s - 2083.37s |  whatever reason, and I'm not into blame, I'm into fixing things. But whatever reason, we didn't
2083.37s - 2091.45s |  take action on that. We're trying to do that now. Along those lines, college professor, we need
2092.41s - 2098.01s |  memory safe programming languages to be taught in colleges and high schools and trade schools and
2098.01s - 2105.65s |  elsewhere. And I was at, I'll say, a service academy, not yours or mine. Earlier this year,
2106.57s - 2114.01s |  talking to a young person about that building blocks report, and I asked the individual if they
2114.01s - 2121.53s |  had read that report. And they had not. So I gave a high level, non-technical synopsis of the
2121.53s - 2126.41s |  report, saying, you know, we need to go to memory safe programming languages. Here are some
2126.41s - 2131.77s |  recommendations. Here are examples of non-memory safe programming languages. And when I ran down
2131.77s - 2137.29s |  the list of non-memory safe programming languages, that individual said, oh, but they're so
2137.29s - 2144.25s |  convenient. And I said, exactly. That's the challenge. Can't always choose convenience over
2144.25s - 2149.85s |  safety and security and reliability. Then I asked the individual, well, when you do graduate and get
2149.85s - 2158.17s |  your commission, what warfare specialty will you go into? And the response was cyber. And I said,
2158.17s - 2162.41s |  well, in a few years, you'll understand better. And that individual will.
2162.97s - 2168.89s |  I mean, it was a quote that I first heard from Dan Geer probably in 2001 or 2002, the enemy of
2168.89s - 2180.12s |  security isn't insecurity, it's convenience. And Dan was so right in so much. So some of my
2180.12s - 2190.12s |  friends who run CornCon in Iowa, they had a project of looking at, we want to look at the text
2190.12s - 2196.36s |  books to see if they're actually teaching good coding procedures. Like, not are we including
2196.36s - 2202.76s |  cyber security in computer science programs, but are we teaching crap in computer science, like,
2202.76s - 2208.36s |  out of date stuff in the programs. And it seems like, you know, I mean, degrees are important.
2208.36s - 2213.88s |  That's a lot of the ways that many of us do get in. And I just wanted to raise that because it
2213.88s - 2220.36s |  struck me as an important idea. Yes. Just yesterday, we visited the College of Southern
2220.36s - 2227.80s |  Nevada. And in our student roundtable, one of the students mentioned and several of the students
2228.68s - 2236.04s |  endorsed that student's perspective that the textbooks that they're using need to be more
2236.04s - 2245.00s |  current. And that's valid. That's a challenge. Our field is evolving so rapidly. But we need to
2245.00s - 2250.36s |  figure out how to at least keep pace. It'd be better if we stayed ahead. But we need to figure
2250.36s - 2257.88s |  out how to keep pace with that. By the way, I saw you dancing on the side of the stage.
2257.88s - 2258.68s |  Yes, sir.
2258.68s - 2261.00s |  Are you tracking the Olympics break dance competition?
2261.08s - 2265.80s |  My gosh, it's great. Yeah. All right. Go Team America, for those of you from America. If not,
2265.80s - 2271.48s |  go whatever your country is. It's just amazing. Especially because it's so, right, especially as
2273.48s - 2279.00s |  computer security professionals, it's really easy to get pessimistic about stuff, right? Every year
2279.00s - 2284.12s |  things seem to kind of get worse. And it's nice. And it seems like everybody hates each other a
2284.12s - 2287.96s |  little more each year. So I'm glad you brought it up because it is great to see what all the
2287.96s - 2293.48s |  athletes are doing, especially when we're putting together. But I didn't make the team this year.
2293.48s - 2299.56s |  And it goes back. Had I not been here, I'd have been in Paris competing. But that does go back
2299.56s - 2305.56s |  to our earlier conversation on cultural change. Plenty of people don't think that's a sport,
2305.56s - 2309.96s |  shouldn't be an Olympic sport, shouldn't have a gold medal. Usually they have great
2309.96s - 2314.04s |  beards like me and you. But we need to evolve with our people.
2314.52s - 2319.88s |  All right. So as we start closing out, there's going to be two questions. And one is,
2322.04s - 2327.00s |  we've talked about some ways people can get involved. The RFIs come out, you can apply to
2327.00s - 2331.56s |  the RFIs, right? The jobs at White House, right? You can go and you can apply to a job at the White
2331.56s - 2338.84s |  House. And like, they're amazing. So I've got a couple ideas. I'd love to hear your ideas on how
2338.84s - 2344.52s |  this community in particular can get involved to help unfuck policy in Washington, D.C.
2344.52s - 2355.00s |  Yeah. I'm big on mentoring and sponsoring. And we've been on a tour of colleges around the
2355.00s - 2361.48s |  country. And what a consistent theme that we've heard from the students is they want to learn
2361.48s - 2371.08s |  more from experienced people. I think there's opportunities for all of us to mentor. I almost
2371.08s - 2377.16s |  said these young people. But fortunately, there are some not so young people also changing their
2377.16s - 2384.52s |  career focus into cybersecurity. So there's opportunities there. We are partnering again
2384.52s - 2391.40s |  with our federal department and agency colleagues on hiring sprints across the country. If you
2391.40s - 2398.76s |  all are hiring, let us know. If you know folks looking for jobs, send them in the direction of
2398.76s - 2404.20s |  those hiring sprints. There are plenty of opportunities. And again, when you look at
2404.20s - 2412.36s |  500,000 open jobs, we need to do that. I want to call out a couple of folks here.
2412.36s - 2416.44s |  Do we have any folks that teach cybersecurity? Please clap. All right. Yeah. Hands up. All right.
2416.44s - 2424.36s |  For those that teach. Any teach at the high school level or below? Good. Only a couple, right?
2426.04s - 2431.72s |  Volunteering at the schools. Doing what you can. Seeing if you can put, right, I was just talking
2431.72s - 2438.12s |  to a colleague at dinner the other day that was at Montana. Was it Montana State? And they didn't
2438.12s - 2443.64s |  have cybersecurity. And he said, let's do this. And they just got $14 million grants and now
2443.64s - 2449.72s |  they're plugging ahead, right? There's room for volunteering and to get things done. So please
2449.72s - 2455.16s |  get out and engage on that and mentoring the rest. I mentioned Tech Congress has amazing fellowships
2455.16s - 2459.88s |  to help those on Congress to get better. Hackers on the Hill, if you're ever in D.C., they have
2459.88s - 2465.96s |  got great projects. And the Policy Village here, it's incredible stuff. It is. And we need to
2465.96s - 2470.68s |  increase it. Again, we need to take those numbers down to something more reasonable.
2471.48s - 2475.64s |  You know, again, back to the National Cyber Workforce and Education Strategy,
2476.44s - 2483.32s |  create multiple pathways and remove obstacles. One of the focuses there is we need to
2484.68s - 2493.08s |  do better in recruiting. You and I talked earlier about the numbers male versus female.
2494.04s - 2503.00s |  And how to encourage more participation from girls and ladies in cybersecurity.
2504.44s - 2510.44s |  We were pleased yesterday at the College of Southern Nevada and UNLV. They both have women
2510.44s - 2518.04s |  in cyber clubs. And to my delight, they said the numbers were increasing. The productivity
2518.04s - 2526.20s |  was increasing. And that's a good thing. We need to make opportunities available to every American,
2526.20s - 2533.24s |  to every community across this country. A lot of that is exposing them to the opportunities.
2533.24s - 2537.96s |  Oftentimes, people just don't know about cybersecurity and the good paying jobs,
2537.96s - 2543.72s |  the meaningful careers, a way to help protect themselves, the nation and their loved ones.
2543.96s - 2549.96s |  One other way I'll say you can participate, run for office. You'll see Andrew running around with
2549.96s - 2556.44s |  elect more hackers. However, we just need you. If you think you can do better than those bozos,
2557.88s - 2562.44s |  let's see you in there. And I'm serious. Through DEF CON over the last ten years,
2562.44s - 2565.48s |  we've had a lot of great elected officials who were smart about
2565.48s - 2569.00s |  computer security. But a lot of times they only learned about it once they were in office.
2569.08s - 2573.96s |  And so we can do better. Okay. Closing out our last couple of sips, last question,
2574.60s - 2586.14s |  favorite hacker movie or literature and why? The Oceans series was good for me
2587.18s - 2596.70s |  because it incorporated cyber into the team. And when I look back on my military experience
2597.18s - 2604.38s |  and my operational experience in the intelligence community, we did not always incorporate cyber
2604.38s - 2611.58s |  early on in our missions. And we would have been better served had we done that. So Oceans
2611.58s - 2619.34s |  was a great example of that. And along those lines, when we talk to folks about the importance
2619.42s - 2627.18s |  of cyber, every now and then, too often, we'll hear entities, individuals and collectives talk
2627.18s - 2637.74s |  about cyber being an inconvenience. That's just so wrong. Today and tomorrow and all the tomorrows
2637.74s - 2644.86s |  that come after that, cyber is an imperative, not an inconvenience. And so Oceans got me focused on
2644.86s - 2651.82s |  that and I was pleased that they incorporated cyber into their missions. Great movies. All right.
2651.82s - 2655.98s |  So we're going to leave with that, right? Because worrying about this and taking care of it is an
2655.98s - 2661.66s |  imperative because we have been bequeathed a miracle, right? To finish off with how Harry
2661.66s - 2667.82s |  started off, right? I always capitalize internet because to me it is a precious thing and we're
2667.82s - 2673.58s |  going to screw it up like we screw up everything else, like the air, land, sea, if we don't take
2673.58s - 2679.02s |  care of it. And so I always capitalize internet just to remind ourselves, we might not want to
2679.02s - 2685.66s |  do that, that this is only going to survive. Our grandkids are only going to have something as good
2685.66s - 2691.58s |  as we have now if we fight to keep it so. So thank you. Keep the fight alive and have a great rest
2691.58s - 2693.58s |  of your DEF CON. Thank you, Harry Coker.


url: https://www.youtube.com/watch?v=EvbNQnZlPJg
type: video
author: DEFCONConference
ingestion_date: 2024-11-10
transcription_model: large-v2
chunking_status: completed
title:
DEF CON 32 - Hi-Intensity Deconstruction: Chronicles of a Cryptographic Heist - Javadi, Levy, Draffe

content:
{
  "webpage_url": "https://www.youtube.com/watch?v=EvbNQnZlPJg",
  "title": "DEF CON 32 - Hi-Intensity Deconstruction: Chronicles of a Cryptographic Heist - Javadi, Levy, Draffe",
  "description": "Introduced in 2011, HID Global\u2019s iCLASS SE solution is one of the world\u2019s most widely-deployed Electronic Physical Access Control platforms. HID's iCLASS SE Readers are ubiquitous in electronic physical access control and used in most government agencies and Fortune 500 companies. The readers can be easily seen and identified in almost every form of mainstream media. Almost 13 years after iCLASS SE\u2019s introduction, ground-breaking research and technical exploits will be disclosed publicly for the first time.\n\nIn this talk, we detail the process by which we reverse engineered the complex hardware and software chain of trust securing HID\u2019s iCLASS SE platform.\n\nOver a seven-year research period, we analyzed hardware, firmware, and software elements the ecosystem, uncovering an unfortunate series of pitfalls and implementation defects. These flaws culminated in an attack chain that allowed for the recovery of sensitive cryptographic key material from secure elements, which have received CC EAL 5+ accreditation. This chain resulted in revealing some cryptographic keys to the kingdom.\n\nFinally, we provide comprehensive guidance on technical and operational mitigations for end customers to identify practical risks and reduce impact.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 4606,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.00s - 5.30s | This text was transcribed using whisper model: large-v2

 One second here, we'll go ahead and get us kicked off.
5.30s - 12.62s |  All right, how's everyone doing?
12.62s - 14.14s |  Well, I think we got here safely.
14.14s - 19.75s |  We can take these off for the moment, yep.
19.75s - 22.03s |  So thank you guys for coming.
22.03s - 24.31s |  This has been a long time coming.
24.31s - 27.31s |  This is a super exciting topic for us,
27.31s - 29.39s |  and we're really passionate about it.
29.39s - 31.79s |  We've worked really hard to try to provide you
31.79s - 34.59s |  all the necessary context you need to understand
34.59s - 36.95s |  what happened and what the implications are.
36.99s - 38.95s |  And we're going to do our best to kind of take you
38.95s - 40.71s |  along the journey as best as possible.
40.71s - 42.07s |  So thank you for being here,
42.07s - 44.83s |  and thank you for your patience in advance.
44.83s - 47.31s |  But first, I really want to introduce
47.31s - 48.73s |  some of the other researchers.
48.73s - 50.73s |  First and foremost, Aaron.
54.69s - 57.65s |  This is not an overstatement.
57.65s - 61.25s |  If it was not for Aaron, I would not be standing here.
61.25s - 64.03s |  I don't know if much of this work had have gotten done.
64.03s - 66.45s |  He was absolutely the tip of the spear,
66.45s - 68.09s |  and I can't say enough good things about him.
68.45s - 70.33s |  He is one of the most talented and kindest researchers
70.33s - 77.33s |  I've ever worked with, so yeah, thank you.
77.33s - 79.85s |  Thank you so much, Bhavik, for the kind words.
79.85s - 82.29s |  So I want to introduce Nick Draphin,
82.29s - 85.05s |  who is one of the most talented security engineers,
85.05s - 87.29s |  security researchers I have ever worked with.
88.41s - 90.33s |  He accomplishes so much stuff,
90.33s - 94.09s |  he works on so much stuff beyond all of this.
94.09s - 99.10s |  Yeah, he's just incredible, he's amazing.
99.10s - 100.96s |  Thanks, Aaron, that's very nice.
100.96s - 102.88s |  Yeah, very pleased to meet you,
103.32s - 105.40s |  or pleased to have met you and know you.
105.40s - 107.76s |  Yeah, and I would like to introduce Bhavik Javadi,
107.76s - 110.88s |  who I'm also pleased to call my friend,
110.88s - 113.74s |  and I really appreciate our friendship
113.74s - 115.40s |  and the things that we've worked on together.
115.40s - 118.00s |  Amazing, really kind person.
119.44s - 120.98s |  One of the best hardware hackers I know,
120.98s - 125.98s |  and we constantly compete for who has the newest tool
126.48s - 129.08s |  or who is on the latest firmware of something.
129.08s - 131.40s |  He has a tendency to update firmware
131.48s - 132.76s |  at the worst possible moment,
132.76s - 135.64s |  like right before a critical training or something,
135.64s - 138.44s |  it's time to do the latest GPU update.
138.44s - 140.40s |  So, that's my friend, Bhavik, so.
146.18s - 150.54s |  So, fun fact, we're all really awkward
150.54s - 152.06s |  about talking about ourselves,
152.06s - 153.58s |  so we came up with this shtick
153.58s - 155.20s |  of introducing each other instead,
155.20s - 157.44s |  so hopefully that worked okay.
159.58s - 163.46s |  I do want to talk about one researcher
163.46s - 165.90s |  who wasn't able to join us on the stage
166.72s - 167.56s |  and that's Kate.
167.56s - 169.74s |  Kate has also been involved with the project.
169.74s - 174.30s |  She's also one of the finest, most talented hackers
174.30s - 175.62s |  I've had the pleasure of working with.
175.62s - 178.02s |  We're honored to call her a friend,
178.02s - 180.58s |  and she has definitely been a part of this journey as well.
180.58s - 183.70s |  So, just want to give a quick thank you to Kate.
183.70s - 184.54s |  Where is Kate?
184.54s - 187.09s |  There's Kate.
187.09s - 189.33s |  All right, so let's get started.
189.33s - 193.81s |  Topics of the hour, because holy shit, 75 minutes.
193.81s - 195.41s |  This is the longest talk.
195.41s - 196.61s |  Who gave us the slot?
197.89s - 200.93s |  All right, we'll do our best to make the best of it.
200.93s - 202.29s |  We got a couple things to cover.
202.29s - 205.53s |  We're gonna talk about access control systems
205.53s - 208.33s |  and a couple of really critical elements of it.
208.33s - 210.85s |  We're gonna talk about obsession,
210.85s - 214.45s |  because this has been all-consuming, as we will discuss.
214.45s - 218.41s |  And of course, the reason why you are all here, a heist.
218.41s - 221.85s |  That's the really exciting stuff that we're here for.
221.85s - 224.29s |  But before we begin, Aaron,
224.29s - 225.81s |  can you tell us a little bit more
225.81s - 228.17s |  about why they should stick around?
228.17s - 230.09s |  What does all this actually mean?
230.09s - 231.45s |  Absolutely.
231.45s - 233.49s |  So, if you look at this video,
233.49s - 235.07s |  you can see that there are two cards.
235.07s - 238.65s |  These are HID CS cards, theoretically unclonable.
238.65s - 240.57s |  And yet, if you look,
240.57s - 244.53s |  they have the same ID card number when scanned, right?
245.39s - 247.73s |  So, we have cloned the unclonable.
247.73s - 251.80s |  And in this talk, we're gonna show you how we did it.
251.80s - 254.48s |  So, I mentioned obsessions,
254.48s - 257.76s |  because we all get that, right?
257.76s - 260.24s |  This project has been kind of all-consuming
260.24s - 263.56s |  for all three of us in different ways.
263.56s - 267.24s |  It has took over my entire COVID, basically,
267.24s - 270.70s |  because we had nothing else to do other than wake up,
270.70s - 273.80s |  work for 12 to 14 hours, and then go to bed,
273.80s - 276.64s |  and then rinse and repeat for a few months, basically.
277.64s - 281.72s |  And even got into shower thoughts in the shower.
281.72s - 283.76s |  We can't stop thinking about this stuff.
283.76s - 286.84s |  Essentially, thinking about this research when we wake up,
286.84s - 288.36s |  thinking about it before we go to bed,
288.36s - 289.96s |  waking up in the middle of the night,
289.96s - 290.96s |  thinking about it,
290.96s - 292.88s |  going to dinner with our significant others,
292.88s - 295.96s |  and all we can think about is HID research.
295.96s - 298.06s |  So, that's what brought us here today.
298.96s - 302.72s |  Yeah, and we have so many HID readers at this point,
302.72s - 304.12s |  it's kind of crazy.
304.12s - 307.04s |  So many, in fact, that my now-husband
307.04s - 308.98s |  actually used an HID reader
308.98s - 311.12s |  in proposing to me a few years ago.
312.08s - 313.52s |  It's true.
313.52s - 314.52s |  We're not kidding.
318.36s - 321.00s |  But yeah, this is collectively,
321.00s - 323.28s |  thousands of hours collectively,
323.28s - 328.08s |  hundreds of readers, way, way too many dollars.
328.08s - 330.40s |  I was considering trying to tabulate it,
330.40s - 331.92s |  and then I thought better of it.
331.92s - 334.12s |  So, let's just say it was a lot.
334.12s - 335.38s |  And of course, very little sleep,
335.38s - 336.88s |  including preparing for this talk.
336.88s - 338.56s |  So, here we are.
339.48s - 343.08s |  We are gonna go kind of quick on a couple of topics.
343.08s - 345.24s |  As long as this talk is,
345.24s - 348.44s |  it is not a soup to nuts on how access control works,
348.44s - 350.32s |  but in order for you to understand
350.32s - 351.60s |  why this stuff is important,
351.60s - 354.04s |  you do need some basic building blocks.
354.04s - 356.12s |  So, we've worked really hard to try to give you guys
356.12s - 358.80s |  those basic building blocks as quickly as possible.
358.80s - 361.28s |  If something doesn't fully track, it's okay.
361.28s - 362.74s |  This stuff is kind of weird,
362.74s - 366.14s |  but I suspect that you guys will get it pretty easily.
366.14s - 369.94s |  So, the main foundation of all of this stuff
369.94s - 372.18s |  is physical access control systems.
372.18s - 374.46s |  And these are, of course, physical security controls
374.46s - 378.50s |  that are designed to control access into or out of areas.
378.50s - 380.54s |  And there's a lot of different components to these, right?
380.54s - 382.50s |  There's readers, there's cards,
382.50s - 385.50s |  there's door lock hardware and stuff like that.
385.50s - 389.10s |  And ultimately, there's a few main tenants
389.10s - 392.10s |  that all these systems have to be focused on and hit
392.10s - 394.98s |  in order to be successful in the marketplace.
394.98s - 398.78s |  In order for it to be viable, these things have to be cheap.
398.78s - 400.42s |  They have to be cost effective.
400.42s - 404.82s |  Because for literally anyone else except us in this room,
404.82s - 408.38s |  security isn't fun, it's a cost.
408.38s - 411.18s |  And so, since businesses have to make money,
411.18s - 413.14s |  for better or for worse,
413.14s - 414.98s |  they don't really necessarily like spending money
414.98s - 418.70s |  on security because they exist to maximize profit.
418.70s - 422.18s |  So, cost effectiveness actually has a huge, huge driver
422.22s - 425.18s |  for how this stuff gets designed and how it sticks around.
425.18s - 427.78s |  It also, of course, has to be easy to use
427.78s - 431.06s |  because security that gets in your way
431.06s - 432.62s |  and prevents you from doing your job
432.62s - 434.90s |  or getting where you need to be also sucks
434.90s - 437.46s |  and incurs a different kind of cost,
437.46s - 441.98s |  both to you psychologically and to the business.
441.98s - 444.34s |  By way of example, I recall,
444.34s - 445.70s |  there was a pen test that we were on
445.70s - 448.50s |  and we noticed that, during reconnaissance,
448.50s - 450.30s |  we noticed there was a side door
450.30s - 452.46s |  that people kept coming out of
452.46s - 453.86s |  and it wouldn't latch all the way.
453.86s - 455.42s |  And we're like, we can just walk in here.
455.42s - 457.46s |  And so, we used it several times.
457.46s - 460.02s |  And I remember that, in the after action report,
460.02s - 461.38s |  we brought it up and we're like,
461.38s - 463.30s |  by the way, do you guys know,
463.30s - 467.34s |  this door doesn't latch and it goes right into your office?
467.34s - 469.62s |  And the head of facilities was there and he's like,
469.62s - 472.30s |  yeah, let me tell you about that door, see?
473.66s - 476.34s |  So, this is a very efficient building.
476.34s - 478.34s |  It seals very, very well.
478.34s - 479.66s |  And when the weather is nice
479.66s - 481.42s |  and the HVAC system's not running,
481.42s - 483.98s |  we have everything adjusted and that's fine,
483.98s - 485.82s |  but then, when the HVAC system is running,
485.82s - 488.06s |  there's a positive air pressure inside the building
488.06s - 489.90s |  and now, the door closers
489.90s - 491.82s |  won't actually close the doors fully.
491.82s - 494.18s |  So, we go through and we tighten all the door closers
494.18s - 496.10s |  and we're like, okay, it's good.
496.10s - 497.46s |  And then, the weather gets nice again
497.46s - 500.62s |  and the HVAC system is off and the doors start slamming.
500.62s - 502.26s |  And so, we got all these trouble tickets
502.26s - 504.30s |  of people complaining that they're on meetings,
504.30s - 506.82s |  they're on sales calls and the door is slamming.
506.82s - 510.30s |  And so, we had to choose between security
510.30s - 512.38s |  and keeping our employees happy.
512.38s - 513.62s |  What do you think won?
514.62s - 516.90s |  Of course, it wouldn't be a story if it was security.
516.90s - 518.32s |  It was the latter.
518.32s - 521.70s |  So, simplicity, ease of use, that's a huge deal.
521.70s - 523.30s |  The golden rule of access control
523.30s - 525.46s |  is never get in the way of doing business,
525.46s - 526.66s |  for better or for worse.
526.66s - 529.54s |  And that really drives a lot of this stuff.
529.54s - 531.50s |  So, there's a couple components you need to understand
531.50s - 532.62s |  about access control.
532.62s - 534.74s |  And if you've been doing any of this stuff at all,
534.74s - 537.10s |  you probably already know about this,
537.10s - 539.38s |  but we'll give you the building blocks anyway.
539.38s - 542.22s |  So, we have cards, we have readers,
542.22s - 545.62s |  we have door hardware, like an electric strike or latch,
545.62s - 547.68s |  and we have door controller of some kind.
547.68s - 551.42s |  This is an embedded device that controls access.
551.42s - 553.38s |  It's what makes the logical decision.
553.38s - 555.42s |  And of course, it has a database of some kind
555.42s - 558.10s |  that it synchronizes with and connects to.
558.10s - 562.50s |  And ultimately, the sequence diagram, the way it works,
562.50s - 565.78s |  is we have, we'll zoom in here.
565.78s - 567.82s |  So, we have a card presentation.
567.82s - 569.88s |  So, that's you presenting your card.
569.88s - 571.94s |  The reader activates it.
571.94s - 574.94s |  And then some weekend data is retrieved from the card.
574.94s - 576.36s |  It's sent to the reader.
576.36s - 577.86s |  The reader goes ahead and grabs that
577.86s - 580.06s |  and sends it to all the way to the controller.
580.06s - 581.50s |  That's what that beep is.
581.50s - 583.10s |  And then the controller makes a decision.
583.10s - 586.02s |  And if you have access, it activates the relay.
586.02s - 588.14s |  And that's basically it.
588.14s - 589.96s |  But for this talk, we're not gonna talk
589.96s - 591.24s |  about the back half of that.
591.24s - 593.08s |  We're really only just gonna focus
593.08s - 595.60s |  on that first part, card to reader,
595.60s - 597.16s |  because that's such a critical aspect,
597.16s - 600.68s |  and it's oftentimes the most exposed element
600.68s - 602.66s |  of the access control system.
602.66s - 604.32s |  And we'll see all the ways that people
604.32s - 605.36s |  have tried to do it right,
605.36s - 607.56s |  and still, sometimes, you struggle.
608.56s - 610.00s |  So, what is WGAN data?
610.00s - 611.64s |  This is something that's important to understand
611.64s - 612.52s |  about access control,
612.52s - 615.16s |  if you haven't had to deal with it before.
615.16s - 619.28s |  WGAN data is a static binary authentication string
619.28s - 623.08s |  that represents a very simple series of numbers.
623.08s - 625.68s |  You got your facility code, you got a card number,
625.68s - 628.48s |  and you also have a set of rules that are used
628.48s - 631.04s |  to encode these into a static binary string,
631.04s - 632.76s |  and that's called the bit format.
632.76s - 634.50s |  And we don't need to get into the details of it.
634.50s - 636.48s |  All you gotta know is that it's a little
636.48s - 637.52s |  static binary string.
637.52s - 639.68s |  We'll talk about that more in a little bit.
640.60s - 642.92s |  There is a difference, though, technically,
642.92s - 644.16s |  if you wanna get technical about it,
644.16s - 648.70s |  I suspect you all do, between a card and a credential.
648.70s - 651.86s |  See, RFID cards of any kind
651.86s - 654.18s |  are really just memory storage devices.
654.18s - 656.22s |  Like a USB stick, but a lot shittier.
657.86s - 659.64s |  They don't become a credential
659.64s - 662.86s |  until you put access control data on it.
662.86s - 664.90s |  And so, technically, these two concepts
664.90s - 666.94s |  are discrete concepts.
666.94s - 668.58s |  So, something to keep in mind.
668.58s - 670.38s |  The technology is different
670.38s - 673.70s |  from how you put data on that technology.
673.70s - 675.14s |  And if you really think about it,
675.14s - 678.18s |  we think that all fundamental aspects
678.66s - 680.58s |  of access control can be boiled down
680.58s - 683.06s |  into either an encode or decode operation.
683.06s - 685.34s |  Storage or retrieval.
685.34s - 687.06s |  So, let's talk about how storage works.
687.06s - 689.96s |  How do we make that credential in the first place?
689.96s - 693.18s |  How do we go from card to credential?
693.18s - 695.98s |  Well, you can see we have a facility code
695.98s - 700.54s |  and card number that goes into some set of rules
700.54s - 703.46s |  called the bit format, and you produce WGAN data.
703.46s - 707.00s |  And that WGAN data is then stored on the card.
707.00s - 710.30s |  If you're having trouble visualizing this, let's show you.
710.30s - 713.60s |  So, for example, let's say we have a facility code
713.60s - 715.70s |  of 42 that we want to encode.
715.70s - 718.02s |  We'll go ahead and grab our handy dandy calculator,
718.02s - 720.68s |  and we'll convert that decimal to binary.
720.68s - 723.60s |  So, that'll give us these eight bits here.
723.60s - 725.22s |  Then we have our unique card number.
725.22s - 728.72s |  That's, of course, 1337, obviously.
728.72s - 731.60s |  And we'll go ahead and convert that to binary as well.
731.60s - 733.52s |  And what you see at the bottom left there,
733.52s - 734.60s |  that's the bit format.
734.60s - 736.92s |  That defines where these bits go
736.92s - 738.84s |  in that long string.
738.84s - 740.80s |  So, we'll go ahead and take the facility code
740.80s - 741.64s |  and card number.
741.64s - 744.60s |  We'll drop that into our bit format,
744.60s - 746.40s |  do some parity bit calculations
746.40s - 747.90s |  that we don't need to get into,
747.90s - 749.72s |  and that is our authentication string.
749.72s - 752.38s |  That's what the door controller is actually waiting for.
752.38s - 753.68s |  And depending on the credential,
753.68s - 755.56s |  we might have to add a preamble to it,
755.56s - 758.10s |  but then that whole blob gets written to the card.
758.10s - 759.12s |  That's it.
759.12s - 761.48s |  That's what a credential basically is.
761.48s - 766.04s |  Very simple, static data stored on a memory device.
766.04s - 768.16s |  Similarly, when you're reading a card,
768.16s - 769.88s |  it's just that in reverse.
769.88s - 771.48s |  So, you have your card memory.
771.48s - 773.52s |  You gotta get in there, get it out.
773.52s - 775.36s |  That's what the reader does.
775.36s - 777.32s |  And then, whoop, went too fast.
777.32s - 780.27s |  My apologies.
780.27s - 781.71s |  Too fast for my own good.
781.71s - 783.23s |  There we go.
783.23s - 785.07s |  Encode, da-da, okay.
785.07s - 786.91s |  So, the reader grabs that credential data,
786.91s - 788.83s |  it transmits it to the door controller,
788.83s - 790.79s |  and now the controller has to interpret it.
790.79s - 792.23s |  So, what does that look like?
792.23s - 794.21s |  I'm so glad you didn't ask.
794.21s - 795.27s |  So, here's our credential.
795.27s - 796.81s |  We present it to the reader.
796.81s - 799.79s |  The reader grabs that credential data, retrieves it,
799.79s - 802.33s |  it processes it, rips out that preamble,
802.33s - 804.53s |  sends the WGAN to the door controller,
804.53s - 807.53s |  and now that door controller interprets that data,
807.53s - 810.37s |  breaks it back apart into its constituent components,
810.37s - 811.81s |  and we have, of course,
811.81s - 814.05s |  our original facility code and card number.
814.05s - 814.89s |  Very simple.
814.89s - 816.89s |  Happens in the blink of an eye.
816.89s - 818.41s |  So, in this example,
818.41s - 821.19s |  we're talking about unauthenticated cards.
821.19s - 823.25s |  You'll notice in this diagram,
823.25s - 824.65s |  there was no password needed
824.65s - 826.73s |  to do either of these operations.
827.45s - 829.89s |  If you guys have ever used a prox credential
829.89s - 831.77s |  or old school credential,
831.77s - 835.79s |  if you've used a flipper to clone low frequency tag,
835.79s - 837.85s |  that's the type of card we're talking about.
837.85s - 840.37s |  These are cards that don't require
840.37s - 842.45s |  any security or authentication
842.45s - 845.09s |  in order to read that data off of it.
845.09s - 847.15s |  So, you'll see in the sequence diagram,
847.15s - 848.49s |  you present the card,
848.49s - 850.17s |  the reader powers it on,
850.17s - 851.61s |  it spits out the data,
851.61s - 852.87s |  the reader takes the data,
852.87s - 854.57s |  and then forwards it to the controller.
854.57s - 855.85s |  Simple as that.
855.85s - 857.93s |  But if you have unauthenticated credentials,
857.93s - 859.17s |  you have, of course,
859.17s - 861.53s |  unauthenticated problems.
861.53s - 862.69s |  Generally speaking,
862.69s - 863.53s |  this is an issue
863.53s - 865.81s |  because there's no protection for the data at rest,
865.81s - 867.83s |  there's no protection for the data in motion,
867.83s - 868.67s |  and as a result,
868.67s - 870.45s |  it's very easy to tamper with that data,
870.45s - 872.95s |  it's very easy to clone that data.
872.95s - 874.77s |  So, what's the solution?
874.77s - 876.21s |  Authentication, right?
876.21s - 877.63s |  Easy enough.
877.63s - 880.09s |  So, we can add an authentication layer in.
880.09s - 881.57s |  You'll notice, right over here,
881.57s - 882.99s |  we added a little, boop,
882.99s - 884.77s |  mutual authentication.
884.77s - 887.87s |  So now, in order for us to access that memory
887.87s - 889.59s |  for reading or for writing,
889.59s - 892.01s |  we have to authenticate with that card.
892.01s - 893.13s |  Simple enough.
893.13s - 895.17s |  We can even go a step further,
895.17s - 897.09s |  and we can, before writing that data,
897.09s - 898.31s |  we can encrypt it,
898.31s - 899.73s |  and put it on the card.
899.73s - 900.81s |  And that's what we call, actually,
900.81s - 902.17s |  transport encryption.
902.17s - 904.33s |  And it also adds another step,
904.33s - 905.45s |  right there.
905.45s - 908.65s |  So now, the reader has to authenticate with the card,
908.65s - 909.69s |  unlock it,
909.69s - 911.47s |  grab the encrypted data,
911.47s - 913.13s |  and now it has to then decrypt it,
913.13s - 915.37s |  usually with a different key,
915.37s - 917.51s |  and then get the WGAN data,
917.51s - 919.29s |  send it to the controller.
919.29s - 922.89s |  So, this is the cornerstone of modern access control,
922.89s - 925.21s |  in terms of how RFID cards work,
925.21s - 926.41s |  but of course,
926.41s - 929.61s |  mo security, mo problems, my friends, right?
929.61s - 931.57s |  Because if you have keys that you gotta use,
931.57s - 933.29s |  you have to manage those keys.
933.29s - 935.49s |  They have to be generated appropriately.
935.49s - 937.57s |  They have to be stored properly.
937.57s - 940.05s |  And, of course, you have to use them correctly.
940.05s - 941.89s |  If you write them down on a Post-it,
941.89s - 944.49s |  or, say, put them in an Android app, mobile app,
944.49s - 945.43s |  and not realize it,
945.43s - 947.33s |  and people disassemble it and find it,
947.33s - 949.33s |  that's kind of a problem.
949.33s - 950.81s |  We can also go a step further,
950.81s - 953.29s |  and we're just touching on this topic very lightly.
953.29s - 955.51s |  If we wanna make sure that we don't put the same key
955.51s - 956.49s |  in every card,
956.49s - 959.07s |  we can, of course, do diversification.
959.07s - 962.99s |  So, a key diversification function,
962.99s - 965.69s |  or KDF, as it's colloquially referred to,
965.69s - 968.37s |  basically takes a secret master key,
968.37s - 970.81s |  some sort of unique value tied to the credential,
970.81s - 972.81s |  like a CSN or UID,
972.81s - 975.97s |  and sometimes an optional salt or piece of context,
975.97s - 977.69s |  and that goes into the KDF,
977.69s - 979.73s |  and what comes out is a unique key
979.73s - 982.45s |  that is just for that credential and nothing else.
983.53s - 984.81s |  And that's a pretty solid system.
984.81s - 986.13s |  That's the best practice,
986.13s - 989.21s |  and almost every vendor follows it these days.
989.21s - 992.25s |  Now, you might wonder how are these master keys generated?
992.25s - 993.21s |  How are they used?
993.21s - 995.61s |  Because any of you who have ever bought
995.61s - 998.17s |  access control systems or used them,
998.17s - 1000.05s |  you may not realize or may not have thought
1000.05s - 1002.85s |  that you don't actually get to pick that key.
1002.85s - 1006.17s |  Generally speaking, these keys fall into two categories,
1006.17s - 1010.63s |  and that's shared master keys and custom master keys.
1010.63s - 1012.45s |  So, with a shared master key,
1012.45s - 1014.29s |  these are cards and readers
1014.29s - 1016.75s |  that are interoperable by default.
1016.75s - 1019.01s |  You buy the card, you buy the reader, and it just works.
1019.01s - 1019.85s |  It's great.
1019.85s - 1020.93s |  It's great for integrators.
1020.93s - 1022.53s |  It's great for customers.
1022.53s - 1024.37s |  It's really fast and easy to install,
1024.37s - 1026.13s |  and of course, because it's so easy,
1026.13s - 1027.95s |  that means your cost is lower.
1027.95s - 1030.91s |  But maybe you got special security needs
1030.91s - 1033.19s |  and you want a custom key,
1033.19s - 1035.83s |  and so now a unique key is generated for you,
1035.83s - 1036.99s |  and someone has to manage it.
1036.99s - 1039.31s |  Maybe it's you, maybe it's your vendor.
1039.31s - 1041.47s |  And of course, if you do that, though,
1041.47s - 1044.79s |  now you need to order those cards and those credentials
1044.79s - 1047.11s |  and those readers on demand.
1047.11s - 1049.35s |  They have to program specifically for you.
1049.35s - 1051.23s |  Because of this extra step,
1051.23s - 1053.03s |  this is a process and a technology
1053.03s - 1055.55s |  that is kind of poorly understood.
1055.55s - 1058.19s |  A lot of integrators don't really like to do this
1058.19s - 1060.59s |  because it kind of gets in the way of the process.
1060.59s - 1064.03s |  It's something that's confusing for a lot of customers.
1064.03s - 1067.11s |  And ultimately, it really slows down the process as well,
1067.11s - 1068.91s |  which people, of course, don't like.
1069.99s - 1071.31s |  But no matter what you do,
1071.31s - 1073.91s |  whether you use unauthenticated credentials
1073.91s - 1075.47s |  or authenticated credentials,
1075.47s - 1077.95s |  or ones with encryption, whenever it is,
1077.95s - 1081.31s |  the reader still outputs WeGand,
1081.31s - 1083.35s |  which is really interesting.
1083.39s - 1086.71s |  But we're not gonna get too far down that path today.
1086.71s - 1088.27s |  Before we continue further,
1088.27s - 1092.19s |  we wanted to share with you a little bit of context.
1092.19s - 1093.83s |  As any of you guys know,
1093.83s - 1096.39s |  who've ever learned any of this stuff,
1096.39s - 1099.39s |  played with anything, done anything even remotely hackery,
1099.39s - 1102.35s |  we all stand on the shoulders of giants before us
1102.35s - 1106.63s |  that have paved the way before for us to learn from
1106.63s - 1108.31s |  and then build on top of that.
1108.31s - 1110.03s |  And this is no exception.
1110.03s - 1113.83s |  In our opinion, one of the big pieces of research
1113.83s - 1115.79s |  that really kind of set us on this path
1115.79s - 1120.11s |  started back in 2011, 2010 rather,
1120.11s - 1124.39s |  when Milos released his paper, Heart of Darkness.
1124.39s - 1127.43s |  And it was one of the first really interesting ways
1127.43s - 1130.55s |  of compromising sensitive cryptographic key material
1130.55s - 1133.15s |  that was supposed to be kept secure in the reader
1133.15s - 1137.03s |  and doing it in a really, really innovative way.
1137.03s - 1139.47s |  Nick, what do you wanna say about this?
1144.10s - 1147.54s |  Yeah, so the predecessor to the system
1147.54s - 1150.06s |  that we're gonna talk about today, iClass,
1150.06s - 1152.58s |  was introduced in 2002.
1152.58s - 1156.22s |  And for quite a while, it was a relatively secure system.
1156.22s - 1157.74s |  It used a modern credential.
1157.74s - 1162.74s |  It had authentication keys.
1162.74s - 1164.50s |  It had encryption keys.
1164.50s - 1166.58s |  It was a relatively secure implementation.
1166.58s - 1170.66s |  But use of cheaper hardware
1170.66s - 1173.18s |  and inadequate key protection
1173.54s - 1176.14s |  ultimately led to the recovery of those keys
1176.14s - 1177.90s |  that made the system secure.
1177.90s - 1181.34s |  So it was originally based on an inside-secure
1181.34s - 1185.50s |  or inside-contactless at the time PicoPath chip.
1185.50s - 1189.62s |  And it was mainly popular in North America.
1189.62s - 1191.50s |  It saw some penetration in other markets,
1191.50s - 1193.78s |  but it was primarily in North America.
1195.22s - 1197.38s |  iClass legacy credential looks like this
1197.38s - 1199.66s |  from a memory map perspective.
1199.66s - 1202.86s |  There are unencrypted variants or encrypted variants.
1203.54s - 1205.74s |  And funnily enough, the credential itself
1205.74s - 1207.90s |  or the card itself controls whether or not
1207.90s - 1210.58s |  it's encrypted or plain text.
1214.30s - 1215.66s |  Nope, it's gonna switch on.
1216.70s - 1217.82s |  Yeah, so.
1219.18s - 1220.78s |  It's all right.
1220.78s - 1221.62s |  Yeah.
1222.78s - 1225.94s |  So you see like two examples here
1225.94s - 1228.90s |  of an encrypted card and an unencrypted card.
1228.90s - 1232.14s |  Suffice to say that having the credential itself
1232.14s - 1233.78s |  specify whether it's encrypted or not
1233.78s - 1235.50s |  might not be the best idea.
1235.50s - 1237.78s |  But the hardware for this ecosystem
1237.78s - 1239.30s |  was a few different revisions.
1239.30s - 1241.10s |  There was Rev A, B, and C.
1241.10s - 1244.70s |  B really wasn't in the channel very long.
1244.70s - 1247.38s |  There's not a lot of customers with Rev B readers.
1247.38s - 1251.02s |  But Milosz selected Rev A readers as a target
1251.02s - 1252.46s |  because it's the earlier generation.
1252.46s - 1254.42s |  There might be some bugs.
1254.42s - 1256.54s |  That's a typical thing for hardware hackers to do
1256.54s - 1258.70s |  is select an earlier revision.
1258.74s - 1263.66s |  Milosz used a relative commodity PIC microcontroller,
1263.66s - 1268.66s |  which was not hard against attacks that Milosz performed.
1268.70s - 1272.06s |  So when I-Class was introduced,
1272.06s - 1275.46s |  this is where the concept of the shared standard keys
1275.46s - 1280.10s |  and what the vendor calls elite keys was introduced.
1280.10s - 1283.14s |  So most customers went with a standard key option.
1283.14s - 1286.46s |  Elite keys were for customers that had
1286.50s - 1289.18s |  or were concerned about advanced threats
1289.18s - 1291.90s |  so that their cards wouldn't work on other readers
1291.90s - 1293.58s |  and vice versa.
1293.58s - 1297.26s |  So those cards and readers are built to order.
1297.26s - 1299.10s |  Customers don't actually get to choose that key.
1299.10s - 1300.22s |  It's chosen for you.
1300.22s - 1301.98s |  There's some good research about that
1301.98s - 1303.62s |  we'll talk about later.
1303.62s - 1306.90s |  But it was, elite is probably one of the,
1306.90s - 1311.54s |  if not the most prominent vendor-managed key program
1311.54s - 1314.86s |  that exists in the access control space.
1314.86s - 1319.86s |  So in this ecosystem, there was an encoder,
1320.34s - 1322.82s |  and that encoder had some use cases
1322.82s - 1327.58s |  for stored value applications, vending, things like that.
1327.58s - 1330.10s |  And it was just another reader that had an interface
1330.10s - 1331.78s |  that you could connect to with your PC
1331.78s - 1333.86s |  and talk to it with a protocol.
1333.86s - 1336.86s |  But this is what Milosz targeted for his research.
1336.86s - 1341.22s |  And his research, the paper's titled Heart of Darkness,
1341.22s - 1343.66s |  it relied on using two readers.
1343.66s - 1346.46s |  It was a destructive attack against each one.
1346.46s - 1350.78s |  With the first reader, you would erase the boot block
1350.78s - 1353.18s |  because the debug interface would let you do
1353.18s - 1354.42s |  some limited things.
1354.42s - 1356.98s |  And in that erased boot block,
1356.98s - 1361.34s |  he wrote a dumper program to dump the rest of the memory.
1361.34s - 1364.98s |  And then on the second reader, he did the opposite.
1364.98s - 1367.82s |  He erased the end part of the memory
1367.82s - 1370.42s |  and wrote the dumper program at the very end,
1370.42s - 1372.22s |  which then looped back around
1372.22s - 1373.78s |  and got the first bit that he didn't have
1373.78s - 1375.10s |  from the first reader.
1375.10s - 1378.82s |  So this led to a complete recovery of the firmware
1378.82s - 1382.10s |  and all associated data with that system.
1382.10s - 1385.50s |  Let's see if this might, oh, way too loud this time.
1385.50s - 1388.26s |  All right, just a quick add.
1388.26s - 1391.58s |  One thing that I found really cool about this attack
1391.58s - 1394.82s |  is that this chip technically had read protection.
1394.82s - 1397.74s |  So they thought the keys were secure,
1397.74s - 1401.26s |  but he found a very innovative way to get his code
1401.30s - 1405.42s |  to run inside the chip without erasing the rest of it.
1405.42s - 1408.38s |  And he found, quite by accident,
1408.38s - 1411.54s |  that code running inside the microprocessor
1411.54s - 1413.94s |  was kind of behind the firewall, so to speak.
1413.94s - 1415.94s |  And so it was able to then get access
1415.94s - 1418.06s |  to those re-protected areas of memory.
1418.06s - 1420.78s |  And that basic concept of,
1420.78s - 1422.98s |  I don't have access to that thing,
1422.98s - 1424.70s |  so I'm gonna find something else
1424.70s - 1426.14s |  that has access to that thing
1426.14s - 1428.30s |  and try to manipulate my way in,
1428.30s - 1431.66s |  that is so critical to so many different aspects of hacking.
1431.66s - 1433.02s |  Yeah, exactly.
1433.02s - 1437.54s |  So once you actually have that extracted firmware and data,
1437.54s - 1439.50s |  you can start to look through it.
1439.50s - 1441.42s |  You kind of have broken the chain of custody.
1441.42s - 1444.86s |  You now have those keys that were meant to be kept secret.
1444.86s - 1448.30s |  And through analysis, it ultimately revealed
1448.30s - 1451.42s |  the algorithms that were used by the platform.
1451.42s - 1453.62s |  It prompted a lot of subsequent research
1453.62s - 1455.18s |  over the next couple of years,
1455.18s - 1458.94s |  and primarily by a handful of European researchers.
1458.94s - 1463.30s |  There are some really interesting cryptanalysis talks.
1463.30s - 1466.02s |  There's a few of the papers that are listed here.
1466.02s - 1467.42s |  Fantastic reads.
1467.42s - 1469.42s |  These are deep, math-heavy papers,
1469.42s - 1482.34s |  so I'll be frank, it's over my head a lot of the time.
1482.34s - 1484.38s |  Testing one, two, there we go.
1484.38s - 1487.62s |  So yeah, this is truly next-level research.
1487.62s - 1490.10s |  And from a failure perspective,
1490.10s - 1491.98s |  choosing a commodity microcontroller,
1492.02s - 1494.18s |  even with reprotection,
1494.18s - 1497.86s |  is not necessarily the proper key protection mechanism
1497.86s - 1499.14s |  that you'd want for a system like this,
1499.14s - 1501.58s |  especially if you've got standard or shared keys
1501.58s - 1505.98s |  across all sorts of customers, potentially globally.
1505.98s - 1510.98s |  So with the data integrity portion of this,
1511.26s - 1513.50s |  it being optional and controlled by the card,
1513.50s - 1516.86s |  also maybe not the best security decision.
1516.86s - 1518.66s |  If customers want encryption,
1518.66s - 1520.10s |  they should be able to specify that on the reader,
1520.10s - 1521.46s |  not the credential.
1522.42s - 1527.42s |  And one other issue that plagues this platform,
1527.54s - 1530.94s |  not just this vendor, but just in this industry as a whole,
1530.94s - 1534.74s |  is firmware upgrades or updating devices in the field.
1534.74s - 1538.18s |  If you take these readers and they're at your doors,
1538.18s - 1540.14s |  if you have five doors, it's not much of a problem,
1540.14s - 1542.90s |  but if you have 50,000 doors with readers
1542.90s - 1545.06s |  that are spread out across the globe,
1545.06s - 1545.98s |  if you wanna update those
1545.98s - 1547.74s |  and you have to go to each one of them,
1547.74s - 1549.30s |  that's quite the task.
1549.30s - 1552.10s |  So centralized updates are an issue
1552.10s - 1553.58s |  just kind of industry-wide
1553.58s - 1556.54s |  that we're hoping to get some attention on
1556.54s - 1558.58s |  in the next couple of years,
1558.58s - 1560.94s |  product advancements and whatnot.
1560.94s - 1562.82s |  And I think one of the really interesting things
1562.82s - 1564.34s |  to understand and take away from this,
1564.34s - 1567.82s |  if you're not familiar with any of this technology already,
1567.82s - 1572.82s |  is that even though they had this encryption layer
1572.90s - 1576.70s |  on there as well, what people found
1576.70s - 1579.02s |  is that once you have the authentication key,
1579.74s - 1582.30s |  you didn't even have to decrypt it in order to clone it
1582.30s - 1584.30s |  because there was no validation
1584.30s - 1587.94s |  of which card that data belonged to.
1587.94s - 1590.54s |  So you could actually just take one card,
1590.54s - 1593.94s |  unlock it, grab the encrypted blob of data,
1593.94s - 1595.22s |  throw it onto another one,
1595.22s - 1598.78s |  and even though the serial number of that card was different,
1598.78s - 1600.90s |  it would still work,
1600.90s - 1603.78s |  which really kind of undermined
1603.78s - 1605.10s |  a lot of the integrity of the data.
1605.10s - 1607.18s |  So when we talk about data tampering,
1607.18s - 1609.54s |  that's what we're talking about.
1609.54s - 1611.78s |  And it's a critical aspect that you'll see coming up
1611.78s - 1613.18s |  as a theme over and over.
1613.18s - 1614.02s |  Yep.
1614.02s - 1617.82s |  And as a result of this research,
1617.82s - 1621.10s |  it actually led to a really cool new platform,
1621.10s - 1623.50s |  really the rebirth of iClass.
1623.50s - 1625.58s |  And to talk to you about that,
1625.58s - 1644.78s |  I'd like to have Aaron come up, if you're willing.
1644.78s - 1647.38s |  We have a phoenix rising from the ashes here.
1647.38s - 1650.38s |  It's truly a next generation, next level platform.
1651.38s - 1654.30s |  Yeah, I mean, if it looks a little bit dramatic,
1654.30s - 1656.66s |  it's because in many ways you could argue
1656.66s - 1660.02s |  that that original platform really kind of
1660.02s - 1662.54s |  got burned down in a lot of ways.
1662.54s - 1667.26s |  But to HID's credit, they actually came back pretty hard.
1667.26s - 1671.74s |  And when SE came out, it was kind of a BFD.
1671.74s - 1672.82s |  Aaron, tell us about it.
1672.82s - 1677.82s |  Sure, so to replace iClass comes iClass SE.
1681.14s - 1683.06s |  Launched in 2011.
1683.06s - 1687.18s |  Technically it stands for SIO enabled.
1687.18s - 1689.22s |  SIO stands for secure identity objects.
1689.22s - 1693.58s |  Yes, nested, a lot of confusing terminology here.
1693.58s - 1696.66s |  But in short, they got a lot of things right here, right?
1697.54s - 1700.86s |  They, you know, HID clearly learned a lot of lessons
1700.86s - 1702.66s |  of things that went wrong with iClass.
1702.66s - 1705.50s |  And so iClass SE really was, you know,
1705.50s - 1709.30s |  arguably the secure edition, right, of the platform.
1711.22s - 1714.14s |  So it can, you know, this name, iClass SE,
1714.14s - 1716.78s |  refers to three different things.
1716.78s - 1720.62s |  A platform, a reader, a credential technology.
1720.62s - 1723.58s |  There's a lot, you can see how that might be confusing,
1723.58s - 1726.66s |  right, and it has been, right.
1726.66s - 1730.65s |  To this day.
1730.65s - 1732.09s |  Oh, try that, there you go.
1732.09s - 1734.97s |  To this day, there is still an incredible amount
1734.97s - 1739.73s |  of confusion over what iClass SE actually means.
1739.73s - 1742.21s |  And I don't mean just from like everyday users.
1742.21s - 1745.09s |  I mean industry professionals, people who,
1745.09s - 1748.53s |  this is their job, nothing but access control.
1748.53s - 1751.61s |  Selling it, installing it, maintaining it.
1751.61s - 1755.45s |  The phrase iClass SE is very, very nebulous.
1755.45s - 1757.13s |  But when you look at it at a technical level,
1757.13s - 1759.57s |  you can understand why there's so much confusion
1759.57s - 1762.13s |  because they reuse the same name
1762.13s - 1766.41s |  for very different discrete aspects of the technology.
1766.41s - 1769.53s |  So we do our best to separate things out here for you,
1769.53s - 1771.37s |  but it's important to understand
1771.37s - 1773.65s |  that depending on the context
1773.65s - 1776.45s |  in which you invoke the phrase iClass SE,
1776.45s - 1778.61s |  what we're referring to can vary.
1780.37s - 1784.53s |  Indeed, and so one of the interesting things
1784.53s - 1787.85s |  about iClass SE as a reader platform.
1789.45s - 1790.85s |  Closer to the mic.
1790.85s - 1792.61s |  One of the interesting things about iClass SE
1792.61s - 1797.13s |  as a reader platform is that it is very much upgradable.
1797.13s - 1799.41s |  And so, you know, they've added support over the years
1799.41s - 1802.97s |  for newer, other credential technologies, right?
1802.97s - 1804.49s |  Something that was not easily possible
1804.49s - 1806.93s |  with the original iClass reader platform.
1806.93s - 1809.37s |  So right in 2011, right, we had, you know,
1809.37s - 1812.73s |  those four, iClass SE most significantly.
1812.73s - 1815.85s |  2012, we got SEOS, which we'll talk about later.
1815.85s - 1818.97s |  2014, mobile, and so on and so forth.
1820.93s - 1823.73s |  You know, so I mentioned that term before,
1823.73s - 1825.33s |  SIO, secure identity object.
1825.33s - 1827.63s |  So let's talk a little bit about what that is.
1828.63s - 1832.51s |  So with iClass, right, you know,
1832.51s - 1835.75s |  one of the things that Bobak was talking about
1835.75s - 1837.63s |  and Nick as well was the fact
1837.63s - 1841.03s |  that there was nothing to cryptographically bind
1841.03s - 1843.23s |  the encrypted data payload on the card
1843.23s - 1845.55s |  to that particular card.
1845.55s - 1847.39s |  And that's one of the main things
1847.39s - 1850.67s |  that the SIO endeavors to fix, right?
1850.67s - 1855.07s |  So it is an ASN.1 encoded payload.
1855.19s - 1858.23s |  It is cryptographically bound to a specific card, right,
1858.23s - 1860.67s |  by its serial number or UID,
1860.67s - 1862.23s |  and the data in it is encrypted.
1862.23s - 1867.23s |  So in other words, if you take an SIO from one card
1867.35s - 1868.47s |  and you put it on another card
1868.47s - 1871.63s |  with a different serial number, it won't work.
1871.63s - 1873.11s |  And that's a big deal, right?
1873.11s - 1876.87s |  Like that's a big step forward in terms of the security
1876.87s - 1881.87s |  of the SIO-based credential technology, yeah.
1882.71s - 1884.55s |  I wanna clarify just in case,
1884.55s - 1887.55s |  cause it's easy to get lost in the weeds on this
1887.55s - 1889.51s |  if it's a new concept to you.
1889.51s - 1894.51s |  The main gain of an SIO, a secure object of any kind,
1895.71s - 1898.47s |  is not only is the data encrypted,
1898.47s - 1902.71s |  but as he mentioned, it's cryptographically bound.
1902.71s - 1906.43s |  It's tied to something unique and unchangeable
1906.43s - 1910.07s |  about that credential such that if you mess with it,
1910.07s - 1913.55s |  if you tamper with it, you change even one bit of data,
1913.55s - 1915.43s |  it breaks the signature
1915.43s - 1918.59s |  and the reader considers it invalid.
1918.59s - 1923.59s |  It's a very important and critical piece of security.
1925.81s - 1927.17s |  Indeed.
1927.17s - 1930.53s |  So let's talk about the advantages of SIOs.
1930.53s - 1933.45s |  So we already spoke a bit about some of this,
1933.45s - 1935.85s |  but there's a really good sort of way to think of this,
1935.85s - 1939.81s |  which is that an SIO is kind of like a tamper seal, right?
1939.81s - 1942.01s |  If you have the card, right,
1942.01s - 1944.33s |  and the WGAN's data on the card,
1944.33s - 1949.33s |  the SIO is ensuring that, well,
1949.97s - 1951.29s |  effectively it's a tamper seal, right?
1951.29s - 1953.65s |  You can't tamper with it at all.
1953.65s - 1956.29s |  And it's independent of card technology.
1956.29s - 1959.17s |  It's a really overall good design.
1962.10s - 1965.54s |  So the first major technology, right,
1965.54s - 1969.14s |  to talk about with regard to SIOs is I-Class SE, right?
1969.18s - 1974.18s |  So it uses the same card technology as I-Class, right,
1975.26s - 1977.70s |  which is called PicoPass.
1977.70s - 1980.26s |  It was still cost-effective, it was cheap.
1980.26s - 1982.86s |  The silicon wasn't broken, right?
1982.86s - 1984.82s |  It had good read distance.
1984.82s - 1987.70s |  Honestly, a lot of things about I-Class
1987.70s - 1991.18s |  as a card technology were good, at least for the time, right?
1992.10s - 1995.38s |  So I-Class SE essentially took I-Class
1995.38s - 1998.86s |  and made it more or less secure, yeah.
1999.62s - 2000.98s |  If you see I-Class credentials,
2000.98s - 2003.30s |  you can see an SE or an SR marking
2003.30s - 2006.30s |  to indicate that there's an SIO on the card.
2006.30s - 2010.02s |  Yeah, this is one of the first places
2010.02s - 2012.62s |  where you begin to have that confusion, right?
2012.62s - 2016.74s |  We talked about how I-Class SE gets reused over and over.
2016.74s - 2021.30s |  So now we're talking about I-Class SE cards specifically.
2021.30s - 2023.98s |  So they just took the same card technology
2023.98s - 2027.66s |  that they had already, but because their keys were broken
2027.66s - 2030.10s |  and their algorithms were broken, yada, yada, yada,
2030.10s - 2031.26s |  they say, hey, you know what?
2031.26s - 2033.10s |  The container's still not so bad.
2033.10s - 2036.50s |  So why don't we just create a new data model
2036.50s - 2038.94s |  and change our keys and change our algorithms
2038.94s - 2043.58s |  and all those things and basically kind of remix it?
2043.58s - 2045.94s |  And it did pretty well.
2047.58s - 2051.84s |  Indeed, but let's talk a little bit
2051.84s - 2054.32s |  about the limitations of PicoPass, right?
2054.32s - 2057.92s |  The card technology that I-Class is built on, right?
2057.92s - 2059.24s |  It has limited memory.
2060.40s - 2062.92s |  You really only have two application areas,
2062.92s - 2065.72s |  so you can't have too many different uses, right,
2065.72s - 2067.32s |  for an I-Class card.
2067.32s - 2069.32s |  It doesn't have replay protection.
2070.28s - 2074.12s |  There are a number of bugs in terms of reader firmware
2074.12s - 2076.86s |  impacting I-Class and PicoPass specifically.
2078.20s - 2081.36s |  More recently, PicoPass became EOL,
2081.36s - 2085.40s |  and HID actually had to develop a custom IC
2085.40s - 2087.44s |  that emulates PicoPass so they can continue
2087.94s - 2089.04s |  to sell I-Class cards.
2090.64s - 2093.68s |  Challenges of not owning your whole supply chain, right?
2093.68s - 2095.24s |  They bought someone else's chip.
2095.24s - 2097.00s |  They said, hey, we're gonna rebrand this,
2097.00s - 2099.84s |  call it I-Class, and then eventually
2099.84s - 2101.32s |  they stopped making that chip,
2101.32s - 2104.66s |  so they had to emulate it, basically.
2105.76s - 2110.76s |  Indeed, and actually, NVX discovered
2111.52s - 2114.68s |  a really interesting implementation defect
2115.40s - 2118.00s |  in reader firmware having to do with I-Class
2118.00s - 2119.92s |  and is giving a talk called
2119.92s - 2123.08s |  I-Class Throwing Away the Keys on Friday.
2123.08s - 2124.40s |  That's today.
2124.40s - 2125.76s |  Yes, today in our village.
2128.28s - 2129.12s |  Yeah, definitely check it out.
2129.12s - 2130.52s |  We'll watch the talk, yeah.
2130.52s - 2131.80s |  Cool. We're excited.
2131.80s - 2133.84s |  So, let's talk about CEOS.
2133.84s - 2137.80s |  So, CEOS is that card technology that was shown
2137.80s - 2140.88s |  in the initial video at the beginning of the talk.
2140.88s - 2143.72s |  It is HID's flagship to this day.
2143.72s - 2144.80s |  Launched in 2012.
2144.80s - 2147.88s |  Originally, they called it I-Class CEOS,
2147.88s - 2152.56s |  which now may be an interesting decision
2152.56s - 2155.92s |  because I-Class has certain connotations
2155.92s - 2158.62s |  of weakened security, right?
2159.88s - 2162.96s |  But at the time, I-Class was a well-established brand name,
2162.96s - 2166.04s |  so it helped really sell it to their customer base.
2166.04s - 2169.16s |  But CEOS, honestly, it gets a lot of stuff right.
2169.36s - 2172.24s |  This is a really solid credential technology.
2172.24s - 2174.16s |  There's more memory, much better security.
2174.16s - 2176.62s |  It's very much standards-based, right?
2176.62s - 2180.76s |  You don't have a lot of the proprietary algorithms
2180.76s - 2184.20s |  and diversification algorithms and things like that
2184.20s - 2186.04s |  that were being done with I-Class
2186.04s - 2187.76s |  and previous generations of technologies.
2187.76s - 2190.28s |  They made tons of improvements.
2190.28s - 2192.74s |  This was like the Rolls-Royce of credentials
2192.74s - 2197.74s |  when it came out, and the price reflects that,
2198.02s - 2199.02s |  as you can see.
2200.10s - 2202.30s |  But it had a lot of cool stuff,
2202.30s - 2207.30s |  and it wasn't really big on adoption initially
2207.50s - 2208.98s |  because of the cost,
2208.98s - 2212.06s |  but now it's actually very, very cost-effective
2212.06s - 2215.62s |  because they've had like 10 years plus to optimize it.
2215.62s - 2216.46s |  Yeah, agreed.
2216.46s - 2220.06s |  And it's also sort of a virtual credential
2220.06s - 2222.34s |  or can be in a sense, right?
2222.34s - 2224.18s |  So CEOS, there are CEOS cards.
2224.18s - 2229.18s |  There are also CEOS virtual cards or mobile cards, right?
2230.14s - 2232.14s |  If you've heard of like HID mobile access
2232.14s - 2234.18s |  or things like that, right?
2234.18s - 2237.70s |  There are all these different form factors, really,
2237.70s - 2239.26s |  where CEOS can exist.
2239.26s - 2241.20s |  So it's extremely portable, extremely well-built.
2241.20s - 2242.04s |  I'd say to this day,
2242.04s - 2244.10s |  it's a very solid credential technology.
2248.08s - 2250.34s |  Now let's talk about support for other technologies
2250.98s - 2254.18s |  within the platform.
2254.18s - 2258.38s |  So SIOs, again, they made things very card agnostic, right?
2258.38s - 2261.62s |  You're not relying on proprietary features of I-Class
2261.62s - 2263.06s |  or really any other credential.
2263.06s - 2267.82s |  An SIO can be applied even to MyFair Classic, right?
2267.82s - 2271.98s |  Another sort of infamously insecure card technology.
2271.98s - 2274.86s |  They're very much future-proof,
2274.86s - 2279.86s |  and yeah, they're an extremely powerful technology.
2280.06s - 2280.90s |  I don't know, Bhavik,
2280.90s - 2283.38s |  if you have anything you want to add or Nick.
2283.38s - 2287.70s |  Yeah, so the neat idea about a secure object
2287.70s - 2289.90s |  is that it's agnostic.
2289.90s - 2292.46s |  So you can take any container you want,
2292.46s - 2296.58s |  whether it's an I-Class PicoPass container
2296.58s - 2298.86s |  or whether it's CEOS or it does fire,
2298.86s - 2303.14s |  whatever flavor of little tiny crappy digital safe
2303.14s - 2304.06s |  that you want to use,
2304.06s - 2306.90s |  you can actually still put this concept
2306.90s - 2308.94s |  of a secure object on there.
2308.94s - 2312.34s |  And so it makes it very extensible and reusable.
2313.42s - 2316.50s |  And it gives them a lot more flexibility
2316.50s - 2319.62s |  because they can control the data model.
2319.62s - 2321.42s |  You can't control as much
2321.42s - 2323.78s |  how the card technology itself behaves in the reader,
2323.78s - 2325.74s |  but that's kind of splitting hairs a little bit.
2325.74s - 2328.94s |  So we don't need to spend too much time on that.
2328.94s - 2331.66s |  But they really did try to intend for this card
2331.66s - 2333.54s |  to be the one card that ruled them all.
2333.54s - 2336.06s |  And they tried to be as forward-thinking as possible.
2336.06s - 2337.66s |  And they really kind of hit that mark
2337.66s - 2339.82s |  in a lot of ways, in my opinion.
2339.82s - 2341.46s |  I agree, I agree.
2341.46s - 2345.46s |  So let's talk about how SE credentials are encoded.
2346.46s - 2350.22s |  So to start, you have to obtain the binding from the card,
2350.22s - 2352.94s |  really the serial number or UID of the card.
2352.94s - 2355.70s |  You have to calculate diversified write keys.
2355.70s - 2360.06s |  You need to generate a unique ID for the secure object
2360.06s - 2364.18s |  and calculate the keys for encrypting the secure object.
2364.18s - 2365.98s |  You gotta encrypt and sign the data.
2366.82s - 2369.26s |  And lastly, you need to authenticate the card
2369.26s - 2373.42s |  with diversified keys and write the SIO to it.
2373.42s - 2377.82s |  And so that brings us to the I-Class SE encoder, right?
2377.82s - 2381.78s |  This is how HID enables customers
2381.78s - 2386.02s |  to encode their own SE, right, SIO-enabled credentials,
2386.02s - 2389.54s |  be that I-Class SE, CEOS, MyFairClassic,
2389.54s - 2393.22s |  you know, with SIO, that's SIO-enabled, et cetera, right?
2393.22s - 2394.70s |  And it came in two form factors,
2394.74s - 2396.66s |  or it comes in two form factors,
2396.66s - 2399.50s |  the desktop encoder as well as
2399.50s - 2402.70s |  an embedded printer-based encoder as well.
2403.58s - 2406.70s |  And it can do a lot of stuff, right?
2406.70s - 2408.74s |  It can encode, you know, primarily, right,
2408.74s - 2410.46s |  it can encode genuine HID cards,
2410.46s - 2414.82s |  but you can also encode third-party cards as well, right?
2414.82s - 2417.22s |  It can, you know, encode prox,
2417.22s - 2418.86s |  lots of different high-frequency credentials,
2418.86s - 2421.70s |  including both CEOS, DesFire, I-Class SE.
2421.70s - 2424.42s |  Yeah, these were pretty cool little tools.
2425.10s - 2427.38s |  Not cheap, very, very expensive,
2427.38s - 2430.10s |  but, you know, if you had a need for it,
2430.10s - 2432.06s |  it really kind of came in clutch.
2432.06s - 2434.42s |  So it allowed you not only to create
2434.42s - 2436.34s |  your own credentials on demand,
2436.34s - 2439.42s |  but also it allowed you to, you know,
2439.42s - 2441.38s |  create custom configuration cards
2441.38s - 2444.02s |  and really enable being able to service
2444.02s - 2446.50s |  your own platform a lot more easily
2446.50s - 2448.54s |  than having to call the vendor every single time.
2448.54s - 2453.10s |  So it definitely filled a very important business need
2453.10s - 2454.42s |  from that perspective.
2455.70s - 2458.50s |  Absolutely, and yeah, configuration cards,
2458.50s - 2460.82s |  that last one there, that's an important one
2460.82s - 2463.42s |  that we're gonna talk about a little more in a bit.
2465.34s - 2467.42s |  But first, let's talk about the target markets for this.
2467.42s - 2469.22s |  Why did HID make this, right?
2469.22s - 2473.38s |  Who's buying this, you know, what is it used for, right?
2473.38s - 2476.50s |  So whether it's customers that have custom keys, right,
2476.50s - 2477.94s |  for various security reasons,
2477.94s - 2480.74s |  or they have a bunch of credentials that they wanna keep,
2480.74s - 2481.66s |  they don't wanna have to buy new ones,
2481.66s - 2483.34s |  but they wanna re-encode them,
2483.34s - 2484.94s |  like put different data on them,
2484.94s - 2486.78s |  or switch from standard to elite.
2487.94s - 2490.30s |  They want to generate their own card numbers
2490.30s - 2492.78s |  that HID doesn't know about, right,
2492.78s - 2495.90s |  or they wanna customize certain reader behavior functionality
2495.90s - 2497.10s |  or load in keys, right,
2497.10s - 2499.00s |  and so they wanna create config cards.
2499.86s - 2502.26s |  A couple of these are a little sneaky in my opinion.
2502.26s - 2504.26s |  So for example, you know,
2504.26s - 2507.62s |  we have customer generated card numbers on there.
2507.62s - 2510.14s |  That is a very specific use case
2510.14s - 2512.34s |  because what you may not realize,
2512.34s - 2514.02s |  or maybe many of you already do realize
2514.02s - 2515.44s |  if you're in this talk,
2515.44s - 2518.42s |  is that by default, when you buy credentials,
2518.42s - 2521.54s |  they are pre-programmed with card numbers
2521.54s - 2523.26s |  and weekend information.
2523.26s - 2528.08s |  So someone else is giving you a box of passwords to use
2528.08s - 2530.50s |  and you assign those passwords.
2530.50s - 2533.50s |  It feels kind of weird sometimes when you think about it.
2533.50s - 2535.90s |  And so what the encoder would allow you to do
2535.90s - 2538.58s |  if you're really super secret squirrel about it,
2538.58s - 2541.14s |  is you could get blank card stock
2541.14s - 2543.86s |  and you could have this encoder either at your desktop
2543.86s - 2546.22s |  or built into your printer,
2546.22s - 2549.46s |  and you can basically generate your own card numbers
2549.46s - 2552.06s |  and then you wouldn't have to worry as much
2552.06s - 2554.02s |  about some third party vendor
2554.02s - 2555.84s |  that you don't have control over
2555.84s - 2558.58s |  knowing those critical bits of information.
2558.58s - 2560.46s |  Of course, that's a lot of overhead too
2560.46s - 2562.34s |  because now you have to manage and remember
2562.34s - 2564.46s |  all the card numbers that you used ever,
2564.46s - 2566.30s |  so you can't repeat it.
2566.30s - 2567.14s |  And in practice,
2567.14s - 2569.30s |  that wasn't a feature that's used very often,
2569.30s - 2572.34s |  but you still need to have that capability there.
2572.34s - 2574.98s |  The other sneaky thing is integrator lock-in.
2574.98s - 2577.14s |  You might be thinking, how does that work?
2577.14s - 2580.02s |  There have been a couple of areas globally
2580.02s - 2583.78s |  where a integrator that has a really strong market presence
2583.78s - 2586.14s |  will say, hmm, you know what?
2586.14s - 2589.42s |  We're gonna get our own custom key
2589.42s - 2591.04s |  and all of our customers,
2591.04s - 2593.28s |  we're gonna issue them readers and cards
2593.28s - 2595.32s |  that use our custom key.
2595.32s - 2597.56s |  And so now, if you're one of their customers
2597.56s - 2600.28s |  and you need more readers or you need more cards,
2600.28s - 2602.42s |  you only got one place you can go
2602.42s - 2604.60s |  in order to get interoperable credentials
2604.60s - 2606.88s |  because only they have the key.
2606.88s - 2609.56s |  So we don't see too much of that in the US,
2609.56s - 2613.08s |  but we did see some of that in Singapore and Australia
2613.08s - 2614.32s |  and a few other places.
2614.32s - 2616.64s |  So it's just really interesting to see how people
2616.64s - 2620.56s |  kind of creatively use some of the features
2620.56s - 2622.20s |  that are offered by the platform.
2622.56s - 2623.64s |  Yeah.
2623.64s - 2625.28s |  Indeed.
2625.28s - 2630.28s |  So the I-Class SE encoder, the CP1000, that's the hardware.
2630.44s - 2633.48s |  Assure ID is the software, right?
2633.48s - 2636.40s |  It doesn't exclusively exist for the CP1000, right?
2636.40s - 2639.52s |  It's used primarily for badge printing, right?
2639.52s - 2642.84s |  But it is the software primarily that is used
2642.84s - 2644.96s |  for credential encoding with the CP1000
2644.96s - 2649.12s |  and it sort of facilitates all of these encoding operations.
2649.12s - 2651.08s |  Yeah, this is the front end.
2651.08s - 2654.00s |  This is the main default user interface
2654.00s - 2657.46s |  for interacting with this piece of hardware.
2657.46s - 2662.46s |  And it is a little bit clunky to use, I'm not gonna lie,
2663.52s - 2665.12s |  but it's kind of the only thing
2665.12s - 2666.68s |  that you have out of the box.
2666.68s - 2669.04s |  Some software vendors,
2669.04s - 2671.18s |  if you have a really large access control system,
2671.18s - 2674.28s |  like say from Linel or Software House,
2675.28s - 2679.00s |  some vendors actually are able to integrate pieces
2679.00s - 2680.96s |  of this software, the SDK,
2680.96s - 2682.76s |  into their access control software.
2682.76s - 2686.48s |  So as a customer, when you wanted to encode a card,
2686.48s - 2688.48s |  you don't have to load a separate application.
2688.48s - 2691.86s |  You can just do it natively in your application
2691.86s - 2693.32s |  and behind the scenes,
2693.32s - 2697.20s |  it makes the appropriate API calls, yada, yada, yada.
2697.20s - 2701.04s |  So that's how the SDK portion is designed to be used.
2702.08s - 2702.92s |  Indeed.
2704.04s - 2707.24s |  So let's talk about the internal operation of the encoder.
2708.04s - 2710.44s |  Everything in that box,
2710.44s - 2713.48s |  that is inside of the encoder itself,
2713.48s - 2715.78s |  which also happens to be rectangular in shape.
2717.12s - 2718.96s |  So you have the desktop here,
2718.96s - 2722.48s |  essentially the Assure ID software in normal operations,
2722.48s - 2725.20s |  that talks to core, which acts as a router
2725.20s - 2727.50s |  between different components in the encoder,
2727.50s - 2729.52s |  sending messages back and forth,
2729.52s - 2732.56s |  which will send commands to the SAM.
2732.56s - 2736.04s |  SAM will send commands to the NFC front end.
2736.04s - 2737.88s |  NFC front end talks to the credential,
2737.88s - 2741.42s |  and that's sort of the overall block diagram
2741.42s - 2742.66s |  of how encoding works.
2744.56s - 2747.92s |  And these encoders, they're very customizable,
2747.92s - 2749.04s |  they're very flexible.
2749.04s - 2751.64s |  You can use different types of keys with them.
2752.68s - 2755.24s |  One sort of interesting thing is that
2755.24s - 2758.68s |  HID does sell these encoders,
2758.68s - 2761.24s |  but they're not unlimited use.
2761.24s - 2763.36s |  They actually have a credit system
2763.36s - 2764.90s |  where when you buy an encoder,
2764.90s - 2766.94s |  you can only encode a certain number of cards
2766.94s - 2768.42s |  of different credential types with it.
2768.42s - 2769.26s |  It's super sneaky.
2769.26s - 2772.22s |  You spend $1,500 or $2,000 on an encoder,
2772.22s - 2774.46s |  you're like, cool, I can make as many cards as I want,
2774.46s - 2775.30s |  right?
2775.30s - 2776.14s |  Nope!
2777.42s - 2779.42s |  Indeed, indeed.
2779.42s - 2782.22s |  You can make 30 configuration cards.
2782.22s - 2784.10s |  Out of the gate, yes.
2784.10s - 2785.56s |  Only 30, yes.
2787.98s - 2790.54s |  So now let's talk about the reader side of things.
2790.54s - 2791.74s |  So the iClass SE reader,
2791.74s - 2794.38s |  it's generally what we call revision e-readers.
2794.38s - 2797.14s |  Technically, there are some revision d-readers
2797.14s - 2799.94s |  that came before it, although they're very rare.
2799.94s - 2802.14s |  They can be ran as iClass SE, multi-class SE,
2802.14s - 2803.26s |  and a few other things.
2803.26s - 2805.70s |  They come in all kinds of different form factors.
2807.90s - 2810.42s |  But I can guarantee that most of the people
2810.42s - 2812.14s |  in this audience have seen at least one.
2812.14s - 2814.54s |  Yeah, it's the same piece of hardware internally.
2814.54s - 2817.10s |  It's just marked up differently with different stickers
2817.10s - 2819.94s |  and different software configurations.
2819.94s - 2822.84s |  And of course, they make them in different sizes and shapes,
2822.84s - 2825.92s |  but the primary circuitry and the design of it
2825.92s - 2827.88s |  is still all the same.
2827.88s - 2831.68s |  Yeah, so let's talk about how things are decoded, right?
2833.54s - 2836.28s |  So in short here, what's happening is that
2838.28s - 2841.08s |  once the card is pulling back
2841.08s - 2844.12s |  or reading the encrypted data blob,
2844.12s - 2846.00s |  now the SIO from the card,
2846.00s - 2847.60s |  first it's doing a signature check, right?
2847.60s - 2850.28s |  Making sure that the data hasn't been tampered with.
2850.28s - 2852.00s |  Then it's decrypting the data,
2852.00s - 2853.60s |  and then it's parsing the weekend data,
2853.60s - 2855.52s |  that same weekend data that Babak
2855.52s - 2857.48s |  was talking about earlier, right?
2857.48s - 2860.00s |  That everything else is sort of a wrapper around,
2860.00s - 2862.56s |  and sending it back to the door controller,
2862.56s - 2864.16s |  which will ultimately decode it
2864.16s - 2867.56s |  and make a sort of a go, no-go,
2867.56s - 2869.76s |  or an allow slash deny decision.
2876.04s - 2878.36s |  Go ahead, yeah, this is kind of a cool zoomed-in part
2878.36s - 2880.44s |  of what actually happens inside the reader
2880.44s - 2881.96s |  when dealing with an SIO.
2882.92s - 2884.44s |  So what Aaron just explained,
2884.44s - 2887.44s |  the job of that signature check is to see,
2887.44s - 2889.64s |  has that data been modified?
2889.64s - 2892.68s |  Is that data bound to the UID or CSN of the card
2892.68s - 2894.16s |  that it just came off of?
2894.16s - 2897.72s |  So after that step, and only if that step succeeds
2897.72s - 2900.50s |  does it actually do the decryption of that weekend data.
2900.50s - 2902.44s |  And then once it decrypts the weekend data,
2902.44s - 2905.34s |  it does the transmit step, which we all know and love.
2905.34s - 2907.00s |  That's when we hear the beep.
2907.00s - 2911.12s |  And it kind of goes on from there, so yeah.
2911.12s - 2912.60s |  Thanks.
2912.60s - 2915.08s |  So, migration modes.
2915.08s - 2918.28s |  So in the industry, yeah, in the industry,
2918.28s - 2922.40s |  there's a type of reader called migration readers
2922.40s - 2923.80s |  that are designed to support both old
2923.80s - 2925.32s |  and new technologies, right?
2925.32s - 2927.84s |  And they need to exist, right?
2927.84s - 2930.72s |  Their existence is to help customers move
2930.72s - 2932.54s |  from less secure older technologies
2932.54s - 2934.72s |  to more secure newer ones, right?
2934.72s - 2936.26s |  And so by definition,
2936.26s - 2939.56s |  they have to support multiple credential types.
2939.56s - 2941.52s |  And the most common one you'll see in the field
2941.52s - 2944.68s |  is probably the multi-class SE reader from HID.
2944.68s - 2946.36s |  It's literally the Swiss Army knife of readers.
2946.36s - 2949.42s |  It reads pretty much all of the common technologies.
2950.70s - 2953.80s |  And even though they aren't always needed by customers,
2953.80s - 2956.80s |  a lot of times, integrators will install these
2956.80s - 2959.76s |  and stock these because they always work, right?
2959.76s - 2962.30s |  If you have to keep, if there's only one kind of reader
2962.30s - 2963.80s |  you can keep in stock, right,
2963.80s - 2968.64s |  to be able to sell to your customers, your clients, right,
2968.64s - 2970.20s |  it stands to reason a lot of people are gonna go
2970.20s - 2971.80s |  with the one that always works.
2971.80s - 2974.24s |  And that is indeed what happens a lot of the time.
2974.24s - 2976.64s |  It always works is a big problem in the industry,
2976.64s - 2978.02s |  not just with readers.
2978.02s - 2980.14s |  So not only do we have these readers
2980.14s - 2982.26s |  that can read all these different card technologies,
2982.26s - 2984.28s |  you're like, oh, that's great.
2984.28s - 2985.30s |  It's very flexible.
2985.30s - 2986.24s |  It's always gonna work.
2986.24s - 2987.08s |  That's awesome.
2987.08s - 2991.04s |  Except it also really undermines how access control works.
2991.04s - 2992.76s |  Similarly, on the hardware side,
2992.76s - 2994.44s |  when it comes to electric strikes
2994.44s - 2996.82s |  and the door hardware that goes in the door,
2996.82s - 2999.94s |  if you've ever slipped a latch with a card
2999.94s - 3000.94s |  or anything like that,
3000.94s - 3004.22s |  that's because that strike is either misadjusted
3004.22s - 3008.14s |  or also very likely sometimes way too darn big
3008.14s - 3009.66s |  for the actual latch.
3009.66s - 3011.82s |  And as a result, those deadlatch mechanisms
3011.82s - 3013.78s |  don't actually work properly.
3013.78s - 3018.42s |  But if they only carry one part that's just really big
3018.42s - 3020.14s |  and it just works with everything,
3020.14s - 3022.78s |  then it's just a lot easier for that integrator as well
3022.78s - 3025.86s |  and they probably get a better price on it too.
3025.86s - 3028.70s |  Indeed, and these migration readers open the door
3028.70s - 3030.38s |  for so-called downgrade attacks,
3030.38s - 3032.98s |  credential downgrade attacks, right?
3032.98s - 3035.78s |  Because as we discussed earlier, right,
3035.78s - 3037.50s |  at the end of the day,
3037.50s - 3039.30s |  everything else is sort of just a wrap around
3039.30s - 3042.02s |  that WGAN's data that Babak was talking about earlier.
3042.02s - 3043.90s |  So as long as the right WGAN's data
3043.90s - 3046.26s |  gets sent from the reader to the door controller,
3046.26s - 3047.46s |  it doesn't matter necessarily
3047.46s - 3049.30s |  what the credential technology on the front end is.
3049.30s - 3054.18s |  So you can take WGAN data from a more secure credential
3054.18s - 3055.46s |  that comes out of a reader
3056.06s - 3057.22s |  and put it on a prox credential instead
3057.22s - 3058.50s |  as long as it's supported.
3058.50s - 3060.14s |  And as far as the door controller is concerned,
3060.14s - 3062.98s |  it's the same thing, it's the same person.
3062.98s - 3065.22s |  But we don't wanna bore you too much with this.
3065.22s - 3067.06s |  It's really important stuff.
3067.06s - 3071.30s |  We're gonna wanna get to some more interesting stuff
3071.30s - 3072.14s |  here in a second.
3072.14s - 3074.34s |  But because it's good context,
3074.34s - 3077.50s |  we wanna make sure you have a little bit of it at least.
3077.50s - 3079.10s |  Indeed.
3079.10s - 3083.98s |  So let's talk about the I-Class SE reader modules, right?
3084.02s - 3086.62s |  So not all I-Class SE readers
3086.62s - 3088.86s |  look like a typical I-Class SE reader, right?
3088.86s - 3090.98s |  There are embedded modules where other vendors
3090.98s - 3094.02s |  can actually take this technology, the reader platform,
3094.02s - 3095.46s |  and embed it in something else,
3095.46s - 3096.86s |  something that looks completely different,
3096.86s - 3098.38s |  such as like a biometric reader
3098.38s - 3100.26s |  or something along those lines.
3102.10s - 3105.02s |  So now let's talk about configuration methods
3105.02s - 3105.86s |  for these readers.
3105.86s - 3108.58s |  So it's all SNMPv3 based, right?
3108.58s - 3110.14s |  Which is an interesting choice of protocol,
3110.14s - 3111.70s |  we'll get to in a bit.
3112.30s - 3115.94s |  It's SNMPv3 over APDUs.
3115.94s - 3118.62s |  You can do it over NFC, BLE, OSTP, UART, et cetera.
3118.62s - 3119.82s |  It doesn't matter.
3119.82s - 3121.10s |  And there are a few different ways to do it,
3121.10s - 3123.98s |  but generally, for readers in the field,
3123.98s - 3125.50s |  it's either with config cards
3125.50s - 3128.54s |  or the HID Reader Manager app most of the time.
3130.94s - 3132.98s |  Generally, when it comes to reader...
3133.98s - 3137.02s |  Generally, when it comes to reader configuration,
3137.02s - 3139.50s |  there are a lot of different things that you can do.
3141.90s - 3142.74s |  Right?
3142.74s - 3145.82s |  And these configuration cards specifically
3145.82s - 3148.86s |  were a bit of a new technology with the platform.
3148.86s - 3151.06s |  They're Java card based, right?
3151.06s - 3153.90s |  Also known as the Artemis updater card.
3153.90s - 3158.14s |  And if you encode one with a CP1000 encoder, right?
3158.14s - 3160.38s |  They, you know, they have credits.
3160.38s - 3163.10s |  Ones from the factory have unlimited credits.
3163.10s - 3164.34s |  Yeah.
3164.34s - 3168.90s |  In short, HID config cards are the same as the Java,
3168.90s - 3170.22s |  or the same technology, right?
3170.22s - 3172.98s |  They're Java cards, like a J3D081,
3172.98s - 3175.58s |  just like many EMV bank cards, credit cards, et cetera,
3175.58s - 3178.54s |  are same platform, different use case.
3180.22s - 3183.34s |  So let's talk a bit about how the firmware structure sits.
3183.34s - 3184.46s |  Do you mind if I jump in on that?
3184.46s - 3185.30s |  Sure, yeah.
3185.30s - 3189.50s |  Thank you.
3189.50s - 3190.70s |  So from a firmware perspective,
3190.70s - 3192.82s |  we've got those components we talked about earlier
3192.82s - 3194.18s |  within the encoder,
3194.18s - 3195.62s |  kind of similar components within the reader.
3195.62s - 3199.74s |  We've got that core, SAM, we've got expansion modules.
3199.74s - 3201.42s |  Each of these things have firmware,
3201.50s - 3203.70s |  and all of those things have to be upgraded,
3203.70s - 3206.06s |  or ideally they should be able to be upgraded.
3206.06s - 3210.10s |  So one of the ways that those things are actually updated
3210.10s - 3212.38s |  is firmware upgrade cards.
3213.38s - 3215.66s |  The same interfaces that work for the config cards
3215.66s - 3217.02s |  also work for firmware upgrades.
3217.02s - 3222.02s |  So you've got the NFC, BLE, OSDP, et cetera.
3222.10s - 3224.50s |  Although OSDP doesn't have as much market penetration yet
3224.50s - 3227.14s |  as we'd like for firmware upgrades, but we're getting there.
3227.14s - 3228.98s |  So for firmware upgrade cards,
3228.98s - 3230.82s |  there's actually this little plastic bracket
3231.22s - 3232.78s |  that you hang because you have to,
3232.78s - 3233.90s |  to fit firmware on cards,
3233.90s - 3235.58s |  you have to use a lot of cards, actually,
3235.58s - 3238.82s |  if anyone remembers splitting RAR files onto floppy disks.
3239.94s - 3243.06s |  Bunch of disks to take Age of Empires home from school
3243.06s - 3245.06s |  with the fast internet connection, but yeah.
3245.06s - 3248.86s |  So you've got a bunch of firmware cards.
3250.34s - 3251.18s |  Really didn't get used.
3251.18s - 3254.50s |  They were clunky, could end up with brick readers,
3254.50s - 3256.34s |  but ultimately, firmware upgrades
3256.34s - 3260.18s |  are still kind of a problem, even in this new platform.
3261.18s - 3265.94s |  But as we had mentioned, this platform introduced a SAM,
3265.94s - 3268.10s |  otherwise known as a secure application module.
3268.10s - 3270.98s |  Its entire job is to protect secrets.
3270.98s - 3274.18s |  So it's implemented on top of a secure microcontroller.
3274.18s - 3276.70s |  It's designed to be a black box to protect your secrets,
3276.70s - 3278.50s |  whether those are cryptographic keys
3278.50s - 3282.62s |  or the algorithms or intellectual property
3282.62s - 3284.36s |  that makes your product unique.
3284.36s - 3286.62s |  You can kind of put that into a black box
3286.62s - 3289.26s |  and with using a secure microcontroller,
3289.26s - 3291.74s |  its entire job is to just protect those secrets.
3291.74s - 3293.26s |  Yeah, do you mind if I touch on this a little bit?
3293.26s - 3294.10s |  Yeah, go ahead.
3294.10s - 3297.78s |  So this is very similar to the concept of a TPM, basically.
3297.78s - 3300.42s |  You have a special processor or a special hardware module.
3300.42s - 3304.18s |  Its only job is security, whether it is storing keys
3304.18s - 3306.98s |  or performing cryptographic operations,
3306.98s - 3309.10s |  and they're designed to resist really,
3309.10s - 3311.50s |  really advanced threats.
3311.50s - 3315.46s |  This particular SAM was made by Infineon, ultimately.
3315.46s - 3318.82s |  It was an SLE88, and one of the first things
3319.38s - 3322.22s |  that we wanted to figure out is how do we get access to this
3322.22s - 3325.22s |  so we can try to understand it better, ultimately.
3326.22s - 3328.42s |  The SAM comes in a lot of different types
3328.42s - 3331.74s |  and shapes and sizes for different purposes, right?
3331.74s - 3333.10s |  So you have these SIM cards,
3333.10s - 3337.26s |  you have different physical form factors that can be used.
3337.26s - 3339.54s |  They can go into readers, they can go into printers,
3339.54s - 3342.14s |  they can go into third-party products.
3342.14s - 3345.58s |  But ultimately, this is the piece of technology
3345.58s - 3348.18s |  that is responsible for key management.
3348.54s - 3349.70s |  So inside of that SAM,
3349.70s - 3353.18s |  which is kind of like a digital vault for keys,
3353.18s - 3356.62s |  there are special write-only slots
3356.62s - 3357.98s |  that you can only write keys to.
3357.98s - 3361.54s |  You're not supposed to be able to read keys out of them.
3361.54s - 3364.60s |  And these, as I mentioned, have both official applications
3364.60s - 3365.44s |  and you might have heard
3365.44s - 3367.30s |  some of the unofficial applications.
3367.30s - 3368.14s |  Woo!
3369.34s - 3370.62s |  Someone owns a flipper.
3372.14s - 3373.06s |  Of course, that's Eric.
3373.06s - 3375.54s |  Eric Betts, writer of Cedar.
3375.54s - 3378.02s |  If you ever have used that, it's a super cool app.
3378.86s - 3380.74s |  We can talk about it in RF Village later.
3380.74s - 3384.78s |  But yeah, it's basically this little super secure little guy
3384.78s - 3388.02s |  and he handles all the important stuff.
3388.02s - 3389.70s |  And so you put it inside of anything
3389.70s - 3391.50s |  that you want compatibility with,
3391.50s - 3394.14s |  and there you go, Bob's your uncle.
3394.14s - 3396.70s |  The firmware is separated out into a couple of pieces.
3396.70s - 3399.12s |  We're not gonna get super deep into the weeds on that
3399.12s - 3400.70s |  just for the sake of time.
3400.70s - 3405.10s |  But suffice to say, it is a layered implementation
3405.10s - 3409.62s |  that builds basically a chain of trust top to bottom
3409.62s - 3411.78s |  to try to protect everything along the way.
3411.78s - 3415.50s |  So there's multiple steps and keys
3415.50s - 3419.02s |  that control what applications run on there,
3419.02s - 3421.78s |  what data's accessible by what application,
3421.78s - 3423.26s |  so on and so forth.
3423.26s - 3425.50s |  But the reason I sped up a little bit there
3425.50s - 3427.50s |  is because we wanna make sure we talk about
3427.50s - 3428.94s |  the most important part.
3428.94s - 3430.18s |  It's the heist.
3430.18s - 3432.50s |  And of course, safety first, right?
3432.50s - 3435.58s |  So we gotta...
3435.58s - 3438.37s |  That's right.
3438.37s - 3441.37s |  This is some high intensity stuff here, right?
3442.25s - 3445.15s |  So let's talk about this process a little bit.
3446.65s - 3449.53s |  I remember Aaron and I talking a lot
3449.53s - 3452.25s |  about one of the favorite aspects
3452.25s - 3455.21s |  of hacking this project is what?
3455.21s - 3458.45s |  Yeah, so one of the really great parts about this project
3458.45s - 3461.89s |  is that a lot of reverse engineering work that you do
3461.89s - 3464.73s |  involves sort of unraveling information
3464.73s - 3466.29s |  that you already have, right?
3466.65s - 3469.17s |  So whether that's reversing a binary in Ghidra
3469.17s - 3470.21s |  and you're just trying to figure out
3470.21s - 3473.47s |  what a bunch of instructions are doing,
3476.61s - 3477.45s |  all the same, right?
3477.45s - 3479.53s |  You're trying to make sense of info you already have.
3479.53s - 3481.49s |  In this case, right, a lot of what happens
3481.49s - 3484.01s |  inside of the SAM is sort of a black box.
3484.01s - 3487.09s |  So we have a lot of information,
3487.09s - 3488.49s |  but we don't have all the information.
3488.49s - 3490.65s |  And so you really have to like put yourself
3490.65s - 3493.61s |  into the headspace of who built this.
3493.61s - 3498.61s |  And if they did X, Y, and Z,
3499.17s - 3502.21s |  then how might they have designed some other thing?
3502.21s - 3504.37s |  And you have to make these really educated guesses
3504.37s - 3506.33s |  and put yourself in the shoes of the person who built it.
3506.33s - 3507.53s |  And you gotta really stretch yourself.
3507.53s - 3508.87s |  It crosses a lot of domains.
3508.87s - 3511.31s |  It's not just software, it's hardware, it's firmware.
3511.31s - 3513.09s |  It's a lot of really cool stuff.
3513.09s - 3515.27s |  So first we need to think about this.
3515.27s - 3516.65s |  How do we want to approach this?
3516.65s - 3519.01s |  Well, where are the master keys?
3519.01s - 3520.37s |  Let's think through all the places
3520.37s - 3522.77s |  that keys are used and stored.
3522.77s - 3525.45s |  Let's think through what kind of operations
3525.45s - 3528.89s |  and what commands would have to use those keys.
3528.89s - 3532.09s |  And then how do those keys get there in the first place?
3532.09s - 3534.17s |  We gotta understand the whole process
3534.17s - 3537.45s |  and see if we can find any vulnerabilities
3537.45s - 3539.01s |  in the armor, so to speak.
3539.01s - 3540.53s |  So we identified our targets,
3540.53s - 3542.81s |  which is anything with keys, of course.
3542.81s - 3546.09s |  That includes standard readers, desktop USB readers,
3546.09s - 3548.25s |  embedded readers, encoders, of course.
3548.25s - 3551.05s |  That's one of the big things we're talking about today.
3551.05s - 3552.73s |  Configuration cards.
3553.57s - 3555.29s |  The common denominator in all of these things
3555.29s - 3558.17s |  is that iClass SE secure processor.
3558.17s - 3562.33s |  It's that SAM, because that's the one trusted piece,
3562.33s - 3565.81s |  that component that is allowed to do all this stuff.
3565.81s - 3568.83s |  So how do we turn unknowns into knowns?
3568.83s - 3572.09s |  Well, we gotta start touching hardware, right?
3572.09s - 3573.69s |  So we need to get inside,
3573.69s - 3577.21s |  see what we can find out about what chips are used,
3577.21s - 3580.21s |  see if we can tap into some communication buses,
3580.21s - 3581.85s |  and just start trying to understand
3581.85s - 3584.71s |  the language that it speaks.
3584.71s - 3587.17s |  On the firmware side, we wanna try to get a copy
3587.17s - 3589.09s |  of anything we can get our hands on
3589.09s - 3591.37s |  and start reverse engineering, right?
3591.37s - 3596.25s |  That is like Aaron's and Nick's bread and butter.
3596.25s - 3599.75s |  I can poke hot pokey things at hardware all day long,
3599.75s - 3602.05s |  I'll cut things apart, but honestly,
3602.05s - 3605.57s |  when it comes to the actual hardcore reverse engineering,
3605.57s - 3608.89s |  I still rely on geniuses like Aaron and Nick.
3608.89s - 3613.13s |  Otherwise, I'm just not as effective on my own.
3613.13s - 3617.01s |  But all the normal techniques that you'd apply,
3617.01s - 3619.41s |  we had to apply to these different domains,
3619.41s - 3622.39s |  software, firmware, hardware, et cetera.
3623.29s - 3627.17s |  As a fun story, while we were working on this,
3627.17s - 3628.85s |  one of our mutual friends, actually,
3628.85s - 3630.53s |  who we didn't know was a mutual friend
3630.53s - 3633.03s |  until we started this project, Vlad,
3634.49s - 3638.85s |  he, as a side quest, decided to look at some readers,
3639.69s - 3641.33s |  and there was this really fun exchange that we had
3641.33s - 3643.69s |  that he gave me permission to post,
3643.69s - 3646.15s |  and he cut it apart and he just sends me
3646.15s - 3648.37s |  this photo out of the blue, and he says,
3648.37s - 3650.85s |  Bobik, what the fuck is this powder?
3650.85s - 3651.89s |  The reader's full of it.
3651.89s - 3654.85s |  Does HID literally put a felony amount
3654.85s - 3656.81s |  of cocaine in every reader?
3656.81s - 3659.49s |  And I corrected him, of course, that's clearly anthrax.
3659.49s - 3662.73s |  That's how HID takes out their researchers,
3662.73s - 3665.41s |  and of course, that explains a lot.
3665.41s - 3667.69s |  But no, that's not the case.
3668.13s - 3672.65s |  This is just epoxy fill, serves a couple different purposes,
3672.65s - 3676.73s |  from weather resistance to making it harder
3676.73s - 3680.55s |  to get to the damn thing, as evidenced by these photos.
3681.45s - 3682.75s |  But that was just the hardware piece.
3682.75s - 3684.93s |  On the software piece, we had tons
3684.93s - 3686.77s |  of other tools as well, right?
3686.77s - 3690.93s |  We had Aaron and Nick breaking out DotPeak and Jeb.
3690.93s - 3693.41s |  I was breaking out the Salialogic analyzer,
3693.41s - 3694.69s |  and we were doing all this remotely,
3694.73s - 3697.97s |  like during COVID, you were in San Francisco,
3697.97s - 3700.61s |  I was in Phoenix, and tons of screen sharing,
3700.61s - 3703.01s |  way, way too much screen sharing.
3703.01s - 3708.01s |  So lots of tiny wires, lots of hot, dangerous things,
3708.89s - 3711.69s |  blood, sweat, and tears, patients, and of course,
3711.69s - 3715.21s |  a very, very healthy slash unhealthy dose
3715.21s - 3717.09s |  of neurodivergent persistence.
3719.33s - 3722.09s |  FCC Docs, if you've ever been curious,
3722.09s - 3725.25s |  it's a great resource for finding out
3725.25s - 3728.21s |  preliminary information about hardware.
3728.21s - 3729.41s |  Anything that has a radio in it
3729.41s - 3732.29s |  is required to go through FCC certification.
3732.29s - 3734.77s |  So you sometimes get leaks of products
3734.77s - 3738.29s |  well in advance of the product actually coming out.
3738.29s - 3740.01s |  And I remember back in 2016,
3740.01s - 3743.27s |  there was this article on a tech site,
3743.27s - 3747.05s |  like, oh, Apple is working on this mystery device.
3747.05s - 3748.93s |  It has NFC and Bluetooth,
3748.93s - 3751.17s |  and maybe it's a new crazy airport extreme.
3751.17s - 3752.49s |  And I looked at the sticker and I'm like,
3752.49s - 3756.53s |  dude, it says D1, D0, it's weekend.
3756.53s - 3758.17s |  It's just a card reader.
3758.17s - 3760.21s |  And yes, it was, it was just a card reader
3760.21s - 3763.05s |  as it came out six to eight months later,
3763.05s - 3765.01s |  and it's a custom piece for Apple
3765.01s - 3768.21s |  that they use in their facility, but we digress.
3768.21s - 3771.49s |  We did FCC research on the iClass SE platform.
3771.49s - 3774.29s |  We got some kind of blurry potato quality photos,
3774.29s - 3776.41s |  so we had to get to that ourselves.
3776.41s - 3778.33s |  We tried a lot of stuff, guys.
3778.33s - 3780.53s |  We tried cutting acetone.
3780.53s - 3783.09s |  I tried boiling readers in my apartment
3783.97s - 3787.37s |  to try to heat up the epoxy and make it more brittle.
3787.37s - 3790.65s |  I remember hitting it with like 1,200 degrees of hot air
3790.65s - 3794.23s |  and trying to chip away at the epoxy, and it just sucks.
3795.09s - 3796.17s |  But that worked.
3796.17s - 3799.37s |  I found that hot air embrittled the epoxy.
3799.37s - 3801.05s |  It did not smell good.
3801.05s - 3804.77s |  I probably have some stuff going on in my head as a result,
3804.77s - 3807.21s |  but I'm here and you're here,
3807.21s - 3809.29s |  and we're gonna have a good time.
3809.29s - 3813.85s |  So here's a photo that actually one of our close friends,
3813.85s - 3817.69s |  Kevin, 0xFFFF, took when he did the same process,
3817.69s - 3819.77s |  and he's just a master at this stuff,
3819.77s - 3821.97s |  and you can see it's a little bit clearer,
3821.97s - 3824.49s |  and of course, there's our SAM, right?
3824.49s - 3826.69s |  That protects the secret things.
3826.69s - 3828.37s |  That's the thing that we're trying to hack.
3828.37s - 3829.85s |  There's other chips in there as well.
3829.85s - 3833.01s |  We have the RF front end, the HF front end,
3833.01s - 3836.45s |  the main microcontroller, which we refer to as core,
3836.45s - 3840.29s |  and we wanted to figure out, how do we get to these SAMs?
3840.29s - 3842.05s |  How do we get access to more of them?
3842.05s - 3843.37s |  And readers aren't cheap,
3843.37s - 3845.21s |  so we've gotta try to figure it out.
3845.21s - 3847.73s |  What I ultimately, by accident, figured out
3847.73s - 3851.49s |  is that by a weird quirk of manufacturing,
3851.49s - 3854.93s |  on the back of the reader, if you'll notice,
3854.93s - 3857.93s |  right over here, there's this debug port
3857.93s - 3860.55s |  that's actually used as an expansion port
3860.55s - 3864.17s |  for external modules like Bluetooth and stuff like that,
3864.17s - 3866.49s |  and something about the manufacturing process
3866.49s - 3870.01s |  required them to put a little plastic bubble in that area,
3870.01s - 3871.37s |  and wouldn't you know it?
3871.37s - 3873.41s |  The SAM's right in that bubble
3873.41s - 3875.47s |  with no epoxy surrounding it.
3875.47s - 3877.73s |  So what I found is I was able to use
3877.73s - 3879.09s |  one of my new best friends,
3879.09s - 3881.89s |  that ultrasonic knife on the right-hand side,
3881.89s - 3885.75s |  and the official SAM recovery guide tool,
3885.75s - 3888.61s |  which is just a piece of cardboard that I cut.
3888.61s - 3890.71s |  Here's the 1.1 version.
3890.71s - 3892.93s |  It's the same thing, basically,
3892.93s - 3894.45s |  and I'll show you the process.
3894.45s - 3895.77s |  This is sped up three times
3895.77s - 3899.47s |  because this is already way too long, let's be honest.
3899.47s - 3902.45s |  So I'm just drawing a little rectangle on there,
3902.45s - 3903.99s |  and I'm using the ultrasonic knife
3903.99s - 3907.21s |  to cut through that top layer of epoxy and plastic,
3907.21s - 3909.53s |  and it goes pretty quick, actually.
3909.53s - 3910.53s |  I love this tool.
3910.53s - 3912.13s |  If you do a lot of hardware hacking,
3912.13s - 3913.49s |  Wonder Cutter, buy it.
3913.49s - 3915.03s |  It's freaking awesome.
3915.93s - 3918.19s |  And you saw I sliced through it there pretty quick,
3918.19s - 3922.29s |  even at 3X, and then boom, the board is exposed.
3922.29s - 3924.93s |  Now that tool on the right, that's pretty cool, actually.
3924.93s - 3927.45s |  Those of you who wear glasses, like me, for a long time,
3927.45s - 3930.85s |  might remember seeing one in your optometrist's office
3930.85s - 3932.17s |  way back in the day,
3932.17s - 3935.05s |  and it's just a bath of hot glass beads,
3935.05s - 3937.25s |  and I used that to preheat the reader
3937.25s - 3939.93s |  to make it easier to then remove that SAM
3939.93s - 3941.53s |  using the hot air station.
3941.53s - 3943.37s |  And so just after a little bit of time,
3943.37s - 3945.03s |  we're able to recover that SAM,
3945.03s - 3948.29s |  and that was a very nice, efficient process
3948.29s - 3950.37s |  of trying to recover SAMs,
3950.37s - 3952.85s |  and to be fair, this looks really slick,
3952.85s - 3955.09s |  but we went through a lot.
3955.09s - 3958.37s |  I damaged a lot and spent a lot of money
3958.37s - 3959.89s |  to get to that point.
3959.89s - 3961.79s |  I even had a little SAM cemetery,
3961.79s - 3964.97s |  and then I ran out of room, and I just stopped.
3964.97s - 3967.61s |  I had a whole pile of these dead, damn things.
3968.73s - 3971.33s |  But ultimately, what worked was choosing the right reader
3971.33s - 3974.27s |  and doing all the things, and great success, right?
3974.27s - 3977.65s |  That's actually a pile of SAMs I successfully extracted
3977.65s - 3979.69s |  out of a bunch of readers, and all of them worked.
3979.77s - 3981.17s |  I was very proud of it.
3981.17s - 3983.57s |  But we wanted to see inside, because why not?
3983.57s - 3986.29s |  And so I live in Las Vegas.
3986.29s - 3988.17s |  There's a really cool local company here
3988.17s - 3989.85s |  called Full Spectrum Laser.
3989.85s - 3992.57s |  They make really cool stuff, and for some reason,
3992.57s - 3995.49s |  they let me play with one of their fancy UV lasers,
3995.49s - 3999.29s |  and I learned that you can decapsulate an IC
3999.29s - 4001.59s |  with UV really, really fast.
4002.45s - 4006.49s |  It is destructive, of course, but that worked a treat,
4006.49s - 4008.37s |  so thank you to Full Spectrum Laser
4008.37s - 4010.57s |  for letting us do that.
4010.57s - 4012.69s |  But these are some dye shots that Kevin took
4012.69s - 4016.13s |  when he did a little acid bath process himself,
4016.13s - 4018.45s |  and that's what proved that this was, in fact,
4018.45s - 4022.97s |  the Infineon SLE88, and you kind of,
4022.97s - 4024.41s |  you get where we're going with this.
4024.41s - 4026.13s |  I'm gonna skip a couple of slides here
4026.13s - 4027.13s |  just for the sake of time.
4027.13s - 4029.69s |  We want to show you the cool demo.
4029.69s - 4032.65s |  But the Artemis platform was the codename
4032.65s - 4036.73s |  for all of that hardware, and as was mentioned earlier,
4036.73s - 4041.73s |  it uses SNMPv3 messages to talk to different endpoints.
4042.13s - 4044.01s |  If you're curious about this more,
4044.01s - 4045.17s |  come talk to us later.
4045.17s - 4047.85s |  Maybe we can share a little bit more about it.
4048.85s - 4052.87s |  But do you have a quick thing to mention about this?
4052.87s - 4054.25s |  I want to make sure we have enough time
4054.25s - 4055.45s |  to get the demos in.
4055.45s - 4057.57s |  Yeah, like standards-based protocols,
4057.57s - 4060.81s |  using an efficient protocol for an embedded system like this
4060.81s - 4062.25s |  provides pretty good security, actually.
4062.25s - 4064.37s |  It's a really interesting use, so yeah.
4064.37s - 4065.73s |  Yeah.
4065.73s - 4067.97s |  There's a couple different roles that we discovered, right?
4067.97s - 4070.41s |  You know, there's OEM admin, there's HID admin.
4070.41s - 4071.61s |  These are users, basically,
4071.61s - 4073.81s |  that have different levels of access,
4073.81s - 4077.37s |  and that was critical for the exploit itself, actually,
4077.37s - 4078.19s |  right?
4078.19s - 4080.73s |  Yeah, no, that very much was critical,
4080.73s - 4085.13s |  and yes, SNMPv3, while it is primarily a network technology,
4085.13s - 4087.11s |  is actually a really good,
4087.11s - 4089.25s |  it's used quite well in this platform.
4089.25s - 4091.29s |  So all this stuff is built on Java cards,
4091.29s - 4092.53s |  which if you've never played with,
4092.53s - 4093.53s |  they're super, super cool,
4093.53s - 4095.77s |  but they're used for all sorts of different applications,
4095.77s - 4099.97s |  everything from credit cards to access control, et cetera.
4099.97s - 4101.89s |  The config cards use them as well,
4101.89s - 4103.81s |  so you can update firmware,
4103.81s - 4107.49s |  and change all those settings, that used Java card.
4107.49s - 4109.81s |  But config card operations, Nick,
4109.81s - 4111.73s |  take it away and punch through this,
4111.73s - 4112.77s |  because this is important.
4112.77s - 4114.63s |  When a config card is encoded,
4114.63s - 4115.61s |  the app is initialized,
4115.61s - 4117.03s |  it's told how much space it should have,
4117.03s - 4120.33s |  and then after that happens, the encoder says,
4120.33s - 4121.95s |  okay, here are the SNMP keys you should use
4121.95s - 4123.59s |  when you generate messages,
4123.59s - 4125.43s |  and then loads the configuration data,
4125.43s - 4127.39s |  that can be keys, or configuration objects,
4127.39s - 4129.39s |  things like LED color, et cetera.
4129.39s - 4132.71s |  So when that process is finished,
4132.71s - 4134.47s |  and you actually go to use it at a reader,
4134.47s - 4135.87s |  the reader selects the applet,
4135.87s - 4139.83s |  the reader itself sends the SAM engine ID
4139.83s - 4141.31s |  that it uses for the SNMPv3,
4141.31s - 4144.95s |  and then the username that the config card should use
4144.95s - 4146.59s |  to actually generate those messages,
4146.59s - 4149.39s |  and then the reader says, okay, give me messages,
4149.39s - 4151.53s |  and now we're at the heist, essentially.
4152.37s - 4155.21s |  So we looked at that set SNMP keys portion,
4155.21s - 4158.37s |  and found that it requires a secure channel to do that,
4158.37s - 4160.89s |  but if you have a secure channel,
4160.89s - 4163.19s |  you can actually change the keys without knowing them,
4163.19s - 4164.89s |  without deleting data.
4164.89s - 4167.13s |  So if you find a card
4167.13s - 4169.33s |  that you can establish a secure channel with,
4169.33s - 4174.17s |  you can then use that to set SNMP keys to zero,
4174.17s - 4177.29s |  and then when you go and pretend to be a reader,
4177.29s - 4179.33s |  you can give it a SAM session ID,
4179.33s - 4180.25s |  you can give it a username,
4180.25s - 4181.25s |  and then you can just get messages
4181.97s - 4183.53s |  that are encrypted with zeros.
4183.53s - 4187.37s |  So here is a demonstration of that exact thing happening,
4187.37s - 4190.65s |  and in this case, we'll take the config card,
4190.65s - 4194.89s |  we'll use it with this standard PCSC reader,
4194.89s - 4198.73s |  and in this case, we're gonna take the script here
4198.73s - 4202.39s |  to establish a secure channel and zero out those keys,
4202.39s - 4205.53s |  and let me just go ahead and skip ahead.
4205.53s - 4206.37s |  Oops, sorry.
4206.37s - 4220.57s |  Oh, too far.
4220.57s - 4222.53s |  I'm trying to zoom ahead.
4222.53s - 4228.35s |  All right, go ahead.
4229.31s - 4231.19s |  When this script runs,
4231.19s - 4233.69s |  it essentially zeros the keys out on the card
4233.69s - 4235.51s |  so that we can then pretend to be a reader
4235.51s - 4238.31s |  with the Proxmark 3 there on the right-hand side.
4238.31s - 4240.35s |  You can see here the success messages
4240.35s - 4241.39s |  generated by the card,
4241.39s - 4243.87s |  showing that the keys have been set to zeros,
4243.87s - 4247.19s |  and then when we go and use that config card with a reader,
4247.19s - 4249.35s |  in this case, our Proxmark 3,
4249.35s - 4251.55s |  we'll tell it to generate those messages.
4253.15s - 4257.33s |  Nope, it's not letting me scrub through it.
4257.33s - 4259.61s |  Essentially, resulting in...
4259.61s - 4270.84s |  Can you move it to the mic a little bit?
4270.84s - 4273.20s |  Yay, tech problems, sorry, guys.
4273.20s - 4275.00s |  A live demo might have been better.
4276.28s - 4277.70s |  Anyway.
4277.70s - 4279.64s |  So, this video will be uploaded.
4279.64s - 4280.80s |  Yeah, it will be uploaded.
4280.80s - 4282.60s |  We're uploading this version of the deck
4282.60s - 4283.48s |  and the demo video,
4283.48s - 4286.28s |  so you guys will be able to play it yourself as well.
4286.28s - 4287.68s |  Essentially, we had a custom key
4287.68s - 4288.84s |  encoded on that config card,
4288.84s - 4291.36s |  and by zeroing the keys and retrieving that SNMP message,
4291.36s - 4293.80s |  we were able to decrypt it and retrieve that secret key.
4293.80s - 4295.28s |  That same process works for any keys
4295.28s - 4297.12s |  stored on an encoder, SAM,
4297.12s - 4300.28s |  or secure element of any kind in this platform.
4300.28s - 4303.08s |  So, the config card impact of this is that
4303.08s - 4304.68s |  if you can establish a secure channel,
4304.68s - 4306.52s |  you can change keys and recover any sort of data
4306.52s - 4308.60s |  that's on these cards, and that's kind of...
4308.60s - 4310.00s |  The teal deer is, you know,
4310.00s - 4313.16s |  Nick found a bug where you can zero out keys on a card
4313.16s - 4315.56s |  and then dump messages from it,
4315.56s - 4317.54s |  and if that card contained keys,
4317.54s - 4318.56s |  you were able to then recover it.
4318.56s - 4319.40s |  Exactly.
4319.40s - 4322.08s |  So, all of that is gonna be in the video.
4322.08s - 4324.52s |  Those of you who are into this can inspect it more.
4324.52s - 4326.48s |  That'll be on the media server.
4326.48s - 4329.12s |  And then the other thing that, sadly, I apologize
4329.12s - 4331.88s |  that we're going a little bit slow earlier in the talk,
4331.88s - 4333.68s |  the main thing is the encoder attack.
4333.68s - 4336.64s |  Now, the encoder attack is a little bit more devastating,
4336.64s - 4340.44s |  and for that reason, we are releasing in video form
4340.44s - 4343.28s |  all of the details of how the config card works.
4343.28s - 4344.70s |  We're describing what happens here.
4344.70s - 4346.72s |  We're not releasing any code for it
4346.72s - 4349.28s |  because after our investigation,
4349.28s - 4351.88s |  the impact was gonna be significant,
4351.88s - 4357.84s |  but we are gonna explain how it worked, basically.
4357.84s - 4361.08s |  So, you wanna touch on this?
4361.08s - 4361.92s |  Sure.
4361.92s - 4362.76s |  Go ahead.
4362.76s - 4365.80s |  So, the way that the encoder attack really works
4366.68s - 4369.36s |  is that as part of encoding a config card
4369.36s - 4370.64s |  and loading key material into it,
4370.64s - 4372.34s |  you need to have a secure channel.
4373.52s - 4376.96s |  But essentially, what we found is that
4376.96s - 4378.92s |  the client is overly trusted here.
4378.92s - 4381.64s |  So, if you look, if we cut out all the steps
4381.64s - 4384.24s |  that involve initializing a secure channel, et cetera,
4385.08s - 4387.56s |  we can just transmit the key in the clear.
4387.56s - 4389.84s |  Yeah, so normally, what happens,
4389.84s - 4391.56s |  and while this video is playing,
4392.80s - 4395.36s |  during any key loading operation,
4395.36s - 4399.68s |  that encoder creates a secure session with the card
4399.68s - 4401.14s |  to create an encrypted channel,
4401.14s - 4403.00s |  and then it transfers the key.
4403.00s - 4405.44s |  And so, you have this whole end-to-end piece
4405.44s - 4408.08s |  that is like a closed tunnel.
4408.08s - 4411.50s |  What we found is that we could actually trick the encoder
4411.50s - 4414.56s |  into saying, don't worry about secure channel session,
4414.56s - 4416.26s |  just do your thing.
4416.26s - 4418.14s |  So, we were able to then instruct it,
4418.14s - 4420.14s |  yeah, ignore secure channel,
4420.14s - 4421.50s |  just load the keys to the card.
4421.50s - 4422.66s |  You're good, you're good.
4422.66s - 4424.00s |  It's cool.
4424.00s - 4425.98s |  And then we used Approxmark 3
4425.98s - 4428.42s |  to intercept those keys in the clear,
4428.42s - 4430.46s |  because we told it to ignore secure channel,
4430.46s - 4431.68s |  and using that method,
4431.68s - 4435.04s |  we were then able to iterate through keys
4435.04s - 4436.42s |  that were built into the encoder
4436.42s - 4437.86s |  and actually then recover them,
4437.86s - 4441.22s |  because we were able to find a defect
4441.94s - 4444.16s |  in this very critical piece of implementation,
4444.16s - 4447.06s |  and that all this work,
4447.06s - 4449.00s |  simple, simple mistakes can be made.
4451.02s - 4455.50s |  With apologies, we're unfortunately out of time.
4455.50s - 4460.50s |  We are going to share these slides and the videos.
4460.50s - 4462.10s |  The impacts that I just,
4462.10s - 4464.82s |  if I could have an extra 60 seconds, if that's okay,
4464.82s - 4466.28s |  I appreciate that.
4467.98s - 4470.06s |  These types of mistakes are easy to make
4470.06s - 4472.64s |  from an engineering perspective, okay?
4472.64s - 4475.22s |  And even though this was one of the most well-designed
4475.22s - 4477.06s |  systems that we've seen to date,
4477.06s - 4479.44s |  with enough persistence, we found problems.
4480.34s - 4485.34s |  And ultimately, this was a vulnerability that came about
4485.74s - 4488.52s |  due to a lot of internal and external pressures
4488.52s - 4491.38s |  from customers, from marketing, from sales,
4491.38s - 4493.02s |  all sorts of different things,
4493.02s - 4494.74s |  and really it boils down to an industry
4494.74s - 4496.70s |  still being hooked on WeGant
4496.70s - 4498.82s |  and looking for that interoperability.
4498.82s - 4501.34s |  And the main message that we're trying to drive home
4501.34s - 4504.42s |  is that no vendor is safe, technically.
4504.42s - 4508.14s |  This was one of the most secure systems on the market,
4508.14s - 4510.28s |  and we're still able to find problems.
4510.28s - 4513.98s |  And really the issue is we're trying to put patches
4513.98s - 4515.44s |  on something that really isn't designed
4515.44s - 4518.18s |  to be that secure in the first place, which was WeGant.
4518.18s - 4520.22s |  But if you do your risk mitigation properly,
4520.22s - 4522.42s |  if you're building your security like an onion,
4522.42s - 4524.66s |  it's not that big of a deal.
4524.66s - 4527.06s |  So the last thing that we want to leave you with,
4527.06s - 4528.36s |  depending on your threat model,
4528.88s - 4530.04s |  and again, these will be in the slides,
4530.04s - 4532.88s |  sincere apologies that we went a little bit slower
4532.88s - 4534.54s |  than we originally had wanted to,
4534.54s - 4535.96s |  depending on your threat actor,
4535.96s - 4538.02s |  that's gonna define whether or not
4538.02s - 4540.80s |  you have to do anything about this in any serious way.
4540.80s - 4543.00s |  If you're just an average user
4543.00s - 4544.84s |  and you're using standard keys,
4544.84s - 4547.08s |  we do recommend that you move to a custom key
4547.08s - 4549.50s |  like EliteKeys, and they're actually waiving the fees
4549.50s - 4552.26s |  for this program for the first year as a result.
4552.26s - 4556.64s |  If you're already using EliteKeys, you're probably fine,
4556.64s - 4559.32s |  even though technically there may be advanced ways
4559.32s - 4560.90s |  of recovering those out of a reader,
4560.90s - 4562.52s |  it still takes a lot of skill
4562.52s - 4564.72s |  and not a lot of people know how to do that.
4565.64s - 4570.64s |  But if you're an advanced threat person or customer,
4571.00s - 4574.20s |  then you really want to upgrade your hardware
4574.20s - 4576.72s |  to the latest version, make sure you're using custom keys
4576.72s - 4580.64s |  and engage your vendor, engage your integrator and HID
4580.64s - 4582.04s |  and talking about your risks
4582.04s - 4583.56s |  and what you're trying to mitigate against
4583.56s - 4586.32s |  so you have a practical real world understanding
4587.00s - 4589.40s |  of what your system will do, what it will not do.
4590.28s - 4591.88s |  And that's really the size of it.
4591.88s - 4593.68s |  Again, thank you for being here.
4593.68s - 4595.04s |  Thanks for your patience.
4595.04s - 4597.08s |  Apologies, we didn't get through a couple slides,
4597.08s - 4598.84s |  but that was really the meat of it.
4599.72s - 4602.68s |  And thank you, thank you again, really appreciate it.
4602.68s - 4603.52s |  Thank you.
4603.52s - 4604.34s |  Thank you.
4604.34s - 4605.18s |  Thank you.
4605.18s - 4606.02s |  Thank you.


url: https://www.youtube.com/watch?v=11Yv2Ru7gF8
title: DEF CON 32 - Iconv, set the charset to RCE exploiting glibc to hack the PHP engine - Charles Fox
type: video
author: DEFCONConference
ingestion_date: 2024-11-10
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=11Yv2Ru7gF8",
  "title": "DEF CON 32 - Iconv, set the charset to RCE  exploiting  glibc to hack the PHP engine - Charles Fox",
  "description": "Upon its discovery, CVE-2024-2961, a very old buffer overflow in the glibc, seemed like a terrible bug. Within the prism of the PHP engine, however, the vulnerability shone, and provided both a new remote code execution vector and a few 0-days.\n\nThis talk will first walk you through the discovery of the bug and its limitations, before describing the conception of remote binary PHP exploits using this bug, and through them offer unique insight in the internal of the engine of the web language, and the difficulties one faces when exploiting it.\n\nAfter this, it will reveal the impact on PHP's ecosystem, from well-known functions to unsuspected sinks, by showcasing the vulnerability on several popular libraries and applications.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2580,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.53s - 2.53s | This text was transcribed using whisper model: large-v2

 Hi
3.93s - 5.93s |  Yeah, thank you
7.97s - 11.33s |  Well, thank you for coming to my talk because I know it's the last talk for today
11.33s - 16.31s |  So I guess everybody's pretty tired of seeing talks, but hopefully it will be interesting
16.73s - 21.73s |  So the bug is a bug that I found by auditing PHP, but it's not on PHP
21.73s - 28.97s |  It's a bug in the gdpc and it targets icons, which is the character set conversion library of the gdpc
29.21s - 34.81s |  And I actually was able to use the bug to compromise the PHP engine in two different ways
35.25s - 38.37s |  Remotely and this is this is what I'm going to talk about today
39.89s - 41.01s |  So
41.01s - 45.61s |  First I will describe how I found the bug it was by complete accident by complete chance
45.85s - 51.53s |  But the way I will explain it to you will serve as an introduction to the next section
51.53s - 54.53s |  Which is gonna which is gonna be about attacking PHP filters
54.53s - 57.13s |  If you don't know what the PHP filter is, don't worry
57.13s - 61.73s |  I will explain what this is and also afterwards I will attack a different way
61.73s - 65.69s |  I will attack PHP by targeting direct calls to icons and
66.65s - 71.69s |  Well after this, hopefully we'll have time for a conclusion and maybe a little bit of a bonus
72.93s - 74.29s |  so
74.29s - 77.77s |  Regarding the discovery. Well to understand how I found the bug
77.89s - 82.09s |  We need to understand what you can do when you have a favorite primitive in PHP
82.09s - 85.69s |  So code such as this one, but it could also be a fellow
86.53s - 92.57s |  An F open followed by an F reads like any foundry primitive in PHP. What can you do with it?
92.89s - 96.09s |  Well, obviously you can read a file you can really TC password
96.73s - 101.09s |  but you can also force PHP into reading HTTP resource that would work and
102.01s - 104.13s |  FTP resource that would work as well and
104.93s - 107.09s |  there are also other protocols that
107.81s - 112.17s |  You can use which are PHP specific such as far colon slash slash
112.73s - 114.73s |  it will let you read the
116.29s - 122.17s |  Contents of archive. So for those who don't know for archive, it's like a jar for Java
122.17s - 126.33s |  So it's a collection of source files resources and also in PHP
126.33s - 134.05s |  It contains serialized metadata and when you access such a file using far colon slash slash the metadata will be deserialized
134.37s - 135.45s |  so
135.45s - 140.61s |  There was an attack for the longest time that was that you could upload a file to a server
141.37s - 148.25s |  Any file an image or anything and then you would use your file with primitive to load it as a far and that would give you
148.45s - 151.65s |  Arbitrary deserialization which oftentimes meant RCE
153.33s - 157.33s |  Sadly in PHP 8 they have disabled the deserialization of the metadata
158.13s - 166.01s |  Because they actually don't use the metadata. So it was completely useless and also in older versions big frameworks have been removing
166.61s - 171.13s |  The far colon slash slash protocol because they don't use it and they also know that
171.69s - 178.19s |  It is very dangerous like magento got completely demolished with this with the the far colon slash like bug
178.49s - 180.49s |  There there was like hundreds of bugs
181.25s - 185.05s |  reported to them using far colon slash slash so they just removed it entirely and
185.81s - 190.25s |  also, it's going to be harder to exploit even not on PHP 8 this bug because
191.13s - 194.49s |  Deserialization is going to get harder and harder to exploit as time goes by because
194.97s - 199.53s |  Mainly because actually types are making a comeback, but that's probably subject for another talk
201.41s - 206.13s |  So people have taken the interest into another PHP specific protocol, which is called PHP
206.93s - 212.05s |  Well, you can guess it's PHP specific and there's a sub part of this which is called PHP filter
212.05s - 218.15s |  And what it does is that it will read a resource and apply some filters that you have chosen onto it
219.07s - 224.63s |  It will then return the resource as if it was the original file, but we felt us apply onto it
224.63s - 228.79s |  So a good example of this and probably the simplest one that you can get is this string
228.79s - 232.79s |  So you have PHP filter then one filter which is convert the base 64 encodes
232.79s - 237.55s |  You can probably guess what it does converse to base 64 and then the resource is it is a password
238.19s - 242.53s |  So what you get when you do a file get contents of this is file get
243.13s - 244.65s |  Is it is password sorry
244.65s - 250.05s |  But basics if one code it and the good thing about these filters is that you can stack as many as you want
250.05s - 256.73s |  So instead of basic c4 encoding once I can do it twice, but I could also do it like a thousand times. It will work
258.85s - 261.57s |  Well, obviously you can do other things than basic c4 encodes
261.73s - 263.73s |  you might be able to
263.85s - 270.69s |  Put your string in uppercase with string dot upper or put it in lowercase with string dot lower and do some very very old
270.73s - 275.01s |  Crypto we've wrought 13. I don't know why it's there, but it actually works and
275.77s - 281.73s |  You can also use filters that are not documented, but very useful as an attacker such as D chunk
281.73s - 283.73s |  I will talk about it later and
284.05s - 286.41s |  Well, you can also use the star for today
286.41s - 292.81s |  Which is convert that icons that X dot Y and what it will do is that it will use the icon of library of the gdpc
292.81s - 298.29s |  To convert your stream from charset X to charset Y just to give you a quick example
298.61s - 301.69s |  Say that you have etc password you want to convert it from
302.29s - 305.41s |  UTF-8 to UTF-16 you can use this string
305.81s - 311.53s |  This PHP filter string and it will do it automatically as you can see in the X dump right underneath
313.81s - 315.05s |  So
315.05s - 318.21s |  Well these filters they've been like attacked a lot
318.45s - 322.65s |  There's been a lot of research on to them and the consensus in
323.17s - 329.93s |  2023 was that you could add using filters an arbitrary prefix to any file so you could dump etc password
329.93s - 334.97s |  but with an arbitrary prefix just by picking the right filters to apply on to it and
336.29s - 340.41s |  Myself what I wanted to see was whether or not I could get an arbitrary suffix as well
340.97s - 345.33s |  So an arbitrary prefix on some text and then some suffix as well
345.33s - 350.41s |  And the idea is very simple say that you have this piece of code of course you have a favorite primitive
350.41s - 354.55s |  But then right afterwards you have a JSON decode, so if the file is not valid JSON
355.05s - 358.05s |  Your favorite primitive is useless like you cannot read etc password
358.17s - 365.61s |  But if you can make your file look like JSON using an arbitrary prefix and suffix you can make the JSON decode works
366.09s - 372.77s |  work sorry and therefore you can well make PHP think it's JSON and return to you the contents of etc passwords and
372.93s - 379.85s |  This research it actually works. It has a few preconditions, but you can actually pull it off and I called the tool
379.85s - 384.77s |  Vraap Vraap and I have made a blog post about it. It's on our company's blog
384.77s - 387.61s |  so I'm bernie nix.io as you can see on the bottom and
388.73s - 392.65s |  Well the important part in all this is that at the beginning
392.65s - 396.29s |  I didn't know much when I started this research about PHP filters
396.37s - 400.57s |  So I built a few scripts just to try and do some conversion
400.57s - 405.21s |  So maybe from charset A to B then apply a basic C4D code then from C to D
405.37s - 409.45s |  Like lots of conversions just to see what I could get as a result
409.45s - 413.25s |  and I actually got a crash while doing this so I was pretty surprised and
414.05s - 419.13s |  I've been working with PHP for like 20 years, so I kind of felt like it was due to PHP
419.13s - 424.65s |  You know because it's always PHP, but this time it wasn't PHP. It was actually due to the glibc
424.65s - 427.95s |  So the base library for most Linux programs
428.29s - 435.09s |  because when PHP does the character set conversion using convert the type of it will use the icon library of the glibc and
435.45s - 439.89s |  What this library does is that you pick an input charset and an output charset
439.89s - 445.97s |  And then you feed it buffers, and it will convert from your input buffer to the output buffer from one charset to another
447.33s - 453.73s |  the thing is when you call the icon function you give it an input buffer with some size and an output buffer with some other
453.73s - 455.37s |  size and
455.37s - 460.61s |  Obviously it should guarantee that it will now read more bytes in the input buffer than it should or more
460.73s - 466.77s |  Write more bytes than it should in the output buffer and generally does so pretty well like there's no overflow
467.09s - 472.85s |  But sometimes it fails to do so and this is exactly why I got my crash. It is
473.37s - 477.41s |  That's when you convert to some very obscure charset, which is called ISO
478.25s - 486.33s |  2022 CNX in some cases it will not check the bounds of the output buffer before writing some escape sequences and
486.77s - 489.25s |  That means that as a result as an attacker
489.45s - 493.41s |  You if you are able to convert some text to ISO 2022 CNX
493.41s - 498.73s |  You will get an overflow of one to three bytes with the very specific values that I've written here
498.73s - 504.73s |  So your overflow could be with dollar star H or dollar plus I or dollar plus J any of these six values
504.73s - 506.73s |  But only these six values
507.97s - 511.77s |  To give you a quick idea of the characters that you can use to trigger the bug
511.93s - 516.45s |  Those are the characters that I trigger the bug with so those are Chinese characters
516.45s - 519.29s |  I have no idea what they mean, but they give you a buffer overflow
521.61s - 527.25s |  So the vulnerability that we have it's already pretty bad like it's a one to three bytes overflow
527.25s - 533.01s |  And it's fixed by values that you don't control the bytes in addition to this you have horrible conditions
533.01s - 535.01s |  Like you have to control the output charset
535.05s - 539.85s |  You have to set it to ISO 2022 CNX like nobody heard about it in in the room
539.85s - 544.21s |  I guess so yeah, you need to find an application that will let you pick your output charset
544.21s - 546.77s |  Otherwise you will not find an application that does it willingly
547.33s - 553.05s |  in addition to this you need to control part of the input buffer so that you can put in the Chinese characters and
553.89s - 560.13s |  Again a third condition is that you need to have a suitable output buffer if the output buffer is too small
561.05s - 566.01s |  Sorry too big compared to the input buffer even though you may have an overflow in theory
566.01s - 572.05s |  You're not going to be able to reach the end of the bounds of the output buffer before you trigger your escape sequence
572.05s - 573.41s |  And therefore you are not overflow
573.41s - 579.05s |  and this is like what was the most annoying part in looking for targets for this bug because I
579.45s - 585.77s |  Thought I had a bug in libxml2 because you can send an encoding using when you send your XML
585.89s - 592.49s |  But the output buffer when you did the conversion was way too big and therefore I couldn't exploit and that's only one of many
592.65s - 597.69s |  And so after probably weeks of looking for targets
597.69s - 603.77s |  I got super frustrated and I went back to PHP filters because that's the only thing that I could make crash and
604.33s - 608.85s |  That's actually the only thing that crashed without even me trying for it to crash. So I
609.61s - 614.69s |  was like, okay, that's probably my best bet to exploit this bug and I focus on to it and
615.25s - 623.53s |  The idea was to convert file read primitives in PHP any fabric primitive into remote code execution like straight up using this binary bug
624.53s - 627.73s |  So to explain to you how we might be able to do this
627.77s - 631.81s |  we need to think about how PHP does allocations and the allocations and
632.81s - 637.91s |  For this we need to understand PHP's heap, but don't worry. That's probably simplest heap that you're ever gonna see
638.25s - 642.97s |  So it's 500 500 sorry in 12 pages of OX a thousand bytes each
642.97s - 648.89s |  So four thousand ninety six bytes and each page contain chunks of some size. So it might be a chunk
649.53s - 655.61s |  Sorry in page 10, you may have chunks of size OX 100 in page 11. You may have chunks of size OX 30, etc
655.61s - 661.17s |  Etc. And then when you free a chunk, it will go into the free list for this chunk size
661.33s - 666.17s |  So if I free a chunk of size OX 100 it will go into the free list for size OX 100
666.17s - 671.73s |  If I free a chunk of size OX 10, it will go into the free list for chunks of this size as well
671.73s - 675.05s |  And the free list are singly linked list. They are lasting
675.57s - 679.81s |  First out so that means that if I free a chunk of some size and allocate a new one afterwards
679.81s - 686.25s |  It will be allocated exactly at the same spot and it's very similar for those who don't would do PT malloc
687.25s - 692.83s |  Exploitation to the leap city cage, but completely unlimited and without any protections
694.01s - 695.25s |  so
695.25s - 699.81s |  Just to give you an idea of what we can do with one to three bytes overflow in the PHP heap
699.85s - 703.21s |  Let's have a look at this example. So on the left you have the heap
703.65s - 710.33s |  Okay with five hundred and twelve pages and in page five in this example, I have chunks of size OX 400
710.45s - 712.61s |  So in page five, I have four chunks
713.17s - 718.73s |  In my example, I have chunk one that is allocated chunks free that is allocated checking two and four that are not
719.09s - 724.57s |  So in chunk two and chunk four since they are in the free list for chunks of size OX 400
724.69s - 727.49s |  That means that they contain a pointer to the next free chunk
727.89s - 732.73s |  So if I was to overflow even with one byte from chunk one
732.73s - 737.89s |  I would be able to at least partially modify the pointer that is control that is contained
737.89s - 743.85s |  Sorry in chunk two and that would be a way to alter some free list pointer and in the end probably
744.53s - 747.37s |  Be a good starting point for an exploitation
747.81s - 757.63s |  So the PHP heap it looks very very easy to exploit right? There's no metadata. It's page based. There's absolutely no protections
757.63s - 762.87s |  It's really easy to understand. So why is it that there are not that many remote binary exploits?
762.91s - 769.29s |  Well to me the main problem is that the PHP has the one heap for one request policy
769.39s - 773.27s |  So if you send an HTTP request PHP will create the heap
773.71s - 778.67s |  Allocate your HTTP parameters into it then run the script. So that means also compiling the script
778.67s - 782.99s |  So you will do like thousands of allocations and the allocations and then it will completely destroy the heap
783.31s - 787.99s |  So now imagine that you have a use-after-free on some VPN instance for instance
788.79s - 792.79s |  What you would do to exploits would be to send a few requests to set up your heap
792.95s - 800.25s |  Then one more request to like trigger your bug trigger your UAF and then afterwards send a few more requests to use your bug
800.63s - 805.67s |  But here you cannot do this. You have to find a way to trigger bug remotely
805.67s - 809.77s |  So you need a bug in the PHP engine you need an application that lets you trigger the bug remotely
809.81s - 815.13s |  But also you need to use the bug as the request is running before the heap is gone
815.13s - 820.05s |  And this is why it's hard because in between the triggering and the bug of the bug and the usage of the bug
820.05s - 823.83s |  You're not gonna have any way to interact with the HTTP request
823.83s - 827.89s |  Like you've sent every HTTP parameter and it's done like it's a black box now
828.37s - 832.01s |  And this is to me why it's really really hard to exploit on
832.85s - 839.60s |  PHP remotely
839.60s - 841.72s |  Okay. So in addition to this
841.72s - 847.32s |  There's one thing that we need to understand is how PHP processes PHP filter strings and to do so
848.12s - 850.28s |  You will have a two-step process
850.72s - 856.12s |  Where you will first read the resource as a stream and then it will apply filters one by one onto the resource
856.96s - 862.44s |  so fetching the stream it will use a very standard structure, which is called a bucket brigades and
863.80s - 867.80s |  Each part of the stream is represented as one bucket of a few bytes
867.84s - 868.96s |  So for instance
868.96s - 873.24s |  If you really see password the first bucket may contain five bytes of it is password
873.24s - 878.16s |  Then the second bucket will contain the next few bytes or for instance ten bytes and the buckets
878.16s - 881.32s |  We will contain a few more bytes that come right after etc, etc, etc
881.76s - 888.44s |  So that's a way to be able to represent any stream a list of buffers that are linked together and that may have different sizes
891.32s - 895.24s |  Once you have your stream you can start applying filters onto them
895.24s - 899.40s |  So you take the first filter and you take the first bucket and you apply the filter onto it
899.92s - 906.60s |  So for instance if it's base 64 decodes PHP will take the first bucket and decode the data disease that is into it
906.80s - 912.88s |  Then it will be able to process bucket 2 which it will do and then bucket 3 and at the end you get a new bucket
912.88s - 915.48s |  Brigade on which the first filter has been applied
915.60s - 920.52s |  So what you can do is start working on the second filter then on the third one, etc
920.80s - 926.56s |  Up until the end and now you have a stream that is being that has been completely processed with filters and
927.16s - 931.28s |  Your PHP filter string has been completely perfectly and look and old
932.24s - 934.68s |  So if we look back at everything now
934.68s - 939.52s |  It looks pretty easy to exploit this fabric because we have a fabric primitive and we want to get our C
939.52s - 943.12s |  But since we have a fabric primitive, well first we can read the binaries
943.12s - 948.12s |  So if I want to have the address of some of some symbol for instance in the lipsy
948.12s - 953.08s |  I just download the lipsy using the fabric primitive if I want to check if the lipsy is patched against the bug
953.08s - 955.56s |  I can also download the lipsy and check the code myself, you know
955.56s - 960.00s |  And so that means that you can find gadgets easily in addition to this
960.48s - 964.24s |  ASLR and PI are not a problem because I can just read proxmaps. So
964.80s - 970.92s |  Any address that I want is going to be probably in proxmaps. So ASLR and PI it's gone
971.44s - 977.28s |  A corollary to this is that the address of PHP the PHP heap is really easy to find in the proxmaps
977.28s - 980.32s |  So I have the address of the PHP which is going to be useful later
980.76s - 985.68s |  In addition to this it kind of feels like they can do arbitrary allocations and the allocations
986.12s - 988.80s |  Simply using the bucket brigade technology
988.80s - 990.68s |  So the way that the stream is
990.68s - 994.48s |  Represented if I can create as many buckets as I want with the sizes that I want
994.48s - 997.40s |  I will probably be able to build an exploit that works
999.32s - 1005.20s |  But on the other side I can I want to have an exploit that works well even in an unknown environment
1005.20s - 1009.00s |  So I don't want to build a new exploit when I'm targeting a wordpress or some very specific
1009.24s - 1014.28s |  Version of PHP or some magento with which has a lot of traffic on the website, you know
1014.28s - 1020.96s |  I want an exploit that just like straight-up works like basically a web exploit even though it's binary and also bonus points if it doesn't match
1022.48s - 1024.52s |  So how can we do this?
1024.52s - 1029.20s |  Well, the first one that we face is that even though there is the bucket brigade technology in PHP
1029.36s - 1032.00s |  You will always get one bucket when you read a stream
1032.00s - 1035.84s |  So if PHP reads ETC password, it will give you one bucket with the whole file
1036.08s - 1039.92s |  If it reads an HTTP resource, it will give you one brick one bucket
1039.92s - 1044.12s |  Sorry with the whole HTTP response into it same for FTP same for everything
1044.12s - 1050.32s |  You always get one bucket and one bucket. It's completely impractical for exploitation because we cannot spray the heap
1050.32s - 1053.60s |  We cannot pad the heap and we can't even use an altered free list
1053.60s - 1056.96s |  Like if we use one bucket to trigger the overflow, we have an altered free list
1056.96s - 1059.68s |  But then we need at least two more locations to be able to use this
1059.68s - 1065.44s |  This altered free list and we cannot do this because we have used our single bucket. So we're not going to be able to exploit
1067.16s - 1067.96s |  Luckily for us
1067.96s - 1073.28s |  There's a single filter that allows us to create as many buckets as we want and this filter is deadly bin flakes
1073.36s - 1075.36s |  What it does is that it will read?
1076.16s - 1078.16s |  your stream and decompress it as
1078.80s - 1083.28s |  With the Zlib algorithm and the way it works is that it will allocate eight pages
1083.80s - 1086.68s |  A buffer of eight pages and then decompress into it
1086.84s - 1091.16s |  If it's not big enough, it will create eight more pages and decompress the rest into it
1091.16s - 1095.24s |  If it's still not big enough, it will create a third bucket, etc, etc, etc
1095.56s - 1100.80s |  So this filter it gives us a way to go from one bucket to as many as we want
1100.84s - 1105.08s |  But the problem that we have is that every bucket has a size of eight pages
1105.08s - 1111.64s |  Which is way too big to exploit because well it takes more it takes two more space too much space
1111.64s - 1116.00s |  Sorry, and also it's not going to be allocated the same way as small chunks
1116.52s - 1118.52s |  so we need a way to change the size of
1118.96s - 1124.76s |  Each of these buckets and a way to do this is to use another filter, which is called G chunk
1125.24s - 1132.72s |  It's undocumented, but it's been used by many actors before so it's pretty well known and the idea is that it will take an HTTP
1132.72s - 1134.72s |  chunked uncoded
1135.08s - 1141.04s |  String and simply decode it. So for those who don't know the HTTP chunked encoding is very simple
1141.12s - 1142.12s |  it
1142.12s - 1144.00s |  consists of sending a
1144.00s - 1149.88s |  Size as ASCII X and then sending the data then a new size as ASCII X and then sending the data, etc
1149.88s - 1157.40s |  So the diction the teaching filter what it does is that it will read a size as ASCII X then reads the amount of bytes
1157.40s - 1158.64s |  That corresponds to this size
1158.64s - 1162.28s |  So for instance, if it reads 8 as in the example, it will read 8 bytes
1162.40s - 1166.36s |  Then it will read 11 and since it's ASCII X it's 17
1166.36s - 1172.60s |  So it will read 17 bytes and then you would read the read the D bytes and then it will read 0 and 0
1172.60s - 1179.96s |  It doesn't indicate an empty chunk. It indicates the end of the D chunking. So when you receive 0 it stops processing the data
1181.40s - 1182.64s |  so
1182.64s - 1186.48s |  Now you probably have an idea of how we can resize our chunks
1186.96s - 1189.96s |  We take bucket 1 if you wanted to have a size of 148
1190.16s - 1196.48s |  We write 148 then 148 bytes and then 0 if we want bucket 2 to have a size of 100
1196.48s - 1202.08s |  we do the same we write 100 then all bytes and then 0 and we do the same with every chunk and
1202.40s - 1206.96s |  Then when we apply D chunk on to this we expect it to resize every single bucket
1207.16s - 1212.24s |  but you may like notice that this will work because even though each bucket is
1213.20s - 1216.08s |  Different they are all processed as one stream
1216.12s - 1220.96s |  So if in bucket 1 you indicate that it's the end of the string of the stream
1220.96s - 1226.08s |  Sorry with the 0 at the very bottom. It will not process bucket 2. It will not process bucket 3
1226.08s - 1232.64s |  It will not process any bucket that comes after so you go back to a single bucket with an arbitrary size, which is completely useless
1233.28s - 1236.44s |  so luckily for us there's a way to improve this and
1237.20s - 1243.80s |  The way to improve this is to pad the size with thousands of zeros such as what we can see here
1243.84s - 1249.40s |  The idea is that in each bucket we will have one chunk size and one chunk data and that's it nothing else
1249.48s - 1252.04s |  So now if the D chunk filter is applied
1252.52s - 1255.20s |  We will have bucket 1 that gets processed
1255.20s - 1261.12s |  it will read the size read thousands of zeros then the real size then the data and then it will go on to bucket 2 and
1261.12s - 1267.00s |  Do exactly the same you will read the size read the data then bucket 3 read the size with the data and you can see
1267.40s - 1270.32s |  That's bucket 1 can be resized to the proper size
1270.32s - 1275.36s |  bucket 2 as well bucket 3 as well and bucket 4 as well and now we have a way to create as many buckets as
1275.36s - 1280.86s |  We want and change the size and this is only with two filters. So it's pretty promising
1282.96s - 1290.64s |  But that's not enough because we can only send one request so we need a whole exploits algorithm in a single request and
1291.28s - 1295.24s |  We have a single PHP filter string. So, how do we do this? Well instead of
1295.80s - 1302.44s |  Only being able to allocate once we cannot want to be able to allocate several times to represent the different steps of the exploits
1302.44s - 1306.60s |  In step one, I want to allocate a few times instead to I want to allocate a few more chunks, etc
1306.60s - 1308.98s |  Etc. And at this point we are not able to do this
1309.20s - 1313.40s |  But to do this what we can do is think about the PHP if it's page based
1313.40s - 1317.24s |  So if I focus my exploitation on one chunk size a single chunk size
1317.24s - 1322.36s |  That means that chunks that are bigger or smaller than this chunk size. They do not really matter
1322.36s - 1328.04s |  I will not have to think about them in my export algorithm if a chunk if of size or x 200 for instance
1328.04s - 1332.84s |  And I'm focusing on chunks of size or x 100 the chunk will not affect my exploitation
1332.84s - 1339.72s |  So at this point if I focus on some very specific chunk size such as weeks 100 chunks that are bigger or smaller
1339.72s - 1342.06s |  They do not matter. It's as if they were they weren't there
1342.06s - 1346.46s |  so the only thing that I need to be able to do is to be able to resize buckets as the
1346.52s - 1349.48s |  Exploitation goes on and to be able to do this. I built
1350.00s - 1351.48s |  buckets that are
1351.48s - 1357.52s |  Russian dolls of d-chunk algorithm. So the idea is that every time I call d-chunk on some buckets
1358.04s - 1364.76s |  Its size will change and that means that I can make buckets appear at some point in the exploitation and then others
1365.12s - 1367.56s |  appear at another step of the exploitation and
1367.96s - 1374.86s |  That basically means that I can allocate and deallocate at will and at this point. I'm really really close to getting an exploit working
1375.92s - 1377.04s |  and
1377.04s - 1383.20s |  the final idea here is that we have a one byte overflow using the icon bug and we want to
1384.92s - 1390.40s |  Use it to alter some free list and get complete control over it and the way that we can do
1390.40s - 1394.96s |  This is a six-step process, which is pretty simple, but I will still explain it to you. It's
1396.24s - 1398.16s |  First we will start in step one
1398.16s - 1402.96s |  So and we're gonna have three chunks ABC and each chunk is freed
1402.96s - 1405.96s |  We have A that points to B and B that points to C
1406.04s - 1410.20s |  Then we allocate these three chunks and we free them we get in step three
1410.20s - 1414.68s |  And the only difference with step one is that now we have C that points to B that points to A so we have reversed
1414.68s - 1415.60s |  the free list
1415.60s - 1421.24s |  Now we allocate in C a buffer which contains at offset 48 an arbitrary pointer
1421.28s - 1424.04s |  Which is represented here with 1 1 2 2 4 4
1424.68s - 1425.96s |  etc
1425.96s - 1432.16s |  Then we allocate B and A and then we free everything and we get into step 5 and we we have exactly the same
1432.76s - 1437.76s |  E play out and free list as in step 1 but in the chunk C
1437.76s - 1441.76s |  We have an arbitrary pointer at offset 48. So now you can probably see where this is going
1442.28s - 1445.76s |  We overflow using chunk A into chunk B
1445.96s - 1452.76s |  So the free list that was B to C is now B to C plus 48 and what we have in C plus 48 is
1452.76s - 1454.60s |  Another pointer that we added ourselves
1454.60s - 1460.96s |  So with three more locations, we will locate B C plus 48 and then we will allocate arbitrary pointer
1461.20s - 1468.16s |  And now we are able to have a write what where which is really really close to getting code execution
1470.16s - 1472.96s |  But now we have to think about like how we can do this
1472.96s - 1477.76s |  Well as I've said before the PHP heap, it's really easy to find it in proc set map
1477.76s - 1481.92s |  So we have it to us and also at the very top of the PHP heap
1481.92s - 1486.00s |  there is a send mmip structure that contains a few things and
1486.96s - 1490.48s |  Also a few alternative heap function pointers
1490.48s - 1493.48s |  So for those again, we do heap exploitation on ptMalloc
1493.48s - 1496.32s |  It would be the same as free hook malloc hook and realloc hook
1496.40s - 1500.40s |  Those are pointers that if you like set them to something else that null
1500.40s - 1503.16s |  They're going to be called inside of the original function
1503.16s - 1509.76s |  And so since it's basically the same as the glibc I can use the glibc technique and I can override free with system
1509.76s - 1515.24s |  So now when PHP wants to free a chunk, it will call free but it will instead call system and this gives me
1515.64s - 1520.12s |  This gives me sorry. Well way to call an arbitrary comment and
1521.04s - 1522.40s |  so
1522.40s - 1525.08s |  With everything put together. What do we have?
1525.20s - 1531.00s |  We have an exploit that works against any targets from PHP 8 to the current version
1531.00s - 1535.40s |  Which is sorry PHP 7 to the current version, which is h3 something
1535.40s - 1539.12s |  So that's 10 years of PHP covered with a single binary exploits
1539.12s - 1542.76s |  And also it works against any PHP application because we can pad the heap
1542.76s - 1548.08s |  So even if like the the website chooses a lot of chunks of size or extra hundred, it will still work
1548.08s - 1553.80s |  It doesn't matter in addition to this the exploit is completely deterministic. So it's 100% reliable
1554.00s - 1557.48s |  So you will never get a crash. So it's pretty cool and
1558.56s - 1561.16s |  final good thing about the exploits is that
1561.40s - 1566.80s |  The payload is really small because the first gadget that we use the first filter that we use is a Zlib inflate
1566.80s - 1570.32s |  so it will decompress the payload so originally it's compressed so it's very small and
1571.32s - 1578.60s |  The last good thing that we can say about the exploit is that it's completely self-contained like the old algorithm of the exploit is
1578.60s - 1583.60s |  In one PHP filter string, which means that you don't have to send additional get or post parameters
1583.60s - 1586.12s |  Like you just need your PHP filter string and you get SE
1586.68s - 1592.16s |  So every file reading primitive now that you have on PHP you have SE instead, which is pretty nice
1593.28s - 1597.00s |  I'm going to show you a demo that actually involves cosmic sting
1597.00s - 1601.96s |  Which is a Magento X6e which is pre-authentication and it came out after I published my bug
1601.96s - 1606.56s |  so it was in June and the original impact was being able to read files and
1607.40s - 1612.44s |  Using this file that you've read you would be able to craft API keys. And so you would get
1613.40s - 1619.16s |  An access which is similar to an administrator level on Magento, but you wouldn't be able to get SE
1619.40s - 1623.92s |  But with the bug that we have now we get the SE easily because we have an X6e
1623.92s - 1629.92s |  So we can force it into reading any file and therefore we can read a PHP filter string and get SE
1630.56s - 1633.09s |  so
1633.09s - 1635.01s |  quick demo
1635.01s - 1637.01s |  Which is not on the right screen
1643.53s - 1645.73s |  So I cannot see it but
1646.25s - 1652.61s |  It's probably pretty easy to understand you have the Magento website on the left and then you have an exploit on the right and in
1652.61s - 1655.73s |  A few moments you will have a shell on the bottom
1656.73s - 1664.56s |  There you go
1674.73s - 1676.73s |  Nope oh
1684.84s - 1686.84s |  Yeah, yeah, right, thanks
1687.92s - 1689.92s |  There we go, thank you
1691.00s - 1705.00s |  So, oh I lost my on the other screen. I lost it. Okay. There we go
1705.88s - 1707.88s |  Okay, does that work
1708.28s - 1709.60s |  Yeah
1709.60s - 1715.68s |  Okay. So now that we have exploited PHP filters, we want to do a completely different exploitation because
1716.24s - 1721.64s |  PHP filters are not the only way in which can reach icon using PHP
1721.72s - 1726.44s |  There's another way that is way simpler. It is when PHP calls icon directly
1727.16s - 1736.31s |  And so there's a PHP function that does this it's called icon. So
1736.95s - 1741.67s |  How do we exploit such a call to icon well, it's very very different to
1742.43s - 1745.27s |  The attack that we've seen using PHP filters
1745.71s - 1749.15s |  So here we don't have a favorite primitive
1749.15s - 1754.47s |  So we cannot just read proxy maps or read like the lipsy or anything like we need to go
1754.47s - 1756.15s |  I would say old-school
1756.15s - 1764.07s |  Exploitation where we need an info leak to get some pointers and then we can start going with the exploitation and in PHP generally
1764.07s - 1766.07s |  which when you want to have
1767.99s - 1773.35s |  An info leak what you do is that you will try and alter the length field of a ZenString
1773.55s - 1779.79s |  So ZenString it's the representation of PHP of your PHP string and the length field
1779.79s - 1781.41s |  It will store the size of the string
1781.41s - 1786.81s |  So if you are able to change the length of a string and then it gets it gets displayed
1786.81s - 1787.31s |  Sorry
1787.31s - 1787.81s |  well
1787.81s - 1795.39s |  you are able to make PHP display more bytes than it should and probably display like lots of useful information from the heap such as
1795.39s - 1797.11s |  addresses
1797.23s - 1802.83s |  Sadly for us the bug that we have as I've said really really bad. We only have one two, three bytes overflow
1802.83s - 1806.59s |  So if we try to overflow into a ZenString, we will just overwrite the ref count
1807.51s - 1810.39s |  With values that we don't even control. So it's pretty useless
1811.79s - 1813.79s |  so what we need to do is
1814.31s - 1819.75s |  Kind of the same as before where we alter some free lists and if we manage to alter some free lists
1819.75s - 1821.71s |  We are able to make two chunks overlap
1821.71s - 1827.03s |  And if we have two chunks that overlap we can use the first one to store a string that is bound to be displayed
1827.03s - 1832.43s |  And then use the second one on top of it to overwrite the length field and when the string gets displayed
1832.43s - 1836.39s |  We actually are able to see what comes afterwards in memory
1838.53s - 1842.83s |  The problem is that here we completely rely on the code beforehand
1842.83s - 1849.15s |  We could like implement an algorithm using PHP filters as I've shown but here we only have a single call to icon
1849.15s - 1851.15s |  And that's it. Nothing else. So
1851.39s - 1853.39s |  Getting it to work would
1854.03s - 1857.27s |  Make us like reliant on the code that comes after
1857.83s - 1863.55s |  The call to icon and to explain this a very simple example say that you have this piece of code
1864.99s - 1871.71s |  We control the output charset, we control the input text so it's clear that we can trigger the bug
1872.83s - 1876.27s |  But right after the bug has been triggered the script will end
1876.63s - 1881.79s |  So there's absolutely no way for us to use the bug after it's been triggered because the heap will be destroyed
1882.79s - 1888.31s |  If you're lucky, however, you might find a line such as this one after your call to icon
1888.87s - 1896.35s |  This line is the same as splits in Python. So it will take a string and explode it. So split it along a token
1896.35s - 1898.35s |  so here the token is new like and
1899.31s - 1901.39s |  If you have a line such as this one
1901.39s - 1907.43s |  you can create as many chunks as you want because it will take your string and split it along a non separator and
1907.75s - 1911.95s |  That will give you a way to use the bug right after it's been triggered and then probably
1912.51s - 1916.31s |  Exploits the bug. So this is what I call a code gadget actually
1916.31s - 1921.75s |  that's a way to get to using your bug starting from the
1922.55s - 1924.55s |  position where icon has been called and
1925.91s - 1930.47s |  To give you an idea of how it can be implemented in in the real world
1930.47s - 1935.23s |  I will show you a demo well and explain to you the demo on round cube
1935.87s - 1943.19s |  Round cube for those who don't know it's a web mail that is very much used in it's probably the most well-known in PHP
1943.23s - 1947.55s |  it's used by hostess generally or private companies even I've seen it a lot and
1948.91s - 1951.07s |  Well, yeah, it's it's used a lot
1951.59s - 1954.83s |  And so when you're logged into round cube and you want to send an email
1955.27s - 1957.63s |  You have to specify email addresses
1957.63s - 1963.95s |  And so you specify the two fields the CC field and the BCC field you can guess what they are
1963.95s - 1965.79s |  You've already sent an email
1965.79s - 1968.19s |  in addition to this you can send
1968.91s - 1972.75s |  Another parameter which is charset and every parameter that you send
1972.75s - 1975.67s |  So the underscore to underscore CC and underscore BCC parameter
1975.83s - 1980.35s |  They are all going to be cast to the charset that you said and it's going to be done using icon
1980.47s - 1985.19s |  So in this single script here, you have three ways of triggering your bug
1985.67s - 1990.79s |  you can trigger it using underscore to or with underscore CC or with underscore BCC and
1991.15s - 1997.95s |  Right after this there's something even better if one of the emails is not valid you will get an error message that says well
1997.95s - 2000.59s |  This is an invalid email colon your email
2001.31s - 2002.59s |  So what can we do with this?
2002.59s - 2008.71s |  Well, this is textbook the strategy that I was telling you about before the idea is that
2009.47s - 2014.99s |  You set underscore to to an invalid email so that invalid email gets it. It's ready to be displayed in the error message
2015.03s - 2018.83s |  so now what we want to do is modify its length before it's
2019.51s - 2020.95s |  Included in the error message
2020.95s - 2026.71s |  so then we use CC to trigger the bug and we have a free list that is altered and then we use BCC to
2026.71s - 2031.43s |  allocate a few strings so that we have a string that gets allocated on top of invalid email and
2031.71s - 2035.35s |  This will alter its size and therefore the error
2035.51s - 2041.35s |  When it gets displayed will display more bytes than it should and we will be able to get a memory leak, which is nice
2042.27s - 2044.99s |  So I implemented this and it was really fast. It took me a few hours
2044.99s - 2047.95s |  So I was really happy with it and I started it and it didn't work
2047.95s - 2053.03s |  And the reason for this is that when PHP when roundtube sends an error message
2053.03s - 2058.97s |  It's converted to JSON and when PHP converts to JSON every byte that is not valid UTF-8 is removed
2059.11s - 2064.13s |  so you have a memory leak, but you don't really have any bytes of interest because
2064.87s - 2067.07s |  Generally addresses are not going to be valid UTF-8
2067.07s - 2072.43s |  So they're just going to be removed any raw data in memory is not going to be valid UTF-8 is going to be removed
2072.43s - 2077.79s |  So what you get is a memory leak which consists of over like only ASCII characters and new bytes
2077.95s - 2079.55s |  Which is completely useless
2079.55s - 2083.47s |  But the idea is pretty good still we still want to do the same thing
2083.47s - 2087.63s |  but we just need to find a string that will not get modified too much before it's
2088.31s - 2089.83s |  Displayed and to do that
2089.83s - 2095.31s |  We just have to look at the framework and go a little bit deeper look at many many functions up until we find a viable
2095.39s - 2098.25s |  That gets displayed without being modified
2098.95s - 2103.87s |  Sadly for us when it gets displayed it gets displayed without being modified
2103.91s - 2110.99s |  It will not have a lot of codes in between the creation of the Bible and the display of the Bible
2110.99s - 2114.99s |  so it limits the number of gadgets that we can use and
2115.59s - 2116.75s |  well
2116.75s - 2121.19s |  It's honestly pretty much how to make this work, but you have to think at
2121.83s - 2126.23s |  Every line that you can use like every line in the code you can use it to
2126.67s - 2132.27s |  Go closer to your goal like every line can be an allocation or the allocation that would shape doing better for you
2132.27s - 2136.11s |  And I actually managed for that off in I think five days
2136.11s - 2139.99s |  It was really really long and I actually managed to get the leak
2139.99s - 2143.95s |  So it was nice because afterwards it's pretty easy to get a C
2143.95s - 2147.87s |  Once you have an address of some value in the PHP heap
2147.87s - 2154.35s |  You can just reproduce the same exploit, but this time use your free list corruption to arbitrate to allocate at an arbitrary
2154.95s - 2161.23s |  Position and that means that you can do that only attacks where you override some value that is in your session for instance
2161.27s - 2167.95s |  Maybe you want to overwrite your goals and set them to admin or maybe you want to override serialized data before it's the serialized
2167.95s - 2170.11s |  So that you have an arbitrary and serialized in PHP
2170.11s - 2174.79s |  Or you can also go like the standard way where you go for a binary attack
2174.87s - 2179.85s |  Where you want to control a YP like you started binary and you want to go like full binary
2179.91s - 2185.15s |  But I think the data only attack is more elegant and it fits more because you don't have to dump the binary
2185.15s - 2187.15s |  So it's it's easier
2187.51s - 2192.03s |  But like all of these that I'm saying it's actually only the visible part of the iceberg
2192.03s - 2196.23s |  It's really really like hard to pull off because first you need a proper heap setup
2196.23s - 2197.67s |  I haven't covered this part
2197.67s - 2202.63s |  It's really hard to do because the only thing that you can use to do your heap setup is HTTP parameters
2202.63s - 2207.47s |  But then the script gets compiled and you will use other scripts. They all get combined in the same heap
2207.47s - 2212.03s |  So you will like completely mess up the heap. It's really annoying to pull off in addition to this
2213.03s - 2214.07s |  Variable scope is here
2214.07s - 2219.95s |  Like if you have a method that is called and then it exists the method every variable that is in the method is going to be
2219.95s - 2221.39s |  freed so
2221.39s - 2223.47s |  Like it will completely change the heap as well
2223.47s - 2231.35s |  And also obviously it's very specific your attack to the server that you're targeting the application that you're targeting and also the settings
2231.35s - 2235.47s |  Like I think the original exploit that I built it was for roundtube in French
2235.47s - 2241.55s |  If I change the language to English it wouldn't work because the strings that I get allocated with error messages
2241.55s - 2246.95s |  They wouldn't be the same and that would completely change the shape of the heap. So again, it's a huge pain to pull off
2246.95s - 2248.95s |  So don't do it unless
2248.95s - 2250.71s |  really necessary
2250.71s - 2252.71s |  but it works and
2252.75s - 2254.75s |  I will show you
2256.82s - 2258.82s |  an exploit
2259.42s - 2266.80s |  Again
2270.44s - 2272.44s |  No, I need to find
2280.94s - 2282.94s |  Okay, same layout
2283.58s - 2290.06s |  you get a shell on the very bottom and exploits on top of this and the application on the left and
2298.06s - 2300.06s |  Now I need to remove it again
2301.30s - 2304.06s |  Each one of these this one. Nope
2305.66s - 2307.66s |  Nope
2307.94s - 2313.54s |  Yeah, okay a quick conclusion and maybe a few more words afterwards
2315.90s - 2323.26s |  So the bug was really bad honestly it had like lots of preconditions and even the bug was not that good like a really bad
2323.26s - 2325.14s |  overflow but
2325.14s - 2329.14s |  Luckily for us PHP exists and we actually are able to
2329.62s - 2331.14s |  do
2331.18s - 2332.26s |  Decent things with it
2332.26s - 2338.42s |  We have a new actor attack vector where we convert the favorite primitive into an RCE on any PHP version
2338.62s - 2344.66s |  Against any target if you're a favorite primitive you have RCE now, it's pretty nice. And also you add
2345.46s - 2349.46s |  application specific attacks such as the one that demonstrated on roundtube and
2350.22s - 2353.26s |  However, the bug is not PHP specific
2353.26s - 2358.74s |  So there could be a lot of other like targets, but I couldn't find any but maybe you will you know
2358.74s - 2363.74s |  and they might be discovered as time go by if people like tries to
2364.74s - 2368.78s |  well try to find a way to explain the bug and
2370.42s - 2376.22s |  The timeline will fast and I found the bug last year and I started exploiting it in February and
2376.54s - 2381.38s |  After a month and a half I could report it to the GDP security team and they were like really amazing
2381.38s - 2383.42s |  Like they were really fast after a week
2383.42s - 2387.54s |  I got a patch and they were really nice and they knew what they were doing which is
2388.46s - 2391.58s |  Well, it's not always the case to say the least and
2391.98s - 2396.38s |  So the bug got patched in a week and two weeks after after the embargo
2396.38s - 2400.58s |  it was released as CVE 2024 2961 and
2401.90s - 2404.54s |  Yeah, that's probably maybe the end of it for me
2404.54s - 2410.70s |  but I have published lengthy blog posts about the bug because there's so much to say about the bugs and
2411.02s - 2416.06s |  also the impact on the PHP ecosystem, which I couldn't cover here because we only have 45 minutes and
2416.38s - 2421.66s |  Also, there are exploits that are available on our github and also there's my Twitter if you want to ask questions
2421.66s - 2425.10s |  you can also have asked some questions like right after the talk and
2426.26s - 2429.06s |  Just to flex a little bit a few what-ifs
2430.70s - 2434.22s |  What if we have a favorite primitive, but we cannot see the output
2434.58s - 2438.62s |  We have a failure contents, but no echo in front of it. So we cannot read for except maps
2438.74s - 2443.74s |  We cannot read like any binary. So the expectation that I've shown you it doesn't work and
2444.30s - 2446.74s |  Also in some very very rare cases
2446.74s - 2452.02s |  they live in faith will not be present like you will not be able to decompress your stream so you will have to exploit with
2452.02s - 2454.02s |  one single pocket and
2454.26s - 2455.78s |  That looks impossible
2455.78s - 2460.98s |  but I was able to do both at the same time that was actually my very first exploits and
2461.62s - 2463.62s |  I will try and show you how
2465.38s - 2470.44s |  It's just a demo really sped up because it's really slow
2471.04s - 2475.64s |  Well at the end you get a shell the important part is on the left the source code
2475.64s - 2479.16s |  You can see at the very bottom you have a failure contents without an echo or anything
2479.16s - 2484.78s |  So I don't have the output and also on top of this. I have arbitrary allocation a random
2484.78s - 2490.68s |  Sorry allocations and the allocations just to show that the script is not very that it's not tailored to attack one PHP script
2490.68s - 2497.04s |  Like it could work against any PHP instance. And yeah, the exploit is not done yet. It's sped up like eight times
2497.04s - 2503.16s |  I think it's really really slow, but you get one bytes per one byte and at the end you have another shell. So yeah, that's it
2510.16s - 2512.20s |  Okay, I'm getting close. No
2512.88s - 2520.41s |  There we go
2520.41s - 2529.88s |  questions
2529.88s - 2531.88s |  Okay, I guess we're good. Ah, there's one
2535.59s - 2537.59s |  Yeah, thank you. This is amazing
2537.63s - 2544.15s |  So, how did you get to the round cube target and establish that those conditions were present that you were looking for?
2544.87s - 2546.87s |  so I
2546.87s - 2549.05s |  Thought that like emails to me
2549.91s - 2552.71s |  When you send an email you can kind of send the charset with it
2552.71s - 2558.51s |  So I cannot felt like webmails would be a good target to look at and I looked at wrong cube
2558.51s - 2565.27s |  And I saw that like it was a good target. So yeah, that's what oh cool pure intuition. That's amazing. Yeah
2565.99s - 2574.84s |  Well, thank you for listening to my talk


