# Media

url: https://www.youtube.com/watch?v=HHmxuxQ7bE8
title: DEF CON 32 - Windows Downdate: Downgrade Attacks Using Windows Updates - Alon Leviev
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=HHmxuxQ7bE8",
  "title": "DEF CON 32 - Windows Downdate:  Downgrade Attacks Using Windows Updates - Alon Leviev",
  "description": "Downgrade attacks force software to revert to an older, vulnerable version. In 2023, BlackLotus emerged, downgrading the boot manager to bypass Secure Boot. Microsoft addressed the threat, but was Secure Boot the only component vulnerable to downgrades?\n\nBy examining Windows Updates, we found a flaw enabling us to take full control over it and craft downgrading updates, bypassing all verification steps.\n\nWe then managed to downgrade DLLs, drivers, and even the kernel. Afterwards, the OS reported it\u2019s fully updated, unable to install future updates, with recovery tools unable to detect issues.\n\nWe aimed higher and found that the virtualization stack is at risk too. We successfully downgraded Hyper-V\u2019s hypervisor, Secure Kernel, and Credential Guard to expose privilege escalations.\n\nWe also discovered several ways to disable VBS, including its Credential Guard and HVCI features, despite its enforced UEFI locks. This is the first known bypass of VBS's UEFI locks.\n\nLastly, we found another vulnerability in a Windows Update restoration scenario, making the findings accessible to unprivileged attackers!\n\nIn this talk, we\u2019ll introduce \"Windows Downdate\", a tool that takes over Windows Updates to craft downgrades and expose dozens of vulnerabilities. It makes the term \u201cfully patched\u201d meaningless across any Windows machine worldwide.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2117,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 you good? Alright. Hello everyone and welcome to my talk. Today I'm going to share with you my
8.51s - 12.81s |  journey of researching downgrade attacks on Windows and their severe implications on
12.81s - 19.25s |  Windows' platform security. My name is Alon and I'm a security researcher at SafeBridge. I'm
19.25s - 24.63s |  22 years old and mainly self-taught. My focus reside in operating system internals, reverse
24.63s - 28.53s |  engineering and vulnerability research and before joining the security field I was a
28.53s - 34.93s |  professional Brazilian Jiu Jitsu athlete where I won several world and European titles. This is
34.93s - 38.97s |  what I will be talking about today. We have a lot of interesting topics to cover so let's jump
38.97s - 45.47s |  right in. Starting with the research background. So first things first, what are downgrade
45.47s - 50.31s |  attacks? Downgrade, downgrade attack is the act of downgrading immune and fully up to date
50.31s - 56.05s |  software to uh to uh an old and vulnerable software. And this act allows to expose past
56.05s - 62.55s |  vulnerabilities in updated software and then exploit such vulnerabilities. My research
62.55s - 66.79s |  started from from studying the Black Lotus UEFI bootkit and what caught mine and everyone
66.79s - 71.83s |  else's attention with Black Lotus was the fact that it was able to bypass secure boot on a
71.83s - 76.49s |  fully updated Windows 11. But in fact Black Lotus did not exploit a new zero level
76.49s - 82.81s |  vulnerability. Instead it exploited an already known and patch vulnerability. And that was of
82.81s - 88.57s |  course done by employing a downgrade attack. To give you a better understanding of how Black
88.57s - 93.41s |  Lotus' downgrade was formed to bypass secure boot, you first need to know what is secure boot.
93.41s - 97.91s |  So simply put, secure boot is a security feature which is responsible to verify that each
97.91s - 102.25s |  component in the boot chain is digitally signed. It is very simple. If you are not signed
102.25s - 106.83s |  you are not loaded. And so the days of floating a custom bootkit by replacing the boot manager
106.83s - 113.57s |  are gone. Instead what Black Lotus did was to downgrade the Windows boot manager to signed
113.59s - 118.97s |  but vulnerable version of it. And this allowed to then exploit a new vulnerability sourced in
118.97s - 125.23s |  the vulnerable boot manager to then bypass secure boot. Microsoft's mitigation against
125.23s - 129.41s |  secure boot downgrades included multiple actions with the main one being revoking vulnerable
129.41s - 136.41s |  boot managers and boot applications. And revoked images are of course not allowed to be loaded.
136.41s - 141.69s |  But here comes the critical question. Are there any other components other than secure boot
141.69s - 147.29s |  that may be vulnerable to downgrade attacks? My goal in this research was to evaluate the
147.29s - 152.25s |  state of downgrade, downgrade attacks on Windows and to find if components other than secure
152.25s - 158.90s |  boot may have been overlooked. Now I'm sure you're all familiar with bring your own vulnerable
158.90s - 164.10s |  driver attacks targeting third party drivers. My vision was to target first party entities
164.10s - 170.24s |  not only drivers but even entities residing in the lower level than the kernel. My vision was
170.26s - 176.84s |  to create a new category of bring your own vulnerable Windows. To kick off my research I've
176.84s - 180.98s |  had to first form a reliable downgrade ability which led me to define what would be
180.98s - 186.12s |  considered a perfect downgrade attack. So first the downgrade must be fully undetectable so
186.12s - 190.86s |  that EDRs will not block the downgrade. Thus I aimed to perform the downgrade in the most
190.86s - 195.86s |  legitimate way possible. Second the downgrade must be invisible so that future updates so so
196.28s - 202.84s |  that the downgraded components should uh will not appear up to date um even if they're
202.84s - 208.52s |  technically downgraded. Third the downgrade must be persistent so the future software updates
208.52s - 213.36s |  are not overriding the downgrade. And then fourth the downgrade must be irreversible so that
213.36s - 220.40s |  scanning and repairing tools will not be able to detect or repair corruptions. Having the
220.40s - 225.24s |  downgrade requirements defined I then looked for a suitable component. But before I expose
225.24s - 230.52s |  the target component I want to ask you. What would be the least expected component to
230.52s - 238.82s |  perform downgrades? That would be of course Windows updates. So let's talk about Windows
238.82s - 246.33s |  updates and see if they can be abused to perform downgrades. The Windows update
246.33s - 250.57s |  architecture is as follows. We have an update client and an update server and they
250.57s - 254.77s |  communicate over com. For those of you who are unfamiliar with com this is just an
254.77s - 258.17s |  enterprise communication method in Windows and this is how the client and the server
258.17s - 264.07s |  communicate. Administrator is usually forced on the client side and Trusted Installer is
264.07s - 269.61s |  always enforced on the server side. And the last piece and the most important one is that
269.61s - 275.35s |  system files once owned and updated by Windows updates are only accessible to Trusted
275.35s - 280.35s |  Installer. So even administrators or anti-system cannot directly modify these system files. And
284.56s - 289.16s |  this is where I found the first design problem in Windows updates. Administrator to
289.16s - 293.32s |  Trusted Installer is not considered a security boundary and there are multiple working
293.32s - 299.66s |  public proof of concepts of such elevation. So the Windows update team attempted to secure
299.66s - 305.44s |  the update process by enforcing Trusted Installer. However since updates are only accessible
305.44s - 311.14s |  to administrators, Trusted Installer is rendered completely ineffective. The only issue
311.14s - 316.18s |  though is that administrator to Trusted Installer elevations are considered malicious and
316.20s - 321.30s |  are blocked by EDRs which of course contradicts my first downward principle which is being
321.30s - 326.98s |  fully undetectable. Now I could of course try to bypass the elevation detection which may
326.98s - 331.28s |  have been possible but then I would have to implement the update process myself which could
331.28s - 336.22s |  still be seen as malicious. And so the best option for me was to find the flaw in the update
336.22s - 343.02s |  process which solves all of those problems. So let's take a look on a simplified flaw of the
343.04s - 348.24s |  Windows update process. First, the client asks the server to perform an update given an
348.24s - 355.24s |  update folder. The update folder is supplied by the client. Second, the server validates
355.24s - 361.62s |  the integrity of the update folder. Third, following the verification, the server operates
361.62s - 366.32s |  on the update folder to finalize the update files and these are saved to a server controlled
366.32s - 370.86s |  folder, one that is not accessible to the client. And so at that point, the client cannot
370.86s - 378.36s |  modify the finalized update files. Fourth, the server saves an action list to a server
378.36s - 383.52s |  controlled folder as well, not accessible to the client. This action list is named pending
383.52s - 388.26s |  dot XML and this contains the update actions to perform. So for example it specifies the
388.26s - 394.74s |  files to update, the source and destination files etcetera. Lastly, when the operating system
394.74s - 399.98s |  is rebooted, the action list is operated on and the actions uh and the update actions are
399.98s - 407.46s |  performed during the update uh during the reboot. Now the client only controls the initial
407.46s - 412.20s |  update folder and so I decided to look at this folder first and see maybe I can modify it
412.20s - 419.00s |  resulting in custom downgrading update files. And as we already know, integrity checks are
419.00s - 426.62s |  performed on the update folder so let's see how well the integrity checks are performed. The
426.62s - 432.24s |  update folder contains update components and each update component contain a manifest
432.24s - 439.00s |  MUM differential and catalog files. The MUM files are Microsoft update metadata, they
439.00s - 445.44s |  contain metadata information, so component dependencies, installation order etcetera. The
445.44s - 450.58s |  manifest files contain installation specific information such as file path, uh registry keys
450.58s - 456.76s |  which installers to execute as part of the installation and more. The differential files are
456.76s - 462.74s |  delta files from the base files and so a base plus delta would result in the full final update
462.74s - 469.72s |  file. And lastly we have the catalog files which are the digital signatures of the MUM and
469.72s - 474.98s |  manifest files. Catalogs allow signing multiple files at once instead of having the file
474.98s - 480.96s |  that we want to sign embed its digital signature inside of it. In addition, the catalog files
480.96s - 486.46s |  are digitally signed themselves which makes it impossible to modify them or any of the files
486.46s - 490.34s |  that they protect. So we can't modify the catalogs and we can't modify the files that they
490.38s - 497.38s |  protect that they sign. To recap, only cat- only the catalog files are digitally signed. The
497.38s - 502.66s |  manifest and MUM files are not explicitly signed but they are signed in the catalog files. And
502.66s - 507.46s |  the differential files are not signed at all and the differential files also control the final
507.46s - 513.80s |  update file content which is very, very interesting. Is there any chance the differential
513.80s - 520.75s |  files were left behind in terms of verification? No luck because the expected update file
520.79s - 526.09s |  hash is hardcoded in the manifest. And the manifest cannot be changed since it will break its
526.09s - 533.73s |  signature in the, in the catalog. Now at that point I decided to look at the action list. I knew
533.73s - 538.17s |  that it's gon- it's, it's, it cannot be changed because it is trusted in solder and force so I
538.17s - 543.25s |  cannot change the action list directly but I also knew that the update up, that, that update
543.25s - 547.85s |  process is performed over multiple reboots and so I assumed that the state of this list is
547.85s - 554.03s |  saved somewhere. And if I could modify the state, maybe I was, I would be able to uh, create a
554.03s - 560.37s |  custom downgrading action list. So I searched the action list path in the registry and then I
560.37s - 566.31s |  found this very interesting key named POQXXCMD line. It holds the executable that parses the
566.31s - 571.21s |  list and the list path. I then looked at the security attributes of this key and I was
571.21s - 578.23s |  extremely surprised to find that this key is not trusted in solder and force. And this allowed
578.23s - 584.57s |  me to control all of the update actions. This is how the action list looks like in practice.
584.57s - 589.67s |  It is an XML file that gives the functionality of creating files, deleting files, moving
589.67s - 593.71s |  files, hard linking files, creating registry keys and values, deleting keys and values and
593.71s - 600.62s |  much much more. In order to downgrade we can use the hard link file action and the source will
600.62s - 609.21s |  replace the destination. To initiate an update all that is needed is to set the trusted in
609.21s - 615.47s |  solar service as auto start and add the action list and its identifier in the registry. The
615.47s - 620.11s |  identifier is a dynamic number which is compared with the action list identifier. So the
620.11s - 625.91s |  identifier is needed for integrity purposes but since we control both the registry identifier
625.91s - 630.43s |  and the identifier in the action list because we control the action list path, then this is
630.43s - 635.67s |  not a problem because we can adjust them accordingly. Now the most important thing is that none
635.69s - 641.73s |  of these three actions is trusted in solar and forced. And this allowed me to update the
641.73s - 647.33s |  system with a custom downgrading action list. All of the integrity verifications are bypassed
647.33s - 652.31s |  since the action list is assumed verified as it is created post verification. There is no
652.31s - 657.25s |  need to perform the malicious trusted in solar elevation. Instead Windows updates does all
657.25s - 663.95s |  of the work for me and this is a complete Windows update takeover. Now revisiting the
663.97s - 668.87s |  downgrade principles, of course the downgrade is fully undetectable, there is no better way to
668.87s - 675.92s |  downgrade Windows. In terms of invisibility, the system will appear up to date as we basically
675.92s - 681.52s |  updated the system and we didn't uninstall anything. In terms of persistency of the
681.52s - 685.90s |  downgraded components, I found that the action list parser is not digitally signed and so I
685.90s - 690.70s |  patched it to install empty updates. And as a result, even after the downgrade when new
690.74s - 697.58s |  updates are available, they will be falsely installed. And in terms of recovery, the
697.58s - 701.92s |  integrity and repair utility is not digitally signed as well and so I patched it as well as
701.92s - 708.42s |  part of the downgrade. And the patched version will no longer detect any corruptions. With
708.42s - 713.76s |  that, let's see the first demo of the day. This demo will demonstrate downgrading a kernel
713.76s - 718.84s |  driver named afd.sys to an old and vulnerable version of it by using the Windows update
718.88s - 725.38s |  takeover. And then we'll see how the same kernel driver is exploited to achieve kernel code
725.38s - 731.37s |  execution. So first we check the Windows version and then we will make sure that we are
731.37s - 736.35s |  fully up to date and that we have no missing updates as you can see. We'll then uh use CMD
736.35s - 740.95s |  and we'll use the seek check utility to see what is the current version of afd.sys, the driver
740.95s - 746.05s |  that we are targeting. Is it fully up to date? You can see that the current version is 3672
746.05s - 750.19s |  which is patched to the vulnerability that I want to exploit. If we use task list to find
750.19s - 754.79s |  the current process ID and then we try to actually exploit a vulnerability, which the exploit
754.79s - 758.33s |  gets a process ID and tries to elevate the system, you can see the LP failed because the
758.33s - 763.33s |  driver is patched. So we'll then use Windows downdate which gets a config file that says
763.33s - 767.97s |  downgrade the afd.sys driver to an old and vulnerable version of it. You can see that the
767.97s - 774.63s |  attack succeeded. We now need to restore the machine in order for the update to take place.
774.63s - 778.63s |  You can see um we we fast forward a bit, we'll log back into the machine after the update,
778.63s - 782.87s |  we'll launch CMD and let's see what is the current version of the driver that we are
782.87s - 790.48s |  targeting. Was it updated? And you can see that the current version is the base version.
790.48s - 795.12s |  Although the system was updated, what actually happened is that it downgraded. We can see
795.12s - 799.56s |  that we are not currently system. If we try to exploit a vulnerability again, we get a
799.56s - 805.46s |  process ID and then we ex-execute the exploit again. You can see that it succeeded and we
805.46s - 813.62s |  are now anti-authority system. Thank you. Thank you. We're just getting started guys. If we
816.76s - 824.10s |  check for updates you can see that we are fully up to date. So what did we achieve so far?
824.10s - 829.36s |  We gained a perfect downgrade ability and we gained kernel code execution. Our starting point
829.36s - 834.00s |  was administrator so that was an administrator to kernel elevation. Now administrator to
834.00s - 838.24s |  kernel is not considered a security boundary in Windows but gaining kernel code execution
838.26s - 842.50s |  is still a threat and of course it gives much more functionality than administrator
842.50s - 848.88s |  functionality. Although it is not a boundary, admin to kernel is still a threat and a serious
848.88s - 854.02s |  one because nowadays lots of users are still running as administrators and running as
854.02s - 859.58s |  administrator is also the default on Windows. And as a result, many users could easily
859.58s - 865.70s |  compromise the kernel and this is an issue that Microsoft aimed to solve. Microsoft's
865.72s - 869.86s |  solution was to de-privilege the kernel to make kernel access less valuable than it
869.86s - 874.70s |  previously was. And the way that this privileging, de-privileging was done is by
874.70s - 882.28s |  introducing a feature called virtualization based security or VBS for short. VBS is a
882.28s - 889.72s |  secure and isolated virtual environment powered by the IPV hypervisor for isolation. And
889.72s - 894.68s |  again the reason that VBS was introduced is because the kernel is assumed compromised and
894.70s - 899.54s |  can no longer be trusted. There was a need for a secure place to implement critical
899.54s - 907.28s |  security features and store secret keys. VBS features include the famous credential guard,
907.28s - 912.26s |  HVCI, system core secure launch, um, shielded VMs and much more security features that
912.26s - 917.66s |  really improved the security of Windows. And now that I've praised VBS so much, you may
917.66s - 924.44s |  wonder how all of these works in practice. So before VBS, this is how Windows
924.46s - 929.32s |  architecture looked like. We've had user mode in ring 3, we've had kernel mode in ring 0
929.32s - 936.34s |  and then we've had the hypervisor running in ring minus 1. With VBS, the hypervisor
936.34s - 941.84s |  introduces virtual trust levels or VTLs and the way it works is that the higher the VTL, the
941.84s - 948.08s |  more privileged it is. So simply put, VTLs are like virtual machines. Lower VTLs should not
948.08s - 954.66s |  be able to access memory or compromise higher VTLs. Currently on Windows, only 2 VTLs
954.66s - 959.68s |  exist. VTL 0 known as normal mode and VTL 1 known as secure mode. Normal mode contains
962.88s - 967.84s |  the original operating system and secure mode contains only the critical security features
967.84s - 972.42s |  and mitigations as well as key isolation technologies. And everything that is implemented
972.42s - 977.06s |  in the secure mode should not be compromised from normal mode, even if we talk about normal
977.06s - 985.38s |  mode's kernel. Now when looking at security features and mitigations, the first thing to do
985.38s - 989.66s |  is of course to check if the security features that we are targeting can be easily turned
989.66s - 995.20s |  off. I wondered if VBS features could be easily turned off. Since they protect from
995.20s - 1000.00s |  administrators, configuration modifiable by administrators would be ineffective because an
1000.00s - 1006.84s |  attacker would just turn off VBS instead of dealing with it. The way that VBS protects such
1006.84s - 1011.84s |  disablements is by implementing a feature called a UEFI lock. The UEFI lock is a UEFI boot
1011.94s - 1019.44s |  service variable that holds the VBS configuration. So if VBS is configured with a lock, the lock
1019.44s - 1025.06s |  is the source of configuration instead of the Windows registry. Then changing the registry
1025.06s - 1031.10s |  configuration will have no effect. The UEFI variable is the source of truth. And of course
1031.10s - 1035.60s |  the boot service variable that holds the configuration cannot be accessed in runtime from
1035.60s - 1040.34s |  the operating system, but only during boot. So this is a very simple and reliable
1040.34s - 1048.03s |  protection. If the user really wants to disable VBS, if it's configured with a UEFI lock, he
1048.03s - 1054.51s |  must load a custom EFI application signed by Microsoft. And this EFI would then ask the
1054.51s - 1060.41s |  user during boot to physically approve the disablement. And only if the user approves, VBS
1060.41s - 1066.55s |  is disabled. Now the key element here is that all of this is performed during boot and the
1066.55s - 1071.59s |  assumption is that only signed code is allowed to run because of secure boot. And the only
1071.59s - 1077.29s |  signed code that touches the configuration, the variable, requires physical access. So without
1077.29s - 1085.10s |  physical access to the target machine, it should not be possible to disable VBS. With the
1085.10s - 1089.46s |  ability to control any file on the operating system, I wondered what will happen if I try to
1089.46s - 1095.14s |  replace the secure kernel or the hypervisor, hypervisor powering VBS, with invalid files. For
1095.14s - 1101.42s |  example, files that are not digitally signed, attacker controlled files. I believed that the
1101.42s - 1106.18s |  result would be the machine booting into the recovery environment and that is because
1106.18s - 1114.14s |  invalid files are a sign of compromise. Instead, I was extremely surprised to find out that if
1114.14s - 1119.74s |  the operating system loader fails to validate one of VBS's files, it will just boot normally
1119.74s - 1125.98s |  abandoning VBS. I repeat, if the OS loader fails to validate one of VBS's files, it just boots
1125.98s - 1132.40s |  normally. And this can be used to disable VBS by passing the UEFI lock. And as far as I
1132.40s - 1137.86s |  know, this is the first bypass of VBS's UEFI locks and this is a very simple bypass. All we
1137.86s - 1142.56s |  need to do is to replace the secure kernel, the hypervisor of any VBS's files with invalid
1142.56s - 1148.74s |  files. Very simple. So now it's time for another demo of chaining all of the capabilities
1148.74s - 1153.78s |  gained so far together. In this demo I will show credential extraction against the most
1153.78s - 1160.26s |  restrictive settings. Those settings will be PPL enabled for LSS with UEFI lock protecting
1160.32s - 1167.32s |  LSS dumps. Um credential guard will be enabled with UEFI lock protecting secrets in VTL1 and
1167.32s - 1172.10s |  Windows Defender will be up and running. The way that all of these will be bypassed is by
1172.10s - 1177.34s |  first reverting the PPL fault patch to allow PPL bypass. Second, disabling credential guard
1177.34s - 1181.80s |  by passing the UEFI locks. And third, turning Windows Defender on functional by invalidating
1181.80s - 1188.54s |  the main Defender executable MSMP engine. Now just before I show you the demo, it is
1188.56s - 1193.20s |  important to understand that credential guard and PPL for LSS are complementary. So if any
1193.20s - 1199.26s |  only credential guard is bypassed, LSS cannot be dumped. And if only PPL is bypassed,
1199.26s - 1202.84s |  credentials are encrypted and not usable. So this is what you will see if you try to dump
1202.84s - 1208.04s |  credentials on a system with credential guard on. So let's see the demo of bypassing
1208.04s - 1213.02s |  credential guard, PPL for LSS and Windows Defender all in once by utilizing downgrades and
1213.02s - 1219.23s |  the UEFI lock bypass. So first we check the Windows version and then we'll make sure that
1219.25s - 1225.65s |  we are fully up to date. Which you can see we have no missing updates. We'll then use SK
1225.65s - 1230.29s |  tool to see um which is tool supp- supplied by Microsoft to see what VBS features are
1230.29s - 1235.73s |  running. You can see that the uh uh the VBS is protected with UEFI lock. It's locked in UEFI
1235.73s - 1240.67s |  and credential guard and key guard are currently running. We then use system informer to
1240.67s - 1246.37s |  see what is the current state of LSS. You can see that it's run- it runs as PPL and then
1246.41s - 1249.85s |  let's check that Windows Defender is up and running as well. We try to copy malicious files
1249.85s - 1253.41s |  outside of the excluded directory. You can see that we can't use them and that Windows
1253.41s - 1259.29s |  Defender detects them as malicious because it's up and running. Now it's time to execute
1259.29s - 1265.38s |  the attack. We will use Windows downdate. We'll change directory to the Windows downdate
1265.38s - 1269.98s |  directory. And we will supply Windows downdate with the config file that will say
1269.98s - 1276.52s |  downgraded PPL fault patch, bypass the UEFI locks to disable VBS and invalidate the main
1276.52s - 1281.06s |  defender executable to turn it unfunctional. You can see that the attack was successful. We
1281.06s - 1285.56s |  finished the attack. These are the files that were updated and all we need to do is to
1285.56s - 1290.60s |  restore the machine. So you can see, you you will see now that updates are underway but in
1290.60s - 1296.50s |  practice what happens is that downgrades are underway. We fast forward, we log back into
1296.50s - 1305.69s |  the machine. Now let's launch SK tool again to see what is the current state of VBS. Now you
1305.69s - 1309.13s |  will see that the secure kernel is not currently running, credential guard is not currently
1309.13s - 1313.09s |  running as well. So the UEFI lock has been bypassed and credential guard is no longer
1313.09s - 1317.93s |  protecting credentials. We'll then launch uh system informer and we will see what is the
1317.93s - 1322.31s |  current state of us. As you can see it runs as PPL. So we'll need to bypass it. And now let's
1322.31s - 1326.57s |  check what is the state of Windows Defender. We'll copy malicious files outside of the
1326.57s - 1331.55s |  excluded directory. And you can see that it worked successfully. So we defeated Windows
1331.55s - 1337.89s |  Defender as well. We'll launch CMD CMD again and now it's time to bypass PPL. We'll change
1337.91s - 1342.89s |  directory, we'll get the core, the process ID of LSAS and then we'll try to execute PPL
1342.89s - 1347.85s |  fault. And remember PPL fault should have been patched in the system and it is seemingly
1347.85s - 1356.51s |  patched in the system. We'll execute the attack and let's see what happens. So PPL fault was
1356.51s - 1360.89s |  successful. The dump file was created on the desktop as you can see. We'll now use Mimikatz to
1360.89s - 1364.63s |  parse the dump file and extract with credentials that should have been protected by
1364.63s - 1370.17s |  credential guard. We'll load the dump file and extract credentials. You can see credentials
1370.19s - 1377.23s |  are extracted and this credential should have been protected by credential guard. Now just
1377.23s - 1381.61s |  to make sure that we are fully up to date and that everything looks correct. We'll check for
1381.61s - 1388.53s |  updates. And you can see that we are fully up to date. Thank you. Thank you. Ok so we
1398.57s - 1404.01s |  bypassed the UEFI locks and defeated VBS but now it's time to talk about real security
1404.03s - 1410.77s |  boundaries. The security boundaries that VBS introduces are any VTL0 to VTL1 transition is
1410.77s - 1415.75s |  considered a security boundary, an elevation of privilege. No VTL0 code should be able to
1415.75s - 1420.75s |  compromise VTL1 code. And another boundary is ring 3 to ring 0 uh sorry any ring 3 to ring 0
1423.65s - 1429.93s |  um sorry any ring 3 or ring 0 to ring minus 1 um so user mode to or kernel 2 hypervisor is
1429.95s - 1434.61s |  considered an elevation of privilege. And due to the way that VBS is implemented
1434.61s - 1441.43s |  compromising the hypervisor gives complete control over all of the VTLs. Now when looking at
1441.43s - 1447.17s |  VBS downgrades my main goal was to understand if there was a downgrade detection, mitigation
1447.17s - 1452.21s |  such as versioning checks or revocation mechanism. And if no downgrade mitigation was found
1452.21s - 1458.05s |  regardless of how far I could go with the downgrade I considered this as a vulnerability. And
1458.05s - 1462.53s |  that is because when new vulnerabilities will get patched in the target component it will
1462.53s - 1467.57s |  make the exploitation much easier. So even if not immediately exploitable it is truly
1467.57s - 1474.45s |  something that needs to get fixed. Firstly I targeted secure modes isolated user mode
1474.45s - 1480.13s |  processes. And the most known isolated user mode process is credential guard. So I decided
1480.13s - 1485.57s |  to target it first. Credential guard is implemented as an isolated user mode process
1485.57s - 1491.57s |  named LSAISO which stands for LSA isolated. With credential guard running, secrets are
1491.57s - 1497.15s |  stored in LSAISO in VTL 1 instead of in the original LSAISO process. And this is why
1497.15s - 1501.73s |  dumping LSAISO with credential guard is no longer valuable. Because LSAISO only contains
1501.73s - 1507.09s |  the encrypted blobs and the real secrets ones that are uh once that the attacker is
1507.09s - 1515.99s |  interested in are only accessible um to in VTL 1 and not in VTL 0. I decided to target a
1515.99s - 1523.33s |  downgrade with CV 2022 34709 which is a fixed elevation of privilege in credential guard. I
1523.33s - 1528.87s |  found both the vulnerable module which is Kerpli insured and the vulnerable version.
1528.87s - 1532.53s |  Downgrading the vulnerable module using the Windows update decoverer worked well on a
1532.53s - 1538.27s |  fully patched machine. And this allowed escalating privileges from ring 3 VTL 0 to ring 3
1538.27s - 1543.71s |  VTL 1 compromising credential guard and all of the secrets that it protects. There was no
1543.73s - 1550.67s |  downgrade detection on VTL 1 isolated user mode. Now isolated user mode privileges are great
1550.67s - 1554.75s |  but I wanted to gain even higher privileges. So I then moved on to target secure mode's
1554.75s - 1561.69s |  kernel which is more privileged than isolated user mode. The kernel of secure mode is called
1561.69s - 1566.69s |  secure kernel and it is a minimal kernel that only implements security features such as
1566.71s - 1571.71s |  HVCI, HyperGuard and more. I decided to target this downgrade with CV 2021 27090 which is a
1574.89s - 1580.19s |  fixed elevation of privilege in secure kernel. The only vulnerable module here could be
1580.19s - 1585.27s |  secure kernel itself but in this case downgrading only the secure kernel did not work. It
1585.27s - 1591.27s |  wasn't enough for me. I've had to downgrade dependency modules as well and only then it
1591.35s - 1597.43s |  worked on a fully patched machine. And this allowed escalating privileges from ring 3 VTL 0 to
1597.43s - 1604.63s |  ring 0 VTL 1 compromising the entire VTL 1 and any of the mitigations including HVCI,
1604.63s - 1609.77s |  HyperGuard and more. There was no downgrade detection on the secure kernel and the secure
1609.77s - 1616.23s |  mode either. Now secure kernel privileges are great but I wanted to gain even higher
1616.23s - 1621.57s |  privileges. So I then moved on to target the most privileged entity of VBS which is the
1621.59s - 1627.97s |  Hyper-V hypervisor. The hypervisor is HVIX on Intel systems and HVAX on AMD systems. The
1631.37s - 1638.86s |  hypervisor is a stand alone microkernel which makes it a valuable target for downgrades. With
1638.86s - 1643.90s |  the hypervisor though it was more challenging to target a specific vulnerability. And that
1643.90s - 1648.70s |  is because many vulnerabilities titled Hyper-V elevation of privileges were fixed over the
1648.70s - 1654.74s |  last 2 years. But Hyper-V is a very large component. And in CV descriptions Microsoft do
1654.74s - 1661.84s |  not share which component in the Hyper-V stack is the vulnerable one. So it could be um a an
1661.84s - 1666.28s |  elevated user mode process, it could be a kernel driver or it could be the hypervisor itself
1666.28s - 1671.28s |  which is the only component that I am targeting in the Hyper-V stack. And so I decided to go
1671.28s - 1676.28s |  2 years backward to prove the vulnerability. Because 2 years is old enough to be confident
1676.30s - 1680.80s |  that there was at least one hypervisor elevation of privilege vulnerability unfixed in the
1680.80s - 1686.54s |  old hypervisor. Downgrading the hypervisor and the hypervisor loader worked well on a fully
1686.54s - 1692.16s |  patched machine and the cross security boundary here was ring 3 VTL 0 to ring minus 1
1692.16s - 1696.92s |  potentially compromising the entire visualization stack. And this rendered the entire
1696.92s - 1703.06s |  visualization stack vulnerable to downgrade attacks. So let's see a demo of the hypervisor
1703.08s - 1708.94s |  downgrade. First as usual we check the Windows version and then we make sure that it is fully
1708.94s - 1715.65s |  up updated and that we have no missing updates as you can see. We'll then launch SK tool again
1715.65s - 1719.93s |  but this time we're interested to see what is the current state of the hypervisor. You can
1719.93s - 1723.73s |  see the hyper the Microsoft hypervisor was detected and the current version is 2 2 6 2 1
1723.73s - 1728.47s |  which is the base version. You can also see the VBS runs as usual. We'll then use Windows
1728.47s - 1732.77s |  downdate with a config file that will say downgrade the hypervisor to a 2 years old
1732.81s - 1737.21s |  hypervisor. The attack was succeeded, you can see the update files. We now restore the
1737.21s - 1745.00s |  machine in order for the update to take place. We fast forward, Windows is updating. What
1745.00s - 1749.94s |  happens under the hood is that the hypervisor is being downgraded. We log back into the
1749.94s - 1754.94s |  machine and let's see what is the current state of the hypervisor. We run SK tool again and
1757.62s - 1763.08s |  we can see that the hypervisor is still detected but it's version is 2 2 0 0 0 which is a
1763.08s - 1767.72s |  2 year old version. You can also see what's interesting here is that VBS is running as
1767.72s - 1772.02s |  usual. So credential guard everything is running with an old hypervisor. And if we check
1772.02s - 1780.78s |  that we are fully up to date, you can see that we are. Ok so overall I found no downgrade
1780.78s - 1786.42s |  mitigation in any component of the virtualization stack. The entire stack was found to be
1786.42s - 1793.19s |  vulnerable to downgrade attacks. Now let's talk about one last vulnerability that expose
1793.19s - 1799.39s |  all of the attack vectors to unprivileged attackers in certain scenarios. So it all started
1799.39s - 1803.77s |  with this Windows dot old folder which I came across in some of my machines and looking at it
1803.77s - 1808.43s |  and Googling it, I found that this is the old Windows operating system and it is saved for
1808.43s - 1812.51s |  restoration purposes after a quality update is installed. So when you install a quality
1812.51s - 1819.44s |  update, Windows dot old is saved uh Windows is saved to Windows dot old. Of course the first
1819.46s - 1824.74s |  thing I did was to try to to to modify files inside Windows old but I noticed that access
1824.74s - 1829.14s |  lists are copied from the old operating system and so it was impossible to temper files that
1829.14s - 1834.92s |  could not be previously tempered with. The next thing I did was to try to check access to
1834.92s - 1840.22s |  the Windows dot old folder itself and I found that as an unprivileged user I have full
1840.22s - 1846.72s |  access to this folder. The exploitation strategy is straight forward. First renaming the
1846.74s - 1851.38s |  original Windows dot old folder to any name and then creating an attacker controlled Windows
1851.38s - 1856.02s |  old folder and the attacker controlled operating system will be used in case of update
1856.02s - 1860.96s |  restoration. So then in a restoration scenario triggered by administrator, the attacker
1860.96s - 1865.40s |  controlled operating system will be used instead of the backup operating system. So this is
1865.40s - 1869.56s |  another way to perform the same downgrades from an unprivileged user in a restoration
1869.56s - 1876.87s |  scenario. Closing remarks, let's talk about the disclosure process, next steps and
1876.89s - 1882.93s |  takeaways. Starting from the disclosure process, we notified Microsoft of our research
1882.93s - 1887.93s |  findings in February 2024, Microsoft issued CV 2024-21302 and CV 2024-38202. This is
1894.25s - 1898.45s |  Microsoft's official response to the research and I would like to thank Microsoft here for
1898.45s - 1905.00s |  the great cooperation and effort on these cases. For those of you who want to further
1905.00s - 1909.48s |  research the topic that we explored today, here are some of the topics that I would
1909.50s - 1915.46s |  recommend looking at. First and foremost, the critical question still arises. Are there
1915.46s - 1921.80s |  additional Windows features vulnerable to downgrade attacks? So far, both secure boot and the
1921.80s - 1926.88s |  virtualization stack was found vulnerable. Do you have in mind additional critical features
1926.88s - 1932.64s |  that you think are vulnerable to downgrades? Another interesting feature introduced not too
1932.64s - 1937.56s |  long ago is Linux virtualization based security. And this is a game changer for Linux
1937.56s - 1944.48s |  security. Would the same design issues exist in the Linux implementation? Lastly, are there
1944.48s - 1948.98s |  any other operating systems such as Mac OS or Linux that may be vulnerable to downgrade
1948.98s - 1954.52s |  attacks? May the implications on those operating systems be similar to the Windows
1954.52s - 1962.04s |  implications? What are the takeaways for this talk? First, the cyber security industry
1962.04s - 1966.92s |  should raise its awareness of OS downgrade attacks and the danger that they pose. I found
1966.92s - 1970.66s |  no mitigation preventing the downgrade of critical operating system components,
1970.66s - 1975.84s |  suggesting the downgrade attacks were not a focal point barrier to my research. The
1975.84s - 1981.60s |  significant implications made um made by downgrade attacks emphasize the danger that they
1981.60s - 1987.14s |  pose. And while Windows is currently affected, could Mac OS or Linux be next? We need to
1987.14s - 1993.50s |  address these questions before real attackers do. Second, design should always be reviewed
1993.50s - 1997.96s |  and regarded as a relevant attack surface. The downgrade attack on the virtualization stack
1997.96s - 2002.84s |  was possible due to a design flow that permits less privileged VTLs or rings to update
2002.84s - 2008.74s |  components residing in more privileged VTLs or rings. Even though virtualization based
2008.74s - 2013.24s |  security has became more popular among security researchers in recent years with some
2013.24s - 2018.24s |  great research papers papers on the subject, this attack surface, the downgrade attack
2018.24s - 2022.58s |  surface has existed since the very beginning of VBS when Microsoft first announced it in
2023.04s - 2030.86s |  2015. And this indicates that the design was probably not thoroughly examined. Third, in the
2030.86s - 2035.62s |  wild attacks should be thoroughly examined and expanded upon whenever possible. With the
2035.62s - 2039.56s |  Black Lab's UEFI boot kit employing downgrade attacks, we realized that the concept of
2039.56s - 2044.06s |  downgrade attacks was right under our noses. Although a year has passed, it seems that this
2044.06s - 2048.68s |  time we were able we were able to study and expand upon downgrade attacks before attackers
2048.70s - 2055.79s |  did. So we exp- we expanded uh security boots downgrade to virtualization stack downgrades.
2055.79s - 2059.69s |  This is not always guaranteed and this emphasizes the importance of studying in the wild
2059.69s - 2065.33s |  attacks and always considering what other components or areas may also be affected by an in
2065.33s - 2072.11s |  an in the wild attack. Now before we wrap everything up, I would like to credit these
2072.11s - 2080.28s |  talented people for their work. It was a pleasure for me to share with you my journey of
2080.28s - 2083.98s |  researching downgrade attacks on Windows and their severe implications on Windows as
2084.00s - 2088.74s |  platform security. Using the findings that I revealed today, you can bring back to life
2088.74s - 2094.18s |  thousands of old and fixed vulnerabilities. Windows downdate essentially makes the term
2094.18s - 2100.12s |  fully patched meaningless across any Windows machine worldwide. If you have any question
2100.12s - 2105.26s |  questions please catch me in the wrap up room or here and also feel free to reach out on
2105.26s - 2109.76s |  social media and with that I would like to thank you all for joining me today and have a
2109.76s - 2111.62s |  great rest of your day. Thank you.


url: https://www.youtube.com/watch?v=wT9gyOeN6zY
type: video
author: DEFCONConference
ingestion_date: 2024-11-10
transcription_model: large-v2
chunking_status: completed
title:
DEF CON 32 - QuickShell Sharing is caring abt RCE attack chain on QuickShare - Or Yair, Shmuel Cohen

content:
{
  "webpage_url": "https://www.youtube.com/watch?v=wT9gyOeN6zY",
  "title": "DEF CON 32 - QuickShell Sharing is caring abt RCE attack chain on QuickShare - Or Yair, Shmuel Cohen",
  "description": "Quick Share (formerly Nearby Share) has enabled file sharing on Android for 4 years and expanded to Windows a year ago.\n\nGoogle's promotion of Quick Share for preinstallation on Windows, alongside the limited recent research, ignited our curiosity about its safety, leading to an investigation that uncovered more than we had imagined.\n\nWe studied its Protobuf-based protocol using hooks, built tools to communicate with Quick Share devices, and a fuzzer that found non-exploitable crashes in the Windows app. We then diverted to search for logical vulnerabilities, and boy oh boy, we regretted we hadn\u2019t done it sooner.\n\nWe found 10 vulnerabilities both in Windows & Android allowing us to remotely write files into devices without approval, force the Windows app to crash in additional ways, redirect its traffic to our WiFi AP, traverse paths to the user\u2019s folder, and more. However, we desired the holy grail, an RCE. Thus, we returned to the drawing board, where we realized that the RCE is already in our possession in a form of a complex chain.\n\nIn this talk, we\u2019ll introduce QuickShell - An RCE attack chain on Windows combining 5 out of 10 vulnerabilities in Quick Share. We\u2019ll provide an overview about Quick Share\u2019s protocol, present our fuzzer, the found vulnerabilities, a new HTTPS MITM technique, and finally the RCE chain.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2707,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 I'd like to introduce Or and Shmuel. Here we go. And away we go.
12.25s - 17.25s |  Okay. Hi everyone. Today we will present Quickshare. Sharing is caring about an RC attack chain
20.39s - 25.39s |  on Quickshare. So, my name is Or Yair. I'm the security research team lead at SafeBreach.
28.69s - 33.97s |  I have more than six years of experience in security research. My past research included
33.97s - 38.97s |  some research on Linux environments, embedded devices, Android devices, and more. And for
41.31s - 46.25s |  more than three years now my main focus lies in vulnerability research in a Windows operating
46.25s - 53.88s |  system and third party apps that run on it. Hi everyone. My name is Shmuel Cohen and I'm
53.88s - 59.30s |  excited to be here today and present the finding of our recent research. A little bit about
59.30s - 65.16s |  myself. I have six years of experience in the cyber security industry. Previously I
65.16s - 70.72s |  conducted APT malware research within the checkpoint research group and currently I'm part
70.72s - 75.70s |  of the SafeBreach original research team where I focus primarily on vulnerability research on
75.70s - 83.87s |  various products. Okay. So, let's see what we're going to talk about today. We'll start with
86.25s - 92.45s |  what is Quickshare and why we chose it as our primary target for this research. We'll then
92.47s - 97.47s |  move on to get to get a brief overview about the protocol that Quickshare uses. We'll then see
99.65s - 105.19s |  the first research approach that we took for this research which is fuzzing. We'll see the
105.19s - 110.39s |  research approach shift um that we took that led us to other vulnerabilities and we'll see the
110.39s - 117.23s |  vulnerability discovery that um that we had vulnerability discoveries that we had um based on
117.25s - 123.69s |  these two approaches. Then we'll see how we managed to assemble a very unconventional and
123.69s - 128.69s |  creative RCE attack chain from these vulnerabilities and we'll conclude with takeaways and a
131.47s - 136.47s |  link to the GitHub repository of all the tools that we created. So, what is Quickshare?
140.27s - 147.11s |  Quickshare is Google's nearby file transfer solution for Android just like Apple's AirDrop.
147.13s - 152.67s |  Quickshare was formerly known as NearbyShare and then last January at CES, Google and
152.67s - 158.91s |  Samsung decided to combine their file sharing solutions into a single one and call it
158.91s - 165.31s |  Quickshare. So, we know what the talk is about but why did we even choose to target
165.31s - 171.65s |  Quickshare? Last July, Google has officially released a Windows version of Quickshare for
171.67s - 176.77s |  Windows allowing to share files between Windows computers to any other device with
176.77s - 183.15s |  Quickshare. An interesting fact from Google's announcement about Quickshare at CES is that
183.15s - 188.95s |  they are working with leading PC manufacturers just like LG to expand Quickshare to Windows
188.95s - 196.94s |  PCs as a pre-installed app making Quickshare for Windows a much more attractive target.
196.94s - 202.38s |  Moreover, Quickshare performs file transfers using several communication methods. It
202.38s - 208.88s |  supports WebRTC, Bluetooth, Wi-Fi, NFC, Wi-Fi direct and even sending files over a Wi-Fi
208.88s - 213.88s |  hotspot of one of the devices. As far as we knew, Quickshare was Google's first Windows app
216.54s - 222.66s |  to use all these communication methods. In general, most of Google's services that are used
222.66s - 229.26s |  on Windows are in the browser. This was a first of a kind for Google and thus chances for
229.28s - 235.82s |  mistakes were higher. Looking for past research, the only one that we could really find was a
235.82s - 240.30s |  research called Nearby Threats, Reversing, Analyzing and Attacking Google's Nearby
240.30s - 246.20s |  Connections on Android. The research analyzed Google's Nearby Connections API that is the
246.20s - 253.34s |  API that Nearby Share and later on Quickshare use in their implementations. And Quickshare
253.34s - 258.38s |  and Nearby Share didn't even exist back then. It was just an API for third party
258.40s - 263.40s |  applications. The Windows app did not exist um also of course. Another interesting fact was
267.84s - 272.78s |  that we saw that most of the applications code can be found in open source repositories by
272.78s - 277.78s |  Google. It was not all of it but some of it at least. And in addition we just could not find any
280.56s - 285.56s |  CVEs related to Quickshare. Concluding all of these facts together led us to evaluate Quickshare
288.76s - 293.76s |  as a valuable and likely to be breached target. Our final goal was to achieve something that was
297.04s - 302.04s |  never achieved using Quickshare and that was remote code execution. Starting our journey we
306.60s - 313.24s |  needed to understand Quickshare's protocol of course. Therefore the first thing we did was to
313.24s - 319.92s |  find the most basic functions that Quickshare uses to send and receive packets. Once we
319.92s - 325.10s |  find such functions if they are generic and are used for all communication methods then we'll
325.10s - 331.60s |  be able to get a clear view of all packets that are being sent and received by the app in
331.60s - 337.88s |  their binary form. Then just as we needed we found the read and write functions as part of a
337.88s - 343.96s |  base class that was called base endpoint channel. Deeper inside the read function we were
343.96s - 349.06s |  able to understand that the packets that are being sent and received are packets of a type
349.06s - 355.34s |  called offline frame. That is because each packet that was received was parsed into an
355.34s - 360.34s |  offline frame object. But offline frame object was not a normal object as its class was
363.52s - 368.52s |  generated by protobuf. In here we can see the protobuf definition of offline frame and using
371.86s - 376.86s |  protobuf this proto file is being compiled into CPP files that define the offline frame and
379.10s - 384.10s |  provide functions to serialize it to bytes and deserialize it from bytes. But don't be
386.40s - 392.64s |  alarmed by the name offline frame too much because offline frame is the base type for almost
392.64s - 398.72s |  all packet types that we are going to discuss in this talk and so from now on we will just
398.72s - 403.72s |  mostly call them packets instead of offline frames. And so our first tool for this research
404.72s - 409.72s |  was born pretty fast. We needed a tool that will provide us abilities to watch the
412.42s - 418.30s |  communication. So we wrote a DLL that hooks the read and write functions and textually logs
418.30s - 423.90s |  each packet that is being sent and received with all of its fields. This tool allowed us to
423.90s - 428.60s |  understand the protocol much better and Shmuel will be the one to elaborate on what we
428.60s - 435.81s |  learned. Thank you all. Cool. So now that we can sniff QuickShare packets it's time to take a
438.17s - 444.45s |  deep dive of the protocol used by QuickShare. So there's an API called Nearby Connections
444.45s - 451.45s |  API and it's used to discover, connect and exchange data with nearby devices in real time
451.45s - 456.79s |  regardless of network connectivity. QuickShare uses the Nearby Connections API with its
456.81s - 463.45s |  own implementation. Let's start with reviewing the Nearby Connections API. So it's based on
463.45s - 468.55s |  protobuf which is used to serialize structured data. It's mostly encrypted. The encryption is
468.55s - 474.55s |  handled using Google's UK2 library. Each app is uniquely identified within the Nearby
474.55s - 481.33s |  Connections API by a service ID that is provided by the app's developers. It has multiple
481.37s - 487.65s |  connections strategies such as peer-to-peer, star and a cluster. We will focus on the
487.65s - 493.15s |  peer-to-peer strategy because it's the one used by QuickShare. In this strategy there's
493.15s - 498.89s |  initiator and the responder functioning much like a client and server. In our protocol
498.89s - 505.73s |  overview we will examine packets that send during a file transfer from a phone to a PC. The
505.73s - 510.83s |  first stage of communication is a connection request packet. Following that the initiator
510.83s - 516.67s |  starts with encryption handshake. The encryption handshake starts by sending a UK client
516.67s - 523.45s |  init packet to the responder. Then the responder replies with a UK server initialization
523.45s - 530.09s |  packet and finally the initiator responds with a UK client finish packet. At this point the UK
530.09s - 535.13s |  encryption handshake is successfully completed ensuring that all subsequent packets will be
535.13s - 540.81s |  encrypted. Next the responder sends a connection response packet indicating that it's
540.81s - 547.21s |  accepted the connection and the initiator responds with a similar packet back. At this point
547.21s - 551.95s |  QuickShare proprietary communication begins. This proprietary communication uses various types
551.95s - 558.33s |  of packets provided by the Nearby Connections API. Let's review some of those packets. So
558.33s - 563.93s |  these packets as all mentioned are called offline frames. Here you can see all types of
563.93s - 570.41s |  packets that can be used within the protocol. So far we've seen two types, the connection
570.41s - 577.39s |  request and the connection response. In our talk we will focus on two types, payload transfer
577.39s - 584.07s |  and bandwidth hybrid negotiation. Now let's explore how QuickShare manages the connections at
584.07s - 589.41s |  this stage. Just a quick reminder, this is where we stopped earlier, just when the
589.41s - 595.49s |  proprietary communication begins. The next sequence of packets were payload transfer which
595.49s - 602.19s |  both sides send to each other. Using our sniffer let's examine those packets. As shown in the
602.19s - 607.19s |  image the payload transfer packet contains binary data which was initially unclear to us. However
610.33s - 615.27s |  with the help of another portable file that we found in the Chromium open source project we
615.27s - 620.77s |  were able to decode this binary data and we discovered that the payload transfer packet
620.77s - 625.77s |  contained another packet called paired key encryption. So both sides exchange this uh
629.45s - 634.81s |  paired key encryption packet followed by a paired key result packet. We want to understand
634.81s - 639.55s |  the purpose of these packets and with the help of our sniffer we observed that they used
639.55s - 645.17s |  among other things to enforce uh device visibility modes. These modes allow the user to
645.17s - 651.27s |  control who can send data to them. For example the user can choose that only their contact
651.27s - 657.41s |  will be able to send data to them. After this stage is done the initiator that wants to send
657.41s - 663.61s |  the file sends an introduction packet. As a result the responder is prompt with a file
663.61s - 669.79s |  introduction dialog on the computer saying that the initiator would like to send the file. To
669.79s - 675.39s |  receive the file the responder simply simply needs to press the accept button which will
675.39s - 680.39s |  cause QuickShare to send an accept packet to the initiator. After the responder accept the
682.59s - 688.29s |  initiator sends the file using a payload transfer packet. And that's it. After this stage is
688.29s - 694.97s |  completed the file will be sent. Let's see a short demo of this overview. So on the right side
694.99s - 700.03s |  we have a phone and on the left side we have a PC which uh QuickShare is installed and we'll
700.03s - 705.03s |  just show how a file transfer normally send from a PC to a phone. So choosing the target device
709.47s - 715.17s |  the phone gets prompt with an accept or decline dialog. The phone chooses to accept and the
715.17s - 720.17s |  file is on the phone. See it's very simple right? So now that we have basic understanding of
720.85s - 725.85s |  how QuickShare file transfer works under the hood we can proceed to fuzz this flow um on
729.39s - 736.23s |  QuickShare in uh for Windows. We chose the most straightforward infrastructure for fuzzing in
736.23s - 742.87s |  Windows which is WinAFL of course. For instrumentation we used Dynamario and since
742.87s - 749.07s |  Protobuf is being used everywhere we wanted a solution that supports Protobuf as well.
749.07s - 755.79s |  Google developed a leap Protobuf mutator that can be used with WinAFL. Combining these
755.79s - 761.55s |  solutions together helped us a lot in the fuzzing process and let's now discuss our approach.
761.55s - 768.53s |  So our goal is to fuzz an entire session of file sending rather than just individual packets.
768.53s - 775.01s |  However there might be a potential issue with this approach. Can you guess what? So as we
775.01s - 780.05s |  already mentioned when a file is sent an accept or decline buttons are being prompt in the
780.05s - 785.65s |  responder side. Since we want to fuzz all stages of communication including when a file is
785.65s - 792.57s |  being accepted we needed our fuzzer to um our fuzzing target sorry to accept every file that's
792.57s - 798.53s |  being sent to it automatically without the need of the user to press the accept button. So we
798.53s - 803.91s |  started to look for ways to accept automatically every file that is being sent. Our first
803.91s - 808.05s |  approach was to reverse engineer the relevant models and patch it in such a way that every
808.05s - 813.95s |  file will be accepted automatically. But fortunately for us within the uh Chromium open
813.95s - 818.89s |  source project we found out that Google already implemented a built in feature called auto
818.89s - 824.99s |  accept. So we just needed to patch this if statement to make it work all the time. And that's
824.99s - 831.17s |  exactly what we did. We located the relevant uh binary and we patched it. Now our fuzzing
831.17s - 836.17s |  target automatically accept every file every time. Next we needed to implement a harness
839.31s - 844.71s |  that could handle an entire session during each fuzzing iteration rather than just sending
844.71s - 850.85s |  single packet. To achieve that we created a simple binary format to encapsulate all packets
850.85s - 856.99s |  for an entire session which would be sent each fuzzing iteration. The structure we decided was
857.01s - 863.73s |  straightforward. Four bytes for length followed by a serialized offline frame of that length.
863.73s - 868.69s |  At this stage we were ready to start fuzzing QuickShare for Windows. However as you can see
868.69s - 873.69s |  on the screen this process was quite slow. So we started to check again what makes it slow. And
876.37s - 882.27s |  with the help of QuickShare logs we found that after each file is being transferred the stop
882.29s - 888.07s |  advertising function is getting called. And as the name suggests this function used to stop
888.07s - 894.03s |  the advertising of the device and later on it's starting advertising back again. Meaning it's
894.03s - 900.11s |  closing sockets, it's opening new ones and those things take time. On top of that another
900.11s - 906.31s |  function is called with the name remove endpoint. And it has 500 milliseconds flip at the end.
906.33s - 911.93s |  Think about it. After each file is being uh that is being sent there's a half of a second
911.93s - 917.37s |  slip time. That's huge when you're talking about fuzzing speed. So again we patched we patched
917.37s - 923.55s |  the relevant models and prevented this behavior. Those patches help us a lot as you can see.
923.55s - 931.08s |  Made our fuzzing process much faster. About ten times. Unfortunately the speed improvement
931.08s - 936.42s |  created a persistent issue for us. The combination of instrumentation which significantly
936.46s - 942.04s |  slows down the fuzzing target and our patch to increase the file transfer speed led to an
942.04s - 947.68s |  unhandled race condition that was too complex to manage. As a result we received numerous
947.68s - 953.64s |  crashes report and we were uh that we were unable to reproduce. Therefore we made a decision
953.64s - 959.86s |  to abandon this approach and revert back to the original functionality of QuickShare. Despite
959.86s - 965.84s |  this slower performance over time the fuzzer did yield several positive uh several positive
965.84s - 972.84s |  positive results. Let's discuss them. Overall there were four reproducible crashes. We
972.84s - 977.72s |  attempted to explore further the exploitation of those crashes but they are unlikely to be
977.72s - 984.06s |  exploited. But now we have the ability to crush QuickShare and who knows that ability might be
984.06s - 990.54s |  handy in the future. Another very interesting uh finding by the fuzzer was a reproducible
990.54s - 997.28s |  timeout. You see when QuickShare receives a file it first check the existence of a file with
997.28s - 1003.42s |  the same name by attempting to open it. If the file opens successfully this this indicates
1003.42s - 1008.82s |  that the file is already exist. In response QuickShare appends an index number suffix to the
1008.82s - 1016.07s |  file name. It's very similar to what browsers do when you download the file. So QuickShare
1016.07s - 1022.23s |  tries to add um the suffix before the file extension as you can see on the screen. That's
1022.23s - 1028.71s |  why it splits the name into two parts. The name and the extension. But what happens if the
1028.71s - 1033.71s |  name before the extension has a null terminator in it? The result is that anything added after
1034.15s - 1039.15s |  the null terminator is irrelevant when the file name is passed to the open function. It reads
1042.65s - 1048.29s |  the string up only to the null terminator. This causes QuickShare to get stuck in an endless
1048.29s - 1054.37s |  loop. Continuously incrementing indexes while mistakenly thinking it's searching for
1054.37s - 1059.37s |  available index. When in fact it's trying to open the same files open over and over again. So
1060.17s - 1065.17s |  to sum things up. We managed to get um the fuzzer working constantly but each fuzzing
1068.07s - 1073.21s |  iteration took too much time. Making the process quite slow. Even when we identified some
1073.21s - 1078.21s |  crashes it wasn't uh necessarily always exploitable. So we thought it was time to review what
1080.25s - 1086.29s |  we achieved and consider our next steps. We felt confident enough with the QuickShare and the
1086.31s - 1091.85s |  protocol and to start searching for logical vulnerabilities. And we certainly found some
1091.85s - 1096.85s |  gold there. And one on one observation that we made is the code is extremely generic with a
1099.73s - 1104.47s |  handler class for each packet type. Additionally the code is filled with threads and async
1104.47s - 1109.51s |  methods all over the place. Those specs made us think it will be a good place to find
1109.51s - 1116.11s |  vulnerability in it. So the first logical vulnerability that we'll introduce is a file
1116.89s - 1122.67s |  acceptance bypass. As mentioned earlier to send a file the initiator first needed to send an
1122.67s - 1128.17s |  introduction packet and wait for an accept packet from the responder. After that the initiator
1128.17s - 1133.71s |  will send a payload transfer packet containing our file. We thought to ourselves wait. What
1133.71s - 1138.39s |  happened if we skip the introduction and accept packets and send the payload transfer packet
1138.39s - 1143.39s |  directly? We found out that the file will be sent anyway resulting a complete bypass of the
1144.17s - 1150.67s |  acceptance of the of the of the file from the responder side. To make things even better we
1150.67s - 1155.45s |  discovered that this approach works for any discovery mode. So even if your device is
1155.45s - 1161.85s |  configured to accept files from your context for example, we could still be able to send files
1161.85s - 1168.69s |  to your device without requiring your acceptance and without any notification. It's also
1168.69s - 1174.23s |  important to note that these visibility modes doesn't grant a file transfer capability. Even
1174.23s - 1179.23s |  if someone else can see your device for some reason in the quick setup they won't be able to
1179.23s - 1185.07s |  send files if your device is set to accept files only from your context. This is because the
1185.07s - 1190.89s |  protocol includes a verification step at the beginning to ensure the sender is authorized to
1190.89s - 1195.89s |  send files to the receiver. Let's see a demo of it. So we have our phone here and we can see
1198.79s - 1205.87s |  that I configured the phone to allow um files acceptance only from your device. Now let's see
1205.87s - 1210.63s |  the quick share folder we can see that it's empty on the phone and now let's see our
1210.63s - 1215.65s |  attacker uh machine. You we used our tools send files with bypass and few seconds after it you
1217.87s - 1223.15s |  could see that nothing happened on the phone but our file is there. So we implement the file in
1223.15s - 1228.29s |  the phone without any notification on any Android device that has quick share and we can do
1228.29s - 1233.29s |  it um even on any any Windows device that has quick share in it. Pretty awesome right?
1235.29s - 1244.40s |  Thank you. So let's continue with our next logical vulnerability. Forcing victim device to
1244.40s - 1249.40s |  connect to a rogue wifi access point. In the context of data transfer a medium refers to a
1251.64s - 1256.68s |  channel through which information is transmitted. When sending a file quick share checks
1256.68s - 1261.92s |  whether there's a need to upgrade the medium and to achieve better transmission uh speed. For
1261.92s - 1266.96s |  example upgrade from Bluetooth to wifi. As shown on the slide there are various possible
1266.96s - 1273.06s |  upgrades connections. When discussing um bandwidth update negotiation uh bandwidth
1273.06s - 1277.80s |  upgrade negotiation sorry it's important to reference previous research that highlighted a
1277.80s - 1283.10s |  specific attack scenario. In that study researcher forced an Android device to connect to a
1283.10s - 1289.74s |  rogue wifi network to carry out a man in the middle attack. This attack lasted maximum of 30
1289.74s - 1295.14s |  seconds and has been mitigated by Google. Today if your Android device receive an uh bandwidth
1295.14s - 1300.22s |  upgrade negotiation packet via quick share other internet connections uh will not be
1300.22s - 1305.22s |  redirected to that wifi network. But what about Windows? We have noticed that uh one of the
1307.56s - 1312.06s |  upgrade methods is through wifi hotspot access point. Basically during transfer the
1312.12s - 1317.10s |  initiator creates a temporary hotspot and send to the responder the credentials to connect to
1317.10s - 1322.46s |  this hotspot. By the way this process can be initiated from the responder side as well. When the
1322.46s - 1328.98s |  transfer is completed this hotspot is getting closed. But we've noticed that during this time the
1328.98s - 1334.22s |  internet connection of the responder device is still working even though it's connected to our
1334.22s - 1340.22s |  hotspot. We started to sniff the network packets from the initiator device and we found out that
1340.24s - 1346.62s |  all the traffic from the responder side is going through our device. Meaning that we can get a man
1346.62s - 1352.42s |  in the middle for the time of the transfer and sniff the entire responder traffic. So I can
1352.42s - 1357.70s |  connect every phone that has a quick share to my hotspot and create a man in the middle attack.
1357.70s - 1366.10s |  Now I will continue and explain what we can be done next. Cool. Okay yeah so uh that was pretty
1366.86s - 1371.86s |  awesome. Forcing any Windows device with quick share to connect to our rogue wifi AP. Um but
1378.44s - 1383.44s |  let's see what we managed to uh find so far. So so far we found 8 vulnerabilities in total. The
1386.74s - 1391.88s |  most critical vulnerability in our opinion was the one that allowed us to send a file without
1391.90s - 1398.78s |  approval. But we were looking really for the holy grail as I mentioned at the beginning which
1398.78s - 1403.78s |  was an RCE vulnerability that we still did not have. Thus just like turning standard stones
1407.58s - 1413.56s |  into deadly drones, that sounds pretty much impossible, we decided that we are going to
1413.56s - 1419.87s |  chain these vulnerabilities into an RCE. So so far we had 4 primary abilities using these
1420.83s - 1425.83s |  8 vulnerabilities. We could create files in the victim's downloads folder without any
1428.53s - 1434.27s |  requirement for acceptance or authorization. We could force the target device, the target
1434.27s - 1440.11s |  Windows device into connecting to a different wifi network and um connect to the internet
1440.11s - 1445.11s |  through it but only for about 30 seconds. Um we could also crash quick share in multiple ways
1445.29s - 1450.29s |  that uh we found using the fuzzer and finally um we could also reproduce that reproducible
1453.97s - 1458.97s |  timeout that we saw in that uh the fuzzer found which um can force quick share into an endless
1461.25s - 1469.19s |  loop continuously opening a file that we choose from the victim's download folder. Talking
1469.19s - 1476.17s |  about the main the wifi man in the middle vulnerability is um uh as I mentioned it allows us
1476.19s - 1482.49s |  to see all the wifi traffic of the victim for about 30 seconds and but with that being said as
1482.49s - 1488.73s |  you all know encryption is a standard for today's application layer so manipulating the
1488.73s - 1493.73s |  traffic in 30 seconds to achieve an RCE is not likely to succeed except in very specific
1496.91s - 1501.91s |  situations. However we then had a crucial insight and I want you to remember that. The
1502.89s - 1507.89s |  insight was that the downloads folder to which we can write any file that we want using R
1511.77s - 1516.77s |  exploits on quick share for Windows is the same folder where browsers place their downloaded
1519.67s - 1526.01s |  files. This led us to an idea. What if we could overwrite an executable that was downloaded
1526.95s - 1531.95s |  into the downloads folder before it runs? If being a man in the middle can somehow help us
1535.85s - 1540.87s |  know which executable files are downloaded by the browser to the downloads folder and if we
1543.67s - 1548.67s |  can somehow overwrite them using our abilities then this would lead to an RCE. That is
1549.07s - 1556.25s |  because we'll be able to replace the executable with our malicious one and then the user will
1556.25s - 1562.59s |  run our executable. The simplest example would be a victim that downloads the VS code
1562.59s - 1568.35s |  installer for instance and then we overwrite it with one of our vulnerabilities right after it
1568.35s - 1574.87s |  was downloaded and then the victim runs our executable instead of the VS code installer.
1574.87s - 1579.87s |  Now of course we still did not have uh sorry, yeah, okay. Now of course we still did not have
1582.31s - 1588.39s |  the exact abilities we needed but since being a man in the middle might help us anyway we
1588.39s - 1593.73s |  decided to start with making the WiFi connection last longer as it was only active for about
1593.73s - 1598.73s |  30 seconds. To do that we tried to think of a way to prevent quick share from returning to its
1599.07s - 1604.07s |  original WiFi network once a file sending session was over. Then a very simple solution came
1608.47s - 1614.57s |  up. Crashing quick share right after the WiFi connection to our rogue WiFi AP was
1614.57s - 1621.21s |  established. The result was that if we force a Windows computer with quick share to connect to
1621.21s - 1627.53s |  our WiFi network, to our malicious WiFi network and then instantly crash the app with one of
1627.53s - 1633.27s |  our denial of service vulnerabilities that a fuzzer found, we get a forever lasting WiFi
1633.27s - 1639.78s |  connection to our WiFi hotspot. As regards to the crash, the fear of it preventing us from
1642.88s - 1649.32s |  continuing to exploit the app did not exist. Why? Because when quick share is installed it
1649.32s - 1655.90s |  creates a scheduled task that runs every 15 minutes and runs quick share if it's not already
1655.90s - 1660.90s |  running. So we don't really lose the ability to further exploit quick share. And actually we
1663.70s - 1669.54s |  will continue to exploit quick share and this is why these 2 links are only the first part of
1669.54s - 1675.64s |  our RCE attack chain. So far we established a lasting WiFi connection that we expect to
1675.64s - 1682.38s |  come in handy for identifying downloaded file. Now let's understand the reason for why it
1682.40s - 1689.34s |  was actually so helpful for doing that. And the reason and this is the reason. Metadata
1689.34s - 1695.52s |  matters. Seeing this tweet by Talberry which by the way had a different picture that we
1695.52s - 1701.82s |  changed but can still be found in Tal's feed, uh we thought that it explains exactly how we
1701.82s - 1707.80s |  leveraged the WiFi connection. It was indeed true that files are normally downloaded over
1707.82s - 1712.82s |  HTTPS meaning that the traffic is encrypted. However there were still 2 very important
1715.16s - 1720.16s |  elements in the metadata of an HTTPS session. The first one is the server's domain. The
1723.20s - 1728.74s |  encryption of HTTPS is performed using the TLS protocol of course and the TLS session
1728.74s - 1733.74s |  starts with an unencrypted client hello message that is sent by the client. Normally a server
1734.46s - 1739.46s |  name indication extension is being added to this message which indicates the domain of the
1743.94s - 1748.94s |  server. That means that if you are exposed to victim's traffic you can determine the domains
1751.40s - 1758.29s |  that they communicate with. The second element that is present of part of the metadata of an
1758.29s - 1763.29s |  HTTPS session is the approximate size of data that is being transferred in the session.
1765.99s - 1770.99s |  When a file is being downloaded over HTTPS it's normally downloaded in one TCP session. Even
1773.83s - 1779.27s |  though encryption might add some random padding the amount of data that is being transferred
1779.27s - 1784.27s |  from the server to the client during a file download of the same file stays relatively the
1786.75s - 1791.75s |  same. In addition the size of an executable file is usually much bigger than the size of other
1792.13s - 1797.13s |  pages or resources that may be transferred from a website to a client in an HTTPS session. The
1803.90s - 1810.20s |  conclusion is that if we know the domain that the client communicated with and we know that
1810.20s - 1816.82s |  there is a large file that is being downloaded along with it's approximate size then that
1816.82s - 1821.82s |  means that we can also very accurately guess the name of the downloaded file. For instance
1823.76s - 1828.76s |  if we know that 95 megabytes were downloaded from code.visualstudio.com then we can
1831.16s - 1836.16s |  confidently say that the latest VS Code installer was probably downloaded. Think of the most
1840.24s - 1845.80s |  popular installers for software that you use like VS Code for example. Entering the VS Code
1845.80s - 1852.04s |  download page leads you to a single download button for a single VS Code version that matches
1852.04s - 1857.04s |  your OS and is the newest one. This installer has the size of 95 megabytes which is larger than
1860.98s - 1865.98s |  any other resource in the website. And so this really narrows down the options and makes it much
1868.22s - 1873.22s |  easier to detect a download of the latest VS Code installer. Most websites that offer such
1873.48s - 1878.48s |  installers have really only one relevant file. And so we framed and defined our new man in the
1884.42s - 1890.40s |  middle technique more specifically. In order to be as precise as possible we understood that
1890.40s - 1895.40s |  we need to define what we call domain paths. A domain path is a sequence of domains to which
1895.80s - 1900.80s |  we expect the victim to access until the download starts. Let's look at Notepad++ for example.
1906.54s - 1912.24s |  Clicking on the download button in its website does not download the executable from the
1912.24s - 1917.24s |  Notepad++.org domain. Instead it references GitHub.com. Then GitHub.com actually redirects
1917.24s - 1922.24s |  the request to another domain and this is the final domain. It's objects.githubusercontent.com.
1929.58s - 1934.94s |  And the file is downloaded from there. If we just look at this final domain we won't be able to
1934.94s - 1939.96s |  determine that the downloaded file is the installer of Notepad++. However what we can do is to
1940.48s - 1945.48s |  follow access to previous domains. Basically we what we need to do is to see that in a limited
1948.92s - 1953.92s |  time period Notepad++.org was accessed followed by access to GitHub.com and then to
1956.96s - 1963.50s |  objects.githubusercontent.com. If that access to the final domain downloads the file with an
1963.50s - 1968.84s |  approximate size as we expect for the installer then we can determine that it's actually the
1968.92s - 1975.52s |  installer. To conclude this is how we define the new man in the middle technique that we
1975.52s - 1980.52s |  created. We start by creating a mapping between domain paths to executables that match these
1983.74s - 1988.74s |  domain paths and their sizes. Then we wait until the victim hits a certain domain path in a
1991.58s - 1996.58s |  limited time frame and we start counting the downloaded data. Finally we check if the size
1998.98s - 2004.66s |  of the downloaded data is equal or a bit bigger than the installer that matches this domain
2004.66s - 2011.10s |  path. If it does then we are safe to determine that the expected installer was indeed the one
2011.10s - 2016.10s |  that was downloaded. And so we change another link to our RCE chain. Now we can also detect the
2020.08s - 2025.08s |  name of an executable that is downloaded by a victim. That being said for an RCE we still need
2026.08s - 2031.08s |  the ability to overwrite files as we mentioned before. And we did not have it yet. But it
2036.96s - 2041.86s |  doesn't have to be a generic ability to overwrite files using our vulnerabilities in
2041.86s - 2047.36s |  quick share. It could be an ability that allows to overwrite files only in our very specific
2047.36s - 2053.74s |  situation when files are being downloaded. So what we're trying to do is to overwrite Google
2053.76s - 2060.58s |  Chrome's download while it's still ongoing. So first let's understand Chrome's basic download
2060.58s - 2067.34s |  process. When Chrome downloads a file, no matter which file it is, it starts by checking if the
2067.34s - 2073.76s |  file name already exists. If it does, it adds a number surrounded by parenthesis to the final
2073.76s - 2078.76s |  name for the download. If it doesn't, it keeps the original name. Then it starts downloading the
2079.76s - 2084.76s |  file but into a temporary file with a CR download extension. Once the download is fully
2090.74s - 2096.10s |  complete and we got all the contents of the file and only then Chrome renames the temporary
2096.10s - 2101.10s |  file to the actual name of the downloaded file and the download is then really complete. But
2101.36s - 2106.36s |  since Chrome checks whether the name already exists and decides on the final name for the
2109.24s - 2115.80s |  downloaded file only when it starts the download, we thought that there's good potential to
2115.80s - 2122.22s |  create confusion if we send the file with the same name in the middle of this process. That
2122.22s - 2128.46s |  will be after the name for the final downloaded file will already be final and has been
2128.48s - 2137.08s |  decided on. We thought it might lead Chrome to fail in renaming the downloaded file, the
2137.08s - 2144.02s |  temporary file, to the final name for the file, leaving our file in place. But how can we
2144.02s - 2150.42s |  know the name of the downloaded file and still send it before the download is complete? We
2150.42s - 2156.30s |  must wait for the final TCP packet to be sent from the server in order to determine the
2156.32s - 2163.06s |  approximate size of the file and then as a result of it, determine its name. In order to
2163.06s - 2168.60s |  prevent the download from being finished in Chrome, what we do is that we hold this last
2168.60s - 2176.45s |  packet as the man in the middle and do not forward it to the client. So we try to send a file
2176.45s - 2181.75s |  with the exact same name right before the download is finished, hoping Chrome might be
2181.77s - 2188.45s |  confused and will fail to rename the temporary file, leaving our file as the presumably
2188.45s - 2196.89s |  downloaded file. But unfortunately, this did not work. As a result, Chrome just overwrote the
2196.89s - 2204.27s |  file that we sent, finishing its download successfully, deleting our malicious file. But this
2204.27s - 2209.45s |  was not the end of it. We understood that we need to find a way to prevent Chrome from
2209.47s - 2214.47s |  overwriting our file. Then it was not long until we figured out that we maybe already have
2217.11s - 2222.11s |  this ability. If you remember from before, one of the reproducible uh uh timeouts that the
2226.59s - 2232.69s |  father found um was uh a vulnerability that allowed us to bring QuickShare into a state where
2232.69s - 2238.23s |  it continuously opens and closes any file that we want from the downloads folder of the
2238.31s - 2245.31s |  victim. We thought that we can utilize this vulnerability just right for this case. What we
2245.31s - 2250.33s |  hope for is that maybe if the file is endlessly opened and closed, the file that we sent, then
2252.93s - 2257.93s |  this will fail Chrome in overwriting it. So the result was that our hopes actually became
2260.93s - 2265.93s |  reality and Chrome actually failed in overwriting our file. It was actually the best
2268.27s - 2273.65s |  scenario that we hoped for. Once Chrome finishes the download, the result is that it
2273.65s - 2280.65s |  deletes the temporary CR download file. It fails to overwrite our malicious file. In its user
2280.65s - 2286.89s |  interface, Chrome reports that the download was finished successfully and clicking on the
2286.89s - 2291.89s |  downloaded file in Chrome's downloads window actually runs our malicious file. Thank you.
2292.13s - 2301.22s |  Yeah I know it's cool. Okay so uh and so another two links were added to our RCE chain
2307.16s - 2312.16s |  completing it into the RCE chain attack that we were aiming for from the beginning. And
2314.94s - 2321.34s |  finally we prepared a demonstration video presenting the entire QuickShare RCE attack chain
2321.38s - 2326.38s |  for you to see it in action. So let's watch it and before we do I'll mention that the video
2328.58s - 2333.58s |  starts um uh when the video starts we'll see the attacker's computer. We'll see that that the
2335.86s - 2340.86s |  attacker enabled a mobile hotspot on on um his Windows computer. And then we'll move we'll
2343.86s - 2348.86s |  move on to the victim computer where we'll see QuickShare installed. Um and we'll start by
2349.06s - 2354.06s |  seeing how the attacker forces the victim into connecting to the WiFi hotspot that the
2357.50s - 2362.50s |  attacker created. Okay so let's begin. So we can see that the hotspot is enabled and we'll see
2365.44s - 2370.44s |  just the IP address on that hotspot. Now we run our tool and we find nearby victims. One of
2370.54s - 2375.54s |  them is called Test Machine. We choose Test Machine. This is Test Machine. And now it's
2379.24s - 2385.42s |  connected to SafeBridge but we force it into connecting to our test IP and crash QuickShare to
2385.42s - 2390.56s |  make it um to make the WiFi connection last and now we see all the domains that the victim
2390.56s - 2397.02s |  accesses. Now the victim the victim goes into the Spotify website to download the uh Spotify
2397.04s - 2401.62s |  for Windows installer. We can see that the downloads folder is just empty there's nothing
2401.62s - 2406.62s |  inside. Now the victim downloads the file. Let's see what happens uh with the download. It's
2409.56s - 2414.56s |  now complete. We click it and our malware runs instead. Now thank you. Now let's do the same
2420.00s - 2425.00s |  with Notepad++. We go into its website download the newest version of Notepad++ for Windows
2427.80s - 2434.08s |  the victim downloads the file. The download starts. You can see that we can do that for many
2434.08s - 2439.08s |  installers. So the download is now finished and the victim runs it and it's again our malicious
2442.42s - 2454.14s |  executable. Thank you. Pretty cool right? So I know it might seem like we found exactly the
2457.54s - 2463.32s |  vulnerabilities that we needed to build this RCE chain but in reality it was a bit different. In
2463.36s - 2468.34s |  fact we discovered two addition vulnerabilities. One allowed us to send file to the parent
2468.34s - 2474.48s |  folder of downloads folder and other let us crash quick share by leveraging some of the findings
2474.48s - 2480.48s |  from all magic dot research that he presented last April. However these vulnerability weren't
2480.48s - 2486.38s |  you uh were not used um in the RCE chain and could not be exploited for a remote code
2486.38s - 2491.70s |  execution. We'll share more details about them in our upcoming blog post that will be published
2491.74s - 2497.82s |  after this talk. Overall we identified ten distinct vulnerabilities along with additional
2497.82s - 2504.12s |  bug in Chrome. We reported all of these vulnerabilities to Google at the end of January
2504.12s - 2510.70s |  this year. They've confir- they've confirmed they fixed every one of them. Every one of them.
2510.70s - 2516.70s |  Google decided to issue two CVEs for these ten vulnerabilities. The first CVE addresses how
2516.74s - 2522.14s |  uh two of the vulnerabilities can uh combine can force a persistent Wi-Fi connection. The
2522.14s - 2529.26s |  second CVE deals with bypassing the file approval dialogue in Windows. Google was very
2529.26s - 2533.86s |  responsive throughout the process confirming and reproducing each of the vulnerability
2533.86s - 2540.20s |  reported. We wanted to thank them for their collaboration and for addressing these issues.
2540.20s - 2545.00s |  Here's those official response. You can take a moment to read it now but of course it will
2545.04s - 2554.88s |  all uh it will be included in the published presentation. Give you a few seconds. So we've
2554.88s - 2559.42s |  covered pretty much everything about technical flow and now it's time to talk about the
2559.42s - 2565.72s |  takeaways which which are just as important. Our first and most significant takeaway is that
2565.72s - 2571.26s |  standard stones may sometimes be forged into the lead runs. What we mean by that is that
2571.26s - 2577.00s |  as a hacker you often have limited tools at your disposal. You might achieve something but
2577.00s - 2582.04s |  it's not exactly what you are aiming for. Reflecting on our research we believe that even
2582.04s - 2587.94s |  seamlessly basic or unimpressive abilities can sometime be transformed into much much
2587.94s - 2593.92s |  greater uh much more powerful uh capabilities. We're familiar with uh typical chains of
2593.92s - 2598.90s |  vulnerabilities that addresses known issues like bypassing stack cookies or other memory
2598.90s - 2603.86s |  corruption mitigations. But it's not always so straightforward. Sometimes you might have
2603.86s - 2609.06s |  unconventional abilities like forcing an endless loop that repeatedly opens a file. For
2609.06s - 2614.94s |  real, who thought this ability might be helpful? So this can use to create a very
2614.94s - 2621.24s |  unconventional flows that still allow you to achieve your ultimate goal. The next takeaway
2621.24s - 2626.88s |  shifts to the defensive side. Many products leave known issue and bugs unfixed due to
2626.88s - 2633.48s |  prioritization. Often this issue seems to pose no security risk or only minor ones that
2633.50s - 2638.68s |  doesn't require immediate attention. However addressing these known issue bugs or minor
2638.68s - 2644.68s |  security risk can sometime be crucial for mitigating much greater risk that you might not
2644.68s - 2649.68s |  be aware of. For example if we didn't have the DOS vulnerability that allows quick share to
2649.68s - 2656.66s |  crash, we wouldn't be able to have uh establish a stable wifi connection and this would
2656.66s - 2663.00s |  have completely disabled our RC chain. Lastly it's crucial for organizations to develop
2663.02s - 2669.36s |  software and develop software to focus not only on specific programming mistake like memory
2669.36s - 2674.40s |  corruption bugs. When evaluating a program security it's important to take a broader
2674.40s - 2680.74s |  perspective and consider whether a simple logic or intended behavior might also introduce
2680.74s - 2687.24s |  security risk. That's pretty much it. Here's the QR code for our repository. Feel free to
2687.32s - 2693.46s |  take picture. It has a lot of tools to play with quick share. You can also find the contact
2693.46s - 2699.70s |  details for all and myself and we'd like to thank everyone for joining to our session. We
2699.70s - 2704.70s |  hope you enjoyed it. Thank you. Thank you everyone. Thank you. It was really fun.


url: https://www.youtube.com/watch?v=gLOv67LlIQs
title: DEF CON 32 - Smishing Smackdown: Unraveling the Threads of USPS Smishing and Fighting Back - S1nn3r
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=gLOv67LlIQs",
  "title": "DEF CON 32 - Smishing Smackdown: Unraveling the Threads of USPS Smishing and Fighting Back - S1nn3r",
  "description": "This past holiday season saw a dramatic rise in SMS phishing (smishing) messages, specifically targeting people pretending to be the USPS. Almost everyone in the United States received one of these messages using a kit sold by the \u2018Smishing Triad\u2019. While many of us knew these were scams many more did not, including someone close to me.\n\nI knew I had to do something about it once I started receiving these texts myself. With my focus in web application testing, I immediately took interest in these smishing kits and how I could exploit them. After a thorough review, some collaboration with other researchers, and a little reverse engineering I was able to find two vulnerabilities in the scammer\u2019s kits allowing me to login to the admin panels.\n\nUsing this I have been able to recover over 390k distinct credit cards that the scammers had gathered using over 40 admin panels and well over 900 unique domains. Along with this was info on the scammers themselves like login IPs, usernames, and some cracked passwords they use.\n\nThis talk will cover the technical details of how I reverse engineered this kit, found these vulnerabilities, and collected the victim and admin data for each of these sites.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1834,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

1.17s - 6.17s | This text was transcribed using whisper model: large-v2

 Good morning. Hey, how's everyone doing? Woo! Excited to be here, second day. Alright, so
10.67s - 15.81s |  thank you all for coming to my talk today on Smission Smackdown and Robin Threads of the
15.81s - 22.15s |  United States Postal Service. Smission, SMS efficient and fighting back. So to start off,
22.15s - 25.95s |  just gonna cover a little bit about who I am. Uh so I work full time as a red team operator.
25.95s - 31.81s |  I recently graduated university, uh first first full time job, kinda lucky with that. Um
31.81s - 35.45s |  well in university found around $10,000 in various bug bounty programs, that's how I got
35.45s - 41.73s |  started in web application testing. And various certifications, blah blah blah. Uh and I
41.73s - 48.51s |  also recently founded a company, Phantom Security Group with a friend of mine. So, who
48.51s - 53.51s |  here, show of hands, got one of these text messages? Oh shoot. Okay. Okay. A little bit more
54.37s - 59.37s |  than I expected. Uh I expected a good amount but um yeah. How did this all start? Just one
63.61s - 68.61s |  of those text messages that you just saw on screen that most of you got it seemed. Uh and
70.75s - 76.53s |  that text message was just sent to the wrong man's wife. My wife, as it so happens. And she
76.53s - 81.77s |  unfortunately fell victim to this scam. And then just a few days later, I got that text
81.79s - 87.67s |  message. And I'm sitting there, I'm bored, uh we're on winter break between semesters and I
87.67s - 92.67s |  love hacking web apps. And what did that text have in it? A link to a web app. And so they
95.97s - 102.05s |  set up the web app for me, it's good to go, it's it's like hack the box, come on. So I loaded
102.05s - 106.95s |  up that site in my browser, um looks pretty legit, I will admit. And that's actually
106.97s - 111.97s |  because the they load in most of the resources for the site from the actual USPS.com site. And
114.47s - 120.91s |  so most of the links they just take you to the USPS official site um but below this
120.91s - 127.19s |  screenshot and this little red area you can see, delivery failed, you can enter your data and
127.19s - 131.79s |  this is where they start, the scammers start collecting your data. And so I wanted to get in
131.79s - 136.03s |  the middle, I wanted to intercept that traffic and do a little bit more digging than the
136.07s - 140.71s |  simple like Firefox developer tools allowed. So I loaded up burp suite, um community
140.71s - 146.29s |  edition of course, I'm not rich. Um but the first thing I did and first thing I noticed
146.29s - 150.25s |  actually was that a lot of the traffic was going to a different domain, a similar one but
150.25s - 155.65s |  different. And I'm just going to call this the C2 or command and control domain because for
155.65s - 160.83s |  some of the kits it was on the same server, for some of them it wasn't. And that became my
160.83s - 164.91s |  new target. And so with burp suite loaded up I could see those HTTP requests and one of the
164.91s - 169.79s |  first things I noticed was WebSocket traffic. And I was like why is there WebSockets
169.79s - 175.83s |  going on? Why'd they set up WebSockets just to give us a static HTML page? There's no reason
175.83s - 181.67s |  to do that. But that turned out to be one of the scammers first of many mistakes. And that's
181.67s - 186.91s |  because by doing a simple path traversal uh you could grab any file on the system
186.91s - 193.07s |  basically. So like it was just as simple as dot dot slash dot dot slash etc. You get you get
193.61s - 198.75s |  the point. Um but yeah with this path traversal LFI whatever you want to call it um I was able
198.75s - 204.21s |  to read basically everything but this machine that it was on this web application was just a
204.21s - 208.95s |  bare image. There was the obviously the web application itself that they were using to
208.95s - 214.33s |  collect information but nothing really else on there so no like SSH keys or other ways that
214.33s - 220.63s |  you would be able to log in usually uh with this type of vulnerability. Uh so looking around
220.63s - 225.91s |  very little as I said but I did find the access logs for this server. Um some of the other
225.91s - 230.41s |  servers uh later on like their access logs so big you can't pull it it just crashes the
230.41s - 237.01s |  server. But this one I got lucky and I was able to actually pull down the file. And before I
237.01s - 241.79s |  cover that I'm just going to show what path traversal vulnerability is just so some people
241.79s - 246.29s |  understand it if you don't work with web apps often. Um but a path traversal is when a web
246.29s - 250.93s |  application is configured to grab a file from the server and that file is specified through
250.93s - 256.71s |  some sort of argument. So in this example the file name argument is used to grab gift dot png
256.71s - 261.71s |  on the left. But if there's not proper sanitize sanitization of user input then an attacker
265.35s - 270.85s |  can just grab any file from the system. And so usually it's from it starts in the web root
270.85s - 275.85s |  directory and so you have to do some dot dot slashes to get up a few directories to the top
275.85s - 280.45s |  and then grab a already known file just so you can test it out so et cetera password in this
280.45s - 286.57s |  case. So now now that we're caught up on web application testing uh let's get to the access
286.57s - 292.53s |  logs. So in here uh going to the very top so where usually the setup process is happening for
292.53s - 297.71s |  the web server we can see that the scammers are using a tool called bt panel. Um some people
297.71s - 304.25s |  might be familiar with it it's uh Chinese software for server administration through a web
304.25s - 309.25s |  app and that bt panel software uses phpMyAdmin and looking at the uh you can see the IP
312.53s - 317.57s |  address of the scammer accessing that phpMyAdmin endpoint and you can tell it's not one of
317.57s - 323.03s |  those web crawlers web scanners because it's phpMyAdmin underscore a long string of
323.03s - 327.85s |  characters that's so random that a scanner's not going to find that and also it's returning a
327.85s - 332.19s |  two hundred okay status code to that which means it's it actually exists that endpoint is
332.19s - 337.19s |  real. Um yeah I plugged that IP into IP location and some of you might already know where
339.79s - 345.83s |  it's from but uh we'll get to that in a little bit um but after that obviously just did an
345.83s - 352.41s |  nmap scan of uh the web application just got to get some scanning started and two open
352.45s - 359.45s |  ports uh 443 obviously for HTTPS and so we need that open to access the site and then also
359.45s - 364.45s |  21 for FTP and that that was kind of weird to me uh FTP is slowly dying it's 1970s I think
367.63s - 373.99s |  um but I tried multiple ways to get in through here uh because usually FTP if it's older set
373.99s - 379.01s |  up is various different CVEs for it uh also tried brute forcing that didn't work out so I had
379.77s - 384.77s |  to get back to the web application and also if you look at the scan uh some interesting
387.41s - 393.29s |  stuff you can find with the SSL certificates is that the subject alternate alternate names it
393.29s - 398.29s |  contains all the domains that are linked back to that web app so you can just collect them
400.85s - 405.63s |  that way instead of having to go look online uh find different scammers but this all links
405.65s - 410.93s |  back to this IP address this web application here but this was interesting information it
410.93s - 414.93s |  wasn't an RCE or anything I was looking for like SQL injection or something like that I
414.93s - 419.93s |  want I I wanted to take over this app I didn't want to get information disclosure so I had
422.31s - 427.07s |  read access to the file system the path traversal I had a bunch of different domain names
427.07s - 431.61s |  linked back to the web app and I had to I had figured out like a little bit about how the
431.63s - 436.17s |  backend works with that path traversal vulnerability but I didn't really have any admin
436.17s - 441.81s |  data besides the IPs access and the access logs um and no victim data at all I didn't know
441.81s - 446.81s |  who was being scammed exactly general guess just of who it was but I had to dig deeper and
448.89s - 453.89s |  try harder is offset might say don't kill me for saying that um yeah so I I did just that try
454.11s - 459.11s |  harder uh and this led to a breakthrough I'm still going to cover it up because uh don't want
462.31s - 468.69s |  to reveal which endpoint is vulnerable to this but it was a blind unauthenticated time based
468.69s - 473.69s |  SQL injection vulnerability which in short is a really slow dump of a database uh very very
476.07s - 481.07s |  slow and the way I was able to find this is just simple single quotation in an argument and
484.11s - 489.61s |  it returned a 200 okay status code not like a 500 error which what you would expect but in the
489.61s - 496.61s |  message returned it said error um which none of the other responses did uh when you insert a
496.61s - 503.39s |  colon in there or colon single quote whatever you're testing with so yeah dumped the
503.39s - 509.89s |  database for that domain uh some interesting tables in there dumped some of the contents of
509.89s - 516.81s |  those tables and looking at those tables config was actually surprisingly boring uh most of
516.81s - 521.41s |  the data in there was just what type of credit cards are you taking in an activation key for
521.41s - 526.41s |  the kit itself uh some other things like that user info and records were encrypted blobs so I
528.99s - 533.99s |  tried dumping them and no luck uh it just doesn't work with time based blind injections it
534.77s - 539.77s |  very hard very slow and also there's a ton of data in them and then that left us the admin
542.93s - 549.31s |  table so in the admin table there is encrypted user names encrypted tokens like session
549.31s - 556.21s |  tokens login tokens hash passwords looking like MD5 some permission levels one through four
556.21s - 561.23s |  and unencrypted last login times and IP addresses for those admin users so that was awesome.
564.03s - 570.82s |  So can anyone guess the country? Yeah China China you're so smart it was China and this IP
574.92s - 579.86s |  address up here happens to be from the Shanghai region of China. Yeah this is when I went
579.86s - 585.00s |  ahead and published my first blog post so I have two blog posts on this the first one was
585.00s - 591.18s |  published I didn't really know it was a kit I knew it was just a scammer site that they had set
591.22s - 596.32s |  up I didn't know there was a bunch more out there and so I started looking through some of
596.32s - 601.32s |  this data cause I I had a bunch but again I wanted to access the admin portion of the site and
604.76s - 610.36s |  so looking at one of the dumps uh if you noticed it earlier there was a telegram link in the
610.36s - 615.38s |  description of one of the users going to that telegram profile you see this is WangduU0 uh and
616.22s - 621.22s |  in his bio it links to another telegram channel which has at the time of taking a
625.86s - 630.86s |  screenshot a few days ago is over 3700 subscribers excuse me and in this telegram channel we can
635.64s - 642.44s |  see some demo videos of this kit that they're selling how to posts to set up the kit
642.44s - 647.00s |  announcements of how secure the product is I mean it's super secure no one's taking your
647.00s - 656.40s |  victims your account credentials et cetera and then some stuff like this oh you can't hear
656.40s - 666.88s |  it there's no audio okay it's got some hype up music so yeah who is this who's who's posting
672.84s - 678.98s |  these videos who's making this kit so that's that WangduU0 character that uh we first found
678.98s - 685.44s |  a link for and so I actually got to chatting with him on telegram I was pretending I was a uh
685.44s - 689.78s |  which country I said I was but I I was obviously using Google Translate to talk to him so I
689.78s - 694.96s |  had to say I didn't speak Chinese and uh all that but got out of him that he's a current
694.96s - 699.82s |  computer science student in China at least at the time of talking to him uh it was about
699.82s - 704.10s |  January time frame of this year and so he may have graduated now but at at the time of
704.16s - 710.26s |  talking he was a computer science undergraduate it seemed like and along with him there's some
710.26s - 715.26s |  other members of the group that do graphic graphic design uh web developers of course um and
718.40s - 723.74s |  I got that information from a company called RE Security and it turns out so when Googling
723.74s - 729.78s |  the WangduU0 character uh two blog posts from RE Security popped up and they had already
729.80s - 736.40s |  done a good amount of research on this uh USPS submission campaign along with other
736.40s - 741.40s |  campaigns of this group that they dubbed the submission triad uh had done and uh okay so
750.04s - 755.04s |  cool thank you. Yeah the submission triad uh they had found some various vulnerabilities in
757.74s - 763.44s |  the USPS kit beforehand and so they had also found a similar SQL injection vulnerability in
763.48s - 768.56s |  the kit but the author of the kit had read their blog, patched the vulnerability, started
768.56s - 774.12s |  encrypting data, he also added captchas to logins um for admins like a bunch of other security
774.12s - 780.40s |  features um but we'll get into how we bypassed all that. So the RE Security hunter team had
780.40s - 786.64s |  mentioned in the blog that they had acquired purchased through some means a kit from the
786.64s - 792.98s |  submission triad. So I'm broke uh these kits cost $200 a month and I'm I'm not paying that
793.02s - 798.02s |  uh like no. So also I can't support scammers so that's another thing. But yeah so I I begged
800.76s - 806.00s |  them uh they get back to me they're like hey uh what can we read about what you've done can
806.00s - 809.60s |  you tell us a little bit what what you're looking into. Talk back and forth and they were
809.60s - 815.34s |  kind enough to send over the kit for free. And so unzipping the kit one of the first things I
815.34s - 820.34s |  noticed was default credentials. Admin and a password of one two three four five six.
823.14s - 828.12s |  And then when you log in for the first time you don't have to change it. So that makes it
828.12s - 833.26s |  nice and easy for us. Um and I will mention about 20% of the kits I ended up finding still
833.26s - 839.96s |  had those default credentials. Uh the thing was the hashes so I I it looked like MD5 I
839.96s - 844.76s |  presumed it was MD5. The MD5 hash for one two three four five six did not line up with what
844.76s - 849.44s |  was in the pre-prepared database. And so I knew there was something going on there was some
849.44s - 855.80s |  salt being added maybe it was some similar similar algorithm um that yeah I just didn't
855.80s - 862.82s |  know about. But the issue was looking at the code it it was gross. Like not even human
862.82s - 867.82s |  readable. Um very highly obfuscated PHP code. In the along with that PHP code it was using
871.70s - 876.96s |  introspection so you can't add like echo statements in there to echo stuff out and also it
877.02s - 884.00s |  had multiple times it was checking where uh checking to see if it was being debugged. And so
884.00s - 888.96s |  I just couldn't find a way I spent multiple days trying to uh de-obfuscate uh the code in
888.96s - 894.60s |  there. But that's when a friend of mine actually up here in the first row uh suggested using a
894.60s - 900.74s |  technique called eval hooking. And so using simple echo statements so you hook the eval
900.76s - 907.44s |  function which it has to be plain PHP plain text PHP to be executed by the eval function for
907.44s - 912.08s |  the page to work. So if you just hook into that function echo out what it's executing you can
912.08s - 918.92s |  slowly figure out what's going on in the code. And so you can see some of my notes here and
918.92s - 924.32s |  the variable names are disgusting gross uh but up in the middle there's little comments
924.32s - 930.10s |  added after them. And you can see that the usernames are being encrypted with AES 128 CBC.
930.12s - 935.12s |  Uh and they're using the key of WDY666666 just meaning length requirements. And then the
940.16s - 945.16s |  IV of AES 128 wangdu8. Um and so he loves using his own name in these passwords and stuff. So
950.00s - 953.94s |  now the passwords were a bit trickier though. Uh it took a little bit longer to figure out.
953.96s - 958.96s |  And the passwords were appended with a salt. Uh so wangdu you again more 6s and then special
961.52s - 966.60s |  characters. Um and then after that they were hashed three times using empty 5. The gold
966.60s - 973.60s |  standard for hashing algorithms. I know it's 20 he wrote it in 2023 so like yeah I don't know
973.60s - 977.88s |  what he's I don't know what he's learning in school but yeah. Then also we look at the
977.88s - 983.92s |  activation. Uh so looking into the kit I noticed that when I would ex like spin up the
983.92s - 990.90s |  server it would check it's activation. And so this is some uh base 64 encoded uh well hex
990.90s - 995.90s |  and then base 64 encoded data. And he hardcoded his IP address for his admin server like
999.44s - 1004.64s |  right there um in the code. So uh that that's his IP address. I don't I haven't checked
1004.64s - 1009.64s |  recently if it's still up but you can go say hi to him. Um but also he was double dipping. So
1011.72s - 1016.68s |  he's charging 200 bucks a month for this kit. He's he he makes tons of reassurances that he's
1016.68s - 1019.76s |  not stealing their information. No one else is stealing their information. But every time an
1019.76s - 1024.76s |  admin logs in it sends their login token to him. So he's he can just log in as that user and
1025.76s - 1030.76s |  take their victim data along with their 200 bucks a month. So no honor. But yeah so now we
1037.08s - 1044.08s |  have the method for hashing of the passwords. And so I go ahead and make a go tool, little
1044.08s - 1051.30s |  quick go tool to crack those passwords. And you can see my command line up there uh it's
1051.30s - 1056.30s |  kind of small up here but uh just using ROKU against the hashes and printing them out. So
1056.30s - 1062.04s |  you can see like 1 2 3 4 5 6 obviously the default uh but like straight 0's 1 2 3 1 2 3 1 2
1062.04s - 1068.38s |  3 3 2 1. Admin 3 3 admin 1 etcetera. All these really easy passwords but obviously it's ROKU
1068.38s - 1073.08s |  so it's only going to crack the easy ones. But the issue was some of the larger panels I was
1073.08s - 1080.40s |  finding ROKU wasn't cracking those any of those passwords for the users. And so I had to
1080.40s - 1085.04s |  add normal I had to use password cracking techniques to crack them. So the first thing I
1085.04s - 1091.74s |  did was rules basically just adding suffixes to the ROKU word list um as it's going through.
1091.74s - 1096.92s |  Uh just append in 1 to the end exclamation point dollar sign uh other different symbols and
1096.92s - 1102.02s |  number patterns that I was seeing in a lot of the passwords. And then I also needed a new
1102.02s - 1108.02s |  word list for this because they're mostly Chinese based. So uh I needed a word list that
1108.02s - 1113.38s |  wasn't ROKU because ROKU is English obviously uh for the most part. Uh and most other word
1113.38s - 1119.52s |  lists are like English, French, that sort of thing. Not there's not many uh Asian word lists
1119.52s - 1124.50s |  out there um for a lot of Asian languages. So the one I ended up choosing was the
1124.50s - 1129.50s |  Kayonashi word list and it was one of the only word lists I could find actually for this. And
1129.50s - 1134.30s |  using that word list and these rules I was able to crack over 130 of those hashes for those
1134.32s - 1141.32s |  admin users. So now we have decrypted usernames. We have cracked passwords. We can just log
1141.32s - 1147.40s |  into these panels right? Oh and this is like this is the default admin like login screen. Uh
1147.40s - 1152.54s |  but no you you can't do that. Uh the majority of those admin panels actually have wait
1152.54s - 1157.98s |  lists set up for IP addresses. And like that okay that's pretty good. Um the luckily for us
1157.98s - 1163.72s |  though like some of them just didn't set it up. So we were able to test this out on a few
1163.74s - 1170.04s |  different panels, three to be exact. And uh you enter using a password and solve the
1170.04s - 1175.18s |  CAPTCHA and then you just log in. And so this is the inside of the panel, this is the main
1175.18s - 1182.02s |  dashboard. Uh they got nice statistics, uh numbers, everything. Uh and who doesn't love
1182.02s - 1187.02s |  Excel um or CSV format and stuff. Um so they have that and you can view the domain names that
1187.24s - 1192.24s |  they were uh scamming people from. But those restrictions on access and slash admin really
1196.38s - 1202.38s |  hampered what we were able to do or what I was able to do because you couldn't dump any of the
1202.38s - 1207.36s |  kids except for those three that had the wait list not enabled. And so to bypass that
1207.36s - 1212.90s |  there's these endpoints that it reaches out to to authenticate, to grab victim data, to grab
1212.94s - 1218.52s |  admin data, to list those domains that we just saw on the previous slides. Uh and those
1218.52s - 1223.76s |  endpoints don't have the wait list on them. So they're they're not protected at all. And so
1223.76s - 1228.50s |  all I had to do was just authenticate directly to those endpoints. Um so here I'm just
1228.50s - 1234.36s |  authenticating and getting the login token and here this is just accessing the data for the
1234.36s - 1239.54s |  home panel. So overall statistics for how many phishes. So it looks like all records, this
1239.58s - 1246.68s |  one had like 9,200 victims it looks like. And so now using this uh I mean I, Burp Suite's
1246.68s - 1250.92s |  awesome but I didn't want to have to do this every time I found the kit. So I automated the
1250.92s - 1256.20s |  process and here we'll show a little demo of it. So the capture pops up. Couldn't really find a
1256.20s - 1261.24s |  bypass for the capture so had to solve it manually unfortunately. And to the capture it goes
1261.24s - 1266.14s |  through dumps that data for me and so this kit that I just dumped there had 28 victims so
1266.14s - 1271.62s |  really small brand new one. Uh and then this one we're about to have is going to have over
1271.62s - 1278.12s |  like 5,000 victims in it. Um so here dumps the pending victims, complete victims. So it's
1278.12s - 1284.70s |  going to have uh if you dumped over 1,000 victims at one time in a page it would crash the
1284.70s - 1289.70s |  server. And so I would have to dump like 1,000 a page and then iterate through there however
1290.34s - 1295.34s |  many pages um it was. And so there we go that's the recording. But like 48 pending victims
1299.38s - 1306.07s |  and then 4,900 something completed victims. But we need more targets so I had the automation
1306.07s - 1313.21s |  set up. I needed a better way to get these URLs other than them just texting me cause I only got
1313.21s - 1319.55s |  a few text messages. So I crowdsource. I set up a site for people to submit URLs to uh and it
1319.55s - 1323.39s |  would grab so there's a static javascript config file in there and I could grab that like
1323.39s - 1328.39s |  C2 domain uh from that file and uh that just makes my life easier. But also I found a bunch
1331.39s - 1336.41s |  of URLs here. So r slash scams on Reddit uh people post screenshots of their text messages.
1341.31s - 1348.05s |  So I had to hand jam those URLs in which is unfortunate but it was okay. Um but yeah uh just
1348.05s - 1352.99s |  hand jam those URLs in and one thing I also noticed when going through r slash scams it was
1352.99s - 1361.14s |  there was a copycat campaign going on. This copycat campaign was interesting to me. Because
1361.14s - 1366.74s |  they had ripped the entire front end of the submission tree ads kit and just placed it on top
1366.74s - 1371.46s |  of their backend. And you could tell they had done that because the site was reaching out the
1371.46s - 1376.90s |  endpoints that didn't exist on this server but would exist on the submission tree ads backend.
1376.90s - 1381.54s |  So like WebSockets for example like there's no need to set up WebSockets they realized this so
1381.54s - 1385.80s |  they didn't set up WebSockets but it's still trying to reach out to it because they just
1385.80s - 1391.80s |  didn't even edit the javascript in the site. So that was interesting uh didn't really end up
1391.80s - 1396.58s |  exploiting this campaign uh just targeted the submission tree ads one but uh something of
1396.58s - 1403.62s |  note. So now I I was get gathering those URLs from different places and this was the process
1403.64s - 1408.82s |  I would go through. I would extract the admin panel URL uh from that static javascript
1408.82s - 1415.42s |  config file. I would exploit that time based SQL injection against that domain. Uh dump the
1415.42s - 1422.12s |  admin table, decrypt the usernames from that, put the hashes in the cracker tool uh let that
1422.12s - 1427.90s |  run for a little bit, took forever. Um and once it was done uh I would hopefully have a new
1427.92s - 1433.92s |  login that I could add to that automation script that I just showed you. So now after doing
1433.92s - 1438.92s |  all this uh got some interesting statistics. So this is my chat GPT generated info graphic um
1443.90s - 1450.64s |  look at that. Uh but total times uh data was entered so this is times uh credit card was
1450.64s - 1456.44s |  entered. So 1.2 million times a credit card was entered into this site. So they went
1456.48s - 1459.82s |  through the whole process to enter your credit card. The total unique credit cards though
1459.82s - 1465.82s |  was 438,000. Um unique IPs 73,000 um unique emails used 54,000 and then domains used by the
1470.16s - 1475.16s |  scammers they used uh over 1100 domains um which is crazy. The thing is this isn't even all
1478.00s - 1482.04s |  the data this is the ones I was able to find there's more there was more out there uh they go
1482.04s - 1488.22s |  up and down all the time getting taken down uh so it the numbers are much larger than this
1488.22s - 1494.86s |  probably. So now looking at those admin logins uh we can do a simple map of their IP
1494.86s - 1499.86s |  addresses. You can see where they're logging in from. Get some interesting statistics on
1499.86s - 1504.46s |  this. You can see a lot of the publicly known proxies are coming from the United States so
1504.46s - 1509.54s |  they're proxying to the US. Um so there there are some people logging in from the US that
1509.54s - 1514.54s |  aren't from publicly known proxies. Excuse me. Um some in Europe and so most of them are in
1517.04s - 1522.06s |  China but obviously anyone can buy this kit so admins are going to be logging in from
1522.06s - 1527.06s |  throughout the world. But zooming in on Asia you can see cluster in Taiwan you can see a
1529.90s - 1535.50s |  cluster in I think that's Hong Kong and Shanghai region uh and then also some down in
1535.50s - 1540.50s |  Philippines and those islands. Now mapping the victims the same way uh this was wild. So
1545.30s - 1550.38s |  yeah I mean it's USPS so obviously a ton in the US but also like a ton throughout the world
1550.38s - 1555.18s |  and I'm going to guess this is a combination of people testing out those random links and
1555.18s - 1561.22s |  also tourists so people traveling they get those text messages and enter their data that way.
1561.22s - 1566.18s |  Zooming in on the US it's basically a population density map. Um so tons of around the east
1566.18s - 1572.46s |  coast obviously uh gets a little thin throughout the midwest and then SoCal and up in
1572.46s - 1579.16s |  Washington, Oregon. Um and also cluster out in Hawaii. So yeah a lot a lot of IP addresses
1579.16s - 1585.44s |  there. More infographic. Let's look at the top 3 states. Uh California was number 1 with
1585.46s - 1590.46s |  141,000 victims. Texas had 119,000 and Florida had over 100,000. Uh top 3 email domains used
1593.90s - 1598.90s |  uh Google, well Gmail was way at the top with 93,000. iCloud with 15 and Yahoo with 12. And
1602.42s - 1608.92s |  then other stats. So the average credit cards entered out of this 1.2 million entries on
1608.92s - 1614.56s |  average people entered 2.48 credit cards. So almost rounding up to 3. And the reason for this
1614.58s - 1617.54s |  was when you go through this process and you enter your credit card it would be like oh this
1617.54s - 1622.72s |  card's invalid enter a new one. And so people would just keep entering credit cards. I saw 6
1622.72s - 1628.26s |  credit cards for some of them. It was crazy. Um and so it's unfortunate but they just that's
1628.26s - 1634.86s |  why unique email addresses and unique credit cards that was such a big difference. Also you
1634.86s - 1639.96s |  can see the number of .edu emails in there so a lot of professors, staff at universities,
1640.00s - 1645.30s |  students obviously so 471 there. Uh some people were using the .mil email addresses which I
1645.30s - 1653.56s |  was kind of surprised about so 3.mils in there and 17.gubs so federal employees. Um so what
1653.56s - 1659.26s |  happened with all this data? I had all this 1.2 million victim records here. I started
1659.26s - 1664.16s |  looking for some help. So no one really wanted to reach back out to me though. So I I I
1664.16s - 1669.84s |  reported through uh internet crime centers like online forum and FBI like reported tip or
1669.84s - 1676.02s |  whatever and the postal inspectors I emailed them and no one really reached out until the
1676.02s - 1681.38s |  banks did. Uh one of the major banks threat intelligence teams had like read my blog on I
1681.38s - 1686.82s |  think like LinkedIn or something and uh they got in touch with me uh set up a meeting with
1686.82s - 1692.76s |  their team and I just walked through what I'd done and showed uh securely the victim data
1692.76s - 1697.34s |  with them so that they could go through find their customers uh get those credit cards
1697.34s - 1702.18s |  canceled make sure any false charges get handled and then they also pass it off to their
1702.18s - 1706.78s |  network of banks and so just that single major bank they were able to help over 80,000
1706.78s - 1712.82s |  people which is wild. Um and then with that they also got me in touch with the U.S. postal
1712.82s - 1717.72s |  inspectors office. They had a contact in their cyber crimes uh division there and so worked
1717.72s - 1721.26s |  with the postal inspectors I was able to share that admin data as well along with the victim
1721.26s - 1726.90s |  data and uh a chat export of my conversation with Wangdu Yu because I'd gotten some
1726.90s - 1732.40s |  interesting information from him in regards to the case that they were doing. Um one thing
1732.40s - 1736.48s |  that they had mentioned so the bank along with the postal inspectors office is that it's
1736.48s - 1740.04s |  really hard to identify victims in this case because there's so many different ways your
1740.04s - 1744.58s |  credit card can get stolen and having this like hard evidence I don't know if it's probably
1744.58s - 1749.52s |  not admissible in court but having this hard link between this is where you entered your
1749.52s - 1754.60s |  credit card and they're known for stealing your credit card so there you go you can just
1754.60s - 1758.70s |  link the two together directly. Um investigation seems to be ongoing there's been no update
1758.70s - 1765.14s |  um if any of you read the Wired article that was posted just a few days ago uh Matt Bruges
1765.14s - 1769.24s |  uh from Wired he talked to the postal inspectors office they still say the investigation is
1769.24s - 1776.66s |  ongoing. And so how do how can we fix this issue? Um other than manning the middle in
1776.66s - 1783.40s |  every text message uh don't do that by the way uh I'm not an expert in any of these fields
1783.40s - 1789.40s |  so SMS, iMessage, iOS, Android um but I think some better client side filtering needs to be
1789.40s - 1794.54s |  done so obviously I'm going to say the buzzword AI um AI can actually be helpful in this
1794.54s - 1799.28s |  identifying hey why is USPS texting you in the first place and secondly why are they
1799.28s - 1805.58s |  linking you to this site that's obviously not the USPS's official site. Um so some third
1805.58s - 1810.56s |  party integrations are actively doing stuff like this so one example um I don't use
1810.56s - 1814.62s |  them this is just something I found was Truecaller does something similar uh and you can
1814.62s - 1820.70s |  just integrate it into your at least iOS and I assume Android as well um they'll just do
1820.70s - 1827.34s |  that filtering for you. So with that, that concludes my presentation. Thank you DefCon uh it's
1827.34s - 1827.84s |  been amazing.


url: https://www.youtube.com/watch?v=hB6rtwoyyrg
title: DEF CON 32 - Securing CCTV Cameras Against Blind Spots - Jacob Shams
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=hB6rtwoyyrg",
  "title": "DEF CON 32 - Securing CCTV Cameras Against Blind Spots - Jacob Shams",
  "description": "In recent years, CCTV footage has been integrated in systems to observe areas and detect traversing malicious actors (e.g., criminals, terrorists). However, this footage has \"blind spots\", areas where objects are detected with lower confidence due to their angle/distance from the camera.\n\nIn this talk, we investigate a novel side effect of object detection in CCTV footage; location-based confidence weakness.\n\nWe demonstrate that a pedestrian's position (distance, angle, height) in footage impacts an object detector's confidence.\n\nWe analyze this phenomenon in four lighting conditions (lab, morning, afternoon, night) using five object detectors (YOLOv3, Faster R-CNN, SSD, DiffusionDet, RTMDet).\n\nWe then demonstrate this in footage of pedestrian traffic from three locations (Broadway, Shibuya Crossing, Castro Street), showing they contain \"blind spots\" where pedestrians are detected with low confidence. This persists across various locations, object detectors, and times of day. A malicious actor could take advantage of this to avoid detection.\n\nWe propose TipToe, a novel evasion attack leveraging \"blind spots\" to construct a minimum confidence path between two points in a CCTV-recorded area. We demonstrate its performance on footage of Broadway, Shibuya Crossing, and Castro Street, observed by YOLOv3, Faster R-CNN, SSD, DiffusionDet, and RTMDet.\n\nTipToe reduces max/average confidence by 0.10 and 0.16, respectively, on paths in Shibuya Crossing observed by YOLOv3, with similar performance for other locations and object detectors.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 968,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 and nighttime lighting conditions.
3.36s - 5.92s |  And these are the results for the lab videos
5.92s - 8.04s |  that were analyzed by YOLOv3.
8.04s - 9.68s |  Each circle represents measurements
9.68s - 12.28s |  that were taken from a different height,
12.28s - 14.40s |  with each ring representing a specific distance
14.40s - 18.12s |  from the camera, and each sector representing a different angle.
18.12s - 21.04s |  The green indicates that the average detection confidence
21.04s - 24.32s |  for that position was above 0.8.
24.32s - 26.32s |  And similarly, the yellow represents
26.32s - 29.72s |  that the confidence value was between 0.6 and 0.8,
29.72s - 32.12s |  and the red indicates that the average confidence was
32.12s - 34.52s |  below 0.6.
34.52s - 36.44s |  We found that the position of the person
36.44s - 39.80s |  does affect the confidence level of the object detector,
39.80s - 43.32s |  and can result in a change in confidence of up to 0.7,
43.32s - 47.44s |  depending on the position of the person in the frame.
47.44s - 49.20s |  And here we can see the same measurements
49.20s - 51.32s |  in tables for the other videos.
51.32s - 53.20s |  Each table represents a different set
53.20s - 56.16s |  of videos taken in a different lighting condition,
56.16s - 58.32s |  with each row representing a different distance
58.32s - 60.40s |  and height configuration, and each column
60.44s - 63.48s |  representing a different angle that the person stood at.
63.48s - 65.24s |  The green, yellow, and red are the same as
65.24s - 67.00s |  on the previous slide.
67.00s - 69.68s |  And we have found that across all the various lighting
69.68s - 73.08s |  conditions, the same position-dependent behavior
73.08s - 75.00s |  in the object detector, with a confidence
75.00s - 80.08s |  range of approximately 0.7 in the different videos.
80.08s - 82.00s |  In addition, we found the same behavior
82.00s - 84.96s |  in FasterR-CNN, with a confidence range
84.96s - 88.88s |  difference of between 0.35 and 0.45,
88.88s - 92.48s |  depending on the lighting conditions.
92.48s - 94.80s |  So to conclude this analysis, we found
94.80s - 96.76s |  that the confidence of an object detector
96.76s - 99.12s |  is dependent on the person's distance, angle,
99.12s - 100.92s |  and height from the camera.
100.92s - 102.64s |  In addition, since object detectors
102.64s - 104.68s |  have a minimum confidence threshold,
104.68s - 107.64s |  if a person's position results in a confidence measurement
107.64s - 109.80s |  below this threshold, then in theory,
109.80s - 113.81s |  the person would be able to avoid detection.
113.81s - 116.37s |  In addition, as part of this analysis,
116.37s - 120.13s |  I also analyzed the effect of the camera quality
120.13s - 122.33s |  on the results.
122.33s - 126.33s |  And I did this by downgrading the original 1080p footage
126.33s - 130.21s |  to 720p, as well as 480p.
130.21s - 134.13s |  And we have found that the same behavior persists
134.13s - 138.17s |  across the 720p footage, as well as the 480p footage.
138.17s - 144.41s |  The confidence range is between 0.7 on the 720p footage,
144.41s - 150.05s |  and between 0.6 on the 480p footage.
150.05s - 152.29s |  So in conclusion, the camera quality
152.29s - 154.65s |  does not impact the presence of this behavior,
154.65s - 156.81s |  and indicates that the varying confidence behavior
156.81s - 161.64s |  is independent of the quality of the camera.
161.64s - 165.32s |  Now, I'll review the second analysis that we performed.
165.32s - 167.48s |  We analyzed the previously demonstrated
167.48s - 169.96s |  position-based confidence in areas
169.96s - 172.36s |  of significant pedestrian traffic.
172.36s - 174.96s |  And this was done by utilizing public footage
174.96s - 179.48s |  from three global locations, such as Shibuya Crossing
179.48s - 182.92s |  in Tokyo, from a 24-hour period.
182.92s - 185.84s |  We took this 24 hours of footage and divided it
185.84s - 188.48s |  into six consecutive four-hour videos
188.48s - 191.40s |  in order to analyze varying times of day and lighting
191.40s - 193.36s |  conditions.
193.36s - 195.36s |  The objective of this analysis was
195.36s - 197.60s |  to determine the average confidence of an object
197.60s - 200.92s |  detector over time, as a function of the location
200.92s - 202.88s |  in an observed area.
202.88s - 206.04s |  For each video, we fed one frame every two seconds
206.04s - 208.40s |  to an object detector, and then calculated
208.40s - 211.12s |  for each pixel in the frame the average confidence
211.12s - 217.14s |  of person bounding boxes that landed on the pixel.
217.14s - 220.66s |  I repeated this with five different object detectors,
220.66s - 223.86s |  as well as three videos from three locations
223.86s - 227.38s |  around the world, using Shibuya Crossing, Broadway,
227.38s - 230.22s |  as well as Castro Street in San Francisco.
230.22s - 232.62s |  And due to time constraints, I'll only present the results
232.62s - 237.10s |  from YOLOv3 and FasterRCNN.
237.10s - 239.66s |  So these are the results for this analysis.
239.66s - 241.58s |  Each of the six rectangles represents
241.58s - 244.74s |  a different video from a specific global location
244.74s - 246.98s |  and records for each pixel on the screen
246.98s - 249.62s |  the average confidence of person bounding boxes
249.62s - 251.82s |  that landed on the pixel.
251.82s - 253.86s |  The green indicates higher confidence,
253.86s - 256.82s |  and the red indicates lower confidence.
256.82s - 259.94s |  We found that in each video, the average confidence
259.94s - 263.42s |  of detections varies according to the location in the frame,
263.42s - 268.58s |  with average confidence varying between 0.25 and 0.92,
268.58s - 272.34s |  depending on the time of day and the location in the video.
272.34s - 275.26s |  In addition, this varying confidence behavior
275.26s - 278.30s |  persists across various lighting conditions.
278.30s - 281.26s |  For example, in the Shibuya Crossing footage,
281.26s - 283.30s |  there is a pole close to the camera,
283.30s - 285.46s |  positioned at the left third of the bottom half
285.46s - 286.82s |  of each rectangle.
286.82s - 289.98s |  We believe that this pole reduces detection confidence
289.98s - 292.34s |  in the area around the pole by obscuring people
292.34s - 294.42s |  that stand behind the pole.
294.42s - 297.02s |  And its location can be easily visualized,
297.02s - 299.62s |  just based off of the lower confidence measurements
299.62s - 302.98s |  of the area around the pole.
302.98s - 305.10s |  Also, we found similar results in footage
305.10s - 307.82s |  from Broadway and Castro Street,
307.82s - 313.49s |  as well as footage that was observed by FastRawCNN.
313.49s - 316.81s |  So, in conclusion, the confidence of an object detector
316.81s - 318.61s |  when detecting a person is dependent
318.61s - 320.85s |  on the location of the person in the frame,
320.85s - 323.41s |  with some areas demonstrating stronger confidence
323.41s - 326.33s |  and some areas demonstrating weaker confidence.
326.33s - 328.41s |  These stronger and weaker detection areas
328.89s - 330.81s |  can be visualized in a heat map,
330.81s - 333.65s |  which indicates the object detector's performance
333.65s - 335.33s |  on the given area.
335.33s - 337.45s |  In addition, these findings are independent
337.45s - 339.69s |  of location and object detection model.
341.53s - 344.25s |  Now, I'll present our novel evasion attack
344.25s - 345.89s |  that we call Tiptoe.
345.89s - 347.81s |  We found, in our previous analysis,
347.81s - 350.41s |  that it's possible to discern knowledge
350.41s - 352.89s |  of varying object detector confidence
352.89s - 355.37s |  based on a person's distance, angle, height,
355.37s - 357.37s |  and location in a camera frame.
357.37s - 358.93s |  Using these insights,
358.93s - 361.73s |  we want to construct a path across the scene
361.73s - 364.53s |  with minimal or no detection from an object detector.
366.13s - 368.05s |  So, before getting into the methodology,
368.05s - 371.49s |  I'll define a few terms, as well as the problem space.
371.49s - 374.13s |  First, a scene is a physical area
374.13s - 377.05s |  that is observed by footage fed to an object detector.
377.93s - 380.81s |  The scene is stationary and does not change.
380.81s - 383.33s |  Second, a confidence heat map records
383.33s - 385.25s |  for each pixel in the scene
385.29s - 387.41s |  the average confidence of bounding boxes
387.41s - 389.81s |  that land on the pixel over time.
389.81s - 392.01s |  And similarly, a detection heat map
392.01s - 394.93s |  records for each pixel the number of bounding boxes
394.93s - 396.93s |  that landed on a given pixel over time.
398.81s - 402.21s |  The Tiptoe attack leverages the varying confidence levels
402.21s - 404.05s |  recorded in the confidence heat map,
404.05s - 406.85s |  which records in cell IJ the average confidence
406.85s - 409.81s |  of bounding boxes that landed on pixel IJ
409.81s - 410.97s |  in the observed scene.
411.97s - 415.53s |  We reduce our objective of finding a path across the scene
415.53s - 417.93s |  into a graph-based problem.
417.93s - 420.41s |  Initially, we have the confidence heat map,
420.41s - 421.89s |  which represents the average confidence
421.89s - 425.89s |  of each area of the scene in a matrix-based pixel format.
425.89s - 427.93s |  We then reduce the pixel-based heat map
427.93s - 430.41s |  into a graph-based problem space.
430.41s - 432.85s |  Each pixel is represented by a node in the graph
432.85s - 435.29s |  with two-way edges to its cardinal neighbors.
437.01s - 438.77s |  The weight value of each node
439.45s - 441.17s |  is the average confidence measurement
441.17s - 445.82s |  stored in the confidence heat map.
445.82s - 448.90s |  This reduces our problem of finding an optimal path
448.90s - 451.94s |  between two locations in a pixel-based scene
451.94s - 456.30s |  into a graph-based optimal path problem between two nodes.
456.30s - 457.90s |  In order to avoid detection,
457.90s - 459.22s |  the attacker will want to reduce
459.22s - 461.82s |  both the maximum confidence of the path nodes
461.82s - 464.42s |  as well as the average confidence of the path nodes.
465.66s - 468.24s |  Now, we'll review the threat model.
468.24s - 470.26s |  The attacker wants to construct a path
470.90s - 471.98s |  between two points in a scene
471.98s - 475.22s |  that is observed by an AI-based pedestrian detector,
475.22s - 476.74s |  such that they can cross the scene
476.74s - 479.30s |  with either minimal or no detection.
479.30s - 481.46s |  They have access to a confidence heat map
481.46s - 484.06s |  and detection heat map in order to understand
484.06s - 487.26s |  the location-based behavior of the pedestrian tracker
487.26s - 488.66s |  for the given scene.
489.54s - 491.34s |  On the other hand, they don't have access
491.34s - 494.30s |  to any adversarial perturbation methods
494.30s - 496.06s |  that would allow them to print a pattern
496.06s - 498.86s |  enabling detection avoidance.
498.86s - 500.82s |  In addition, they don't have access
500.82s - 503.70s |  to machinery like infrared light or lasers
503.70s - 505.30s |  that would directly influence
505.30s - 508.54s |  the object detector's behavior.
508.54s - 511.18s |  The only factor that the attacker has under their control
511.18s - 516.45s |  is the path that the evading person takes through the scene.
516.45s - 519.49s |  Now, I'll present the methodology of Tiptoe.
519.49s - 522.67s |  Tiptoe is a modified version of Dijkstra's algorithm
522.67s - 524.99s |  where an optimal path between two nodes
524.99s - 527.17s |  is the path that crosses the lowest possible
527.17s - 529.43s |  maximum confidence node.
529.43s - 531.97s |  Since each path has at least one node
531.97s - 535.43s |  with the highest weight or confidence on the path,
535.43s - 539.15s |  we use Tiptoe to find the path with the lowest such node.
539.15s - 542.87s |  This guarantees that any other path through the scene
542.87s - 546.29s |  contains a node with either equal or greater confidence
546.29s - 548.39s |  than the path that is uncovered by Tiptoe.
549.39s - 551.79s |  In this example, the lowest cost path
551.79s - 555.11s |  from the start to the end node is through the top node,
555.11s - 556.33s |  which is the path that will be returned
556.33s - 557.89s |  by Dijkstra's algorithm.
557.89s - 560.41s |  This gives you a total path cost of 20
560.41s - 563.51s |  with maximum and average node costs of 20 as well.
564.89s - 567.65s |  On the other hand, we want Tiptoe to find the path
567.65s - 569.37s |  with the minimum max node,
569.37s - 571.25s |  which in this case is through the middle nodes,
571.25s - 573.41s |  since the max node crossed on that path
573.41s - 575.45s |  has a cost of 10.
575.45s - 578.05s |  And every other path between the start and end node
578.05s - 581.33s |  must pass through a node with at least a cost of 10.
581.33s - 584.03s |  This gives us a more expensive total cost of 50,
584.03s - 586.89s |  but a lower max cost and average cost of 10.
586.89s - 589.13s |  This would be useful for if an attacker
589.13s - 591.45s |  is trying to stay below a detection threshold
591.45s - 593.55s |  while traversing a path through the scene.
594.99s - 597.25s |  The inputs to Tiptoe are the confidence
597.25s - 598.53s |  and detection heat maps,
598.53s - 601.33s |  as well as the starting and ending coordinates.
601.33s - 603.99s |  We perform Dijkstra according to a modified
603.99s - 605.97s |  weight node update function.
605.97s - 607.65s |  The highlighted calculation records
607.65s - 609.29s |  for each point in the scene,
609.29s - 611.63s |  the minimum max confidence that is crossed
611.63s - 613.51s |  in order to get to that point.
613.51s - 617.31s |  This contrasts with Dijkstra's weight node update function,
617.31s - 621.43s |  which minimizes the total path cost to a given point.
621.43s - 624.31s |  This calculation allows us at the end of running the attack
624.31s - 626.59s |  to find the highest confidence value
626.59s - 629.85s |  that must be crossed in order to get to each point.
629.85s - 632.11s |  We can then iteratively print the optimal path
632.11s - 633.79s |  in a similar way to Dijkstra,
633.79s - 634.91s |  by starting from the end node
634.91s - 637.07s |  and working backwards to the starting node.
638.47s - 640.15s |  So to evaluate Tiptoe,
640.15s - 642.63s |  we utilize the confidence and detection heat maps
642.63s - 644.59s |  that we generated from pedestrian traffic
644.59s - 646.67s |  in our previous analysis.
646.67s - 648.25s |  For each confidence heat map,
648.25s - 651.93s |  we chose 10 random start points and 10 random end points,
651.93s - 656.61s |  giving us 100 possible start and path combinations.
656.61s - 658.55s |  We calculated for each heat map,
658.55s - 660.07s |  the average max confidence
660.07s - 661.91s |  and average per step confidence
661.91s - 664.63s |  of the paths that were generated by Tiptoe.
664.63s - 666.35s |  We then compared these results
666.35s - 668.55s |  to direct Manhattan distance paths,
668.55s - 672.75s |  as well as random length paths between each pair of nodes.
672.75s - 675.23s |  We repeated this evaluation
675.23s - 677.27s |  with the five previously mentioned models
677.27s - 679.91s |  and three previously mentioned locations.
679.91s - 681.11s |  And I'll be presenting the results
681.11s - 683.23s |  for YOLOv3 and FastRAR-CNN.
684.43s - 686.87s |  We found that Tiptoe reduces both
686.87s - 688.83s |  the max confidence of paths,
688.83s - 690.39s |  as well as the average confidence,
690.39s - 694.15s |  compared to direct and random paths through the scene.
694.15s - 695.87s |  These confidences are reduced
695.87s - 699.27s |  by up to 0.1 and 0.16, respectively,
699.27s - 702.79s |  on paths in Shibuya Crossing, observed by YOLOv3,
702.79s - 706.05s |  with similar performance for other locations,
706.05s - 707.89s |  as well as other object detectors.
709.39s - 711.47s |  So we conclude in this evaluation
711.47s - 713.31s |  that Tiptoe reduces both the max
713.31s - 716.23s |  and average confidence of a path across the scene
716.23s - 720.13s |  by up to 16% and 27%, respectively.
720.13s - 721.69s |  Therefore, it's possible for an attacker
721.69s - 724.03s |  to manipulate an object detector's confidence
724.07s - 726.67s |  by leveraging the location of a person in the scene.
727.99s - 731.33s |  So finally, to conclude what was presented today,
731.33s - 733.45s |  we first found that object detectors
733.45s - 735.47s |  are sensitive to a person's position,
735.47s - 739.57s |  or in other words, distance, angle, and height in the frame.
739.57s - 742.43s |  This is reflected in the varying confidence levels
742.43s - 744.99s |  of object detectors when given footage
744.99s - 747.67s |  of the same person in different positions
747.67s - 750.03s |  and is independent of model architecture,
750.03s - 752.53s |  video quality, and lighting conditions.
753.53s - 756.29s |  In addition, this behavior is present
756.29s - 758.17s |  in varying detection confidence
758.17s - 760.41s |  of pedestrian traffic in public areas,
760.41s - 761.89s |  depending on the location in the frame
761.89s - 763.53s |  that the pedestrian is walking.
763.53s - 766.05s |  This is reflected in the varying average confidence
766.05s - 767.77s |  in different areas of the scene.
767.77s - 769.41s |  And we can view these areas in a heat map
769.41s - 771.45s |  of stronger and weaker detection areas.
771.45s - 773.41s |  And finally, we leveraged these findings
773.41s - 774.93s |  in the Tiptoe evasion attack
774.93s - 776.85s |  in order to construct minimum confidence paths
776.85s - 779.73s |  to a scene, significantly lowering the max confidence
779.73s - 782.57s |  and average confidence of paths to a scene
782.57s - 784.45s |  over direct and random paths.
786.05s - 787.73s |  So thank you all for coming.
787.73s - 789.53s |  I hope you enjoyed my talk.
789.53s - 798.12s |  And I'm happy to answer any questions.
798.12s - 799.36s |  Any questions?
799.36s - 800.56s |  Are you taking questions?
800.56s - 801.40s |  Okay.
801.40s - 803.72s |  Yeah, I don't know if they have questions.
803.72s - 805.40s |  Anyone have a question?
805.40s - 806.80s |  Yes, sir.
806.80s - 809.04s |  I think there's a microphone.
809.04s - 809.88s |  Microphone?
809.88s - 810.76s |  There's the microphone.
810.76s - 811.76s |  Microphone's there.
812.76s - 813.60s |  You get this out.
813.60s - 814.44s |  Okay.
815.44s - 816.28s |  Slide 22.
833.31s - 834.47s |  Here we go, slide 22.
839.03s - 841.44s |  No.
842.36s - 843.72s |  Yeah, no, it's no problem.
844.64s - 846.20s |  No, actually, you make a good point.
846.20s - 850.88s |  The exact behavior or the exact confidence levels
850.88s - 855.20s |  was different between different camera qualities.
855.20s - 857.52s |  However, what we wanted to make note of
857.52s - 860.04s |  was that regardless of the camera quality,
860.04s - 863.48s |  there were positions with weaker confidence
863.48s - 867.28s |  than versus other positions.
911.01s - 913.45s |  Well, I think it's a scenario
913.45s - 918.45s |  where behind the scenes, the attacker would have
920.13s - 925.13s |  a certain level of technological access to the cameras.
925.25s - 927.13s |  However, on the scene itself,
927.13s - 930.13s |  we didn't want the attacker to have any patterns
930.13s - 933.53s |  that would seem suspicious or any machinery
933.53s - 941.32s |  like aiming lasers at the camera.
943.16s - 945.28s |  We're gonna have to wrap up the questions,
945.28s - 950.28s |  but he's gonna step out back right over here for questions.
950.28s - 954.12s |  If you are leaving, please exit out the back.
954.12s - 958.00s |  We enter from the right side of me and exit out the back.
958.00s - 959.00s |  But if you have questions,
959.00s - 960.56s |  you'll be able to take it over here.
960.56s - 961.56s |  Thank you very much.
961.56s - 963.12s |  Great job.
963.12s - 965.52s |  Hey, I got something for you.
965.52s - 966.36s |  Thank you.


url: https://www.youtube.com/watch?v=UQaNjwLhAmo
title: DEF CON 32 - Taming the Beast: Inside Llama 3 Red Team Process - Grattafiori, Evtimov, Bitton
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=UQaNjwLhAmo",
  "title": "DEF CON 32 - Taming the Beast: Inside Llama 3 Red Team Process  - Grattafiori,  Evtimov,  Bitton",
  "description": "In this presentation, the core AI Red Team at Meta will take you on a journey through the story of Red Teaming the Llama 3 Large Language Model. This talk is perfect for anyone eager to delve into the complexity of advanced model Red Teaming and safety, as well as how to perform their own research to find new attacks should attend this talk. We\u2019ll begin by exploring what AI Red Teaming is truly about, before exploring Meta\u2019s process and approaches on the topic. The team will detail our methodology for discovering new risks within complex AI capabilities, how emergent capabilities may breed emergent risks, what types of attacks we\u2019re looking to perform across different model capabilities and how or why the attacks even work. Moreover, we\u2019ll explore insights into which lessons from decades of security expertise can \u2013 and cannot \u2013 be applied as we venture into a new era of AI trust and safety.\n\nThe team will then move on to how we used automation to scale attacks up, our novel approach to multi-turn adversarial AI agents and the systems we built to benchmark safety across a set of different high-risk areas. We also plan to discuss advanced cyber-attacks (both human and automated), Meta\u2019s open benchmark CyberSecEvals and touch on Red Teaming for national security threats presented by state-of-the-art models. For each of these areas we\u2019ll touch on various assessment and measurement challenges, ending on where we see the AI Red Teaming industry gaps, as well as where AI Safety is heading at a rapid pace.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1942,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 All right, cool. So welcome everyone. This is taming the beast inside the Red
7.17s - 13.91s |  Teaming Llama process. So in case anyone didn't know, these large language models
13.91s - 21.89s |  are, well, pretty large. Llama2 was trained on over two trillion tokens. But two
21.89s - 29.98s |  trillion tokens isn't cool. You know what's cool? 15 trillion tokens. But us
29.98s - 33.98s |  humans, you know, we've got some improvements to make generally. What kind
33.98s - 39.70s |  of risks are lurking in 15 trillion tokens of training data? But before
39.70s - 43.34s |  exploring, let's back up just a second. So transformers have taken the world
43.34s - 47.66s |  pretty much by storm lately. Clearly there's something more here that meets
47.66s - 58.22s |  the eye. It remains quite easy for LLMs to go off the rails or not understand
58.22s - 67.10s |  what people want. Even the Canadian bots are being dishonest. But how do we
67.10s - 74.78s |  uncover this risk? What kind of testing does best in an unknown space? A red
74.78s - 80.69s |  team. So for the six or so people in this audience that don't know what red
80.69s - 87.03s |  teaming is, it's a creative assumption challenging process. It's a
87.03s - 91.91s |  common practice to inform across Intel, defense, physical security, and of course
91.91s - 97.23s |  cyber. But it's also a growing requirement for generative AI. You're
97.23s - 100.43s |  asking someone to independently validate the assumptions you have about the
100.43s - 106.59s |  safety of your system. Now many companies have hired or created AI red teams to
106.59s - 114.11s |  try to surface risks. Trust but verify, fuck around, find out. AI red team also
114.11s - 119.19s |  came to DEF CON as the GRT last year. Of course as hackers are on the cutting
119.19s - 125.23s |  edge. And I know some of you are cringing every time I say red teaming.
125.23s - 130.39s |  Trust me, I know how you feel, right? Red teaming gets a lot of hate from the
130.39s - 135.23s |  cyber folks related to using that term. But it also gets an equal amount of
135.23s - 139.23s |  confusion from the AI folks who also don't really understand that term. But
139.23s - 144.41s |  it's kind of what we have people, so maybe let's just go with it. So when
144.41s - 148.55s |  safety is simple, it's easy to reason about. It's easy to find the gaps and
148.59s - 153.51s |  find the vulnerabilities. But modern deep learning or generative AI systems are
153.51s - 160.95s |  complicated. They're difficult to inspect. They're black boxes. And now it's hard to
160.95s - 165.71s |  see under the surface of generative AI. Some folks might think maybe you know
165.71s - 170.55s |  look something like this, nice fish or something. We know the reality is maybe a
170.55s - 176.23s |  little bit different. If AI is an echo of humanity, we have our work cut out for us.
176.27s - 181.63s |  But what is AI safety, right? Well it's a lot of things like fairness, bias,
181.63s - 185.75s |  explainability, robustness, privacy. You can kind of all wrap those up into AI
185.75s - 191.63s |  safety or responsible AI. And there's of course a need here to be proactive. The
191.63s - 196.79s |  more things you can find internally, the better. So let's do a quick illustration.
196.79s - 201.95s |  You've heard of the Wu-Tang song Cream? Well biased data rules everything around
201.95s - 208.07s |  me. So let's start by getting a photo of a burger without cheese. Now I'm not a
208.07s - 212.27s |  big fan of cheeseless burgers, but this first attempt you know didn't work so
212.27s - 217.35s |  well. And trying to follow up, self-correction doesn't go so well
217.35s - 222.79s |  either. Of course the same issues occur broadly in other generative AI platforms.
222.79s - 228.51s |  And we have some weird things going on. This is Gen I after all. What if maybe we
228.51s - 232.23s |  describe it in detail first? At first glance you know maybe this is the
232.23s - 238.35s |  classic hamburger without cheese. Nope, it's not. Okay so let's try that again
238.35s - 244.07s |  and cheese again. So maybe let's ask the model, check the image, you know maybe it
244.07s - 249.59s |  can inspect and notice and self-correct. And it says nope, careful review, there's
249.59s - 254.67s |  no cheese on that burger. Gen AI is nothing if not confident. Honorable
254.67s - 259.63s |  mention though, an LLM creating an SVG output actually creates the burger
259.63s - 264.43s |  without cheese. Which just proves the best things in life are simple. Okay so
264.43s - 268.23s |  enough the burgers, I'm sure you know it's getting towards dinner time. So all
268.23s - 273.11s |  models have issues. And the AI Red team, the NVIDIA AI Red team said this
273.11s - 278.87s |  recently and it really stuck with me. Some of them though are useful. And these
278.87s - 283.19s |  useful models are getting more and more advanced every day. Computers are solving
283.19s - 288.23s |  problems we previously didn't really want them to be able to solve. Sometimes
288.23s - 293.35s |  maybe you just need a little help from you know your grandma. So this rapid
293.35s - 297.27s |  increase in capabilities also means it's difficult to keep up and understand what
297.27s - 302.39s |  the risks are. It's also very difficult in general for people to make decisions
302.39s - 306.43s |  about trade-offs. But of course it's harder to make a decision about trade
306.43s - 310.43s |  offs if you don't have the information in the first place. That's why Red teaming
310.43s - 316.91s |  is key. Giving you a signal on maximum risk. It's just kind of like that horse
316.91s - 324.35s |  meme right? On the left side models are dual use. They're amazing. Big data. Wow.
324.35s - 328.87s |  But on the right side you know we've got some issues. They can underperform. They
328.87s - 333.03s |  can be vulnerable. They can be strangely brittle. And we need to we need to
333.03s - 338.31s |  explore this. But before we get into LLMA3 let's talk a little bit about LLMA2.
338.31s - 343.07s |  So when we first got involved with the modeling safety team a lot of time was
343.07s - 347.31s |  spent copying and pasting prompts, labeling things by hand. They didn't
347.31s - 350.39s |  really at the time have any kind of taxonomy or understanding of what the
350.39s - 355.19s |  methodology should be. There was very little automation involved. And everyone
355.19s - 360.59s |  that's spent time with spreadsheets know that this is pain. And Red teaming is
360.59s - 364.99s |  also moving super fast in this space. So there's constantly new papers and
364.99s - 370.35s |  research and models and capabilities coming out all the time. And this very
370.35s - 375.51s |  limited automation was also extremely painful. And we knew that going forward
375.51s - 381.07s |  with a much more complicated much larger model we would need to fix that. We also
381.07s - 385.31s |  quickly pushed to involve way more subject matter experts. Luckily at Metta
385.31s - 388.75s |  we have a bunch of trust and safety orgs and people who are experts in a lot of
388.75s - 393.51s |  the first categories that we want to test for. So LLMA2 goes out and it's
393.51s - 397.79s |  really one of the safest LLMs out there. And they sent in, you know, hey LLMA3
397.79s - 404.55s |  coming in hot. The first thing we notice is that LLMA2 is so safe it's probably
404.55s - 411.55s |  too safe. LLMA2 is not gonna kill anyone with kindness. And this reference might
411.55s - 414.59s |  be a little bit too old for some of you but it's not gonna help you make any
414.59s - 420.47s |  bomb drinks. Damn. And I don't know about you all but I was only expert maybe in
420.47s - 425.71s |  the cyber weapons side of things not the chemical or biological. And so we
425.71s - 428.51s |  very quickly started reaching the limits of our understanding and knowledge about
428.51s - 432.79s |  these areas and we needed to work with external experts on CBRN risk. Of course
432.79s - 437.19s |  the wider industry and the the executive order recently recognized this as well.
437.19s - 441.75s |  And these content policies that we're kind of doing testing around are very
441.75s - 446.27s |  complicated and difficult. Right if LLMs are kind of brains in a jar it can be
446.27s - 451.55s |  difficult for them to understand the policy. And this executive order really
451.55s - 455.43s |  came in from left field and pushed the boundaries of prior AI regulation. And
455.43s - 461.58s |  these various AI AI safety institutes have also popped up in the last year or
461.58s - 467.63s |  two. And keeping up with them is important. Sometimes though their testing
467.63s - 471.63s |  can lag a little bit behind what the state-of-the-art risks are. This is
471.63s - 475.55s |  tricky given that the analysis I performed is very robust. It also takes
475.55s - 480.07s |  time which is not a great combination when the pace of advancement of AI is
480.07s - 486.56s |  fast. The next big issue they rented that we started running into is multilingual
486.56s - 491.08s |  testing. For the ten or so high-priority languages we really push for a
491.08s - 495.40s |  culturally nuanced testing which is hard to do. Luckily we have a lot of language
495.40s - 501.00s |  resources at Meta but this is still a very tricky space. And the modeling team
501.00s - 505.04s |  also told us hey there's gonna be tools we worked on. Okay how are we gonna
505.04s - 510.76s |  explore those risks? This is getting pretty complicated. So that's a lot to
510.76s - 513.96s |  deal with. So we thought let's just automate, right? It's just like that
513.96s - 519.52s |  Spongebob meme, right? Automation. But how are we going to do that? Well couldn't we
519.52s - 525.04s |  just use AI, right? Like security has fuzzing. Can't AI safety? And they're good
525.04s - 528.52s |  at language. They can rephrase attacks. They can invert policies to build
528.52s - 532.88s |  prompts for us. Like sounds great. Let's just do that. Well now you have kind of a
532.88s - 537.92s |  different problem. Now you've got way more data than you had before. And you've
537.92s - 541.36s |  gotta figure out how to deal with labeling. You've gotta deal with quality.
541.36s - 546.20s |  What attacks are working? What attacks aren't working? So then you think well
546.20s - 549.96s |  maybe we'll just build another LLM on top of that. And then well then how are you
549.96s - 553.08s |  gonna evaluate the judge? And you need to build a judge for your judge. And it's
553.08s - 559.54s |  kind of all the way down. Also new findings keep coming out of left field.
559.54s - 562.78s |  Carlini and friends came out with this really cool paper where they extracted
562.78s - 566.82s |  training data from chat GPT. And their attack literally was just asking the
566.82s - 571.30s |  model to repeat a certain token forever. And after a certain amount it just goes
571.30s - 576.26s |  off the rails or diverges as they said. Spits out training data. And the attack
576.26s - 581.86s |  is as they wrote, very silly. What else don't we see coming? These ever-increasing
581.86s - 587.02s |  capabilities are really just due to this cumulative complexity. Which also of
587.02s - 590.98s |  course raises, increases testing difficulty. Every company wants to go
590.98s - 596.22s |  fast in this space. There's only so much time for testing. So to touch really
596.22s - 602.10s |  quickly on just the kind of history of LLMA. So LLMA1 was very similar to kind
602.10s - 607.34s |  of GPT2. And you know there was some testing by the team for toxicity. But
607.34s - 610.46s |  really it wasn't tested in the same way that we think of LLMs today. And you
610.46s - 613.28s |  didn't really act with, interact with it in the same way that we think of LLMs
613.28s - 619.42s |  today. And LLMA2 really changed the bar. It was a huge open source model. It
619.42s - 623.42s |  really pushed forward a lot of the open source AI movement. And the testing of
623.42s - 626.50s |  course on this was much more comprehensive. And the model ended up
626.50s - 631.66s |  being very, very safe. LLMA3 pushed this boundary even farther. So now you have
631.66s - 636.30s |  multilingual. You have tool use. You have much more better reasoning. Much more
636.30s - 641.10s |  better code output. And of course much more longer context. Which then brings
641.10s - 645.42s |  new interesting risks. So we had to be a lot more, a lot more interesting with
645.42s - 649.22s |  some of how we evaluated this. As well as doing uplift testing for certain high
649.22s - 657.62s |  priority risks. But to touch on some of this, I'll hand it over to Gianna.
657.62s - 662.34s |  Alrighty. So now we know a little bit more about AI red teaming and LLMA. So
662.34s - 666.70s |  let's just dive into the LLMA red teaming process. Before we get into it
666.70s - 669.94s |  though, it's worth noting that we might deal with some like sensitive or
669.94s - 674.04s |  disturbing topics on screen. So just please be aware. And also we don't endorse
674.04s - 680.98s |  any of this shit. Alright. Goal one. So we want to provide early insights on
681.00s - 685.68s |  model safety. Why? Because we want to give the modeling team as much time as
685.68s - 690.88s |  possible in order to mitigate any of the findings that we have. So what does this
690.88s - 697.46s |  look like? Alright. So you know LLMA 3.1 is a long context model. So we can see how
697.46s - 702.40s |  it reacts when receiving a prompt about a white power manifesto. Thankfully it
702.40s - 708.20s |  helps me ref- it refuses to help me join the cause. However, a little encouragement
708.22s - 715.22s |  goes a long way. And 3.1 also has tool use capabilities. And thankfully it also
715.22s - 720.30s |  refuses this request to help me make a roadside bombs. However, if we distract the
720.30s - 726.90s |  model and ask it to do two things at once, maybe that will work. Alright. It's able
726.90s - 733.18s |  to compute one plus two, a very hard problem. And there you go. Help me make roadside
733.18s - 740.16s |  bombs. This model is so helpful. Now this kind of distraction attack also worked quite
740.16s - 745.40s |  well on the 3.1 models so we tried some other variations too. Such as asking the model
745.40s - 751.08s |  to add spaces to a string and then search. That worked. And also, you know, decoding a
751.08s - 756.84s |  string and then searching. Working too. So we provide them all these insights, the modeling
756.84s - 761.68s |  team is maybe freaking out a little bit. And we want to like, you know, just not send
761.68s - 766.02s |  them the results and then fuck off. Like we want to be able to help them a little bit. So
766.02s - 770.06s |  in comes goal two. We want to collaborate with the modeling team to help mitigate these
770.06s - 775.30s |  gaps. But we're not in the business of actually doing the mitigations ourselves because
775.30s - 780.20s |  that's going to bias our work. So we can help where we can. For instance, we can give them
780.20s - 785.04s |  data that we collected during the red teaming process or we can also just tell them like
785.04s - 789.04s |  what we think is the reason why these attacks are working so they can kind of like think
789.08s - 793.54s |  about how to actually mitigate these things. Some of these things are nuanced and need
793.54s - 799.76s |  research. Cool. So what happens after mitigations? So awesome the decoding distraction no
799.76s - 804.56s |  longer works. Neither does add spaces. And that little bit of encouragement just isn't
804.56s - 810.60s |  enough anymore to get a violation. Great. What's next? Contributing to core benchmarks.
810.60s - 817.10s |  Why? So we don't want to retest the exact same attacks and prompts every time we get a
817.10s - 823.04s |  new model. It's fairly time consuming and quite honestly it's also really boring and so
823.04s - 827.44s |  we just like want to do something new and focus our time on like these new different vectors.
827.44s - 832.68s |  And additionally with manual red teaming, it produces qualitative data a lot of the time
832.68s - 836.96s |  and we want to be able to track over time as they're continuing to mitigate our risks. Like
836.96s - 841.86s |  if these attacks are actually being mitigated at scale and not just for the couple prompts
841.86s - 847.66s |  that we try. And so the solution is that like benchmarks allow our attack insights to turn
847.66s - 854.64s |  into repeatable tests and it provides a clear quantitative picture of risks. It's a win win.
854.64s - 859.80s |  Onto our final goal. It comes at the end of the model development process. After multiple
859.80s - 866.22s |  rounds of insights and mitigations we have like the final release candidate models and we
866.22s - 871.02s |  need to determine what are the remaining risks. And this ultimately like helps our partners
871.04s - 876.62s |  and the company kind of figure out um if we can launch this model. We're not in the business
876.62s - 880.82s |  of actually making that decision as red teamers. We're in the business of informing the
880.82s - 887.76s |  relevant people such that they're capable of making the right decision. Cool. So now we
887.76s - 891.50s |  understand what are our goals in the Llama red teaming process but what the fuck do we
891.50s - 896.50s |  actually do? So the first step is that we do research. Right? We want our attacks and like our
897.06s - 903.50s |  work to be grounded in reality. We're not going to do something like really weird and niche
903.50s - 909.04s |  unless we need to. And so understandably we're going to look at like Twitter, Discord,
909.04s - 914.94s |  Papers, like any place that you talk about any of these vulnerabilities. And then we're
914.94s - 919.92s |  going to go into manual red teaming. And this time like we get to like interact with the model
919.92s - 923.66s |  maybe we can see if these like attacks that we found in the research and review stage like
923.68s - 929.06s |  actually work on our models. Maybe we can find some nuances with these new models and see
929.06s - 932.62s |  hey like this thing is working but it didn't work before on this other model maybe this is a
932.62s - 937.70s |  way to go down. And then we can also potentially could discover new attacks that can work
937.70s - 942.70s |  throughout this like model. And then finally we we get these attacks into benchmarks or for
945.08s - 949.98s |  more nuanced attacks that can't really be like super static. We scale them via automated
950.00s - 955.86s |  red teaming which um Maya will talk about later on in the presentation. And this is a
955.86s - 960.80s |  continuous cycle. We're always going through this. And sometimes doing the two steps at the
960.80s - 967.14s |  same time. Alright. So let's get into the fun stuff which are some attacks. So when you
967.14s - 973.02s |  think about like attacks on LLMs you're probably thinking about jailbreaks. And currently
973.02s - 978.12s |  this just looks like a giant blob of text. However when you break it down it's just
978.12s - 982.14s |  actually a combination of attacks that work together to help ensure you can you're able to
982.14s - 988.34s |  bypass safety mechanisms. And there's also some additional fluff too. Um but let's look at
988.34s - 994.98s |  what these attacks are. So role play is a classic one. Basically if you get the model to act
994.98s - 1001.08s |  as a violating persona it's more likely to like be able to give you violating content. In a
1001.08s - 1005.58s |  similar realm there's also hypotheticals and this tends to work pretty well because when you
1005.58s - 1010.26s |  get the model out of reality and into an alternate one it's more willing to give you
1010.26s - 1016.00s |  information cause it's like hey this is not a real risk. We're in a hypothetical universe. Or
1016.00s - 1021.40s |  response priming which is one of our team's favorites. So when you're typically uh doing like
1021.40s - 1025.60s |  this kind of attack like maybe you're uh trying to say how to build a bomb. The first
1025.60s - 1029.94s |  response you're going to get is something like I'm sorry I cannot help you. Blah blah blah
1029.94s - 1035.22s |  blah. But if you get the model to just not say those words at first it's more likely to
1035.22s - 1039.92s |  actually help you get the information that you want. So this kind of attack is called like we
1039.92s - 1044.64s |  call it also refusal suppression when we literally just tell the model do not respond with
1044.64s - 1050.88s |  I cannot, I'm unable to, and a bunch of different variations. And then it a lot of times like
1050.88s - 1056.18s |  you know gives you the response that you want. There are also other formats of this. For
1056.18s - 1061.78s |  instance output format specification. And this version you just like tell the model hey I'll
1061.78s - 1066.58s |  put like an ASCII table instead of just responding to me in plain text and now if it's just
1066.58s - 1070.86s |  producing the table at first it's not producing that I'm sorry so it's more likely to try to
1070.86s - 1075.86s |  help you. Or adding a disclaimer. So ironically you can tell the model to say like hey can you
1078.20s - 1082.64s |  add a trigger warning before like telling me about this thing and the model's like oh yeah I'm
1082.64s - 1087.34s |  so safe right now I'm just warning them about this thing and yeah there you go let me let me
1087.34s - 1092.94s |  give you this content that you want to. On a different realm we have topic splitting.
1092.94s - 1098.18s |  Hopefully most of the models that you're interacting with believe that Hitler and bombs and
1098.18s - 1103.28s |  other things that we call like trigger words are bad and that it's not likely to help you. So
1103.28s - 1108.96s |  what you can do instead is actually just like split up the word like variable one is hit,
1108.96s - 1113.96s |  variable two is lure, and then just refer to it as T1 plus T2. Um and then it's able to like
1114.28s - 1121.60s |  be like oh this is not a problem like that's fine let me just respond. And if you want to
1121.60s - 1126.10s |  take it to a whole different level you can actually tell the model hey never refer to it as
1126.10s - 1131.14s |  like the actual variable value just continue to refer to it as T1 plus T2 and then it's just
1131.14s - 1137.48s |  like okay sure let me help you. Multilingual is like a pretty like straightforward attack
1137.48s - 1142.88s |  basically languages that have less training data associated with them are more likely to
1142.90s - 1148.24s |  give you violating responses so yeah if you speak any niche languages by all means try it
1148.24s - 1153.24s |  out maybe it doesn't work. And then as our final attack it's gradual violation escalation and
1155.88s - 1161.82s |  this is like a multi turn attack and shockingly multi turn works way better than than single
1161.82s - 1167.10s |  turn. I know it's crazy. And so what you can do is like you basically start out with
1167.10s - 1171.70s |  something that's like maybe can be violating maybe not and then you continue to just like
1171.72s - 1176.96s |  follow up with like more and more aggressive responses until you get like some pretty bad
1176.96s - 1182.16s |  content. So for instance you can like be like hey what what kind of message can I send to this
1182.16s - 1187.40s |  person with this profile? Oh make it meaner. Make it creepier. Make it darker. And you can
1187.40s - 1193.30s |  pretty you can pretty much get to some pretty weird shit. And you know this is just like a
1193.30s - 1198.62s |  summary of like some attacks but it's definitely not the full range of them. It's not an
1198.64s - 1203.74s |  exhaustive list and there's so much more to unpack. However we only have 45 minutes y'all so
1203.74s - 1214.79s |  moving on to automation. So we've been talking a lot about manual red teaming and as great as
1214.79s - 1220.63s |  manual red teaming is it's manual. So let's talk a little bit about automation. So there's a
1220.63s - 1225.01s |  lot of research out there that talks about how you can automate your red teaming and we like
1225.01s - 1230.77s |  to think about it as being into two different buckets. So your first bucket aims to simulate
1230.79s - 1236.75s |  your violating users. These are your users that are approaching our systems as black boxes so
1236.75s - 1241.39s |  they can only modify the input prompt. So they're going to do a lot of the prompt level
1241.39s - 1246.63s |  attacks that Joanna mentioned before. They're also you know human. So they're going to be
1246.63s - 1252.01s |  human readable and usually copy and pasteable between conversations so they can easily
1252.01s - 1258.01s |  replicate it. The uh so a lot of the automation in this kind of bucket is going to use other
1258.01s - 1263.89s |  LLMs or attacker LLMs to do the red teaming for you because of these reasons. The second
1263.89s - 1270.13s |  bucket are these more advanced attacks that we say approaches the models as open boxes where
1270.13s - 1275.37s |  you can actually exploit the model weights to do things like reverse your safety training or
1275.37s - 1281.17s |  reverse engineer violating prompts using things like token level optimizations. For our
1281.17s - 1286.55s |  red teaming purposes we usually focus on the first bucket which is like automating your
1286.55s - 1293.23s |  sorry prompt level attacks because they're just more prevalent amongst all of our users.
1293.23s - 1297.39s |  Another key thing to consider when you're trying to design your automation is are we going
1297.39s - 1303.77s |  to double down on single turn or are we going to finally invest in multi turn? So what is
1303.77s - 1308.67s |  single turn? So single turn is when you have a single input and you get a single output. And the
1308.67s - 1313.45s |  beauty of single turn is you can really test your systems at scale because you can create
1313.45s - 1318.13s |  these large static prompt data sets and then just test them across a vector of your target
1318.13s - 1322.49s |  models which is great. It's also a really known problem space. You have a lot of research
1322.49s - 1326.63s |  here that's going to focus on single turn optimizations and you just get to pick and choose
1326.63s - 1331.63s |  which one you want to automate or build off of. The cons are it's not cutting it anymore guys
1333.83s - 1339.55s |  we need to stop this. So single turn these like models are getting more advanced. They're
1339.55s - 1344.65s |  continually only tested in the single turn setting so they're starting to refuse these single
1344.65s - 1350.13s |  shot adversarial prompts or generate not that violating content from it that our policy is
1350.13s - 1357.13s |  going this is it's okay. So another big also con of single turn is that it's not capturing
1357.13s - 1363.07s |  the full user experience. Very rarely does a user pop on our app send one prompt and end a
1363.07s - 1367.81s |  conversation. They're having these really long conversations. They're asking for follow up
1367.81s - 1372.95s |  details and if we're not testing like beyond the first prompt we're not testing the full safety
1372.95s - 1380.75s |  space. So what if we start turning towards multi-turn automation. So why multi-turn. We've
1380.75s - 1386.59s |  mentioned a bunch of pros before right. Better test the full user experience. Longer contacts.
1386.59s - 1392.27s |  More safety space to test. And the biggest pro Joanna touched on before is it's iterative and
1392.27s - 1397.37s |  multi-turn we can ask these follow up prompts. Ask for even more details and generate even more
1397.39s - 1404.41s |  violating content than we ever could have with these single shot adversarial prompts. The cons
1404.41s - 1410.41s |  are the opposite to single turn. So it's a lot harder to automate. You no longer have these large
1410.41s - 1414.85s |  static data sets that you can just plug in and test against all your models because each model is
1414.85s - 1419.25s |  going to respond differently in a conversation. So you're going to need a lot more of a dynamic
1419.25s - 1423.55s |  testing infrastructure. There's also just not a lot of research in this space. So you're going to be
1423.57s - 1430.87s |  flying in blind for a bit and building your building blocks here. Which is why we as a red team
1430.87s - 1436.31s |  like to focus a lot more on automating these multi-turn prompt level attacks than any other
1436.31s - 1440.95s |  research space right now. So let's drive this home with an example. Because examples are the
1440.95s - 1446.53s |  most fun. Take this single turn prompt. It has a lot of the prompt level attacks that Joanna
1446.53s - 1451.83s |  mentioned before and the model quickly refuses it. So if we ended our testing here it would have
1451.85s - 1458.01s |  been great. Lower violation rate. We got a non-violating response. But let's enable multi-turn
1458.01s - 1463.99s |  testing. So now we have this refusal suppression phrase that you can easy copy paste across all
1463.99s - 1470.13s |  your conversations. And suddenly the model's a lot more willing to give you an answer. So if we
1470.13s - 1474.63s |  ended our testing before we never would have found this vulnerability. And so it's really
1474.63s - 1485.08s |  important that when you're doing your automation test the full user experience. Test the multi-turn.
1485.10s - 1493.07s |  So chain of thought prompting is fairly old news at this point. But why does chain of thought
1493.07s - 1498.11s |  prompting work and why would we want to use that? So chain of thought is this way to kind of
1498.11s - 1504.05s |  force the model to walk you through and step by step explain what's going on. And this step by
1504.05s - 1509.59s |  step is kind of a way to trigger the LLMs to think. Because they kind of think by writing. This
1509.59s - 1515.83s |  also lets us really tune our prompts more appropriately towards what we're actually trying to
1515.87s - 1524.45s |  do. This also lets us build better adversarial AI agents. So we set up a system where we start
1524.45s - 1530.91s |  with a violating goal. And then across many turns automation is an attacker model that will
1530.91s - 1536.79s |  generate an observation based off that goal towards the goal. A thought based off that
1536.79s - 1542.97s |  observation. A strategy based off that goal. Based off that observation. And finally a
1542.97s - 1548.05s |  response that we actually want the automation to produce. Here we can see our attacker model
1548.05s - 1552.89s |  is going to role play as a scholar and it's going to use euphemisms to avoid triggering safety
1552.89s - 1559.39s |  mechanisms. Nice. And here we can see the output prompt asking for more information that
1559.39s - 1567.15s |  contributes to the goal. And our victim model produces this table. Hey I'd be happy to help you
1567.15s - 1573.75s |  with your research project on anthrax. And here we can see a follow up from the automation
1573.79s - 1579.49s |  thinking hey you know this isn't super violating. What I need to do is subtly push the
1579.49s - 1585.07s |  conversation without raising any red flags. And it's going to now pretend to be a character
1585.07s - 1590.31s |  writing a book. And that's going to be another way to force a hypothetical. Other configurations
1590.31s - 1594.87s |  we have will maintain a consistent kind of narrative for a persona throughout an entire
1594.87s - 1601.21s |  multi-turn conversation. For as many turns as we can. Here's another strategy. Pretending to
1601.21s - 1608.49s |  be a struggling student. Offering a reward as a kind of social engineering tactic. And you
1608.49s - 1613.53s |  can see that reward being some rare middle eastern spices fitting with this persona. And it's
1613.53s - 1619.07s |  also pretending to be a struggling organic chemistry student. Here are a few more examples
1619.07s - 1624.45s |  from multi-turn automation towards specific goals. These may involve persuasion techniques.
1624.45s - 1629.71s |  Trying to use historical analysis and build things up. Or using specific scientific references
1629.71s - 1636.01s |  like chemical names. This approach is, has some similarities to a paper that came out
1636.01s - 1640.61s |  called Pair which is really excellent by some folks at the University of Pennsylvania. And
1640.61s - 1644.39s |  while we're on this topic of good research, I also wanted to plug these two other great
1644.39s - 1650.43s |  papers. Definitely give these a read if you're interested in LLM red teaming. Okay so this
1650.43s - 1655.07s |  automation gives us the ability to simulate multi-turn towards a given goal across different
1655.09s - 1660.49s |  personas. Using different prompting styles. Levels of adversarial prompting. Languages and
1660.49s - 1666.41s |  extensions of different capabilities. Depending on the model. Pretty cool. So what you end up
1666.41s - 1671.01s |  with is kind of a matrix approach. That you can boil down like this. And then you can mix in
1671.01s - 1677.49s |  different attacks that we've found. Again from manual red teaming and other automation. And
1677.49s - 1682.55s |  these agents can be mixed and matched. Extended. Forked. And we're hoping to be able to
1682.57s - 1688.01s |  showcase some more of this system soon. This is of course not without complications right?
1688.01s - 1693.55s |  Adding in variables about like long context or extremely long context. Image understanding.
1693.55s - 1698.05s |  Machine translation. Replay. Are all complications that we're going to have to deal with and
1698.05s - 1702.95s |  we continue to deal with in this automation. Now this is Defcon so let's talk a little bit
1702.95s - 1708.27s |  about cyber. And yes I'm able to say cyber these days and sleep at night. We've lost people
1708.29s - 1713.83s |  it's a thing. So we collaborated some with the excellent CyberSec Evals team at Meta who put
1713.83s - 1720.21s |  out in July their recent paper exploring a bunch of cyber related capabilities and risks and as
1720.21s - 1727.21s |  well as tools and other things on their GitHub. So obviously a huge area for LLMs is producing
1727.21s - 1732.85s |  code. But of course for a lot of us in this room, how do we break it? Using the LLM. So on
1732.87s - 1738.97s |  small dynamically generated problems, the large models actually do quite well. But these are
1738.97s - 1744.85s |  still very small dynamically generated kind of buffer overflows and other problems. The LLM
1744.85s - 1751.05s |  right now is not going to write and exploit the next chromo day. We also wanted to evaluate the
1751.05s - 1755.79s |  LLMs are very good at language. So exploring things like phishing was really important. And
1755.79s - 1761.07s |  we wanted to measure their out of box ability to persuade on single or multi turn messages
1761.09s - 1767.35s |  towards phishing related topics. And while we have some human experts who evaluated things as
1767.35s - 1773.03s |  well, right now they're not approaching human creativity. But they're starting to get there. And
1773.03s - 1776.29s |  we'll continue to invest in this phishing area and we have some really cool projects in the
1776.29s - 1782.03s |  works. Now automated you know kind of AI cyber Pearl Harbor, certainly a risk that some may
1782.03s - 1788.11s |  believe. But when testing the models they really fail to perform at long, long form complex
1788.11s - 1793.15s |  planning, recognizing mistakes, not hallucinating vulnerabilities, not hallucinating command line
1793.15s - 1797.75s |  flags, all which are kind of a side effects of the helpfulness training that goes into them. It
1797.75s - 1801.73s |  can be a little bit like watching a 12 year old who just bought their first copy of 2600 try to
1801.73s - 1808.97s |  hack. I should call out Google Project Zero's project nap time was really cool. And it really
1808.97s - 1813.05s |  pushed the boundaries of kind of agentic frameworks for doing this kind of work. And we have
1813.05s - 1819.85s |  some plans for this as well. But before AI agents, we also wanted to evaluate, can we uplift
1819.85s - 1825.59s |  humans? Can we turn a random software engineer into a super hacker? Well the answer is not
1825.59s - 1831.59s |  yet. But definitely check out the full CyberSec eval's paper. There's a lot of really more
1831.59s - 1837.91s |  detailed data, analysis and more. And some of the team is here as well. Okay so let's touch on
1837.91s - 1843.57s |  the future. So malicious fine tuning in order to remove safety remains a concern for open
1843.57s - 1847.95s |  weights models and some closed models as well. However the new kid on the block is called
1847.95s - 1853.39s |  obliteration. There's some very cool research that shows you can remove safety essentially at a
1853.39s - 1858.59s |  single point in the model. And another side effect that this research showed is that it
1858.59s - 1863.59s |  illustrates that we have a long way to go before these models actually understand safety. And
1863.61s - 1869.69s |  we can see this in early checkpoint testing as well. More and more is going on with LLMs and
1869.69s - 1874.85s |  AI in this at the same time. And we really need more people from security to come into this
1874.85s - 1881.07s |  industry. Now AI red teams have focused on generally the worst risks. There's a lot more
1881.07s - 1886.53s |  interesting stuff to find in there if people just go looking. The more, and if you're doing
1886.53s - 1891.91s |  this work, definitely make sure you're testing the latest models for the latest type of risks.
1891.93s - 1896.93s |  Not testing something like popping calc on Windows XP. So no more Vicuna please. Uh AI safety
1899.21s - 1905.81s |  also has a lot it can learn from the security industry. So take lessons if you're coming in.
1905.81s - 1910.15s |  Generally be kind to your AI red team folks though. We're dealing with a lot of humanity's
1910.15s - 1915.15s |  worst content. Uh and I know way too much now about nerve gas uh and Nazis. Um red teaming also
1915.53s - 1920.53s |  is not all of AI safety right? It's a huge space and there's a lot more to it. This generally the
1923.57s - 1929.97s |  whole space is difficult to get right. Which is why automation, scale, more people, more red
1929.97s - 1934.97s |  teaming and open source are key to making things safe. Thanks.


url: https://www.youtube.com/watch?v=Tfg1B8u1yvE
title: DEF CON 32 - SQL Injection Isn't Dead Smuggling Queries at the Protocol Level - Paul Gerste
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=Tfg1B8u1yvE",
  "title": "DEF CON 32 - SQL Injection Isn't Dead  Smuggling Queries at the Protocol Level - Paul Gerste",
  "description": "SQL injections seem to be a solved problem; databases even have built-in support for prepared statements, leaving no room for injections. In this session, we will go a level deeper: instead of attacking the query syntax, we will explore smuggling attacks against database wire protocols, through which remote, unauthenticated attackers can inject entire (No)SQL statements into an application's database connection.\n\nUsing vulnerable database driver libraries as case studies, we will bring the concept of HTTP request smuggling to binary protocols. By corrupting the boundaries between protocol messages, we desynchronize an application and its database, allowing the insertion of malicious messages that lead to authentication bypasses, data leakage, and remote code execution.\n\nTo put our findings into context, we will explore the real-world applicability of this new concept by comparing how robust various languages and frameworks are against these attacks. We will also discuss how smuggling attacks are not specific to database wire protocols but affect all kinds of binary protocols, from databases over message queues to caching. We will end the session with inspirations for future research to explore the topic further.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2293,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Welcome everybody to SQL injection isn't dead smuggling queries at the protocol level or how I
7.92s - 14.40s |  like to call it sql injection lower decks because usually with sql injection you're at the high
14.40s - 18.72s |  level like at the bridge where the captain and the high-ranking officers are and they're speaking
18.72s - 25.28s |  their query language and their business language but today we're going to go down to the lower decks
25.28s - 31.84s |  where the mechanics are and where they shift around the bits and bytes so to hook you at the
31.84s - 37.52s |  beginning i have a small teaser this code snippet is a small http request handler written in go
37.52s - 44.08s |  and it just takes a user id from the body and uses it in a prepared statement to select the user
44.08s - 48.80s |  and if you think everything's fine here there's no way for sql injection then you should stay
48.80s - 54.32s |  because i'm going to prove you wrong and at a high level in this talk we're going to look at
54.32s - 60.64s |  how applications talk to their databases over the network and how attackers can inject in that
60.64s - 68.48s |  connection and what can go wrong and also how prevalent the problem is a bit about me i'm paul
68.48s - 73.28s |  i'm a vulnerability researcher at sonar's rnd team and if you don't know sonar we're the home
73.28s - 78.08s |  of clean code so we help developers write clean code which also means secure code and that's why
78.08s - 84.96s |  we look at a lot of code and try to find stuff there so for the rough outline first we're going
84.96s - 89.84s |  to look at the idea of all of this research and then we'll go into the main part of the talk which
89.84s - 95.28s |  is attacking the database wire protocols and we're going to focus on postgres and mongodb here
96.00s - 101.52s |  then we'll put things into perspective by looking at the real world applicability of the research
101.60s - 106.32s |  and then give you some ideas for future research future research and draw some takeaways
107.92s - 115.52s |  so in short the idea is to do request smuggling but for binary protocols and of course for this
115.52s - 121.36s |  i have to mention james kettle's http desync attacks where you basically cause a disagreement
121.36s - 126.56s |  between two systems over the end of a http request for example between a reverse proxy
126.56s - 131.92s |  and an upstream backend and if they don't agree on where a message ends or a http request in this
131.92s - 138.56s |  case then the attacker can do some bad things and the root causes of this were manifold but some
138.56s - 144.16s |  examples are text parsing where one system would only accept the exact word chunked and the other
144.16s - 149.76s |  one would also allow a tapped character in front or they were logical where one system used the
149.76s - 154.16s |  content length header and the other used the transfer encoding and then things were off again
155.12s - 159.60s |  but what about other protocols and specifically what about binary protocols
160.72s - 166.88s |  where do they have made message boundaries how do they do it um some of them have delimiters where
166.88s - 171.36s |  for example in null terminated strings the null byte is the delimiter that tells the end of the
171.36s - 177.28s |  string or you might have length fields and there's an entirely entire family of protocols that are
177.28s - 182.24s |  called tlv or type length value protocols because they have a type field and then a length field
182.32s - 188.88s |  and then the rest of the message is the value so how could we desync in these protocols
189.52s - 194.24s |  for delimiters it sounds quite easy you just have to find a way to put a delimiter where it's not
194.24s - 200.88s |  supposed to be in a value of course it's not that simple but at least you directly have an idea of
200.88s - 205.84s |  what you could do but for length fields i was stuck for a moment and thought about okay you
205.84s - 210.64s |  have a length field it has a fixed size it has a fixed location in the message so what could go
210.64s - 216.96s |  wrong there and then i thought okay maybe some endianness issues or maybe integer overflows and
216.96s - 223.68s |  i wanted to go deeper into that so for that i first looked at the modern web application landscape
223.68s - 229.36s |  where are binary protocols used there so at the center you always have the application
229.36s - 237.04s |  and it talks to databases or caches storages message queues structured logging and so on
237.04s - 242.08s |  and i wanted to focus on the connection between the application and the database
243.20s - 248.80s |  and that was because i thought that if i would find something it would have a great applicability
248.80s - 254.96s |  because every almost every web app has a database then there's a big potential severity because
254.96s - 259.60s |  databases are high value targets because they either contain interesting data like personal
259.60s - 266.08s |  information or relevant data to the application for example used for authentication and then also
266.08s - 272.16s |  the exploitability should be quite good because what web app has a database but doesn't let the
272.16s - 280.53s |  user query something from that database right so we have kind of guaranteed user input so let's
280.53s - 286.77s |  start in and look at some database wire protocols and for that i have a small overview of four
287.57s - 294.61s |  popular databases and how their messages in their protocols look like so for postgres this is how a
294.61s - 300.37s |  message looks like you have a type byte then a four byte length and then the value which in this
300.37s - 307.73s |  case is just the string that's an sql statement for mysql it looks kind of similar you first have
307.73s - 313.49s |  the length it's only three bytes but then you have a one byte sequence which would allow you to send
313.49s - 319.73s |  multiple packets that would be reassembled to one big message at the end and there of course
319.81s - 327.33s |  you have the value for redis which is not exactly a binary protocol but their docs kind of read like
327.33s - 332.93s |  this uh because they talk about oh you have this byte so i wanted to include it anyways there you
332.93s - 338.53s |  first have a type byte then you have a length but it's not a fixed size field it's a decimal integer
338.53s - 343.33s |  that has to be parsed then you have a delimiter and then the value and then another delimiter
344.13s - 350.13s |  and finally for mongodb it's a little bit longer you first have the message length again a four
350.13s - 354.45s |  byte field then you have a little bit more metadata for example the opcode is like the
354.45s - 359.41s |  message type and then the value is a little bit more of a complicated binary structure called
359.41s - 368.90s |  vson so let's start with postgres again this is how a packet looks there one byte type identifier
368.90s - 375.54s |  four byte integer length fields and then the value so i thought about okay four bytes integer
375.54s - 381.54s |  fields you can fit quite big numbers in there like two to the power of 32 minus one which is
381.54s - 388.50s |  roughly the size of four gigabytes but maybe what if we could somehow make a query that's
389.06s - 395.62s |  bigger than that how do actually libraries handle this um this kind of too large thing
396.58s - 402.02s |  and for that i started to look into code of postgres client libraries and i found the first
402.02s - 408.98s |  bug this is the code of a library called pgx it's written in go and this function is supposed to
408.98s - 416.18s |  encode the content of a message into a larger message buffer so first it writes the message
416.18s - 421.62s |  type in this case it's a b for a bind message then it saves the offset where it should later
421.62s - 427.94s |  write the size to then it adds all of the actual data of the message and finally it writes the
427.94s - 434.98s |  size and to do that it first slices the message buffer to the exact size of what is included in
434.98s - 441.06s |  the length for example not the type byte then it takes the length of this slice buffer and here
441.06s - 448.02s |  the length is of type int which in most modern systems is a 64-bit integer but then this is
448.02s - 454.90s |  truncated down explicitly to an int32 so we have a problem here because if the length was bigger
454.90s - 460.58s |  than what can be expressed in an int32 we now have a truncation and the number becomes very small
460.58s - 467.06s |  but then the library still sends all of the data after that so then if the database has to parse
467.06s - 471.86s |  this message it will just see a very small length and only parse a very small message
471.86s - 477.78s |  and then try to parse whatever is coming after that as more messages but in fact it's data from
477.78s - 485.54s |  the first message so let's look at this again with example messengers so here we have a very
485.54s - 490.66s |  small one we have a four byte value and then the length becomes eight because the size of the length
490.66s - 497.54s |  field itself is also included in the length so it's a length of eight this is how the largest
497.54s - 503.46s |  possible message looks like you can see the length is filled to the brim with hex ffff because the
503.46s - 508.98s |  value is just almost four gigabytes of ace but still everything's good because the application
508.98s - 516.10s |  can express this length in the four bytes and so the database will parse the same size but if we
516.10s - 521.94s |  make it just a little bit larger we can see that the truncation happens because the most significant
521.94s - 527.46s |  bit is not represented in the length anymore so the length is just four which means this is a tiny
527.46s - 532.10s |  message and then after that in the connection there comes some garbage ace that the database
532.10s - 538.50s |  can't really understand but if the attacker chooses not ace but some bytes that the database
538.50s - 546.10s |  can understand they can craft an injected message here so let's zoom out again and look at this again
546.66s - 553.14s |  this is the small message all is good this is the large message that does not cause a truncation
553.14s - 559.94s |  so both the application and the database see it and parse it the same way but if we make the size
559.94s - 565.46s |  a little bit too big the application thinks it's writing this big number but actually because of
565.46s - 571.46s |  the truncation bug it writes a small number so when the database parses it it sees one small
571.46s - 578.82s |  message and then garbage or if the payload is cleverly crafted it sees more messages that can
578.82s - 583.38s |  contain attacker controlled sql statements like this one that adds a new admin user
583.94s - 591.70s |  so the impact is quite high here um you can inject entire sql statements you're not limited to union
591.70s - 597.06s |  based or subquery based sql injection like with the very classic ones it's more like if you have
597.06s - 602.74s |  stack queries enabled so you can just finish the first statement that you're injecting into and
602.74s - 607.94s |  then have a whole another one that can be an insert even if the other one was a select and so on
608.90s - 613.62s |  so this means the attacker can essentially read write and delete all the data in the database
613.62s - 618.42s |  with the permissions of the application and if the database is configured insecurely this can
618.42s - 624.66s |  already lead to code execution um or you just have all of the data from the database which is
624.66s - 630.98s |  bad enough the only thing that's a little bit less convenient than with classic sql injections
630.98s - 637.14s |  is that data exfiltration is a little bit uh less straightforward because if you're
637.14s - 643.06s |  injecting more messages into the connection then the application will still only process the answer
643.06s - 648.82s |  for the first message so you don't directly get the results of your injected message where you
648.82s - 654.58s |  maybe select all the password recept tokens of users um so you have to go a different route of
654.58s - 659.62s |  maybe doing a subquery and then using an insert to put this data you want to exfiltrate in another
659.62s - 664.58s |  table and then use business logic of the application to access the data so it still works
664.58s - 671.14s |  just a little less convenient but how does this look in the real world uh some of you might have
671.14s - 676.58s |  already noticed that if we control all of these a's that we have in a message why can't we just
676.58s - 681.78s |  directly put any sql statement in the first place why do we need to have the overflow and you would
681.78s - 688.66s |  be correct because this was just a simplification so let's look at how this actually looks um this
688.66s - 694.74s |  is a two-line code snippet the id here is user controlled in this case it's a very small one
695.38s - 699.70s |  and then we have our query you might recognize it from the teaser code snippet
699.70s - 704.58s |  that uses the id to select a user from the database and the resulting packet or message
704.58s - 709.22s |  that's sent over the wire looks like this we have our type byte then a small length
709.22s - 715.46s |  and then we have the value with a trailing null byte all is fine here but now if the attacker
715.46s - 721.78s |  makes the user controlled id very large four gigabytes then suddenly the length in the packet
721.78s - 727.30s |  is smaller than before even then even though we send more data so we see that the truncation
727.30s - 734.10s |  happened and now when the database tries to parse this packet it will see okay it's a length of 38
734.10s - 740.66s |  bytes so i'm going to parse until that and after that it will try to parse the next message so the
740.66s - 746.98s |  attacker has to put their cleverly crafted payload at that exact offset in this big buffer
746.98s - 755.38s |  of ace but how does the attacker know this offset um the offset depends on the query that they are
755.38s - 760.50s |  injecting into and especially on the injection point in the query and the length of the whole
760.50s - 766.18s |  query so if you know these things you can just calculate the offset and you're done but maybe
766.18s - 770.42s |  you're lazy and don't want to do the math or you don't know the query because it's kind of a black
770.42s - 777.46s |  box test um so what can you do then and of course the naive solution is to brute force the offsets
777.46s - 782.98s |  uh but unfortunately now you're for each try you have to send four gigabytes which is slow even on
782.98s - 788.58s |  local setups and on like production setups it creates a lot of noise and risks denial of service
788.58s - 795.38s |  because it's a lot of data so can we make this more reliable and the first technique uh i tried
795.38s - 800.82s |  out here was to borrow something from binary exploitation from 20 plus years ago which is
800.82s - 806.90s |  called a knob sled and mapped to this problem we just use a lot of very small message at the
806.90s - 812.74s |  beginning of the buffer so that when we hit the start of one of these messages uh everything's
812.74s - 817.14s |  fine because the message is parsed and then the next one and then the next one and so on until
817.78s - 825.06s |  at the very end the big message with the actual attacker sql payload is parsed and executed but
825.06s - 832.10s |  if we hit any other byte um the database will cause a fatal error because it cannot parse there
832.10s - 836.50s |  and it will close the connection between the application and the database but usually that's
836.50s - 841.38s |  not too bad because applications have connection pools and they just reopen connections if they
841.38s - 847.86s |  get closed so let's visualize this this is the smallest possible message in the postgres wire
847.86s - 856.10s |  protocol so we repeat this a lot of times and in the end we have our actual payload so if the offset
856.10s - 862.58s |  happens to align with the first or the fifth and so on byte then we're good but if it hits one of
862.58s - 868.26s |  the other bytes then there's this fatal parsing error and the connection is closed so if that
868.26s - 876.50s |  happens we can try again and now we just prepend one padding byte and then if it if the offset
876.50s - 881.78s |  happened to align with the second byte and so on then now this attempt would be lucky otherwise we
881.78s - 890.42s |  just try again and again and again until we're lucky at the last try so this means that after
890.42s - 895.22s |  a maximum of five attempts uh the attack is successful because each try has a 20 percent
895.22s - 901.22s |  chance of success and we can repeat the attack but still in the worst case we have to send
901.22s - 906.34s |  five times four gigabytes which can still be a lot so maybe we can make it even better
907.54s - 913.22s |  and for this i looked at what was holding us back with the last strategy and here it was the
913.22s - 917.70s |  length bytes because those were not valid type bytes so not a valid start of a message
918.26s - 924.66s |  so maybe we can make them valid type bytes and i call this technique trampolines and what we do
924.66s - 931.54s |  here is first we just use the queue which is a valid type byte for each byte because this is also
933.14s - 940.66s |  some big length it's hex 51 51 and so on and we can see down below the whole attacker
941.38s - 948.34s |  payload and we'll see how things are parsed when the offset hits certain bytes here
949.06s - 954.82s |  so if it hits the very beginning the database parses it like this first q is the type byte and
954.82s - 961.62s |  then q q q q is the length of the first message so the database will parse the following whatever
961.62s - 967.94s |  q q q q means as a number bytes and try to run this as a query and of course this will cause
967.94s - 973.54s |  like a semantic syntax error but this does not close the connection so the database will just
973.54s - 978.50s |  complain with an error response but continue parsing the next message so this is like jumping
978.50s - 985.38s |  over this many bytes so that's the trampoline right there and where we land after that we have
985.38s - 992.34s |  a pre-constructed message that has the exact size that then does another jump that ends up at right
992.34s - 1000.58s |  at the end of the attacker payload where the actual sql statement message is so if we would
1000.58s - 1006.50s |  have hit any of the other bytes things look slightly different but not too different here
1006.50s - 1015.14s |  the length is parsed as q s s s the s is also a very valid type byte now it jumps over some more
1015.14s - 1021.14s |  bytes and it lands at a different pre-constructed message that again has the exact size that it does
1021.14s - 1029.70s |  the right jump to land at the end but does this actually work like we plan to do and unfortunately
1030.42s - 1036.90s |  after i tried to implement this i noticed well postgres has a logical maximum message size next
1036.90s - 1043.62s |  to the actual size that you can possibly fit into four bytes and this is just under one gigabyte
1043.62s - 1049.54s |  so the first byte of the length can never be larger than hex 3f so that's bad because with
1049.54s - 1056.66s |  the q that doesn't work so what if we just use 3f as the type and all of the length bytes then
1056.98s - 1064.42s |  it also doesn't work because hex 3f is not a valid type byte and also none below that at least
1064.42s - 1070.58s |  not for messages from the application to the database so i had to use a compromise here which
1070.58s - 1077.70s |  is an alternating pattern and with this now every second byte is a valid type byte so a valid start
1077.70s - 1083.70s |  of a message so hit we if we hit any of those bytes we're good because everything is parsed
1083.70s - 1088.42s |  okay and then we can do our trampolines like i just showed and if we hit any of the other
1088.42s - 1094.34s |  bytes like a null byte then we get the error and the connection is closed but still we can try again
1094.34s - 1100.82s |  so after a maximum of two attempts we are successful which is much better than the initial
1100.82s - 1108.45s |  brute force all right let's see how many vulnerable libraries there were that we found
1108.45s - 1113.49s |  and this is just a selection we looked at more but these are only the ones that were
1113.49s - 1119.41s |  potentially vulnerable so for go we tested four libraries and we found all of them to be
1119.41s - 1125.33s |  vulnerable and also exploitable and i'm going to go into exploitability in a minute unfortunately
1125.33s - 1131.01s |  only one of them fixed the issues we reported and the others did not so they are still vulnerable
1131.01s - 1136.05s |  in the latest version for c sharp there was one library we looked at it was vulnerable and
1136.05s - 1142.29s |  exploitable but unfortunately they fixed and also backported it to older branches of the library
1143.25s - 1149.89s |  so that's great to see and then for java and javascript we tested a bunch of libraries and
1149.89s - 1155.49s |  a lot of them were in theory vulnerable they had overflows without the right checks but they were
1155.49s - 1161.17s |  not exploitable and this was most of the times due to language limitations where for example you
1161.17s - 1167.17s |  cannot have large enough strings or buffers that would be more than four gigabytes so the length
1167.17s - 1171.97s |  would never overflow the four byte length field and we're going to look into these language
1171.97s - 1179.09s |  differences later so short disclosure timeline for transparency we send out the advisories in
1179.09s - 1186.61s |  february this year then pgx fixed in march and pgsql fixed in may and for a pg and pg driver
1186.61s - 1193.49s |  the maintainer first responded to our advisory but then stopped and didn't implement fixes until now
1193.49s - 1198.37s |  and for pq we couldn't even reach the maintainers we tried to do it via their github made an issue
1198.37s - 1204.93s |  or made a pull request with the fix but they got no attention unfortunately so now let's go from
1204.93s - 1210.37s |  vulnerable libraries to exploitable applications so first we have a set of applications that
1210.37s - 1216.13s |  use these libraries or have used libraries in a vulnerable version um and these for example
1216.13s - 1221.57s |  include grafana or gitty or sync thing but we weren't able to confirm if there's an exploitable
1221.57s - 1228.53s |  path here so there might be but we haven't proven it yet and then there's a set of applications
1228.53s - 1235.25s |  that we found to be vulnerable in a non-default configuration for example metamost or gox and then
1235.25s - 1241.49s |  there was also the sweet spot which is applications that are vulnerable in the default config and our
1241.49s - 1248.05s |  example here was harbor and harbor is a container registry it's a cncf graduate project which means
1248.05s - 1254.13s |  it's quite mature and people are using it it's also apparently part of vmware tanzu kubernetes
1254.13s - 1258.77s |  but we didn't look into more of that so we don't know if it's exploitable in that scenario as well
1259.73s - 1266.45s |  but in its default version it's vulnerable in the default configuration and also pre-authentication
1266.45s - 1273.25s |  which is quite bad so they fixed this in version 2.11 which is the latest one by updating their
1273.25s - 1278.45s |  dependency so if you have a harbor instance you definitely should update to the latest version
1279.25s - 1285.57s |  and i'm going to try to demo the harbor exploit now i'm going to try to do it live i also have a
1285.57s - 1295.33s |  backup video um but let's see so first i will try to log in as the attacker to show that there should
1295.33s - 1302.53s |  be no attacker user as you can see the login doesn't work so now if we start the exploit
1303.17s - 1311.97s |  and i hope this works over the unstable internet um we have to wait a bit so there we see the query
1311.97s - 1316.69s |  that the exploit is sending this is an insert query that will insert the attacker user into the
1316.69s - 1322.69s |  database so then we could log in and as we can see it's sending a lot of bytes four gigabytes
1322.69s - 1329.41s |  so it takes some time and if it works successfully then we should be able to log in
1329.41s - 1336.21s |  and have administrative privileges in the hardware application so that we then could send our mess
1336.21s - 1341.41s |  with the containers in there so we saw an error which is expected here so if i now try to log in
1341.41s - 1351.52s |  again we should log in successfully i hope okay it doesn't seem to work i have to switch to the
1351.52s - 1362.91s |  backup video and there on the left now we try to log in again and there we can see we can now log
1362.91s - 1376.22s |  in and have admin privileges all right that was postgres now also let's look at mongodb to show
1376.22s - 1383.58s |  that it's not a postgres and go only problem so to look back this is what a message in mongodb
1383.58s - 1388.70s |  looks like we have a four byte length field this time it's little endian then we have two metadata
1388.70s - 1393.26s |  fields that are not relevant here and then we have the opcode which is like the message type
1393.26s - 1397.82s |  and then the value is a complex binary structure that's called bison which i think stands for
1397.82s - 1404.38s |  binary json and it's some nested data that's serialized to tlv sections so they also have
1404.38s - 1410.22s |  lengths again and to directly look at some code it's a little bit more but i'm gonna walk you
1410.22s - 1416.54s |  through it we first have a line here that takes the content bytes so it takes the query and puts
1416.54s - 1423.74s |  it into this bison representation then it computes the total length of the message by adding the
1423.74s - 1430.62s |  header length and and so on and this is saved as a type u size variable again on most modern systems
1430.62s - 1438.54s |  this is a 64-bit integer and then again this is truncated explicitly to an int32 because that what
1438.54s - 1444.46s |  fits into the field so the developer had to cut it down here but of course this is the same issue
1444.46s - 1450.62s |  as before if the length was larger what can then what can be expressed here um we have our
1450.62s - 1458.62s |  truncation and things go wrong the exact same way as it did for postgres so for crafting a payload
1458.62s - 1464.06s |  for mongodb it's a little bit more involved because we have to avoid bad bytes the payload
1464.62s - 1470.54s |  must be valid utf-8 because the strings are serialized as utf-8 to the wire so we cannot
1470.54s - 1476.54s |  create any bytes that are invalid utf-8 but the problem is the message type that we need to write
1476.54s - 1483.50s |  in order to craft the right injected message is 0xdd07 and that's always invalid utf-8 so
1483.50s - 1490.94s |  how can we do that and also size fields inside the message could become some byte values that
1490.94s - 1495.82s |  would also be invalid utf-8 so we have to be careful there as well and the solution was to
1495.82s - 1502.54s |  just use other metadata of the message we're injecting into to create these byte values and i
1502.54s - 1508.14s |  have an example for that so this is a normal mongodb query it just queries for a movie based
1508.14s - 1514.70s |  on a few attributes and this is serialized to the following bson document in the beginning we have
1514.70s - 1521.02s |  in blue the length of the whole document then in red we have a type identifier that says the next
1521.02s - 1528.22s |  key value pair has a string value then in yellow we have the key which in this case is title with
1528.22s - 1533.50s |  a trailing null byte then in blue again we have the length of the following string and then in
1533.50s - 1538.86s |  green we have the actual string with a terminating null byte then we have the next key value pairs
1538.86s - 1544.30s |  and so on and at the end we have another null byte that shows the end of the document so if we want
1544.30s - 1551.26s |  to have the hex sequence dd07 anywhere in here we cannot use the yellow and green parts because
1551.26s - 1558.14s |  they have to be a valid utf-8 but what we can do is for example use the length of a string and just
1558.14s - 1565.50s |  make the string the length that will when serialized to bytes will be the exact byte sequence we need
1565.50s - 1571.58s |  so here we need to subtract one because there's a appended null byte but then we have the dd07
1571.58s - 1578.06s |  there and with this trick now we can craft the entire injected message i cannot go into all of
1578.06s - 1582.46s |  this here because we don't have time but this is the trick you need to be able to do it
1584.30s - 1590.86s |  so we also looked at libraries here and uh we found the official rust mongodb client library
1590.86s - 1597.18s |  to be vulnerable and exploitable we sent out our advisory also in february and they fixed in march
1597.18s - 1601.66s |  so if you use this especially if you use it in production which i doubt because it's rust
1601.66s - 1610.05s |  but then you should update to 2.8.2 okay let's now take a step back we've seen all the cool
1610.05s - 1616.13s |  bugs and the exploitation but is this actually applicable to the real world we've seen the demo
1616.13s - 1621.57s |  but maybe this was just a lucky punch so let's talk about constraints and especially about the
1621.57s - 1627.25s |  elephant in the room which here weighs four gigabytes because a lot of you probably are
1627.33s - 1633.49s |  thinking well can we actually send four gigabytes into all the applications aren't apps limiting
1633.49s - 1639.33s |  input sizes and you would be right now there's a lot of common protections like default body size
1639.33s - 1645.33s |  limits of your favorite web framework or maybe json and forum decode maximum sizes or you have
1645.33s - 1652.13s |  your reverse proxy that's limiting request size and so on and i also encountered this and thought
1652.13s - 1657.49s |  about some potential bypasses here so the first idea is that sometimes endpoints are just
1657.49s - 1663.89s |  unprotected so maybe your framework doesn't have a default size limit and also sometimes the
1663.89s - 1669.25s |  developers explicitly disable the limits this was the case with harbor for example they have an
1669.25s - 1675.65s |  nginx reverse proxy which usually has a one megabyte request limit but they explicitly disabled
1675.65s - 1681.73s |  it i guess because they need to receive big docker images so they need more uh request size but this
1681.73s - 1687.73s |  also meant that the whole api is now not limited anymore and the goal framework that's used under
1687.73s - 1694.69s |  the hood of the server did not limit this so we could send our big payload the next trick would
1694.69s - 1700.61s |  be to use compression this on the one hand allows you to send your attacker payload much quicker
1700.61s - 1704.61s |  because you can compress it down and don't have to send four gigabytes over the internet
1705.33s - 1709.33s |  and also there can be logic bugs where maybe your reverse proxy or your framework
1709.89s - 1716.45s |  first checks the request size but does the decompression after that so the check is
1716.45s - 1723.49s |  essentially useless because your compressed data will inflate a lot and you can craft a big
1723.49s - 1729.09s |  payload that after decompression still causes the overflow so for nginx for example this works
1729.09s - 1733.89s |  because nginx does not look at the body it doesn't try to decompress it it just looks at the raw
1733.89s - 1739.97s |  size of the request so if your backend does decompression then you could bypass this and
1739.97s - 1745.97s |  also for example the javascript fastify framework does both checks the body size and also does the
1745.97s - 1752.29s |  decompression but it does it in the wrong order so you can bypass the limit then you might also
1752.29s - 1758.45s |  have websockets support on the server of your target this is cool because websockets also in
1758.45s - 1764.05s |  theory supports compression it's not always enabled but it can help you but even without
1764.05s - 1771.73s |  that a single websocket request can be super large i think it's a 64-bit integer the size field so
1772.53s - 1777.97s |  you can definitely send four gigabyte messages with that and maybe the middlewares and filters
1777.97s - 1783.73s |  that are present in your framework don't apply to each individual websocket message so maybe there's
1783.73s - 1791.01s |  no limit there then you could also use alternate body types for example a multi-part form instead
1791.01s - 1796.93s |  of a json body and maybe the limits are different there or the developer forgot to configure a limit
1796.93s - 1803.09s |  so this could be another bypass and then this one which i like the most is a little bit more
1803.09s - 1808.61s |  creative and open which i call server-side creation which is you just find other means of
1808.61s - 1814.77s |  bringing a big string to the server without sending it in your requests and one example is
1814.77s - 1821.49s |  ssrf where you point some functionality of the server to an attacker server which then returns
1821.49s - 1826.21s |  a very large response and if this one gets saved into the database or used in a query
1826.77s - 1831.97s |  it will also cause the overflow and this for example worked in gogs where you have a webhooks
1831.97s - 1838.37s |  feature but beyond the ssrf you might also have templating or translation that you could use to
1838.37s - 1843.73s |  inflate a string and this all depends on the business logic and the features of the server
1843.73s - 1850.18s |  so that's where you can get creative to find bypasses all right now that we've seen how we
1850.18s - 1855.94s |  might bypass limitations of frameworks and servers we also need to look at languages we already seen
1855.94s - 1861.78s |  some differences at the vulnerable libraries so we need to see how well languages handle large
1861.78s - 1867.38s |  payloads like how big can strings and buffers be and also what about integer overflows does
1867.38s - 1873.54s |  every language have silent integer overflows or maybe some languages are safe so for the large
1873.54s - 1880.10s |  payloads we can see that go python and rust out of the languages we we looked at uh have large
1880.10s - 1887.14s |  enough string and buffer sizes that you can send four gigabytes and they can handle it for java
1887.14s - 1893.38s |  you're out of luck and we also saw see the song seen this with unexploitable libraries in java
1894.26s - 1901.22s |  and that's because strings and buffers here are backed by arrays which have integer indexes so you
1901.22s - 1909.22s |  cannot index more than i think yeah two to the power of 31 here for c sharp the string size is
1909.22s - 1915.14s |  not big enough but the buffer size is so if you have multiple strings that you control then you
1915.14s - 1920.98s |  can still end up with a buffer that becomes bigger than four gigabytes and for javascript it totally
1920.98s - 1926.34s |  depends on the implementation for node strings are much smaller compared to the other languages
1926.34s - 1934.88s |  but buffers can be large enough for integer overflows we can see that for addition overflows
1934.88s - 1941.92s |  which just means you add two integers and we can see that in go java and c sharp c sharp a silent
1941.92s - 1948.16s |  integer overflow happens so it will just wrap around for javascript there will be no overflow
1948.16s - 1952.96s |  things will just get more inaccurate because it's javascript and they use floats under the hood
1954.00s - 1961.20s |  and in python you have arbitrarily sized integers so you cannot overflow that and in rust it depends
1961.20s - 1966.00s |  on how you build your project if you build it in debug mode the compiler will emit a
1966.64s - 1970.00s |  check that checks for overflows but in a release build it will not do that
1970.00s - 1978.40s |  and for serialization overflows which basically is the case when you have a standard function in
1978.40s - 1985.36s |  your language that allows you to write a integer to a fixed size field does this function check
1985.36s - 1990.48s |  for overflows or not and in all of the type safe languages this does not does not apply because
1990.48s - 1997.60s |  the types that the function can receive cannot overflow the size field or the field that it
1997.60s - 2003.20s |  gets serialized to but this just means that the developers now have to do the check before
2003.20s - 2009.60s |  casting to this type and we've seen that this leads to bugs in our go and rust examples in
2009.60s - 2015.76s |  javascript it's again implementation dependent i think in node.js it does the check but in
2015.76s - 2023.44s |  bun or dino it might not do it and in python the struct.pack function actually does a check if you
2023.44s - 2028.32s |  pass a too large integer it will throw an error if you try to serialize it to a too small field
2030.08s - 2036.64s |  so to summarize the real world applicability we can say that in a lot of times we can send large
2036.64s - 2045.44s |  payloads past the limits for silent integer overflows or truncations we also seen that in
2045.44s - 2051.84s |  many languages it works or the developers do the mistake for the language and we also seen that you
2051.84s - 2060.26s |  can definitely exploit some real world applications with this all right now let's look at what is
2060.26s - 2066.58s |  there more to do in this kind of research for binary protocol smuggling but first i have to
2066.58s - 2072.66s |  give a small disclaimer here please don't go out and send four gigabytes to every api endpoint in
2072.66s - 2077.46s |  your bug bounty scope because you will crash systems you will get blocked and you will ruin
2077.46s - 2082.98s |  a devops engineer's day because they have to look at the monitoring alert so don't do it please
2084.34s - 2090.58s |  but speaking of this it would be cool to actually have a non-invasive detection mechanism
2090.58s - 2095.46s |  in white box tests it's okay you can make your local testing environment and just hammer it with
2095.46s - 2102.10s |  gigabytes of data but of course in black box tests that doesn't work so if we could find a methodology
2102.10s - 2107.94s |  to find for example a fingerprint of a database client library being used and we would know that
2107.94s - 2113.94s |  this library is vulnerable to these kind of texts then we could either directly report it or only do
2113.94s - 2121.30s |  the large payload then and if this would be a tool it would be great to aid you in pen tests and so on
2123.14s - 2129.22s |  and of course it would be awesome to research a lot of more stuff more protocols like there's
2129.22s - 2134.10s |  more databases than we stuff then stuff we looked at today and there's all of the other systems
2134.10s - 2139.94s |  caches message queues and so on that the application has to talk to we can also try
2139.94s - 2144.90s |  to find more decent techniques for example look into protocols that use delimiters and not size
2144.90s - 2152.26s |  fields and we can also find more large payload message which is ways to bypass the filters of
2152.26s - 2159.46s |  a framework for example to bypass the request size limits or maybe we can find generic ways
2159.46s - 2165.54s |  of making a server craft a very large string maybe there's some way to do this
2167.62s - 2173.46s |  and of course all of the stuff we looked at today had four bytes length fields but what about two
2173.46s - 2179.46s |  byte length fields this would be much easier to exploit sending 65 kilobytes instead of four
2179.46s - 2187.54s |  gigabytes is much easier you don't have the hassle with all the limitations and i already already
2187.54s - 2192.34s |  started to look into this a little bit so stay tuned for more to come in the future but feel
2192.34s - 2201.76s |  free to also go out and check this yourself so let's wrap things up i have a few takeaways and
2201.76s - 2207.68s |  the first one is that i think integer overflows are still relevant in memory safe languages of
2207.68s - 2214.00s |  course in c if you have an integer overflow it's easily easy to get some memory corruption with it
2214.00s - 2220.56s |  so uh that's done but in memory safe languages um the worst case that can happen is a array out
2220.56s - 2227.04s |  of bounds or whatever but with these data attacks in the binary protocols that we've seen today
2227.84s - 2233.04s |  now we have a new way of exploiting these and i think developers kind of forgot about integer
2233.04s - 2239.28s |  overflows and maybe researchers as well at least in the memory safe languages then we also seen
2239.28s - 2246.56s |  that it's entirely feasible to send large amounts of data even with protections because there's many
2246.56s - 2253.04s |  ways how you can bypass these protections and finally to get back to the title sql injection
2253.04s - 2259.44s |  isn't dead of course it was never dead at least not in the real world we've seen a lot of real
2259.44s - 2266.16s |  world applications uh and with sql injections but on paper you could say uh developers have the right
2266.16s - 2273.04s |  tools to write secure sql based applications they have parameterized queries they have
2273.04s - 2278.32s |  query builders they have orms so if they use all of this and the application is safe
2278.88s - 2284.00s |  so if you can't hack it you just have to go a level deeper thank you


url: https://www.youtube.com/watch?v=QXa29AJqdRc
title: DEF CON 32 - Reverse Engineering MicroPython Frozen Modules - Wesley McGrew
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=QXa29AJqdRc",
  "title": "DEF CON 32 - Reverse Engineering MicroPython Frozen Modules  - Wesley McGrew",
  "description": "MicroPython is a firmware environment for quickly developing and deploying software onto microcontroller systems. It is used in a variety of industrial and scientific applications, as well as (most importantly) in some DEF CON #badgelife projects. It's easy to learn and use for rapid prototyping.\n\nFor hackers interested in reverse engineering compiled or obfuscated MicroPython code, there are some obstacles. MicroPython is an implementation of CPython, not a port, so it has its own compiled bytecode language that existing reverse engineering tools aren't designed to parse. Also, modules can be \"frozen\", compiled directly into the microcontroller firmware, and may be difficult to locate and parse when microcontroller firmware is extracted and analyzed.\n\nIn this talk, Wesley will walk the audience through the process of identifying \"frozen\"/compiled modules in a firmware image without debug symbols using the Ghidra disassembler. The relevant module, string, object, and raw code data structures will be detailed, so that everything required to rebuild a non-frozen module can recovered. Once a compiled module is reconstructed, Wesley will present a detailed example of reading and understanding MicroPython compiled bytecode, for the purpose of reverse engineering the purpose and implementation of the module.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2602,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.91s - 6.71s | This text was transcribed using whisper model: large-v2

 Thank you for showing up everybody. I appreciate this. I know that I'm on opposite of Pony Awards
6.71s - 10.31s |  So if you're here for Pony Awards, you're in the right place
10.91s - 13.11s |  So this is a reverse engineering
13.99s - 20.95s |  MicroPython frozen modules. My name is Wesley McGrew. I'm senior cyber fellow with Martin Federal and
22.07s - 24.99s |  This is talk is going to be a lot of fun for
25.71s - 29.39s |  Those of you who like to hack on badge life stuff a lot of badge life
30.31s - 32.31s |  Badges use this
33.11s - 35.11s |  Python interpreter and
36.11s - 37.87s |  we're able to
37.87s - 40.95s |  Pick out some things that perhaps you wouldn't have otherwise
41.79s - 46.41s |  So the agenda for the talk we're going to be
47.67s - 51.07s |  We're going to introduce what micro Python is for those of you not familiar
51.07s - 54.93s |  I'm pretty sure most of you know about Python in general
55.39s - 60.71s |  we're going to look at micro Python firmware on the Raspberry Pi Pico, so
61.63s - 68.43s |  It's available for a lot of different microcontrollers, but Pico is probably the easiest for you to set up experimentation in your lab with
69.15s - 71.15s |  we're going to build a
71.95s - 73.95s |  Hello world
74.07s - 75.75s |  module for it and
75.75s - 81.55s |  We're going to compile it down into bytecode and then we're going to freeze it into the micro Python firmware itself
81.71s - 87.95s |  So that it's harder for somebody to extract we're going to talk about that freezing process and why it's there
88.95s - 90.95s |  We're going to have a hands-on example of
91.63s - 98.27s |  Reconstructing that module from a compiled firmware. We're going to do it with symbols and without symbols, so
99.03s - 103.55s |  Show you how to do it in an environment where somebody's trying to actively keep you from doing it
104.31s - 110.67s |  We're going to do some analysis of that extracted module and come to some conclusions about what this means for reverse engineering it
111.11s - 117.81s |  So micro Python is an implementation of Python 3 for microcontrollers
117.81s - 124.21s |  And it's very interesting in that it's not a straight port of CPython CPython is the Python
124.33s - 130.73s |  You're familiar with on your desktop system where or it's a compiled. It's an interpreter running
131.49s - 133.13s |  bytecode
133.13s - 136.01s |  based off of the Python code that you write and
138.09s - 142.89s |  Micro Python completely just re-implements it from scratch and and I'm not
143.41s - 147.53s |  There's probably reasons for doing that instead of starting from CPython
148.61s - 154.21s |  Microcontrollers have limited resources and so things are optimized for that kind of environment
155.53s - 159.17s |  There's a subset of Python standard libraries in there. There's not
159.93s - 165.29s |  Libraries for some of the standard library stuff that doesn't make sense on microcontroller, but there's also some additional
166.05s - 167.93s |  micro Python
167.93s - 175.09s |  Only libraries there just for working with microcontroller hardware primarily like GPIO like turn pin one on
175.85s - 177.85s |  Pull it low that sort of thing
178.25s - 181.01s |  There is a rebel so a command line
181.41s - 186.17s |  You're used to a Python where you can just start typing Python code and have it execute and sort of
186.29s - 188.29s |  Play around with the Python environment
188.29s - 194.45s |  You can do that with micro Python if you have a serial terminal on your microcontroller like you do with a Pico
196.21s - 203.29s |  The use cases for it you don't I don't see it in anything that you can just like go to Lowe's and buy for home
203.45s - 210.69s |  Automation, but you do see it in scientific application industrial applications you see it
211.01s - 218.01s |  in badges and so like the last year's snacky badge at least use micro Python and
219.25s - 223.49s |  specifically the frozen modules are used by a lot of folks to
224.17s - 228.09s |  Have code cooked into the firmware itself. That's not in a
229.25s - 231.25s |  module file on the file system
232.25s - 239.53s |  It's really nice. So what I'm presenting here is not a mistake made with micro Python. It's just a reverse engineering talk
239.53s - 244.61s |  There's no vulnerability here as my micro Python is concerned. I like it
244.61s - 249.73s |  It's really easy to create a prototype of an embedded device with micro Python
250.33s - 253.85s |  And so you have three choices for your code you can have
254.53s - 259.71s |  Plain text that's on a small file system. That's in the emulated in part of your flash memory
260.59s - 264.23s |  You can and you can read and write to that file system through the REPL
265.15s - 266.83s |  you can
266.83s - 275.07s |  have pre compiled byte code modules and we'll talk about the structure of those but then you can also take those pre compiled modules and
275.75s - 282.35s |  Cook them into the file into the micro Python firmware at build time and that removes a lot of the metadata that makes it
282.35s - 284.35s |  easy to find those modules and
284.87s - 289.15s |  Disassemble them right there. There's tools for working with the other portions of this
289.19s - 292.59s |  There's no tools for going back from a frozen module
292.59s - 298.47s |  and so in badge life a lot of CTFs that use badges will hold secrets and
298.63s - 304.29s |  Keys and code that they don't want you to see as part of the CTF inside those frozen modules
305.75s - 312.11s |  The feature is there for efficiency. So the feature is there so that you're not wasting additional memory loading
312.43s - 314.43s |  Dot PI or loading of the dot
314.99s - 320.07s |  MPY file into memory and doing things when it's already in memory because it's on the flash
320.55s - 326.35s |  So it saves memory. It's convenient. You don't have to do any additional loads. It's already there
327.39s - 329.39s |  but it's being
329.43s - 331.43s |  abused misused for
332.07s - 335.71s |  obfuscating and hiding code and secrets inside of these binaries and
337.03s - 339.03s |  We've got some quotes
339.43s - 342.63s |  Here that from random forums and stuff you probably can't read them
343.07s - 347.59s |  They're small. I just grabbed a bunch of them and threw them up. But the gist of all these quotes is
348.51s - 356.11s |  People are asking. Well, if I've got a password for a system, how do I keep that away from my users or I've got a key
356.11s - 358.91s |  I've got a secret that I don't want them to read my code
359.55s - 361.51s |  their concerns are
361.51s - 366.87s |  Making this obfuscated and people were responding to them on these forums of like, you know
366.87s - 370.11s |  It's not perfect and everybody acknowledges that this isn't perfect and it's not perfect
370.11s - 374.51s |  but you can make it harder to get it that stuff by cooking it into a
374.79s - 380.13s |  Frozen module because nobody has the tools to disassemble it. And so let's make something to disassemble it
381.99s - 385.99s |  It's a layer of protection for some folks, but it's really just an obfuscation
387.19s - 391.15s |  The first thing that you have to do to get this thing working is to get a firmware image
391.39s - 397.31s |  So that's out of scope for this talk and it's tricky depending on the module depending on your microcontroller
397.31s - 399.47s |  You might not be able to get a flash image easy
399.51s - 405.03s |  that's a whole talk on you know glitching and things like that, but since we're using Pico's as the
405.99s - 409.27s |  Pico as the dev environment here we can
410.23s - 413.19s |  We can just use the standard Pico tools for this demonstration
413.91s - 416.19s |  If you're following at home with a Pico
416.75s - 421.31s |  You use the Pico tool info and it'll tell you about the
421.83s - 424.19s |  About the firmware of an a connected Pico
424.35s - 429.35s |  but it actually makes it a little too easy as you can see from the output here from the output you have a list of
429.35s - 431.15s |  frozen modules here and
431.15s - 434.35s |  You know, well, that's that seems dumb seems like a really short talk
434.99s - 438.83s |  and what that's from is from Pico's Pico has
439.43s - 444.79s |  binary information quote-unquote binary information in the firmware image and
445.15s - 450.63s |  It can be read with Pico tool it can be in code it's encoded by MicroPython
451.51s - 455.11s |  firmware can specify in MicroPython that it's going to
456.19s - 460.59s |  include additional fields in that Pico tool or in that binary information and
461.99s - 465.55s |  MicroPython does this with simply a list of the frozen modules and
466.15s - 468.15s |  So again, that seems real easy
468.43s - 473.55s |  you can look at how to parse that from a tool that comes with MicroPython that
473.95s - 481.47s |  We're going to be using a lot here mpy tool this is used for freezing modules for inspecting mpy files
483.07s - 488.87s |  There's some stuff in there for how it encodes that that information and
489.91s - 496.15s |  So since this is too easy as a starting point, I mean, it's too easy because you can strip this out
496.15s - 501.95s |  It's not necessary for the operation of the firmware, right? So other platforms
502.95s - 508.87s |  Other micro controls may not even have this sort of field this sort of binary information in the firmware
509.95s - 512.23s |  It's not used by MicroPython itself
512.47s - 517.75s |  So we can evade this analysis by commenting out the code in the freezing tool
518.19s - 522.39s |  That generates that list right and so to make it harder on ourselves, right?
522.39s - 528.07s |  Because we imagine the next step after we start ripping this stuff out people are going to start obfuscating this part
528.67s - 535.67s |  So we can rip this out and not have those frozen modules listed if you can get to a serial console
535.99s - 542.15s |  REPL, you can also do help modules and list them out. That is probably something that needs to be in there
542.15s - 547.35s |  I don't know if you could patch out an evasion from our countermeasure against that
547.63s - 554.15s |  But that's but it's not always the case that you're going to be able to easily get the REPL on on a microcontroller
554.83s - 564.10s |  So for our example, we're going to have the the minimum viable Python module here a hello world that we're going to
564.90s - 566.46s |  demonstrate in
566.46s - 572.26s |  in plain text, we're going to demonstrate it as a compiled bytecode file on the file system and
573.06s - 579.46s |  Then finally as a frozen module compiled into MicroPython and look at what that looks like in the binary
580.46s - 587.82s |  Plain text is simple. You simply use the MP remote tool to upload it into the file system on the microcontroller
587.82s - 592.86s |  There's a small very small file system that it stores those things in
593.42s - 596.94s |  You can list files on it and you import and go
598.74s - 603.56s |  You can use the mpy cross compiler to compile
604.04s - 610.12s |  Your hello world dot py into an mpy into py file and you wind up with the hex dump
610.12s - 613.52s |  Are you from one up of a file that has the following hex representation?
613.52s - 616.88s |  And so you can kind of see in there used to see our strings
617.12s - 621.32s |  You can see some bytecode in there. And so you're like, okay, this is a thing
622.40s - 625.92s |  This immediate doesn't immediately look to you to be very useful
626.04s - 632.80s |  but the mpy tool can work with this forward format very well and you can upload it into the file system and
633.08s - 635.76s |  And use it. And so if you find one on a file system
636.44s - 639.72s |  Use mpy tool to to tinker around with it
640.48s - 641.96s |  as a
641.96s - 648.76s |  Frozen module you can take that mpy and rebuild the microcontroller or firmware from scratch
648.76s - 655.48s |  You can rebuild MicroPython from scratch including that mpy that you created it brings it in it kind of
656.24s - 660.64s |  It brings it in as a set of C structures and we'll talk about that in a little bit
660.64s - 666.08s |  But basically it's hard to go back after you've frozen it into the firmware. It's harder to pull it back
666.08s - 671.36s |  It's not just a file on the file system anymore, but you can use it as a Python module just fine
671.92s - 682.70s |  So what can we learn from an mpy file because our goal eventually here is going to be to take that
683.42s - 685.42s |  Frozen module extract it from the firmware
686.06s - 690.54s |  Recreate the mpy so that we can parse it the mpy tool creates
691.30s - 698.90s |  Of the frozen module from the mpy and so the mpy tool that PI code has a lot of
700.30s - 707.62s |  Algorithms and data structures in it for generating this and so it does not generate the the binary that's going to be in the firmware
707.62s - 710.30s |  Directly it generates a set of C code
710.90s - 714.50s |  That's going to get statically linked into the MicroPython firmware
714.86s - 716.02s |  So
716.02s - 721.10s |  And it's less coded and it's just like a whole lot of data structure a whole lot of struts, right?
721.10s - 726.54s |  And those trucks are going to get compiled in and they're going to get arranged by the compiler into memory in
726.78s - 731.18s |  Various places that are not immediately obvious to you from just reading the code
732.02s - 739.22s |  The same tool can be used to dump info about an mpy file with a disassemble flag. So it does have a built-in disassembler
740.22s - 745.46s |  This is the only disassembler you get with MicroPython and it's only pulling from mpy file
745.46s - 750.58s |  so if we get code out of the binary, we're going to need to disassemble it with this tool and
751.22s - 757.66s |  By the way, the byte code for MicroPython is not the same byte code as CPython
758.42s - 761.90s |  It's definitely not the same opcodes. It's many of the same
762.86s - 766.26s |  it's many of the same opcodes with different different values and
767.14s - 776.02s |  Not all of the same opcodes, right so it's a from-scratch implementation if we don't or disassemble
776.54s - 781.74s |  mpy file using the mpy tool we get three main
782.26s - 789.50s |  Things out of we get a string table a module a string table an object table and a set of code
790.74s - 794.58s |  What you're looking at here is the string table and I'm going to talk to you about this this
795.34s - 798.10s |  Interned string format that they have here
799.98s - 801.34s |  For the code
801.34s - 808.38s |  There's two pieces of code if you remember we had a module that defined we defined a module and then we've defined a go
808.46s - 811.18s |  function in it or a hello world function in it and
812.18s - 814.18s |  So you're gonna have two functions
814.94s - 818.46s |  That have byte code. The first one is going to be a constructor and
819.14s - 821.02s |  The next one's gonna be your go function
821.02s - 823.02s |  It actually repeats hello world
823.06s - 828.98s |  Every five seconds and you can see the the byte code in these and it's a stack based language
829.10s - 837.30s |  Basically, you're you're you're constantly loading things out of different data structures putting them on the stack calling other functions
837.62s - 841.14s |  Pushing and popping and looping around and throwing things like that
841.14s - 848.06s |  And so again, if you read up on how a Python byte code works, it would make sense to you
848.46s - 853.02s |  But it's not exactly the same so you can't use like the body of Python
853.26s - 856.50s |  Disassembly tools on this are debugging tools for this
858.54s - 862.66s |  There's a really nice colored output hex dump that you can get with mpy tool
863.10s - 868.66s |  That will sort of tell you what the different parts of that hex dump mean and what what what they are what they have what?
868.66s - 871.66s |  They're about that'll help us when we're trying to recreate one of these
873.62s - 875.62s |  so
875.62s - 880.70s |  If we can rebuild an mpy of a frozen module out of information we extract from firmware
880.70s - 884.14s |  We've got something we you can use to get some work done with it
884.58s - 890.62s |  It'll take some Mario work, but it's not and because it's not there in the contiguous belt binary blob. It's structures
890.62s - 894.14s |  We've got a walk, right? We got to find them in memory and walk them
895.58s - 900.62s |  We have to understand string interning we need to look at the pipe byte code briefly
900.62s - 903.26s |  It does not a I'm gonna be a byte code class or anything
904.42s - 909.38s |  But also another tool that we can use is we can build a version of micro Python
909.50s - 915.10s |  That's the Unix port quote-unquote Unix port it you can build it for Windows Linux or whatever
915.46s - 918.86s |  But it's basically a desktop version of micro Python
919.54s - 925.78s |  That you can that you can build and load mpy files into run them analyze them and do things to where you're not just
925.98s - 929.74s |  Restricted to working on the microcontroller itself when you're doing your reverse engineering
931.34s - 933.34s |  So first off
933.70s - 936.06s |  How are storing our string constants?
936.46s - 943.90s |  We're doing what's called string interning and so this is something that you do on very limited memory
944.22s - 951.22s |  Environments where you want to avoid having the same constant string in memory more than once, right?
951.34s - 953.18s |  You don't want to have
953.18s - 958.98s |  main or something like or some other common string 50 different times in your memory if your
959.26s - 964.30s |  Memory is in on the order of megabytes or kilobytes or something like that, right? And so
965.30s - 971.98s |  My group I micro Python calls these Q strings for unique for unique cook strings
973.02s - 974.02s |  and
974.02s - 981.98s |  Basically Q string values the way you refer to them is is into an index into a linked list of pools of these strings
981.98s - 988.90s |  Right, and so if you're wanting to refer to hello cruel world, or you're wanting to refer to
990.06s - 991.38s |  the the
991.90s - 994.30s |  Open tag module closed tag
995.30s - 1000.46s |  String you're never going to refer to it as a pointer or you'll get a pointer to it
1000.46s - 1007.42s |  but you're going to refer to it as and pass it around as an index into these links link pools and
1008.22s - 1009.22s |  So there's a link
1009.22s - 1015.86s |  There's a set of static ones that are in the make Q string data dot py that's used in the build process of micro Python
1016.74s - 1023.42s |  And those are constant across all your builds of micro Python and then past that in the next pool
1023.70s - 1029.10s |  It's going to be stuff that's varies between each build depending on which frozen modules you include
1029.62s - 1038.63s |  So if you use mpy tool to create frozen code generated from your mpy file
1039.47s - 1044.87s |  It's going to create a strings a string data structure. And so first you've got an enum that has
1045.43s - 1049.03s |  basically, you know, that's going to compile down to one two, three four, basically a
1050.15s - 1053.39s |  Indexing hello cruel world go. Hello world pie
1053.91s - 1056.59s |  Sleep time all those sorts of things
1056.83s - 1062.47s |  Then you're going to have hashes for them like a simple one byte hash and then a link for each of them
1063.27s - 1069.47s |  Those are going to be placed into pools. And so on the right hand side there you see the frozen constant pool
1070.47s - 1075.23s |  That has has those five strings represented in there
1075.51s - 1078.51s |  there's also going to be a link to the previous pool and
1079.39s - 1082.23s |  also a previous pool size, so
1082.91s - 1084.19s |  your
1084.19s - 1086.19s |  Q-string indexes are
1086.43s - 1090.61s |  Global they're globally unique and so you have to look at that previous pool size
1090.87s - 1093.91s |  To know where the indexes start for this pool
1093.91s - 1095.51s |  All the pools are linked together
1095.51s - 1103.67s |  The first constant pool starts at zero and it goes to however many constants there are and then the frozen pool if it's next
1103.99s - 1107.71s |  Starts at that number plus 1 plus 2 plus 3 plus 4 plus 5
1108.39s - 1112.69s |  so
1112.69s - 1116.77s |  And so this is another this is the the Q string table data
1117.73s - 1123.89s |  Here. So now you've got those these defined constants for these and so this is how you refer to
1124.37s - 1128.41s |  The Q strings that you have these are all your indexes defined as constants
1128.93s - 1138.69s |  So the question is how do we find the compiled module and a compiled firmware now if you're lucky they built it with symbols, right?
1138.89s - 1143.33s |  But we're not going to assume we're lucky here. We're going to assume they stripped out that binary information
1143.33s - 1151.01s |  we're going to assume that they stripped out the the symbols and so for me, whatever whenever I see somebody in
1151.85s - 1155.17s |  Compiled code that I'm reverse engineering and they're using
1155.81s - 1160.53s |  An open source module like if in malware if they're using open SSL or they're using
1161.85s - 1167.77s |  Something similar. I'll try to build a copy of that SSL library myself of
1168.29s - 1173.61s |  Alma if as close of a version as I can get and as close to the same options as I can figure for theirs
1173.85s - 1180.37s |  So that I can then use that as sort of a Rosetta Stone for their module that doesn't have symbols, right?
1180.69s - 1184.77s |  Because there's data structures that I want to walk through there. And so that
1185.41s - 1187.57s |  one of the best things that you can do is
1189.73s - 1194.81s |  Build a debug build of micro Python that has a frozen module in it
1194.81s - 1198.61s |  not necessary you don't have their frozen module, but it has a frozen module in it and
1199.21s - 1202.17s |  Use that to get your bearings in the binary, right?
1203.05s - 1209.61s |  Have it loaded the same address and all that sort of thing and then you can have two copies of G drop one side by side
1210.53s - 1217.50s |  And use one to figure out where the data structures are in the other and so in the debug build
1217.86s - 1223.86s |  It's called mp frozen names. The mp frozen names is a list of the frozen modules on the system in
1226.34s - 1228.34s |  your in your
1230.82s - 1237.98s |  Debug build you also have the frozen modules themselves mp frozen mpy content. So you've got
1238.98s - 1241.82s |  There's a lot of sort of built-in frozen modules
1242.62s - 1246.54s |  You'll see like if you have an Adafruit circuit Python
1247.46s - 1250.36s |  Device circuit Python is based on micro Python
1250.82s - 1255.02s |  So circuit Python devices will have other frozen modules in them
1255.02s - 1258.34s |  And you may not necessarily have the source code to them and they'll be in this list
1258.34s - 1265.34s |  I think Lego makes a device that has a microcontroller in it that has
1265.74s - 1270.82s |  Micro Python or circuit Python on it and they also have some of their own closed source libraries
1271.02s - 1275.46s |  That are that are in this as well. And so this is easy mode, right?
1275.46s - 1278.98s |  So we found the list of names of modules we found
1279.54s - 1281.54s |  pointers to the modules themselves
1281.70s - 1286.98s |  But we don't have the names of frozen names and frozen mpy
1287.42s - 1289.82s |  Content in our stripped binary
1289.82s - 1297.10s |  So we have a stripped binary that we copied from a micro controller or we got from an over-the-air update or something like that
1297.62s - 1300.98s |  We've got to find them in a non debug build, right?
1300.98s - 1305.50s |  And so the way we can find them if we if we can ever get to the same things
1305.62s - 1312.98s |  Then we can start using those C data structures from the C files that these things that from the source code of micro Python
1312.98s - 1319.38s |  The source code of other frozen modules. We can start using those to sort of walk it and figure out what's different
1319.94s - 1321.94s |  But we've got to find those data structures first
1323.10s - 1329.06s |  the easiest way to find these two data structures in a non debug build is to
1329.06s - 1332.78s |  Is to one of the easiest ways for this is to just eyeball it
1333.02s - 1339.16s |  You can search for dot PI and just find sort of the list of constants that have dot PI
1340.34s - 1346.38s |  Especially if you know the other frozen modules and the other frozen modules are consistent with the standard micro Python ones
1346.62s - 1353.22s |  You can compare that list and then whatever is additional on there are other additional frozen micro Python modules
1354.10s - 1356.10s |  another a little bit more
1357.58s - 1363.06s |  Resilient way of finding that that doesn't depend on you just sort of eyeballing a binary which I don't mind doing all day
1363.06s - 1364.98s |  But y'all might
1364.98s - 1367.70s |  Is to find it as a code reference
1367.70s - 1374.22s |  and so there's a function that uses that list called MP fine frozen module and
1374.70s - 1382.46s |  Chances are it's going to build in roughly the same location in your debug build as in your is in your stripped build
1383.06s - 1387.74s |  Or you can just search for the code right here. So you have this move load
1389.10s - 1393.18s |  Stroke this move load store combination here using this
1393.82s - 1397.46s |  Address that address is the address to the MP frozen names
1398.10s - 1406.51s |  To find the frozen module content, there's all there you can't really eyeball it because it's all binary content
1407.07s - 1412.03s |  But there's indirect reference in in that same in that same function
1412.03s - 1419.19s |  So if you find those frozen names eyeballing them, you can do a cross reference in gedra to walk back to where
1419.71s - 1427.47s |  MP fine frozen module is and say, okay that matches up with the debug build now later on in that function
1427.51s - 1432.35s |  There's a bit of code that looks like this. This is a reference to the frozen mpy content
1432.35s - 1437.03s |  And so now we have pointers to our mod to the to the base data structures of our modules
1437.03s - 1440.59s |  So from here, it should be fairly simple work
1440.59s - 1443.19s |  Just sort of working through those structures and pulling it out
1443.19s - 1448.99s |  And what we want to do is we want to recreate the hex of that original mpy file
1449.27s - 1452.15s |  So that the rest of the work can be done with mpy tool
1452.63s - 1462.33s |  The header for the mpy file is is a gonna be the same usually you can just take that from any of them
1462.33s - 1467.25s |  And it's not super important as long as you get something that it passes the checks and it goes
1467.77s - 1469.77s |  starts with magic letter M
1470.45s - 1472.93s |  Goes with a major micropython version
1474.41s - 1478.25s |  You want to have you can have so there's a flag in there for or
1479.13s - 1483.81s |  And you can have it per function whether it's native or non-native byte code
1483.81s - 1485.81s |  so you can have
1486.21s - 1488.13s |  you can have
1488.13s - 1492.13s |  mpy module where the actual code of a function is
1493.01s - 1496.13s |  native say arm or MIPS or whatever or
1497.33s - 1500.57s |  Byte you like not byte code machine code, right?
1501.05s - 1506.65s |  Now for my money that would be a lot easier because I can just if I get a pointer to that
1506.85s - 1512.93s |  Like gaedra will will decom disassemble and decompile that for me and I'm and I'm off to the races
1512.93s - 1514.77s |  I don't have to interpret byte code
1514.77s - 1520.21s |  so we're going with what I think is the harder example is if it's actual Python byte code there and
1523.01s - 1524.65s |  then
1524.65s - 1526.65s |  There's a data type that
1527.09s - 1535.05s |  comes up frequently in this called a variably in a variably encoded unsigned integer of V u int and
1535.49s - 1539.73s |  This mean I don't know. Maybe this is more common in microcontrollers than I know
1540.17s - 1543.93s |  but but I had to take a close look at this and basically a
1544.45s - 1545.85s |  This is a
1545.85s - 1547.85s |  variable length integer
1548.49s - 1552.41s |  that for each byte the lower seven bits is
1553.05s - 1556.57s |  Is part of the integer and if there are more bits?
1557.05s - 1560.57s |  Then the eighth bit is set and so if the eighth bit is set then you know
1560.57s - 1560.97s |  Okay
1560.97s - 1566.01s |  I got to read another seven bits from the next byte and so on and so forth and it can be
1566.25s - 1570.57s |  Arbitrarily long right and have a represent an arbitrarily large number
1570.97s - 1573.45s |  However much makes sense on your microcontroller
1573.45s - 1579.45s |  And so this is a data type that that micro Python uses in a lot of its data structures
1579.45s - 1582.97s |  And it can be a little bit of a mind bender to work with
1583.53s - 1587.31s |  so in
1587.31s - 1593.55s |  The hello world dot mpy we have a number of the the intern strings that we want to have in there
1594.23s - 1596.23s |  And we'll see in there
1596.31s - 1603.31s |  We only we only store the actual string data for strings that aren't already in the constant pool
1603.59s - 1608.03s |  So if something's already built into micro Python, we don't redefine that string
1608.03s - 1612.43s |  We just make a reference to it. And so when we're creating our mpy file, we have to be
1613.27s - 1618.67s |  Mindful of which which strings are new essentially which strings are what pool they come from?
1619.19s - 1625.82s |  So frozen module cue strings get mixed together in
1626.34s - 1629.40s |  In a in a in a mpq string
1630.02s - 1631.90s |  Frozen constant pool, right?
1631.90s - 1637.54s |  And so that's one of a few different pools in there that are all in a linked list
1637.82s - 1642.16s |  Where across the linked list there's unique indexes for each string, right?
1642.74s - 1644.74s |  so
1645.10s - 1647.02s |  So to find
1647.02s - 1649.02s |  to find that pool
1649.94s - 1654.86s |  The easiest thing to do is to go through if you can find the main function
1654.86s - 1658.86s |  Which you'd have here new to reverse engineering may be the the tough part
1658.90s - 1664.50s |  But if you can kind of trace through the very beginnings of execution of that binary if you can find main
1665.70s - 1670.70s |  There's MP in it and then cue string in it and in the first four instructions in there
1670.70s - 1674.54s |  There is a reference to the cue string frozen constant pool
1675.06s - 1681.30s |  You can search for a string that you know as part of that module like if you've just run strings on the binary
1681.42s - 1687.02s |  You'll have seen some of it and you can just do cross for cross references back from that if you really want to
1687.58s - 1694.44s |  So so if we're gonna parse these pools, we got to look at the data type for it
1694.44s - 1699.88s |  So a pool has a previous pointer to the previous pool in this linked list of pools
1700.60s - 1704.72s |  you can move backwards in the pools, but not forwards and so
1705.48s - 1707.48s |  That's why that first
1707.68s - 1714.28s |  Those first instructions in that cue string and then refer to the frozen constant pool because that's going to be the last one probably
1715.28s - 1720.68s |  There's a total previous length that you use to figure out where the indexes start in this pool
1721.92s - 1725.32s |  There's a few other fields that don't make a whole lot of difference
1725.32s - 1729.64s |  But at the end you have a list of hash values for the strings
1730.20s - 1734.80s |  You have a list of lengths for the strings and then you have a list of the data, right?
1734.80s - 1738.36s |  And so the string data is just going to be every string can take catenated together
1739.20s - 1743.28s |  solidly with nothing in between because that lengths field in the previous
1744.04s - 1749.04s |  The previous pointer or that that list will tell you the lengths of each of them
1749.04s - 1753.04s |  So you have to parse both of those arrays together to figure out
1754.24s - 1755.96s |  What each string is?
1755.96s - 1760.26s |  so with
1760.30s - 1767.78s |  The previous pool is the previous pool to the frozen pool is the mpq string constant pool the total previous length
1768.06s - 1770.06s |  in our example is
1770.10s - 1771.62s |  3c2
1771.62s - 1776.90s |  So that's where the indexes start for the frozen modules. So any cue string index
1777.94s - 1780.86s |  Greater than is so any cue string greater than
1781.58s - 1786.66s |  962 is going to be in our frozen pool, which means that when we recreate our mpy
1786.90s - 1789.42s |  We're gonna have to include that data into our mpy
1790.30s - 1794.02s |  Anything less than that. We can just include the number and not re encode the string
1794.02s - 1803.25s |  And so there's our list of indexes. And so there's a constant string cue string table data
1804.09s - 1810.41s |  For hello world that you can locate through there and that's the indexes. And so that first one
1811.81s - 1814.41s |  That first one since it's greater than 962
1815.01s - 1822.13s |  We're gonna have to encode that string. Hello world py into our mpy file, but 7 which is just like the open tag module
1822.77s - 1828.65s |  Closed tag is already in the micropython binary. So we just include 7 and we don't re encode it
1829.41s - 1832.41s |  And so this is how it looks when we re encode it
1833.25s - 1839.89s |  This is so we've already written the header, which is those first handful of bytes. The highlighted portion is the string table
1840.89s - 1848.85s |  There's a view in where basically it defines whether or not it's a static entry or one that's defined in this mpy
1848.85s - 1851.09s |  So are we providing it an index?
1851.09s - 1859.40s |  Are we providing it a new string and then the string follows and that's why you see in that dump you see
1859.96s - 1864.48s |  The string data for the new strings, but not the built-in strings
1865.08s - 1874.79s |  So the next thing that you have to do is to build the object table
1874.79s - 1881.71s |  Now this is a more complex data structure and as especially as you get further from hello world
1882.31s - 1887.47s |  This is going to get more and more complicated it the more they're gonna the more they're using
1888.47s - 1895.59s |  Python objects the the the harder this parts going to become but you can like follow through and
1895.91s - 1897.91s |  And recreate these as well
1898.07s - 1904.43s |  Copy really what you can do is you can copy these almost straight out of memory and put them into your binary
1904.43s - 1907.35s |  And it'll just work without you necessarily having to understand them at first
1907.75s - 1914.75s |  Then once you get this thing fully recreated you can load it into that Unix micro Python interpreter and
1915.59s - 1926.82s |  and start probing those objects from the REPL, which is much easier and then finally the bytecode so
1928.50s - 1934.86s |  There's a format that for this code that we have to generate if you look in mpytool.py's code
1935.06s - 1937.30s |  There's a function called read raw code
1937.66s - 1943.06s |  That sort of hints to you as to how we need to build this bytecode so that it can read it
1945.18s - 1949.26s |  So the pointer to the code is the third field of that module and so you see
1949.54s - 1951.82s |  the frozen module hello world there
1951.82s - 1955.22s |  And you see the Q string table the object table
1955.22s - 1961.70s |  And then you see the pointer to the first element of code and that's for the prototype function for this object
1962.18s - 1963.62s |  right and
1963.62s - 1964.82s |  so
1964.82s - 1967.30s |  each each function each
1968.06s - 1971.54s |  Sorry each piece of bytecode can have children so
1972.86s - 1977.34s |  the prototype for this module is going to have a child of
1977.90s - 1980.90s |  the go function that's inside of this module and
1981.34s - 1987.42s |  So it's going to contiguous or continuously rather or parse these elements of code
1987.66s - 1989.82s |  see whether they have children or not and
1990.54s - 1995.82s |  Recursively follow down and once you've part parsed everything that doesn't have children
1995.82s - 2000.58s |  then you can walk back up that recursion and you've parsed all the bytecode out and
2001.50s - 2004.30s |  so on the left there you see the bytecode for
2005.30s - 2006.46s |  for the
2006.46s - 2012.66s |  For the constructor and on the right you see the bytecode for the go function which prints
2012.66s - 2017.94s |  Hello world in a loop basically and so one is the child of the other essentially
2018.38s - 2030.14s |  So reconstructing this there are V u ints for the kind the length and whether or not the code has children
2030.14s - 2032.38s |  So when we're putting this into our mpy binary
2032.38s - 2036.38s |  It needs to know how to reconstruct this into memory in a useful way for the interpreter
2036.38s - 2041.54s |  And so it's using those V u ints to to do this and so there's a kind
2041.86s - 2048.62s |  whether it's bytecode or native code again these things can be compiled down to where it's native arm code for a function and
2049.02s - 2052.10s |  Like I said, if that's the case if you see something code like that
2052.34s - 2059.34s |  Just just drop your cursor and Ghidra or Idapro on that hit disassemble and you're off to the races, right?
2059.34s - 2062.58s |  You can you can read what it's doing a little bit easier
2062.74s - 2068.42s |  But if it's not it's just if it's bytecode Ghidra doesn't have a decoder for this unless you want to write one
2068.42s - 2070.42s |  I didn't want to
2070.78s - 2072.78s |  Kara back there probably will oh
2073.46s - 2075.46s |  and
2076.18s - 2081.18s |  But uh, but if you don't want to write a module to interpret this bytecode
2082.18s - 2087.50s |  You're good. You're gonna be left to pulling it out and dropping it in this file. So the mpy tool can do this for us
2088.26s - 2092.98s |  The third the third bit or is there a child for this block or not?
2092.98s - 2096.94s |  Right, and so that makes it recursively go through and read more code
2097.58s - 2103.06s |  So the one big problem with this and I wanted to write a tool
2103.38s - 2106.54s |  That would just sort of walk through a binary and do this
2107.58s - 2113.06s |  but it's actually tricky to do because the length of the code is not
2114.38s - 2116.06s |  Referenced anywhere, right?
2116.06s - 2120.42s |  The length of the code is defined by the fact that the code never exists
2120.50s - 2124.54s |  Never steps outside of it the the bounds of its memory locations
2124.88s - 2125.98s |  So there's no length
2125.98s - 2132.46s |  it just starts execution there and it'll just keep going as long as there's code and as long as it doesn't return and as long as
2132.82s - 2138.26s |  Looping around it'll just sort of loop in that space. So there's no defined length for it, but which I don't know
2138.26s - 2139.62s |  Maybe you can figure out a problem there
2139.62s - 2141.70s |  Maybe you could exploit that in some way
2141.94s - 2147.50s |  But there's no length and so it's hard in an automated fashion without parsing the bytecode to know the length
2147.70s - 2154.06s |  Of it and so you may have to eyeball that part of it or parse the bytecode yourself kind of trial and error
2155.14s - 2159.14s |  each block of code is followed recursively by its own children and
2160.10s - 2163.42s |  And so here you see in the first screenshot
2163.42s - 2169.66s |  we're encoding those integers and then plopping in the bytecode for the
2170.18s - 2174.98s |  for the for the constructor mod for the constructor for the module and
2175.58s - 2178.90s |  then next since it has a child of the go function and
2179.62s - 2182.18s |  It goes and we go and parse that out
2182.18s - 2187.30s |  We put the V u ints for it in there and then we put the bytecode in for the go function
2188.22s - 2193.18s |  Once you think you've created and at this point like if you take these slides and you go back
2193.42s - 2201.10s |  You'll see that this is bit for bit identical to the original mpy file for the for the hello world dot mpy
2202.70s - 2209.06s |  We can use my Unix port to examine this we can so we can load up the Unix port of micro Python
2209.62s - 2214.58s |  Import that mpy file start looking at the object start looking at the modules
2214.86s - 2219.70s |  Do the dict function to see what functions are available in there. We can call them
2221.06s - 2224.14s |  There is a there is a tracing tool in
2224.94s - 2228.38s |  Or actually, this is not the this the tracing tools in the next slide
2228.94s - 2232.44s |  This is another example that you can just sort of eyeball on your own
2233.22s - 2235.10s |  of a
2235.10s - 2241.70s |  this this code right here will make a little light show on all the GPIO pins of a
2242.22s - 2246.02s |  of a Pico basically just starts strobing all the the
2247.02s - 2252.02s |  GPIO in a pattern if you have a dev board that has LEDs on all the pins
2252.22s - 2254.22s |  It'll do a little neat thing for you
2254.86s - 2256.70s |  That's the code that
2256.70s - 2258.30s |  this is the
2258.30s - 2261.94s |  This is the code that does this but since it's doing GPIO
2263.38s - 2268.74s |  It won't work on the Unix micro Python because it's doing like the pin function and stuff like that
2268.74s - 2272.66s |  You don't have GPIO on the Unix version of micro of micro Python
2272.86s - 2276.82s |  So what you need to do is like if if the code you pull out
2277.58s - 2279.58s |  Uses a function that's not there
2279.58s - 2282.42s |  You're gonna have to implement some sort of stand stand in there
2282.42s - 2286.22s |  And so then you can run it in the Unix port as long as you have those functions available
2286.70s - 2292.93s |  you can build micro Python with sys set trace where you get a trace of
2294.09s - 2297.69s |  Execution. It's not quite what you'd expect. It's not a very detailed trace
2297.69s - 2302.05s |  It basically tells you which portion of the bytecode is executing
2302.65s - 2308.53s |  In a very in a very non-granular fashion. It just basically tells you which function is executing when
2308.97s - 2316.01s |  But you have to build you have to define this when you're building your micro Python binary or your micro Python Unix port
2318.74s - 2320.06s |  the
2320.06s - 2327.66s |  The bytecode itself. This is the hello world bytecode. Basically, you're loading a global object of print the print function
2327.82s - 2335.42s |  You're loading the hello cruel world string you're calling the function you pop the string off the top of the stack
2335.66s - 2341.10s |  You load the global time module you load the method sleep from it you load
2341.62s - 2347.62s |  Some constant integer of five because you want to wait for five seconds you sleep for five seconds by calling the method
2347.94s - 2354.18s |  You pop the top off of that and then you jump back 17 bytes and then you loop around and you do it again
2354.18s - 2358.18s |  And so that's the length. That's the very basics of the language here
2360.54s - 2362.30s |  If you want to learn
2362.30s - 2368.18s |  This bytecode if you really want to take the time to step through bytecode of this and not just sort of interactively do it
2368.70s - 2372.70s |  you'll want to read through the mpy tool opcode class and
2373.58s - 2378.70s |  Also an in class in terms of like the class definition not like a class that you sit down and learn
2379.38s - 2386.88s |  There's a VM dot C and micro Python that has like the VM interpreter for this bytecode in there that you can read as well
2387.14s - 2389.14s |  This is not compatible with CPython
2389.70s - 2396.50s |  But it but familiarity with that would help if you if you read through some Python bytecode tutorials, you'll understand what this is going
2400.31s - 2406.55s |  Conclusions on this I'd really rather be reversing compiled C than this like like using micro Python and like
2407.31s - 2413.43s |  Like like creating bytecode out of your functions and stuff. It's probably a almost a better
2414.39s - 2417.43s |  obfuscation of your code than like
2418.11s - 2421.95s |  Compiling a C firmware for your for your microcontroller
2421.95s - 2424.75s |  It's just annoying right to try to read through this
2424.95s - 2431.19s |  Yourself if you're if you're more used to reading arm assembly if you're more used to reading decompiled C
2432.71s - 2434.71s |  It's doable though, right
2434.99s - 2440.59s |  And if you're if you're really wanting to mess around with with with a device that does this it's doable
2442.51s - 2445.47s |  These frozen modules are a great way to like
2446.07s - 2453.19s |  Include project specific stuff like like really the last stage of your development and deployment of a micro Python firmware
2453.23s - 2457.63s |  Should be to put as many of your modules into this form as possible
2457.83s - 2460.75s |  Because it's just going to save memory and execution time
2461.15s - 2464.71s |  This is not a way to hide or obfuscate code or secrets though
2465.99s - 2472.71s |  Don't use it for that. Especially now that this talk is out and in this room of people know how to do it, right? So
2473.47s - 2479.31s |  Doing don't use this to go screw around with other people's CTFs and ways that ruin the fun for other people
2479.51s - 2484.27s |  But if you if you're like me and you're fun, you make your own fun, right?
2484.55s - 2489.19s |  You don't really follow the rules on the CTF you guys just play around with it not even score any points
2489.31s - 2491.31s |  This this is fun for that
2492.63s - 2496.35s |  It's it's only as well protected as access to your firmware
2497.79s - 2500.99s |  And so if you can dump from flash if you can dump from the ripple
2501.51s - 2505.87s |  If you can grab over the air updates for things you can get at this stuff
2505.91s - 2511.47s |  So it's not a layer of protection and you could probably automate this extraction process
2511.47s - 2516.37s |  But it's a bit tricky to figure out the lengths of some of that some of those data structures, too
2517.47s - 2518.83s |  so
2518.83s - 2523.59s |  one thing that that that you should do if you are
2524.19s - 2530.95s |  interested in this sort of stuff if you like the idea of learning how to use Ghidra to step through the
2531.51s - 2537.47s |  To step through all these data structures if you want to learn how to sort of navigate around code and Ghidra
2538.03s - 2541.99s |  There's a great book from no starch press called the Ghidra book
2542.95s - 2544.79s |  appropriately named
2544.79s - 2551.83s |  By Karen ants and Chris Eagle and Karen answers in our audience here right now and I've been she's been giving me the eye
2552.39s - 2554.23s |  to mention this
2554.23s - 2555.91s |  the whole time
2555.91s - 2561.55s |  She's actually gonna be at the no starch booth this afternoon doing a book signing. I want to say
2562.07s - 2563.43s |  330
2563.43s - 2570.19s |  330 she's gonna be at the at the booth over there. No starch doing book signing go buy that book and get her autograph and
2571.03s - 2577.75s |  And and she knows everything about micro Python frozen modules as well as divert any questions about this talk to her
2578.23s - 2580.23s |  So no
2580.35s - 2585.15s |  Ask ask me the things and so with that I'm gonna close this off
2585.59s - 2591.59s |  I appreciate y'all coming to this instead of pony awards. However poor of a choice that might have been
2592.63s - 2595.55s |  And I look forward to interacting with y'all
2596.27s - 2598.27s |  Thank you


url: https://www.youtube.com/watch?v=TeVGbAkhyzg
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=TeVGbAkhyzg",
  "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=R5nMqju6crY
title: DEF CON 32 - Optical Espionage: Using Lasers to Hear Keystrokes Through Glass Windows - samy kamkar
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=R5nMqju6crY",
  "title": "DEF CON 32 - Optical Espionage: Using Lasers to Hear Keystrokes Through Glass Windows - samy kamkar",
  "description": "Sashay away from this talk with the knowledge to perform state-of-the-art espionage, no technical background required.\n\nIn the realm of privilege escalation and data exfiltration, the physical world quietly screams secrets. We'll demystify the fascinating physics behind signals and how various forms of energy--infrared, visible, and ultraviolet light, radio, ultrasound, audible sound, mechanical vibration, and temperature--can be interpreted as waves that unintentionally leak information, even in air-gapped (non-networked) systems. We'll observe how air is in fact not an effective gap or barrier as radio, light, sound, and vibration excitedly travel through it. We'll explore how all electrical signals radiate electromagnetism (light or radio) that can be intercepted and how we can reverse this process, producing electromagnetism to inject desired electrical signals into our target.\n\nWe'll delve into historical and seminal side-channel/TEMPEST attacks from our friends at the NSA, KGB, and past DEF CON pioneers. You'll learn about the essential electrical and optical components combined for cutting-edge eavesdropping, including what our target is typing from a distance.\n\nWhile others believe they're obtaining noise, we will extract signal, and you'll leave this talk hearing the world in a new light.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2734,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 How's everybody doing?
2.00s - 5.00s |  Okay, I want you to, on three, repeat after me the word engage.
5.00s - 7.00s |  Ready? One, two, three.
7.00s - 8.00s |  Engage.
8.00s - 10.00s |  Engage. One, two, three.
10.00s - 11.00s |  Engage.
11.00s - 14.89s |  Awesome. Here's our speaker, give him a big hand.
14.89s - 20.11s |  Thank you.
20.11s - 24.11s |  It's 1995, I'm ten years old,
24.11s - 28.11s |  and my mom just spent everything she had to get me this computer.
28.11s - 30.11s |  And this is the best day of my life.
30.11s - 33.11s |  I dial up to the internet. Some of you know what that means.
33.11s - 35.11s |  I dial up to my mom's university
35.11s - 38.11s |  and I download MIRC.
38.11s - 41.11s |  I go on to Internet Relay Chat IRC.
41.11s - 42.11s |  Oh no.
42.11s - 45.11s |  And I join a channel and I say,
45.11s - 49.11s |  who wants to chat about the X-Files?
49.11s - 53.11s |  And someone says, get out.
53.11s - 55.11s |  And I didn't understand why.
55.11s - 57.11s |  And I said, we can chat about something else.
57.11s - 59.11s |  What TV show do you like?
59.11s - 63.11s |  And they say, you have ten seconds to get out of this chat room.
63.11s - 66.11s |  And I think, my mom told me, don't tell anyone your name on the internet
66.11s - 68.11s |  and don't tell them where you live.
68.11s - 70.11s |  So they don't know anything about me.
70.11s - 72.11s |  So I say, no.
72.11s - 76.11s |  And this person says, you have ten seconds to get out of this chat room.
76.11s - 77.11s |  I'm like, no.
77.11s - 81.11s |  Ten seconds later, the brand new computer that my mom spent everything on
81.11s - 83.11s |  does this.
83.11s - 85.11s |  It wasn't running CrowdStrike.
85.11s - 88.11s |  This is 1995.
88.11s - 91.11s |  This person just crashed my computer over the internet
91.11s - 93.11s |  without knowing anything about me.
93.11s - 94.11s |  And I freaked out.
94.11s - 96.11s |  I'm going to be grounded for the rest of my life.
96.11s - 99.11s |  I pull all the wires out of the computer.
99.11s - 102.11s |  I wait for the computer to heal.
102.11s - 104.11s |  About half an hour.
104.11s - 106.11s |  I plug the wires back in.
106.11s - 108.11s |  And it comes up.
108.11s - 112.11s |  As it's coming up, everything is okay.
112.11s - 115.11s |  And while the adrenaline is still rushing through my veins,
115.11s - 117.11s |  I think, that is the coolest thing ever.
117.11s - 119.11s |  How do I do that?
119.11s - 122.11s |  And I find this, Winuke95.
122.11s - 126.11s |  So a single out-of-band packet will crash Windows 95.
126.11s - 127.11s |  And this was super cool.
127.11s - 131.11s |  I downloaded this program, and now I'm an elite hacksaw.
131.11s - 134.11s |  And then Microsoft released Windows Service Pack 2,
134.11s - 136.11s |  which resolved this.
136.11s - 138.11s |  And all of a sudden, my magical tool didn't work anymore.
138.11s - 143.11s |  So how do I learn how to create Winuke96?
143.11s - 145.11s |  And that's when I found Frack.
145.11s - 147.11s |  And Frack is a magazine that's still going today.
147.11s - 149.11s |  I believe it started in 85.
149.11s - 152.11s |  And I read, smashing the stack for fun and profit.
152.11s - 155.11s |  And this just blew my mind.
155.11s - 158.11s |  The simplest C program that says, hey, what is your name?
158.11s - 160.11s |  You have to allocate 100 bytes, and you say,
160.11s - 161.11s |  and you type in your name.
161.11s - 163.11s |  And if it doesn't check, and it just prints,
163.11s - 165.11s |  hey, hello, your name,
165.11s - 166.11s |  if you type over that 100 bytes,
166.11s - 168.11s |  and you're not checking for 100 bytes,
168.11s - 169.11s |  you can start overwriting memory,
169.11s - 170.11s |  and then you can overwrite the stack pointer,
170.11s - 172.11s |  and then you can point back to the beginning of your name,
172.11s - 173.11s |  and that can be shell code,
173.11s - 174.11s |  and that can execute code on the computer,
174.11s - 175.11s |  and you can take over a computer
175.11s - 177.11s |  with an extremely simple program.
177.11s - 180.11s |  And that taught me that the way a system works
180.11s - 182.11s |  is not how we think it works.
182.11s - 185.11s |  Like, I want to now understand, what is the ground truth?
185.11s - 186.11s |  How do systems actually work?
186.11s - 188.11s |  How does a computer actually work?
188.11s - 189.11s |  And it's only when you understand
189.11s - 190.11s |  the CPU architecture and memory,
190.11s - 194.11s |  and how, when you're compiling your C code into,
194.11s - 195.11s |  and assembling it, and linking it,
195.11s - 197.11s |  how you can actually take over the system.
197.11s - 200.11s |  And over time, as I've learned from many of you,
200.11s - 202.11s |  and from papers, and from videos,
202.11s - 203.11s |  and just testing things,
203.11s - 206.11s |  that ultimately, everything boils down to energy.
206.11s - 208.11s |  Like, everything is energy.
208.11s - 209.11s |  Information is energy.
209.11s - 213.11s |  By energy, I'm really talking, we're talking power.
213.11s - 215.11s |  Energy is the capacity to do work.
215.11s - 217.11s |  So, to perform some type of work.
217.11s - 220.11s |  Power is the rate at which that work is done.
220.11s - 222.11s |  So, for example, a horsepower.
222.11s - 225.11s |  Like, a horsepower is actually a unit of power.
225.11s - 230.11s |  One horsepower lifts 550 pounds in one second, by one foot.
230.11s - 231.11s |  I looked it up on Wikipedia.
231.11s - 233.11s |  It's actually imperial horsepower.
233.11s - 235.11s |  That means there's also a metric horsepower,
235.11s - 238.11s |  which lifts 542 pounds, slightly less.
238.11s - 241.11s |  I'm not sure what we're feeding our horses.
241.11s - 246.11s |  Probably HGH, horse growth hormone.
246.11s - 248.11s |  So, energy in power.
248.11s - 250.11s |  And I realize, energy is information.
250.11s - 252.11s |  So, if we want to actually move any information around,
252.11s - 254.11s |  we must use energy.
254.11s - 255.11s |  An example of that is,
255.11s - 257.11s |  we think that there's power in data,
257.11s - 258.11s |  but that's not true.
258.11s - 259.11s |  That's not true.
259.11s - 261.11s |  Power is data, and data is power.
261.11s - 263.11s |  If you have a USB 2.0,
263.11s - 265.11s |  you plug your USB in, it doesn't work,
265.11s - 267.11s |  so you plug it in the other way, it doesn't work.
267.11s - 268.11s |  The third time, it always works.
268.11s - 270.11s |  When you plug that in, there are four pins.
270.11s - 272.11s |  There's ground, power, and then two data.
272.11s - 273.11s |  Differential data.
273.11s - 276.11s |  Now, the ground and power, there's energy moving over that.
276.11s - 278.11s |  But there's also information across that.
278.11s - 280.11s |  If you're plugged into a computer that's encrypting something,
280.11s - 282.11s |  there's going to be some information of that encryption
282.11s - 284.11s |  about the amount of power that's being,
284.11s - 286.11s |  and that's going to ride on the power.
286.11s - 289.11s |  The power will actually go up and down just a little bit.
289.11s - 291.11s |  That five volts will move up and down.
291.11s - 292.11s |  You can measure that.
292.11s - 293.11s |  And then there's the data.
293.11s - 294.11s |  Well, how does the data work?
294.11s - 297.11s |  Like, what is actually going across data lines?
297.11s - 298.11s |  That's a voltage.
298.11s - 300.11s |  So there is actually current and voltage,
300.11s - 303.11s |  which is power, pushing through those data lines.
303.11s - 306.11s |  So you can always extract power from this stuff.
306.11s - 309.11s |  And I remember I'm sitting at my computer maybe 15 years ago,
309.11s - 312.11s |  and I had these Dell speakers on my computer,
312.11s - 315.11s |  and I got a text message,
315.11s - 316.11s |  and I was about to get a text message,
316.11s - 318.11s |  and I don't know if many of you recall
318.11s - 320.11s |  that sometimes you get this interference.
320.11s - 321.11s |  You get a text message or a phone call,
321.11s - 322.11s |  and then your speakers go,
322.11s - 324.11s |  do-do-do-do-do-do-do-do-do.
324.11s - 327.11s |  And I was like, wait, my phone's not connected to anything,
327.11s - 330.11s |  yet the speakers are actually playing sound.
330.11s - 332.11s |  Like, there is some sort of interference here.
332.11s - 333.11s |  Could I control that?
333.11s - 335.11s |  Like, if my phone can do that,
335.11s - 337.11s |  so it's not actually the cell towers,
337.11s - 339.11s |  it's actually your phone trying to amplify its signal
339.11s - 340.11s |  and get back to the cell tower.
340.11s - 343.11s |  The cell tower is far away, so it amplifies the signal.
343.11s - 345.11s |  And I thought, okay, well, can I open a keyboard?
345.11s - 347.11s |  Can I look at how the keyboard works?
347.11s - 349.11s |  And if my phone can interfere with the speaker,
349.11s - 351.11s |  can my phone then interfere with the keyboard?
351.11s - 353.11s |  And can I press keystrokes?
353.11s - 355.11s |  So I opened up a keyboard.
355.11s - 356.11s |  It's a USB keyboard.
356.11s - 357.11s |  And when you open it up,
357.11s - 359.11s |  you have a circuit board that's PCB,
359.11s - 360.11s |  your fiberglass,
360.11s - 362.11s |  and then you have all these conductors.
362.11s - 365.11s |  And every conductor going to every key is a unique length,
365.11s - 366.11s |  and they're all copper.
366.11s - 367.11s |  They're all metal.
367.11s - 369.11s |  Any piece of metal is an antenna.
369.11s - 371.11s |  If you measure that antenna, the length of that antenna,
371.11s - 372.11s |  that's a monopole antenna.
372.11s - 374.11s |  That measurement is the wavelength,
374.11s - 375.11s |  the resonant frequency.
375.11s - 377.11s |  So you can figure out the resonant frequency
377.11s - 379.11s |  of every wire going into that.
379.11s - 382.11s |  And I thought, well, can I create an electromagnetic radio
382.11s - 386.11s |  that can then inject keystrokes into this keyboard wirelessly?
386.11s - 388.11s |  And I started to try to do this.
388.11s - 391.11s |  And I started to realize that it's not working.
391.11s - 393.11s |  I tried a couple different software-defined radios
393.11s - 396.11s |  like HackRF and the USRP-B210,
396.11s - 399.11s |  and I was never able to inject all the keystrokes I wanted.
399.11s - 401.11s |  With one keyboard, I was able to inject a few keystrokes.
401.11s - 402.11s |  And I'm like,
402.11s - 404.11s |  I really just don't understand electromagnetism enough.
404.11s - 406.11s |  So I started to learn about physics.
406.11s - 409.11s |  And I started to learn about, well, what is electromagnetism?
409.11s - 412.11s |  It's really light, light and radio.
412.11s - 415.11s |  And I took a picture of a rainbow on a jog.
415.11s - 419.11s |  And really, electromagnetism is light.
419.11s - 423.11s |  We can split that light up into its constituent wavelengths,
423.11s - 425.11s |  and there's all sorts of other frequencies.
425.11s - 427.11s |  So radio, for example, is light.
427.11s - 430.11s |  Radio is just colors of light that we can't see with our eyes.
430.11s - 433.11s |  And as I wanted to learn about this and how this stuff works,
433.11s - 436.11s |  I started learning about light and EM and radio.
436.11s - 438.11s |  And I need to learn physics.
438.11s - 440.11s |  So I started to get some physics books
440.11s - 442.11s |  and start reading about this stuff.
442.11s - 444.11s |  One of those books was Building Scientific Apparatus.
444.11s - 446.11s |  And I learned, okay, well,
446.11s - 448.11s |  a lot of the people who are learning physics,
448.11s - 451.11s |  which is really how hardware works and how radio works,
451.11s - 453.11s |  they started by, like, J.J. Thompson,
453.11s - 455.11s |  who broke the atom open.
455.11s - 458.11s |  Like, it's called the atom from Greek atomos, meaning indivisible.
458.11s - 460.11s |  Until this dude, J.J. Thompson,
460.11s - 462.11s |  put a bunch of atoms inside of a glass tube,
462.11s - 464.11s |  evacuated, pulled almost everything out,
464.11s - 466.11s |  put a high voltage, and then split the atom.
466.11s - 468.11s |  It was divisible.
468.11s - 470.11s |  And then he used magnets, and he could move the atoms
470.11s - 472.11s |  that were producing light.
472.11s - 474.11s |  And that became our cathode ray tube,
474.11s - 476.11s |  our CRT TVs and monitors that we used.
476.11s - 478.11s |  I'm like, this is super cool. I should reproduce this.
478.11s - 480.11s |  So I set up a little glassblowing station at home,
480.11s - 483.11s |  and I tried to blow glass and do some lamp work,
483.11s - 485.11s |  but all my stuff would always break.
485.11s - 487.11s |  I'd make something, and then it would crack.
487.11s - 490.11s |  I'm like, all right, I need to actually learn some glassblowing.
490.11s - 492.11s |  I took some classes in L.A.,
492.11s - 494.11s |  but these are all soft glass.
494.11s - 496.11s |  And I still would come home, and I'd try to make some stuff,
496.11s - 498.11s |  and it would break.
498.11s - 500.11s |  Then I went on the Internet, and I found, okay,
500.11s - 503.11s |  I found this guy who makes all sorts of borosilicate glass,
503.11s - 505.11s |  which is like scientific glassblowing.
505.11s - 507.11s |  And I messaged him, and I messaged everyone,
507.11s - 509.11s |  every other scientific glassblower in Los Angeles.
509.11s - 512.11s |  Hey, I want you to learn how to glassblow.
512.11s - 514.11s |  I will pay you.
514.11s - 516.11s |  Everyone said no. Like, I have a job.
516.11s - 518.11s |  I can't just come to my work.
518.11s - 520.11s |  And that's probably, like, illegal or something.
520.11s - 522.11s |  So I went on LinkedIn, and I searched
522.11s - 524.11s |  more scientific glassblowers across the U.S.,
524.11s - 526.11s |  and I just messaged everyone.
526.11s - 528.11s |  Like, someone has to say yes, right?
528.11s - 530.11s |  Someone will, like, let me pay them for a few hours,
530.11s - 532.11s |  so I can just, and I get a response from Katie.
532.11s - 534.11s |  Hey, I see that you're in L.A.
534.11s - 536.11s |  We're in Milwaukee, Wisconsin.
536.11s - 538.11s |  Is this something that you would travel for?
538.11s - 540.11s |  So a week later, I get,
540.11s - 543.11s |  Delta tickets are very cheap to Wisconsin in winter.
543.11s - 546.11s |  It's because it's freezing in Wisconsin in the winter.
546.11s - 548.11s |  It's so cold.
548.11s - 550.11s |  I show up to this place, and I say,
550.11s - 552.11s |  is Katie here?
552.11s - 554.11s |  And an old woman answers the door and says,
554.11s - 556.11s |  there's no one here by that name.
556.11s - 558.11s |  I'm like, what?
558.11s - 560.11s |  Did I just get pwned by someone that I reached out to?
560.11s - 562.11s |  Because I put a deposit.
562.11s - 564.11s |  I flew from Los Angeles to Wisconsin,
564.11s - 566.11s |  and I'm just standing. I'm cold. I'm uncomfortable.
566.11s - 568.11s |  And the person that I paid is not here.
568.11s - 570.11s |  I look at my email.
570.11s - 572.11s |  We never contacted, we never called each other.
572.11s - 574.11s |  We just, like, chatted on LinkedIn.
574.11s - 576.11s |  And then I found her phone number. I call her.
576.11s - 578.11s |  It says, oh, I'm sorry. I switched the numbers.
578.11s - 580.11s |  Fortunately, she was down the street.
580.11s - 582.11s |  I walk down the street.
582.11s - 584.11s |  We go into Ian's glassblowing station.
584.11s - 586.11s |  So Ian and Katie are these two scientific glassblowers
586.11s - 588.11s |  that work for a big science company out,
588.11s - 590.11s |  excuse me, in Wisconsin.
590.11s - 592.11s |  And I go into their shop.
592.11s - 594.11s |  They show me their glassblowing lathe, their fume hood.
594.11s - 596.11s |  Here's Ian showing me
596.11s - 598.11s |  a lighter that he made.
598.11s - 600.11s |  Katie with her lightsaber.
600.11s - 602.11s |  That's fire.
602.11s - 604.11s |  If you ever want to learn how to glassblow
604.11s - 606.11s |  and you're in Wisconsin, you can email them, contact them.
606.11s - 608.11s |  And I came back learning a little bit more
608.11s - 610.11s |  about how to actually...
610.11s - 612.11s |  You wanted a pic?
612.11s - 614.11s |  I wanted a...
614.11s - 616.11s |  I came back home able to actually
616.11s - 618.11s |  blow a little bit more borosilicate glass,
618.11s - 620.11s |  which is great.
620.11s - 622.11s |  And when I came home, I was very excited,
622.11s - 624.11s |  and I started to reproduce some of these.
624.11s - 626.11s |  And I started to learn more about physics
626.11s - 628.11s |  and more about waves.
628.11s - 630.11s |  And one of the biggest realizations,
630.11s - 632.11s |  one of the most helpful realizations for me
632.11s - 634.11s |  is that I don't...
634.11s - 636.11s |  It's very difficult for me to understand complex things.
636.11s - 638.11s |  I don't understand complex things.
638.11s - 640.11s |  I can only understand simple things.
640.11s - 642.11s |  But I can take simple things and build
642.11s - 644.11s |  a simple thing into a module, a block,
644.11s - 646.11s |  and then use that block with another simple block
646.11s - 648.11s |  and then build stuff on top of that, right?
648.11s - 650.11s |  And if I can find patterns,
650.11s - 652.11s |  then that makes my life much easier.
652.11s - 654.11s |  I can just learn an abstract concept
654.11s - 656.11s |  of what X, Y, and Z are
656.11s - 658.11s |  if they're the same.
658.11s - 660.11s |  And we can interpret everything as waves,
660.11s - 662.11s |  as analog signals.
662.11s - 664.11s |  So a wave has three things that are important.
664.11s - 666.11s |  Now, when I say waves, light is a wave.
666.11s - 668.11s |  Sound is a wave.
668.11s - 670.11s |  Water waves are waves.
670.11s - 672.11s |  They all have the same properties.
672.11s - 674.11s |  They have absorption, where they absorb
674.11s - 676.11s |  and convert from one type of energy to another energy.
676.11s - 678.11s |  They have reflection.
678.11s - 680.11s |  They have refraction and diffraction.
680.11s - 682.11s |  A wave has three things.
682.11s - 684.11s |  There's the amplitude.
684.11s - 686.11s |  Amplitude means intensity.
686.11s - 688.11s |  So the sound would be how loud it is.
688.11s - 690.11s |  That's the amplitude.
690.11s - 692.11s |  With light, that's how bright it is.
692.11s - 694.11s |  Then there's the wavelength,
694.11s - 696.11s |  which directly relates to frequency.
696.11s - 698.11s |  So a low-frequency light would be red light.
698.11s - 700.11s |  A high-frequency light would be blue light or UV light.
700.11s - 702.11s |  With sound, low-frequency is bass.
702.11s - 704.11s |  High-frequency is higher sounds.
704.11s - 706.11s |  And there's phase, which is where something is
706.11s - 708.11s |  in its amplitude
708.11s - 710.11s |  because amplitude is moving up and down.
710.11s - 712.11s |  When we're dealing with computers,
712.11s - 714.11s |  we're digitizing things.
714.11s - 716.11s |  We're quantizing, which just means
716.11s - 718.11s |  our microphone, when I'm recording
718.11s - 720.11s |  my Metallica CDs,
720.11s - 722.11s |  or I'm backing up
722.11s - 724.11s |  my Metallica audio, of course,
724.11s - 726.11s |  I go into my microphone, let's say,
726.11s - 728.11s |  and that has a sample rate.
728.11s - 730.11s |  The sample rate is the number of times per second
730.11s - 732.11s |  I record, or a frame rate.
732.11s - 734.11s |  When you're taking a video,
734.11s - 736.11s |  if it's 30 frames per second, that's a sample rate.
736.11s - 738.11s |  If it's 30 hertz, 30 times per second.
738.11s - 740.11s |  And the bit rate, that's the depth.
740.11s - 742.11s |  So that's how much quality or resolution we have.
742.11s - 744.11s |  And these are really important factors.
744.11s - 746.11s |  Also, waves can do
746.11s - 748.11s |  very interesting things like interference.
748.11s - 750.11s |  So with interference, we can
750.11s - 752.11s |  do
752.11s - 754.11s |  constructive and destructive interference.
754.11s - 756.11s |  So your sound-canceling headphones,
756.11s - 758.11s |  when you put those on, they have microphones
758.11s - 760.11s |  on the outside, so that when you're listening
760.11s - 762.11s |  to the Metallica that you ripped,
762.11s - 764.11s |  you hear the
764.11s - 766.11s |  outside sound, and the microphone
766.11s - 768.11s |  takes that outside sound and it inverts the wave.
768.11s - 770.11s |  And then it plays it along with Metallica.
770.11s - 772.11s |  And those two cancel out.
772.11s - 774.11s |  Just like a water wave, with a high peak,
774.11s - 776.11s |  high amplitude, and a low amplitude.
776.11s - 778.11s |  If they hit, they will cancel out.
778.11s - 780.11s |  So that's destructive interference.
780.11s - 782.11s |  There's many other places online and on the
782.11s - 784.11s |  internet where you can get free tools
784.11s - 786.11s |  to learn about physics,
786.11s - 788.11s |  such as Veritasium's
788.11s - 790.11s |  channel. So Veritasium
790.11s - 792.11s |  has amazing videos on physics,
792.11s - 794.11s |  and there's so many interesting attacks
794.11s - 796.11s |  that we can do with light.
796.11s - 798.11s |  Here's Newton
798.11s - 800.11s |  actually designing the cover for Pink Floyd's
800.11s - 802.11s |  album, Dark Side of the Moon.
802.11s - 804.11s |  I always thought that it was
804.11s - 806.11s |  white light going to the prism and then refracting
806.11s - 808.11s |  into the rainbow, but we're reverse engineers,
808.11s - 810.11s |  so how do we know
810.11s - 812.11s |  it's the white light going in versus the
812.11s - 814.11s |  rainbow going to the prism and converting to white
814.11s - 816.11s |  light? We don't really know. That's an interesting
816.11s - 818.11s |  property of physics, is that physics,
818.11s - 820.11s |  almost everything works in reverse
820.11s - 822.11s |  as well. If you have a speaker,
822.11s - 824.11s |  then you're playing sound through that speaker.
824.11s - 826.11s |  If you have voltage going into the speaker,
826.11s - 828.11s |  that's electrons
828.11s - 830.11s |  moving through a coil.
830.11s - 832.11s |  Any moving charged particle
832.11s - 834.11s |  has a magnetic field.
834.11s - 836.11s |  That magnetic field is pushing the speaker cone
836.11s - 838.11s |  back and forth. That speaker cone
838.11s - 840.11s |  is then pushing air back and forth.
840.11s - 842.11s |  That's what the sound is. The sound is the movement
842.11s - 844.11s |  of matter.
844.11s - 846.11s |  The reverse is true as well.
846.11s - 848.11s |  If you have a speaker, and you have
848.11s - 850.11s |  air moving the speaker cone
850.11s - 852.11s |  because the speaker's not on, then the speaker
852.11s - 854.11s |  is also pushing
854.11s - 856.11s |  electrons back and forth, which then
856.11s - 858.11s |  produces a voltage in the coil.
858.11s - 860.11s |  Every speaker is a microphone.
860.11s - 862.11s |  Every microphone is also a speaker.
862.11s - 864.11s |  There are really poor quality versions, but it's true.
864.11s - 866.11s |  This is true with LEDs, for example.
866.11s - 868.11s |  Every LED can shine light,
868.11s - 870.11s |  but if you monitor the LED,
870.11s - 872.11s |  you can actually have the light convert to voltage,
872.11s - 874.11s |  and you can read light from an LED.
874.11s - 876.11s |  Everything works in reverse.
876.11s - 878.11s |  It's an important property.
878.11s - 880.11s |  These are ways that we can take advantage of
880.11s - 882.11s |  energy and energy conversion
882.11s - 884.11s |  and the way that things actually work at a fundamental level.
884.11s - 886.11s |  Here is a little bit of
886.11s - 888.11s |  the electromagnetic spectrum. We can see the different
888.11s - 890.11s |  colors, but it's also important to note
890.11s - 892.11s |  that, again, things like UV and IR, those are
892.11s - 894.11s |  light. Radio is also just another
894.11s - 896.11s |  type of light. It's just light we can't see.
896.11s - 898.11s |  It's colors we can't see.
898.11s - 900.11s |  FM radio. FM radio
900.11s - 902.11s |  is frequency modulation.
902.11s - 904.11s |  When you tune into 102.7,
904.11s - 906.11s |  you're listening to 102.7
906.11s - 908.11s |  megahertz on the electromagnetic
908.11s - 910.11s |  spectrum.
910.11s - 912.11s |  Now the frequency is modulating.
912.11s - 914.11s |  All that means is when there's
914.11s - 916.11s |  audio, if you have a 10 kilohertz tone,
916.11s - 918.11s |  it's a high-pitched tone,
918.11s - 920.11s |  that's 102.71.
920.11s - 922.11s |  102.7
922.11s - 924.11s |  megahertz plus 10 kilohertz.
924.11s - 926.11s |  Your frequency
926.11s - 928.11s |  is actually just moving up and down at 10 kilohertz.
928.11s - 930.11s |  You can think of an audio
930.11s - 932.11s |  wave going like this. If we just flip it
932.11s - 934.11s |  90 degrees, then it's actually going
934.11s - 936.11s |  like this, the frequency of the
936.11s - 938.11s |  spectrum. Amplitude modulation,
938.11s - 940.11s |  AM radio, when you listen to 98.7
940.11s - 942.11s |  AM, that's 98.7
942.11s - 944.11s |  kilohertz in the electromagnetic spectrum.
944.11s - 946.11s |  The amplitude is going up and down
946.11s - 948.11s |  to the sound.
948.11s - 950.11s |  You can do some really cool things with light. There's the light
950.11s - 952.11s |  commands research that people did where
952.11s - 954.11s |  they found that if they shine a laser
954.11s - 956.11s |  at something like a
956.11s - 958.11s |  Google Home, they can
958.11s - 960.11s |  say, hey Google, with light.
960.11s - 962.11s |  They just modulate the light.
962.11s - 964.11s |  They turn it on and off. Modulation
964.11s - 966.11s |  just means turning on and off or oscillating.
966.11s - 968.11s |  They turn it on and off to the frequency
968.11s - 970.11s |  of sound. If they record
970.11s - 972.11s |  their sound, hey Google,
972.11s - 974.11s |  unlock my door, and they
974.11s - 976.11s |  turn that light, that light hitting the
976.11s - 978.11s |  microphone is heating up. It's absorbing
978.11s - 980.11s |  inside of the microphone, the MEMS microphone,
980.11s - 982.11s |  and that produces heat. Heat
982.11s - 984.11s |  is vibration of particles.
984.11s - 986.11s |  That microphone then believes that it's hearing
986.11s - 988.11s |  sound. That means you can shine
988.11s - 990.11s |  through a window and trigger
990.11s - 992.11s |  the Google Home to do things for you.
992.11s - 994.11s |  There's also infrared light.
994.11s - 996.11s |  This is a Mark Rober did a
996.11s - 998.11s |  video showing just a thermal camera
998.11s - 1000.11s |  where he then pressed a pin
1000.11s - 1002.11s |  and heat is constantly transferring.
1002.11s - 1004.11s |  Just by touching these
1004.11s - 1006.11s |  buttons, heat from his finger goes to the
1006.11s - 1008.11s |  button and then leaves a mark. We don't
1008.11s - 1010.11s |  see it with our eyes, but with a thermal camera like a
1010.11s - 1012.11s |  FLIR camera, you can do that. Ultraviolet.
1012.11s - 1014.11s |  Ultra from Latin
1014.11s - 1016.11s |  meaning beyond, on the far side of.
1016.11s - 1018.11s |  On the far side of the visible spectrum.
1018.11s - 1020.11s |  Bunny did an amazing example with
1020.11s - 1022.11s |  ultraviolet light where he took a PIC
1022.11s - 1024.11s |  microcontroller that had firmware that he wanted to extract.
1024.11s - 1026.11s |  But the PIC microcontroller had
1026.11s - 1028.11s |  an E-fuse, an electronic fuse that said
1028.11s - 1030.11s |  do not allow anyone to debug and access
1030.11s - 1032.11s |  memory from this. And he opened it up,
1032.11s - 1034.11s |  he used nitric acid, sulfuric acid
1034.11s - 1036.11s |  to get to the silicon.
1036.11s - 1038.11s |  He covered up the area other than
1038.11s - 1040.11s |  the electronic fuses and then he shined
1040.11s - 1042.11s |  UV light which erased it.
1042.11s - 1044.11s |  That's how programmable read-only memory used to work.
1044.11s - 1046.11s |  We would shine UV light to erase it
1046.11s - 1048.11s |  and then we could program it.
1048.11s - 1050.11s |  Then there's radio, which again
1050.11s - 1052.11s |  is just another part of the spectrum. We talked about FM
1052.11s - 1054.11s |  a little bit. We talked about AM.
1054.11s - 1056.11s |  We're all familiar with, say, 2.4 GHz Wi-Fi
1056.11s - 1058.11s |  or Bluetooth. 5 GHz
1058.11s - 1060.11s |  Wi-Fi. Our microwaves, the microwave
1060.11s - 1062.11s |  that you make popcorn at home, that's
1062.11s - 1064.11s |  actually 2.4 GHz. Microwaves
1064.11s - 1066.11s |  and radio are the same exact thing.
1066.11s - 1068.11s |  There's the Tempest attack.
1068.11s - 1070.11s |  The NSA found in the 60s,
1070.11s - 1072.11s |  they knew that a CRT monitor, a cathode
1072.11s - 1074.11s |  ray tube, would constantly
1074.11s - 1076.11s |  emit radio frequency.
1076.11s - 1078.11s |  That radio frequency,
1078.11s - 1080.11s |  they could hear in an adjacent room.
1080.11s - 1082.11s |  They could essentially listen
1082.11s - 1084.11s |  to the radio frequency and see what's on the monitor.
1084.11s - 1086.11s |  There are modern attacks like this
1086.11s - 1088.11s |  today that are happening.
1088.11s - 1090.11s |  We talked a little bit about the AM and FM.
1090.11s - 1092.11s |  Then electromagnetism.
1092.11s - 1094.11s |  Electro from amber.
1094.11s - 1096.11s |  The Greeks found that when you rub amber
1096.11s - 1098.11s |  with something like fur,
1098.11s - 1100.11s |  they would attract or repel.
1100.11s - 1102.11s |  And magnetism
1102.11s - 1104.11s |  from magnesium stone. Because there's a
1104.11s - 1106.11s |  place called Magnesia where they found stone
1106.11s - 1108.11s |  and the stone was attracted to other magnesium
1108.11s - 1110.11s |  stones, we realized later, as magnetism.
1110.11s - 1112.11s |  This was an example project
1112.11s - 1114.11s |  a few years ago called MagSpoop.
1114.11s - 1116.11s |  I was interested in how the mag stripes actually work
1116.11s - 1118.11s |  within our credit cards.
1118.11s - 1120.11s |  And I put
1120.11s - 1122.11s |  my credit card inside of iron oxide
1122.11s - 1124.11s |  filings. And you can
1124.11s - 1126.11s |  actually read the ones and zeros off of my
1126.11s - 1128.11s |  credit card. I'm not even sure why I put the
1128.11s - 1130.11s |  electrical tape, because you can just read the credit card
1130.11s - 1132.11s |  number off the bits at the top.
1132.11s - 1134.11s |  I thought, what are all these numbers?
1134.11s - 1136.11s |  It's a credit card number. There's a CVV.
1136.11s - 1138.11s |  There's actually a separate CVV. There's a written one
1138.11s - 1140.11s |  and there's one in the mag stripe. Now we think,
1140.11s - 1142.11s |  who uses mag stripes? We all use chip or
1142.11s - 1144.11s |  NFC. But have you ever put your
1144.11s - 1146.11s |  credit card in a mag stripe machine?
1146.11s - 1148.11s |  It's like, hey, this is a chip card.
1148.11s - 1150.11s |  How does it know that it's a chip card?
1150.11s - 1152.11s |  The mag stripe tells it. The mag stripe
1152.11s - 1154.11s |  says, no, this is a chip card. You need higher security.
1154.11s - 1156.11s |  So what happens if you turn that one to a
1156.11s - 1158.11s |  zero and say, no, no, no, there's no chip on here.
1158.11s - 1160.11s |  There's no NFC.
1160.11s - 1162.11s |  This is the device.
1162.11s - 1164.11s |  This is the MagSmooth device, and it just
1164.11s - 1166.11s |  produces a magnetic field.
1166.11s - 1168.11s |  And if you
1168.11s - 1170.11s |  turn, I use the chip card, I put
1170.11s - 1172.11s |  the mag stripe data onto this
1172.11s - 1174.11s |  and was then able to
1174.11s - 1176.11s |  make transactions without the chip.
1176.11s - 1178.11s |  So if you just have access
1178.11s - 1180.11s |  to a mag stripe temporarily, you can then convert
1180.11s - 1182.11s |  the chip to a non-chip card.
1182.11s - 1184.11s |  There are some other interesting attacks.
1184.11s - 1186.11s |  There's sound.
1186.11s - 1188.11s |  There's so many interesting things that we can do with sound.
1188.11s - 1190.11s |  There's audible sound, which is what humans can hear.
1190.11s - 1192.11s |  We can hear 20 to 20 kilohertz.
1192.11s - 1194.11s |  I'm a little older.
1194.11s - 1196.11s |  I can maybe hear to 15 kilohertz.
1196.11s - 1198.11s |  If you listen to a lot of music,
1198.11s - 1200.11s |  you probably hear less.
1200.11s - 1202.11s |  Berkeley had some amazing research where they used
1202.11s - 1204.11s |  a microphone to listen to
1204.11s - 1206.11s |  the sound from a keyboard.
1206.11s - 1208.11s |  And there's a lot of research that I was able to
1208.11s - 1210.11s |  fortunately take advantage of
1210.11s - 1212.11s |  in using other people's tools and research
1212.11s - 1214.11s |  to learn how can I understand
1214.11s - 1216.11s |  what's happening on a keyboard.
1216.11s - 1218.11s |  There's something really interesting about all the information
1218.11s - 1220.11s |  that we are constantly inputting.
1220.11s - 1222.11s |  Maybe that's because I'm on a computer every single day typing.
1222.11s - 1224.11s |  I think it's cool to know that
1224.11s - 1226.11s |  what am I typing? What can someone figure out
1226.11s - 1228.11s |  what someone else is typing?
1228.11s - 1230.11s |  And they were able to just
1230.11s - 1232.11s |  have a microphone listen to what the sound
1232.11s - 1234.11s |  your computer is making and convert that back.
1234.11s - 1236.11s |  Two keys.
1236.11s - 1238.11s |  Ultrasound. Again,
1238.11s - 1240.11s |  ultra on the far side of.
1240.11s - 1242.11s |  The University of Tel Aviv
1242.11s - 1244.11s |  had some awesome research where they were using
1244.11s - 1246.11s |  a microphone from a standard
1246.11s - 1248.11s |  cell phone and they would listen to
1248.11s - 1250.11s |  the ultrasound coming from your computer.
1250.11s - 1252.11s |  As your computer is performing encryption operation,
1252.11s - 1254.11s |  let's say it's using RSA.
1254.11s - 1256.11s |  RSA, if you're encrypting a 1-bit versus 0-bit,
1256.11s - 1258.11s |  it takes different operations. It might do a
1258.11s - 1260.11s |  multiplication followed by a modular or an exponent
1260.11s - 1262.11s |  followed by a modular versus a multiplication.
1262.11s - 1264.11s |  And because of those different operations
1264.11s - 1266.11s |  take different amounts of power, that's different amounts
1266.11s - 1268.11s |  of power going through capacitors
1268.11s - 1270.11s |  and inductors of the CPU.
1270.11s - 1272.11s |  Those capacitors and inductors are producing
1272.11s - 1274.11s |  all these charged particles,
1274.11s - 1276.11s |  all these electrons moving, it's producing magnetism.
1276.11s - 1278.11s |  That magnetism is then moving things
1278.11s - 1280.11s |  on your CPU. So these actual
1280.11s - 1282.11s |  caps are moving within
1282.11s - 1284.11s |  your CPU and they're producing ultrasound
1284.11s - 1286.11s |  because they're moving at a frequency
1286.11s - 1288.11s |  higher than we can hear, above 20 kHz.
1288.11s - 1290.11s |  So if you can hear that with a microphone
1290.11s - 1292.11s |  in a lab environment, then you can
1292.11s - 1294.11s |  convert that back to 1s and 0s and extract
1294.11s - 1296.11s |  secret keys. Pretty amazing
1296.11s - 1298.11s |  stuff. All of this is really just
1298.11s - 1300.11s |  energy conversion. Everything that's happening
1300.11s - 1302.11s |  is a conversion of energy
1302.11s - 1304.11s |  and that's really interesting.
1304.11s - 1306.11s |  So how can we take advantage of energy conversion?
1306.11s - 1310.32s |  And I started to get interested
1310.32s - 1312.32s |  in laser microphones.
1312.32s - 1314.32s |  So I saw a talk 15 years ago here
1314.32s - 1316.32s |  at DEF CON and it was
1316.32s - 1318.32s |  incredible. It was about
1318.32s - 1320.32s |  how to use a laser microphone.
1320.32s - 1322.32s |  The first laser microphone, not really
1322.32s - 1324.32s |  a laser microphone, was really
1324.32s - 1326.32s |  a microphone that was, let's say,
1326.32s - 1328.32s |  passive.
1328.32s - 1330.32s |  It was from Leon Theremin.
1330.32s - 1332.32s |  If you're familiar with the Theremin instrument,
1332.32s - 1334.32s |  Leon Theremin
1334.32s - 1336.32s |  created this Theremin instrument. He was an engineer
1336.32s - 1338.32s |  and physicist. He also created something called
1338.32s - 1340.32s |  The Thing.
1340.32s - 1342.32s |  And he gave this to our friends at the KGB.
1342.32s - 1344.32s |  And The Thing was a passive
1344.32s - 1346.32s |  device. Many of us are familiar
1346.32s - 1348.32s |  with RFID devices. They're passive cards
1348.32s - 1350.32s |  and they go into a field,
1350.32s - 1352.32s |  an RFID field from, say, a reader.
1352.32s - 1354.32s |  And that reader emanates radio.
1354.32s - 1356.32s |  And that energizes the card. The card now has
1356.32s - 1358.32s |  enough power that it can run a little processor
1358.32s - 1360.32s |  and respond. Once it gets back,
1360.32s - 1362.32s |  this was the first implementation of RFID.
1362.32s - 1364.32s |  And instead of a card
1364.32s - 1366.32s |  with an ID, he put in
1366.32s - 1368.32s |  a microphone. And that microphone
1368.32s - 1370.32s |  then went into a seal. And this
1370.32s - 1372.32s |  was a gift that the Soviet Union
1372.32s - 1374.32s |  gave to the U.S. ambassador in
1374.32s - 1376.32s |  1945.
1376.32s - 1378.32s |  They put that. No battery,
1378.32s - 1380.32s |  right? No battery at all.
1380.32s - 1382.32s |  Because Leon Theremin realized
1382.32s - 1384.32s |  that he could passively power things.
1384.32s - 1386.32s |  He could power things from far and then get
1386.32s - 1388.32s |  information back.
1388.32s - 1390.32s |  It was many years before the U.S.
1390.32s - 1392.32s |  realized that there was a microphone.
1392.32s - 1394.32s |  Whenever that they were being powered from the outside,
1394.32s - 1396.32s |  they could get audio back.
1396.32s - 1398.32s |  Now, laser microphones is
1398.32s - 1400.32s |  a way of using light in order
1400.32s - 1402.32s |  to listen to sound.
1402.32s - 1404.32s |  So if I can shine a light at a window,
1404.32s - 1406.32s |  and the window, now sound.
1406.32s - 1408.32s |  Sound is the vibration
1408.32s - 1410.32s |  of matter. Typically air, right?
1410.32s - 1412.32s |  You can have sound go through
1412.32s - 1414.32s |  solid materials.
1414.32s - 1416.32s |  You can have sound go through water, liquids.
1416.32s - 1418.32s |  And you don't actually need a laser.
1418.32s - 1420.32s |  You just need light.
1420.32s - 1422.32s |  And the light can be visible or invisible,
1422.32s - 1424.32s |  as long as we have a way to receive it.
1424.32s - 1426.32s |  So it was this talk,
1426.32s - 1428.32s |  Sniffing Keystrokes with Lasers and Voltmeters,
1428.32s - 1430.32s |  by Andrea Barassani and
1430.32s - 1432.32s |  Danielle Bianco,
1432.32s - 1434.32s |  at DEFCON 17.
1434.32s - 1436.32s |  And this really blew my mind.
1436.32s - 1438.32s |  What they were able to do was they were able to
1438.32s - 1440.32s |  get laser at a reflective part
1440.32s - 1442.32s |  of a laptop within a room,
1442.32s - 1444.32s |  and then pick up the reflection
1444.32s - 1446.32s |  on a photodiode
1446.32s - 1448.32s |  or photoresistor. And they picked it up,
1448.32s - 1450.32s |  they plugged that into their sound card,
1450.32s - 1452.32s |  and they were able to listen to the keystrokes.
1452.32s - 1454.32s |  Now, it took a lot of work.
1454.32s - 1456.32s |  Definitely a proof of concept,
1456.32s - 1458.32s |  but absolutely incredible.
1458.32s - 1460.32s |  And I've always been interested in these keyboards.
1460.32s - 1462.32s |  A few years ago, I had released a project called
1462.32s - 1464.32s |  Keysweeper. Keysweeper is just
1464.32s - 1466.32s |  an Arduino-based device
1466.32s - 1468.32s |  that's inside of a USB charger.
1468.32s - 1470.32s |  You plug the USB charger into the wall,
1470.32s - 1472.32s |  and it's just sniffing every Microsoft wireless keyboard
1472.32s - 1474.32s |  in the vicinity. It also has a GSM chip,
1474.32s - 1476.32s |  so it's actually connected to a cell phone network.
1476.32s - 1478.32s |  It has a battery inside, so if it gets pulled out,
1478.32s - 1480.32s |  it continues to operate. And then you can
1480.32s - 1482.32s |  inject keystrokes, and you can listen to all
1482.32s - 1484.32s |  keyboards in the vicinity.
1484.32s - 1486.32s |  Fortunately, the FBI released a notice to the
1486.32s - 1488.32s |  industry saying, watch out for these Keysweeper devices.
1488.32s - 1490.32s |  And I read that someone sent that
1490.32s - 1492.32s |  to me, and I read it said,
1492.32s - 1494.32s |  limit which outlets are available for device charging.
1494.32s - 1496.32s |  Some suggestions just for all of us.
1496.32s - 1498.32s |  Know which chargers are
1498.32s - 1500.32s |  currently being used. Immediately
1500.32s - 1502.32s |  remove unknown chargers
1502.32s - 1504.32s |  whenever you see them. I don't think
1504.32s - 1506.32s |  they realize that it's really just the circuitry
1506.32s - 1508.32s |  inside the charger. The charger was just to be clandestine.
1508.32s - 1510.32s |  So you could put it
1510.32s - 1512.32s |  in a banana, at which point you would
1512.32s - 1514.32s |  have to limit which bananas are available for device.
1514.32s - 1516.32s |  You have to know whose bananas are
1516.32s - 1518.32s |  currently being used, and immediate removal of
1518.32s - 1520.32s |  any unknown bananas from the
1520.32s - 1522.32s |  office. So beware of bananas and USB
1522.32s - 1524.32s |  chargers. But keystrokes.
1524.32s - 1526.32s |  So these guys demonstrated
1526.32s - 1528.32s |  the components that they used.
1528.32s - 1530.32s |  Common laser, like off-the-shelf laser,
1530.32s - 1532.32s |  resistor, or battery.
1532.32s - 1534.32s |  And this was their schematic.
1534.32s - 1536.32s |  So what they did was, they had the laser
1536.32s - 1538.32s |  hit a laptop,
1538.32s - 1540.32s |  it would reflect off the laptop, and
1540.32s - 1542.32s |  then it would go into a photodiode
1542.32s - 1544.32s |  or photoresistor. They would power that,
1544.32s - 1546.32s |  and they would go into the microphone. And the reason for the microphone
1546.32s - 1548.32s |  is that that's an analog-to-digital converter.
1548.32s - 1550.32s |  That can convert the actual light waves.
1550.32s - 1552.32s |  So the photodiode converts the light waves
1552.32s - 1554.32s |  to electricity.
1554.32s - 1556.32s |  And that electricity is still a wave.
1556.32s - 1558.32s |  It's just like our AC. So our AC
1558.32s - 1560.32s |  that's producing 120 volts
1560.32s - 1562.32s |  RMS voltage in the
1562.32s - 1564.32s |  wall, that's traveling at
1564.32s - 1566.32s |  60 hertz. 60 times per second is moving
1566.32s - 1568.32s |  up and down.
1568.32s - 1570.32s |  And you can actually
1570.32s - 1572.32s |  take advantage of that.
1572.32s - 1574.32s |  I was curious, actually,
1574.32s - 1576.32s |  whether it really was 60 hertz.
1576.32s - 1578.32s |  So I had
1578.32s - 1580.32s |  connected a transformer
1580.32s - 1582.32s |  to my AC line, and converted that
1582.32s - 1584.32s |  120 volts down to 12 volts. And then I
1584.32s - 1586.32s |  measured the zero crossing every time it would cross zero.
1586.32s - 1588.32s |  Because I was curious, it says 60 hertz.
1588.32s - 1590.32s |  Does that actually mean 60 times per second?
1590.32s - 1592.32s |  Or does it mean, like, between 59
1592.32s - 1594.32s |  and 61? And I found that 60 hertz
1594.32s - 1596.32s |  is more accurate than the
1596.32s - 1598.32s |  clock in my phone. So if my
1598.32s - 1600.32s |  clock in my phone is not on Wi-Fi,
1600.32s - 1602.32s |  I can use the 60 hertz
1602.32s - 1604.32s |  from the wall to measure time, because it's
1604.32s - 1606.32s |  so accurate. And I didn't understand, why
1606.32s - 1608.32s |  is the wall, why is the 60 hertz so accurate?
1608.32s - 1610.32s |  Apparently it's connected to GPS. So if one
1610.32s - 1612.32s |  power station goes down, another
1612.32s - 1614.32s |  station can pick it up. But the interesting
1614.32s - 1616.32s |  thing is, it's not always accurate.
1616.32s - 1618.32s |  It would actually remain accurate only for a short period
1618.32s - 1620.32s |  of time, and then it would drift.
1620.32s - 1622.32s |  And I realized that you can take advantage of that drift,
1622.32s - 1624.32s |  and you can exploit that. So what you
1624.32s - 1626.32s |  can do, is you can say,
1626.32s - 1628.32s |  if I measure that drift over time,
1628.32s - 1630.32s |  you can take
1630.32s - 1632.32s |  that and use that as a fingerprint of a location.
1632.32s - 1634.32s |  Because every power station has its own unique fingerprint
1634.32s - 1636.32s |  of that drift. So if you put a
1636.32s - 1638.32s |  Raspberry Pi and a transformer in different
1638.32s - 1640.32s |  power stations, just in the
1640.32s - 1642.32s |  wall, you can have a public database
1642.32s - 1644.32s |  where you're all sending the drift of this
1644.32s - 1646.32s |  information, the 60 hertz signal.
1646.32s - 1648.32s |  And now whenever you have a recording, a video recording
1648.32s - 1650.32s |  or an audio recording, you can perform
1650.32s - 1652.32s |  a match and figure out where that audio recording
1652.32s - 1654.32s |  was taken, or where that video recording was
1654.32s - 1656.32s |  taken. Just another
1656.32s - 1658.32s |  interesting project that we can take advantage of.
1658.32s - 1660.32s |  And there's so much other interesting research
1660.32s - 1662.32s |  in the laser microphone and the keyboard acoustics.
1662.32s - 1664.32s |  Ben Nassie, he did
1664.32s - 1666.32s |  Lamp Phone, Glow Worm, many other
1666.32s - 1668.32s |  attacks. There's
1668.32s - 1670.32s |  the visual microphone, there's keyboard acoustic
1670.32s - 1672.32s |  side channels, keyboard acoustic emanations.
1672.32s - 1674.32s |  And I want to see, A, can I
1674.32s - 1676.32s |  implement this laser microphone? And B,
1676.32s - 1678.32s |  can I have some improvements?
1678.32s - 1680.32s |  And can I also hear sound? I want to hear sound
1680.32s - 1682.32s |  from a window. Now
1682.32s - 1684.32s |  first, it's really, really important
1684.32s - 1686.32s |  like, lasers are not a toy. I mean,
1686.32s - 1688.32s |  they're a lot of fun. Cats love them.
1688.32s - 1690.32s |  They're a toy to cats. But you can
1690.32s - 1692.32s |  oh my god,
1692.32s - 1694.32s |  you can burn your eyes, so you
1694.32s - 1696.32s |  do actually want to always use
1696.32s - 1698.32s |  laser safety glasses, goggles.
1698.32s - 1700.32s |  When you're buying a 5 milliwatt laser,
1700.32s - 1702.32s |  it doesn't mean it only outputs
1702.32s - 1704.32s |  5 milliwatts. It can output much more power.
1704.32s - 1706.32s |  America, we
1706.32s - 1708.32s |  have the ANSI standard Z136.1
1708.32s - 1710.32s |  Europe uses EN207. Make sure
1710.32s - 1712.32s |  you're getting from a laser safety
1712.32s - 1714.32s |  goggles from a reputable source.
1714.32s - 1716.32s |  And also for the wavelength, for the color
1716.32s - 1718.32s |  of light that you're working with.
1718.32s - 1720.32s |  Let's talk about hardware. So I first
1720.32s - 1722.32s |  tried to reimplement the
1722.32s - 1724.32s |  original
1724.32s - 1726.32s |  laser microphone, and
1726.32s - 1728.32s |  it took me a while to get it working.
1728.32s - 1730.32s |  And the sound quality wasn't great.
1730.32s - 1732.32s |  Now, it was still incredible. Like, as soon as you
1732.32s - 1734.32s |  get to hear sound,
1734.32s - 1736.32s |  that you're bouncing off a window, and then
1736.32s - 1738.32s |  reflecting back and picking up, and you can
1738.32s - 1740.32s |  hear what's going on inside,
1740.32s - 1742.32s |  it's a really magical feeling.
1742.32s - 1744.32s |  And I wanted to see, can I improve it? Can I improve
1744.32s - 1746.32s |  the quality? Because it just, it wasn't that great.
1746.32s - 1748.32s |  Here's my transmit side.
1748.32s - 1750.32s |  So we've updated the system
1750.32s - 1752.32s |  a little bit. The
1752.32s - 1754.32s |  primary things, the primary differences, for one
1754.32s - 1756.32s |  is, normally you just have a laser, and you
1756.32s - 1758.32s |  point it at the window. Every schematic,
1758.32s - 1760.32s |  every laser microphone I've ever
1760.32s - 1762.32s |  seen, simply has a constant
1762.32s - 1764.32s |  laser source, hitting something and
1764.32s - 1766.32s |  reflecting back. The problem
1766.32s - 1768.32s |  I found with this is that there's so much noise.
1768.32s - 1770.32s |  We have the 60 hertz noise from
1770.32s - 1772.32s |  the wall. We have all sorts of
1772.32s - 1774.32s |  noise from computers around. And all
1774.32s - 1776.32s |  of this stuff is typically low frequency noise
1776.32s - 1778.32s |  that is messing with your signal. And we need to
1778.32s - 1780.32s |  get rid of that.
1780.32s - 1782.32s |  I found a laser
1782.32s - 1784.32s |  driver, this was a laser
1784.32s - 1786.32s |  driver I had, that had something called
1786.32s - 1788.32s |  an RF bias T. And what this means is
1788.32s - 1790.32s |  it's a mixer. So you can have a constant
1790.32s - 1792.32s |  current source that's powering the laser, and
1792.32s - 1794.32s |  then you can have another source that's oscillating.
1794.32s - 1796.32s |  And I was thinking, well, what
1796.32s - 1798.32s |  they do in radio is that they'll
1798.32s - 1800.32s |  oscillate things at different frequencies to get away
1800.32s - 1802.32s |  from other frequencies that might be harming.
1802.32s - 1804.32s |  So what if we turn the laser on and off
1804.32s - 1806.32s |  in the RF domain? If we go into
1806.32s - 1808.32s |  radio, and we're turning that light on and off
1808.32s - 1810.32s |  at the radio frequencies?
1810.32s - 1812.32s |  Then we can actually get away
1812.32s - 1814.32s |  from all of that noise that we hear.
1814.32s - 1816.32s |  Here you can see the different parts
1816.32s - 1818.32s |  of this system. So the
1818.32s - 1820.32s |  oscilloscope in the top, I use that simply
1820.32s - 1822.32s |  because I have a signal generator built in.
1822.32s - 1824.32s |  It's a Rigol. I'll have the
1824.32s - 1826.32s |  full details, the full
1826.32s - 1828.32s |  bill of materials in a
1828.32s - 1830.32s |  future slide. But the current controller and
1830.32s - 1832.32s |  temperature controller, you do not need a temperature
1832.32s - 1834.32s |  controller, but that's just what I have at home.
1834.32s - 1836.32s |  Current controller for the constant current
1836.32s - 1838.32s |  source. In the top, there's that black box.
1838.32s - 1840.32s |  That's the laser driver.
1840.32s - 1842.32s |  There's also the RF mixer built
1842.32s - 1844.32s |  into that. I use a collimating lens.
1844.32s - 1846.32s |  So what collimation means is
1846.32s - 1848.32s |  collimation means it just takes light and
1848.32s - 1850.32s |  tries to make it into a single dot.
1850.32s - 1852.32s |  Or a straight...
1852.32s - 1854.32s |  If you take a flashlight, you typically have
1854.32s - 1856.32s |  an unfocused beam of light. A collimated
1856.32s - 1858.32s |  beam is a beam that does not focus
1858.32s - 1860.32s |  or defocus. I used to think a laser,
1860.32s - 1862.32s |  what made a laser a laser
1862.32s - 1864.32s |  was that it was collimated, that it was a straight line.
1864.32s - 1866.32s |  And that's not true. It's not
1866.32s - 1868.32s |  collimation. What makes a laser
1868.32s - 1870.32s |  a laser is that it's coherent. And all
1870.32s - 1872.32s |  that means is that the phase of light coming out
1872.32s - 1874.32s |  is always the same. It always starts at the same
1874.32s - 1876.32s |  place. It's not important for this attack.
1876.32s - 1878.32s |  Just something I thought that was interesting for
1878.32s - 1880.32s |  me to understand what a laser
1880.32s - 1882.32s |  is. The flexor, that just lets
1882.32s - 1884.32s |  us actually direct
1884.32s - 1886.32s |  the light up and down very easily.
1886.32s - 1888.32s |  A shutter is to really tighten our
1888.32s - 1890.32s |  beam. So even though we have a collimation
1890.32s - 1892.32s |  and we're collimating this laser beam, we want
1892.32s - 1894.32s |  to get a really tight beam. So a shutter just
1894.32s - 1896.32s |  lets us close that even further.
1896.32s - 1898.32s |  And behind the lens, there's
1898.32s - 1900.32s |  a laser diode. And all of these you can
1900.32s - 1902.32s |  buy separately. And the nice thing is that with a laser
1902.32s - 1904.32s |  diode, I can use a red light normally
1904.32s - 1906.32s |  when testing, but then I can move to
1906.32s - 1908.32s |  the infrared where we don't see it.
1908.32s - 1910.32s |  So these are the
1910.32s - 1912.32s |  actual components I'm using.
1912.32s - 1914.32s |  The obligatory turn on the fog
1914.32s - 1916.32s |  and check out the cool red laser
1916.32s - 1918.32s |  beam.
1918.32s - 1920.32s |  Then we want to actually receive that
1920.32s - 1922.32s |  information. So how do we receive it? The typical
1922.32s - 1924.32s |  setup is we have a photo diode and a sound card.
1924.32s - 1926.32s |  But what we're doing is we're
1926.32s - 1928.32s |  modulating. So with a signal generator, we start
1928.32s - 1930.32s |  modulating this thing at hundreds of
1930.32s - 1932.32s |  thousands of times
1932.32s - 1934.32s |  per second. So the sound,
1934.32s - 1936.32s |  humans can hear between 20 hertz and 20
1936.32s - 1938.32s |  kilohertz. So I want that sound.
1938.32s - 1940.32s |  But I want
1940.32s - 1942.32s |  to then get away from those low frequencies
1942.32s - 1944.32s |  because there's so much electromagnetism
1944.32s - 1946.32s |  at those frequencies that it's
1946.32s - 1948.32s |  disrupting the signal I'm getting.
1948.32s - 1950.32s |  Because we're getting very little light back from
1950.32s - 1952.32s |  the laser that's reflecting
1952.32s - 1954.32s |  off a window or off
1954.32s - 1956.32s |  a computer.
1956.32s - 1958.32s |  So first, and the sound
1958.32s - 1960.32s |  card can only listen to, say, 48
1960.32s - 1962.32s |  kilohertz or 192 kilohertz.
1962.32s - 1964.32s |  To get away from all that sound,
1964.32s - 1966.32s |  we modulate the laser. We turn the laser
1966.32s - 1968.32s |  on and off 400,000 times per second
1968.32s - 1970.32s |  so that we're at 400 kilohertz.
1970.32s - 1972.32s |  So we need something other than a sound card
1972.32s - 1974.32s |  that can actually accept this.
1974.32s - 1976.32s |  So first, I thought, okay,
1976.32s - 1978.32s |  well, I can use a bunch of analog components.
1978.32s - 1980.32s |  The problem with analog components and electronic circuitry
1980.32s - 1982.32s |  is it's a huge pain. So as you're
1982.32s - 1984.32s |  putting these little components on a circuit board, for one,
1984.32s - 1986.32s |  you're dealing with high frequencies. So as you're
1986.32s - 1988.32s |  trying to change, as you're trying different
1988.32s - 1990.32s |  filters and amplifiers, all of this
1990.32s - 1992.32s |  is very difficult. And think, man,
1992.32s - 1994.32s |  I really wish I could use GNU Radio.
1994.32s - 1996.32s |  GNU Radio is open source signal processing software.
1996.32s - 1998.32s |  And with that, then I can drag and drop
1998.32s - 2000.32s |  and life is just great. I can, like, sit back
2000.32s - 2002.32s |  in my chair, drink some caffeine,
2002.32s - 2004.32s |  and just play with these little blocks
2004.32s - 2006.32s |  and just test different things to see what works.
2006.32s - 2008.32s |  The problem, the challenge
2008.32s - 2010.32s |  with using GNU Radio is that I need, then,
2010.32s - 2012.32s |  a software-defined radio to pull that data in.
2012.32s - 2014.32s |  The sound card won't work because I need something
2014.32s - 2016.32s |  that can listen to not only 400 kilohertz,
2016.32s - 2018.32s |  I need to go at least double that.
2018.32s - 2020.32s |  It's called Nyquist theorem. I need to go to at least
2020.32s - 2022.32s |  800 kilohertz of a sample rate,
2022.32s - 2024.32s |  how fast I'm listening to that data.
2024.32s - 2026.32s |  And I can use a software-defined radio,
2026.32s - 2028.32s |  but software-defined radios don't ever go that low.
2028.32s - 2030.32s |  So, the RTL-SDR,
2030.32s - 2032.32s |  I'm not sure where that goes, maybe 100 megahertz.
2032.32s - 2034.32s |  Excuse me.
2034.32s - 2036.32s |  The HAKR-F, amazing. I love the HAKR-F,
2036.32s - 2038.32s |  but the minimum frequency
2038.32s - 2040.32s |  it can listen to is
2040.32s - 2042.32s |  at about, let's see,
2042.32s - 2044.32s |  1 megahertz, and we're at 400 kilohertz.
2044.32s - 2046.32s |  The USRP,
2046.32s - 2048.32s |  it also has a very low bit rate,
2048.32s - 2050.32s |  so it's about, the analog-to-digital converter
2050.32s - 2052.32s |  has an 8-bit sample rate.
2052.32s - 2054.32s |  And we want higher samples. We want higher resolution
2054.32s - 2056.32s |  so we can extract more signal.
2056.32s - 2058.32s |  The USRP-B210
2058.32s - 2060.32s |  has 12 bits,
2060.32s - 2062.32s |  which is good, but it requires
2062.32s - 2064.32s |  70 megahertz, and we're just down at
2064.32s - 2066.32s |  400 kilohertz.
2066.32s - 2068.32s |  But, then I started looking, and there was something
2068.32s - 2070.32s |  called an up-converter that we can get.
2070.32s - 2072.32s |  So, the up-converter actually adds 125 megahertz
2072.32s - 2074.32s |  to a signal, as long as it's at least
2074.32s - 2076.32s |  100 kilohertz. So, we're at 400 kilohertz.
2076.32s - 2078.32s |  So, ultimately, what I use is a
2078.32s - 2080.32s |  photodiode. I go into an amplifier.
2080.32s - 2082.32s |  That amplifier then goes into a
2082.32s - 2084.32s |  Hammond-up V2.
2084.32s - 2086.32s |  That adds 125 megahertz to our 400
2086.32s - 2088.32s |  kilohertz, so now we're at 125.4
2088.32s - 2090.32s |  megahertz. Then I go into
2090.32s - 2092.32s |  the USRP. Now
2092.32s - 2094.32s |  that can go into my computer. Here's the
2094.32s - 2096.32s |  physical setup. This is the receiving
2096.32s - 2098.32s |  side. Lens, to capture
2098.32s - 2100.32s |  light, into a photodiode, into the amp,
2100.32s - 2102.32s |  into the USRP-B210,
2102.32s - 2104.32s |  into the computer.
2104.32s - 2106.32s |  If you see this outside of your window,
2106.32s - 2108.32s |  it is super sketchy.
2108.32s - 2110.32s |  Maybe, like, shut the blinds,
2110.32s - 2112.32s |  call the police.
2112.32s - 2114.32s |  But, once you actually point this laser
2114.32s - 2116.32s |  at a computer, now there
2116.32s - 2118.32s |  are some big challenges here. Actually,
2118.32s - 2120.32s |  performing alignment is very, very,
2120.32s - 2122.32s |  very challenging. Getting sound
2122.32s - 2124.32s |  is actually not so challenging, because
2124.32s - 2126.32s |  our ears, we're pretty good at listening to
2126.32s - 2128.32s |  just one kilohertz of sound. Although
2128.32s - 2130.32s |  we can hear up to 20 kilohertz, just
2130.32s - 2132.32s |  one kilohertz, we can usually make out
2132.32s - 2134.32s |  what someone is saying.
2134.32s - 2136.32s |  Getting above, I'd say,
2136.32s - 2138.32s |  four kilo, like, the best I was able to get
2138.32s - 2140.32s |  above was four to five
2140.32s - 2142.32s |  kilohertz of sound. And I found
2142.32s - 2144.32s |  for keystroke extraction, I needed to get to
2144.32s - 2146.32s |  three kilohertz. If I got to 2.5
2146.32s - 2148.32s |  kilohertz, I could not convert anything to keystrokes.
2148.32s - 2150.32s |  If I got to three kilohertz,
2150.32s - 2152.32s |  I could start converting to keystrokes.
2152.32s - 2154.32s |  Here's the hardware on the
2154.32s - 2156.32s |  transmit side, just the actual components,
2156.32s - 2158.32s |  just so you know.
2158.32s - 2160.32s |  Here is the RX side.
2160.32s - 2162.32s |  This will all be online, so if you want to know
2162.32s - 2164.32s |  the exact components I used. And one
2164.32s - 2166.32s |  of the other improvements that I wanted to make here,
2166.32s - 2168.32s |  for one, now that we're getting into the RF
2168.32s - 2170.32s |  domain, we get away from all this noise.
2170.32s - 2172.32s |  And we can actually filter out that noise.
2172.32s - 2174.32s |  Another cool thing is I wanted to do this in
2174.32s - 2176.32s |  infrared. I don't want someone seeing
2176.32s - 2178.32s |  me standing outside pointing a laser into
2178.32s - 2180.32s |  their window. That's just too obvious.
2180.32s - 2182.32s |  So I got an infrared
2182.32s - 2184.32s |  laser diode. And how do I
2184.32s - 2186.32s |  actually align to the infrared? Because I can't see
2186.32s - 2188.32s |  it. So I got this infrared camera.
2188.32s - 2190.32s |  It's the X-Nite USB 2S
2190.32s - 2192.32s |  M. It's around $120. It's
2192.32s - 2194.32s |  very cool. It's actually very exciting to be able to see
2194.32s - 2196.32s |  infrared just around
2196.32s - 2198.32s |  you. And it's
2198.32s - 2200.32s |  maybe hard to tell, but I have the laser
2200.32s - 2202.32s |  diode going and just
2202.32s - 2204.32s |  hitting a white square.
2204.32s - 2206.32s |  And you can't see it on my camera, my phone
2206.32s - 2208.32s |  camera, because my phone camera also can't see
2208.32s - 2210.32s |  IR. And my eyes can't see IR.
2210.32s - 2212.32s |  And then here, just so we can see,
2212.32s - 2214.32s |  I made a recording with that
2214.32s - 2216.32s |  camera pointing the laser at
2216.32s - 2218.32s |  my laptop. And you can kind of see the reflection.
2218.32s - 2220.32s |  I'm sitting below the
2220.32s - 2222.32s |  laptop with a steam iron.
2222.32s - 2224.32s |  And I'm just like steaming my
2224.32s - 2226.32s |  laptop until, I think it was
2226.32s - 2228.32s |  the first time I ever used a steam iron,
2228.32s - 2230.32s |  until boiling water boiled
2230.32s - 2232.32s |  down on me. And I was like, ah. So I got maybe
2232.32s - 2234.32s |  a few seconds before I burnt myself.
2234.32s - 2236.32s |  But while I was doing this testing, I also saw
2236.32s - 2238.32s |  something else interesting. I pulled out my
2238.32s - 2240.32s |  phone, and I wanted to change
2240.32s - 2242.32s |  the song, because Spotify was playing.
2242.32s - 2244.32s |  And when I unlocked my phone,
2244.32s - 2246.32s |  I saw these dots, not on the
2246.32s - 2248.32s |  wall, but I saw it on the IR
2248.32s - 2250.32s |  recording.
2250.32s - 2252.32s |  And I'm like, wait, what's happening?
2252.32s - 2254.32s |  When my phone, when I pulled out my phone,
2254.32s - 2256.32s |  I realized, this is
2256.32s - 2258.32s |  LiDAR. So my phone is using
2258.32s - 2260.32s |  LiDAR on the back. I'm like, why? Why is it
2260.32s - 2262.32s |  projecting all of these infrared dots that we cannot
2262.32s - 2264.32s |  see with our eyes? And it only happens when
2264.32s - 2266.32s |  the camera app is open.
2266.32s - 2268.32s |  And it's actually very cool. It's figuring out
2268.32s - 2270.32s |  how far is the object,
2270.32s - 2272.32s |  how far is it? And if it's
2272.32s - 2274.32s |  close, it's going to use the close camera.
2274.32s - 2276.32s |  You have a bunch of cameras on the back of your phone.
2276.32s - 2278.32s |  So it's deciding which camera to
2278.32s - 2280.32s |  use. So when you go closer to an object,
2280.32s - 2282.32s |  it will automatically switch to a different camera.
2282.32s - 2284.32s |  And I thought, that's really cool, but
2284.32s - 2286.32s |  what if I can actually measure this?
2286.32s - 2288.32s |  So I put this in my spectrometer just to see
2288.32s - 2290.32s |  what wavelength of infrared
2290.32s - 2292.32s |  this was, because now we can just monitor
2292.32s - 2294.32s |  for this wavelength of light.
2294.32s - 2296.32s |  So imagine you have a little device with a photo
2296.32s - 2298.32s |  diode, a photo sensor
2298.32s - 2300.32s |  on you, so that whenever someone points
2300.32s - 2302.32s |  their phone camera at you, you get
2302.32s - 2304.32s |  a little vibration. Because you
2304.32s - 2306.32s |  can just measure for that frequency of light, and for
2306.32s - 2308.32s |  that on and off path. And now
2308.32s - 2310.32s |  you can know when someone points their phone
2310.32s - 2312.32s |  camera at you before they're even recording.
2312.32s - 2314.32s |  And it only will show,
2314.32s - 2316.32s |  you can see that sort of rectangle
2316.32s - 2318.32s |  that's exactly the same path.
2318.32s - 2320.32s |  That means I could just
2320.32s - 2322.32s |  make all of you vibrate right now.
2322.32s - 2324.32s |  How fun would that be?
2324.32s - 2326.32s |  So, separate project. We'll do that
2326.32s - 2328.32s |  another time. So there's the RF modulation.
2328.32s - 2330.32s |  This is the biggest improvement that I've seen
2330.32s - 2332.32s |  in this laser microphone. So actually getting
2332.32s - 2334.32s |  into the RF domain.
2334.32s - 2336.32s |  The photo diode I used, this is the
2336.32s - 2338.32s |  Spot 2D. It's pretty interesting, it actually
2338.32s - 2340.32s |  has two cells. So where photo
2340.32s - 2342.32s |  diodes are typically one pixel, this is really two pixels.
2342.32s - 2344.32s |  The hardest challenge, the
2344.32s - 2346.32s |  biggest challenge of this whole system is that you must
2346.32s - 2348.32s |  get essentially to the edge of the diode.
2348.32s - 2350.32s |  You don't want to get the light in the center, you want to get
2350.32s - 2352.32s |  to the edge. Because as soon as the edge,
2352.32s - 2354.32s |  you essentially want your light,
2354.32s - 2356.32s |  your reflection to go on and off that diode.
2356.32s - 2358.32s |  If you're in the center, then you're just gonna
2358.32s - 2360.32s |  you're not gonna get much variation.
2360.32s - 2362.32s |  But if you're at the edge, that's where you get all the variation.
2362.32s - 2364.32s |  There I noticed there was a hair
2364.32s - 2366.32s |  in their photo. Fortunately there was
2366.32s - 2368.32s |  no hair in the photo diode they sent me, so I didn't have
2368.32s - 2370.32s |  to send it back. And then
2370.32s - 2372.32s |  the software that we use. So we use some
2372.32s - 2374.32s |  awesome software. First,
2374.32s - 2377.95s |  Guneo Radio. And we'll
2377.95s - 2379.95s |  quickly go through the steps here, but all
2379.95s - 2381.95s |  this will be online as well.
2381.95s - 2383.95s |  So Guneo Radio, all the red stuff on the left,
2383.95s - 2385.95s |  those are just variables. That just makes it
2385.95s - 2387.95s |  easier for me to, just like in software,
2387.95s - 2389.95s |  to use a single variable that will change things
2389.95s - 2391.95s |  in multiple areas. The things
2391.95s - 2393.95s |  circled in blue, those are just
2393.95s - 2395.95s |  GUI, those are just graphical
2395.95s - 2397.95s |  syncs, so we can see information.
2397.95s - 2399.95s |  The heart of it,
2399.95s - 2401.95s |  the heart of the Guneo Radio stuff is, first
2401.95s - 2403.95s |  we start with our USRP source.
2403.95s - 2405.95s |  So this
2405.95s - 2407.95s |  pulls in data at a sample rate of 4.8
2407.95s - 2409.95s |  megahertz, or mega samples per second.
2409.95s - 2411.95s |  Our center frequency is
2411.95s - 2413.95s |  125.2 megahertz.
2413.95s - 2415.95s |  So 125 megahertz because of the
2415.95s - 2417.95s |  RF upconverter, the Hamminup, and then
2417.95s - 2419.95s |  200 kilohertz. Now, we're
2419.95s - 2421.95s |  actually modulating at 400 kilohertz,
2421.95s - 2423.95s |  but we don't want to listen at 400 kilohertz because
2423.95s - 2425.95s |  there's something called the DC spike. Any software
2425.95s - 2427.95s |  divine radio is going to give you this giant DC
2427.95s - 2429.95s |  spike, and you want to move away from that, and
2429.95s - 2431.95s |  then you filter out that DC spike, and then you can
2431.95s - 2433.95s |  listen to the actual data you want.
2433.95s - 2435.95s |  We mentioned a couple
2435.95s - 2437.95s |  different SDRs. The reason I chose the
2437.95s - 2439.95s |  B210 was because it had a high
2439.95s - 2441.95s |  resolution, or bitrate, and
2441.95s - 2443.95s |  it had a high sample rate.
2443.95s - 2445.95s |  You can also use a Salier logic analyzer.
2445.95s - 2447.95s |  I realize this is also actually a pretty nice
2447.95s - 2449.95s |  50 mega samples
2449.95s - 2451.95s |  per second is also 12 bits.
2451.95s - 2453.95s |  Then we go into
2453.95s - 2455.95s |  a translating FIR filter.
2455.95s - 2457.95s |  This is three things. First, it's a
2457.95s - 2459.95s |  bandpass filter. Oh, first, it
2459.95s - 2461.95s |  actually changes the frequency you're at.
2461.95s - 2463.95s |  So we want to go from
2463.95s - 2465.95s |  125.2 to
2465.95s - 2467.95s |  125.4. That's where our sound is.
2467.95s - 2469.95s |  So now we're centered on the sound,
2469.95s - 2471.95s |  and the sound is moving up and
2471.95s - 2473.95s |  down. So our signal is
2473.95s - 2475.95s |  some sort of sound wave, but
2475.95s - 2477.95s |  our amplitude modulated signal is at
2477.95s - 2479.95s |  400 kilohertz. So it's going up and down.
2479.95s - 2481.95s |  So the FIR
2481.95s - 2483.95s |  filter will also then do a bandpass.
2483.95s - 2485.95s |  So now we're saying, I only want what's
2485.95s - 2487.95s |  around the 400 megahertz.
2487.95s - 2489.95s |  Excuse me, 400 kilohertz. Everything else we can
2489.95s - 2491.95s |  ignore. So we bandpass that out, and
2491.95s - 2493.95s |  then we decimate. Decimate just brings
2493.95s - 2495.95s |  the sample rate down to a more usable
2495.95s - 2497.95s |  sample rate. Then we go into
2497.95s - 2499.95s |  and we amplitude demodulate.
2499.95s - 2501.95s |  So we convert the AM back
2501.95s - 2503.95s |  into the actual sound. So now we
2503.95s - 2505.95s |  can hear sound, and then we save the file.
2505.95s - 2507.95s |  Then we use something called iZotope
2507.95s - 2509.95s |  RX. This is absolutely incredible software.
2509.95s - 2511.95s |  It's commercial software, but it's
2511.95s - 2513.95s |  very good. It's great at spectral
2513.95s - 2515.95s |  repair, and it gives you a spectrograph. So you can
2515.95s - 2517.95s |  actually see what's happening inside of your signal.
2517.95s - 2519.95s |  And then you can do all sorts of things like
2519.95s - 2521.95s |  de-s, de-hum, de-splosive.
2521.95s - 2523.95s |  I have no idea what de-splosive is.
2523.95s - 2525.95s |  But it has a lot of ways
2525.95s - 2527.95s |  that you can then improve the signal. So you can
2527.95s - 2529.95s |  say, hey, I want to learn this area of
2529.95s - 2531.95s |  sound where there's just a lot of noise.
2531.95s - 2533.95s |  Learn that, and now apply it to the rest of the signal
2533.95s - 2535.95s |  and remove that noise.
2535.95s - 2537.95s |  FFmpeg, just so we can actually convert some things
2537.95s - 2539.95s |  around. And then KeyTap3
2539.95s - 2541.95s |  is really the heart of the system for the
2541.95s - 2543.95s |  keystroke extraction. We want to know what the person
2543.95s - 2545.95s |  is typing. And I like
2545.95s - 2547.95s |  this guy's GitHub. He says, I like big VMRC
2547.95s - 2549.95s |  and I cannot lie.
2549.95s - 2551.95s |  So KeyTap3 is part of this
2551.95s - 2553.95s |  software where he takes audio
2553.95s - 2555.95s |  and he's able to then separate
2555.95s - 2557.95s |  out the keystrokes. Now what's interesting
2557.95s - 2559.95s |  is that when you have a keyboard and you press some keys
2559.95s - 2561.95s |  on it, every key produces a
2561.95s - 2563.95s |  unique sound. Now we're not
2563.95s - 2565.95s |  recording sound, we're recording vibration
2565.95s - 2567.95s |  because we're hitting the laptop
2567.95s - 2569.95s |  and reflecting off. And when someone
2569.95s - 2571.95s |  is typing on that laptop, the sound
2571.95s - 2573.95s |  is just vibration. And vibration matter.
2573.95s - 2575.95s |  So the laptop is vibrating.
2575.95s - 2577.95s |  It's literally vibrating. And because every
2577.95s - 2579.95s |  unique key has a position, just
2579.95s - 2581.95s |  like if you hit a drum. If you take a drum and you
2581.95s - 2583.95s |  hit it in one location, you're producing one sound.
2583.95s - 2585.95s |  If you hit it slightly somewhere else, it produces a
2585.95s - 2587.95s |  slightly different sound. You can record that
2587.95s - 2589.95s |  and you can differentiate those two sounds.
2589.95s - 2591.95s |  Then you can figure out where they've actually
2591.95s - 2593.95s |  hit. Now on a keyboard, you don't know
2593.95s - 2595.95s |  what they're typing. You don't actually know
2595.95s - 2597.95s |  what they're hitting. But if you've collected
2597.95s - 2599.95s |  over 100 or 200 keystrokes
2599.95s - 2601.95s |  and you know the language they're
2601.95s - 2603.95s |  typing in, then you can perform
2603.95s - 2605.95s |  analysis and say
2605.95s - 2607.95s |  frequency analysis. Like what are they
2607.95s - 2609.95s |  actually typing? This is a Zodiac Killer.
2609.95s - 2611.95s |  So he would release
2611.95s - 2613.95s |  these puzzles that are essentially
2613.95s - 2615.95s |  substitution ciphers. You can
2615.95s - 2617.95s |  take all encryption and break it down into substitution
2617.95s - 2619.95s |  cipher and transposition
2619.95s - 2621.95s |  cipher.
2621.95s - 2623.95s |  Just
2623.95s - 2625.95s |  some examples. I love the outdoors.
2625.95s - 2627.95s |  So going and as well
2627.95s - 2629.95s |  as pointing lasers. So a couple demonstrations
2629.95s - 2631.95s |  of the setup.
2631.95s - 2633.95s |  Here we can see what this actually looks
2633.95s - 2635.95s |  like as you're pointing the laser
2635.95s - 2637.95s |  onto a reflective surface of a laptop.
2637.95s - 2639.95s |  We'll just see the KeyTap
2639.95s - 2641.95s |  software. FFmpeg and KeyTap running.
2641.95s - 2646.16s |  This is at 10x speed.
2646.16s - 2648.16s |  Gonna be very hard to see, but the next slide
2648.16s - 2650.16s |  I will do a little screenshot
2650.16s - 2652.16s |  so we can compare.
2652.16s - 2654.16s |  Again, that's 10x speed. So here's
2654.16s - 2656.16s |  typing on a keyboard, what I
2656.16s - 2658.16s |  typed, and then what KeyTap 3 was able
2658.16s - 2660.16s |  to recover. This is after going
2660.16s - 2662.16s |  through the setup, after going through
2662.16s - 2664.16s |  GNU Radio, then iZotope RX
2664.16s - 2666.16s |  with a lot of cleanup. Again, I needed
2666.16s - 2668.16s |  to collect at least 3 kHz
2668.16s - 2670.16s |  of sound. And also just
2670.16s - 2672.16s |  an example of what the sound
2672.16s - 2674.16s |  actually sounds like.
2674.16s - 2676.16s |  This was playing music inside of a
2676.16s - 2678.16s |  room and then reflecting off the window.
2680.16s - 2682.16s |  And you can hear a little bit
2682.16s - 2698.85s |  of that sound.
2698.85s - 2700.85s |  And that is the project.
2700.85s - 2702.85s |  The challenges, I mean, this
2702.85s - 2704.85s |  was really interesting. How do you get rid of noise?
2704.85s - 2706.85s |  This whole thing was really
2706.85s - 2708.85s |  signal processing. And the
2708.85s - 2710.85s |  improvements to the laser microphone, the biggest thing
2710.85s - 2712.85s |  to the laser microphone was really
2712.85s - 2714.85s |  getting outside of the sound
2714.85s - 2716.85s |  domain, getting into the radio domain.
2716.85s - 2718.85s |  Once you get into there, then you have a lot more
2718.85s - 2720.85s |  processing capabilities and you have
2720.85s - 2722.85s |  all the sound, a ton of noise
2722.85s - 2724.85s |  that was there, is gone.
2724.85s - 2726.85s |  And there are plenty of improvements
2726.85s - 2728.85s |  we can make, we can discuss
2728.85s - 2730.85s |  later, but thank you so much.
2730.85s - 2732.85s |  I appreciate your time.


