# Media

url: https://www.youtube.com/watch?v=MDndWJxfP-U
title: DEF CON 32 - The hack, the crash and two smoking barrels. - Thomas Sermpinis
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=MDndWJxfP-U",
  "title": "DEF CON 32 - The hack, the crash and two smoking barrels.  - Thomas Sermpinis",
  "description": "This is not a talk in which I will demonstrate exploit chains obtained from the underworld after signing with blood. It\u2019s about sharing meaningful stories from said underworld. The automotive underworld of huge corporations, short deadlines and lukewarm engineers. The one where companies fight for packing more and more functionality inside your computer on wheels, without paying attention to one of the things that our life actually depends on right now, cybersecurity.\n\nWhile others talk about extremely significant remote vulnerabilities, I will focus on a high-level view of architecture and design of vehicles and where security fits in these processes. I will go through a journey of exploitation, from discovering 0days, to persuading engineers for the significance of a finding, by putting him in the driving seat and engaging the breaks mid-journey.\n\nI will conclude, trying to understand why this is happening, why this behavior towards security still exists in the automotive industry, and how a small manufacturer managed to create one of the most secure embedded systems I faced in my career. All this, with a series of demos in real targets, and a real ECU on stage.\n\nOur ultimate goal is to help people understand the state of the industry, spark the interest which can come out of hacking a computer on wheels, and try to raise awareness with a bit of hack, a bit of crash and two smoking barrels.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2378,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.50s - 5.50s | This text was transcribed using whisper model: large-v2

 Hello. So thank you for joining um it's an immense honor to be here with you today uh
9.68s - 13.84s |  something that I would never expect to happen. But this is the hack the crash and two
13.84s - 20.08s |  smoking barrels and how I almost killed an engineer. And I must mention that uh basically I
20.08s - 24.58s |  had no lawyers advising me before my talk so I will not if if you will not be able to reach
24.58s - 30.12s |  me after the talk it was nice meeting you. And now while you are here because some
30.14s - 34.62s |  people in the industry really pissed me off and I wanted to be the one taking the stage.
34.62s - 40.42s |  And now that I got probably your attention let's start. I'm Thomas and yeah my
40.42s - 44.50s |  pictures are usually so bad that uh making it black and white didn't really help. It's like
44.50s - 50.16s |  my accent it can only go worse. And people also know me as Crow Tom. And the main thing
50.16s - 55.04s |  you need to know about me is that I lead an amazing team uh in Auxilium Pentest Labs
55.04s - 60.50s |  they are uh competing in the car hacking village right now and they are second. Um and I
60.50s - 65.50s |  also love to hack like everything day, night, whatever. Mainly to prove to me and you that
67.78s - 73.18s |  our world is hacking in on in really thin threads. And that most products are created with
73.18s - 78.82s |  two main components. A bit of laziness and a sprinkle of capitalism. And for more you can
78.82s - 84.26s |  always go to my website. What we will really really talk about today is vehicle
84.28s - 88.62s |  security. Or how I like to call it all the stupid things that automotive industry is doing
88.62s - 94.62s |  still in 2024. We will try to understand where we are uh where we are heading and if there are
94.62s - 98.70s |  any if there is any light in the end of the tunnel. Hoping to get more people interested in
98.70s - 103.36s |  the industry I love and highlight the significance of all the safety related hardware that no
103.36s - 109.70s |  one cares about. What we will definitely not talk about is extreme exploit chains. I love to
109.72s - 115.22s |  hack but I'm the worst at it. And this means that I'm not here to teach you how to do it but to
115.22s - 120.92s |  show you why you should be here too and why you should care. Also if you were alerted into
120.92s - 124.66s |  coming to my talk because of the title I'm sorry to tell you that during the process of the
124.66s - 128.86s |  testing preparation and development of my talk no engineers were actually killed or
128.86s - 135.10s |  suffocated due due to lack of oxygen. And let's start with the state of the industry and
135.10s - 140.64s |  what a better start than one of my favorite examples of my living room on wheels. Uh as
140.64s - 145.22s |  this car is not actually a result of pin by ride episode but still packs more functionality
145.22s - 149.96s |  and entertainment than my living room. This example of a computer on wheels might be one of
149.96s - 154.86s |  the extreme ones but it's becoming kind of the norm to be honest. Vehicles are getting
154.86s - 160.10s |  connected, getting richer services and functionality something that the users ask for I
160.10s - 165.10s |  guess. What they don't ask for though is for these services to be implemented in an insecure
165.10s - 171.82s |  way. We see examples of improper and insecure implementation of new functionality every day
171.82s - 178.66s |  and we have a handful of examples making the news every week. And while news outlets are
178.66s - 185.70s |  mainly interested in the financial aspect of the thing um no one wants like their car to be
185.70s - 190.70s |  stolen to be honest. I will mostly focus today on the safety aspect of those security issues.
193.54s - 197.84s |  And while the industry waits for the security software defined vehicle messiah today we will
197.84s - 202.88s |  start with the complicated architectures that look like this. Uh here we have a representative
202.88s - 207.72s |  example of a vehicle architecture with individual parts being electronic control control
207.72s - 212.90s |  units. Different embedded components that most of the time have a single specific purpose
212.90s - 219.50s |  inside the vehicle. All these are segmented in several isolated buses to avoid external
219.50s - 225.18s |  communication or interruption and segment them by functionality and criticality. What you
225.18s - 230.38s |  can also see is the fact that some of the interfaces are getting exposed internally though.
230.38s - 234.62s |  And as we saw previously this is a kind of a necessity considering new technology and
234.62s - 239.66s |  requirements needed to exist to make it make it happen. As an example the onboard charging
239.66s - 245.06s |  ECU has an exposed interface handling the communication between the charger and the vehicle
245.06s - 250.06s |  and the main head unit that the user inter uh interacts with is exposed to the internet through
250.06s - 256.04s |  a telematics unit. Most of the times for SOS calls, OTA updates and more interconnected
256.04s - 261.88s |  functionality. Now of course the purpose of this talk is not to cover everything automotive
261.88s - 266.94s |  related but we need to get a bit of understanding on what we are seeing here and what the demos
266.96s - 273.06s |  are representing later. Uh for this reason we will mainly focus on CAN uh which many of you
273.06s - 278.54s |  might know as it exists for more than 40 years. Um and you would be surprised if I tell you
278.54s - 283.84s |  that the majority of the ECUs we are testing still come with this interface. And of course
283.84s - 289.78s |  the need of a single ABS ECU 30 plus years ago does not even come close to modern needs. So
289.78s - 295.82s |  the the protocol has several iterations but still the main issue from my point of view is that
295.86s - 300.74s |  there is no encryption as a standard and no message authentication. This makes CAN messages
300.74s - 306.44s |  flowing on those buses prone to interception, injection and replication in cases that no
306.44s - 312.72s |  additional protections are implemented. Which is more common than you think even 40 years
312.72s - 318.28s |  after its inception. Of course this is not only uh the only technology which is currently
318.28s - 323.90s |  used in modern vehicles but it's one of the most commonly used and that's why it's important
323.90s - 328.42s |  to stress its flaws considering the stubbornness of automotive companies to stick with
328.42s - 334.68s |  archaic and insecure technologies. As we speak for the current state of automotive security
334.68s - 340.62s |  it's worth mentioning that um what started to be enforced to all manufacturers homologating
340.62s - 346.64s |  vehicles uh in UNESCO member countries. Um but I don't want to bore with you as USA does
346.64s - 353.40s |  not have any specific binding regulation similar to this. But it's worth mentioning that
353.40s - 359.18s |  it's a starting point for shaping the completely unregulated mess that exists till now in our
359.18s - 365.32s |  industry but of course it's still a regulation with all the negatives that come with it.
365.32s - 370.12s |  Considering that I will have a relatively negative talk I want to state from now that while
370.12s - 374.36s |  the majority of the industry has a negative approach to cyber security there are several
374.36s - 379.94s |  people that still strive for secure and safe vehicles every day with their work, research and
379.94s - 385.22s |  discussions. Though not everything is sunshine and flowers and automotive is mainly based on
385.22s - 389.78s |  hundred plus year old mechanical engineering industries that were recently forced to
389.78s - 395.36s |  implement a lot of things they had no idea about and innovate in an environment with really
395.36s - 400.50s |  short life cycles and restricting safety requirements that will make most of us cry in any
400.50s - 405.50s |  case in many cases. I struggled a lot though so let me tell you my story. To start with I have to
406.06s - 411.06s |  tell you that I'm tired of hearing about the state of automotive security by professionals in
415.24s - 419.68s |  commercial events referring to a couple of good examples in the sea of OEMs and tier one
419.68s - 425.24s |  suppliers developing products in this industry. Tesla and BMW are not the only companies
425.24s - 430.98s |  out there. And yes while I really appreciate their work in some cases we are here to talk
431.00s - 436.80s |  about the industry as a whole and not the two examples that are out of the ordinary. And I'm
436.80s - 441.78s |  saying this because vulnerability disclosure programs are not the norm here. The small
441.78s - 447.88s |  amount of OEMs that escaped from their mechanical engineering past attitude or they
447.88s - 452.96s |  started in this new generation of automotive manufacturers is not representative for the
452.96s - 458.10s |  whole industry. And even the companies that incentivize and support researchers they only
458.12s - 462.92s |  give payouts to findings that are heavily security critical but no mention to safety
462.92s - 468.90s |  critical issues and exploit chains. And I'm saying this because the last two years I
468.90s - 474.90s |  discovered twenty five safety related findings out of which only two were accepted until now.
474.90s - 479.40s |  And not because they are out of scope or not applicable but because there is no way to
479.40s - 485.18s |  actually disclose them. To start to start talking about them though uh we need to get an
485.20s - 489.86s |  understanding of one of the protocols we approach today in our example POCs namely the
489.86s - 494.64s |  Unified Diagnostics Protocol which lives in the application layer of the ECUs and allows
494.64s - 499.54s |  diagnostic functionality such as reading and erasing faults, reprogramming, testing and
499.54s - 505.02s |  monitoring. It commonly consists of several services that handle specific actions and the
505.02s - 510.68s |  common one here that we will try to use in uh in these examples in these demos is the ECU
510.72s - 515.86s |  reset or service eleven which is commonly used to perform a reset on the ECU as the name
515.86s - 521.00s |  implies but of different types so depending on the supplied subservice we can specify if it's a
521.00s - 526.60s |  hard a soft or any other supported uh type of reset on the ECU. And finally I have to
526.60s - 531.58s |  mention that the hard ECU reset is most in most cases it's equivalent to a comp to a
531.58s - 538.58s |  complete power cycle and we will see how this can go really bad for the ECU. Now the last
538.58s - 543.02s |  five years me and my team performed almost two hundred penetration testing and research
543.02s - 548.70s |  projects in the automotive industry. Uh is the screen? Yeah. In the automotive industry
548.70s - 554.84s |  sorry. And this means that first of all we got a broad understanding and experience of how
554.84s - 559.98s |  security is implemented and discovered several nasty things along the way. While we try to
559.98s - 564.38s |  work with all these people to make the products more secure the issue is that I'm not able to
564.38s - 569.36s |  talk about those so I had to find a way to share some of those juicy things. So it was
569.36s - 574.32s |  during a warm summer in Arizona when I had the rental unit from a brand which I tried my
574.32s - 580.06s |  best to hide here. And during my free time and during night as if I was testing during the day
580.06s - 585.44s |  in Arizona I would not be here. Uh I started working uh like poking around uh this thing
585.44s - 590.44s |  that you see there and I had my first hit. In this case we triggered something that is not
590.88s - 597.78s |  a hundred percent clear what it is. From the context given in the error created on the
597.78s - 602.12s |  heads up display. For this reason we need to dig deeper and understand the architecture of
602.12s - 609.12s |  the vehicle, understand how, why, in which extent something is affected. Is this error real? Is
609.12s - 615.14s |  it expected behavior? Does it even have any security or safety impact or not? This is the
615.14s - 621.24s |  only, this is only a part of the questions that I have to answer at this point in order to
621.24s - 627.88s |  move forward. And that's what I did. In the first demo you see how we discovered that the
627.88s - 633.62s |  affected ECU uh and by issuing a simple ECU reset on the user accessible onboard
633.62s - 638.06s |  diagnostics board the ECU resets and the light of the affected blind spot blind spot
638.06s - 645.00s |  detection sensor is engaged. Of course I didn't stop there and because at this point a lot of
645.02s - 651.16s |  educated guesses can be done considering uh what was discovered. As is the finding has no
651.16s - 656.70s |  big safety related severity outside of the fact that it can distract the driver. By listing the
656.70s - 661.38s |  known facts though we can assume where the affected ECU is located in the architecture and
661.38s - 668.18s |  how this can be escalated further by a malicious user. What we know is that first of all we can
668.18s - 673.56s |  power cycle the ECU and what and that there are no preconditions that can restrict this
673.58s - 680.22s |  action. Like a vehicle speed uh restriction for example. Additionally from the function of the
680.22s - 685.22s |  assistive driving uh we can assume that the blind spot detection sensor is connected with the
685.22s - 692.00s |  functionality of the ADAS itself. By this we can easily prove that the sensor can be
692.00s - 697.08s |  triggered mid drive. Uh as a direct result it can confuse the driver because of the engagement
697.10s - 702.84s |  of a sensor in an unexpected situation. But more importantly we can engage serious
702.84s - 708.68s |  safety implications to the ADAS system like steering interruption during a lane change or
708.68s - 713.78s |  even braking engagement during a false safety related incident on the blind spot detection
713.78s - 719.48s |  sensor. Of course I don't want to check these assumptions myself um and I hope I don't need to
719.48s - 726.16s |  mention that you you should always check safety related issues in a safe environment. Who has
726.18s - 731.48s |  the ability and the environment? The manufacturer of course. And for this reason I had to find a
731.48s - 736.32s |  way to report the finding and prove those assumptions. Now going through the process of
736.32s - 742.02s |  vulnerability disclosure I initiated uh by trying to find a communication channel uh with the
742.02s - 747.46s |  OEM and a couple of years ago that this happened. The problem is that there was no
747.46s - 751.30s |  vulnerability disclosure program. No one was answering to me regarding this from the
751.34s - 757.38s |  contact options and the people I discovered online. But of course I didn't give up. I kept
757.38s - 763.56s |  hacking. And getting our ha- hands a bit dirtier here we need to introduce the main access
763.56s - 769.12s |  control mechanism in UDS diagnostics called security access. Which as you understand from
769.12s - 775.14s |  my diagram is a simple challenge response. The client requests a random seed, the ECU generates
775.14s - 782.16s |  what seed uh that seed and calculates the key using the secret algorithm and secret key. And
782.16s - 786.46s |  after that the client needs to know the same secrets, use the random seed and calculated key
786.46s - 792.90s |  to send to the ECU where the ECU verifies uh verifies this uh calculated key and grants or
792.90s - 798.30s |  rejects that access to the client. The implementation highly highly depends on the
798.30s - 803.54s |  cyber security requirements of the OEM most of the times. Uh and when these are loosely
803.54s - 809.32s |  developed we see some unimaginably sloppy implementations, backdoors and weak sources of
809.32s - 817.99s |  randomness um or any other random aspect of uh the process. Where this access control is
817.99s - 824.57s |  used no- commonly I would say mostly software updates and reprogramming and the most
824.57s - 831.57s |  commonly used uh in high severity instances um is these ones. Um mainly also the ones that
831.57s - 837.47s |  we care about and that shows the level of access they can give us in cases of compromise. And
837.47s - 842.29s |  of course it's automos- automotive so the process is not encrypted. But it's behind an
842.29s - 847.29s |  ADPS and it's a challenge response right? Knowing that the process is unencrypted we already
849.63s - 855.37s |  know that we can intercept and replay a seed and the applicable calculated key for the process.
855.37s - 861.67s |  Message authentication also does not exist in 99 percent of the times here so that should not
861.67s - 867.75s |  be an issue most probably. But even with access to the bus managing to intercept the seed and
867.75s - 873.51s |  the applicable key should not yield to elevated access as the process heavily based on the
873.51s - 879.69s |  random aspect of the seed. Um if we cannot control the seed we cannot replay a successful
879.71s - 886.23s |  seed key pair to obtain elevated access to the target ECU. Or can we? And going back to our
886.23s - 891.33s |  friend ECU reset I want to remind you that one of the subservices capable of full power
891.33s - 897.49s |  cycling the ECU is the hard ECU reset. This is the direct outcome though. Indirectly by
897.49s - 902.51s |  completing a power cycle we also perform a reset to the system clock in many cases. And here
902.77s - 909.61s |  we see the effects of this assumption. Uh while the seed of the target ECU can be considered
909.61s - 915.65s |  really secure at 32 bytes we can see that we can reset the system clock with an ECU reset and
915.65s - 920.75s |  after a predefined and fixed delay between the reset and the seed request the supplied
920.75s - 925.75s |  random seed is always the same with a staggering hundred percent accuracy. In this case we
926.01s - 932.75s |  invalidated the assumption of what is needed in a challenge response when we can intercept
932.75s - 938.55s |  successfully a seed and key pair. With that in mind we only need one seed key pair to obtain
938.55s - 943.19s |  elevated access to the unit. Which can potentially be obtained at the service visit or during
943.19s - 950.19s |  an OTA update from the head unit. Fast forward two years later and I eventually discovered
950.21s - 956.25s |  someone that was willing to help me report those issues to the OEM. I prepared a well
956.25s - 960.81s |  structured report of of my vulnerabilities and sent it to the contact point working for the
960.81s - 967.25s |  OEM. The issues were acknowledged a couple of days later but privately. At this point we know
967.25s - 973.29s |  that these findings were not only affecting the model and model year I tested but several
973.29s - 978.83s |  models and bra- and of the brand and numerous model years. So we are talking about a
978.83s - 985.77s |  significant number of affected vehicles. The drama starts here though. Despite the help
985.77s - 990.81s |  from the contact point OEM decided that the cost of fixing the issue exceeds the expectations
990.81s - 997.65s |  for this model. The excuse is that future electrical and electronic architecture that they
997.65s - 1003.03s |  designed will mitigate those issues in the models for 2025 and 2026. Which of course
1003.03s - 1008.33s |  directly means that the currently sold architecture is still vulnerable and that the OEM
1008.33s - 1013.91s |  is not willing to either fix or disclose the findings publicly. As a romantic myself I
1013.91s - 1019.17s |  decided to not publish the findings. I wanted to act professionally especially in comparison
1019.17s - 1024.95s |  to the norm in my industry and irresponsibility brings chaos. I'm not the one feeding this
1024.95s - 1029.95s |  beast. Trying to find a solution I decided to uh to propose a responsible disclosure to a generic
1030.89s - 1035.89s |  VDP namely the ASRG Automotive Security Research Group which out of many things they are
1039.03s - 1044.77s |  also an officially recognized CNA. So after a short discussion with my contact point and the
1044.77s - 1049.77s |  OEM uh I decided to report the issue to ASRG. Something that needs to be mentioned out here
1052.03s - 1057.05s |  here for the sake of compli- completeness sorry. Uh is that I disclosed the finding in a generic
1059.99s - 1064.99s |  email from the website of the VDP. And not to anyone directly just the generic available email
1067.75s - 1073.03s |  address that was uh on the website. At this point and after a couple of email exchanges with
1073.03s - 1078.03s |  me the OEM and the ASRG the OEM stops responding completely. I was completely clueless of
1080.73s - 1086.15s |  what there is to follow. Uh despite my continuous effort to resolve the issue and find why
1086.17s - 1093.19s |  this happened um the OEM wasn't responding to all uh of our requests. Or to any of our
1093.19s - 1098.23s |  requests. And not only they didn't give me a reason but I was directly accused by third
1098.23s - 1103.69s |  parties which I never contacted or revealed my findings to that I'm collaborating with
1103.69s - 1109.17s |  hostile nations. You don't accuse me of doing something like this especially when I tried so
1109.17s - 1115.27s |  much to responsibly disclose this shit and not and the only thing they did was find excuses.
1115.29s - 1121.97s |  And to be honest I don't want to dex dox anyone uh this is not why I'm here. I'm here to share
1121.97s - 1128.21s |  my experience and maybe shake the industry a bit out of this limbo they are into. But what
1128.21s - 1133.11s |  happened is that the that the person that handled my case in the public VDP had the
1133.11s - 1139.41s |  citizenship of a supposed hostile nation which the legal department of the OEM decided that
1139.41s - 1144.95s |  it's not good for their image. You want to hear some plot twist uh basically this guy
1144.97s - 1150.91s |  does not live in this nation he has another residency on the homeland of the OEM and guess
1150.91s - 1156.21s |  what I recently learned that he has chosen to handle this topic because of an affiliation
1156.21s - 1161.75s |  with the OEM and he has he was the best person for this job. But the OEM research can go that
1161.75s - 1167.59s |  far of course or they didn't even care to be honest. After all the drama and after I contact
1167.59s - 1172.13s |  all the parties saying that this level of accusations from third parties and the fact that
1172.15s - 1177.15s |  they disclosed they disclosed the private findings outside of the legal framework was
1177.15s - 1181.93s |  unacceptable. I also announced to them that the findings will be published published on the
1181.93s - 1186.93s |  day of DEF CON today. And of course this is the day they answered. Something that needs to
1190.57s - 1195.41s |  be mentioned here is that during the initial discussion for the findings I was clearly
1195.41s - 1201.35s |  asked if the finding is discovered by the directly connecting to the ECU or from the OBD
1201.37s - 1208.17s |  port. Um as the OBD port is user accessible and the findings are applicable and if it's only
1208.17s - 1213.35s |  applicable to the direct connection will mark the findings as mitigated by the IDPS system.
1213.35s - 1218.35s |  Something that I don't agree but it was reasonable. This though not so much. Um yeah. So
1221.99s - 1226.05s |  yeah today I'm releasing these 2 vulnerabilities as I said I don't want to dox anyone I want
1226.05s - 1231.77s |  a safe future with cars that can support their functionality in a secure way but in in this
1231.77s - 1236.77s |  case the OEM instead of communicating decided to play politics and it's not only them this is
1238.67s - 1244.31s |  the common trend. Researchers are not the ones to blame here with falsified accusations. As in
1244.31s - 1250.09s |  most cases we are more than happy to collaborate and help each other. And not only
1250.09s - 1255.25s |  researchers, pen testers too. Let's crash it and see where it brings us in this case. As we
1255.25s - 1259.99s |  saw previously politics play a big role. Not only in public disclosure but in private
1259.99s - 1264.69s |  projects too. Throughout my time with automotive security projects I heard a lot of excuses by
1264.69s - 1271.71s |  engineers and management only uh on why they don't want to accept or fix an issue. The usual
1271.71s - 1276.71s |  suspects are loosely developed requirements uh or internal or external. Strict deadlines and
1276.91s - 1281.91s |  long product life cycles along others of course. By my conclu but my conclusion is always that
1286.15s - 1291.23s |  it's a culture issue. Either the company culture or the respective local culture affects the way
1291.23s - 1296.53s |  companies consume, approach and mitigate issues. Of course it's a complex issue where
1296.53s - 1302.27s |  regulators, governments and external parties are contributing to the development and
1302.27s - 1308.83s |  production of a full vehicle. But in the end the people I interacted and worked with uh out of
1308.83s - 1315.01s |  these projects construct my perception of this industry. But considering the culture and how
1315.01s - 1321.35s |  the findings are approached what do we need to do to persuade them about the severity? Which
1321.35s - 1326.85s |  level should we reach and why people uh and which people should we contact? Who is
1326.87s - 1333.71s |  responsible for the person that will die if my next finding is not fixed? Even if you develop the
1333.71s - 1339.91s |  target with security in mind uh and with the best of intentions logical flaws can exist and
1339.91s - 1344.39s |  exploited. Developers of different components usually only interact with a vehicle
1344.39s - 1349.39s |  simulation ignoring how one action can have a security or safety event outside the scope of the
1349.51s - 1354.51s |  functional testing. And this is how safety related findings can be discovered in most
1357.69s - 1364.03s |  unexpected for the manufacturer behavior. A completely unrelated issue of seemingly minimal
1364.03s - 1370.43s |  secure uh security impact can have a devastating safety outcome. As a first use case we can
1370.43s - 1374.81s |  easily get the example of electric vehicles where I was testing the security not only of a
1374.83s - 1379.77s |  battery management system on the on board charging but the batteries themselves. By
1379.77s - 1384.61s |  analyzing the communication and while I was close to the car I discovered that there is a sound
1384.61s - 1389.91s |  generated when I was injecting uh an unauthenticated message. When I started discussing
1389.91s - 1395.65s |  with one of the engineers it ended up being the battery contra- contractors of the AV. I was
1395.65s - 1400.55s |  immediately concerned at that point knowing that wear and tear of the con- contact uh surface
1400.57s - 1405.57s |  can increase the resistance and lead to excessive excessive heating. And you know what
1405.57s - 1410.61s |  comes with after excessive heating and localized uh especially heating for extended
1410.61s - 1416.95s |  periods of time? It's of course fire. Um of course I cannot burn an engineer and I cannot
1416.95s - 1422.09s |  conduct a test to prove physics the physics behind behind it without risking the battery pack
1422.09s - 1427.29s |  burning nonstop for days. So the topic ended there, the vehicle is out, all engineers are
1427.33s - 1434.41s |  safe, a couple of hundreds of thousands of users are not. Same applies to hydrogen and the
1434.41s - 1439.81s |  loving OEM that could not understand why small leaks in hydrogen in the hydrogen tank can
1439.81s - 1445.75s |  affect uh the specific rotations of the valve and can lead to suffocation of the whole
1445.75s - 1452.54s |  garage we were working in in a couple of minutes. As I said in the start uh I have no
1452.54s - 1457.90s |  magical exploit chains but to prove this finding in an effective way doesn't take much.
1457.90s - 1464.18s |  Considering that at the current state we can easily spoof messages in an unencrypted way
1464.18s - 1469.68s |  and perform a power cycle with an unrestricted service we can easily find a way to reproduce
1469.68s - 1474.96s |  the issue from an exposed interface. Because most of the times manufacturers try to use the
1474.96s - 1481.00s |  obscurity factor as a way of mitigation for those findings. But as we saw in the
1481.00s - 1486.44s |  architecture modern vehicles are getting more connected than ever so find the exposed
1486.44s - 1491.44s |  interface, directly communicate uh with the ECU uh and start sending, that's my advice.
1494.28s - 1500.62s |  Even if it needs some cutting around. Now of course after that you have to listen to all the
1500.62s - 1505.90s |  excuses about how your exploit is not realistic and how physical security mitigates issues
1505.90s - 1510.40s |  in digital security when at this point it's time to put them inside the vehicle and show
1510.46s - 1517.04s |  them adjustable injections where they will either believe you or they will believe in God. Of
1517.04s - 1521.84s |  course for safety reasons and when I'm ready to unleash my magical exploit chain there is
1521.84s - 1527.04s |  always some party pooper that restricts me from doing so and thank you to this party pooper
1527.04s - 1533.18s |  but uh I guess in many times it's not only that they don't believe you but they even want to
1533.18s - 1538.80s |  prove you wrong during the night because that's who we are. Next day I found this in the
1538.82s - 1544.26s |  garage after some engineer tried to engage the injection from the OBD port from for the
1544.26s - 1550.88s |  sake of completeness this is how I left it the previous day. Continuing with the trend of
1550.88s - 1557.88s |  naiveness though both from mine and the engineer side I got my hands on an ECU unrelated to
1557.88s - 1563.08s |  commercial project and I thought here we are let's do some exploitation. So I started my
1563.08s - 1567.76s |  common workflow tried to exploit trying to exploit UDS and trying to evaluate the source of
1567.78s - 1572.78s |  randomness but after several hours it didn't seem feasible so I had to resort resort in other
1575.02s - 1580.02s |  solutions. So I did this thing apart and started getting a better understanding of its guts. I
1582.20s - 1588.34s |  analyzed the hardware parts one by one and started getting deeper inside my rabbit hole. To
1588.34s - 1594.28s |  realize that it's one more case of automotive SOC architecture with all the pros and cons
1594.30s - 1599.94s |  that come with it. The biggest thing that has to be said about it um and which will help us
1599.94s - 1605.84s |  understand some of the issues later on is the fact that ECUs are considered safety related
1605.84s - 1611.28s |  components with which require real time responsiveness due to the safety related nature
1611.28s - 1617.66s |  on the products that utilize them. So by opening one of the targets we can easily see what
1617.66s - 1623.80s |  happens here. Not only one SOC but two exist on the target board. And this is because of the
1623.82s - 1629.82s |  safety related functionality we mentioned earlier. An instruction needs to be executed twice
1629.82s - 1636.26s |  in either two different controllers um in this case the secure and application controller
1636.26s - 1642.20s |  which we discovered or two different isolated cores and then compared between the two. If the
1642.20s - 1648.14s |  output of the instruction is the same it gets executed if not a fallback procedure has to be
1648.14s - 1653.28s |  followed depending on the system. Of course this architecture is applicable to higher severity
1653.32s - 1658.80s |  safety related devices like airplanes with more secure controllers needed but this is out
1658.80s - 1670.50s |  of the scope at least for today. Why this is important? Uh because in the devices in which is
1670.94s - 1676.84s |  applicable their fail- failure will result in loss or damage of equipment, environmental
1676.84s - 1681.84s |  harm, injury or even death of some users or the surrounding people. And moving closer to the
1681.98s - 1686.98s |  hardware we see that not only the supplier was kind enough to spoil the fun and let us uh tell
1689.28s - 1695.22s |  us when uh one of where one of the JTAG headers is on the board but they included a second
1695.22s - 1701.10s |  header for the secure controller. Unfortunately there uh after connected connecting my
1701.10s - 1708.12s |  debugger I discovered that both the JTAG interfaces are locked. And after I desperately
1708.12s - 1714.02s |  started clicking on my power supply I realized something really interesting. And here you
1714.02s - 1720.39s |  can see uh did it start? Yes so here you can see that the device is locked by normally
1723.59s - 1728.59s |  connecting my uh JTAG debugger to the to the unit to the target ECU and by connecting the JTAG
1729.59s - 1734.59s |  on the first seconds after boot you can see a nice easter egg that we get debug on the secure
1742.73s - 1747.87s |  controller. So yes we got access to the secure controller in this case we basically got to
1747.87s - 1754.11s |  enable the debug access in a really short period of time during boot uh and as a result we can
1754.13s - 1758.61s |  control the execution and dump the memory of the vulnerable controller. I love automotive
1758.61s - 1764.95s |  security. I know that you're not yet tired of the fails so on the same ECU and because we are
1764.95s - 1769.59s |  talking about the telematics unit there is a Qualcomm modem SOC running which comes with
1769.59s - 1774.73s |  these magical pins that if sorted provide us with a nice Qualcomm download mode and after
1774.73s - 1779.39s |  discovering some other pins seemingly matching a USB port pin out and performing the
1779.41s - 1785.45s |  dangerous act of connecting a random USB from an ECU purchased from eBay we realized that our
1785.45s - 1791.69s |  assumptions are correct. After I dumped the firmware with more than one ways as you see I
1791.69s - 1796.43s |  realized that the automotive related controller has several references to the system clock
1796.43s - 1800.63s |  which confused me even more. As my process of discovering weak sources of randomness
1800.63s - 1806.57s |  till now was unbeatable. So what is happening here? Went back to my terminal and performed
1806.59s - 1813.73s |  some more tests and as you see here uh when the seed capture goes faster we can make some
1813.73s - 1818.71s |  really important observations. Which is that the middle byte of the seed is incrementing by
1818.71s - 1823.71s |  one. My assumptions seemed more correct than ever but I was also more confused than ever. Uh
1825.65s - 1830.55s |  there was some missing piece that I was struggling to find. Some implemented mitigation that
1830.55s - 1837.54s |  was in front of me but could not see it. What this mitigation was? Of course security
1837.56s - 1841.90s |  through obscurity as always with automotive and I started thinking what if the ECU is
1841.90s - 1847.14s |  restricting software power cycles for safety reasons. As we are talking about a telematics
1847.14s - 1853.24s |  unit that has to be always available for SOS calls. And if that's the case how can we
1853.24s - 1858.94s |  control a power cycle in more than uh more ways than an ECU reset? And that's where my
1858.94s - 1865.32s |  favorite re- relay comes into play. And we immediately see not only a duplicate but a
1865.34s - 1872.13s |  complete compromise of the unit here. POC for this will be published under my tool Karen
1874.67s - 1879.83s |  Caribou Next uh but it's nothing that you cannot easily make in a couple of minutes. The
1879.83s - 1883.91s |  main reason that this happens is because there is always a battery in those telematics
1883.91s - 1889.41s |  systems to mitigate downtime and unexpected power cycle that will restrict the unit from
1889.41s - 1894.41s |  performing an SOS uh call during an emergency. So we got a bit pranked for a second there but
1894.75s - 1899.75s |  found a way through eventually. And for the smarties out there that uh this is not only
1902.75s - 1908.77s |  applicable to controlled uh environments with power supplies but many of these nowadays
1908.77s - 1915.01s |  come uh with external on or internal for pass sensor vehicles battery isolators. Mainly
1915.01s - 1921.45s |  used in safety related incidents to cut power and mitigate the risk of fires and other
1921.45s - 1926.99s |  issues. Uh but I used to I used it to bypass restrictions that were only possible on
1926.99s - 1931.73s |  individual ECUs. And now by controlling the power supply externally through the battery
1931.73s - 1937.67s |  isolator we can perform all these attacks in a combined manner in full vehicles. Here we
1937.67s - 1942.91s |  see the exposed battery isolator of heavy duty vehicles. And here we see something I
1942.91s - 1947.89s |  discovered a couple of weeks ago. The battery isolator of a passenger vehicle which of
1947.89s - 1952.93s |  course made me laugh but uh it will make me cry probably in the future when I will get into
1952.93s - 1959.01s |  more politics with the manufacturers about the applicability of my future findings. This is a
1959.01s - 1965.17s |  sample list of the applicable findings for the ECU. And of course I had no response so I guess
1965.17s - 1971.85s |  nothing to see here. But it's not only dark and stormy days. While everything we said now is
1971.85s - 1978.09s |  applicable to most of the OEMs. While this is only a small uh this is only a small subject
1978.09s - 1984.09s |  sub subset of the issues we see every day. And they clearly are some relics of
1984.09s - 1989.77s |  vulnerabilities discovered in modern vehicles and components. And while several CVEs are
1989.77s - 1996.51s |  currently stuck you saw because of uh the unacceptable attitude of the industry. There is
1996.51s - 2001.81s |  always someone that breaks the norm and makes us smile and not because they made everything
2001.81s - 2008.25s |  perfect but because they proved a point. So one small manufacturer came to us for some common
2008.25s - 2013.85s |  service. We started evaluating the unit and after several several tries we didn't manage to
2013.85s - 2019.79s |  discover a single entry point to the custom ECU. While the hardware used was one of the
2019.79s - 2026.43s |  cheapest of the self hardware a developer can buy. And what was the solution in this case? One
2026.43s - 2031.09s |  of the cheapest of the self hardware a developer can buy. And we're talking about this
2031.09s - 2037.83s |  mighty ESP32 a low cost, low power SOC that was fitting perfectly the needs of the OEM in
2037.83s - 2043.27s |  this case. Of course it's not built for safety critical functionality and its main focus is
2043.27s - 2049.85s |  automation. But for the case we needed for for the case needed there was nothing more
2049.85s - 2055.75s |  needed by the OEM in this case. And from a security standpoint it proved a big point. Because
2055.77s - 2061.55s |  this ten dollar ESP32 in contrary to what comes with hundreds of thousands of dollars of
2061.55s - 2067.71s |  automotive uh worth of automotive SOCs comes standard with an RNG. It uses a combination of
2067.71s - 2073.29s |  thermal noise sourced from the hardware analog to digital converter and combines it with
2073.29s - 2078.99s |  the asynchronous clock mismatch for true random generation as we call it in this industry. And
2079.01s - 2084.01s |  I say it again with ten dollars but does it solve completely the problem here? Of course
2086.31s - 2091.73s |  not. There are still ways to bypass these mitigations but the point is how difficult and
2091.73s - 2097.29s |  financially viable you make it for an attacker to perform an attack like this. It's not about
2097.29s - 2101.93s |  how sophisticated an exploit is in the end it's about who has the biggest biggest budget to
2101.93s - 2107.37s |  invest. So the mitigation is clearly about how expensive you make it for an attacker to break
2107.39s - 2113.39s |  into your system, steal your IP or even potentially perform coordinated attacks. And while
2113.39s - 2118.03s |  looking at systems like the PlayStation running non safety critical chips that implement
2118.03s - 2122.87s |  state of the art mitigations for these issues and our computer on wheels cannot even mitigate
2122.87s - 2128.27s |  the basics I'm left to wonder is there any light in the end of the tunnel? And my answer is
2128.27s - 2135.27s |  that it's up to us all of us here to make the best out of it. The best out of our work and our
2135.31s - 2140.65s |  research. To pass out our culture to the people that we're working with. From the higher to
2140.65s - 2146.29s |  the lower level. Not with bitching not with attitudes but with scientific proof with our
2146.29s - 2152.63s |  POCs with our posts and our talks. Let's make the world a safer place one POC at a time. And
2152.63s - 2157.63s |  in honor to this year's theme remember to take back the internet we need to engage. Thank you.
2158.53s - 2186.35s |  Any questions? Hi awesome talk thank you. Um did you think about going to NHTSA the National
2190.79s - 2195.59s |  Highway Transportation Safety Administration who is responsible for implementing safety
2195.59s - 2201.47s |  standards for car manufacturers? Yeah look there are several things that we can do. I agree
2201.47s - 2208.31s |  with you. The problem is that you have to take several steps into reaching a point that I
2208.31s - 2214.01s |  will follow your advice. I mean the specific advice you gave right now. It's like I agree
2214.01s - 2220.99s |  with you but I would expect that the manufacturer already handled it. Of course in many of
2220.99s - 2225.99s |  the cases maybe I did it. I cannot reveal it to you but maybe I did it. But I have to say that
2229.23s - 2233.43s |  there is a need for something to change in this industry and that's what I had to clarify
2233.49s - 2238.49s |  here. Totally agree and it that would be the perfect world wouldn't it if you know people I think
2241.83s - 2246.83s |  most engineers want to do the right thing. They want to operate securely and write good code
2246.83s - 2251.85s |  and and all the rest of it. But then to your point there's that sprinkle of capitalism and um
2254.75s - 2259.75s |  budgetary this and that and somebody says well it's good enough. And then you know that's that's
2260.01s - 2265.01s |  why we do sometimes need those government agencies even though they themselves are not the
2266.35s - 2272.71s |  most efficient right. I agree there needs to be a balance but I think there needs to be a
2272.71s - 2278.79s |  balance in all the ways you know even for who talks where. You know there are the commercial
2278.79s - 2283.19s |  conferences that everyone brags about from the industry. We also need to talk about stuff. We
2283.19s - 2289.57s |  also need to be able to get the stand and start discussing about these things. Thank you very
2289.59s - 2296.00s |  much it was awesome. Thank you. Hi again thank you for the talk. Amazing talk. But um do you
2296.00s - 2301.18s |  think emerging tech emerging technologies such as automotive ethernet or secure CAN transceivers
2301.18s - 2306.32s |  might help mitigate some of the risk? Definitely definitely and we see a change in the
2306.32s - 2310.82s |  industry. As I said software defined vehicles and centralized architecture is something that
2310.82s - 2317.06s |  we we hear about a lot of years now but it's not yet implemented in many vehicles and that's
2317.08s - 2323.04s |  why I was talking about the differences between uh mainstream OEMs and the new type of OEMs
2323.04s - 2327.88s |  that are basically IT companies that started building cars. So this is the main difference.
2327.88s - 2331.76s |  They have way more experience in this but the industry just needs to catch up. They are
2331.76s - 2338.75s |  exposing so many things and they need to do something about it. Thank you. Thanks. Thank you
2338.75s - 2342.11s |  for thank you for your talk. This was great. My question is regarding your tool kit. Is
2342.11s - 2347.09s |  everything you know hand built? Can you? My question is about your tool kit. Is everything
2347.09s - 2352.33s |  Python scripts that you build or is there a software or platform uh that we? Um no basically
2352.33s - 2358.17s |  it's a modular tool and this is not only the POC but you can use it to perform the same
2358.17s - 2364.21s |  attacks to other vehicles. What's the name of that tool? Uh Carrying Caribou Next. Uh it's a
2364.21s - 2368.21s |  fork of the original Carrying Caribou which is a state of the industry for a lot of years
2368.21s - 2373.89s |  but I just made the fork because of uh the slowness of the development of this project. Thank
2373.89s - 2374.93s |  you. You're welcome.


url: https://www.youtube.com/watch?v=G7GwXu684JY
title: DEF CON 32 - Sshamble Unexpected Exposures in the Secure Shell - HD Moore, Rob King
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=G7GwXu684JY",
  "title": "DEF CON 32 - Sshamble  Unexpected Exposures in the Secure Shell - HD Moore, Rob King",
  "description": "The Secure Shell (SSH) has evolved from a remote shell service to a standardized secure transport that is second only to Transport Layer Security (TLS) in terms of exposure and popularity. SSH is no longer just for POSIX operating systems; SSH services can be found in everything from network devices, to source code forges, to Windows-based file transfer tools. While OpenSSH is still the most prominent implementation, it's now just one of dozens, and these include a handful of libraries that drive a wide range of applications. This presentation digs deep into SSH, the lesser-known implementations, many of the surprising security issues found along the way, and how to exploit them. As part of this talk, we will release an open source tool, dubbed \"sshamble\", that assists with research and security testing of SSH services.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2723,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Hey guys, uh, so we're gonna talk about SSH. And this has been probably the most exciting year in
5.75s - 12.59s |  SSH since X2.cd got lea- X2.cd got leaked by Teso. So, um, uh, props to anyone who used that.
12.59s - 17.59s |  Uh, so, uh, SSH for folks who aren't aware, um, you probably, probably should be or if you
17.59s - 21.57s |  don't know what SSH is, but, um, SSH, secure shell, port 22, the thing we've been using to
21.57s - 26.53s |  admin the internet for many years, like almost 30 years. Um, there's really two flavors of
26.53s - 31.09s |  SSH that we use the most. There's OpenSH, which is like 80 something percent of all SSH
31.09s - 35.09s |  installations. And then there's DropBear, which is like another like 5 to 8 percent. And then
35.09s - 39.71s |  there's a long tail of random weird stuff out there. So we decided to do some research into
39.71s - 44.81s |  first looking into the XC backdoor. And then part of that, we just accidentally found a couple
44.81s - 47.67s |  tens of thousands of shells. And we're like, well, let's go figure out what all these random
47.67s - 51.69s |  things, all these free shells were. Uh, and that led to this giant pile of work and this open
51.69s - 55.09s |  source tool. Um, so if you want to play with the toolkit, you can get it right now. It's this,
55.11s - 60.09s |  the shamble.com SSH and BLE. And that goes to GitHub and you can go grab the stuff and play
60.09s - 63.79s |  with it. And it's a big hot mess, but we're making it better. And it should be a lot of fun as
63.79s - 67.89s |  we start cranking on, make the polishing up, making it cool. Um, so with that, we'll go ahead
67.89s - 73.99s |  and get started. Um, fortunately we're only doing 67 slides in 45 minutes, not 100. So we
73.99s - 78.93s |  had a little breathing room this time. Um, so I'm sure we're all very much aware of the XC
78.93s - 82.77s |  utils backdoor. Well, step back a little bit. So there's, you know, four major events this
82.79s - 86.89s |  year in SSH that were really important. Obviously XC utils backdoor targeted SSH using the
86.89s - 92.89s |  system D patches and Debian and, uh, Red Hat builds of OpenSH. We also had the really cool
92.89s - 96.13s |  Terrapin vulnerability, which affected pretty much everything because of the truncation
96.13s - 100.81s |  attack. Um, we also had, uh, the regression vulnerabilities, the really fantastic work by the
100.81s - 105.51s |  Qualys Threat Research Unit. Um, and then the other regression bug found by Solar Designer
105.51s - 109.51s |  that only affected Red Hat. And regression was amazing. It's a signal re-entrance bug that
109.55s - 114.33s |  gets you remote route in OpenSH by default. It just takes six hours on a 32-bit machine or
114.33s - 119.03s |  weeks or months on a 64-bit to compromise. So, but it's been a really cool year. Um, one of my
119.03s - 123.67s |  favorite SSH bugs this year kind of flew under the radar. Um, the guys at Watchtower Labs did a
123.67s - 128.43s |  really cool analysis of the move-it vulnerability that uses the SFTP server. And so they found a
128.43s - 132.41s |  vulnerability where any public key being sent to the service, um, would be treated like a file
132.41s - 136.41s |  path, like the binary blog is treated like a file path. And it just opened random UNC URLs and
136.41s - 139.65s |  all kinds of fun stuff. They threaded like a million little needles to be able to get a shell
139.65s - 142.89s |  remotely and move it. But the really cool thing about that bug is it affected every other
142.89s - 147.79s |  vendor also using IPWorks as the underlying library. So, they actually uncovered like a supply
147.79s - 152.57s |  chain bug, if you will, which is really neat. So, going kind of back on topic again, um, the
152.57s - 158.77s |  XE Utils vulnerability or backdoor was amazing. It was like it's own little Netflix docuseries,
158.77s - 163.57s |  right? We're going to see like the true crime of XE Utils for years. But like who is Gia Tan?
163.57s - 167.41s |  Like it's going to, it's the most dramatic thing to happen to InfoSec in a very long time. Um,
167.41s - 171.11s |  so the, this is a multi-year campaign where this person, um, contributed to open source for a
171.11s - 175.55s |  long time, then eventually kind of twisted the knife and tried to backdoor the world. And I got
175.55s - 180.15s |  caught the very last minute by, uh, Andrews Frond who says, hey, my SSH is taking slightly too
180.15s - 183.89s |  much longer than it should. And then unraveled the whole thing right before it got put into the
183.89s - 188.19s |  stable distributions. So, we got really close to the whole internet being backdoored. Uh, but
188.19s - 191.67s |  what was really important about that backdoor that it was a nobody but us backdoor, which is
191.67s - 194.97s |  normally, you know, normally the US government's famous for those. But in this case, who
194.97s - 199.51s |  knows who it was. Um, in fact, it was a encryption key controlled by the attacker that only
199.51s - 202.91s |  people with a private key had access could abuse the backdoor. That was really a neat thing
202.91s - 207.65s |  about it. So, we thought it'd be fun to go figure out who this Gia Tan person was. And we're
207.65s - 211.89s |  like, hey, you know, everyone's looking for Gia Tan, we're going to go find some Gia Tan. Uh,
211.89s - 215.15s |  and we're very happy, Alfredo, if you're out here, thank you so much for designing your
215.15s - 220.87s |  graphics. They're amazing. Um, so we decided to go hunting. And, you know, before we go
220.89s - 225.67s |  hunting for Gia specifically, we want to talk a little bit about SSH protocol. So, uh, Gia Tan
225.67s - 230.71s |  targeted SSH, uh, with ex- with ex-utils backdoor. So, we're going to target Gia Tan using
230.71s - 236.19s |  SSH. But before we go there, we need to talk about how SSH public key authentication
236.19s - 240.15s |  works. So, SSH public key authentication is two stage. The first thing you do is say, hey
240.15s - 244.19s |  server, would you accept this public key for this username on your machine? And it says, yeah,
244.19s - 247.89s |  sure. And then you have to sign this big blob of data that proves that you have the private
247.89s - 251.29s |  key. But you can do that first part without the private key at all. And it's really cool.
251.31s - 255.01s |  There's been a module in Metasploit for it since 2012, lets you take someone else's public key
255.01s - 258.15s |  that you got however you got, and then check a bunch of servers to see whether that public key
258.15s - 261.19s |  has access to, uh, those servers for that username. And you can, so you can kind of see
261.19s - 264.75s |  where this is going. Um, it's, there's this great common or open SSH saying, is this a
264.75s - 267.63s |  problem? I don't know. But it's been there forever. It's just kind of the protocol spec at
267.63s - 271.33s |  this point. It is what it is. Maybe it's not a big security deal. So, we decided to create
271.33s - 275.03s |  this thing called Shamble, which started off being a half-off scanner for SSH. So, what we
275.03s - 278.67s |  do is you take a bunch of public keys, and then you'd like put them in Shamble and scan the
278.69s - 283.19s |  whole internet saying, what on the internet can you access using these public keys? And the
283.19s - 287.53s |  idea is like, well, if we have, let's say, Geotan's public key, we can find all the servers
287.53s - 290.23s |  that they use, and then from there we figure out who they are. So, that was, that was the
290.23s - 294.31s |  idea. But it ended up evolving into this massive tool to find all kinds of other crap
294.31s - 297.61s |  because of all the things that we found. So, you know, first thing you do say is, hey, my
297.61s - 300.95s |  name's Geotan, we're gonna go download your GitHub keys. So, we grabbed their two GitHub
300.95s - 305.51s |  keys, which are still present today, um, and basically took those two public keys, ran them
305.53s - 309.69s |  to Shamble, and then, um, you know, threw that at the whole internet, all the, all the SSH
309.69s - 314.07s |  daemons we could find, let it grind out for a couple days. And what's, what's exciting about
314.07s - 316.77s |  it is like, we spent the whole weekend on this, we hadn't slept or anything like that, Rob and
316.77s - 320.41s |  I were like working at four in the morning, we're like, we got one, we got a hit for GEA. It's
320.41s - 324.35s |  really exciting. Um, in the meantime, we're melting all of our DigitalOcean nodes, so this
324.35s - 328.09s |  is this poor little DO droplet just like falling apart as we're like destroying it. It's, I
328.09s - 332.79s |  think it sent like a terabyte of traffic at this point, like we're, yeah, we made DO VMs
332.81s - 338.41s |  very unhappy. Um, so, just heads up for law enforcement, um, we sent the public key for
338.41s - 343.05s |  GEATAN to every server on the internet from our IPs. We are not GEATAN, we do not backdoor
343.05s - 346.79s |  exe-utils, even though it very much looks like we did. So we sort of accidentally framed
346.79s - 351.39s |  ourselves, uh, we realized that after the fact that we probably might, I'm sure the long-arm
351.39s - 354.37s |  law will catch up at some point, like, you guys, you're GEATAN, like 10 years from now, and
354.37s - 360.33s |  like, yeah, we are not, sorry. So, um, unfortunately, like every single result we found
360.35s - 363.41s |  that we thought was GEATAN was a false positive. It was like a buggy server with like the
363.41s - 367.09s |  memory was corrupted or the service would accept every fifth public key or every third
367.09s - 370.99s |  public key. So we had to say, okay, let's try a bunch of random public keys and if you reject
370.99s - 375.93s |  all those, now try the GEAT key. And let's try like an RSA key, an RSA 1024, 2048. We've
375.93s - 379.49s |  still found devices that are just randomly accept or randomly not accept keys and it just
379.49s - 383.43s |  drove us crazy. So we finally fixed all these bugs, re-scanned, re-scanned, re-scanned, uh,
383.43s - 387.31s |  you know, clicked all those DigitalOcean abuse notices, says, yeah, we're good, our server's
387.31s - 391.85s |  not compromised, we're cool. Um, and we still found no GEATAN. So whoever this, you know,
391.85s - 395.59s |  actor was, they had really good OPSEC, we found nothing, so good job them. Um, but we did
395.59s - 399.23s |  find like thousands of free shells. So we're like, how come we're getting all these random
399.23s - 403.53s |  shells on all these random machines? And that's really what this talk is, is about. Uh, so
403.53s - 408.47s |  with that, um, a little bit of a detour. So an SH, um, public keys used to not be something
408.47s - 411.37s |  that you actually made public. They used to be something you kind of kept privately in your
411.37s - 415.11s |  .SH directly and you copied to a server here and there. But, um, in the last five or six
415.11s - 420.55s |  years, we've seen people using, uh, SH keys like identities. So just like people used PGP back
420.55s - 424.05s |  in the day, you can now use SH keys as your identity when you're installing a Ubuntu server.
424.05s - 426.89s |  You can tell it to grab your key from GitHub or from Launchpad and automatically give you
426.89s - 432.79s |  access to your server during installation by username. Um, you can also, uh, um, use these
432.79s - 436.69s |  keys for things like, uh, OJ encryption. So if you use the OJ tool or H tool, you can use it
436.69s - 439.83s |  almost like a PGP key now these days as well. So there's all kinds of cool stuff you can do
439.83s - 443.57s |  with, uh, SH keys you didn't before. But the key thing here is like, keys are effectively
443.57s - 447.37s |  public if you use any of these major platforms. And literally public. So there's this great
447.37s - 451.25s |  little, uh, daemon by Filippo where you SSH into it, it'll say who you are. It'll use the
451.25s - 454.67s |  public key you send to the server, dock to you based on the GitHub database and say, oh,
454.67s - 458.65s |  you're so and so, welcome. So it's kind of a fun little trick. And effectively we're doing
458.65s - 462.39s |  that, but at scale for the whole internet. So if you want to link a user to a particular key
462.39s - 465.89s |  on a particular server, you need, um, one, a list of all the SH servers out there. So
465.89s - 469.45s |  ZMAP, Mascan, dump it from Shodan, whatever you want to do to get the list. You want a list of
469.45s - 472.77s |  all the public keys, so you go grind all those out of GitHub through their BigQuery API,
472.79s - 476.67s |  about 117 million users as of about a month ago. Uh, Launchpad's got a bunch of users too.
476.67s - 480.13s |  You get all their keys too, why, why not? And then Bad Keys is a great project by, uh,
480.13s - 483.91s |  Hanno Bach, um, that allows you to, that keeps track of all the compromised keys out there.
483.91s - 487.31s |  So you can look for keys that give you access to the system. And then lastly, you need a list
487.31s - 491.25s |  of common usernames the user might have, like root, ec2 user for cloud, Ubuntu, et cetera,
491.25s - 494.99s |  or whatever the comment is in the key. So one of the nice things about GitHub is that when
494.99s - 498.25s |  you upload your public key to there, they actually preserve the comment field, which is
498.25s - 501.39s |  typically your, your username when you uploaded the key. So you know what their default
501.41s - 504.09s |  username is. So if you're trying to find like their server someplace, you can pull it out of
504.09s - 507.85s |  the comment, use that to talk to the user and so on. So you, you take this nice little recipe
507.85s - 512.89s |  and you throw it in the oven and, um, it gives you a nice little primitive to take one key and
512.89s - 515.89s |  check lots of servers really fast. Like you can grind through all the servers on the internet
515.89s - 519.83s |  in like an hour or something like that on a single box. It's pretty quickly just for one key.
519.83s - 522.73s |  Um, but if you want to test, um, so that works great if you're looking for like a geotan
522.73s - 526.87s |  everywhere. But what if you want to say for this server on the internet that's acting fishy,
526.87s - 531.11s |  which GitHub user has access to it? And do the other way, check all 117 million keys on
531.13s - 534.67s |  one server. Well, that's a very different attack. This is like, you know, a duck-sized horse or
534.67s - 538.43s |  horse-sized ducks, you know, kind of approach. So if we want to test a million keys against,
538.43s - 542.87s |  uh, a single server, it's a little bit tougher because, uh, SH will slow you down. Uh, they
542.87s - 546.31s |  have, uh, this thing called max auth limit, which is how many tries you can authenticate
546.31s - 549.25s |  before it kicks you off of that connection. And there's a max connection limit, so you can
549.25s - 552.89s |  only do so many of those at once, right? So the idea is that with OpenSH, if you try to
552.89s - 556.49s |  brute force keys, you get four into it and it knocks you out and you can't auth anymore. So
556.49s - 559.69s |  if you've ever had more than four keys in your SH, uh, agent and you try to shell out a
559.71s - 562.81s |  machine and it just immediately says, you know, too many tries, that's why. It's because you're
562.81s - 568.05s |  hitting the max auth limit of OpenSH. However, um, OpenSH is the only one that does that.
568.05s - 572.35s |  Everything else lets you just bang keys all day long. So DropBear lets you just grind keys as
572.35s - 576.19s |  fast as that little device can, can test them. Um, also a lot of commercial products like
576.19s - 579.83s |  BitVise, GlobalScape, Maverick, LanCom, all this stuff, all their SH daemons do not care.
579.83s - 583.43s |  They'll let you just try every possible key in the world until, until you're done. It's great.
583.43s - 586.03s |  Uh, we emailed the DropBear folks, they didn't care, they didn't even bother replying, so
586.05s - 590.91s |  like, it's not really a bug, it's a feature. So we like that feature. So, uh, with the
590.91s - 594.95s |  shamble code you mentioned before, we tested the GitHub, like 4.6 million key database at the
594.95s - 599.19s |  time, and you can do about 10,000 keys per second on a DropBear box on an embedded node
599.19s - 602.25s |  without it spiking the CPU on the target device at all. It just doesn't even care. It's like
602.25s - 605.99s |  super fast. So it doesn't even murder the machine. And this is 10,000 keys per second per
605.99s - 610.53s |  connection, and DropBear is typically configured with 15 connections. So you can do 150,000
610.53s - 614.83s |  keys per second on a machine for pub key testing to dock someone's server. So if you see
614.83s - 618.27s |  someone like hitting you on a random box and SH is open, just go take all the keys and give
618.27s - 622.15s |  it, like yeah, you jerk, stop that. And just email them, like quit it. Like, it's really,
622.15s - 625.85s |  really easy to dock to your hackers. And if you're running an SH honeypot, and your SH
625.85s - 629.29s |  honeypot collects the public key being sent to you, you can turn around and flip that on
629.29s - 632.79s |  them again and immediately figure out who they are. Like, people forget all the time that
632.79s - 635.39s |  their SH agent's configured, and they're sending their public key to every server they
635.39s - 638.53s |  connect to. Even if their agent is not authenticating to it, they're still automatically
638.53s - 642.53s |  sending that public key as a test whenever you touch anything. So if you're a, a lead hacker
642.53s - 645.31s |  and you've been just SHing to random machines on the internet, you're also sending your
645.31s - 650.87s |  public key identity to all those machines, and if they're logging in, you're a host. So, um,
650.87s - 654.91s |  by contrast, if you try the same attack against OpenSH, you can do 132 keys per second. So
654.91s - 659.49s |  it'll take you 10 hours to do the same 4.8 million keys with a single connection. So, um,
659.49s - 663.69s |  obviously the OpenSH approach is much nicer, um, but it's great if you're trying to, um,
663.69s - 667.09s |  ad- ad- docks people. So, uh, with that, I'll hand it to Rob to talk about shaking out
667.09s - 672.09s |  shells. Testing, testing. Testing. Testing, testing. Hey, alright. So, shaking out shells.
676.87s - 681.87s |  Say that five times fast. Um, what we did with Shamble is it resulted in, uh, around 27
684.45s - 690.15s |  million devices on the public internet that are listening on port 22. We got another, you
690.15s - 694.55s |  know, 14 million or so that actually negotiated, uh, SSH off, and we ended up with about
694.55s - 699.55s |  110,000 sessions. Um, what's really interesting about SSH, so SSH, uh, especially OpenSSH
701.55s - 708.24s |  has done an immense amount of work in- do what? Oh, sorry, front mics are hot. Uh, so-
712.26s - 717.26s |  sorry. So, uh, we ended up with, um, about 110,000, uh, that are actually listening and we
719.12s - 723.50s |  were able to get sessions. What's fascinating about OpenSSH is- or SSH, is that there's a
723.52s - 729.36s |  fairly large post-authentication attack surface. So, SSH does lots of things. You can create
729.36s - 733.70s |  tunnels, you, uh, can create pseudo terminals, there's subsystems, there's all sorts of things
733.70s - 738.88s |  that are running on, uh, SSH once you're inside. Uh, it kind of assumes that once you've
738.88s - 742.94s |  authenticated you're okay, but there's an immense, uh, an immense amount of systems out
742.94s - 747.94s |  there that actually will do this interesting post-auth-auth. So, you authenticate, uh, non-authentication
748.20s - 753.20s |  with LeftBeef and you get in and then it actually gives you a secondary authentication mechanism.
756.24s - 760.48s |  It'll prompt you for a username and then a password, but you're inside the session at that
760.48s - 763.54s |  point. So, you can start doing some interesting things. This is one of the- the interesting
763.54s - 769.12s |  cool things that- that Shamble will do. Um, you can say, oh, okay, uh, I can send signals, I
769.12s - 775.22s |  can send, uh, SIGWINCH, I can, uh, forward X11, things like that. And you can see there's a
775.24s - 781.72s |  fair amount of large, uh, devices, uh, popular devices out there that do this post-auth-auth.
781.72s - 787.22s |  So, you can see you've got, uh, SonicWall firewalls, um, Juniper network devices. You can
787.22s - 791.16s |  SSH in with AuthNone and then it'll give you the secondary one. That, uh, that smaller one,
791.16s - 794.70s |  the PleaseLogin, that's, uh, a ruckus one that HG's gonna talk about here in a minute.
794.70s - 799.70s |  That's super, uh, super fascinating. But it's worth noting that there is this post-auth attack
800.46s - 805.46s |  service that is kind of not considered, but is exposed. So, and with that, with sort of the
807.70s - 812.60s |  first one that you can talk about is signal injection. I'm gonna pass it back to HG for that.
812.60s - 814.60s |  Did we get the second mic working?
814.60s - 816.94s |  Cool, thank you. Sorry, I just wanted to stay away from the front mic so we don't get
816.94s - 821.54s |  feedback here. Um, so, uh, Rob mentioned that one of the things you can do to a post-auth
821.54s - 826.52s |  session is, uh, inject signals into the process before you've fully authenticated. So,
826.54s - 830.44s |  effectively, you can connect to a machine, it'll pass through the authentication from
830.44s - 834.44s |  SSH, Auth equal None, and then drop you to a real login shell and it'll say, PleaseLogin.
834.44s - 838.76s |  And you can just say, Signal Sec V, and it goes, ah, and dies. Which is a lot of fun. So,
838.76s - 841.62s |  effectively, you can just, you know, we talk about regression being signal re-entrance.
841.62s - 844.62s |  This is just signal entrance. You just bang signals all day long into whatever process you
844.62s - 848.56s |  want and see what terrible things fall back out of it. So, uh, we didn't get too far into
848.56s - 850.80s |  this testing, but we've put, there's all kinds of fun things that come out of it. You can
850.80s - 853.90s |  send a SIGINT request, you can pass Python scripts that are part of the login shell to
853.92s - 858.52s |  crash. Uh, you can do SIG alarms, SIG childs, SIG ills, SIG aborts, you can pass core dumps,
858.52s - 862.62s |  uh, all kinds of crazy stuff you can just do with signals. And OpenSH tries to protect you a
862.62s - 866.80s |  little bit by limiting things like SIG Sec V, SIG abort, and so on. Uh, but DropBear does
866.80s - 869.60s |  not. DropBear is like, anything that you can possibly send me, I'll treat as a signal and
869.60s - 872.76s |  deliver to the process. Thank you. Um, so there's a lot of really cool attacks that we think
872.76s - 876.44s |  you can do there and we're gonna start working on expanding the shamble code to then basically
876.44s - 880.44s |  just mash symbols into random processes so you get a shell. And, yeah. Um, with that, hand
880.48s - 885.82s |  it back to Rob, talk about TSP forwarding. I, I do always love that, uh, DropBear is like,
885.82s - 889.16s |  I, you know, it's like, if it were dying, it wouldn't be dictating, right? It wouldn't be
889.16s - 895.16s |  writing it out, it would just say IE, but no. Um, but another part of this post-auth, uh, uh,
895.16s - 901.90s |  attack surface is forwarding, right? So SSH allows you to generate or create tunnels, uh, you
901.90s - 905.60s |  know, through channels and create encrypted tunnels. It's almost like a little miniature VPN
905.60s - 909.84s |  thing. And this is a pretty popular and common, uh, feature. But once you've po- once you're
909.84s - 913.02s |  in this post-auth situation, you can start doing that. You can start creating these things
913.02s - 917.92s |  on a lot of these systems. Um, many of them will administratively restrict you from doing it
917.92s - 923.46s |  or they'll only let you go to certain things, but for example, uh, uh, you can say, OK, well
923.46s - 927.70s |  I'm gonna try to forward to this particular host or I'm gonna try to forward to a local host
927.70s - 932.64s |  and do a loopback. Um, and we actually found, uh, this is an ION, yeah, OK, good, the chip's
932.64s - 939.30s |  blank. Uh, this is a, an ION network's access point and you can see that it's trying to, uh,
939.34s - 946.04s |  forward to Google.com and it, it gets rejected. And then it's gonna try, oh, and by the way,
946.04s - 950.68s |  this is the shambles shell, uh, which I love. Um, and it'd say, oh, I'm gonna try to get
950.68s - 955.86s |  88888, but then you can actually forward back to local host. You can actually use that to
955.86s - 961.12s |  get around restrictions and things like that once you're in this sort of, uh, uh, mystery,
961.12s - 967.46s |  uh, uh, post-auth shell. But the big, the big one is shell injection. I'm gonna let
967.46s - 971.84s |  Jason take this one cause this is super cool. One thing that was kind of fun about this is
971.84s - 975.40s |  that we found bugs that like we shouldn't have found. Like because of this post-auth
975.40s - 979.38s |  sequence, effectively you SH to the machine and instead of asking for a password, you just,
979.38s - 982.34s |  it drops you straight in, but it drops you straight into a secondary shell. And that
982.34s - 985.48s |  secondary shell has its own bugs. So we kept finding these vulnerabilities in these
985.48s - 989.06s |  secondary shells that no one had found before, even though they were like stupid. Like we
989.06s - 993.02s |  found so many dumb bugs just because no one really tested that level of the protocol. So
993.02s - 998.60s |  in this case, um, we're ran across these like ruckus access points and you SH them. There's
998.60s - 1002.00s |  about 36,000 of these suckers exposed on the internet. About 900 are vulnerable to this
1002.00s - 1006.90s |  particular attack still right now today. And it asks you for a username, you type in root, you
1006.90s - 1009.44s |  type in, you start entering your password and for your password, you just type in like
1009.44s - 1012.40s |  dollar parenthesis, whatever command you want to run, right? And it's redirected back out to
1012.40s - 1015.38s |  standard error so you can see the result. And it just runs this route for your life. It's
1015.38s - 1019.74s |  great. Um, so we'll, we reached out to ruckus of course, like, Hey, what's up? Like you guys,
1019.74s - 1023.28s |  is this a new bug? Is this a fixed bug? We can't really tell what's patched. Like, Oh yeah, we
1023.28s - 1026.58s |  patched that already. I'm like, did you tell anyone? Nope. They didn't tell anyone. There's no
1026.58s - 1029.92s |  CV, you know, security note whatsoever. So of course no one's applying patches because they
1029.92s - 1033.68s |  didn't know they had to apply the patch. Um, so they've got two different tracks, the 521 and
1033.68s - 1037.28s |  the 61. Those both fix it. But there's, you know, still about, you know, almost a thousand
1037.28s - 1041.02s |  folks out there still running unpatched up. But the question was like, why did this bug live so
1041.02s - 1044.60s |  long? How did we end up with this? Like a stupid login prompts, like password character
1044.60s - 1048.20s |  injection. And it's because there's behind this SSH off layer that no one really bothered to
1048.20s - 1051.76s |  test it. Like all your folks who normally hit a telnet prompts, something like that, just
1051.76s - 1056.24s |  hadn't tried this SSH post off attack. So we uncovered this whole like layer of bugs that
1056.24s - 1059.88s |  really should have been found 20 years ago, but they were just hiding behind this extra SSH
1059.88s - 1063.38s |  layer. Uh, and that's one of the interesting kind of side effects of this work. So here's an
1063.38s - 1068.14s |  example of us, uh, rooting one of these random ruckus boxes. SSH in with all the, I don't care
1068.14s - 1073.22s |  about my cipher stuff. Please log in or OOT. And then for the password, we're just typing in
1073.24s - 1078.78s |  $PSAUX-W and getting a big process listing. And the funny thing about it is you can actually see
1078.78s - 1083.02s |  the echo command in the PS listing showing that it's going to shop 256 sum. That's how they
1083.02s - 1086.46s |  check your password. So they fixed it just by putting in proper quotes, but whole thing is
1086.46s - 1090.10s |  ridiculous. So it's amazing like how many dumb bugs are out there. If you just go a little bit
1090.10s - 1093.40s |  further into the protocol stack and back to Rob for the permit.
1095.46s - 1100.30s |  So SSH, you know, is the secure shell. It's designed to talk as your shell. It replaces
1100.30s - 1105.42s |  Telnet and RSH and all that. And it lets you set environment variables. Um, environment
1105.42s - 1109.60s |  variables are used to control the execution of things and, you know, keep track of environment
1109.60s - 1115.00s |  and all that. And a lot of, uh, SSH implementations will limit what you can send, but a lot
1115.00s - 1119.74s |  won't. Um, there's been a, uh, and it's configurable. Of course, some will, you can say,
1119.74s - 1124.84s |  I accept these environment variables, don't accept these. So there's been this renaissance in,
1124.84s - 1129.78s |  uh, Gitforges lately. There's a ton. There's, there's GITI, there's GOGS, there's a, I always
1129.80s - 1134.46s |  pronounce this wrong, FORGEHO. Tell me if I'm saying that right. Garrett, things like that.
1134.46s - 1139.04s |  And they are using these embedded SSH libraries that speak the SSH protocol. And these
1139.04s - 1143.28s |  libraries, because they're, you know, designed for general use, they will accept, you know,
1143.28s - 1147.88s |  any environment variable you send. And they rely on the client, the user of the library, to,
1147.88s - 1154.56s |  uh, limit what is going on. Um, and so that's generally okay. Like a lot of them do it
1154.56s - 1159.84s |  correctly. Uh, for example, GitLab, GITI, FORGEHO, they will only accept Git protocol as,
1159.84s - 1163.88s |  uh, an environment variable. And that's a, something that's looked at by Git to negotiate
1163.88s - 1167.18s |  protocol versions. So you can say, oh, I want to use Git protocol version two or whatever.
1167.18s - 1170.82s |  But for example, there's still some vulnerabilities there. If you were using a version of one
1170.82s - 1174.52s |  of these, these are all written in Go, and it was compiled using a version of Go prior to
1174.52s - 1180.56s |  1.19.3, which is a year or two old, um, on Windows systems, they don't properly sanitize
1180.56s - 1183.86s |  the, uh, the value of the environment variable. So if you put a null in there, you can
1183.90s - 1188.94s |  actually just inject arbitrary environment variables, which is, uh, super fun. But, um,
1188.94s - 1193.94s |  there was another one that was really interesting in, uh, GOGS, where whenever it gets an
1193.94s - 1198.44s |  environment variable, it actually runs the env command. And so the point of the env command
1198.44s - 1202.88s |  is to start a new process, um, with a, a new environment with, you know, setting certain
1202.88s - 1207.68s |  environment variables or whatever. And it starts a new process. It doesn't affect the
1207.68s - 1213.72s |  environment that you're in, right? It, it, that's not how POSIX works. So you could
1213.72s - 1218.36s |  just say, okay, well, I want to set an environment variable with, you know, daset, dash
1218.36s - 1224.76s |  S A equals B, and then, you know, bash or, you know, touch temp foo or whatever, and you
1224.76s - 1228.46s |  are just executing arbitrary commands. And we, we did reach out, there's, there's no
1228.46s - 1234.44s |  patch for this, uh, it's, seems moribund, so maybe don't use it. Um.
1235.00s - 1238.94s |  this one too. Um, this is a great example of like parallel discovery. So not, not in the
1238.94s - 1243.68s |  court sense, but in the, uh, we reported this vulnerability on like April 24th and Sonar
1243.68s - 1247.28s |  Research had reported the same bug to the same maintainer on the 22nd and they scooped us on
1247.28s - 1250.68s |  the advisory. We both had our own separate GitHub advisories, but it's just hilarious. So
1250.68s - 1254.06s |  we both managed to look at the same bug at the same time. So it's funny like how often that
1254.06s - 1257.32s |  happens. And this is a great example. So props to the Sonar source folks for beating us by
1257.32s - 1261.16s |  two days. Uh, and they did a really great blog post about how the bug works, but it, it
1261.16s - 1263.80s |  almost looks like a backdoor cause this doesn't actually influence the environment of the
1263.80s - 1269.30s |  subprocess. It's just a straight command exec pre-auth. So it's a, it's a funky bug. Yeah.
1269.30s - 1274.34s |  Yeah, exactly. Thank you, HG. Um, so going back to these, uh, these libraries. So for
1274.34s - 1279.18s |  example, uh, Apache Mino, which is a Java, uh, implementation of SSH will accept any
1279.18s - 1285.24s |  variable you want. Um, and most of the time, uh, it doesn't really run into anything, but
1285.24s - 1288.58s |  this is, this is maybe my whole, this is maybe my favorite thing that we found, uh,
1288.58s - 1292.98s |  personally. Uh, so there's this piece of software called SoftServe and it's designed to
1292.98s - 1299.32s |  build, um, get repos and it gives you this beautiful, uh, SSH or, you know, CLI, you SSH
1299.32s - 1304.26s |  and you control it, you can do whatever. And it uses, um, the charm bracelet SSH, uh,
1304.26s - 1309.36s |  library, which is built on top of goes SSH. Um, and it will accept any environment
1309.36s - 1313.76s |  variable or it did. We reported it, they fixed it. This is our CVE, go us. Um, but what's
1313.78s - 1320.56s |  fun is you can, first off, watch how slow I am when I'm typing in a, in GIF form, but, um,
1320.56s - 1325.82s |  you can, uh, we just basically created some shellcode and we checked it into LFS and you
1325.82s - 1329.50s |  can actually do this in lots of different ways. LFS just, uh, get LFS as large file
1329.50s - 1332.96s |  storage. It, it just makes it to where it's not compressed and, uh, the file name is
1332.96s - 1336.18s |  predictable so we don't have to worry about it too much. Uh, makes it easier to exploit.
1336.18s - 1341.18s |  We push it up to, uh, to SoftServe and then, uh, doing the SHA 256 sum of our shellcode
1343.78s - 1347.12s |  because that gives us the, uh, the file name that we can, you know, guess. And then we
1347.12s - 1352.12s |  just set LD preload to our shellcode and we now have, you know, shell on that system. So
1353.66s - 1357.26s |  that was super fun. Uh, I, I always love when I get a shell and I'm just like, oh, this is
1357.26s - 1360.70s |  great, you know? Uh, so that made me really happy. And these, uh, these folks were really
1360.70s - 1365.24s |  super cool to work with. Um, we, uh, we disclosed that and they were very, very nice.
1365.24s - 1372.24s |  Uh, but now moving on to, uh, broken states, which is the SSH state machine to HD.
1372.26s - 1376.30s |  Thanks. Um, another fun thing about the SoftServe side. So that particular exploit, um,
1376.30s - 1380.14s |  because it's using Git LFS, you can reference a raw file on disk and you don't have to know
1380.14s - 1383.40s |  your file location. You can use relative paths and stuff. But this works just fine for
1383.40s - 1387.04s |  unauthenticated Git access too. So if you're running SoftServe for read-only access, you can
1387.04s - 1390.08s |  still exploit it. It just requires jumping through more hoops because you can specify LD
1390.08s - 1394.18s |  preload, LD load library. You can set LD library debug output paths. There's a million ways
1394.18s - 1397.98s |  you can, like, eventually get a file onto disk to then load or to trigger a shell script.
1397.98s - 1401.62s |  Just LFS was the quickest way to be like, yes, we're loading arbitrary code. So it, right
1401.64s - 1405.04s |  access to the repo is not a requirement to exploit SoftServe. And there's still about 10
1405.04s - 1407.88s |  of those suckers hanging out on the internet right now that are exploitable. So if you're
1407.88s - 1412.52s |  quick, they're yours. Um, kidding. But, um, so I'll talk a little bit about the SH state
1412.52s - 1416.72s |  engine. So SSH is like incredibly complicated in terms of how it makes you go through these
1416.72s - 1419.92s |  different states to get to each phase of the protocol. The stuff you're mostly familiar
1419.92s - 1424.36s |  with is like when you first connect to the port 22, you'll see like SH-2.0, uh, server
1424.36s - 1427.70s |  banner, things like that. If you happen to send the same manner back to it or you connect
1427.70s - 1431.04s |  a dropper, then you'll get this big blob of stuff with no delimited strings, which have
1431.06s - 1434.66s |  like ciphers and Macs and algorithms, things like that inside of it. So all that's kind of
1434.66s - 1439.46s |  during the, uh, server version exchange and the key exchange. Um, the SH daemons are very
1439.46s - 1443.74s |  clear that they will only accept a certain range of message values for each state. So before
1443.74s - 1447.34s |  you've done the, uh, version exchange, you can't do the key exchange. Before you do the key
1447.34s - 1451.48s |  exchange, you can't do authentication exchange. And this is enforced two ways. The protocol
1451.48s - 1455.84s |  itself has a range of values allowed for each state. So values 1 through 49 are allowed in
1455.84s - 1460.12s |  state 1, 0 to 79 in state 2 and so on. So if you're trying to like just open a channel or
1460.16s - 1463.14s |  open a shell, technically there's no even message handler for it because it hasn't even
1463.14s - 1466.54s |  configured the state handler to even accept that type of message yet. But that depends very
1466.54s - 1470.14s |  much on the implementation. Uh, DropBear and OpenSH are really good at keeping a big
1470.14s - 1473.98s |  command table. And when they go to another state, they just remove that command table
1473.98s - 1476.82s |  handler for the previous state. So there's really no way to like accidentally call the
1476.82s - 1481.08s |  wrong function pointer. Um, and that mostly works the way you expect. What's also
1481.08s - 1484.86s |  interesting here is everything after the key exchange, of course, is encrypted. So SH is
1484.86s - 1487.92s |  kind of like TLS in a lot of ways in that you have your normally version exchange, key
1487.96s - 1491.10s |  exchange, algorithm, Tiffy Hellman type thing, and then you have like your encrypted
1491.10s - 1494.90s |  transport. And that's where all the fun stuff happens, like authentication, your banner, if
1494.90s - 1497.64s |  you will. Like if you ever see a pre-auth banner in SH, it's actually being sent over the
1497.64s - 1500.98s |  encrypted connection, not over the on-auth connection. So typically when you're talking
1500.98s - 1503.34s |  about an SH banner, you're not talking about the version string, you're talking about the
1503.34s - 1507.14s |  pre-auth big blob of data that it sends you when you try to authenticate. Um, so lots of
1507.14s - 1510.62s |  cool stuff happening there, but you can see the state engine is pretty complicated. Um,
1510.62s - 1513.72s |  what's also worth pointing out here is there's something called a larval session. So that
1513.72s - 1518.16s |  means you've successfully authenticated, or maybe not, and it's the state of your shell
1518.16s - 1521.60s |  before there's a shell. So effectively, if you haven't created a sub-process yet, you're in
1521.60s - 1524.84s |  this kind of like larval state, and that's how the code generally references it. And that's
1524.84s - 1529.00s |  important when we start getting into some of these other exploits. So a historic example
1529.00s - 1533.58s |  where this has gone wrong is libsh. In 2018, someone reported vulnerability where this
1533.58s - 1536.98s |  library is used for both client and server side. Same with opensh, same with dropper. They
1536.98s - 1540.62s |  kind of share the same code base for both halves of the protocol. Um, and if you sent the
1540.62s - 1543.92s |  user-authenticated succeeded message from the client to the server, the server's like, oh,
1543.92s - 1547.32s |  okay, cool, you're in, and that's fine. Um, and there's still a bunch of these libsh
1547.32s - 1550.36s |  implementations out there that'll just drop you to a shell if you send user-auth success, and
1550.36s - 1554.64s |  of course, you know, Sham will test for that and makes it easy for you to use it. Um, so we
1554.64s - 1558.54s |  decided to take this up another level. Instead of just saying, let's just send a fake success
1558.54s - 1562.30s |  message, let's just try to get a shell everywhere. Let's take every single part of the
1562.30s - 1566.14s |  protocol transition and say, let's do half-auth, let's do full-auth, let's do a fake pubkey,
1566.14s - 1570.32s |  let's do a password, let's do a password none, let's do even before sh user-auth command at
1570.32s - 1573.62s |  all. And between every one of those attempts, we're gonna ask you for a shell. We're just
1573.62s - 1575.76s |  gonna be like, how about a shell now? How about a shell now? How about a shell now? How
1575.76s - 1579.60s |  about now? Um, and it worked. Like, we got crap loads of shells from random devices because
1579.60s - 1583.30s |  we asked them in weird states to give us a shell. So there's some out there where you don't
1583.30s - 1586.16s |  even bother even starting the authentication process and it gives you a shell. There's some
1586.16s - 1588.86s |  out there where you start the authentication process but don't finish, it gives you a shell.
1588.86s - 1592.80s |  Like, it's all over the map. So, um, there's three good examples we talk about here. First
1592.80s - 1597.34s |  one is the Digi transport, uh, gateways. They're mostly using, like, ICS environments. They're
1597.34s - 1600.70s |  kind of, like, out in the field, hard and stuff. They act as, like, kind of the VPN router, if
1600.70s - 1605.68s |  you will, for all the, all the juicy OT stuff you want to hack behind it. Um, so having a
1605.68s - 1608.78s |  remote admin to these means you basically have serial port access to all the stuff behind it,
1608.78s - 1611.44s |  which is great. So if you want to, like, blow up pipelines, things like that, that's how you
1611.44s - 1615.62s |  do it. Um, so the Digi team was really cool. They were great to work with. Um, this device
1615.62s - 1618.72s |  had already been, like, basically effectively legacy and retired, but it's still up for
1618.72s - 1621.92s |  maintenance on screen patches. Like, they had to go find, like, the one developer who hadn't
1621.92s - 1624.80s |  looked at this thing in five years and dust off their compiler and try to figure out how to
1624.86s - 1627.66s |  build the damn thing and all that. And the funny thing about this is it ended up being an
1627.66s - 1633.10s |  un, uh, an uninitialized variable in the SH engine. So it took us forever to repro, because
1633.10s - 1636.14s |  we'd say, hey, we can get shells on, like, all these machines on the internet. Like, here's a
1636.14s - 1639.64s |  bunch of them, here's the serial numbers, like, it's bad, go fix it. Like, we can't repro. I'm
1639.64s - 1642.78s |  like, you gotta be kidding me. Like, just run the command. Like, what are you doing wrong?
1642.78s - 1646.74s |  Like, it's run command, what's doing, it was not their fault, of course. It's that when they
1646.74s - 1650.02s |  were setting up the machine to test, they were logging in for the rest of the age first and
1650.02s - 1653.02s |  setting up their monitoring on it, and then they'd run our exploit and it wouldn't work.
1653.04s - 1656.28s |  Because the uninitialized variable had been set. So just one of those things was, like,
1656.28s - 1659.38s |  freaking Heisenbug repro, it took forever to fix. Anyways, so we finally got to the end of
1659.38s - 1661.96s |  it, but the team was really cool, they're great to work with, they got a patch out, even for
1661.96s - 1665.92s |  this legacy hardware, so awesome to see them actually supporting older systems. Uh, then we
1665.92s - 1669.90s |  found these Realtek devices that are, like, branded to all kinds of things. Netterbit, um,
1669.90s - 1673.44s |  Netist, there's probably like a dozen vendors out there, and they all have, like, different
1673.44s - 1677.34s |  flavors of firmware from 2018 to 2023, and there's just, like, free shells everywhere. We
1677.34s - 1680.70s |  didn't even know who to report it to, so that's, there's a bunch out there. Um, yeah, have fun
1680.72s - 1685.26s |  with that. Uh, we also ran across a bunch of Panasonic switches, but also a really weird set,
1685.26s - 1688.26s |  and we had no idea who to report that one to either, like, the normal Panasonic thing
1688.26s - 1691.46s |  wasn't the right fit, and so, all the docs were in Japanese, we kind of gave up on that
1691.46s - 1694.50s |  too, so we'll eventually figure out how to disclose that one, but there's a bunch of
1694.50s - 1697.10s |  random Panasonic switches that'll just give you a shell pre-auth as well through the same
1697.10s - 1700.64s |  mechanism. Um, and this is just kind of the tip of the iceberg. We found another, like, 70
1700.64s - 1704.18s |  odd devices, we just haven't figured out where they are yet. Um, so, you know, basically
1704.18s - 1706.52s |  take Shamble, throw it in your home network, throw it in your work network, and you might
1706.52s - 1710.12s |  just get random free shells out of crap through this stage transition. The only trick of it
1710.14s - 1713.34s |  here is you may have to specify a username that's not the default username. So, if the
1713.34s - 1716.88s |  device typically has, like, an admin or manager username, specify all the default admin
1716.88s - 1722.56s |  usernames for the products, and you'll be more likely to shake out some shells. So, here's
1722.56s - 1727.06s |  an example of the Netterbit NSL-224s. These are really popular in Iran, so a huge portion
1727.06s - 1731.70s |  of Iran uses these things, and you just basically log in as, you know, whatever you like. Um,
1731.70s - 1736.10s |  so, in this case, we're using the Shamble shell for it, we're just saying, like, brute
1736.10s - 1739.68s |  force all the different session states, and it logs us directly into it, and it shows
1740.20s - 1743.74s |  the firmware, all the info, things like that. So, it's super straightforward. And here's an
1743.74s - 1748.20s |  example of the Digi transport ICS gateways. Same thing, what I love about this is when you
1748.20s - 1753.22s |  log in, it says, welcome, your access is super! So, I also have the, you know, the South Park
1753.22s - 1757.58s |  voice in my head when I see that, so it's amazing. Um, with that, I would like to talk a
1757.58s - 1762.66s |  little bit about the OpenSH landscape. So, you know, typically we think about, like, SSH
1762.66s - 1767.80s |  being OpenSH, and sure, it's like 90% of us, it's 87% of all SSH in the world, but OpenSH
1767.82s - 1772.12s |  isn't just OpenSH either. There's a lot of different flavors of OpenSH. So, for folks who
1772.12s - 1777.76s |  aren't super familiar, OpenSH was forked from OSSH, which was forked from the original V1,
1777.76s - 1784.40s |  um, you know, tattoo, um, version of SSH back in the day. Um, but OpenSH wasn't designed
1784.40s - 1789.48s |  for Linux. OpenSH was hard-coded for OpenBSD. Like, they didn't want our dirty Linux paws all
1789.48s - 1793.18s |  over their beautiful SH daemon, so eventually they conceded and said, you know what, you
1793.18s - 1796.62s |  guys can, all you plebs can actually touch our beautiful SH code, but we're gonna create a
1796.64s - 1800.44s |  version of OpenSH just for you called OpenSH Portable. So, when you talk about OpenSH, you're
1800.44s - 1803.64s |  really talking about the portable version of OpenSH, which has a compatibility layer that
1803.64s - 1808.36s |  makes, um, all of us heathens be able to use the nice functions of BSD, basically, uh, without
1808.36s - 1812.12s |  all the pledge and cool things like that. But if you look at OpenSH Portable, there's actually a
1812.12s - 1816.60s |  bunch of variants of that too. So, if you look at, like, who has molested OpenSH the most,
1816.60s - 1820.20s |  we're gonna start off with Apple. Apple was just light touch. They just gave a little hug.
1820.20s - 1824.10s |  They didn't really do much to it. Uh, they did not do terrible things to OpenSH. They, um,
1824.12s - 1829.96s |  added some changes for, um, let's see, the key login, the endpoint event logging, uh, PKCS
1829.96s - 1833.32s |  helper and keychain, things like that. Really straight forward, not terrible at all. Very
1833.32s - 1838.44s |  happy that they did not destroy OpenSH. Um, if you start looking at Debian and Ubuntu, they've
1838.44s - 1843.40s |  got about 36 different patches on top of the core OpenSH code. Uh, and those patches make it
1843.40s - 1847.94s |  libxutils backdoor compatible, um, among other things, right? But there's a lot of changes, and
1847.94s - 1850.74s |  those changes aren't getting the same scrutiny that, let's say, the rest of OpenSH code is
1850.74s - 1853.82s |  getting. It's, it's basically linking it to all kinds of other libraries. It's the reason why it
1853.84s - 1857.44s |  linked to system D. Um, there's a lot more attack service because of all those changes they
1857.44s - 1862.28s |  put into the, those system patches. Now, moving up to Red Hat, now you're like 60 plus
1862.28s - 1865.82s |  different patches. So even, even bigger attack service. And, you know, hopefully they're
1865.82s - 1868.82s |  auditing this stuff and everyone's looking at it, cause it's important, cause if you're hacking
1868.82s - 1872.12s |  a Linux server, it's probably gonna be either Debian, Ubuntu, or Red Hat based these days,
1872.12s - 1875.36s |  right? Unless you're like, I use ARC. You know, you know, there's only a few of those out
1875.36s - 1881.46s |  there. Um, so, um, if you're using, uh, you know, Debian, Ubuntu, Red Hat, Linux, etc., um,
1881.46s - 1885.48s |  you probably have a ton of different patches on top of OpenSH that are not pure OpenSH, if
1885.48s - 1889.52s |  you will. Uh, you've mangled pretty well. And then there's a thing called PKI-SSH, which I
1889.52s - 1893.82s |  think probably a lot of folks haven't heard about. It was forked from OpenSH back in 2002
1893.82s - 1898.50s |  to support X.509 certificates and then FIPS code. So because it supports X.509 and FIPS, a lot
1898.50s - 1902.62s |  of the networking vendors decided to use that instead of regular SSH, uh, to build out their
1902.62s - 1905.22s |  products because they want to sell to the federal government and they want to use
1905.22s - 1909.70s |  Crestiel crypto protocols. Um, so there's a thing called PKI-SSH. It forked in 2002. It
1909.74s - 1913.92s |  mostly, it's almost like they hate each other. If you do, like, so, put it this way, we diffed
1913.92s - 1917.76s |  all of it. We looked at, like, OpenSH mainline to every one of these forks and just read every
1917.76s - 1921.82s |  single line of code for days and weeks. Well, that was my vacation. I just did that for hours
1921.82s - 1926.60s |  a day. Um, but the PKI-X one is really funny because you'll see a change in OpenSH and then a
1926.60s - 1932.30s |  change is written slightly differently in PKI-SSH and they oftentimes disagree. Like, once
1932.30s - 1935.60s |  in a while they mostly match, like, if one equal this, if that equal that, but occasionally it's
1935.64s - 1939.82s |  like, if not, when equal this. And it's like, so, there's probably some weird compatibility
1939.82s - 1943.18s |  bugs because the changes weren't followed entirely. They obviously don't want to look like
1943.18s - 1946.82s |  they're copying OpenSH, but they also can't not copy it and stay compatible. So you can just,
1946.82s - 1950.76s |  you can feel the rage between the two teams there. It's great. Um, I've never felt so much
1950.76s - 1955.66s |  like animosity in a code diff before. Um, but finally, uh, the, the really fun one here is
1955.66s - 1960.30s |  Windows. So Microsoft Windows, um, shipped OpenSH on Windows 10. Everyone's like, oh my
1960.30s - 1963.74s |  God, I can actually type SSH and curl. I don't have to do all these stupid commands anymore to
1963.74s - 1967.32s |  back to my Windows box. I can use the built-in nice native Linux commands to back to my
1967.32s - 1970.98s |  Linux boxes. And that was great. So we love the fact that SH clients on Windows, we can use
1970.98s - 1975.52s |  them for all kinds of stuff. Um, there's also SH server for Windows. And so there's a fork for,
1975.52s - 1981.06s |  uh, of OpenSH portable called OpenSH, um, under the PowerShell GitHub repo. And they just
1981.06s - 1985.26s |  massacred it. There's like 350 files are changed. They ripped out everything. All those secure
1985.26s - 1989.48s |  parts of SH kind of just got put into the corner over there, uh, and, and deleted. And then
1989.48s - 1993.24s |  it's like, if Windows do something totally different. So they ripped out support. They ripped
1993.24s - 1996.78s |  out, um, the PrivSep stuff works totally different through a sub process versus the fork
1996.78s - 2001.28s |  because there's no forks on Windows. Um, they, uh, logged to Windows Event Viewer. They
2001.28s - 2005.68s |  logged, uh, they sent telemetry back to Microsoft for everything you do. Um, they still
2005.68s - 2009.06s |  haven't bothered fixing Terrapin. Like, it just, it's a very different fork. So if you're
2009.06s - 2012.82s |  using Windows and SH, either a client or a server, you probably want to pay attention to this
2012.82s - 2017.16s |  next slide, which is, uh, let's see, this is what it looks like. Not super exciting. But if you
2017.16s - 2019.90s |  start looking through the OpenSH for Windows code, you can start looking at the telemetry
2019.90s - 2023.94s |  callback. You can't disable this crap. Unless you disable telemetry, telemetry total on your
2023.94s - 2028.64s |  machine. Every single connection going to your Windows, your SH server on Windows is sending
2028.64s - 2032.20s |  your client version and server version back to Microsoft in the telemetry. So every time you
2032.20s - 2035.48s |  port scan your system, every time you run a Nessa scan against your Windows server, it's
2035.48s - 2038.88s |  sending that info back. Every time you SH directly from your Mac OS client or whatever it is
2038.88s - 2042.56s |  to a Windows server, it's sending your version string back to them. So Microsoft knows who you
2042.56s - 2046.82s |  talk to and knows who you shell into. It collects all those craps for default telemetry. It
2046.82s - 2050.04s |  even collects telemetry for things that are part of encrypted session. Like things like
2050.04s - 2053.98s |  authentication methods that are negotiated over the secure channel. That's also shipped off
2053.98s - 2057.76s |  to telemetry. So, uh, you know, I know we're all good, you know, cool kids here and we
2057.76s - 2062.56s |  disable telemetry in VS code, but like, have you done so in OpenSH? Probably not, right? Um,
2062.56s - 2065.76s |  so it's worth digging out the diagnostics viewer where you can look at the telemetry data on
2065.76s - 2070.84s |  Windows and seeing like all your SH stuff being shipped off to the cloud. Um, so, yeah. But
2070.84s - 2075.54s |  the next thing we'll talk about is even worse. Uh, so there's this really key function. We
2075.56s - 2081.74s |  talked about OpenSH portal being a compatibility layer to make it, um, work not on OpenBSD. So
2081.74s - 2086.10s |  the pure OpenBSD people, you know, can give us their code. Um, one of the functions that
2086.10s - 2090.08s |  they implemented was timing safe B comp, which is like you expect. It compares two binary
2090.08s - 2094.18s |  blobs as are these identical in a way that doesn't change based on how long the strings are,
2094.18s - 2097.92s |  what contents they have. It can be consistent either way. This is to prevent side channel
2097.92s - 2101.46s |  attacks. It's really clean, really code. It's only like four lines of code. Maybe take out
2101.48s - 2105.92s |  the return and the int and the variable. It's only three lines of code. It's really hard to
2105.92s - 2110.52s |  break this, right? This is a super nice great piece of code by, uh, you know, Damian Miller.
2110.52s - 2114.32s |  It's great. It's perfect. It's beautiful. And then OpenSH for Windows comes along. And they
2114.32s - 2121.20s |  made it Windows compatible. So, uh, Windows compatible means, uh, first they look for a
2121.20s - 2125.90s |  back R and a back N and they scrub out the back R. And so they just, they allied the fact
2125.90s - 2129.68s |  that there's a back R back N. They treated it as if it was equal to a back N. But you can
2129.70s - 2133.80s |  probably see there's some problems here. Um, we'll kind of highlight those real quick. First
2133.80s - 2137.48s |  off, there's only two lines of code they added and they introduced a ton of bugs. It's no
2137.48s - 2142.32s |  longer timing safe because they look one byte ahead. It's no longer, uh, secure because they
2142.32s - 2146.28s |  read one byte out of, out of memory. They're actually reading the, the pointer plus one, not
2146.28s - 2149.82s |  the pointer, which could be beyond the end of that particular variable. So for every back R
2149.82s - 2153.36s |  back N sequence you have in the source buffer called by this function, you're actually going
2153.36s - 2157.60s |  one byte out of the memory buffer and moving forward. And that, and then that value's being
2157.62s - 2161.22s |  compared for your byte comparison. So if you know there's a blob of data at the end of your
2161.22s - 2164.50s |  buffer, you can now just tell SH to not compare the bytes you thought you were comparing and
2164.50s - 2167.06s |  now compare the bytes at the end of the buffer, which are typically a bunch of nulls or
2167.06s - 2170.40s |  something more predictable. So there's a bunch of like really gnarly bugs that happen just
2170.40s - 2173.34s |  because somebody decided their config parser didn't work with this function that wasn't
2173.34s - 2178.14s |  designed to parse configs in the first place. Um, so it's about as bad as it gets. So this
2178.14s - 2182.34s |  function is used in every single packet that gets processed by SH. So every crypto buffer
2182.36s - 2187.86s |  coming into it gets the SH comp or comp buff check on it. And, and basically it gets buggy
2187.86s - 2191.46s |  really quick. Um, it's used for RSA signature validation, all this stuff. But the question
2191.46s - 2194.90s |  was like, can we actually exploit it? And that's where it gets tricky. It's like the buffer
2194.90s - 2198.64s |  that you can, that triggers the bug is the first buffer, first parameter, and the attacker
2198.64s - 2202.28s |  doesn't control it directly. But if you do enough signing operations, you're not packets.
2202.28s - 2205.18s |  Eventually you get a buffer that has at least one back R back N in it. If you get to two, you
2205.18s - 2207.84s |  get a little more interesting, but it's been really tough to actually get an exploit out of
2207.84s - 2212.08s |  it. So of course, when we report to Microsoft, uh, their take is, you know, even though we've
2212.08s - 2216.50s |  got $1 billion annual security budget, we've got 3,500 security professionals and we backdoor
2216.50s - 2221.36s |  your timing, save B comp code, you do not get a banana. So we got nothing. They said, no, no,
2221.36s - 2224.10s |  you guys don't get anything. We're not going to fix it. Have fun. Like, all right, well, we're
2224.10s - 2229.48s |  going to talk about it at DEF CON. See you guys. Uh, so we did. Cool. Um, so that's the end of
2229.48s - 2232.68s |  the, most of the content about SH. We're getting a little close to time. I want to make sure
2232.68s - 2235.68s |  we have time for a little bit of questions here. Uh, we're going to talk a little about the
2235.68s - 2239.98s |  shamble tool. So, uh, this tool is a research tool for SH simplifications. It's a
2239.98s - 2243.26s |  combination of like, I think you can use today to scan your network, but I think you can extend to
2243.26s - 2247.42s |  find even more horrible bugs in SH and then share them with the world. So, uh, we, we'd like
2247.42s - 2253.00s |  you to, uh, play with it, make it better and, and rain hell upon vendors that do it wrong. Um,
2253.00s - 2256.00s |  there's a lot of really cool interesting attacks against authentication, auth bypass, null
2256.00s - 2261.18s |  bytes, uh, ends up when you send a, uh, uh, SH password authentication, there's a, if you send a
2261.18s - 2264.82s |  second parameter in addition to your password, that tells SH server that you want to change
2264.82s - 2268.14s |  your password to that new value. So you can imagine that when we're developing this tool, we
2268.18s - 2273.38s |  might have actually changed a lot of passwords. Uh, so be careful about that part. Uh, other than
2273.38s - 2276.38s |  that, and it's kind of funny, it's like, oh, I got into all these machines and then you scan
2276.38s - 2278.98s |  them again. Like now I can't get into all those machines. What happened? Well, we
2278.98s - 2282.36s |  accidentally sent all the passwords to a null byte. Uh, there's also a lot of systems out
2282.36s - 2285.92s |  there that will, uh, accept a null byte as a password. And there's specifically a lot of
2285.92s - 2289.54s |  honeypots. So we doxed like 5,000 honeypots by accident because they accept null byte
2289.54s - 2292.04s |  passwords where nothing else does. It's like, oh, here's all the honeypots. That makes our
2292.04s - 2295.50s |  lives a lot easier. Uh, a lot of the pre-auth state transition stuff, so you can extend
2295.50s - 2298.34s |  those, make your own. It's kind of modular. It's not as cool as Metasploit, but it does a lot of
2298.34s - 2301.50s |  stuff like that. You can kind of add your own checks to register them. Uh, and then all the
2301.50s - 2304.68s |  post-session stuff too. If you get a session, but you don't get a shell, you can use
2304.68s - 2308.68s |  Shamble to like bang on that session, try signals, jam keystrokes into it, generally do all
2308.68s - 2311.62s |  the crap you don't want to do by hand that's really annoying. And eventually, um, do that.
2311.62s - 2314.48s |  Plus we added some timing analysis stuff too. So if you think there's like timing leak in
2314.48s - 2317.62s |  the username, we've got some built-in functions that'll tell you like what's the, what's the
2317.62s - 2321.10s |  statistical probability of this username being different than this other one based on a timing
2321.10s - 2326.10s |  attack with really tight, uh, timing. So Shamble.com gets you all that stuff. And there's a
2326.10s - 2329.24s |  whole bunch of stuff it does. So I think first off, I want to hand it to Rob to talk about all
2329.24s - 2334.14s |  the vulnerability checks we do. So, uh, Shamble will actually check for all the vulnerabilities
2334.14s - 2338.42s |  we talked about, uh, over this. And they will not only check for you, it will give you proof.
2338.42s - 2342.62s |  So you can run through, uh, it'll check for TCP forwarding, see if it can forward anywhere.
2342.62s - 2346.46s |  It'll try different, uh, destinations, see what it can find. See if it's, uh, administratively
2346.46s - 2350.76s |  prohibited for some. Uh, it will do generic environment injection. So it'll take, uh,
2350.76s - 2354.26s |  environment variables that will control execution of processes and we'll check to see if the
2354.26s - 2358.46s |  output changes and things like that. Uh, LD preload, stuff like that. Super useful. We'll say,
2358.46s - 2361.20s |  oh, this is actually how it's vulnerable. This is what it can do. It'll tell you what to do
2361.20s - 2365.34s |  next. Um, the software vulnerability that we talked about, it will, uh, it will give you the
2365.34s - 2370.68s |  exact, uh, version and exactly the repo that it used and everything to get into there. Um, it
2370.68s - 2375.32s |  will check the GOGS thing. That's the, uh, that's the, uh, ENV thing that looks vaguely like a
2375.34s - 2379.42s |  backdoor, um, where it's executing ENV and it'll try to give you commands, uh, command
2379.42s - 2383.48s |  execution there. And, uh, it will check the ruckus password escape. That's the one where you
2383.48s - 2389.36s |  can, uh, you can put bat ticks or a dollar parents in the password and, uh, it'll just give
2389.36s - 2392.92s |  that to you and it'll say, and the report you can actually see, uh, in the report, it'll say,
2392.92s - 2395.90s |  okay, here's what I found. Here's the references and here's the proof. It'll actually give you
2395.90s - 2399.90s |  the output that it found. Um, and you can just run that. They're automatically, it will
2399.90s - 2403.70s |  automatically detect it and it will continue. We're continually adding more vulnerabilities
2403.76s - 2407.36s |  to make it easier. So, uh, stay tuned and run that on all your systems and tell us what you
2407.36s - 2411.76s |  find. Well, thanks Rob. And even the last 24 hours since the code's gone live, we've got a lot
2411.76s - 2414.70s |  of great feedback, feature requests, things like that. So we're really excited to keep
2414.70s - 2418.00s |  expanding it. Adding things like the, you know, a keystroke masher where it just like hits
2418.00s - 2420.74s |  every possible keystroke trying to break out of the shell. Like the things you usually put
2420.74s - 2423.54s |  your toddler in front of to make them give you shells. Like we'll just do that for you here.
2423.54s - 2428.48s |  So, uh, who needs AI, right? Um, but in that sense, um, lots of cool stuff's already built in
2428.48s - 2435.20s |  today. Uh, to get started you just run shamblescan-o. It generates a gigantic JSON file. Um, if
2435.20s - 2438.74s |  you run this across the whole internet, you get about 60 gigs of data. I don't know why I know
2438.74s - 2442.34s |  that, but it's a lot of fun and you have millions of shells to go play with. Uh, and then you can
2442.34s - 2445.28s |  run the analyze command. It'll try to like bucket your results based on what cool things you
2445.28s - 2449.42s |  found. So if it, if it's like a known backdoor or a known, uh, bug, we'll hopefully stick into
2449.42s - 2452.72s |  its own little file and you keep track of them that way. We also report like vulnerabilities in
2452.72s - 2456.32s |  the JSON. You can scrape out and import. Uh, of course all this stuff's been, a lot of this has
2456.32s - 2459.84s |  been linked into the run zero tool that we work on at, at our day job. And so it does a lot of
2459.84s - 2462.96s |  these checks for you automatically, including grabbing all your keys, stuff like that. We're
2462.96s - 2467.00s |  also looking at integrating it with, uh, HanoBox, uh, uh, bad keys project to automatically
2467.00s - 2470.54s |  identify host keys that have been compromised. And shambles is unique in that it's one of the
2470.54s - 2474.28s |  very few tools that test all of your host keys, not just your first host key. So if your
2474.28s - 2478.78s |  machine has an RSA key, an ECDSA, an ED25519, et cetera, we'll actually grab all the
2478.78s - 2482.38s |  different host keys by grabbing them all and then test all of those keys for weak keys and, uh,
2482.38s - 2485.52s |  things like that. So it's still a little bit early for the bad key stuff, but we're, we're
2485.52s - 2489.26s |  making progress. Uh, so an example, one of the neat things about shamble is that you can tell
2489.26s - 2493.30s |  it to get into that larval session state without actually opening the process, which is a
2493.30s - 2497.54s |  pain in the butt to do otherwise with an SH client. So essentially you say, um, you know,
2497.54s - 2501.64s |  shamble scan dash dash interact equal first. So interact with the first session you get and
2501.64s - 2505.18s |  then interact auto equal nothing. Do not do any, do not do anything at all and just drop you
2505.18s - 2508.62s |  straight to the interpreter shell instead. And then from that interpreter shell, you can like
2508.62s - 2512.58s |  set any environment variables you want. LD debug equal all, LD preload, whatever you like.
2512.58s - 2516.92s |  Uh, you can start sending signals to it even pre shell. And then when you want to drop a shell,
2516.92s - 2520.46s |  either type exec to run a command or you can do shell to get interactive shell. And at that
2520.46s - 2523.42s |  point you can then mess with the shell itself. So it gives you kind of all the tools you need to
2523.42s - 2527.00s |  manually mess with it. And control E is how you open the shamble shell, uh, from the prompt
2527.00s - 2530.36s |  there. Just so we don't conflict with the SSH escape codes. And there's a million other things
2530.36s - 2533.00s |  we can talk about, but we're going to keep kind of hammering on the code a little bit. And of
2533.00s - 2537.68s |  course, happy scanning. And, uh, here's us just throwing out a slash 24 real quick, but it is
2537.68s - 2541.38s |  pretty fast too. It'll just, it'll eat all your CPU and RAM, just grinding away all your
2541.38s - 2547.62s |  things. Um, and yeah, here's a bunch of bones we found. Thanks. We've got a couple minutes, I
2547.62s - 2550.98s |  think, for questions. It looks like, uh, if you have a question, please come up to the middle
2550.98s - 2570.98s |  standy thing and the mic so that everyone else can hear you. The mic may not be on. I'm not
2570.98s - 2579.96s |  sure. You want to grab this one instead? Yeah. I'm sorry. You're still on mic. All right. So
2579.96s - 2585.40s |  out of all the implementations that you have, uh, that you've scanned, what is in your
2585.46s - 2592.16s |  opinion, the most secure? Uh, the most seeker or the most insecure? The most secure. Okay.
2592.16s - 2597.74s |  Yeah. The, yeah. Two, you know, the, the TLDR of this entire talk is just use openSH98P1
2597.74s - 2601.14s |  and don't do anything else. Just don't roll your own. That's basically all you found. Just
2601.14s - 2606.38s |  like any other crypto, anytime you try to mess with it, you break it. Oh, thank you. Uh, any
2606.38s - 2615.30s |  other questions? Does anybody recognize my shirt? It's, it's particularly nerdy. I'll be your
2615.32s - 2623.76s |  friend if you know. Anybody? Anybody? One more question? Uh, yes. Did you guys try anything
2623.76s - 2628.78s |  with PuTTY? PuTTY, P-U-T-T-Y, client. I'm sorry. Yeah. It's, it's, uh, uh, TTY client for
2634.08s - 2638.88s |  Windows called PuTTY. Oh, PuTTY. Do SSH. Yeah. We didn't look at the code for it because it's
2638.88s - 2642.48s |  mostly client side. We really focused on all the, just the server side implementations. Uh, I
2642.48s - 2645.22s |  know PuTTY does a bunch of weird things with the keys. Like it has a weird preferences in
2645.24s - 2649.64s |  which EDSA keys uses, but we didn't get the chance to test PuTTY itself. There, there was an
2649.64s - 2653.14s |  interesting, uh, not volume per se, but there was an interesting, uh, key generation issue
2653.14s - 2656.18s |  with PuTTY this year. I need to go back and look at that. Yeah. Sorry. Another question? Does
2656.18s - 2662.62s |  Shamble detects honeypots? Like how do you guys are detecting honeypots? And like, um, how
2662.62s - 2671.28s |  Shamble detects honeypots? Sorry? Oh, okay. Yeah. So the short version is you, it just makes
2671.28s - 2674.70s |  the TCP connection to whatever port and range you tell it to. And then it looks for SSH
2674.72s - 2678.32s |  version, does the handshake, all that. So, um, that's about it. Unless I missed your
2678.32s - 2684.02s |  question. How is it detecting honeypots? Oh, honeypots. Yeah. Um, so the funny thing is
2684.02s - 2688.36s |  most honeypots, uh, have a bug where they accept a nullbyte password and they just drop and
2688.36s - 2692.60s |  they accept that where a real machine will never accept the nullbyte password. So in a, in a, in
2692.60s - 2695.70s |  an open stage implementation, by default, if you put a null into the password field, it'll
2695.70s - 2699.74s |  kick you back out. But most honeypots will accept you with a nullbyte password. And that's
2699.74s - 2703.44s |  an easy way to find like 5,000 of them. Um, we found a bunch of other ones through, uh, some
2703.48s - 2706.98s |  of them accept any public key, no matter what key you give it. Other ones will take, uh,
2706.98s - 2711.28s |  passwords that are, uh, outside the spec otherwise or m-mangled password requests. So you
2711.28s - 2717.13s |  just throw garbage at it and it accepts it, you know it's not open stage. Cool. Alright, and
2717.13s - 2720.57s |  that's it. Thank you very much. Thanks everybody. Look for us if you have any questions. We're
2720.57s - 2721.27s |  happy to talk to y'all.


url: https://www.youtube.com/watch?v=JERBqoTllaE
title: DEF CON 32 - Splitting the email atom exploiting parsers to bypass access controls - Gareth Heyes
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=JERBqoTllaE",
  "title": "DEF CON 32 - Splitting the email atom  exploiting parsers to bypass access controls - Gareth Heyes",
  "description": "Websites often parse users' email addresses to identify their organisation. Unfortunately, parsing emails is far from straightforward thanks to a collection of ancient RFCs that everyone knows are crazy. You can probably see where this is going\u2026\n\nIn this session, I'll introduce techniques for crafting RFC-compliant email addresses that bypass virtually all defences leading to broken assumptions, parser discrepancies and emails being routed to wildly unexpected destinations. I'll show you how to exploit multiple applications and libraries to spoof email domains, access internal systems protected by 'Zero Trust', and bypass employee-only registration barriers.\n\nThen I'll introduce another class of attack - harmless-looking input transformed into malicious payloads by unwitting libraries, leading to yet more misrouted emails, and blind CSS injection on a well-known target.\n\nI'll leave you with a full methodology and toolkit to identify and exploit your own targets, plus a CTF to develop your new skillset.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2175,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Welcome to splitting the email atom, exploiting parsers to bypass access controls.
6.96s - 12.56s |  Email addresses might seem mundane but the RFCs governing them are downright bonkers.
13.44s - 19.92s |  I'll show you why predicting an email destination is highly complex and I'll take you on a journey
19.92s - 27.20s |  of ancient protocols, exotic encodings, access control bypasses and how I gained remote code
27.20s - 36.86s |  execution from an RFC compliant email address. First I'll explain why email address parser
36.86s - 42.22s |  discrepancies matter. Next I'll cover the shaky foundations that emails are built on.
43.66s - 49.18s |  The core of the talk will focus on parser discrepancies including Unicode overflows,
49.18s - 53.74s |  encoded word, AMP Unicode all with real world case studies.
54.94s - 59.34s |  Then I'll share my methodology and tools for automating exploitation.
59.90s - 65.26s |  Followed by advice on defense. I'll conclude with the key takeaways leaving five minutes
65.26s - 73.09s |  for questions. There's also a bonus material for Defcon 2. So this research all started when we
73.09s - 79.65s |  realized many websites use the domain part of the email address to infer the user's organization
79.65s - 86.29s |  and apply access control. For example Slack will automatically give you access to your company's
86.29s - 93.33s |  Slack channel based upon your work email address and Cloudflare Zero Trust can be configured to
93.33s - 100.93s |  use the email domain to protect your internal network. This makes email verification a critical
100.93s - 110.38s |  security boundary. What could possibly go wrong? Everyone knows that URL parser discrepancies are
110.38s - 119.26s |  critical as they can lead to SSRF path traversal and other security issues. Using an email domain
119.26s - 125.90s |  for access control makes email address parser discrepancies critical too. Predicting which
125.90s - 132.30s |  domain an email should be routed to should be simple but it's actually ludicrously difficult
132.30s - 140.90s |  even for valid RFC compliant addresses. So we've established why email address parser discrepancies
140.90s - 148.10s |  matter. Now let's explore why predicting the email destination is so challenging. Email addresses are
148.10s - 155.06s |  built on a shaky foundation of RFCs designed many years ago. Validation is often performed using
155.06s - 162.26s |  regular expressions copy and pasted from Stack Overflow all trying to follow the RFC. However
162.26s - 170.56s |  one mistake in the RegEx and everything can come crashing down. I'm not going to bore you
170.56s - 176.96s |  with RFCs but I will highlight the important ones for this talk. For instance the characters before
176.96s - 183.20s |  the at symbol in an email address are called the local part. The RFC allows what is called the
183.20s - 189.76s |  quoted local part. This enables you to use characters in the local part that are not
189.76s - 196.08s |  normally allowed by using quotes. In the example shown I use a quoted local part to use the at
196.08s - 204.08s |  symbol as part of the address. The same RFC allows you to use a quoted per which means one character
204.08s - 210.24s |  preceded by a backslash. This enables you to use a double quote and a backslash as part of the
210.24s - 217.20s |  address provided it is it is escaped. Characters enclosed in parentheses are treated as comments
217.20s - 223.76s |  and can be placed anywhere within the address except the quoted local part. They're all ignored
223.76s - 233.07s |  when the actual email is delivered. So here are two email addresses. You might be wondering which
233.07s - 240.83s |  one is valid as this is a typical question asked in an email presentation. However it's the wrong
240.83s - 249.33s |  question for this talk. The question you should be asking is which domain do they go to? You might
249.33s - 257.01s |  expect both emails to go to example.com but that's not what happens. They both go to psres.net
257.97s - 263.97s |  Remember how I said predicting the email destination is extremely difficult? This is just
263.97s - 270.53s |  the tip of the iceberg. The first example works on postfix and the second example works on sendmail.
271.25s - 280.83s |  If you are confused you should be. Next let's explain why this happens. A source route is a
280.83s - 286.91s |  sequence of servers which an email is sent before reaching its final destination. Servers in the
286.91s - 293.15s |  chain are separated by commas with the final destination marked with a colon before the
293.15s - 301.09s |  recipient's full address. Another form of source routing is called the percent hack. Despite its
301.09s - 306.69s |  name the actual character is determined by the mailer. In this process the email is initially
306.69s - 313.25s |  sent to example.com after which the percent symbol is converted into an at symbol and the email is
313.25s - 323.94s |  sent to foo at psres.net. This process can be repeated several times. Before email addresses
323.94s - 332.10s |  existed and even the internet people exchanged messages using UUCP. UUCP stands for Unix to Unix
332.10s - 338.50s |  copy protocol. It's an early protocol that separates the local user and multiple hosts
338.50s - 344.58s |  using an exclamation mark creating what is known as the bang path. Unlike the standard format
345.14s - 350.50s |  for internet email addresses today the bang path lists the host from left to right
350.50s - 358.83s |  with the destination user mailbox on the right as you can see in the example. So going back to
358.83s - 363.71s |  the original examples with all the special characters removed what the parentheses actually
363.71s - 369.55s |  do is remove that symbol and domain and without the domain part postfix treats that as a percent
369.95s - 376.03s |  route. Using a backslash and escape in the at symbol has the same effect on send mail which
376.03s - 382.11s |  treats the email as a UUCP address. Pretty damn crazy right and I've tested it and all those
382.11s - 389.41s |  special characters do go to the mailbox. I wish I could tell you that I uncovered this behavior by
389.41s - 394.13s |  analyzing thousands of lines of code and using a debugger and stepping through the code flow
394.13s - 401.41s |  in send mail and postfix but that's not actually how it went down. I noticed an unnamed target
401.41s - 406.61s |  was allowing all sorts of special characters so I just took all the characters pasted it into my
406.61s - 412.61s |  email and expected it to fail but actually what happened was I checked the syslog on the box that
412.61s - 419.81s |  I was testing and I noticed a difference. I was getting host unknown error in the delivery status
419.81s - 425.01s |  notification. This was significant because it would suggest a different host was being used.
426.53s - 430.69s |  If you look at the error you'll notice the exclamation mark is missing. I didn't actually
430.69s - 436.53s |  notice that at the time so I started to remove characters, resend the email and I still got the
436.53s - 443.01s |  same error message. I narrowed it down to the exclamation mark and thus discovered this UUCP
443.01s - 449.97s |  behavior. This was bonkers by sheer luck the characters I pasted into my email address
449.97s - 455.81s |  ended with a backslash. I think I did this subconsciously and then when the exclamation
455.81s - 461.73s |  mark was then sorry and then escape the out symbol and then the exclamation mark was treating
461.73s - 468.45s |  the address as a UUCP address. I then wrote a fuzzer to find the other behavior with source
468.45s - 474.45s |  routes with postfix. These findings gave me great confidence that there were a ton of bugs out there
474.45s - 484.10s |  so I began to look for more and this is a bonus slide for Defcon. In the RFC there are optional
484.10s - 491.70s |  SMTP parameters. I analyzed the postfix code with a poet swinger colleague and I discovered that
491.70s - 495.78s |  these parameters could be used to remove the domain part of the email address.
496.58s - 501.78s |  I found this parsing bug on a real target but the application in question didn't use the email
501.78s - 508.10s |  domain for access control. This attack works by escaping the backslash to break out of the
508.10s - 514.26s |  quoted local part confusing the email validation. Then you can use the greater than to end the
514.26s - 520.98s |  receipt to command and then you stick all the rest of the address within this SMTP optional
520.98s - 527.86s |  parameter and you will notice that yeah this works on a real target and is a valid
531.30s - 537.62s |  SMTP conversation so when it does the receipt to command it's a valid syntax for that.
540.37s - 545.97s |  As a further bonus here is some surprising email parsing behavior that I uncovered
545.97s - 551.41s |  works on postfix. I couldn't use these for access control bypasses but nevertheless
551.41s - 557.01s |  they are interesting and challenges your assumptions of how email addresses are parsed.
557.81s - 565.09s |  This first one uses a UUCP address and is sent regardless of the quotes. It's pretty damn crazy.
567.14s - 573.54s |  This second one uses source roots so if you use a square bracket syntax postfix will still treat
573.54s - 582.59s |  it as a source root and send to that email. So one of the main problems I had to solve with
582.59s - 588.83s |  this research was generating blocked characters. Since many web applications will block multiple
588.83s - 596.03s |  art symbols so this following section focuses on unicode overflows which enable the creation
596.03s - 601.47s |  of ASCII characters from higher unicode characters. It's pretty much normalization
601.47s - 610.37s |  but I'm calling it unicode overflows because it's a different technique. So the PHP char
610.37s - 616.93s |  function is a good example of how unicode overflows can occur. The function generates
616.93s - 622.45s |  a character from an integer code point. Here's an illustration of how the algorithm is used by this
622.45s - 629.25s |  function. It loops while the code point is less than zero continually adding 256 until it's non
629.25s - 636.93s |  negative because why not it's PHP after all. Then it uses the mod operation to ensure the byte value
636.93s - 644.61s |  is always within a range of 0 to 255. So if you introduce a unicode character is larger than 255
644.61s - 650.37s |  it'd be truncated into this range. Note that unicode overflows aren't just specific to PHP.
652.93s - 659.65s |  So generating a unicode overflow in JavaScript is quite simple using the from code point method.
660.29s - 667.49s |  First you pass the number that will cause the overflow such as 0x100 which is 256 in decimal.
668.13s - 672.69s |  Next you provide the second hex number to specify the actual character that you want
673.57s - 680.69s |  like 0x40 which is the art symbol. The from code point method will generate a unicode character
680.77s - 686.29s |  and when this character is transformed to fit within 255 a system that doesn't support higher
686.29s - 690.93s |  unicode characters will produce the ASCII character specified by the second number.
693.39s - 698.99s |  So I hunted for real world unicode overflows and I found a target that altered characters
698.99s - 705.31s |  within the mailer's SMTP conversation. This application blocked the backslash within the
705.31s - 711.71s |  quoted local part but I bypassed the validation using unicode overflows that enabled me to escape
711.71s - 718.43s |  characters and break out of the quoted local part. Despite this when using an encoded art symbol
719.07s - 725.15s |  the email wasn't sent suggesting there is a double validation going on once in the application and
725.15s - 731.87s |  once before sending. So although I didn't manage to exploit this particular target the key takeaway
731.87s - 737.71s |  is if you can you can use a unicode overflow to bypass validation and actually smuggle characters
737.79s - 747.25s |  within the SMTP conversation. So unicode overflows were great but I needed more methods to generate
747.25s - 753.17s |  block characters so I took a deep dive into the glorious RFC looking for gold and I found it.
754.29s - 760.29s |  This next section is about encoded word. I discovered this when trying to find ways of
760.29s - 769.17s |  encoding the art symbol without unicode overflows. Encoded word is specified in RFC 2047
769.17s - 778.85s |  and it allows the inclusion of unicode characters using encoded data and here is how encoded word
778.85s - 785.33s |  works. So first we've got the equals and question mark that indicate the start of encoded word.
786.93s - 792.53s |  The following character the following is the character encoding in this case utf-8.
800.99s - 806.91s |  Inside the so the question marks act as a separator between the charset and the encoded type
808.27s - 813.07s |  then it's the type of encoding and then you've got your encoded data as hex
813.07s - 819.79s |  so it's prefixed with equals so equal 41 is an uppercase a so that's where the data occurs
822.26s - 829.14s |  and the question mark equals indicate the end of the encoded word and the actual email that
829.14s - 836.02s |  gets sent is that so you all the meta characters are removed and that email is sent to there.
839.01s - 845.01s |  To probe for encoded word you should make two requests with the two charsets. The reason for
845.01s - 851.01s |  this is that many different email parsing libraries support different charsets. When
851.01s - 857.49s |  probing you should use lowercase characters in in case the site rejects or transforms to lowercase
857.49s - 864.93s |  so I was initially using x as a charset but to reduce the size of the the probe but however on
864.93s - 870.85s |  some systems they will reject unknown charsets and it would fail so it's better to use these
870.85s - 877.49s |  two probes and then follow up with a charset of x to see if it works. If successful in each case
878.45s - 884.29s |  you'll send an email to the ones displayed. In a real probe you would use a collaborator payload
884.29s - 891.17s |  or a similar tool. I've highlighted the encoded and decoded text in red so for example equals
891.17s - 901.81s |  61 is a lowercase a. So we've covered how encoded word works so let's dive into some real world case
901.81s - 910.13s |  studies. The following case studies all use the Ruby mail library which has over 508 million
910.13s - 918.29s |  downloads. At the time of testing the version was 2.8.1. This library is used by many popular
918.29s - 928.38s |  applications including github, zendesk, gitlab and bugcrowd. So for my first case study I'm going to
928.38s - 933.58s |  show you how I exploited gitlab enterprise. I love this vector because it's so elegant.
934.38s - 939.26s |  So first I used a charset of x because this was not important on the enterprise product.
941.26s - 948.14s |  Then I use an encoded at symbol so equals 40 is encoded at and then I used the underscore
948.14s - 954.70s |  character. So interestingly encoded word supports equals 20 as a space but also underscore. What
954.70s - 961.98s |  happens then is the email is split in half and the email is sent to that address. So gitlab thinks
961.98s - 971.50s |  the address is example.com but it actually goes to psres.net. So what was the impact on gitlab
971.50s - 977.50s |  enterprise? Well I could verify email addresses that I didn't control. This means I could gain
977.58s - 988.53s |  access to gitlab enterprise servers that use domain-based registration restrictions. To understand
988.53s - 994.85s |  the next set of slides let's have a quick recap on the how the email gets sent at the smtp level.
995.49s - 1000.53s |  So there's a conversation between the mailer and the smtp client and that and there's a handshake
1000.53s - 1005.25s |  that occurs but that's not important for this part of the talk. The important part is the receipt2
1005.25s - 1011.25s |  command. You'll notice it's enclosed with angle brackets. We're going to abuse this in the next
1011.25s - 1022.27s |  few slides to change the email destination. Gitlab is also an idp and I exploited the email
1022.83s - 1029.07s |  verification. So I used x for the slide because it wouldn't all fit on. No one needs to be able
1029.07s - 1036.35s |  to see it but you'd have to use this charset specified in red here. Then I used an encoded
1036.51s - 1042.75s |  symbol again but this time I used the greater than symbol. So this is an encoded greater than symbol
1043.47s - 1051.71s |  and then an encoded space and then gitlab thinks the domain is example.com but it actually goes
1051.71s - 1057.31s |  to psres.net. So you can spoof any domain you like and verify any domain you like on gitlab.
1060.06s - 1066.86s |  So yeah using this bug you could bypass domain-based access controls that websites
1067.18s - 1073.42s |  that support gitlab as an idp. This screenshot shows that I've got a Microsoft verified email
1073.42s - 1078.46s |  address and gitlab email address. It's a bit small but you can see it's verified.
1080.75s - 1088.27s |  So this one is more complex and this works on zendesk and uses the quoted local part with
1088.27s - 1099.36s |  encoded quotes. First we start the quoted local part then we use a q encoded double quote.
1099.36s - 1105.36s |  So equals 22 is a double quote followed by an encoded at symbol this time.
1107.60s - 1115.28s |  Next we have to use the greater than and a null character for zendesk. So this has the same effect
1115.28s - 1123.86s |  on space the null character prevents the rest of the address from being used. Due to the quirks of
1123.86s - 1130.58s |  the mailer and the validation that zendesk use I had to use an encoded less than character and
1130.66s - 1137.38s |  a double quote and my theory for this is that zendesk were doing email parsing multiple times
1137.38s - 1142.42s |  so adding all this would then decode and then start to remove parts of the email address
1143.54s - 1148.50s |  and then we finish the quoted local part and the actual email that gets sent is there.
1148.50s - 1157.94s |  Absolutely crazy um yeah pretty nuts. So the impact of this attack was attackers could verify
1157.94s - 1163.14s |  email domains from domain email addresses from domains they don't control which means they could
1163.14s - 1172.43s |  access zendesk email domain protected support centers. GitHub were also vulnerable to the
1172.43s - 1180.03s |  greater than a null attack so first I created an encoded at symbol then I used an encoded
1180.03s - 1187.95s |  greater than symbol to end the receipt to command and github required a null character so adding
1187.95s - 1193.23s |  this null character would then ignore the rest of the address and that would go to that email again.
1197.02s - 1203.02s |  So using this technique I was able to verify domains I didn't control on github and I had
1203.02s - 1213.97s |  verified emails from mozilla.com github.com and microsoft.com. By spoofing domains on github I
1213.97s - 1218.85s |  could verify domains I don't control this means I could bypass domain-based access controls
1218.85s - 1225.57s |  on websites that used github as an identity provider. For example I could penetrate internal
1225.57s - 1233.09s |  networks protected by cloudflow zero trust if it was configured to use github as an idp and email
1233.09s - 1240.53s |  domain validation. So the following screenshot shows zero trust trusting domains from github.com
1240.53s - 1246.53s |  since any domain can be spoofed and verified this vulnerability affected cloudflow zero trust
1246.53s - 1256.19s |  instance using email domain validation. So as I was testing multiple ruby libraries I could I
1256.19s - 1262.59s |  discovered that you could use base64 encoded email addresses that's why not right we all need this
1262.59s - 1271.39s |  don't we need base64 encoded addresses in this example you can it uses the b as the encoding
1271.39s - 1281.55s |  type so that indicates base64 and this is a base64 foobar so I'm using foobar as an example but any
1281.55s - 1289.63s |  character can be encoded and that results into an email of foobar at psres.net don't worry it gets
1289.63s - 1299.23s |  worse it gets more disgusting. So who remembers this a script tag encoded in utf-7 this xss vector
1299.23s - 1309.23s |  used to work on ie anybody remember it yeah surely no let's see surely email parsing libraries
1309.23s - 1317.23s |  won't allow me to use a utf-7 charset of course they do using the ruby library mail here is a
1317.23s - 1326.11s |  utf-7 encoded address so this is a an utf-7 foobar you'll notice the ampersand that's intentional
1326.11s - 1334.03s |  because that's the character that they support for utf-7 so the the charset will be decoded and
1334.03s - 1342.11s |  the email will be sent to foobar at psres.net I know what you're thinking or maybe it's just me
1342.11s - 1352.11s |  but yes you can use utf-7 and base64 in an email address in this example there's a base64
1352.11s - 1359.55s |  email address with a utf-7 charset first the email parser will decode base64
1360.67s - 1367.15s |  then the email parser will decode the utf-7 charset finally the decoded address will be
1367.15s - 1373.95s |  sent there absolutely crazy and I'll emphasize the point that any character can be encoded I'm
1373.95s - 1382.94s |  just using foobar to make it simple to follow then I thought what about utf-7 and queue encoding
1382.94s - 1389.90s |  so here I'm going to modify the a character and replace it with equals 41 this will then get
1389.90s - 1397.82s |  decoded and then the and then it will be decoded and form a utf-7 encoded foobar so it's going
1397.82s - 1403.42s |  through two layers of encoding at this point you might start having a few doubts about following
1403.42s - 1409.98s |  the rfc especially when I tell you that this works in the domain part 2 and when I tested the
1410.86s - 1420.86s |  ruby mail library I know what you're thinking it's sorry I've lost track I know what you're
1420.86s - 1426.46s |  thinking no website is going to support utf-7 right no website is going to support that
1427.18s - 1434.94s |  but actually there was a small source code web hosting site called github they supported utf-7
1435.42s - 1440.62s |  I'm so gutted that I didn't exploit them with utf-7 because they'd already fixed it by the
1440.62s - 1447.41s |  time I found this and then yeah it'll go to that email address so foobar psres done it
1450.37s - 1457.01s |  so then I went hunting for encoded word outside of ruby and I found that php mailer supports
1457.01s - 1463.17s |  encoded word within the name of the recipient I tried exploiting this in wordpress and other
1463.17s - 1468.61s |  applications but the requirements of needing angle brackets around the email made exploitation
1468.61s - 1474.29s |  difficult still I bet there are vulnerable systems that decode the actual name of the
1474.29s - 1485.17s |  recipient so you may find this in bug bounty sites so we've explored how you can manipulate
1485.17s - 1491.33s |  email parsing to sidestep access controls but shall we take it a bit further what if we could
1491.33s - 1497.97s |  use an email address and weaponize it to gain remote code execution in this section we'll cover
1497.97s - 1506.69s |  punicode attacks and how I exploited joomla punicode is a way to represent unicode characters
1506.69s - 1513.01s |  in the current dns system punicode always starts with xn and is followed by two hyphens
1513.57s - 1519.41s |  the algorithm converts the sequence of unicode characters into a representation that utilizes
1519.41s - 1525.01s |  only alphanumeric characters and hyphens for example the domain ruchun I hope I pronounced
1525.01s - 1531.41s |  that right is encoded with the following punicode sequence as you can see there due to the very
1531.41s - 1537.81s |  nature of how punicode works it makes it difficult to test because changing one character can affect
1537.81s - 1543.57s |  the entire output and the character position due to how the algorithm works so what we want to do
1543.57s - 1551.01s |  is generate some malicious characters that when it's decoded uh sorry what we want to do is
1551.01s - 1557.81s |  generate malicious characters when it's decoded but doing so is a big challenge in these examples
1557.81s - 1563.09s |  you can see the unicode character changes when one byte is modified this makes it difficult to
1563.09s - 1570.61s |  generate a malicious payload so after reading about punicode in uh on wikipedia I followed
1570.61s - 1578.45s |  a link to an online punicode converter and I began to experiment the converter used the idn php library
1578.45s - 1584.29s |  I first started to add zeros to the beginning of the punicode address to convert it into ascii
1584.29s - 1589.97s |  characters so I initially succeeded generating comma a comma which was so surprising I doubted
1589.97s - 1595.33s |  my eyes encouraged by this I started to experiment further and managed to produce an art symbol
1598.03s - 1602.59s |  so after searching github I found an interesting target using the library
1602.59s - 1609.63s |  joomla this was great because if I got xss then I would have rce doing a source code analysis
1609.63s - 1615.07s |  I noticed they were escaping the email before it was punicode decoded this means if I could
1615.07s - 1621.87s |  produce some malformed punicode that when decoded produces html I could get xss but it wouldn't be
1621.87s - 1629.63s |  that easy sounds simple just give the decoder some malformed punicode and generate some html
1629.63s - 1634.83s |  but remember how the algorithm works any change in the character can result in a completely
1634.83s - 1640.83s |  different output I thought about this for a while and I thought that this was a good job for a fuzzer
1641.87s - 1648.59s |  so I wrote a fuzzer to generate malformed punicode and the results were interesting I found many ways
1648.59s - 1653.07s |  to generate different characters so you can see what I was trying to do here I'm trying to generate
1653.07s - 1661.10s |  an svg type so I started generating millions of different character combinations I managed to
1661.10s - 1667.18s |  construct partial xss vectors but I encountered several issues I could only generate two ascii
1667.18s - 1673.10s |  characters by using more than one punicode subdomain this limitation arose from the specific
1673.10s - 1681.26s |  workings of the punicode of the punicode algorithm php and the quirks of this buggy php idn library
1681.26s - 1686.54s |  as you can see in the examples I was really close but these problems made exploiting joomla
1686.54s - 1693.90s |  very difficult I concluded that xss was not feasible so because although I was able to
1693.90s - 1699.66s |  generate a single quoted attribute it required an underscore character and joomla however
1699.66s - 1704.06s |  does not permit underscore does not permit underscore characters in the domain part of
1704.06s - 1710.62s |  the email address so you can see those mad punicode addresses are trying to inject some html
1711.58s - 1717.98s |  so what's that the end of the story not quite I thought about this for a while and I worked out
1717.98s - 1724.14s |  that you could use a single punicode subdomain and you could generate any opening tag eventually
1724.14s - 1729.74s |  after a lot of testing I concluded the only exploitable vector was an opening style tag
1730.30s - 1736.14s |  here I use malformed punicode to construct it it looks like a test string right but this is
1736.70s - 1743.10s |  this is actually how it works style 1 2 3 and 3 2 1 sorry and that would generate style tag
1745.33s - 1751.49s |  the rest of the pre-existing joomla html code would add the space and the closing angle bracket
1751.49s - 1757.81s |  for me so it injects this style tag and then the rest of the html adds those characters for me
1760.02s - 1765.30s |  so what I'd need is two accounts the first registered registers with a style tag with
1765.30s - 1772.26s |  malformed punicode as demonstrated the second account has the actual css payload inside the
1772.26s - 1779.38s |  name of the user that imports the malicious style sheet the first account starts with a
1779.38s - 1785.62s |  and the second account starts with x this is to ensure the style injection occurs first
1785.62s - 1792.74s |  and then the payload with the import occurs second notice I'm using curly braces this is
1792.74s - 1798.58s |  to trade to treat all the html that occurs before the import as an invalid css selector
1798.58s - 1808.24s |  and this still works because this is css right it'll just work so the first step is to register
1808.24s - 1814.88s |  two accounts for the attacker the first with the malicious punicode and the second with the evil
1814.88s - 1821.92s |  css so here we're using the malformed punicode in the email and the second account in the name
1825.66s - 1832.86s |  the attacker then uses import chaining and a custom node server a custom css exfiltrator
1832.86s - 1839.34s |  to quickly exfiltrate the c-surf token from the admin and when the admin visits the user's page
1839.34s - 1844.30s |  this css will get executed and the c-surf token is leaked to the attacker
1846.06s - 1854.93s |  the screenshot shows this process happening using the exfiltrated token the attacker then
1854.93s - 1862.05s |  uses the css exfiltrator and gives the admin a url the admin visits that site and the c-surf
1862.05s - 1868.05s |  attack is then performed on the admin using the exfiltrated token and then the admin template
1868.05s - 1877.60s |  is then modified and then you get rce now james said i should do a live demo i wasn't as keen
1877.60s - 1890.54s |  but let's give it a shot right so on the left is the victim so it's the admin on the left
1891.18s - 1895.82s |  on the right is the attacker we've also got the exfiltrator running
1896.78s - 1904.06s |  and this is where the token will be extracted so the attacker visits the page i've pre-filled
1904.06s - 1910.22s |  the data because you don't want to see me typing everything and the email address contains a
1910.22s - 1915.98s |  malformed punicode so i get an error and that error is just because i haven't configured
1915.98s - 1924.14s |  mail on the server and then you register a second account and this is with the actual payload in
1924.14s - 1935.60s |  that exfiltrates the token so the two accounts are registered now let's log in as the admin
1935.60s - 1951.79s |  and pray to the demo gods right thank you very much but we still need to send the message to
1951.79s - 1957.47s |  the admin right hey admin how's your day going yeah going good living the dream let's click on
1957.47s - 1966.32s |  this so i'm showing you a real attack he wouldn't show the payload in there but we've backdoored
1966.32s - 1976.99s |  joomla and then the attacker goes to pond and we've got rce we're casting etc password thank you
1976.99s - 1994.46s |  thank you so whilst conducting this research i found it useful to follow the following methodology
1994.46s - 2002.06s |  probe observe encode exploit first probe for encoded word observe that it will be decoded
2002.06s - 2007.34s |  to confirm that it's supported then encode the various characters and observe how they're
2007.34s - 2012.94s |  decoded and then follow with an exploit that abuses these characters so this methodology
2012.94s - 2018.22s |  this methodology is spelt out here so these are the steps you can take to exploit and this is the
2018.22s - 2026.26s |  some of the steps i use to exploit these targets hackverter is a free open source tool that i wrote
2026.26s - 2032.98s |  for burp suite i've crafted some hackverter tags to help you generate unicode overflows
2032.98s - 2040.02s |  and encoded word attacks easily within burp turbo intruder is another free burp extension
2040.02s - 2045.30s |  written by james kettle i've created a turbo intruder script to exploit the mailers so you
2045.30s - 2051.38s |  remember when github supported null for example this was found with turbo intruder i've also
2051.38s - 2058.26s |  created a punicode fuzzer to help with malformed punicode the fuzzer works by giving some inputs
2058.74s - 2064.02s |  some punicode address and then the placeholders are substituted with random numbers characters or
2064.02s - 2070.02s |  white space it was really effective in finding what characters could be generated we've also
2070.02s - 2079.18s |  updated burp intruder word list with a list of these attacks too for your convenience to defend
2079.18s - 2086.22s |  against email splitting attacks make sure you filter out or disable encoded word always verify
2086.30s - 2092.54s |  email addresses before using them even when received from an sso provider after validating
2092.54s - 2098.62s |  the email address do not use the domain as a sole means of authorization because it can lead to bad
2098.62s - 2106.67s |  stuff a few blog posts were really inspirational when conducting this research i recommend you
2106.67s - 2112.11s |  read each one because they are really useful and contain really useful information the import
2112.11s - 2117.23s |  training technique to use to exfiltrate the token is from pet villa and donut awesome researchers
2120.19s - 2126.91s |  so the three takeaways that i want to leave you with are valid email addresses that can trigger
2126.91s - 2134.43s |  major parser discrepancies even email addresses that end in at example.com might go elsewhere
2134.43s - 2140.11s |  and as a result is never safe to use email domains for access control enforcement
2140.59s - 2147.31s |  we've created a web security academy ctf so you can try and do an email splitting attack
2147.87s - 2152.67s |  i've also created a docker file with the vulnerable joomla uh installation for your
2153.47s - 2160.03s |  convenience you can get all the materials and download the um all the materials for
2160.03s - 2164.59s |  this presentation are on the github repository thank you very much defcon
2164.59s - 2174.83s |  thank you any questions


url: https://www.youtube.com/watch?v=Dh220NQIkaQ
type: video
author: DEFCONConference
ingestion_date: 2024-11-10
transcription_model: large-v2
chunking_status: completed
title:
DEF CON 32 - Redefining V2G: How to use your vehicle as game controller -Timm Lauser, Jannis Hamborg

content:
{
  "webpage_url": "https://www.youtube.com/watch?v=Dh220NQIkaQ",
  "title": "DEF CON 32 - Redefining V2G: How to use your vehicle as game controller -Timm Lauser, Jannis Hamborg",
  "description": "Modern cars are a complex networks of computers put on four wheels. For security research, it is important to understand the car's internal network and exposed interfaces. But what else could you use this knowledge for? You probably guessed it from the title \ud83d\ude42. So we developed a tool to turn our research car into a game controller.\n\nIn this talk, we present Vehicle-to-Game (V2G), a Python-based project that enables the usage of cars as game controllers. V2G can run either directly on a laptop or turn a Raspberry Pi Zero WH into a Bluetooth gamepad. In addition, V2G can either be used over the OBD2-diagnostic port or by directly accessing the internal CAN-busses of the car.\n\nOur project can be a great starting point if you always wanted to tinker around with your car or want to learn about the CAN bus or diagnostic communication (UDS). To make V2G work with your car, some reverse engineering of CAN messages or diagnostic communication will be required (as well as additional hardware to connect to the CAN bus). Otherwise, if you can get this running, you can be sure that you own a more expensive game controller than your neighbors.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2339,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

1.20s - 3.20s | This text was transcribed using whisper model: large-v2

 Hello DEF CON!
3.20s - 4.20s |  Hi!
4.20s - 13.66s |  I hope you enjoy your time here, we definitely do.
13.66s - 16.66s |  It's actually our first time here at DEF CON
16.66s - 21.66s |  and thus we are very proud and excited to present to you our talk
21.66s - 26.66s |  Redefining V2G, how to use your vehicle as a game controller.
27.66s - 31.66s |  So, why do we need to redefine the acronym V2G?
31.66s - 39.39s |  Well, let me tell you a story.
39.39s - 45.39s |  Once upon a time, our professor told us we should do some research about V2G.
45.39s - 50.39s |  And what he means by that is that we look at vehicle-to-grid communication,
50.39s - 54.39s |  the communication between the car and the charge point
54.39s - 61.39s |  and also the backend and even the power grid for bi-directional charging, for example.
61.39s - 65.39s |  Well, that's actually a pretty cool research topic.
65.39s - 69.67s |  But do you know what's even cooler?
69.67s - 71.67s |  Using your car as a game controller.
71.67s - 77.67s |  So, that's why we developed this little project called Vehicle-to-Game.
77.67s - 82.67s |  But before we get started with that, a short introduction of ourselves.
82.67s - 87.67s |  My name is Tim, I'm a PhD student at Darmstadt University of Applied Sciences in Germany.
87.67s - 91.67s |  And I mainly do automotive security.
91.67s - 94.67s |  So, also a lot of theoretical stuff.
94.67s - 99.67s |  I look at protocols and standards and do a formal analysis of these standards
99.67s - 104.67s |  to see if they meet certain security goals.
104.67s - 107.67s |  Yeah, hello from my side too.
107.67s - 112.67s |  I'm Janis, I'm also a PhD student at our small automotive research group
112.67s - 118.67s |  called ACSD, Automotive Cyber Security Darmstadt.
118.67s - 120.67s |  It's located in Germany.
120.67s - 124.67s |  I finished my master's at the end of the last year
124.67s - 129.67s |  and now I'm a PhD student about resilience in the automotive topic,
129.67s - 132.67s |  but also for IoT systems.
132.67s - 138.67s |  Means what happens if an ECU in a car breaks or is going to be compromised,
138.67s - 141.67s |  how you can migrate functionality to another ECU
141.67s - 148.67s |  and strengthen the safety inside the car by such a resilience concept.
148.67s - 152.67s |  Our research group is also very focused on teaching.
152.67s - 155.67s |  We have a lecture called Automotive Security
155.67s - 159.67s |  and therefore we have to motivate students, of course,
159.67s - 165.67s |  and that's why we have created this motivating and beginner-friendly talk
165.67s - 171.67s |  and our project V2G to get students excited and motivated
171.67s - 175.67s |  about the topic of automotive research.
175.67s - 179.67s |  Maybe the most important member of our research group is our research car.
179.67s - 181.67s |  It's a Volkswagen ID.3.
181.67s - 183.67s |  It's an electric vehicle.
183.67s - 185.67s |  And since, of course, we are Germans,
185.67s - 193.52s |  so we have to do research on the Volkswagen, I think.
193.52s - 197.52s |  Usually the initial step of the automotive research,
197.52s - 202.52s |  but also other security research, is considering attack vectors.
202.52s - 206.52s |  And that's what we have to do also for the automotive context.
206.52s - 209.52s |  You can see there are various attacks.
209.52s - 211.52s |  It's a huge attack surface.
211.52s - 214.52s |  First of all, you have long-range attacks, you have short-range attacks,
214.52s - 218.52s |  but you have also physical attack possibilities.
218.52s - 220.52s |  For the long-range attacks, for example,
220.52s - 226.52s |  the cellular communication between the car and the back end of the OEM,
226.52s - 229.52s |  for example, for over-the-air updates.
229.52s - 234.52s |  In newly upcoming cars, you have also the V2X communication,
234.52s - 239.52s |  cars communicating to each other about their location, about their speed.
239.52s - 242.52s |  You have cars communicating with road signs
243.52s - 250.52s |  to get a status about allowed speed, for example, of this street section.
250.52s - 252.52s |  You have short-range attacks.
252.52s - 255.52s |  That's more or less classical cyber security,
255.52s - 260.52s |  considering Bluetooth, Wi-Fi connection for your infotainment system
260.52s - 264.52s |  between the smartphone, for example, for playing via Apple CarPlay,
264.52s - 268.52s |  for example, the music on your car.
268.52s - 272.52s |  Maybe the most interesting and car-specific attack vectors
272.52s - 274.52s |  are these physical attacks.
274.52s - 278.52s |  That's the bus systems inside the car.
278.52s - 283.52s |  There are several of them, but we want to focus on two,
283.52s - 286.52s |  and we'll go into them a little bit later in detail,
286.52s - 289.52s |  because we need them for our V2G project,
289.52s - 294.52s |  getting all information required for our game controller out of this car.
294.52s - 301.66s |  Here you can see our two main research cars.
301.66s - 303.66s |  We are focused on electric vehicles.
303.66s - 306.66s |  On the left side, you can see our Volkswagen ID.3.
306.66s - 310.66s |  On the right side, you can see the Tesla Model 3.
310.66s - 313.66s |  We use them for practical research.
313.66s - 316.66s |  Tim also introduced them as theoretical research.
316.66s - 318.66s |  I'm also more theoretical part,
318.66s - 321.66s |  but you cannot do the whole time theoretical research,
321.66s - 324.66s |  so you have to do tinkering around with a car.
324.66s - 326.66s |  It's also good for the motivation.
326.66s - 330.66s |  There's a lot of information you just get when you look at the actual car,
330.66s - 332.66s |  because the manufacturers won't tell you.
332.66s - 334.66s |  Also, for students, it's quite cool
334.66s - 339.66s |  to do research on the actual cars and projects.
340.66s - 343.66s |  We have equipped our cars with lots of techniques
343.66s - 346.66s |  to get information about them.
346.66s - 351.66s |  We'll show you in the following how we have done this.
351.66s - 353.66s |  That's the back of the Volkswagen ID.3.
353.66s - 356.66s |  We've equipped this with lots of measurement techniques.
356.66s - 359.66s |  On the right, you can see so-called vector boxes.
359.66s - 362.66s |  They're from a German company called Vector.
362.66s - 364.66s |  That's why we call them vector boxes.
364.66s - 369.66s |  They're for capturing different buses inside a car.
369.66s - 372.66s |  We have equipped the car in a way
372.66s - 377.66s |  that we can get a holistic view of all relevant buses in this car.
377.66s - 380.66s |  On the left side, you can also see
380.66s - 384.66s |  some interesting parts for the electrical engineers.
384.66s - 388.66s |  We have equipped the car with so-called LEM sensors.
388.66s - 391.66s |  They are current-measuring sensors via induction.
391.66s - 396.66s |  You can clip them on the high-voltage system wires
396.66s - 398.66s |  to measure the current.
398.66s - 401.66s |  The idea behind this holistic view
401.66s - 405.66s |  between physical and messages inside the car
405.66s - 409.66s |  is that we can compare those data
409.66s - 414.66s |  and get correlations between the actual physical measurements
414.66s - 419.66s |  and the recorded, for example, canvas data.
419.66s - 425.34s |  As I've already introduced, from a theoretical way,
425.34s - 428.34s |  there's also a practical attack surface, of course.
428.34s - 435.34s |  On the left side, you can see classical key fob attacks using an SDR.
435.34s - 439.34s |  Maybe all of you have heard about the roll jam attack.
439.34s - 444.34s |  You jam the signal of the key fob because it's using a rolling code
444.34s - 447.34s |  and the owner of the car will press a second time
447.34s - 451.34s |  and you have recorded both signals
451.34s - 456.34s |  and you resend the older one because the car hasn't heard this already.
456.34s - 460.34s |  So you have a newer one for the car unlocking this in the future
460.34s - 463.34s |  without the owner getting any notice about this.
463.34s - 468.34s |  In the middle, you can see for automotive and classical attack surfaces
468.34s - 474.34s |  also unsoldering the chips where the firmware is located on
474.34s - 476.34s |  because you have physical access to your car.
476.34s - 481.34s |  If you own the car, you can do anything you like with it, more or less.
481.34s - 485.34s |  So that's why we have unsoldered the EMMC chip
485.34s - 489.34s |  to get in contact with the firmware.
489.34s - 492.34s |  That's the same we've done with the key fob.
492.34s - 496.34s |  You can see here there was the memory chip.
496.34s - 503.34s |  And maybe another interesting part is that you can directly connect
503.34s - 507.34s |  with here you can see such a vector box to the internal buses of the car.
507.34s - 511.34s |  Here you can see one such an ECU
511.34s - 518.34s |  and we have connected this box with the CAN bus of the ECU controlling messages.
518.34s - 525.34s |  But before we go there for a little bit in detail how these messages look like
525.34s - 529.34s |  first we have to understand what this CAN bus actually is.
529.34s - 533.34s |  How can we talk to those cars?
533.34s - 540.74s |  For a game controller, we require, as I've already mentioned,
540.74s - 544.74s |  information about specific actuators of the car.
544.74s - 546.74s |  For example, the steering wheel.
546.74s - 551.74s |  We later want to transfer the angle of the steering wheel to our virtual game controller.
551.74s - 554.74s |  So we have to get this information out of the car.
554.74s - 557.74s |  And this information is transferred via the CAN bus.
557.74s - 567.49s |  The topology of such a car looks like follows.
567.49s - 569.49s |  It's a very condensed view.
569.49s - 572.49s |  It's a very simplified view of our Volkswagen ID.3
572.49s - 579.49s |  where you can see there's a main gateway ECU and several domains.
579.49s - 583.49s |  Each domain consists of several other ECUs
583.49s - 586.49s |  and each of those domains is separated in a way
586.49s - 591.49s |  based on the criticality of those functionalities in the ECUs.
591.49s - 595.49s |  For example, in the drive domain you can see
595.49s - 598.49s |  that's located the engine ECU but also the brake ECU.
598.49s - 600.49s |  They're all safety relevant.
600.49s - 603.49s |  So they're very critical for the safety behavior of the car.
603.49s - 608.49s |  On the left side you can see a separated domain with less criticality
608.49s - 612.49s |  for example the light controlling inside the car.
612.49s - 620.90s |  The special thing in this topology is that those domains are separated
620.90s - 622.90s |  based on this gateway ECU.
622.90s - 631.90s |  The gateway ECU is responsible for shielding the inside of the car against the outside
631.90s - 636.90s |  because, maybe you know this from combustion engines,
636.90s - 640.90s |  the outside of the car is connected with a so-called OBD2 port.
640.90s - 642.90s |  It's for diagnosis.
642.90s - 646.90s |  If you bring your car to a garage they will plug there in
646.90s - 649.90s |  and you want to prevent that via the OBD2 port.
649.90s - 652.90s |  Everyone can read everything of the car.
652.90s - 657.90s |  So that's why such a gateway ECU is introduced into this topology.
657.90s - 661.90s |  But this strongly depends on the actual car you want to consider.
661.90s - 671.58s |  That's just for the Volkswagen ID.3 and the group of vehicles from Volkswagen.
671.58s - 674.58s |  Now we get a little bit into detail about this CAN bus.
674.58s - 677.58s |  The CAN bus was developed by Bosch in 1986.
677.58s - 683.58s |  It's a dual wire twisted pair cable and as I said before it's a bus topology.
683.58s - 685.58s |  What does it mean?
685.58s - 693.58s |  The bus topology means that the ECUs are connected to the same wire or wire pair
693.58s - 698.58s |  and all ECUs get the same state of information in the respective time frame.
698.58s - 704.58s |  We have a frequency in this CAN bus and all this information is distributed
704.58s - 710.58s |  in this time frame to all ECUs connected to this CAN bus.
710.58s - 713.58s |  It's also a multi-master protocol.
713.58s - 718.58s |  It means that all ECUs can send and receive on demand
718.58s - 722.58s |  and there's no master required to control them.
722.58s - 730.18s |  Now we have the foundations how this CAN bus works.
730.18s - 735.18s |  Now we get to gain access to this physical CAN bus inside the car.
735.18s - 742.18s |  Maybe the most convenient way is to find just a repair manual or a wiring diagram of the car.
742.18s - 744.18s |  They are usually available for garages.
744.18s - 747.18s |  For Volkswagen you can get them online.
747.18s - 751.18s |  If you claim you are a garage then you can buy it.
751.18s - 757.18s |  Otherwise you have to find it out by yourself but this can become very, very hard.
757.18s - 761.18s |  So very common having such a wiring diagram.
761.18s - 769.18s |  Based on this wiring diagram you can find a good exposed position of an interesting CAN bus
769.18s - 771.18s |  where you can connect to.
771.18s - 777.18s |  For example here you can see the Tesla Model 3 which is in the mid console of the car.
777.18s - 786.18s |  There's one of three CAN buses which you can easily open and connect to ready to buy adapter.
786.18s - 789.18s |  You can buy those adapters easily on eBay for example.
789.18s - 794.18s |  And then you can gain access to this CAN bus.
794.18s - 798.18s |  If you don't want to destroy your car or altering this
798.18s - 804.18s |  there are also less intrusive techniques called contactless CAN readers.
804.18s - 808.18s |  They read CAN messages based on induction of the signal.
808.18s - 811.18s |  And that's more or less looks like a crocodile.
811.18s - 814.18s |  That's why some products called CAN crocodile.
814.18s - 817.18s |  You clamp the CAN wires high and low.
817.18s - 824.18s |  Those dual wires between the clamp of the contactless CAN reader.
824.18s - 827.18s |  And you can read those messages.
827.18s - 831.18s |  So you have gained access to the physical layer.
831.18s - 835.18s |  You have read those physical signals of the CAN bus.
835.18s - 839.18s |  Now you have to transfer them into software.
840.18s - 844.18s |  For the Raspberry Pi for example.
844.18s - 848.18s |  A CAN head where those physical CAN signals are interpreted
848.18s - 852.18s |  and transferred to the kernel of the Raspberry Pi.
852.18s - 858.18s |  There are also other options available which can conveniently be used
858.18s - 862.18s |  where you can connect your CAN bus directly via USB to your PC.
862.18s - 867.18s |  This also works for Windows so maybe it's for part of you interesting.
867.18s - 872.18s |  So now we have transferred the message to the software part of our project.
872.18s - 875.18s |  And that's where Tim continues.
875.18s - 878.18s |  Alright, so very conveniently in the Linux kernel
878.18s - 881.18s |  there's already a CAN driver built in.
881.18s - 884.18s |  And if you want to work with that there's CANutils
884.18s - 888.18s |  which has all the basic tools to use that.
888.18s - 892.18s |  Also if you want to do more advanced stuff for scripting
892.18s - 895.18s |  you can use for example PythonCAN as a really good library.
895.18s - 897.18s |  That's what we use for our project.
897.18s - 901.18s |  There's also CAN tools for more advanced command line tools.
901.18s - 906.18s |  If you're into GUIs there's SavvyCAN which is a really good open source GUI tool.
906.18s - 909.18s |  And of course there are a lot of commercial tools.
909.18s - 912.18s |  We talked about all this vector stuff before.
912.18s - 914.18s |  But let's stick with the very basics.
914.18s - 920.18s |  So you install CANutils and then there's this condom command
920.18s - 923.18s |  which will just print out all of the CAN messages on the bus.
923.18s - 928.18s |  It looks somehow like this but probably a lot faster if you're on a real car.
928.18s - 931.18s |  So for a Tesla for example it might be on one bus
931.18s - 934.18s |  it's I think like 3,000 messages a second.
934.18s - 937.18s |  So it can be quite a lot.
937.18s - 942.18s |  One step back even if you connect to this.
942.18s - 947.18s |  So for Linux the CAN interface is like any other network interface
947.18s - 951.18s |  if your adapter is compatible with SocketCAN.
952.18s - 956.18s |  The only difference is that you don't have network manager
956.18s - 960.18s |  to directly get your interface up and running.
960.18s - 963.18s |  And you also need a bitrate.
963.18s - 969.18s |  So you have to tell the computer how fast the bus operates.
969.18s - 974.18s |  And you can measure that by using an oscilloscope of course.
974.18s - 978.18s |  Luckily for automotive it's usually 500 kilobits per second.
978.18s - 980.18s |  So you can also try that.
980.18s - 989.18s |  And just as a disclaimer there are also more modern standards
989.18s - 991.18s |  like improvements on the CAN standards.
991.18s - 993.18s |  For example CAN FD.
993.18s - 997.18s |  And there you will also need to have the data rate for example.
997.18s - 1001.18s |  But let's assume standard CAN for now.
1001.18s - 1004.18s |  And then we've already seen the CANup command.
1004.18s - 1008.18s |  I just want to walk very quickly through what you can see here.
1009.18s - 1011.18s |  That's one single message picked out.
1011.18s - 1015.18s |  You see the interface in the front.
1015.18s - 1019.18s |  If you have multiple CAN interfaces connected that's important.
1019.18s - 1024.18s |  Then the CANID and the data length and the data.
1024.18s - 1029.18s |  And the thing is this CANID if you are used to IP
1029.18s - 1034.18s |  you're usually used to having a source and a destination address.
1034.18s - 1037.18s |  The CANID is actually neither.
1037.18s - 1040.18s |  Think of it more like a publisher subscribed topic.
1040.18s - 1049.18s |  So it will tell you how to define or how to interpret the bits in the data part.
1049.18s - 1051.18s |  Also it's the priority of the message.
1051.18s - 1056.18s |  So the lower the ID the higher the priority.
1056.18s - 1061.18s |  And this data can be really arbitrarily defined.
1061.18s - 1064.18s |  The information in there is called signals.
1064.18s - 1070.18s |  It can be 1 bit, it can be 5 bit, it can be all 8 bytes.
1070.18s - 1073.18s |  So that's up to the manufacturer to define that.
1073.18s - 1081.18s |  And that's why we usually need some reverse engineering to make sense of this information.
1081.18s - 1086.18s |  So you might want to get started.
1086.18s - 1090.18s |  But maybe you do not want to remove all the plating of your car.
1090.18s - 1096.18s |  It sounds like a lot of work to figure out all the wiring and stuff.
1096.18s - 1100.18s |  So that's actually how we started.
1100.18s - 1104.18s |  But if you don't want to do that there's also the way the garages do that.
1104.18s - 1107.18s |  So Janis already spoilered it.
1107.18s - 1113.18s |  You have this OBD2 connector for vehicle diagnostics.
1114.18s - 1120.18s |  And this connector is usually very conveniently located somewhere in the driver area of your vehicle in front.
1120.18s - 1125.18s |  And you can just plug in a diagnostic connector there.
1125.18s - 1130.18s |  It's usually an OBD2 dongle which connects via Bluetooth to a diagnostic device.
1130.18s - 1134.18s |  And will read out data like that.
1134.18s - 1138.18s |  And the protocol to do this is called UDS, Unified Diagnostic Services.
1138.18s - 1142.18s |  And it's basically a request response protocol.
1142.18s - 1147.18s |  The diagnostic tester will, for example, in our case we want the steering wheel angle.
1147.18s - 1150.18s |  So it will ask, is you responsible for that?
1150.18s - 1152.18s |  Can you give me the steering wheel angle?
1152.18s - 1154.18s |  And it will respond with the correct value.
1154.18s - 1158.18s |  So that's on top of the CAM protocol.
1158.18s - 1163.18s |  It can also be IP but usually CAM or both.
1163.18s - 1168.18s |  And in between there's actually another protocol which is called ISOTP.
1168.18s - 1171.18s |  And which allows to basically combine multiple CAM edges.
1171.18s - 1176.18s |  They are limited to 8-byte to one message in UDS.
1176.18s - 1181.18s |  So you can send longer data.
1181.18s - 1186.18s |  But that comes with the difference that now we also...
1186.18s - 1191.18s |  I told you before that this is not like source and destination address to Kennedy.
1191.18s - 1195.18s |  But for UDS it's actually the destination address now.
1195.18s - 1199.18s |  So there's also, if you want to read data, there's also a data identifier.
1199.18s - 1201.18s |  Which identifies which data it is.
1201.18s - 1207.18s |  So you can have now multiple different interpretations for data with the same kind of ID.
1207.18s - 1210.18s |  And data can be split over multiple CAM frames.
1210.18s - 1212.18s |  Just watch out for that.
1212.18s - 1216.18s |  Alright, and with that I think we should have everything ready to go.
1216.18s - 1217.18s |  Yeah, I think so.
1217.18s - 1219.18s |  We have considered the physical layer.
1219.18s - 1222.18s |  We have considered the transfer to the software.
1222.18s - 1225.18s |  We have considered how we can interpret those CAM messages.
1225.18s - 1228.18s |  So we have all together to create our game.
1228.18s - 1234.18s |  And as a small in-between motivation, that's the actual result.
1234.18s - 1237.18s |  You can see Tim sitting in our Volkswagen ID.3.
1237.18s - 1243.18s |  In front we have placed a big monitor playing Need for Speed Most Wanted from 2008.
1243.18s - 1246.18s |  With the actual car.
1246.18s - 1250.85s |  Thank you.
1250.85s - 1258.08s |  You can see a little bit more of our V2G experience.
1258.08s - 1260.08s |  On the left side you can see our setup.
1260.08s - 1263.08s |  A laptop where the game is actually running.
1263.08s - 1269.08s |  In front of the car we have placed a huge monitor for a very immersive experience for the driver.
1269.08s - 1272.08s |  But also for all other people inside the car.
1272.08s - 1276.08s |  On the right side you can see me playing again Need for Speed Most Wanted.
1276.08s - 1279.08s |  And you can see I'm very focused on this game.
1279.08s - 1286.08s |  So, as I said, it's very immersive and it's a very cool experience sitting in such an equipped car.
1288.55s - 1294.55s |  But how can we now connect the laptop, the game, with the car?
1294.55s - 1297.55s |  You can see on the right the topology again.
1297.55s - 1302.55s |  Therefore we have several possibilities to connect the car.
1302.55s - 1304.55s |  First, we can use wires.
1304.55s - 1309.55s |  We can use the USB-based P-CAN Pro, for example.
1309.55s - 1314.55s |  Connecting, as one possibility, to the internal CAN bus.
1314.55s - 1319.55s |  Therefore we have to figure out which CAN bus relevant messages are located on.
1319.55s - 1323.55s |  We have to find the relevant messages.
1323.55s - 1329.55s |  Figuring out the relevant signals of the CAN messages, as Tim already explained.
1329.55s - 1334.55s |  And there's an overwhelming number of CAN messages on this internal bus.
1334.55s - 1337.55s |  As Tim said, several thousands per second.
1337.55s - 1341.55s |  So it's quite difficult to figure this stuff out.
1342.55s - 1348.55s |  Also, the whole breakout box stuff we've shown to you is required to get access to those internal buses.
1348.55s - 1354.55s |  So the more convenient solution is connecting directly to the OBD2 port.
1354.55s - 1359.55s |  And use the diagnostic services for pulling those informations.
1359.55s - 1363.55s |  And getting conveniently just the requested information.
1363.55s - 1368.55s |  But since we live in 2024, wires are a little bit outdated.
1368.55s - 1371.55s |  We have created a Raspberry Pi head.
1371.55s - 1379.55s |  Which allows us to emulate an Xbox 360 controller with a Raspberry Pi Zero.
1379.55s - 1382.55s |  Connecting directly to the OBD2 port of the car.
1382.55s - 1388.55s |  And this Raspberry Pi connects via Bluetooth to the laptop, emulates this controller.
1388.55s - 1393.55s |  And the laptop can stand outside the car and runs the game.
1393.55s - 1396.55s |  For this setup we use UDS.
1396.55s - 1403.38s |  Now a little bit into detail of the actual hardware we use for it.
1403.38s - 1410.38s |  The lower layer of this, you can see it's a classical Raspberry Pi Zero with no modifications.
1410.38s - 1415.38s |  Above that we have located the Raspberry Pi CAN head.
1415.38s - 1422.38s |  Which is responsible for converting those physical CAN signals to a software readable CAN message.
1423.38s - 1429.38s |  And the top layer, we have created a self-designed PCB.
1429.38s - 1437.38s |  For connecting to this OBD2 port of the car.
1437.38s - 1442.38s |  From this OBD2 port we only use four connections.
1442.38s - 1447.38s |  The 12V, the ground, the CAN high and CAN low connection.
1447.38s - 1455.38s |  The CAN high and CAN low connection is directly transferred via this PCB to the lower CAN head.
1455.38s - 1458.38s |  Which converts this message.
1458.38s - 1464.38s |  But the more interesting part of this PCB is the 12V, 5V DC-DC conversion.
1464.38s - 1469.38s |  So we can very conveniently connect this dongle to our car.
1469.38s - 1474.38s |  Without the requirement for a power bank and power supply of the Raspberry Pi.
1474.38s - 1477.38s |  As a short disclaimer, we are no electrical engineers.
1477.38s - 1482.38s |  So if you have any recommendation about this, feel free to contact us.
1482.38s - 1485.38s |  We are quite happy about recommendations.
1485.38s - 1494.38s |  This circuit for 12V, 5V DC-DC conversion is just taken out of the datasheet of the used IC.
1494.38s - 1502.29s |  Feel free to come off stage to us and discuss it with me.
1502.29s - 1508.29s |  We have also added the possibility to add status LEDs, but that's to be done.
1508.29s - 1513.29s |  They are connected to the GPIO pins of the Raspberry Pi.
1513.29s - 1518.29s |  So if you want to extend the project, you can use them for your own purpose.
1518.29s - 1522.29s |  So we have the hardware, now the software.
1522.29s - 1527.29s |  I'm just going very briefly over the software architecture of our tool.
1528.29s - 1534.29s |  If you want to use it in the Bluetooth mode, there's an install script for that.
1534.29s - 1542.29s |  You just run it on your pre-imaged Raspberry Pi and it will set up everything which is required.
1542.29s - 1546.29s |  If you don't want to do it, then just run it on your own laptop.
1546.29s - 1548.29s |  There's a run script for Linux.
1548.29s - 1553.29s |  For Windows, you just directly run the Python protocol.
1553.29s - 1558.29s |  The run script actually will also set up some interfaces and stuff.
1558.29s - 1563.29s |  But you can do this beforehand if you do not want to execute it with pseudo-privileges,
1563.29s - 1567.29s |  because that's required for interface management.
1567.29s - 1575.29s |  Then for emulating the game controller, for the Bluetooth version, we used the HitPi project
1575.29s - 1577.29s |  to emulate a Bluetooth device.
1577.29s - 1581.29s |  If you run it on your own laptop, we used the VGamePad library,
1581.29s - 1585.29s |  which is also cross-platform, so it also runs on Windows.
1587.29s - 1589.29s |  You can also use that.
1589.29s - 1593.29s |  For the Bluetooth one, it kind of doesn't really work on Windows so far.
1593.29s - 1597.29s |  So if you have any recommendations on that and are an expert on Hit devices,
1597.29s - 1601.29s |  also pull requests are welcome.
1602.29s - 1609.29s |  So now to our actual domain components.
1609.29s - 1610.29s |  We have a car detector.
1610.29s - 1614.29s |  If you have multiple vehicles, as we have the ID3 and the Tesla,
1614.29s - 1618.29s |  you can give it basically a list of 10 IDs and it will figure out which car it is
1618.29s - 1622.29s |  and then use the according configuration.
1622.29s - 1625.29s |  The heart of our project is the car connector,
1625.29s - 1634.29s |  which will convert all the car signals in the messages to triggers for the Xbox emulation.
1634.29s - 1641.29s |  Then there is the vehicle configuration, which has all the vehicle-specific stuff in there.
1641.29s - 1645.29s |  I'll just have a more detailed look on that.
1648.29s - 1652.29s |  You can configure a name for your vehicle to reference it.
1652.29s - 1654.29s |  Then you have to specify which operation mode,
1654.29s - 1657.29s |  if you want to use the internal mode or the UDS mode.
1657.29s - 1662.29s |  Sometimes if you have an older car where there is no gateway in between the internal buses
1662.29s - 1667.29s |  and the OBD2 connector, you can also use the internal mode for that.
1668.29s - 1674.29s |  Or if you install the OBD2 adapter for the Tesla.
1676.29s - 1681.29s |  Otherwise, for the UDS mode, you will also have what you can see on the right side.
1681.29s - 1685.29s |  You will have to send those polling messages I talked about earlier.
1685.29s - 1691.29s |  Basically, you can just paste them in here and it will periodically send them to get the data.
1691.29s - 1694.29s |  There is also an update interval.
1694.29s - 1699.29s |  Usually, we have a higher interval for the steering angle and brakes,
1699.29s - 1702.29s |  and for the buttons we use a lower update interval,
1702.29s - 1706.29s |  because there is a limit how fast the ECUs will respond.
1706.29s - 1710.29s |  Also, we have some, you can see the auto-detect IDs I mentioned before,
1710.29s - 1714.29s |  and also some high-level configuration stuff.
1714.29s - 1717.29s |  For example, we limit the steering,
1717.29s - 1723.29s |  because if you play a racing game and you have to turn the wheel two times for the maximum steering,
1723.29s - 1725.29s |  it's just too slow.
1726.29s - 1729.29s |  Also, there is the steering dead zone,
1729.29s - 1737.29s |  which basically you have a bit more space to set your steering wheel to zero,
1737.29s - 1742.29s |  because otherwise, if it's like 0.01 degrees and it will always go left in the menus,
1742.29s - 1745.29s |  or you just cannot drive straight,
1745.29s - 1750.29s |  it's actually pretty hard to get your steering wheel to exactly zero degrees.
1750.29s - 1752.29s |  So, that's pretty handy.
1753.29s - 1757.29s |  I'll go a bit into detail on the signal configuration later,
1758.29s - 1762.29s |  but for now, let's look at how it works out.
1762.29s - 1764.29s |  Yeah, we are ready to play.
1764.29s - 1767.29s |  Unfortunately, we are not allowed to bring our car with us,
1767.29s - 1770.29s |  so we have brought some videos of the gaming experience.
1770.29s - 1775.29s |  You can see me here driving with first-person view, playing SuperTux Kart.
1780.51s - 1785.51s |  You can see I control the racing car with the steering wheel, left and right,
1785.51s - 1790.51s |  and now I've paused, because you can see I put my foot on the brake,
1790.51s - 1792.51s |  and see what happens next.
1792.51s - 1800.75s |  As expected, the racing car slows down, and I was overtaken.
1802.75s - 1809.75s |  Now, you can see I've started the indicator.
1809.75s - 1815.75s |  We have mapped the indicator function for left to throwing items in this game.
1815.75s - 1819.75s |  You can do this for your own purpose, for your own game, but we have mapped it like this.
1820.75s - 1828.75s |  So, you can see here, I'm throwing this exploding muffin to the racing car in front of me,
1828.75s - 1830.75s |  so it will explode.
1830.75s - 1836.75s |  Unfortunately, because PowerPoint is a little bit annoying,
1836.75s - 1844.75s |  usually you should see that I have turned on the full beam 2,
1844.75s - 1852.75s |  so we have mapped the full beam trigger to the nitro activation in the game.
1853.75s - 1858.75s |  So, it's very cool driving in the night, igniting, and the car speeds up.
1859.75s - 1860.75s |  See what happens?
1860.75s - 1863.75s |  Yeah, you can see the nitrogen.
1863.75s - 1871.75s |  Now, you can see it's a little bit difficult to drive, especially with just one hand,
1871.75s - 1878.75s |  but it is possible to race, it is possible to overtake enemies in this game,
1878.75s - 1882.75s |  and it is also possible for you to get the right items,
1882.75s - 1887.75s |  in this example the acceleration one, to win racing games.
1893.49s - 1895.49s |  And it's actually a lot of fun.
1896.49s - 1898.49s |  You see, we're very excited about this.
1899.49s - 1903.49s |  So, maybe, over to Tim.
1903.49s - 1907.49s |  So, the question all of you probably have in your mind,
1907.49s - 1911.49s |  how do you support your own car to use this?
1911.49s - 1919.49s |  Well, before you get started on that, just make sure you keep in mind the safety,
1919.49s - 1923.49s |  so make sure you cannot accidentally drive into a wall.
1924.49s - 1928.49s |  Because if you're in your garage, and you're really into your game,
1928.49s - 1934.49s |  and by accident you switch to drive mode, you don't want to do that,
1934.49s - 1938.49s |  even if you're probably out on the gas, right?
1938.49s - 1940.49s |  So, make sure you cannot do that.
1940.49s - 1944.49s |  Of course, that's a problem on combustion engine vehicles,
1944.49s - 1948.49s |  where you do not have to turn on the engine,
1948.49s - 1952.49s |  but then make sure not to drain your 12-volt battery,
1952.49s - 1954.49s |  like playing all night.
1954.49s - 1960.49s |  Yeah, that's probably not good, if you do not have a charger connected.
1961.49s - 1963.49s |  So, what do you need?
1963.49s - 1965.49s |  I think we talked about everything of that.
1965.49s - 1967.49s |  The Raspberry Pi, a con-head.
1967.49s - 1971.49s |  You can also use just an OBD-II augmented cable,
1971.49s - 1976.49s |  if you do not want to solder your own OBD-II head.
1976.49s - 1980.49s |  So, that all should be less than 50 bucks, I think, to get started.
1980.49s - 1983.49s |  If you use the diagnostic mode,
1983.49s - 1987.49s |  and you have to get a diagnostic tester to reverse-engineer that,
1987.49s - 1989.49s |  that really depends on the car, probably.
1989.49s - 1991.49s |  There are sometimes some very cheap ones,
1991.49s - 1996.49s |  and if you have to get a garage-level one, it's pretty expensive.
1996.49s - 2000.49s |  So, yeah, probably too much.
2000.49s - 2003.49s |  Okay, and then you can start reverse-engineering.
2003.49s - 2007.49s |  So, here you can see the UDS tester set-up, basically.
2007.49s - 2011.49s |  The actuator, we are looking at the steering wheel angle, as before.
2011.49s - 2016.49s |  Here we have a tablet with the diagnostic tool,
2016.49s - 2018.49s |  which reads out the steering angle.
2018.49s - 2022.49s |  And here we have my laptop, which runs CAN Sniffer,
2022.49s - 2024.49s |  which is a very convenient tool
2024.49s - 2027.49s |  to show you the differences in CAN messages.
2027.49s - 2032.49s |  And what we'll do next is turn the steering wheel
2032.49s - 2035.49s |  to see where the information is.
2035.49s - 2040.49s |  And, actually, I turn it one time completely to the left
2040.49s - 2043.49s |  and one time to the right to get the min and maximum value,
2043.49s - 2045.49s |  which is possible for the signal,
2045.49s - 2048.49s |  but you have seen where it is located.
2048.49s - 2051.49s |  And, yeah, sometimes you're lucky,
2051.49s - 2056.49s |  and you will find already complete CAN database files,
2056.49s - 2059.49s |  called DBC files, online for your car.
2059.49s - 2062.49s |  Then you can also try to get this information out of there
2062.49s - 2064.49s |  and use that.
2064.49s - 2067.49s |  But, otherwise, reverse-engineering of this data is quite good
2067.49s - 2071.49s |  because it's like you can easily turn the steering wheel
2071.49s - 2073.49s |  to see where the data is, right?
2073.49s - 2075.49s |  It's just if there are 3,000 messages,
2075.49s - 2079.49s |  it might take you some time to find the right one.
2079.49s - 2082.49s |  Then, for configuring it,
2082.49s - 2084.49s |  you basically add all this information,
2084.49s - 2086.49s |  the CAN ID, the position in the signal,
2086.49s - 2088.49s |  and the length of the data.
2088.49s - 2091.49s |  And then that's why we use Python for the configuration.
2091.49s - 2097.49s |  You can just use a function to specify the signal mapping.
2097.49s - 2103.49s |  In this case, we have the first byte turning to the left,
2103.49s - 2104.49s |  the second to the right,
2104.49s - 2106.49s |  and then we specify the min and max value
2106.49s - 2110.49s |  and map this to a range of minus 1.0 to 1.0.
2113.18s - 2114.18s |  All right.
2114.18s - 2119.18s |  That's what you need to configure it for your own car.
2119.18s - 2121.18s |  So, in conclusion of this talk,
2121.18s - 2126.18s |  if anybody asks you, especially our professor,
2126.18s - 2132.18s |  now you definitely know that V2G stands for Vehicle-to-Game.
2132.18s - 2134.18s |  Car hacking can be really fun,
2134.18s - 2137.18s |  and I think our project is a great entry point
2137.18s - 2138.18s |  if you want to get into that
2138.18s - 2143.18s |  or just want to be able to say
2143.18s - 2148.18s |  that you have a very expensive game controller at home.
2148.18s - 2150.18s |  Always be careful if you do that stuff.
2150.18s - 2153.18s |  Do not drive into walls.
2153.18s - 2156.18s |  We actually use it, as Janis said before,
2156.18s - 2158.18s |  as a demonstrator to motivate students,
2158.18s - 2159.18s |  to show it to visitors.
2159.18s - 2163.18s |  It's always a good icebreaker to get started
2163.18s - 2166.18s |  about talking about automotive security.
2166.18s - 2169.18s |  And so the only question that remains is
2169.18s - 2171.18s |  what you're going to use it for.
2171.18s - 2179.74s |  Yeah. Feel free to contact us.
2179.74s - 2182.74s |  Do any contributions to our project.
2182.74s - 2183.74s |  Write us an email.
2183.74s - 2185.74s |  Here you can see the QR code.
2185.74s - 2186.74s |  The Git repository is public,
2186.74s - 2192.74s |  so you can make an issue or do a pull request.
2192.74s - 2193.74s |  Feel free.
2193.74s - 2196.74s |  We're happy if we can keep in contact with you.
2196.74s - 2201.22s |  And I think we have eight minutes left for questions,
2201.22s - 2202.22s |  if there are any.
2202.22s - 2206.22s |  Otherwise, we can also take further questions offstage.
2206.22s - 2214.06s |  Have you thought about playing with heads-up display?
2214.06s - 2216.06s |  You know, you can get these things now.
2216.06s - 2217.06s |  You just put it on the dash,
2217.06s - 2223.06s |  and it'll actually just reflect your iPad
2223.06s - 2225.06s |  or anything up onto the windscreen,
2225.06s - 2229.06s |  and it looks like a heads-up display kind of a thing.
2229.06s - 2230.06s |  Have you thought about that,
2230.06s - 2235.06s |  just for a way to project onto the screen?
2236.06s - 2239.06s |  Um, so...
2239.06s - 2240.06s |  Oh, yeah, so the question was
2240.06s - 2244.06s |  if we have thought about, like, projecting the game,
2244.06s - 2247.06s |  basically, onto the screen of the car.
2247.06s - 2249.06s |  So we've thought about that.
2249.06s - 2250.06s |  We haven't done it.
2250.06s - 2252.06s |  We also thought about because the ID3
2252.06s - 2256.06s |  actually has a heads-up display.
2256.06s - 2260.06s |  Yeah, so I think there are adapters
2260.06s - 2262.06s |  to the protocol they use there,
2262.06s - 2265.06s |  and then you can use it as an HDMI interface,
2265.06s - 2267.06s |  basically, if you plug in there.
2267.06s - 2270.06s |  So we have some plans maybe for the future,
2270.06s - 2273.06s |  but we actually haven't done that or tested it.
2273.06s - 2277.06s |  But, yeah, also just putting a projector
2277.06s - 2278.06s |  in the back of the car,
2278.06s - 2280.06s |  it's probably quite good, yeah.
2280.06s - 2282.06s |  It's not a security-related problem.
2282.06s - 2286.06s |  It's just throwing money on it by such a converter,
2286.06s - 2288.06s |  and then you can easily connect your laptop
2288.06s - 2290.06s |  with those internal screens of the car.
2290.06s - 2295.06s |  That's expensive but easily doable.
2295.06s - 2299.06s |  Um, yeah, but come up with your own setup.
2299.06s - 2303.06s |  I think there's a lot of possibility, right?
2303.06s - 2304.06s |  Yeah.
2304.06s - 2309.42s |  The question was how if we build up
2309.42s - 2311.42s |  a flight simulator out of this.
2311.42s - 2316.42s |  If you have a real airplane, maybe you can transfer this.
2316.42s - 2317.42s |  I don't know.
2317.42s - 2319.42s |  Maybe you can use also your car for this.
2319.42s - 2320.42s |  It should be possible.
2320.42s - 2323.42s |  It's just an Xbox controller.
2323.42s - 2327.42s |  You can map it to anything you want.
2327.42s - 2329.42s |  Okay, any further questions?
2329.42s - 2330.42s |  No?
2330.42s - 2331.42s |  No.
2331.42s - 2332.42s |  All right.
2332.42s - 2333.42s |  Okay, thank you.
2333.42s - 2335.42s |  Thank you for listening, and have a nice day.
2335.42s - 2337.42s |  Enjoy the last day of DEF CON.


url: https://www.youtube.com/watch?v=Fd6v9NXmszM
title: DEF CON 32 - Spies and Bytes: Victory in the Digital Age - General Paul M Nakasone
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=Fd6v9NXmszM",
  "title": "DEF CON 32 - Spies and Bytes: Victory in the Digital Age  - General Paul M  Nakasone",
  "description": "Join General Paul M. Nakasone, U.S. Army (Retired), for a deep dive into the realities of modern cyber warfare at DefCon. With critical stories from his extensive career, General Nakasone will expose the details of national security in the digital era.\n\nThe longest-serving leader of both the National Security Agency and U.S. Cyber Command, General Nakasone has been on the frontlines of America's cyber defense. He will share firsthand accounts of defending against nation-state hackers, securing critical infrastructure during global crises, and the strategies that kept adversaries at bay.\n\nThis talk will examine the evolving nature of conflict, where the battlefield extends into cyberspace and unique partnerships must be built to offer agility and resilience. General Nakasone will discuss the persistent threats posed by sophisticated hackers and the innovative defenses employed to counteract them. He\u2019ll delve into the importance of intelligence sharing, international alliances, and transparency in operations.\n\nLooking ahead, General Nakasone will present a forward-thinking vision for the future of warfare. He\u2019ll highlight the necessity for adaptive cyber strategies, resilient defenses, and the cultivation of new leadership to address emerging threats.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2650,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

1.42s - 6.42s | This text was transcribed using whisper model: large-v2

 Nothing like starting your day with a shot of Kentucky bourbon. Hi, I'm Paul. Former handle,
11.60s - 16.60s |  Dernza. I want to thank uh Dark Tangent for inviting me to DEF CON 32. More importantly I
20.04s - 25.58s |  want to thank Dark Tangent for building a community of hackers. Hackers that have been
25.58s - 30.98s |  invited not only in the private sector but also for our hackers that work in
30.98s - 35.48s |  government. And it's so good to see so many of you today. Thanks a lot for coming and
35.48s - 40.48s |  joining us for what will undoubtedly be the best DEF CON ever. Hey, let me begin. You
43.12s - 48.56s |  know it's been 180 days, 6 months since I left Cyber Command and the National Security
48.56s - 53.56s |  Agency. I retired from the Army and had a number of different experiences. It's just been
53.86s - 61.23s |  incredible. I thought I'd share something a couple months ago. I decided to look for a job.
66.11s - 73.09s |  And the job that I was looking for they said hey we have to do a background check on you. I
73.09s - 78.09s |  said fantastic. Imagine my surprise when the background check comes back and it says
79.97s - 87.96s |  unable to confirm U.S. citizenship. Wow, what a story that would be. I wonder if the
87.98s - 92.98s |  Washington Post knows. So after a informed and impassioned conversation with the Social
95.62s - 100.62s |  Security Administration, they invited me to visit their local office, which I did. Now when
102.70s - 108.46s |  you come into the local Social Security Administration office, there's like a ticket
108.46s - 113.04s |  booth. You know like you would have at a deli, right? And I saw like tickets but it wasn't
113.06s - 118.06s |  like 1 through 10. It was like 1 through 10 and then also letters there. And I was thinking
120.32s - 126.50s |  letters and numbers. Wow, I better take many tickets because I want to get seen fast. Who
126.50s - 131.50s |  knew that that's both monitored and frowned upon by the Social Security Administration. The
135.86s - 140.86s |  Department of Motor Vehicles. The DMV. Amazing place to be. Can we have the next slide
141.54s - 146.54s |  please? Now a number of my friends and family indicated to me that I should be very careful in
152.42s - 157.42s |  terms of what I do when I go to the DMV. Why is that? Because if you're not precise in the
160.12s - 165.16s |  information that you bring, they're going to send you back. Are you able to see the slide
165.16s - 175.72s |  yet? Oh, that's unfortunate. Okay, that's me at the DMV. That's before they send me home
178.96s - 185.96s |  two times to get the right information for my license. I'll spare you the second shot. But
185.96s - 190.74s |  here's what I would tell you. They didn't require me to take a road and a written test so I
190.74s - 197.12s |  thought it was at least above the curve there. Last thing I would say. Imagine after three
197.12s - 202.12s |  decades of serving and not being able to bring your cell phone to work. Right? That's a
202.12s - 207.76s |  big deal, man. We don't allow cell phones in where we work at the NSA and Cyber Command. And
207.76s - 212.76s |  then I got this email saying, hey Paul, leave your cell phone, your iPad, your Apple watch at
215.06s - 220.08s |  home. You're going to DEF CON. Wow. Good to see some things haven't changed in my life. Hey,
221.08s - 226.08s |  today I want to talk about the journey of NSA and Cyber Command and cyberspace. What I want to
229.38s - 234.46s |  talk about is our beginnings, want to talk about where we were, what we've done, some of the
234.46s - 239.40s |  impacts that we've had. I also want to talk about the opportunities and challenges and then
239.40s - 244.40s |  conclude with, hey, this is really what we need to do collectively going forward. The picture
244.82s - 250.72s |  that's shown there is the National Security Operations Center. It is among the most
250.72s - 255.74s |  sensitive places in the National Security Agency. We don't take visitors. It's not a stop on the
257.74s - 263.30s |  hop on, hop off tour for D.C. And it's one of the places where we're able to provide
263.30s - 268.18s |  indication warnings to the President, the Secretary of Defense, senior military
268.18s - 274.18s |  commanders about what's happening in the world. What's going on? And if you think about it,
274.96s - 280.14s |  this allows our leaders to have knowledge. They see first, they know first, and hopefully they
280.14s - 286.98s |  can act first. When I took over NSA in the spring of 2018, I established a series of wake
286.98s - 292.64s |  up conditions. What are wake up conditions, you ask? Wake up conditions are this idea that,
292.64s - 299.52s |  hey, I want the officer on duty to call me when something happens, right? There might be
299.52s - 303.40s |  Americans in danger, there might be a hostage crisis, there might be something that's going on
303.40s - 307.62s |  in the world that is going to get alerted to the President and the Secretary of Defense. I
307.62s - 314.12s |  always like to have that information first before my boss knows. Now, here is how the world
314.12s - 322.12s |  has changed in the past even five years. The first year, three times I was called. Three times
323.26s - 329.26s |  an entire year. My last month in the job, over ten times I was called. And it was a very
329.76s - 336.88s |  interesting relationship that developed between the senior operations officer and my wife, who
336.88s - 344.87s |  normally took the calls at our home. It went something like this. It's for you, it's them,
348.75s - 355.52s |  good luck. So that's the world in which we live in today. The scope, scale, sophistication and
355.52s - 361.66s |  speed of what we're facing is tremendously different. But if we want to understand where we
361.66s - 366.44s |  are today and where we need to go, it's my belief that we have to take a look at where we've
366.44s - 372.44s |  been, what shaped us, what we've experienced and what has actually occurred. Next slide, it's
374.38s - 380.38s |  2008. We find out the Russians have conducted an intrusion into our classified systems using
383.68s - 390.82s |  simple USB keys. Air jumping capability with malware that allows them to establish a beach
390.82s - 396.82s |  head in our secret and top secret systems. From this intrusion really three things happen. First
398.66s - 406.00s |  of all, really this sense that combat operations come to a stop in the theaters of war in Iraq
408.88s - 414.88s |  and Afghanistan. Secondly, monopolizes the intention of the incomplete Department of Defense
414.98s - 422.33s |  and the Pentagon. And thirdly, the idea is shattered within our Department of Defense that our
426.97s - 433.97s |  classified systems are truly secure. Now the Pentagon's response to this is called Operation
433.97s - 441.80s |  Buckshot Yankee. A farcical, maybe comical attempt, maybe what you would say is a shit show, in
441.82s - 447.82s |  terms of what goes on with regards to the deployment by a foreign adversary into our classified
450.00s - 455.98s |  networks. We don't understand the, we don't understand the threat, we don't understand the
455.98s - 460.50s |  malware, we don't understand the technology. We have a number of different commands to come,
460.50s - 465.38s |  come together, action officers that are trying to figure out what's going on, counting computers,
465.38s - 472.33s |  more computers one day, less computers the next day. The idea that the infection is spreading, it
472.35s - 478.35s |  is truly a mess. It's finally cleared up in the fall of 2008 when the National Security Agency is
480.23s - 486.23s |  able to identify the threat, identify the vector, and then identify the way that we've got to return
487.57s - 494.51s |  assurance to our classified systems. Okay, that's one intrusion. But what I would tell you from the
494.51s - 500.51s |  past and why this is so important is that intrusion sets off a series of actions in our Department of
502.49s - 508.49s |  Defense. Then Secretary of Defense Gates says that, hey maybe we need to think about a new command
509.35s - 515.35s |  that operates in cyberspace. We'll call it U.S. Cyber Command. And we want this command to take a
516.63s - 522.63s |  look at securing the nation in cyberspace, defending our networks and our data, and providing
523.91s - 531.22s |  support to other military commanders. Four officers were given the job of designing and selling
533.76s - 539.76s |  this concept and educating a whole slew of leaders within the Pentagon. Jen Easterly, who you'll
541.12s - 547.12s |  hear about or you'll hear from later today, S.L. Davis, T.J. White, and myself. Now this is
550.68s - 556.68s |  2009. We were talking about things like, how does an email transition the internet? How do you
556.70s - 562.70s |  work TCP IP? How do you take a look at hunting and penetration testing? How do you take a look at
565.60s - 571.60s |  building a secure architecture? We were having this conversation, I realized, with people and
575.58s - 581.58s |  senior leaders that had never turned on their computers. In fact, their assistants were printing
582.42s - 588.42s |  their emails, providing them to the leaders, and the leaders would write out the response. And
589.36s - 595.36s |  the assistant would send it back to the person that asked the question. So we had to think
595.36s - 601.36s |  differently. Because I would share with you, sometimes new ideas in the Pentagon are not warmly
603.40s - 609.40s |  greeted. Particularly when those ideas have a request for money and people. So what do we do?
612.48s - 619.12s |  We developed a story. We talked about networks that were like neighborhoods. We talked about
619.12s - 625.12s |  security in terms of the way that you put on locks and alarm systems on your house. The idea of a
627.66s - 633.66s |  neighborhood watch. The idea that we had to think differently about a domain, a cyberspace, than
634.06s - 640.06s |  we'd ever thought about before. And these four officers took this briefing with these type of
643.50s - 649.50s |  slides to a number of different senior leaders within the Pentagon. Being able to tell that story.
651.44s - 657.44s |  Being able to actually answer the questions that came up so readily. The commands approved in
658.30s - 664.30s |  2010. A new four star headquarters is established. And then over a series of years, we build a
667.48s - 674.02s |  force. We build a force of hackers, we build a force of defenders, we build a force of analysts,
674.02s - 680.02s |  we build a force across all our services. And our first adversary is ISIS. ISIS in the terms of
681.02s - 688.27s |  being able to understand in 2015, the fact that this terrorist organization was starting to have
691.97s - 698.85s |  tremendous success in Iraq and Afghanistan, I'm sorry, in Syria and Iraq. And as they had
698.85s - 704.85s |  tremendous gains across the battle space, they were also having tremendous gains in an information
705.27s - 711.27s |  operational campaign that they were conducting to raise money, to recruit forces, and to
715.49s - 721.49s |  proselytize. Guess what? We had tremendous challenges at cybercom. We had really no
724.59s - 730.59s |  infrastructure. We had limited capabilities and we had really no authorities. And this first
730.71s - 736.71s |  foray into being able to battle an adversary was not quite successful for U.S. Cyber Command. And
741.21s - 747.21s |  then things changed in 2016. 2016 as the slide shows here, brought together our best warriors on the
749.89s - 756.33s |  internet with our best warriors on the ground. Special operations forces were our number one
756.35s - 762.85s |  calling and our number one advocate to what we were doing. Folks like Tony Thomas and Joe
762.85s - 769.65s |  Votel, leaders within the special operations community said, we need to have a virtual presence to
769.65s - 775.93s |  battle ISIS. And that virtual presence appeared. We had an infrastructure. We started to get
775.93s - 781.93s |  capabilities. We had limited authorities. And suddenly, the ability to take on ISIS became our
782.21s - 787.71s |  number one goal and our number one success story. The ability for ISIS to produce high
787.71s - 793.71s |  definition visuals, the ability for ISIS to set up multi-language websites, the ability for ISIS to
797.25s - 803.25s |  communicate broadly was taken on and was taken down. And in fact, we matched the fires on the
804.49s - 810.49s |  ground with fires on net. Now you would think after that experience, you would think, you know,
811.93s - 817.93s |  in 2015 and 2016, that we would be prepared for what information operations from a determined
819.97s - 832.46s |  adversary might bring to our country. The 2016 presidential election is well covered. I'm sorry,
832.46s - 841.73s |  if we can go back one slide, please. Go back one slide. A number of different reports that were
841.73s - 847.87s |  released in terms of what the Russians were doing in the, in this run up to the 2016
847.87s - 854.11s |  presidential election. Their equation was pretty set. It went something like this. We'll take
854.11s - 860.11s |  their best intel services, the SVR, the FSB, the GRU. We'll combine them with a series of proxies,
863.11s - 869.99s |  like the Internet Research Agency out of St. Petersburg, Russia. We'll be able to take a very,
869.99s - 876.99s |  very honed message, feeding both sides of divisive issues and then leverage the technologies of
877.05s - 883.05s |  bots and U.S. social media organizations to feed a message broadly within the United States.
885.93s - 891.93s |  Here's the thing the Russians didn't plan for. The fact that we did nothing. We failed in 2016
896.57s - 902.41s |  to protect our democratic processes. And so as I came to the command and the agency in 2018,
902.41s - 906.71s |  there was certainly a sense, whether it was from Congress, whether it was from the White House,
906.73s - 912.21s |  whether it was from the Secretary of Defense, that this election in 2018, the midterms was going to
912.21s - 918.21s |  be completely different. Here was our equation in 2018. A new organization. It's called the Russia
921.55s - 927.55s |  Small Group. It was the idea of bringing the best of NSA and U.S. Cyber Command together. It was
930.62s - 936.62s |  adding really capable leaders. Two leaders whose names you probably recognize. Ann Neuberger led
937.62s - 943.48s |  the NSA contingent of the Russia Small Group. She's going to talk later today here at DEF CON.
943.48s - 950.22s |  Tim Hawk, he led the element from U.S. Cyber Command. He's now a commander of U.S. Cyber
950.22s - 956.32s |  Command. And we took it and combined these new leaders, this new organization with a new
956.32s - 962.90s |  strategy. A strategy of defending forward. The idea that we're no longer going to take some type
962.96s - 970.96s |  of adversary trying to interfere or influence our electoral process. And so we took the idea of hunt
970.96s - 976.56s |  forward operations. Let me talk about hunt forward operations for a second. Hunt forward
976.56s - 982.56s |  operations. The idea that was brought to me by a young Air Force captain and a young NSA analyst that
982.92s - 988.92s |  said, hey general, maybe if we take a defensive team and we go to a country that invites us and we hunt
995.80s - 1001.60s |  on their networks with that country, we can discover what the Russian tradecraft, their
1001.60s - 1007.60s |  technology and their malware was all about. Sounds good to me. But here's the even better part of
1008.22s - 1014.22s |  what they thought about. The idea of taking the malware and the tradecraft that they had seen in a
1017.66s - 1023.66s |  place like Ukraine and sharing that not back with Fort Meade and the silos that exist within the
1026.94s - 1032.94s |  National Security Agency and U.S. Cyber Command, but how about with VirusTotal? A cybersecurity
1033.26s - 1039.26s |  consortium that suddenly is able to attribute, signature and develop many times an antidote to the
1043.30s - 1048.94s |  malware that we saw and then broadcast it to the world. That's the difference, ladies and gentlemen,
1048.94s - 1054.94s |  in terms of being able to defend our democracy, work with a series of partners and think
1054.94s - 1060.28s |  differently. The 2018 elections, incredibly successful in terms of being able to deliver a safe and
1060.32s - 1066.32s |  secure election. The 2020, the 2022 elections all followed a similar path. Here's why this is so
1068.10s - 1073.64s |  important to the agency in command and to, I would say, what we do in terms of election security.
1073.64s - 1078.78s |  First of all, it brought to the idea of where we work in government about the power of
1078.78s - 1084.78s |  partnerships. It begins within our organizations internally, NSA and Cyber Command, organizations
1085.26s - 1090.76s |  that need to work together. It broadly works within terms of the interagency. How do we bring in
1093.22s - 1099.24s |  CISA? How do we bring in the FBI? How do we bring in other elements of our government to ensure a
1099.24s - 1104.64s |  safe and secure election? And then the final piece, how do we bring the private sector? How do we
1104.64s - 1110.72s |  ensure the private sector that knows so much about what's going on is able to contribute to the
1110.76s - 1116.76s |  security of our democratic processes? Secondly, it sends a warning to Russia and China, Iran and
1121.70s - 1127.70s |  North Korea that we are capable actors, the best actors, the best hackers, offensively, and the
1130.58s - 1136.58s |  best defenders. No doubt, a message was sent by our action. You know, in the old days, we had a
1136.94s - 1142.94s |  term for the way that we approached the defense of a lot of our networks. We called that clean-up
1147.48s - 1153.26s |  on aisle nine. We'd seen our adversaries steal our intellectual property, steal our personal
1153.26s - 1161.26s |  identifiable information, try to influence our elections, and the role that was left to us was
1161.62s - 1169.62s |  to clean that all up. After 2018, that stops. And the idea of being able to defend forward,
1169.62s - 1175.66s |  persistently engage with your adversaries, bring a series of partners, comes to the fruition.
1175.66s - 1181.74s |  Okay. 2018 midterm elections is incredibly important in terms of our development as a force.
1181.74s - 1187.74s |  Let me share with you a story that perhaps is not as well known. Who will forget COVID-19? So it's
1191.28s - 1197.28s |  the spring of 2020, and all of us are starting to grasp this idea of a global pandemic. I think many
1200.62s - 1206.36s |  of you remember, you know, the challenges of finding hand sanitizer or looking for personal
1206.36s - 1212.94s |  protective equipment or understanding really where this pandemic was going as so many of our
1212.94s - 1220.94s |  countrymen were becoming sick and many losing their lives. In the spring of 2020, the Secretary of
1220.96s - 1225.26s |  Health and Human Services and the Secretary of the Department of Defense came together and said,
1225.26s - 1231.26s |  we need to develop a vaccine. A vaccine that can be designed, tested, and deployed not in years,
1234.14s - 1240.14s |  but in months. And this idea became known as Operation Warp Speed. Now the part of the story
1243.24s - 1248.88s |  that involves the National Security Agency and U.S. Cyber Command is the fact that the Secretary
1248.92s - 1254.92s |  of Defense came to me and said, Paul, I want to make sure as this vaccine is developed by Health and
1256.80s - 1262.80s |  Human Services and a series of private sector companies that we protect the design phase, the test
1265.04s - 1273.04s |  phase, and the detection phase. Let me be honest with all of you. When I took over as the Director of
1273.04s - 1278.28s |  the National Security Agency and Commander of U.S. Cyber Command, I don't remember the part of the
1278.28s - 1286.28s |  instruction about global pandemic. And I don't remember the part of the instruction about working
1286.28s - 1292.26s |  with a series of partners that were broader than perhaps the Secretary of Defense's remit and the
1292.26s - 1300.26s |  Defense Industrial Base. But this is where the power of what we do comes together. Because here's
1301.50s - 1308.00s |  what we did. First of all, take what is our platform at the National Security Agency and garner
1308.72s - 1312.36s |  as much foreign intelligence as possible. What are the Chinese and what are the Russians doing? How are
1312.36s - 1317.80s |  they planning for what they want to do? What is their tradecraft as they look at the development of a
1317.80s - 1325.80s |  vaccine within the United States? Secondly, let's have a hostage exchange. A hostage exchange taking our
1326.98s - 1332.98s |  best people and putting them in places like Health and Human Services or pharmaceutical companies to
1333.00s - 1338.84s |  understand how do you actually develop a vaccine? What's your network look like? How do you test it?
1338.84s - 1347.22s |  What's the assurance that you have as this vaccine is developed? And the final piece is how do you
1347.22s - 1355.24s |  coordinate all of this seamlessly to make sure that what is being done is being done based upon what
1355.24s - 1362.74s |  we're seeing our threat do? And this was the work of Ann Neuberger, who is the Director of Cyber
1362.76s - 1368.46s |  Security for the National Security Agency. Persistent in her approach, being able to bring together
1368.46s - 1372.84s |  partners, being able to understand that there are truly vulnerabilities in a number of our government
1372.84s - 1380.04s |  networks that had to be patched. It wasn't perfect, but I will tell you that we were persistent about it.
1381.14s - 1386.72s |  And we reached out to a series of partners that we had never dealt with before. And what was the
1386.72s - 1394.14s |  result? A vaccine that was delivered in record time, two weeks before the date in December of 2020.
1396.27s - 1405.99s |  Secondly, the safe development, testing and distribution of 300 million doses of a vaccine that
1405.99s - 1412.85s |  addressed COVID-19. And finally, and most importantly, to the work of those pharmaceutical
1412.85s - 1420.61s |  companies, to Health and Human Services, and to our agency in command, the realization that that
1420.61s - 1428.93s |  vaccine saved thousands and thousands of lives. That's the work of bringing together what our
1428.93s - 1437.65s |  government does best, and what the private sector does well as well. So this was really kind of the
1437.65s - 1443.33s |  end of 2020. And it was a busy year. And we were thinking that everything was really good as we had a
1443.33s - 1448.13s |  safe and secure election, as we were dealing with a number of adversaries in cyberspace, as we were
1448.13s - 1457.69s |  able to develop a vaccine, until an unannounced visitor comes to the National Security Agency the
1457.69s - 1467.05s |  Tuesday before Thanksgiving 2020. Any time that Kevin Mandia comes to the National Security
1467.05s - 1474.33s |  Agency unannounced, I get nervous. I would tell you, though, that Kevin came to talk about something he
1474.33s - 1480.73s |  was incredibly nervous about, the Russians within his network. He had started to see a series of
1480.73s - 1486.81s |  patterns within Mandia that concerned him. As he came to NSA and talked about it, we were able to
1486.81s - 1491.45s |  confirm some of the things that we were seeing as well. This became known as SolarWinds. Many of you
1491.45s - 1497.25s |  recall this. The supply chain attack by the SVR within Russia against a number of different
1497.25s - 1504.05s |  companies within the United States. Hey, what was unique about this? What was unique about this is
1504.05s - 1512.57s |  the fact that we have an adversary that understands our authorities and laws almost as well as we do.
1513.57s - 1520.73s |  As they bought a series of VPSs within the United States, brought them up, conducted their operations
1520.73s - 1528.69s |  and took them down before we could ever get a warrant. The idea of not only being able to impact tens
1528.69s - 1536.05s |  or hundreds, but 18,000 different victims with a supply chain attack. That means the Defense
1536.05s - 1541.05s |  Industrial Base. That means Microsoft. That means Deloitte. That means Cisco. That means the Health
1541.05s - 1550.89s |  and Human Services Treasury Department of State. An incredibly powerful intrusion that was
1550.89s - 1556.09s |  discovered, first of all, by Mandia, confirmed by our agency, and then dealt with by the private
1556.09s - 1563.73s |  sector. But if that was just one intrusion in 2020-21, I would have been happy. But that was
1563.73s - 1571.53s |  quickly followed by Microsoft Hafnium in March. And then who'll forget Colonial Pipeline? 43% of
1571.53s - 1579.34s |  the petroleum products that flow through the East Coast flow through Colonial Pipeline. And then, of
1579.34s - 1583.78s |  course, as we think about the summer, a series of different ransomware attacks that were conducted by
1584.42s - 1592.98s |  adversaries and criminals against JBS, among the largest food purveyors in the United States. So
1592.98s - 1599.50s |  think about this. In six months, from the time Kevin Mandia comes on our doorstep at NSA to really the
1599.50s - 1607.86s |  end of it, we've seen supply chain. We've seen zero day. We've seen ransomware. So what's our
1607.86s - 1613.38s |  playbook at the agency in command? Here's our playbook. Our playbook begins with intelligence.
1613.58s - 1618.54s |  It's being able to take what we do so well in terms of our foreign intelligence and be able to apply it to what
1618.54s - 1625.14s |  is going on. Secondly, it has always been my posture that when you're in a difficult time and not
1625.14s - 1631.70s |  understanding what your adversaries are doing, unleash your hackers. We unleash the hackers of NSA
1631.70s - 1640.54s |  and Cyber Command to understand exactly what Russia or China or a series of criminals are trying to do in
1640.54s - 1649.18s |  terms of zero days, ransomware, or supply chain. The third part is bring a series of new partners
1649.18s - 1657.62s |  together. So bring the partners within the interagency. Bring FBI and DHS to the party. Bring also this idea of
1657.62s - 1663.74s |  your international partners. So whether or not it's the Five Eyes, the English-speaking countries of the world,
1663.74s - 1672.10s |  that's the U.S., U.K., Canada, New Zealand, and Australia, or a series of broader partners. Whether or not it's
1672.10s - 1678.22s |  countries within the Indo-Pacific region that understands China well, or whether or not it's countries within Europe
1678.22s - 1685.14s |  that understands Russia well, the more the merrier. And then finally, bring the private sector and have this
1685.14s - 1693.02s |  discussion. The way that we were able to get after SolarWinds was the fact that we had a very, very brave and
1693.02s - 1699.90s |  forward-thinking CEO in Kevin Mandia coming to us to be able to understand what was going on and then being able to
1699.90s - 1710.13s |  talk about it publicly. So what's my assessment? Where are we at with all of this with regards to ransomware and
1710.13s - 1717.97s |  criminal attacks? Our attribution is much better. Our partnership is growing. Our intelligence is really good. But I
1717.97s - 1727.05s |  would tell you bottom line is, we're not keeping up. We are not keeping up. We need a new strategy. We need increased
1727.05s - 1735.69s |  pressures on countries like Russia that allow hackers to conduct criminal attacks into different countries within the
1735.69s - 1745.37s |  world. And we need some new and innovative ideas to be able to address the profit motive and the profitability of what
1745.37s - 1752.25s |  these criminals are doing. So if that was all it was with regards to what's going on in cyberspace, that would be one
1752.25s - 1760.17s |  thing. But this has been followed over the past year by even greater concerns that I have with regards to the state of our
1760.17s - 1769.29s |  cybersecurity. Many have heard that in March and May of 2020, 2023, the National Security Agency, FBI, DHS, and CISA
1769.45s - 1779.19s |  released a report about pre-positioning in our critical infrastructure and key resources. Pre-positioning by an actor that's
1779.19s - 1789.95s |  named Volt Typhoon that's tied to the Chinese government. The idea that this actor is living off the land. Living off the land.
1789.95s - 1797.63s |  The idea of being able to not have any signatures, not have any known indicators, but be able to take the resources that are
1797.63s - 1806.71s |  available at their disposal at the place and time of their choosing to create havoc within our critical infrastructure. And
1806.71s - 1813.47s |  whether or not that critical infrastructure is in the Pacific, whether or not the critical infrastructure is in the United States, the
1813.47s - 1824.19s |  intent here is an intent not to gather intelligence. It's an intent to cause havoc within our country in a time and place of our
1824.19s - 1837.03s |  adversaries choosing. The bad news is we have Volt Typhoon within our critical infrastructure. The good news is we found them. And so now
1837.03s - 1847.27s |  that we found them, what do we have to do? The first thing is we need to make sure that we talk about this publicly all the time. China
1847.27s - 1861.76s |  needs to own this type of behavior. We need to point it out. We need to make sure that a spotlight is shined on this at all times. Secondly, we need
1861.76s - 1871.36s |  to discuss with a series of nations this idea of a diplomatic approach to saying that our critical infrastructure is off limits. No
1871.36s - 1882.64s |  prepositioning and targets that are aimed at our civilian populations. Thirdly, after decades, after decades of spending tremendous amounts of
1882.64s - 1895.16s |  money, tremendous amounts of time, exhortations with regards to the state of cybersecurity, we're still not there. Our patching is still lacking. Our
1895.16s - 1907.04s |  cybersecurity levels are incredibly low. And so today at DEF CON 32, I encourage all of you, take a look at the AI cyber challenge that DARPA has
1907.04s - 1920.02s |  presented. Take a look at Northgate and the idea of being able to bring a series of ideas to bring scope and scale to the problem of cybersecurity. And
1920.02s - 1929.50s |  finally, we need a larger force. We need a larger force that's able to address a series of nation state actors or a series of criminals that are conducting this.
1929.50s - 1938.06s |  And whether or not that's being able to bring a larger force with greater partners, a larger force with technology, or a larger force with a broader private
1938.06s - 1950.45s |  sector, we need it. So change is also imprinting not only what's going on in cybersecurity, but I will also tell you the character of warfare and our
1950.45s - 1959.93s |  national security. What do I mean by the character of warfare? This character of warfare is the idea of how nations be able to organize or equip or conduct
1959.93s - 1973.93s |  operations during wartime. And today, it's being done largely within the digital domain. I show here, the Magura V5, a fascinating approach that the
1973.93s - 1988.97s |  Ukrainians have taken towards battling the Russian Black Sea Fleet. You know, when the Russians invaded Ukraine in February of 2022, the Ukrainian Navy had no
1988.97s - 2002.45s |  ships. Yet, in a little over two years, the Ukrainian Navy, utilizing a series of approaches that bring their hackers together, that bring their industrial
2002.53s - 2014.81s |  private sector partners together, that brings technology together, have developed platforms like these that have sunk over a third of the Russian Black Sea Fleet. That's $500 million
2014.81s - 2032.71s |  in damages. What does one of those platforms cost? $250,000. That's it. And guess what? An operator utilizes a simple laptop with a Starlink connection that
2032.71s - 2047.39s |  allows that platform to approach 40 miles an hour, travel about 400 kilometers, and deliver a lethal impact of 700 to 800 pounds of explosive. Ladies and
2047.39s - 2058.11s |  gentlemen, that's the future of warfare. That's the changing character of warfare that's playing together and playing before our eyes right now. I would tell you much as the
2058.11s - 2070.99s |  book in the 1990s said, it's not the big that eat the small, it's the fast that eat the slow. And this is the fast eating the slow. Hey, but there's been a bigger
2070.99s - 2080.63s |  picture. It's not only just the changing character of warfare, it's the changing nature of our national security. Think about the national security, how it's
2080.63s - 2095.33s |  changed over the past five years. We've dealt with a global pandemic. We've dealt with cybersecurity, we've dealt with terrorism, we've dealt with fentanyl. And guess
2095.33s - 2112.81s |  what? The idea of two broad oceans and two friendly neighbors protecting our country doesn't hold up to this type of broader change in character of what's coming at us. So this idea of
2112.81s - 2120.65s |  national security has changed. The idea of being one power in the world is being replaced by many powers in the world. The rising importance of China, both
2120.65s - 2131.93s |  diplomatically, informationally, militarily, and economically is playing out. You know, I entered the service when there was really a binary approach to what we did. A binary approach of either
2131.93s - 2152.57s |  you're at peace, or you're at war. Today, we're in a real stat of aggressive competition, competition within our information sphere, our economic sphere, crisis, or conflict. It's our job to ensure that we
2152.57s - 2184.59s |  maintain this idea of aggressive competition, that we ensure that we were able to mitigate the crises that appear and deter the conflicts that are in the future. So what do we need to do? What goes on in terms of being able to approach this? First of all, I would tell you that there are three things that we should be thinking about. First of all, new strategies and new ideas. In the fall of 2021, the United States government released a number of
2184.59s - 2214.43s |  sensitive reports about Russia, what it was going to do in Ukraine. Guess where a lot of those reports came from? Can you imagine being Dernza and having those discussions with a series of Russian analysts that have spent decades of their life collecting this information, and you say something like this? Hey, you know that information that we've been collecting for decades about Russia, some of the most sensitive information that we have? We're
2214.43s - 2244.15s |  going to go ahead and release that to the world. Yeah, it was kind of like this, a complete silence. But if you think about it, if we're able to do that, if we take our competitive advantage, which is our intelligence, and if we can protect our sources and methods, if we do it in a manner that builds a coalition, disrupts an adversary like Russia, and enables a partner like the Ukrainians, that sounds like
2244.15s - 2275.76s |  it's in our national interest. Why wouldn't we do that? And this is the broader approach, I would tell you. And one of the things I'm most proud of about the National Security Agency is taking a look at how do we do things more transparently? Many of you have seen the tool Ghidra that we released in 2019. Can you imagine the conversation we had about releasing Ghidra in 2019? Yeah, it was fascinating. But it's also been followed up by initiatives like the Cybersecurity Collaboration Center, this
2275.76s - 2305.72s |  idea that, hey, within the NSA, we should not only get but give from the private sector. How do we work with over 2000 partners in the defense industrial base and provide them information, and also gather information from them about what's going on? I call that this idea of almost a canary in the coal mine. This is the spirit of new ideas and new approaches that we need given the changing environment of national security. Here's a second
2305.76s - 2339.96s |  thing that we need. We need unique partnerships. Unique partnerships, partnerships that consider ransomware, partnerships that consider Chinese prepositioning within our critical infrastructure, partnerships that are able to get after the increasingly challenged difficulty of dealing with ransomware. You know, this idea of unique partnerships, this idea of unique partnerships, it's not only that we have to keep up with the threat, we've got to be ahead
2339.96s - 2371.61s |  of the threat. And we need greater partnerships between what we do in the government and what many of you do as you do your own operations. You are the experts that operate in gray space. You are the ones that first see things that are unique. For someone who is at the Pentagon on 9-11, the thing that I take most from that experience is the fact that if you see something, say something. So we need all of you working
2371.61s - 2401.57s |  with organizations like the Cyber National Mission Force, a unit I once commanded, under advisement, their program to be able to understand what's going on in the private sector. Or it's working with CISA, an ability to share this information. We need this. We need your assistance. We need your expertise. We need to understand what's going on as well. And then finally, we need to maintain the trust and confidence. One of the
2401.57s - 2432.39s |  key lessons that I took as the Director of the National Security Agency was maintaining the trust and confidence of what we do with the American people. Incredible authorities, incredible surveillance capabilities that are provided to the National Security Agency. I'm a private citizen who believes strongly, just as I did when I was the Director of the National Security Agency, that oversight is a must. That scrutiny is good. That we should always understand what our intelligence community is doing.
2434.39s - 2455.25s |  But I would also tell you that we will not be transparent all that we can do. We just cannot do that. The adversaries that we have faced today, whether or not it's Russia, China, Iran, or North Korea, require us an ability to understand what they're doing and protect that information.
2455.25s - 2485.09s |  You know, one of the things that I would tell you that after six months being retired, I do think a lot about the things that perhaps I should have done, both being Commander and Director. One of the things that I am certain I should have done is come and address DEF CON as the Acting Commander. Much in the same way DT talked today about building a community, this is a community that we need to build.
2485.73s - 2496.93s |  And so it's my hope that future Dernses and Commanders will make sure that their speaking tour is stopping here at Vegas, at DEF CON 33, and beyond.
2499.51s - 2511.40s |  So as I got ready to retire, I had a lot of options. And I would tell you the number one option that I wanted to do was to be able to give back.
2511.88s - 2527.44s |  And so I'm now the Founding Director of the Institution of National Security at Vanderbilt University. In 40 days, we're going to launch this new institute. This is a university, Vanderbilt, that is world class.
2528.64s - 2536.72s |  This is a university that's able to take a look at a series of problems and approach them with expert faculty, with unique partnerships,
2537.44s - 2543.60s |  and with an interagency approach to looking at how we get things done across a number of different silos within academia.
2545.44s - 2572.36s |  It's also an institute, are we there? Okay, sorry about that. It's also an institute that's going to take artificial intelligence, cyber security, and intelligence for decision making, and apply that to the program that we're developing.
2574.55s - 2590.79s |  You know, one of the interesting things that I found in my travels across the United States when I was the Director and Commander was, I would show up on the West Coast, or Austin, or Boston, Massachusetts, and I was normally twice the age of the people I was talking to.
2591.35s - 2613.64s |  And then I'd come back to D.C., and I was one of the younger ones in the room. 15 times more people are over the age of 50 than under the age of 30 working national security issues today. We need to change that, and this institute at Vanderbilt University is our approach to be able to start that momentum.
2614.60s - 2624.20s |  So I invite all of you, those that have done so much of the work that has been able to build our economy and understand what our nation does in cyberspace, to join us.
2625.00s - 2634.92s |  Later on today, please see Brett Goldstein, who will be here to talk about what you might be able to do to join our journey as we take a look at a new institute for national security.
2635.96s - 2643.56s |  Ladies and gentlemen, thank you so much for your patience and your attention. Best wishes for DEF CON 32. Thanks a lot.


url: https://www.youtube.com/watch?v=-iNezAL_EF0
title: DEF CON 32 - Sudos and Sudon’ts: Peering inside Sudo for Windows - Michael Torres
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=-iNezAL_EF0",
  "title": "DEF CON 32 - Sudos and Sudon\u2019ts: Peering inside Sudo for Windows - Michael Torres",
  "description": "In February 2024, Microsoft announced the release of Sudo for Windows for Windows 11 Insider Preview[1]. Like the Unix sudo utility, it provides a method for users to run commands with elevated permissions. This talk will share the results of an analysis of Sudo for Windows, starting with a summary of the information provided by Microsoft. From there, we will explore the architecture used to coordinate the elevation of the specified process, the ALPC service used to communicate between elevated and non-elevated processes, how Rust interoperates with Windows APIs, and the path resolution process for files and relative paths. As part of that journey, we will discuss a few discovered security issues.\n\nThis presentation will be valuable to anyone with an interest in Windows reverse engineering or Rust memory safety. A conceptual understanding of Windows Inter-Process Communication (IPC) and heap allocation may make parts of the talk more approachable, but the main ideas will be accessible to anyone with a high-level understanding of process memory layout (stack vs heap).",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1640,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Hey everybody, how's it going? My name is Michael Torres. I'm going to be talking about uh,
8.22s - 14.22s |  pseudo for Windows. Title of the talk is Pseudos and Pseudonts. Here's a quick overview of
14.22s - 17.70s |  what I'm going to talk about. You can read so I'm not going to bore you too much, but first
17.70s - 21.64s |  we're going to go over what pseudo for Windows is cause it sounds weird. Then we're going to
21.64s - 27.58s |  hit uh, some research, initial research on it, how it all works. Talk about some non-security
27.58s - 31.54s |  issues according to MSRC, I'm supposed to use those words. Uh, then we're going to talk
31.56s - 35.60s |  about some security issues that we found. One of them is unfortunately still under embargo.
35.60s - 41.60s |  Talk more about how I found that one later. Uh, but let's hit it. So who am I? Uh, I do operational
43.84s - 48.68s |  technology security at Google. I also sort of do cyber depending on who you ask for the
48.68s - 52.62s |  United States Marine Corps Reserve. I also volunteer my time with VETSEC which is a
52.62s - 56.68s |  profit focused on helping uh, veterans of the armed services for the US and allied
56.70s - 61.80s |  countries get careers in cyber security. I also just do random research projects like this
61.80s - 69.16s |  that are not related to any of that when I get bored. So here I am. So what is pseudo for
69.16s - 73.72s |  Windows? They uh, Microsoft announced that they're going to introduce this utility in Windows
73.72s - 78.96s |  11 in the H2 update which usually drops around September so in a month or so. It's currently
78.96s - 83.44s |  an insider preview which is how I got access to test all this good stuff. The way it works at a
83.48s - 89.32s |  very high level is it uses UAC, that standard process elevation thing, to support the type of
89.32s - 93.06s |  command line features you're probably used to if you use pseudo on Linux. So taking your
93.06s - 97.66s |  input, your output, all that, putting it back into the prompt that you originally ran it in.
97.66s - 101.26s |  Uh, that's both console input and output which are different on Windows than standard in,
101.26s - 105.44s |  standard out, and standard error. It does this via fancy pipes and redirection and all that
105.44s - 110.74s |  good stuff. It's written in Rust. It is now fully open source. At the time they just, at the
110.74s - 114.54s |  time I did this research, they said it was open source but it wasn't published yet. Uh,
114.54s - 118.62s |  which meant that I did a lot more work than I actually had to do but that's alright. That's
118.62s - 124.28s |  what, that's what's fun I guess. Uh, I found two issues with again, according to MSRC, no
124.28s - 128.26s |  security impact. I have to use those words over and over again. One is a memory corruption
128.26s - 132.02s |  issue which is fun cause like I said it's written in Rust. Uh, and the other one was a
132.02s - 137.10s |  search order confusion issue. I found two issues with security impact. One allowed uh,
137.10s - 141.74s |  cross user code execution which, kind of sad. You don't really want other users to run code
141.74s - 146.94s |  as you if you like your secrets being yours. And the other one allows you to data tamper
146.94s - 151.84s |  the input and output data for sudo. And again I can't go into too much detail on that one
151.84s - 158.15s |  but we'll talk more about it later. Most of my research was conducted against sudo version
158.15s - 162.99s |  1. Uh, you'll note that both of these bullet points say sudo version 1 but have different
162.99s - 167.39s |  signature dates. I can't help you. They didn't increment the version number so I just had to
167.41s - 173.53s |  use the signature date on the binary to distinguish the two. Uh, one is from February, one's
173.53s - 177.09s |  from March. I don't know if they've released a more recent update cause I haven't checked in
177.09s - 182.09s |  the last three weeks. So they might have but three weeks ago it was still the version from
182.09s - 189.89s |  March. So precursor things to know. User account control. If you use Windows, which I
189.89s - 194.59s |  assume most of you do cause you came to a talk about sudo for Windows, you've seen a user
194.59s - 197.35s |  account control prompt, right? You always just hit yes cause you don't care what you're
197.35s - 202.77s |  doing you just want it to work. Uh, the way it works is normal processes without elevation run
202.77s - 208.31s |  in what's called medium integrity. That's pretty much everything except for processes or
208.31s - 213.45s |  systems that are designed to use low integrity. Which quick shorthand is basically just web
213.45s - 217.49s |  browsers and your PDF reader because they want that to have the absolute least privilege they
217.49s - 222.19s |  can. Elevated processes, so the thing that runs once you hit that yes button cause you don't
222.19s - 227.97s |  care you just want it to work. Uh, we're run as high integrity. Only processes running in
227.97s - 234.11s |  high integrity are allowed to modify system resources which implicitly means that they can
234.11s - 239.11s |  get system level permissions which is roughly equivalent to root on Windows, right? It's
239.11s - 242.55s |  considered a defense in depth measure by Microsoft. They do not consider it a primary
242.55s - 247.73s |  control. They do not consider UAC bypasses a security issue. They won't service them, they
247.73s - 252.13s |  don't consider them part of bug bounty. Importantly for why sudo for Windows needs to
252.13s - 258.63s |  exist, you can't spawn a process with UAC and inherit the standard in standard out standard
258.63s - 263.17s |  error or console input and console output into the privilege process. Meaning that if you're
263.17s - 269.25s |  in a command prompt and you try to run, you know, reg query as a privilege process, you can't
269.25s - 273.85s |  then pipe that into another command or redirect it into a text file or something like that.
273.85s - 281.24s |  It'll spawn it as a new process that can't put it back into your same window. Other things to
281.24s - 286.74s |  know about, uh, the ALPC interface. It's an inter-process communications framework. It is
286.74s - 291.92s |  officially undocumented and only used by Microsoft internal systems. The way it works is the
291.92s - 296.88s |  server listens on a port which is just an object cause everything in Windows is an object.
296.88s - 302.02s |  That port is just a string name. Sometimes it's a string as is the case with sudo. You can
302.02s - 308.16s |  see the example there. Uh, sometimes it's a GUID if it's a com object or things like that.
308.16s - 313.60s |  The way that security is supposed to be implemented on ALPC is that the server can query
313.60s - 319.26s |  attributes of the client, like the process ID, the, uh, SID, the principal name, and all of
319.26s - 325.88s |  that of the color. And the client is able to say I only want to connect to an ALPC server if
325.88s - 330.08s |  it's also this SID or some other properties that I don't remember frankly and they're not in
330.08s - 334.52s |  the slide so I'm not gonna remember them right now. Um, the other thing to know is that in
334.52s - 340.18s |  Rust if you want to use Windows native APIs like create process or shell execute X which are
340.18s - 344.48s |  important if you're trying to run a process as an elevated user. Um, you have to use one or
344.48s - 349.16s |  you don't have to but Microsoft released two crates for it. Windows and Windows Sys. So
349.16s - 354.36s |  those are first party owned by Microsoft. They both require you to run in unsafe Rust.
354.36s - 358.60s |  Meaning that now we can get memory issues and buffer overreads and buffer overruns and all
358.60s - 363.34s |  that good stuff. Um, the only difference between Windows and Windows Sys is the Windows
363.36s - 369.76s |  crate does type coercion for you. So if you have a Rust string and you want to call a Windows
369.76s - 373.94s |  API if you use the Windows crate you just give it the Rust string and magic happens. I don't
373.94s - 377.78s |  really know Rust that well so sorry it just magically happens to me. Uh, whereas with
377.78s - 382.52s |  Windows Sys you have to explicitly cast things into the right data type to get it to work in
382.52s - 390.56s |  Rust. So Microsoft's blog post did actually include a fair bit of detail, uh, which was cool
390.56s - 394.86s |  to see, uh, both from a security research perspective and just a curiosity perspective. It's
394.88s - 399.74s |  cool to see them publish information about their tools like this. Uh, there are three modes
399.74s - 404.26s |  that Sudo for Windows supports. Those are new window, input closed, and inline. The new
404.26s - 409.06s |  window one is basically just the same as if you ran run as and then the command. So there's
409.06s - 413.66s |  not really much novelty there. Uh, the input closed and inline modes do this weird client
413.66s - 418.26s |  server thing which you can see at the bottom, uh, right there. That sort of high level thing
418.26s - 422.78s |  we'll go into that more in a second. The difference between inline and input closed is in
423.76s - 428.06s |  input closed the elevated process can't see the un-elevated console's standard end. So if you
428.06s - 433.14s |  were to pipe the result of a command into a Sudo execution and your system is configured to
433.14s - 439.04s |  run it in input closed mode, your elevated process won't be able to see it. They say that
439.04s - 444.82s |  those are in order by most secure to least secure so new window being the most secure and
444.82s - 448.78s |  inline being the least secure. Um, they don't really go into a lot of details about that
448.78s - 453.80s |  other than that it's, it keeps things open for longer. Um, again I mentioned earlier it, in
456.10s - 460.26s |  the blog post they say it's open source. They link to a GitHub repo. That GitHub repo was
460.26s - 464.50s |  empty when I was doing this research so I just got to look at Rust code in Ghidra which if
464.50s - 469.48s |  you haven't done it I don't recommend it. Um, but now it's open source. You can go on GitHub
469.48s - 473.14s |  and look at all their stuff. Um, they included that diagram as I mentioned to explain the
473.14s - 476.74s |  request flow. We'll go into that more in a second but you can see that there's a client
476.74s - 485.17s |  server thing in there. So off the rip like this was actually found after the rest of this
485.17s - 489.31s |  research cause I was finally able to look at the source code. The new window mode still
489.31s - 495.11s |  creates that RPC server so you're still able to do fun things with the RPC server. Um, it
495.11s - 500.45s |  doesn't always do what's on the tin. Sometimes it does actually pull in your standard in,
500.45s - 503.85s |  standard out, standard error in your console input and console out and pipe it into the new
503.85s - 510.13s |  process. Um, again it's supposed to be the most secure uh but it does always get the standard
510.13s - 516.53s |  in handle unlike the input disabled one. I don't know of any ways that that's necessarily a
516.53s - 520.53s |  security issue but it's kind of an odd novelty because they describe it as being the most
520.53s - 527.63s |  isolated from the unprivileged process perspective. So I started looking into this because
527.63s - 533.11s |  I saw on Hacker News that veritable Y Combinator uh news aggregator that one of my co-workers
533.11s - 536.45s |  at Google actually which I didn't know at the time made a blog post about Sudo for Windows
536.45s - 541.71s |  and published some research. Um, he pulled apart the RPC server some and found that at the
541.71s - 547.09s |  time that RPC client server thing had zero authentication which is obviously very bad. That
547.09s - 550.95s |  means you can just tell the server you would like to run a privileged command and it'll
550.95s - 555.93s |  happily do it. Um, that was fixed by the time I was testing it. Note that that's in quotes.
555.93s - 561.23s |  Talk more about that in a second. Um, and it talked to again it pulled apart that RPC like
561.23s - 566.39s |  client server API if you will and highlighted the methods of interest to call. Specifically
566.39s - 572.03s |  that server do elevation API. That's what actually is called by the client into the server
572.03s - 577.01s |  to coordinate execution, passes handles that the process binds to and then you can get all
577.01s - 581.11s |  your input and output and all that good stuff. It also passes a bunch of parameters relevant
581.11s - 585.65s |  to the command being ran like the command to run, arguments to the command, the current
585.65s - 594.60s |  working directory and optionally the environment depending on the flags you pass to Sudo.
594.62s - 598.96s |  Here is a more detailed look at run mode 3 inline mode. This is the one I did most of my
598.96s - 603.74s |  research with because it is listed as the most insecure so it's probably the easiest target
603.74s - 608.84s |  right? I'm lazy. Um, you can see on the far side there you have the actual unprivileged
608.84s - 613.64s |  console where the person runs Sudo who am I and they're trying to run it as that elevated
613.64s - 619.08s |  user. The way that works is it first spawns an elevated process to host that RPC service
619.08s - 623.12s |  using normal run as. The user gets a prompt again they click yes like everyone does
623.14s - 628.32s |  because they just want the thing to work. Um, the client then sends an RPC into that
628.32s - 633.22s |  privileged process telling it what command it wants to run. The privileged process binds to
633.22s - 637.42s |  the handles that gets passed in there so that all your input output and standard error stuff
637.42s - 643.00s |  just flows naturally. Privileged process that the user specified gets spawned and then
643.00s - 649.91s |  magic happens you can do all your normal command line pipes and stuff. So summarizing
649.91s - 653.35s |  everything we just talked about sort of high level notes. Uh, it's written in Rust, it's
653.37s - 658.45s |  open source. Uh, Rust requires you to enter into unsafe mode so again memory safety issues
658.45s - 664.01s |  can happen. Uh, to call Windows native APIs which things like this kind of have to do. Um,
664.01s - 672.34s |  an ALPC is what's used to coordinate the actual execution of the user specified process. So
672.34s - 676.84s |  our first issue, the memory safety issue in Rust. Um, sort of odd right but as I just
676.84s - 682.42s |  mentioned you have to use unsafe APIs. Uh, they removed this functionality before they
682.44s - 688.18s |  published it to GitHub so I can't tell you exactly how it happened. But at a hi- at a from
688.18s - 694.28s |  my analysis what happened was if you gave a path that rewrote from the beginning meaning
694.28s - 700.82s |  that you had a leading like backslash or C colon backslash right. It would write your path
700.82s - 705.96s |  to the start and then when it passed it to an API function it didn't truncate at the end of
705.96s - 711.04s |  where your path was. It just read until the end of the buffer to the first null byte. I think
711.06s - 717.30s |  that that happened because they assumed that a path as string would point to a null
717.30s - 721.50s |  terminated buffer as you would kind of expect it to if you're used to C. When in fact it just
721.50s - 726.50s |  points to a vector of U8s that may or may not include a null byte at the end. Um, here's
728.64s - 733.04s |  sort of my mock up of the code. Uh, you can pull these slides off the Defcon media server if
733.04s - 736.28s |  you want to take a better look at it but this is just sort of demonstrating what I just
736.28s - 741.96s |  talked about where if you assume that you can take the path as a string and then just get a
741.96s - 747.24s |  pointer to it and pass it to the Windows API function you'll end up very sad because it'll
747.24s - 752.50s |  just read until the first null byte not necessarily until the end of your target string.
752.50s - 758.44s |  Meaning you have buffer overread in heap, uh, for arbitrary numbers of bytes that you can't
758.44s - 764.02s |  necessarily control but because you can control the path you can control approximately how
764.06s - 769.76s |  far into that heap buffer you read. Uh, so like I just said you can read everything up to the
769.76s - 776.10s |  first non, non-null byte. You don't control which heap allocation you're reading and it
776.10s - 781.04s |  doesn't let you write memory into arbitrary things that are outside of your heap boundary
781.04s - 785.44s |  because it is rust. It's a vector. Uh, so it'll reallocate if you reach the capacity of the
785.44s - 791.12s |  current heap allocation. Um, but still you get to read things from previous heap
791.12s - 796.56s |  allocations which in my testing tended to just be paths but it could be something like a
796.56s - 802.66s |  token or something like that. Um, it says at the bottom there why I, it's not really a
802.66s - 808.50s |  security issue. Uh, the main problem being this is only noticeable if you run sudo with an
808.50s - 814.98s |  unprov- or a untrusted input which you shouldn't do anyway so it's not really security
814.98s - 820.38s |  impacting if you run sudo with arbitrary things someone you don't trust supplied and then
820.40s - 824.68s |  you can read other memory because you shouldn't be doing that in the first place because
824.68s - 830.01s |  you're going to execute someone else's code. This screenshot shows what I was talking
830.01s - 834.29s |  about so you can see on the left there I run sudo with a leading slash and then a path and
834.29s - 839.43s |  then you can see in process monitor that at the end of the day a create file operation or
839.43s - 845.27s |  trying to read the file, um, ends up re- trying to read a file that's the thing that I was
845.27s - 849.63s |  trying to read and then a bunch of things from presumably a previous heap allocation
849.65s - 853.39s |  because that's the path, that's the current working directory and then some garbage at the
853.39s - 861.44s |  end until it reaches the first null byte. So the second issue, uh, search order inconsistency
861.44s - 865.48s |  so in Windows just like, actually I shouldn't say that I don't know if it's true in Linux but
865.48s - 871.96s |  in Windows if you run a command without a path it is supposed to execute that command in
871.96s - 876.56s |  the current working directory if it's present and then search your path. Uh, so if you run
876.56s - 881.76s |  sudo program.exe you expect it to run the program.exe in the current working directory
881.78s - 888.28s |  not some other random program.exe. Uh, path resolution didn't work that way. The way it
888.28s - 892.66s |  worked is again because of that client server thing it would try to resolve the path in
892.66s - 896.52s |  the context of the privilege process which had a different current working directory
896.52s - 901.40s |  meaning that you could end up running a command you didn't expect to run. Uh, says up there
901.40s - 904.96s |  it's a somewhat contrived example but if you had compiled your own binary and named it
904.96s - 911.14s |  cmd.exe and then you tried to run sudo cmd.exe it wouldn't run your command.exe it would
911.18s - 917.12s |  run the system32 cmd.exe. According to Microsoft it's not a vulnerability. I have their exact
917.12s - 922.12s |  response quoted there at the bottom. But they fixed it anyway. Um, so they more or less
925.76s - 930.84s |  looked up the in the unprivileged process they looked up the command you gave them and
930.84s - 936.88s |  resolved it and then passed the fully resolved path into the privileged process. Um, they
936.88s - 942.06s |  fixed it. I'm not gonna complain too much but it's kind of odd that you accept input from
942.06s - 945.16s |  people on what issues are, fix them and then tell them yeah but we don't think it's a real
945.16s - 954.15s |  issue. And this is a very well drawn I'm an artist if you didn't know uh example of how that
954.15s - 960.07s |  would work from an attacker's perspective. So you try to run cmd.exe you expect it to run
960.07s - 965.67s |  yours it ends up running some other command in the privileged process path which isn't the
965.67s - 974.21s |  one you wanted. So let's talk more about that RPC server. Again, it's ALPC. Um, source code
974.21s - 979.39s |  wasn't available so I had to look in Giger to figure out what all these parameters meant. Uh, I
979.39s - 984.13s |  got pretty good results out of it. I didn't know what those handles were or how to deal with
984.13s - 989.09s |  them necessarily but luckily I didn't have to. You can just bind to input and output without
989.09s - 994.77s |  dealing or without worrying about the handles too much. Um, importantly the unprivileged
994.77s - 999.05s |  process ID so the one that you run before you hit that yes prompt as quick as humanly
999.05s - 1005.15s |  possible is what is used to create the socket name. So it's predictable as long as you know
1005.15s - 1010.19s |  the process ID that's uh trying to run sudo. And again I mentioned earlier after James
1010.19s - 1014.69s |  Foreshaw's blog post they added an authentication check which was checking that the
1014.69s - 1020.93s |  client's process path so that unprivileged process was the same as the server's process path
1020.93s - 1029.04s |  meaning both are running sudo.exe. See Windows system 32 sudo.exe, right? Um, overview of
1029.04s - 1033.28s |  that, that auth check on the right, right? Just is the image name of my calling process the
1033.28s - 1040.90s |  same as my image name? If it is, good to go. We'll run your command. Which brings us to our
1040.90s - 1046.74s |  first security issue. Um, it turns out that that's not really a good authentication check. Um,
1046.74s - 1053.42s |  any user can issue elevation requests to that RPC server meaning that any user of a multi-user
1053.42s - 1057.76s |  Windows system to include, you know, unprivileged users because anyone can call an
1057.76s - 1063.52s |  ALPC socket like your web browser, um, can go ahead and run commands in the context of a
1063.52s - 1068.86s |  user, uh, when they run sudo. So it's not latent and a privileged user would have to try to
1068.86s - 1075.22s |  run sudo and then you'd be able to exploit this to run it in the context of that user.
1075.22s - 1080.26s |  Exploitation requires two things. So, like I mentioned, insufficient authentication. Um, the
1080.26s - 1086.66s |  way I did that is I just injected a DLL into a sudo.exe, sudo process that I controlled so
1086.66s - 1091.70s |  that I could do whatever I want in the context of a process whose image name is the legitimate
1091.70s - 1096.24s |  sudo.exe. Um, and the other part of this was that predictable, uh, port name. That
1096.24s - 1101.68s |  predictable RPC control port name. Because users can view the process IDs of other users in
1101.68s - 1106.28s |  Windows, uh, pretty much no matter what there are some types of tokens that can't do that. Uh,
1106.30s - 1111.92s |  you can get that information very easily and then you can just call the target sudo,
1111.92s - 1117.22s |  privileged sudo process and have it run whatever you command you want and gain execution in
1117.22s - 1123.16s |  that user's context. This was patched in the version, in the second version 1 of sudo. The
1123.16s - 1129.10s |  one that was, uh, code signed on the 4th of March. So again, high level attack diagram you
1129.10s - 1132.40s |  see at the top there we have our victim who's just trying to run sudo and get on with their
1132.46s - 1139.20s |  day. We have our attacker with again, I'm an artist, very well drawn horns, thank you. Um, the
1139.20s - 1145.70s |  attacker starts their code that's just waiting and trying to find a victim sudo that is
1145.70s - 1152.04s |  running and then as soon as it notices one, it spawns its own sudo with a hooked method to
1152.04s - 1158.62s |  connect to the target RPC server instead of one that it spawned, uh, to run whatever
1158.64s - 1162.72s |  command the attacker wants. From the victim's perspective, what this looks like is they ran
1162.72s - 1167.22s |  sudo, they as fast as humanly possible because again, they're just trying to get the job done,
1167.22s - 1171.88s |  hit the yes button on the UAC prompt and then nothing happens from their perspective. But in
1171.88s - 1180.64s |  reality, the attacker was able to run whatever command they wanted. Uh, demo, I think. Do I
1180.64s - 1191.64s |  have that wrong? Hopefully it plays. All right. Well, that was surprising. So here I'm just
1191.64s - 1196.84s |  showing there's nothing up my sleeve. Um, uh, the left prompt is going to be our victim user. So
1196.84s - 1204.22s |  who am I? I'm MTU. Um, it can run sudo just fine. The right prompt is now my unprivileged user or
1204.22s - 1210.30s |  my non-administrative user, not MTU. Right now I'm going to show that, uh, sudo works and then
1210.30s - 1218.15s |  that the base prompt is not running elevated. And then on the right, on the right, we're
1218.15s - 1222.89s |  running that implant code that's just going to spawn some stuff, uh, to try to target that
1222.89s - 1228.89s |  victim sudo process. We are racing because if we don't beat the legitimate process, um, the
1228.89s - 1234.09s |  RPC socket closes and we can't run our command. So we go slowly insane trying to win the race. I
1234.09s - 1239.27s |  did test this in a debugger first, so I was pretty confident it was supposed to work. But man,
1239.27s - 1244.97s |  recording this video and just sitting there doing this for two minutes was not fun. Um, at the
1244.99s - 1250.13s |  end there, you can see that it worked. On the right side, our unprivileged process again, we were
1250.13s - 1256.17s |  able to inject into that victim server process and run command.exe as this, as the privileged
1256.17s - 1260.77s |  user. We run who am I? And we see that we're now running as that other user who is just trying to
1260.77s - 1268.50s |  run something with sudo. Well, I already played the video, but we could play it again if you
1268.50s - 1279.34s |  want. Oh, nothing showing up there. Neat. Let's try it this way. Can you see this? This video
1279.36s - 1300.82s |  now? So again, uh, again, left prompt is the uh, privileged user who's just trying to run
1300.82s - 1305.32s |  sudo. Uh, the right prompt that's about to spawn is the unprivileged user, not MTU, some evil
1305.32s - 1312.38s |  attacker man. Um, user runs command, everything works. Let's see if I can skip this bit a bit. Um,
1316.38s - 1320.08s |  user keeps running command, they keep working because you'll notice on the other side, the
1320.08s - 1324.18s |  attacker process is failing, it's not winning that race. Uh, like I mentioned, I confirmed
1324.20s - 1329.20s |  this in a debugger, but still very frustrating watching it fail over and over and over again. Um,
1329.20s - 1333.54s |  but eventually it does work. And we can see on that right side now, we just got a command
1333.54s - 1338.18s |  prompt back from the attacker's perspective. We run who am I? And we see that we are running as
1338.18s - 1351.82s |  a user other than ourselves, which is not good, I think is what it's called in the business.
1351.82s - 1365.91s |  All right. Work with me here. Nope. Hands. Perfect. Um, so I did find out after I tested
1365.93s - 1370.03s |  this again, after they made the source code available, that they made that race window really
1370.03s - 1374.97s |  short. So I assumed that the way it worked was the victim process ran its command
1374.97s - 1381.01s |  successfully and then went ahead and uh, then went ahead and closed the socket after it was
1381.01s - 1385.97s |  done. In fact, as soon as you called that elevation request API, it locked all future calls
1385.97s - 1391.19s |  of it, which would explain why I had to run the command over and over again, going slowly
1391.23s - 1396.31s |  and saying until it worked, but I don't know, not, not really a security control, but good for
1396.31s - 1401.91s |  them for locking out other users and thinking about it. So the second vulnerability I
1401.91s - 1406.65s |  mentioned, it's still under embargo, unfortunately. Um, I reported it 13th of June while the
1406.65s - 1412.75s |  rest of this research was done, April, May timeframe. Um, sort of interesting story for you
1412.75s - 1417.59s |  since I can't talk too much about the details of this one. The reason I thought of this was I
1417.59s - 1423.69s |  was on a run trying to avoid working on the slides and I realized that there was some other
1423.69s - 1429.63s |  issues with how they do that client server thing. So I was able to prove it out and get data
1429.63s - 1433.93s |  tampering and information disclosure from again, the process or the perspective of a non
1433.93s - 1441.96s |  privileged user on the privileged users stuff. So public issues again, it is a GitHub repo.
1441.96s - 1446.12s |  There are public issues that I think are sort of notable to talk about when we talk about
1446.12s - 1450.38s |  sudo for Windows. The first one, um, the elevation prompt is confusing. So there's a
1450.38s - 1455.12s |  screenshot of it on the right. You saw it earlier in the video. You don't know what hitting yes
1455.12s - 1459.06s |  will do because it's just telling you it's a sudo invocation, right? It doesn't tell you, oh,
1459.06s - 1462.62s |  sudo is actually going to spawn this other process over here. Maybe you don't want to do that.
1462.62s - 1469.20s |  It just says, hi, I'm Microsoft. I'm a legitimate binary. Would you like me to run? Um, not
1469.20s - 1473.18s |  great from a security perspective, right? Admittedly, again, most of us probably just click
1473.20s - 1477.40s |  yes as fast as humanly possible anyway, or type in our credentials if we have that version
1477.40s - 1484.14s |  of UAC enabled. But, um, I believe that they committed to trying to figure out how to make
1484.14s - 1487.88s |  it so it was more obvious what the actual command that's going to run is instead of just
1487.88s - 1491.66s |  saying, yeah, it's, it says it's legitimate. I'm just going to hit yes and hope everything's
1491.66s - 1496.32s |  okay. And the second issue, uh, which is critical to me because I like my computers to
1496.32s - 1503.06s |  insult me is, um, sudo for Linux or Unix if you will, has a mode to have it insult you.
1503.08s - 1507.78s |  If you don't have legitimate access to run a command, uh, I want that in windows cause I
1507.78s - 1515.65s |  like my computers to be mean to me when I'm silly. So summary of everything we just
1515.65s - 1519.85s |  talked about, sudo for windows is coming soon. Again, it is scheduled to be in mainline
1519.85s - 1525.79s |  windows 11 and I think windows server, don't quote me on that one. Uh, end of September
1525.79s - 1530.83s |  ish in the, in the H2 update, uh, it's open source. Again, we, we love to see that. It
1530.83s - 1534.53s |  makes it so people like me or people like anyone in this audience can go look at the
1534.57s - 1538.91s |  source code and pull it apart and understand not only how it works, but maybe find some
1538.91s - 1543.71s |  more security issues in it. So we're not shipping products that are enabling bad things
1543.71s - 1547.75s |  to happen on windows or if you're on the other side of it, using it to make bad things
1547.75s - 1553.63s |  happen on windows. I don't know. I don't judge. Um, it is meant to be a drop in replacement
1553.63s - 1557.27s |  for the way sudo works on Linux. So it lets you actually have standard in standard out
1557.27s - 1561.03s |  standard air piped and redirected and all that stuff within your command prompt or your
1561.03s - 1566.61s |  PowerShell prompt. Um, and it does all of that using user account control to elevate
1566.61s - 1572.85s |  processes and inner process, uh, communication to actually coordinate that across the not
1572.85s - 1578.15s |  a trust boundary because that's not what Microsoft calls it of UAC. Uh, sort of the big
1578.15s - 1583.45s |  takeaway for me and it's informing some more stuff I'm looking into is you cannot call a
1583.45s - 1588.47s |  windows native API without going into unsafe rust. If you want to do that or for anything
1588.87s - 1595.37s |  that uses a windows API, that means there is now the potential for you to get memory
1595.37s - 1601.35s |  corruption vulnerabilities in something written in rust, which is counter to what everyone
1601.35s - 1605.05s |  tells you about rust. So be on the lookout for that if you're a bug hunter that if you see
1605.05s - 1609.03s |  something calling a windows native API from a rust program, somewhere in that code it is
1609.03s - 1615.87s |  unsafe. Poke at that boundary. And then I'll show some references and if anyone has any
1615.87s - 1620.17s |  questions, you can step up to that mic in the middle and I'll be happy to answer them. I
1620.17s - 1635.08s |  don't know how much time I have left, but I'll answer any questions I can. Thank you. Cool.
1635.08s - 1636.08s |  Well, thanks everyone.


url: https://www.youtube.com/watch?v=-Z34ya4rb8A
title: DEF CON 32 - Manipulating Shim and Office for Code Injection - Ron Ben-Yizhak, David Shandalov
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=-Z34ya4rb8A",
  "title": "DEF CON 32 - Manipulating Shim and Office for Code Injection - Ron Ben-Yizhak, David Shandalov",
  "description": "This talk brings back from the dead an attack surface that security vendors believed they had addressed a long time ago.\n\nWe will introduce a novel and stealthy technique to apply malicious shims on a process that does not require registry modification or SDB files and leaves no traces on the disk.\n\nThe reverse engineering of the shim infrastructure will be shown while focusing on undocumented API and the kernel driver of the infrastructure.\n\nThe various operations offered by the infrastructure will be analyzed from an offensive point of view, and the course we took to achieve this unique technique will be presented.\n\nIn addition, we will unveil an attack surface research that resulted in a noteworthy attack that manipulates 2 different OS components into performing DLL injection and privilege escalation.\n\nResearching the undocumented RPC interfaces of the service OfficeClickToRun.exe uncovered a method that can inject a DLL into another process running as \u201cNT AUTHORITY\\SYSTEM\u201d, which achieves privilege escalation. For this to work, specific conditions had to be met.\n\nThe conditions we tailored will be displayed as we abuse the Opportunistic Lock and App Compatibility (shim) mechanisms.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2472,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.82s - 4.38s | This text was transcribed using whisper model: large-v2

 Hello everyone, thank you for coming to our talk,
4.38s - 5.94s |  Shimmy What You Got,
5.94s - 9.18s |  Manipulating Shim and Office for Code Injection.
9.18s - 11.06s |  We're very excited to be here.
11.06s - 12.58s |  Let's introduce ourselves.
13.86s - 15.74s |  My name is Ron Ben-Yitzhak.
15.74s - 17.86s |  I'm a security researcher at Deep Instinct.
17.86s - 19.58s |  And this is the third year in a row
19.58s - 25.85s |  I'm speaking here at DEF CON.
25.85s - 27.93s |  And my name is David Shandalov.
27.93s - 30.45s |  I'm also a security researcher at Deep Instinct.
30.45s - 39.13s |  And this is my first time here.
39.17s - 41.69s |  This is what we're going to talk about today.
41.69s - 43.25s |  I'll start with an intro
43.25s - 45.53s |  about the App Compatibility Framework,
45.53s - 48.77s |  what it is made of and known techniques to abuse it.
48.77s - 52.17s |  Then I'll dive into our attack surface research
52.17s - 53.81s |  on Microsoft Office.
53.81s - 56.81s |  I'll show how we found an interesting RPC method
56.81s - 60.45s |  and combined several manipulations into a single attack
60.45s - 64.77s |  that achieves both code injection and privilege escalation.
64.77s - 67.69s |  Then we'll show another novel attack.
67.69s - 70.73s |  We'll show the reverse engineering process of the driver
70.73s - 72.69s |  and the undocumented structures
72.69s - 75.13s |  that make the App Compatibility Mechanism
75.13s - 77.53s |  and how we discovered the finest technique
77.53s - 80.05s |  to apply a malicious shim on a process.
80.05s - 81.57s |  At the conclusion of the talk,
81.57s - 85.41s |  we'll discuss how to detect the attacks shown here
85.41s - 90.22s |  and how the community can continue our research.
90.22s - 91.74s |  The App Compatibility Framework
91.74s - 94.46s |  is used for backwards compatibility.
94.46s - 97.26s |  Software developed for old versions of Windows
97.26s - 100.30s |  might behave unexpectedly on newer versions.
100.30s - 103.10s |  Microsoft offers many compatibility modes
103.10s - 106.26s |  that might look familiar from this window.
106.26s - 108.78s |  Programs might access registry paths
108.78s - 111.34s |  or directories that no longer exist,
111.34s - 114.62s |  such as the C documented settings for those who remember.
115.58s - 118.46s |  Those issues are fixed with API hooking,
118.46s - 120.50s |  patching the assembly of the program itself
120.50s - 122.50s |  and other runtime modifications.
123.78s - 126.90s |  Behind the scenes, this is how the mechanism works.
127.58s - 130.82s |  The OS uses shim database files, or SDB files,
130.82s - 132.46s |  that contain the fixes and modes
132.46s - 134.46s |  various applications require.
134.46s - 137.18s |  The main file is sysmain.sdb.
137.18s - 139.02s |  It is maintained by Microsoft
139.02s - 142.26s |  and can only be modified by system updates.
142.26s - 144.70s |  We can view those files using a graphic software
144.70s - 148.14s |  provided by Microsoft, the Compatibility Administrator.
149.86s - 152.22s |  Here we can see that Age of Empires III
152.22s - 155.54s |  requires the compatibility mode High DPI Aware.
155.54s - 158.34s |  Users can also install custom SDB files
158.34s - 160.74s |  by writing them to these registry paths.
162.54s - 164.50s |  Like every component of the OS,
164.50s - 166.70s |  people looked for ways to abuse it.
166.70s - 168.58s |  There were several talks over the years
168.58s - 171.74s |  about the malicious implications to the shim framework.
171.74s - 175.02s |  Here you can see a DEF CON talk from almost 10 years ago
175.02s - 177.98s |  that shows shims can be used for credential access,
177.98s - 180.30s |  network redirection, and more.
180.30s - 183.46s |  Also, Alex UNESCO released several articles
183.46s - 186.50s |  about this subject back in 2007.
186.50s - 189.10s |  Because this is such an old attack vector,
189.10s - 192.38s |  most security products should detect malicious shim usage.
192.38s - 194.10s |  And the easiest way to do it
194.10s - 196.14s |  is by monitoring the registry paths
196.14s - 198.70s |  used for installing custom SDB files.
200.06s - 203.10s |  So once upon a time, David and I
203.10s - 205.26s |  wanted to start a new research.
205.26s - 207.82s |  Initially, we thought about bypassing an EDR
207.82s - 209.86s |  or even disabling it.
209.90s - 213.38s |  But apparently, some products just disable themselves.
214.26s - 216.14s |  So instead of EDR bypass,
216.14s - 218.82s |  we decided to start an attack surface research,
218.82s - 220.54s |  and we needed the targets.
220.54s - 223.86s |  One of the first choices we came up with is Office.
223.86s - 225.94s |  This software is very popular.
225.94s - 228.78s |  It can be found on almost every Windows machine.
228.78s - 230.62s |  It is also very complex.
230.62s - 233.14s |  It has com objects, scripting engines,
233.14s - 235.26s |  cloud synchronization, and more.
235.26s - 236.98s |  The more components there are,
236.98s - 239.54s |  the higher the chances to find an issue.
239.54s - 241.86s |  And the most promising feature about Office
241.86s - 244.06s |  is the backwards compatibility.
244.06s - 246.54s |  It was released over 30 years ago,
246.54s - 249.62s |  and legacy code is usually the problematic one,
249.62s - 251.06s |  which is good for us.
252.14s - 254.46s |  Now let's talk about the research itself.
255.94s - 259.38s |  We wanted to find RPC servers related to Office,
259.38s - 262.62s |  and that led us to the service ClickToRunSVC.
263.70s - 267.18s |  Here you can see the RPC interfaces it exposes.
267.22s - 270.54s |  And narrowing down this list to files related to Office
270.54s - 272.38s |  results in three files.
272.38s - 275.46s |  The actual executable of the service,
275.46s - 277.42s |  OfficeClickToRun.exe,
277.42s - 279.74s |  and let's skip the long prefix
279.74s - 282.86s |  and just call them virtualization.dll
282.86s - 287.59s |  and subsystemcontroller.dll.
287.59s - 289.47s |  We started looking into these files
289.47s - 291.71s |  to see what functionality they provide,
291.71s - 294.87s |  and we found an interesting string in the virtualization.dll.
295.87s - 299.15s |  Could not inject subsystem.dll to child process.
299.15s - 302.51s |  And lucky us, this string is used by a function
302.51s - 304.83s |  that is exposed through RPC.
304.83s - 307.43s |  This means that you can easily invoke it.
307.43s - 310.31s |  Still, before we start reverse engineering
310.31s - 313.23s |  the RPC interface and its methods,
313.23s - 317.11s |  we wanted to make sure it actually performs DLL injection.
317.11s - 318.79s |  So we debugged it,
318.79s - 321.91s |  put breakpoints on API used for code injection,
321.91s - 323.71s |  and then we launched Word.
323.71s - 327.15s |  That caused the service to call write-process-memory.
327.15s - 330.99s |  This diagram shows the call stack that led to this API.
330.99s - 334.19s |  The RPC call went through several undocumented functions
334.19s - 339.43s |  in a few DLL files until it reached write-process-memory.
339.43s - 341.79s |  So what is this DLL?
341.79s - 344.35s |  The file description is Microsoft Application
344.35s - 348.03s |  Virtualization Client Virtualization Manager Component.
348.03s - 350.79s |  And yes, it says virtualization twice.
351.79s - 355.43s |  This file exposes two undocumented RPC methods.
355.43s - 357.87s |  Instead of diving headfirst into the code,
357.87s - 359.27s |  we wanted to find symbols
359.27s - 362.03s |  that can shed some light on these functions.
362.03s - 364.63s |  We used PowerShell to find RPC clients,
364.63s - 369.63s |  and that led us to a file that has symbols, subsystem64.dll.
370.15s - 372.43s |  Again, I'm going to skip the long names.
372.43s - 375.59s |  The functions in the client are called notifyNewProcess
375.59s - 377.67s |  and notifyNewChildProcess.
377.67s - 380.43s |  We didn't find anything interesting about the first one.
381.11s - 382.67s |  The second function causes the server
382.67s - 386.97s |  to call write-process-memory.
386.97s - 388.69s |  Now we want to understand the flow
388.69s - 390.65s |  that leads to the DLL injection.
390.65s - 393.25s |  So we'll start by debugging the client.
393.25s - 395.85s |  We notice that before Word performs the call,
395.85s - 400.85s |  it spawns ai.exe as a child process in a suspended state.
400.93s - 402.81s |  Then we reach the call itself.
402.81s - 406.05s |  We reverse-engineered it and came with its definition.
406.05s - 408.49s |  This syntax is for the IDL file.
408.49s - 410.37s |  It sends two parameters.
410.41s - 415.41s |  The process ID of ai.exe and the string subsystem64.dll,
415.81s - 417.89s |  the name of the DLL that made the call.
419.41s - 422.21s |  Time to switch sides to the RPC server.
422.21s - 426.09s |  Like I said before, those DLL files are undocumented,
426.09s - 428.93s |  and we want to save time on reverse-engineering them.
428.93s - 431.13s |  We searched for all the files that are related
431.13s - 433.21s |  to the app virtualization platform
433.21s - 435.65s |  and found out that there are files with similar names
435.65s - 437.81s |  in the system32 directory.
437.81s - 439.89s |  Those files have symbols,
439.89s - 443.09s |  and they show that the DTools library is being used.
443.09s - 446.73s |  This is an official library by Microsoft used for hooking,
446.73s - 449.97s |  and it can also inject code into another process.
449.97s - 453.21s |  The functions DToolUpdateProcessWithDLL
453.21s - 455.85s |  and DToolCopyPayloadToProcess are used
455.85s - 458.65s |  to patch the import address table of the target process
458.65s - 460.65s |  and force it to load a DLL.
460.65s - 462.73s |  Comparing the two files with bindif
462.73s - 464.85s |  further proves the similarities.
464.85s - 467.93s |  The name primary column belongs to the office file,
467.93s - 471.77s |  and the name secondary column belongs to the system32 file.
471.77s - 473.93s |  Those functions are a perfect match.
475.73s - 478.25s |  We can easily understand how the injection is done
478.25s - 480.05s |  with the source code of DTools.
480.05s - 482.21s |  The optional header is modified to point
482.21s - 484.17s |  to a new copy of the import table
484.17s - 486.53s |  that includes an additional import descriptor
486.53s - 488.29s |  to the injected DLL.
488.29s - 490.89s |  This is how WinDebug displays the headers.
490.89s - 494.45s |  We can see the full path to the DLL, which is unusual.
494.45s - 498.16s |  Compilers link the base name.
498.16s - 500.88s |  This is everything done by the RPC server.
500.88s - 502.48s |  Now let's go back to the client
502.48s - 504.80s |  and finish going through this process.
504.80s - 506.96s |  Word resumes ai.txt,
506.96s - 509.56s |  and since the process is not yet initialized,
509.56s - 511.84s |  the loader uses the new import table.
511.84s - 516.48s |  Because of that, subsystem64 is loaded into the process.
516.48s - 520.20s |  We looked at what happens if we imitate the RPC call
520.20s - 523.40s |  but specify a 32-bit process as the target.
523.40s - 525.24s |  In this case, Office Click-to-Run
525.24s - 528.40s |  isn't writing to the memory of this process directly.
528.40s - 530.96s |  It launches the tool mavinject32,
530.96s - 533.24s |  which is known as a living off-the-land binary,
533.24s - 537.40s |  but the injection is exactly the same.
537.40s - 539.36s |  Now we want to understand exactly,
539.36s - 542.36s |  now that we know exactly how the DLL is injected,
542.36s - 544.16s |  what can we gain from it?
544.16s - 547.76s |  Security products detect all kinds of malicious behavior,
547.76s - 551.72s |  file encryption, shellcode execution, and code injection.
551.72s - 554.52s |  But sometimes legitimate programs do that.
554.52s - 556.16s |  We just saw an example.
556.16s - 559.72s |  And to avoid generating false positive events for customers,
559.72s - 563.00s |  such programs will be excluded by the products.
563.00s - 565.36s |  This means that if we force Office Click-to-Run
565.36s - 568.48s |  to inject the DLL, we'll be able to bypass detection.
569.56s - 572.04s |  We know the definition of the RPC method,
572.04s - 576.00s |  and we can imitate it to inject subsystem64.dll.
576.00s - 580.36s |  But the big question is, can we inject another DLL?
580.36s - 583.32s |  As I showed before, the function receives a string,
583.32s - 586.28s |  so we can just change the name of the file.
586.28s - 588.32s |  But that means we'll have to write our DLL
588.32s - 591.36s |  to the office directory, which is very suspicious,
591.36s - 593.68s |  and it also requires admin privileges.
595.40s - 597.80s |  We tried providing a full path to the file
597.80s - 601.40s |  instead of the base name, and this is what happened.
601.40s - 604.64s |  We changed the string to ctemp-injected.dll,
604.64s - 608.00s |  and it was appended as it is to the office directory.
608.00s - 611.20s |  This should raise a flag for every security researcher.
611.20s - 614.60s |  It means that there are no sanity checks on the inputs.
614.60s - 619.30s |  So we can go back to the 90s and use directory traversal.
619.30s - 620.92s |  We can manipulate the file lookup
620.92s - 623.36s |  to a completely different place.
623.36s - 625.50s |  Let's display the headers of the process again
625.50s - 629.34s |  with WinDebug, this time after we manipulated the call.
629.34s - 631.32s |  We can see our malicious string was appended
631.32s - 633.20s |  to the office directory and written
633.20s - 634.84s |  to the memory of the process.
636.36s - 639.78s |  With this trick, we can inject any DLL we want.
639.78s - 642.14s |  But there are still a few limitations.
642.14s - 644.62s |  The modified import address table will be used
644.62s - 647.06s |  only if the process was launched as suspended
647.06s - 649.58s |  and wasn't resumed until the injection was done.
649.58s - 651.82s |  It must be uninitialized.
651.82s - 653.72s |  Right now, we have a new technique
653.72s - 656.94s |  to force a legitimate program to inject a DLL for us,
656.94s - 659.82s |  but what more can we achieve from this?
659.82s - 662.34s |  A nice thing about RPC is that the client
662.34s - 665.06s |  can have lower privileges than the server.
665.06s - 668.22s |  The office service runs this anti-authority system,
668.22s - 679.15s |  so can we perform privilege escalation?
679.15s - 681.63s |  Well, the short answer is no.
681.63s - 684.23s |  The server calls RPC impersonate client
684.23s - 686.15s |  before the injection is done.
686.15s - 688.67s |  This means that the thread that handles our request
688.67s - 691.75s |  will use our token, and not the token
691.75s - 693.15s |  of anti-authority system.
694.15s - 695.99s |  This is done to verify that the client
695.99s - 699.15s |  has enough permissions to access the remote process.
699.15s - 701.75s |  After the impersonation, the request reaches
701.75s - 705.31s |  a subsystem controller.dll, which calls open process
705.31s - 707.47s |  to gain a handle to the remote process.
707.47s - 710.99s |  If we can't get this handle, so will the RPC server,
710.99s - 712.63s |  and the call will fail.
712.63s - 715.83s |  But still, maybe we can escalate from admin to system.
717.35s - 721.11s |  The first step to do that will be to launch a process
721.11s - 724.45s |  with the privileges of system in a suspended state.
724.45s - 727.17s |  We used API monitoring to find such calls,
727.17s - 729.27s |  and we found that the task scheduler service
729.27s - 731.23s |  does exactly that.
731.23s - 733.23s |  Scheduled tasks are a great target
733.23s - 735.15s |  because there are many default ones
735.99s - 737.39s |  that are configured to run a system,
737.39s - 739.91s |  and even some that are related to Office,
741.39s - 744.79s |  such as this one, Office Automatic Updates 2.0.
744.79s - 746.99s |  Our injection will be even less suspicious
746.99s - 749.89s |  if the service will inject a DLL to another process
749.89s - 751.71s |  that is related to Office,
751.71s - 754.11s |  but we still have a few challenges ahead.
754.11s - 756.59s |  The task scheduler service resumes the process
756.59s - 758.41s |  shortly after it is launched.
758.41s - 760.79s |  We need to find a way to hold the execution
760.79s - 762.71s |  of the task scheduler service,
762.71s - 767.93s |  and we can do that with an opportunistic lock.
767.93s - 770.97s |  Opportunistic locks, or OP locks for short,
770.97s - 772.41s |  are a special kind of locks
772.41s - 774.37s |  that are used to keep data coherency
774.37s - 777.09s |  across computers accessing a file server.
777.09s - 778.81s |  A client can lock a file,
778.81s - 781.81s |  and when another client tries to access the same file,
781.81s - 783.17s |  it will wait.
783.17s - 784.89s |  The server will break the lock
784.89s - 786.93s |  and notify the first client.
786.93s - 788.71s |  The new data will be flushed,
788.71s - 790.07s |  the file will be closed,
790.07s - 791.93s |  and only then the second client
791.93s - 793.89s |  will be able to access it.
793.89s - 795.45s |  The nice thing about OP locks
795.45s - 796.85s |  is that they can be requested
796.85s - 799.81s |  from the local file system by a process.
799.81s - 802.13s |  This usage is effectively a semaphore
802.13s - 803.97s |  managed by the local file system
803.97s - 805.93s |  that synchronizes multiple processes.
807.57s - 810.21s |  So how does it relate to our attack?
810.21s - 811.57s |  If we could find a file
811.57s - 814.37s |  that is accessed by the task scheduler service
814.37s - 815.97s |  after the process is created,
815.97s - 817.65s |  but before it is resumed,
817.65s - 818.69s |  we could lock it,
818.69s - 822.23s |  and it will stop the service from resuming the process.
822.23s - 823.57s |  Keeping the process suspended
824.25s - 826.37s |  will allow us to inject a DLL to it.
826.37s - 829.33s |  We monitor the system for file access
829.33s - 832.81s |  while launching the scheduled tasks,
832.81s - 835.97s |  and we saw that sysmain.sdb was accessed.
835.97s - 838.25s |  In this image, we can see the call stack.
838.25s - 840.01s |  Inside createProcessInternal,
840.01s - 842.95s |  functions related to the app compatibility were called,
842.95s - 847.10s |  and then the shim database was opened.
847.10s - 849.28s |  At this point, we know that the task scheduler
849.28s - 851.76s |  sometimes reads sysmain.sdb,
851.76s - 854.90s |  but we need to understand which tasks lead to that.
855.70s - 857.62s |  We need to find a task that executes a file
857.62s - 859.78s |  with app compatibility settings.
859.78s - 862.74s |  To do that, we locked the sdb file,
862.74s - 865.62s |  launched every task registered on the machine,
865.62s - 869.06s |  and checked when we were notified about the lock breaking.
869.06s - 873.36s |  This led us to a task that executes Microsoft Edge updates.
873.36s - 875.46s |  This file has app compatibility settings
875.46s - 877.26s |  because of the following entry.
878.10s - 880.26s |  The generic installer fix will be applied
880.26s - 883.54s |  on every process that has the word update in it.
883.54s - 884.68s |  So this is good,
885.46s - 886.58s |  but still, it's not good enough.
886.58s - 889.60s |  This file is under Program Files x86,
889.60s - 892.12s |  which means it is a 32-bit process.
892.12s - 894.70s |  We want to find a target for 64-bit as well.
896.40s - 898.28s |  We continued digging into this subject
898.28s - 900.88s |  to understand under which circumstances
900.88s - 902.72s |  the sdb file will be read,
902.72s - 904.40s |  and we noticed a strange behavior
904.40s - 906.48s |  that applies to the OS as a whole,
906.48s - 909.12s |  not just the task scheduler service.
909.12s - 912.24s |  The sdb file was read the first time an executable ran
912.24s - 913.76s |  since the machine started,
913.76s - 915.80s |  even if it didn't need a fix.
915.80s - 918.70s |  And after that, in all other runs, it wasn't.
920.16s - 922.52s |  If we could guarantee that the sdb file
922.52s - 925.20s |  will be read any time an executable runs,
925.20s - 928.40s |  we could choose any scheduled task as our targets.
928.40s - 931.76s |  And of course, we could register a custom sdb file
931.76s - 934.44s |  that applies some fix to every process,
934.44s - 936.22s |  but that is too noisy.
936.22s - 937.40s |  We want to avoid actions
937.40s - 940.08s |  that are monitored by security products.
940.08s - 941.08s |  We need to find a way
941.12s - 944.00s |  to manage the app compatibility mechanism.
944.00s - 946.20s |  We looked for files related to this mechanism
946.20s - 948.88s |  and found apphelp.dll.
948.88s - 950.64s |  By looking at the code of this DLL,
950.64s - 953.24s |  we understood that it wraps various operations
953.24s - 956.90s |  with the API anti-apphelp-cache-control.
956.90s - 960.70s |  Let's try to understand how to use it.
960.70s - 964.72s |  This is an undocumented API that is exported by anti-DLL.
964.72s - 967.40s |  We searched for references to this API online
967.40s - 969.52s |  and in several DLL files
969.52s - 972.28s |  until we found that the symbols of combase.dll
973.08s - 974.60s |  contain information about it.
974.60s - 977.16s |  This is a screenshot of a function from combase
977.16s - 979.52s |  without any reverse engineering.
979.52s - 982.20s |  We can see that the first parameter is an integer
982.20s - 985.00s |  that represents the type of operation to be performed,
985.00s - 987.06s |  and the second parameter is a structure
987.06s - 988.76s |  with various members that are filled
988.76s - 992.97s |  based on the operation chosen.
992.97s - 995.57s |  We extracted those definitions
995.57s - 997.21s |  and that revealed to us everything
997.21s - 999.17s |  that can be done with this API.
999.17s - 1002.85s |  We applied the definitions on calls from other DLL files
1002.85s - 1005.17s |  and that helped us understand them better.
1005.17s - 1008.01s |  Let's look at create-process, for example.
1008.01s - 1010.61s |  Now we know that it performs the lookup operation
1010.61s - 1013.49s |  and what information it requires.
1013.49s - 1016.61s |  Like I said before, we encountered a strange behavior.
1016.61s - 1019.97s |  The SDB file was read the first time in an executable run
1019.97s - 1023.13s |  since the machine started, even if it didn't need a fix,
1023.13s - 1024.89s |  and then it wasn't.
1024.89s - 1027.13s |  At this point, we had enough information
1027.13s - 1030.01s |  to come up with an assumption on why it happens.
1031.01s - 1034.85s |  In this scenario, CMD is going to launch calc,
1034.85s - 1036.69s |  so we have these two processes,
1036.69s - 1040.71s |  and also the app-help cache, which is empty at this point.
1040.71s - 1042.73s |  We know that when we call create-process,
1042.73s - 1045.25s |  the lookup operation is done on the cache,
1045.25s - 1048.81s |  so CMD is going to look for an entry about calc.
1048.81s - 1052.73s |  The cache is empty, so the response is no entry found.
1052.73s - 1055.45s |  That causes CMD to read the SDB file
1055.45s - 1057.41s |  to check if it contained information
1057.41s - 1059.81s |  about fixes calc requires.
1060.61s - 1061.89s |  It doesn't require any fix.
1061.89s - 1064.37s |  So the next step is that the cache is updated
1064.37s - 1066.13s |  and an entry is added.
1066.13s - 1068.57s |  Calc, no fix needed.
1068.57s - 1072.09s |  Then, let's say CMD launches calc again,
1072.09s - 1075.71s |  so it queries that cache one more time.
1075.71s - 1079.01s |  This time, the response is no fix needed,
1079.01s - 1083.19s |  and that is why CMD doesn't read sysmin.sdb again.
1083.19s - 1084.89s |  Based on this assumption,
1084.89s - 1087.17s |  if we could remove this entry from the cache,
1087.17s - 1091.10s |  the SDB file will be read again.
1091.10s - 1094.18s |  We looked at various calls to empty app-help cache control
1094.18s - 1097.50s |  and found out that both kernel32 and app-help
1097.50s - 1099.70s |  performs the remove operation.
1099.70s - 1102.76s |  In this pseudocode, we can see the information required.
1102.76s - 1105.66s |  It requires the path and the handle to the file.
1105.66s - 1107.62s |  Kernel32 exports a function
1107.62s - 1109.54s |  that does most of the work for us,
1109.54s - 1110.72s |  and it saves us the effort
1110.72s - 1112.68s |  of recreating this call in our code.
1113.74s - 1115.94s |  After this call, the execution of the file
1115.94s - 1118.88s |  will once again trigger reading the SDB file.
1120.70s - 1123.50s |  Okay, so we talked about a lot of stuff.
1123.50s - 1126.90s |  RPC methods, locks, and undocumented API.
1126.90s - 1130.24s |  So in case you lost track, let's put everything together.
1130.24s - 1132.22s |  This is the flow of the attack.
1132.22s - 1135.30s |  We'll start by writing the DLL that will be injected.
1135.30s - 1137.14s |  Then, we'll pick a schedule task.
1137.14s - 1140.42s |  Let's say Office Automatic Updates 2.0.
1140.42s - 1142.38s |  We need to take care of the shim cache.
1142.38s - 1145.36s |  The file that will be executed might have an entry,
1145.36s - 1147.24s |  so we're going to remove it.
1148.14s - 1152.43s |  Then, we'll lock sysmain.sdb.
1152.43s - 1154.89s |  The next step will be to start the task,
1154.89s - 1157.03s |  and that will launch a suspended process
1157.03s - 1159.19s |  with the privileges of system.
1159.19s - 1162.67s |  The task scheduler will try to read the SDB file
1162.67s - 1164.59s |  and start waiting.
1164.59s - 1167.63s |  That will send us a notification about the lock breaking,
1167.63s - 1170.15s |  which means it's time to send the RPC request
1170.15s - 1172.31s |  to the Office service.
1172.31s - 1174.55s |  The service will patch the import table
1174.55s - 1178.55s |  of the suspended process and link it to our DLL.
1178.55s - 1181.07s |  The last step will be to release the lock,
1181.07s - 1182.79s |  and that will cause the task scheduler
1182.79s - 1188.21s |  to resume the process, and our DLL will be loaded.
1188.21s - 1195.06s |  Ready to see if it works?
1195.06s - 1198.02s |  First, we'll copy our tool to the machine.
1198.02s - 1201.49s |  And let's even scan it.
1201.49s - 1203.49s |  And of course, Defender won't detect it.
1204.55s - 1206.29s |  Now, just to make it clear,
1206.29s - 1212.07s |  we are running the latest version of Office 365,
1212.07s - 1216.67s |  and also the latest Windows 11 build.
1216.67s - 1218.27s |  Now that we made it clear,
1218.27s - 1224.39s |  let's start monitoring the system and launch our tool.
1224.39s - 1228.51s |  We can see that Office C to our client loaded our DLL,
1228.51s - 1231.95s |  and that we gained a console with the privileges of
1231.95s - 1239.93s |  anti-authority system.
1239.93s - 1241.41s |  Time to summarize.
1241.41s - 1243.75s |  We decided to make an attack surface research
1243.75s - 1245.27s |  on Microsoft Office.
1245.27s - 1247.83s |  We manipulated several components of the OS
1247.83s - 1250.07s |  into a single functioning attack.
1250.11s - 1253.43s |  And these are the advantages of it.
1253.43s - 1256.47s |  Security products will most likely ignore code injection
1256.47s - 1260.45s |  done by Office Click to Run, because this is its purpose.
1260.45s - 1262.39s |  So we'll bypass detection.
1262.39s - 1265.97s |  It will be difficult to link this attack back to us,
1265.97s - 1269.31s |  because not only the injection is done by another process,
1269.31s - 1272.35s |  but the target process is spawned under the task scheduler,
1272.35s - 1274.43s |  not under us.
1274.43s - 1277.65s |  We escalate our privileges from admin to system,
1277.65s - 1279.87s |  and the rest of the actions we perform
1280.55s - 1281.39s |  aren't suspicious.
1281.39s - 1284.07s |  It is very unlikely that someone monitor calls
1284.07s - 1288.13s |  to anti-app-help-cache-control or monitors using Oprox.
1289.15s - 1291.49s |  So this is the end of my part of the talk.
1291.49s - 1301.05s |  Now please welcome David Chandalov.
1301.05s - 1302.49s |  Thank you, Ron.
1302.49s - 1305.49s |  As we concluded our first attack surface research,
1305.49s - 1308.21s |  we identified a significant knowledge gap
1308.21s - 1311.25s |  regarding anti-app-help-cache-control.
1311.25s - 1314.61s |  Despite extensive information available online,
1314.61s - 1317.77s |  we found that crucial details about some data structures
1317.77s - 1319.71s |  and flows remain unclear.
1320.61s - 1324.05s |  Additionally, with the continuous updates and changes
1324.05s - 1326.77s |  in Windows versions over the years,
1326.77s - 1328.65s |  many publicly shared insights
1328.65s - 1330.97s |  have been altered by Microsoft.
1330.97s - 1334.49s |  Today, I'll provide a comprehensive overview
1334.49s - 1337.07s |  of the mechanism and the modernized attack.
1337.07s - 1338.81s |  So let's dive right in.
1340.61s - 1342.91s |  As we embarked on our research journey,
1342.91s - 1345.51s |  we were driven by a fundamental question.
1345.51s - 1349.77s |  What can we achieve with the anti-app-help-cache-control API?
1349.77s - 1352.03s |  This inquiry became our guiding light,
1352.03s - 1356.39s |  sparking our curiosity and determination to delve deeper.
1356.39s - 1359.01s |  Our initial exploration gave us a foothold,
1359.01s - 1360.91s |  but we knew we needed more.
1360.91s - 1364.67s |  We needed to understand the technical intricacies.
1364.67s - 1368.09s |  After all, this API controls shim fixes.
1368.09s - 1370.05s |  Maybe we can bend it to our will
1370.05s - 1372.31s |  and control which shim fixes are applied
1372.71s - 1376.04s |  to specific processes.
1376.04s - 1378.52s |  Our second question was more technical.
1378.52s - 1380.80s |  As you can see from the screenshots,
1380.80s - 1383.44s |  during the reading of sysmain.sdb,
1383.44s - 1386.24s |  we noticed that anti-app-help-cache-control
1386.24s - 1388.28s |  interacts with the kernel.
1388.28s - 1392.44s |  This API calls a driver named ahcache.sys,
1392.44s - 1396.40s |  which contains some intriguingly named functions.
1396.40s - 1399.12s |  Functions like api-lookup and write-to-process
1399.12s - 1401.16s |  and cache-lookup stood out,
1401.16s - 1403.78s |  suggesting deeper mechanisms at play.
1404.76s - 1407.48s |  These findings hinted at something significant
1407.48s - 1409.60s |  inside of ahcache.sys,
1409.60s - 1411.88s |  something that required us to dig deeper.
1412.78s - 1417.12s |  So, down the rabbit hole we go.
1417.12s - 1419.44s |  All right, let's lay the foundation.
1419.44s - 1422.64s |  To understand how ahcache.sys operates,
1422.64s - 1424.36s |  we need to start with the basics
1424.36s - 1426.76s |  of its initialization process.
1426.76s - 1430.42s |  When the system boots up, ahcache.sys is loaded,
1430.42s - 1434.58s |  and it requires some initial setup to function properly.
1434.58s - 1436.90s |  This is where the registry comes into play.
1438.26s - 1440.58s |  The registry provides essential values
1440.58s - 1444.34s |  that ahcache.sys reads and stores data to.
1444.34s - 1446.70s |  These values act as a safe location
1446.70s - 1448.56s |  for the driver's operations.
1450.18s - 1452.50s |  This path contains binary data
1452.50s - 1455.90s |  that the driver sorts into an AVL table.
1455.90s - 1458.22s |  The cache needs to be properly initialized
1458.22s - 1460.02s |  through the Windows API
1460.02s - 1464.70s |  before these components can start working.
1464.70s - 1468.18s |  The opposite process happens a shutdown and restart.
1468.18s - 1470.82s |  The AVL table is dumped into the registry
1470.82s - 1475.32s |  into the AppCompatCache value.
1475.32s - 1477.16s |  Let's take a moment to understand
1477.16s - 1481.40s |  the link between sysmain.sdb, registry entries,
1481.40s - 1483.92s |  and the AppCompatibility cache.
1483.92s - 1486.56s |  Each entry in the registry's values data
1486.56s - 1489.96s |  is representing either a file that needs a shimfix
1489.96s - 1491.88s |  or a file that doesn't.
1491.88s - 1493.76s |  We'll revisit the decision-making process
1493.76s - 1496.20s |  for applying fixes, but for now,
1496.20s - 1500.08s |  let's focus on entries indicating files that need a fix.
1500.08s - 1503.36s |  These entries contain several fields,
1503.36s - 1506.08s |  the most significant being the exit tag,
1506.08s - 1508.76s |  which points to a specific shimfix.
1508.76s - 1511.24s |  By examining the data within these entries,
1511.24s - 1514.20s |  we can observe notable differences.
1514.20s - 1517.72s |  Specifically, three bytes vary across entries,
1517.72s - 1521.12s |  and in the last entry, the three bytes are zeroized.
1521.12s - 1524.44s |  Is it a sign for a file not needing a fix?
1524.44s - 1527.20s |  Considering the data's little-endian format,
1527.20s - 1533.03s |  converting it could reveal connections to sysmain.sdb.
1533.03s - 1536.91s |  With SDB Explorer, we can search for these converted values
1536.91s - 1539.99s |  in a readable version of sysmain.sdb.
1539.99s - 1542.71s |  Zooming in on the fields that appear in the SDB,
1542.71s - 1544.83s |  we have the name of the file field,
1544.83s - 1547.39s |  and we can see the matching file field.
1547.39s - 1550.35s |  The matching file field contains just an asterisk,
1550.35s - 1554.63s |  so the whole name field will be compared as it appears.
1554.63s - 1557.63s |  And lastly, we find the shimreference field.
1557.63s - 1560.95s |  Each shimreference has a name and an ID.
1560.95s - 1564.43s |  Some have a command line for additional arguments.
1564.43s - 1567.51s |  Each field has a hexadecimal number attached.
1567.51s - 1570.38s |  Why?
1570.38s - 1572.98s |  It represents the address in the SDB
1572.98s - 1574.94s |  that contains the exit tag
1574.94s - 1580.16s |  as it prefixes the shimfix information block.
1580.16s - 1582.80s |  Now that we understand what an exit tag is
1582.80s - 1586.48s |  and how the registry cache and sysmain.sdb are linked,
1586.48s - 1590.36s |  we wanted to look under the hood of ahcache.sys.
1590.36s - 1592.64s |  We started looking at the dispatch routines
1592.64s - 1594.84s |  for device ahcache,
1594.84s - 1597.36s |  and we found that, among other things,
1597.36s - 1600.40s |  anti-app-help-cache-control can
1600.40s - 1603.20s |  update the table with hc-api-update
1603.20s - 1606.92s |  that utilizes insert-element-api,
1606.92s - 1610.52s |  lookup a table entry with hc-api-lookup-cdb
1610.52s - 1612.60s |  that uses lookup-element-api,
1614.16s - 1616.52s |  or it can remove an entry from the table
1616.52s - 1620.20s |  with hc-api-remove using delete-element-api.
1621.24s - 1626.78s |  We decided to continue looking for the dispatch routines.
1626.78s - 1628.62s |  As we already have shown,
1628.62s - 1632.98s |  anti-app-help-cache-control uses the ahc-service class enum,
1632.98s - 1636.26s |  but it is also being used in the dispatch routine
1636.26s - 1638.82s |  inside of ahcache.sys.
1638.82s - 1642.42s |  The enum has an interestingly sounding member
1642.42s - 1644.46s |  in its process data for short.
1644.46s - 1647.02s |  We traced a function that is using this value.
1648.42s - 1650.42s |  We were surprised to see no mentions
1650.42s - 1652.24s |  of AVL table manipulation.
1653.98s - 1656.04s |  Maybe this is what we were looking for,
1656.04s - 1658.26s |  writing to a process for a kernel driver?
1658.26s - 1659.30s |  Sounds awesome.
1660.94s - 1663.30s |  But before we check if we got the good news,
1663.30s - 1665.74s |  let's go through some definitions.
1665.74s - 1667.38s |  Almost every dispatch routine
1667.38s - 1669.62s |  has a unique structure for its operation.
1671.38s - 1675.02s |  This structure contains an undocumented data field.
1675.02s - 1677.36s |  We tried to search the web for definitions,
1677.36s - 1680.52s |  and with some more in-house reverse engineering,
1682.22s - 1683.98s |  we got shim data.
1683.98s - 1687.74s |  It contains a fixed magic value and a fixed size value.
1687.74s - 1692.86s |  Remember this struct as we will come to visit it later.
1692.86s - 1695.28s |  Dive in deeper inside the function.
1695.28s - 1697.68s |  The calling process and the target process
1697.68s - 1698.74s |  are being checked.
1700.40s - 1701.88s |  Now here is the tricky part.
1701.88s - 1705.24s |  We need to have protected signer app and PPL.
1706.62s - 1709.24s |  And these two values will be important later.
1710.50s - 1714.56s |  But the call fails in psget process protection.
1714.56s - 1717.80s |  Looking at every process in Windows 11,
1717.80s - 1720.10s |  we concluded that no Windows apps
1720.10s - 1723.52s |  with this kind of protection exist.
1723.52s - 1724.92s |  We came to a dead end.
1725.52s - 1729.12s |  But the undocumented structure I talked about before,
1729.12s - 1730.68s |  it piqued our interest.
1732.48s - 1735.04s |  We decided to take that strange name we found
1735.04s - 1738.56s |  and try to look for references of this structure.
1738.56s - 1741.72s |  Maybe we can understand by which operation it is being used
1741.72s - 1745.28s |  and who can be the target.
1745.28s - 1747.18s |  There were a few hits.
1747.18s - 1749.12s |  Reverse engineering the functions
1749.12s - 1751.76s |  that reference shim data revealed
1751.76s - 1754.44s |  that this structure represents the shim fixes
1754.44s - 1756.52s |  that need to be applied to a process.
1758.34s - 1760.44s |  Let's see how a new process is born.
1761.88s - 1764.44s |  Notepad.exe is the child process
1764.44s - 1768.98s |  that is created on behalf of the parent process cmd.exe.
1768.98s - 1770.92s |  The parent queries the app help cache
1770.92s - 1774.68s |  to check if the child process requires shim fixes
1774.68s - 1776.82s |  as we have shown in the first attack.
1778.00s - 1780.80s |  The parent process readsysmain.sdb
1780.80s - 1783.88s |  to retrieve the complete information about the fixes.
1785.93s - 1787.73s |  The parent builds the structure
1787.73s - 1790.41s |  according to the specific fixes
1790.41s - 1796.12s |  and writes it to the memory of the child process.
1796.12s - 1797.76s |  The parent modifies the value
1797.76s - 1800.80s |  of the process environment blocks pshim data
1800.80s - 1805.47s |  to point to the new structure.
1805.47s - 1808.57s |  NTDLL is already loaded in the child process.
1810.23s - 1813.63s |  So NTDLL's loader loads app help.dll
1813.63s - 1816.47s |  if pshim data is not empty.
1817.47s - 1821.63s |  App help identifies which shim fixes are to be applied.
1823.11s - 1826.23s |  And so app help.dll applies the shim fixes
1826.23s - 1830.19s |  according to the structure.
1830.19s - 1832.47s |  We also wanted to share the flow
1832.47s - 1836.99s |  of the shim data structure creation for future references.
1836.99s - 1841.45s |  The flow starts with create process internal in kernel base,
1841.45s - 1843.05s |  goes through kernel 32,
1843.05s - 1847.25s |  and finally ends with app help.dll.
1847.25s - 1849.25s |  The finished struct is built
1849.25s - 1852.53s |  in the sdb pack up compa data function
1852.53s - 1856.05s |  inside of app help.dll.
1857.49s - 1861.29s |  Okay, let's consider the implications
1861.29s - 1863.65s |  of manipulating a system component
1863.65s - 1867.13s |  to build and trigger unauthorized fixes.
1867.13s - 1870.85s |  This could potentially allow us to inject or alter code
1870.85s - 1874.13s |  in a way that bypasses typical security measures.
1875.13s - 1878.45s |  Our investigation into pshim data
1878.45s - 1881.01s |  begins with understanding what data
1881.01s - 1883.37s |  is being written to this specific part
1883.37s - 1887.70s |  of the process environment block.
1887.70s - 1890.70s |  We utilized the compatibility administrator
1890.70s - 1895.61s |  to create and apply custom rules.
1895.61s - 1900.55s |  By extracting the shim data directly from process memory,
1900.55s - 1904.07s |  we gained a first insight into how the data is organized.
1904.79s - 1909.79s |  We chose to fuzz the inputs to see the effect on the data.
1909.79s - 1912.39s |  This process helped us identify patterns
1912.39s - 1915.15s |  in the data handling.
1915.15s - 1916.63s |  By following these steps,
1916.63s - 1918.75s |  we gained a comprehensive understanding
1918.75s - 1922.84s |  of how shim data looks like.
1922.84s - 1924.60s |  And so at last,
1924.60s - 1927.82s |  we have reversed engineered the shim data structure,
1927.82s - 1929.34s |  essential for understanding
1929.34s - 1932.06s |  how to manipulate shims to our advantage.
1933.06s - 1936.44s |  Here we can see the previous version of the shim data.
1936.44s - 1937.86s |  If you can recall,
1937.86s - 1940.60s |  this is the struct I ask you to remember.
1940.60s - 1942.38s |  There are quite a few changes.
1942.38s - 1945.20s |  Most notably, the exit up type field,
1945.20s - 1946.52s |  the exit tag field,
1946.52s - 1948.54s |  and the exit count field.
1948.54s - 1954.95s |  All are essential for correct use of shim fix manipulation.
1954.95s - 1955.99s |  At this stage,
1955.99s - 1958.67s |  we are preparing to use all of our accumulated knowledge
1958.67s - 1960.05s |  for an attack.
1960.05s - 1962.67s |  We can make a target process load the shim fix
1962.67s - 1965.45s |  simply by building our own shim data struct
1965.45s - 1968.67s |  and pointing to the target pshim data to it.
1968.67s - 1970.77s |  The process won't check any condition
1970.77s - 1972.89s |  the original rule has configured.
1972.89s - 1976.37s |  This allows us to apply any fix we want.
1976.37s - 1978.93s |  We chose to inject the DLL,
1978.93s - 1983.93s |  to inject the DLL into the target process by itself.
1987.28s - 1988.20s |  Okay.
1988.20s - 1990.58s |  We chose to inject the DLL
1990.58s - 1993.28s |  into the target process by itself.
1993.30s - 1996.68s |  This effectively makes the attack a file-less
1996.68s - 1998.78s |  and registry-less DLL injection
1998.78s - 2000.28s |  that can evade detection.
2002.02s - 2003.66s |  According to this entry,
2003.66s - 2006.34s |  rtvideo.dll will be injected
2006.34s - 2009.70s |  if the process name starts with glj,
2009.70s - 2011.66s |  ends with the temp extension,
2011.66s - 2013.78s |  and it has the correct checksum.
2013.78s - 2017.38s |  Luckily, these checks are done by the parent process
2017.38s - 2019.72s |  and not by the child process.
2019.72s - 2022.78s |  This means that once the exit tag in shim data
2022.78s - 2024.16s |  points to this entry,
2024.16s - 2027.68s |  the child process's app.ldll will apply the fix
2027.68s - 2029.78s |  without checking the conditions.
2031.48s - 2032.76s |  Having said all that,
2032.76s - 2035.20s |  our tech has three limitations.
2035.20s - 2038.86s |  The target process must be started as a suspended process.
2040.36s - 2043.16s |  If the injected process executable file
2043.16s - 2045.28s |  resides in this specific path
2045.28s - 2048.68s |  or the security identifier of the file's owner
2048.68s - 2050.42s |  is trusted installer,
2050.42s - 2052.42s |  the shim fix won't be loaded.
2053.68s - 2057.80s |  Injected DLL is not available to 64-bit processes
2057.80s - 2059.92s |  as acgeneral.dll revealed.
2061.08s - 2062.40s |  And you won't believe it,
2062.40s - 2063.92s |  we found the target.
2063.92s - 2066.96s |  And it's the Microsoft Edge updater we have shown before.
2068.40s - 2070.72s |  Microsoft has made our lives easier
2070.72s - 2073.24s |  as all three limitations are not present.
2073.24s - 2074.28s |  Let's inject.
2075.84s - 2077.00s |  At this point,
2077.00s - 2078.52s |  we have enough knowledge
2078.52s - 2080.88s |  to abuse the app compatibility mechanism.
2080.88s - 2083.28s |  So let's go over all of the steps.
2084.46s - 2086.58s |  We need to write our own DLL
2086.58s - 2088.64s |  as the name of the rule specifies.
2090.14s - 2093.34s |  We launch our binary as a suspended process.
2094.46s - 2097.78s |  The struct is built with the correct tag
2097.78s - 2101.08s |  as in our example.
2101.08s - 2103.86s |  We write the struct to the target process's memory.
2104.72s - 2107.12s |  We point to the struct.
2108.16s - 2110.68s |  We resume the execution.
2110.70s - 2112.76s |  And so app help will help us
2112.76s - 2114.82s |  and apply our desired fix.
2114.82s - 2117.98s |  And RTVideo will load to the target process.
2117.98s - 2123.98s |  Let's see how it looks in action.
2123.98s - 2129.27s |  shim injector.exe is dropped.
2129.27s - 2131.71s |  And so we can see the hello message
2131.71s - 2134.55s |  from inside of the child process.
2134.55s - 2137.87s |  RTVideo.dll is loaded by our target.
2137.87s - 2141.19s |  We can see our call stack going from install after init
2141.19s - 2143.19s |  to NSInject.dll.
2143.19s - 2145.75s |  And lastly, to load library.
2146.57s - 2148.37s |  We also have some logs on the command prompt.
2148.37s - 2151.03s |  You can see the unique size, magic,
2151.03s - 2161.89s |  exit type, and exit tag we defined earlier.
2161.89s - 2163.83s |  Let's recap our second attack.
2163.83s - 2166.13s |  There is a long history of shim attacks
2166.13s - 2168.89s |  and how security products typically detect
2168.89s - 2172.49s |  and mitigate malicious shim attacks, attack vectors.
2174.01s - 2176.55s |  We were able to uncover new definitions
2176.55s - 2179.51s |  and insights on the app compatibility component.
2179.51s - 2181.81s |  And we used them to change what we think
2181.81s - 2183.47s |  about this attack vector.
2184.99s - 2186.75s |  This new perspective allowed us
2186.75s - 2189.91s |  to create a new file-less and registry-less attack.
2191.53s - 2193.55s |  We essentially took care of the problem
2193.55s - 2196.19s |  of creating a custom SDB on a system
2196.19s - 2198.01s |  with all that comes with it,
2198.01s - 2203.24s |  namely registry and disk tracks.
2203.24s - 2206.64s |  By writing to a child process, which is not suspicious,
2206.64s - 2208.32s |  and by loading the target DLL
2208.32s - 2210.36s |  from the suspended child process
2210.36s - 2213.76s |  before any EDR hook can be established,
2213.76s - 2219.21s |  we effectively bypassed EDR detection.
2219.21s - 2221.47s |  We chose this specific shim fix
2221.47s - 2224.51s |  because it is applicable to many scenarios
2224.51s - 2226.91s |  and demonstrates our attack in a clear way.
2227.95s - 2229.75s |  There are many more shim fixes
2229.75s - 2231.95s |  that can be used for malicious purposes.
2231.95s - 2233.75s |  This was only one of them.
2235.43s - 2236.75s |  We've come a long way.
2236.75s - 2238.31s |  Let's summarize both attacks
2238.31s - 2243.04s |  and see what we can take away from this research.
2243.04s - 2245.28s |  As for detections, let's go over
2245.28s - 2247.88s |  how should someone detect these kinds of attacks.
2248.88s - 2251.00s |  For the first attack,
2251.00s - 2254.44s |  RPC is a big and early part of the first attack,
2254.44s - 2257.56s |  so monitoring remote procedure calls
2257.56s - 2259.28s |  made to click-to-run service
2259.28s - 2262.48s |  can reveal the use of non-standard DLL paths.
2263.32s - 2265.96s |  Requests for opportunistic locks
2265.96s - 2272.26s |  on critical system files like sysmain.sdb should be flagged.
2272.26s - 2274.40s |  Implementing security policies
2275.38s - 2278.36s |  that restrict such high-level memory write operations
2278.36s - 2280.36s |  as it is very suspicious,
2280.36s - 2282.60s |  click-to-run service shouldn't write
2282.60s - 2286.94s |  to this type of processes on its own.
2286.94s - 2288.52s |  Regarding the second attack,
2289.70s - 2292.20s |  keeping an eye on file system activity,
2292.20s - 2295.30s |  particularly for the creation of DLL files
2295.30s - 2298.22s |  which are listed in sysmain.sdb
2298.22s - 2302.30s |  and are in directories unrelated to the original files,
2302.30s - 2306.16s |  to the original rules.
2306.16s - 2309.36s |  Also, we invite the community to take our findings
2309.36s - 2312.94s |  to refine our attacks and make new and better ones.
2314.24s - 2315.68s |  Some ideas.
2315.68s - 2317.36s |  The community could find a target
2317.36s - 2322.00s |  for the init process data operation that we didn't find.
2323.64s - 2325.60s |  There is much more to understand
2325.60s - 2327.38s |  about the shim data structure
2327.38s - 2329.72s |  and how it can affect the execution
2329.72s - 2333.92s |  of the ahcache.sys functions.
2333.92s - 2335.12s |  There are many more flows
2335.12s - 2338.04s |  that can potentially manipulate the AVL table,
2338.04s - 2340.48s |  which in turn will affect which process
2340.48s - 2345.94s |  will get what shim fix.
2345.94s - 2350.76s |  In conclusion, in our presentation,
2350.76s - 2353.00s |  we detailed our comprehensive methodology
2353.00s - 2355.40s |  for conducting attack surface research.
2357.12s - 2360.52s |  By leveraging and manipulating various system components,
2360.52s - 2363.16s |  including services, op locks,
2363.16s - 2365.20s |  and compatibility mechanisms,
2365.20s - 2368.08s |  we demonstrated how to consolidate these elements
2368.08s - 2372.85s |  into a singular, cohesive attack strategy.
2372.85s - 2375.73s |  The op lock and the compatibility mechanisms
2375.73s - 2379.57s |  could be integral parts of other multi-component,
2379.57s - 2382.73s |  sophisticated, and complex attacks.
2382.73s - 2386.57s |  Op lock can be used in many scenarios as a building block,
2386.57s - 2388.17s |  and there are many more shim fixes
2388.17s - 2390.53s |  that can be used with malicious intent,
2390.53s - 2395.76s |  even with 64-bit processes.
2395.76s - 2398.40s |  Our extensive research uncovered new techniques
2398.44s - 2402.20s |  for stealthy injection and privileged escalation,
2402.20s - 2407.37s |  enhancing the effectiveness of these attacks.
2407.37s - 2411.85s |  We demonstrated two attacks that won't be monitored by EDRs.
2411.85s - 2414.97s |  The injection occurs in a very early stage,
2414.97s - 2421.18s |  a stage where EDRs can't establish a hook yet.
2421.18s - 2424.26s |  Through reverse engineering and undocumented API
2424.26s - 2426.38s |  and its associated structures,
2426.38s - 2429.02s |  we gained valuable insights that contributed
2429.02s - 2431.10s |  to the development of these methods.
2432.90s - 2434.70s |  Additionally, we modernized
2434.70s - 2437.10s |  a previously known malicious technique,
2437.10s - 2439.62s |  transforming it into a more elusive,
2439.62s - 2441.66s |  file-less, and registry-less attack.
2442.86s - 2445.74s |  Lastly, we once again encourage the community
2445.74s - 2448.14s |  to continue building on our research,
2448.14s - 2450.18s |  exploring the leads we have provided
2450.18s - 2454.19s |  to further advance this field.
2454.19s - 2455.03s |  Thank you.
2455.99s - 2459.35s |  Thank you so much for being here and hearing our talk.
2459.35s - 2462.11s |  The source code of our tools is now public.
2462.11s - 2464.23s |  If you have any questions, you are free to ask.
2464.23s - 2466.83s |  You can also find us on Twitter and LinkedIn.
2466.83s - 2467.67s |  Thanks again.


url: https://www.youtube.com/watch?v=1Hx-PzyGtX0
title: DEF CON 32 - Process Injection Attacks w ROP - Bramwell Brizendine, Shiva Shashank Kusuma
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=1Hx-PzyGtX0",
  "title": "DEF CON 32 - Process Injection Attacks w ROP - Bramwell Brizendine, Shiva Shashank Kusuma",
  "description": "This talk showcases techniques for process injection using advanced return-oriented programming (ROP). Process injection via ROP introduces significant hurdles, requiring many WinAPIs to be chained together, each with complex parameters and return values. We give practical details on how to best manage this. One seemingly insurmountable challenge is in identifying the target binary, as string comparison can be extremely difficult in ROP, as needed ROP gadgets may be lacking. We unveil a unique, universal solution, giving a reliable means of string comparison via ROP, which works all the time, allowing a specific process to be pinpointed and injected into via ROP.\n\nWe created numerous patterns for different WinAPIs, allowing for as many as a dozen ways of preparing a specific WinAPI via ROP, if using an approach centered around the PUSHAD instruction. With some WinAPIs, there are zero patterns for PUSHAD, forcing us to rely upon the much lauded \u201csniper\u201d approach. We document all such variations of patterns for the WinAPIs in our demonstrated process injection. This research is not intended to demo a one-off example of process injection via ROP, but to provide a methodology that can be used time and time again, providing unique templates for others to use the same WinAPIs when attempting process injection via ROP.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1367,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

1.52s - 6.52s | This text was transcribed using whisper model: large-v2

 Welcome, welcome, welcome to DEF CON. My name is Dr. Bramal Brizendine. I am the director of
8.86s - 14.34s |  the Verona Lab, which deals with vulnerability research. Creator of the Shell Wasp, which
14.34s - 19.88s |  allows us to utilize Windows syscalls in shellcode. I've created the Jop Rocket and Rop
19.88s - 24.32s |  Rocket, both of which deal with return oriented programming and jump oriented programming.
24.32s - 28.72s |  And I've also created an NSA funded research project called Sherem, which allows us to
28.72s - 34.96s |  analyze, uh, shellcode. Uh, I've spoken at many different conferences in the past, um, and
34.96s - 39.96s |  I'm also an assistant professor of cyber security. I have a PhD in cyber operations, which
42.40s - 48.58s |  is a highly technical degree. And all of those, uh, previous projects have, um, previously
48.58s - 53.58s |  been presented at DEF CON, so check them out. My co-speaker is, uh, Shiver Shashank Kusama.
53.58s - 58.58s |  He is a research assistant and, uh, he has a master's in computer science and is pursuing a
61.58s - 66.12s |  master's in cyber security. Uh, he's looking for internship opportunities for the summer as
66.12s - 71.12s |  well. So, our agenda. What are we going to focus on? Well, firstly, we'll talk briefly about a
73.96s - 79.76s |  general approach to shellcodeless ROP. How do we create unique patterns to facilitate
79.76s - 85.68s |  process injection? Some generic ROP techniques for process injection. And then we will look
85.68s - 90.70s |  at a sample process injection technique that has a, uh, highly novel solution to a rather
93.40s - 100.40s |  significant problem. We'll have a demo and then we'll have another brief, uh, uh, process
100.40s - 106.34s |  injection and then we'll, we will conclude. So, some, uh, preliminary words on our
106.36s - 112.16s |  experiment. Now this, when we, we conducted this research, we did it on a contrived binary, uh,
112.16s - 116.90s |  one of those intentionally vulnerable and is filled with convenient gadgets because we want
116.90s - 122.18s |  our work to be applicable not just to one particular vulnerable binary, but to
122.18s - 126.48s |  potentially, uh, any binary. So, we want to discover everything that is possible. And this
126.48s - 133.32s |  research is really focused on, uh, ROP from the standpoint of you compromise a binary. It's
133.36s - 137.70s |  not something where we're trying to integrate ROP and some kind of custom malware or some
137.70s - 144.14s |  kind of custom red team software. So, let's introduce the idea of shellcodeless ROP. What
144.14s - 149.04s |  does it mean exactly? Well, it's this idea of instead of a bypassing data execution
149.04s - 154.86s |  prevention DEP, we are instead going to invoke the, uh, functionality of a shellcode
154.86s - 159.86s |  directly via ROP gadgets. And it's something that has very seldom been done in the Windows
160.24s - 165.24s |  ecosystem. And when you see it, it's almost always two, three APIs chained together. But
169.88s - 176.18s |  you'll see, uh, later today that we have, uh, vastly, uh, more APIs to achieve what we want to
176.18s - 181.26s |  do. Some also, uh, some previous work on shellcodeless job. There's a video link in the
181.26s - 187.52s |  slides, so I do encourage you to, uh, check it out if you're interested. So, in terms of
187.52s - 191.42s |  approaching shellcodeless job there, or shellcodeless ROP, there are a couple approaches we
191.42s - 198.20s |  could take. One is utilizing push add, where we're going to populate values on, uh, certain
198.20s - 204.44s |  registers, uh, with certain predefined values. Um, and then that causes them to be loaded
204.44s - 209.18s |  onto the stack in a, a certain predefined order. And we'll also use move dereference or the
209.18s - 214.08s |  sniper technique. And this allows us to precisely write our values to the stack and we can
214.08s - 220.98s |  then increment or decrement to the next, uh, slot that we want to provide values for. So,
220.98s - 226.66s |  those are both critically, uh, important for us. And I want to reemphasize the importance of
226.66s - 230.50s |  this idea of finding patterns. Because again, we're not really just approaching one process
230.50s - 235.04s |  injection technique, but we want our work to be applicable broadly to many different
235.04s - 240.74s |  techniques. How do we do this in terms of return oriented programming? So, we really want to
240.74s - 245.58s |  emphasize that, you know, we have these particular slots, uh, where we have, uh, registers
245.58s - 251.28s |  going in a certain order. Uh, so we really, uh, weaponize this in terms of developing new
251.28s - 257.66s |  patterns for different APIs, uh, both Windows APIs as well as native APIs to allow us to invoke
257.66s - 265.16s |  those easily using return oriented programming. So, and when using many different APIs, we
265.18s - 270.46s |  want to be able to chain them together. Lar- kind of like in the sense where you have a, uh, a
270.46s - 273.56s |  ROP chain, you have different, uh, ROP gadgets chained together. We'll be chaining different
273.56s - 279.86s |  APIs together. So, you may get one, uh, return value. Uh, in this case, uh, open process
279.86s - 286.14s |  runtime address is provided to us in EAX. We can use that subsequently in a pattern for open
286.14s - 291.14s |  process because of course we need to call open process. So, a large part of our research is
291.36s - 297.56s |  really focused on generating a lot of these different types of patterns and actually we've
297.56s - 302.58s |  developed more than 150 unique patterns to provide a lot of opportunities. Um, we'll talk
305.58s - 309.72s |  more in depth about some of them and we'll give some examples, but historically, uh, some of
309.72s - 315.12s |  the tools that have done this have been things like, uh, Mona, Mona, you know, Virtual Alloc,
315.12s - 320.20s |  Virtual Protect, and you have a couple patterns. So, it's not a significant number of patterns.
320.22s - 326.10s |  So, let's talk now briefly about some generic ROP techniques that we can use to help us with,
326.10s - 331.10s |  uh, process injection. So, one is the idea of using function output, using that function
333.50s - 339.90s |  output as a way to, um, to be a parameter. So, get product address and a little library
339.90s - 345.74s |  often go hand in hand and they're very familiar and well known. Uh, so with a little library,
345.76s - 351.96s |  we can get a handle to a module, uh, which is the, the base address of a certain DLL and that's
351.96s - 357.60s |  required for get product address. So, we take the output from the one, which is going to be
357.60s - 364.44s |  returned to us in EAX and then we use that subsequently in, uh, get product address. And
364.44s - 368.94s |  we'll do this time and time again. So, return values as well as other out parameters if
368.94s - 374.32s |  you're dealing with native APIs. And then this gets a little bit more complex. So,
374.36s - 379.64s |  structures is parameters. Can we do that with return oriented programming? And we actually
379.64s - 384.50s |  can. So, with a structure, we need to look clearly at the, the definition of the structure and
384.50s - 388.38s |  then we need to build that byte by byte through return oriented programming. And we'll
388.38s - 392.44s |  typically do that with a series of move dereferences and we can just increment and
392.44s - 398.52s |  decrement to the, to the next slot as we slowly build our, uh, our structure. And in some
398.52s - 403.00s |  cases, we may actually have nested structures. So, take a look at adjust hook and privileges.
403.00s - 408.98s |  We have several nested structures and it needs to be done exactly correctly or else it
408.98s - 413.98s |  simply will just not work. Um, one thing that is also, uh, immensely important is this idea
417.42s - 422.42s |  of storing important values, um, addresses, handles, things which may be obtained by
425.96s - 430.40s |  calling a Windows API. If we call a Windows API to obtain one of these values, well that
430.44s - 434.60s |  takes a lot of effort. And if we needed it again, well of course we don't want to call it a
434.60s - 441.04s |  second time. So, we will make an effort to save that value somewhere in memory and then we
441.04s - 445.82s |  can retrieve it later. So, we might have a common reference point. We move ESP to a
445.82s - 450.28s |  location, maybe we advance forward 500 bytes and we just start writing different values
450.28s - 455.26s |  there. And that common, uh, reference point can, will change from gadget to gadget but we
455.26s - 460.26s |  can manually calculate that and make adjustments, uh, as need be. So, again you'll have
460.26s - 465.46s |  lots of important values and you can save them and then retrieve them subsequently, uh,
465.46s - 470.66s |  later on. So, one other thing we did is, and this is actually, uh, completely novel,
470.66s - 476.10s |  combining move dereference and push add in terms of building a pattern. So, we can use that
476.10s - 482.74s |  to create a, a, a ROP chain pattern. Uh, push add you can have a maximum of 4 parameters, 5
482.74s - 488.86s |  if you use ESP but that can be rather, uh, challenging to do. Um, so we can do push add and
488.88s - 494.52s |  then do the remainder. We can supply those via move dereference. Now, if you have the option
494.52s - 499.50s |  to, uh, place your strings and data in the payload directly, then by all means do it.
499.50s - 504.06s |  Because it's going to save you effort. Again, if you have a common reference point, you can
504.06s - 507.90s |  use these. You have a pointer to a string. And you, some of you might be saying, well, what
507.90s - 513.24s |  about EDR? Well, yes, EDR will be an issue at times and so this may not always be plausible.
513.24s - 518.24s |  If you have no payload size restrictions, one option is to obfuscate some of this and then
518.26s - 524.94s |  you could use a ROP to go and de-obfuscate it as need be. So, let's get into an actual, uh,
524.94s - 529.00s |  process injection technique. Now, this is based on something that I actually did at Hack in the
529.00s - 535.44s |  Box Amsterdam 2023. That was all Windows syscalls and shellcode. This obviously is not. It's
535.44s - 539.64s |  return oriented programming. And so these are more, uh, these are Windows APIs and native
539.64s - 544.66s |  APIs. It's not necessarily strikingly original. Um, but in any case, we have a new URL. We're
544.88s - 551.48s |  going to create that. It's going to slither up inside of our victim target and external
551.48s - 556.92s |  process and then we're going to write our shellcode there and then cause it to launch. So, in
556.92s - 562.72s |  terms of ROP, the actual complete chain of gadgets that we have, 29 gadgets. It's an
562.72s - 569.36s |  extraordinary amount. Uh, I'm not familiar with any, uh, ROP chain in the Windows ecosystem
569.36s - 574.60s |  that has anywhere near this level of gadgets. And so it's a lot of work to, to maintain
574.60s - 580.18s |  these from, um, from API, API call to API call. And it would be a lot more, actually, if we
580.18s - 586.42s |  did not use that technique of storing and retrieving certain values that we need. So, let's
586.42s - 591.18s |  talk about load library. We can use that with, uh, push add and a pattern. So, we load the
591.18s - 596.96s |  particular values into, uh, registers and then we go and do push add. Then that causes it to
596.96s - 603.24s |  go in a predefined, uh, location. And so, let's see what happens exactly. So, we, we have our
603.24s - 607.80s |  stack values there and those correspond to our pattern. So, we have red 8. That means we're
607.80s - 612.48s |  going to do this ROP NOP. We're going to skip 8 bytes. So, we skip that. We do a jump EVP
612.48s - 616.94s |  dereference. We, therefore, invoke load library. We have a return address. We have a
616.94s - 623.26s |  parameter. Everything checks out. And then we get a result. Exact result that we want. So,
623.26s - 629.86s |  we get the base address of NTDLL. And then we can use that subsequently for git proc
629.86s - 633.60s |  address, which, which is our next one. And we'll do the same thing. We'll populate different
633.60s - 639.00s |  values into the registers that we can then call push add. And we get the runtime address. In
639.00s - 645.32s |  this case, we're doing create tool help 32 snapshot. An extremely important thing that we'll
645.32s - 649.62s |  talk about momentarily. So, these are the patterns for load library. We have a lot of them,
649.62s - 655.32s |  9. And git proc address, we have 11. So, that gives us a lot of flexibilities because if you're
655.32s - 660.22s |  trying to do something, you don't have a particular gadget while you just give up. If you do,
660.22s - 665.90s |  then the chain is incomplete. But having multiple patterns, we can drill down deeper and
665.90s - 671.26s |  maybe find something that actually works. In any case, our next API is create tool help 32
671.26s - 675.60s |  snapshot, which will allow us to take a snapshot of all the active processes that are out
675.62s - 681.12s |  there. And it's immensely important. We need it to discover, uh, the different PIDs. We're
681.12s - 687.10s |  going to target one of those. So, there are actually 11 patterns. So, a lot of flexibility
687.10s - 692.30s |  there in terms of how you can invoke it with the push add instruction. Um, there's an example
692.30s - 697.08s |  of the ROP and we got the push add at the bottom. Virtual alloc, um, it's one way to allocate
697.08s - 701.32s |  memory. Yes, some EDR can block it. There are other ways you could do it. Uh, the pattern for
701.34s - 705.78s |  that is very, uh, familiar. Uh, one of, one of the most familiar goes back probably about 15
705.78s - 710.94s |  years. Um, but with this, we're going to allocate a region of memory. We're going to use that
710.94s - 717.52s |  for a couple very, uh, important, uh, things. One of which is to build the process entry 32.
717.52s - 723.22s |  The process entry 32 is where we're going to go in and check our PID and we're going to check
723.22s - 729.15s |  our, uh, string. So, the first thing is going to be process 32 first. It's going to kick
729.17s - 736.13s |  everything off. It's going to initiate the whole, uh, process. So, how are we going to do
736.13s - 739.61s |  that? Uh, first we actually need to build the structure. So, we can go ahead and build the
739.61s - 744.05s |  structure via ROP and our move dereferences. Most of it are null bytes, so it's relatively
744.05s - 749.55s |  simple. We have a DW size. Uh, it's an arbitrary value, so you can make it whatever you want.
749.55s - 754.25s |  And then once we're done, we get a pointer to that. We supply that pointer as the parameter.
754.29s - 759.93s |  So, all of that work and we just get a pointer to that. So, again, the idea of being able to, uh,
759.93s - 763.67s |  dynamically locate something in memory and use that as kind of like a pointer can be very
763.67s - 769.37s |  useful. And then the patterns for process 32 first and process 32 next are actually
769.37s - 774.75s |  interchangeable. So, one of the biggest challenges is this idea of string comparison. How do
774.75s - 780.51s |  we do that with ROP? Well, the gadgets are not really very common, so that can be very, uh,
780.55s - 786.19s |  problematic. We need to identify a specific process, otherwise you really can't proceed
786.19s - 791.55s |  forward. So, you're kind of at a, an, uh, you can't really go forward without this. So, we
791.55s - 795.39s |  came up with a solution. We're going to build our own custom function in memory. It's an
795.39s - 800.63s |  enumerate process function. And we're actually writing the raw assembly. So, remember we
800.63s - 805.77s |  made a writable memory with virtual alloc. We can write our code there. You can do it other
805.77s - 809.91s |  ways as well. And so, this will cycle through process 32 next. It can do it hundreds of
809.91s - 816.79s |  times. It'll loop until it finds the exact, uh, string, VU player. We can supply that and
816.79s - 820.89s |  then once it does that, it'll go ahead and exit out. So, how do we write that? Well, we
820.89s - 825.79s |  simply just compile it. We can then write our bytes to memory using the move dereference
825.79s - 830.23s |  technique one by one until they're all written. Make sure the code is executable and there
830.23s - 833.67s |  are multiple ways in which you can do that. And then we need to supply the appropriate
833.67s - 839.13s |  values. So, things like our HP snapshot, our, our VU player string, uh, dereference
839.13s - 845.03s |  process 32 address. And then how do we kick it off? Uh, again, multiple ways, but in this
845.03s - 848.37s |  case, we're going to do a simple push ret, which will then push the address onto the stack
848.37s - 853.71s |  and then return to that. And then we can, uh, immediately start executing our custom code
853.71s - 860.25s |  that we just wrote there. And so, that'll invoke process 32, uh, repeatedly until it finds
860.25s - 867.13s |  our particular PID. In this case, we have VU player. It's going to look at offset 24 and
867.13s - 872.13s |  once it finds offset 24, then again, it's going to break out of that loop. And, um, from
872.13s - 877.03s |  there, the base of the structure, we can just go to simply offset 8. Offset 8 will then hold
877.03s - 882.05s |  the PID. We can capture that PID. In this case, it's 668. And how do we do that via return
884.45s - 888.89s |  oriented programming? Well, we just basically take exactly what I said, translate it to ROP.
888.89s - 895.29s |  So, some move dereferences, some POPs, uh, sequence of 8, uh, increments. And, uh, in this
895.29s - 901.39s |  case, we have a different PID, B98. And, uh, we can supply that. Uh, we can save that to
901.39s - 907.37s |  memory so we can use that later. Remember the idea of save and then retrieve. And then that
907.37s - 916.49s |  brings us to our next API. And with that, we're going to have Shiva, uh, take the podium.
916.49s - 921.43s |  Here we take this PID that we just obtained after all of that hard work and, uh, we are going
921.43s - 926.43s |  to convert that into the handle to the process. We got to have this. It's impossible to move
926.43s - 931.89s |  forward if you don't have a PID to your target process. And we don't want to just randomly
931.89s - 936.77s |  inject into some other unknown process. Uh, so this one we are going to use both push add as
936.77s - 941.77s |  well as move dereference technique. So, here we have multiple patterns for open process. And
943.43s - 948.61s |  then we'll follow that up after push add. And we also have a move dereference with the
948.61s - 953.61s |  process ID. In this ROP chain, the process ID has been provided by move dereference, uh, with
954.43s - 959.43s |  everything else being done via push add. Next, we'll open a handle to our current process with
962.61s - 968.75s |  open process token. And then we'll use that. So, right here we have a handle and we are using
968.75s - 976.12s |  ROP to create a pointer to hold the access token that we'll retrieve. With adjust token
976.12s - 981.06s |  privileges, uh, we are going to take that token handle and we can then change the privileges as
981.08s - 987.78s |  we need. We need to do this to avoid some problems that could happen otherwise. And this
987.78s - 993.40s |  requires multiple complex structures such as token privileges, such as, uh, where we can
993.40s - 1001.20s |  specify the AC privilege and AC debug privilege. With adjust token privileges, uh, here we
1001.20s - 1006.74s |  have a ROP. So, we are setting disable all privileges to false. And what that means is that
1006.74s - 1013.32s |  whatever we specify inside the new state structure will be then done. With adjust token
1013.36s - 1019.30s |  privileges, we can then go inspect via the debugger and see if it has all of our values. Like
1019.30s - 1024.64s |  AC privilege enabled and AC debug privilege. And then everything is going according to the
1024.64s - 1029.64s |  plan. Our goal with this is to take a common DLL URL mon, create a file for it, and then go
1032.14s - 1037.32s |  ahead and map that out. And then we can inject our payload into that, then causing that to be
1037.32s - 1042.32s |  executed. And we'll do this with these APIs which we'll be talking about. So, create file A is
1044.52s - 1049.86s |  the first. We get a handle to the URL mon, which is our file. We are going to be using this
1049.86s - 1056.54s |  later on, uh, but we are going to do this with sequence of moody references. And here we are
1056.54s - 1061.78s |  providing the absolute address, the string pointer to that, and also generic read. We are
1061.78s - 1066.78s |  doing generic read to avoid some possible detections. And then NT create section, a lower
1069.28s - 1074.28s |  level native API will allow us to then create a section object for URL mon DLL, and here we are
1075.92s - 1080.92s |  doing page read only. And then with drop we are specifying the sec image. NT map your
1083.80s - 1089.64s |  section. Now that we have the URL mon section handle, we can now map that view of the
1089.66s - 1095.10s |  section into address space of VU player. We'll do this purely through moody references,
1095.10s - 1102.00s |  because, uh, we have many nulls and also we have page read only, so it's a bit more limited.
1102.00s - 1106.78s |  One more important thing is providing the base address or pointer to the base address, and
1106.78s - 1113.28s |  that will receive a base address inside of VU player. So that will be provided to us, as you
1113.28s - 1120.77s |  can see in this example, which we'll be talking about later, so it is very important.
1120.79s - 1125.79s |  Virtual protect EX will then allow us to change the target DLL URL mon to RWX, and so we are
1127.97s - 1132.53s |  going to do this with sequence of moody references, because remember we have limited
1132.53s - 1138.47s |  permissions for it. And so we'll get the handle to the VU player as well as the base address
1138.47s - 1145.42s |  that we just retrieved, and then once it's done, we'll have the page execute read write. Here
1145.42s - 1149.66s |  is a route where we can provide the pointer to the base address. We then go and dereference
1149.74s - 1155.64s |  that and we'll pull the base address out of that, and then we do the moody reference. Write
1155.64s - 1161.42s |  process memory allows us to inject the shellcode into the process memory of VU player. We are
1161.42s - 1166.82s |  doing this via push add as well as moody references, which you can see right here, so
1166.82s - 1173.56s |  pointing to the shellcode up there, and also providing the size. Same thing here, we are, we
1173.56s - 1178.56s |  have the shellcode and the size and then the remaining parameters with push add. Write
1178.56s - 1183.40s |  process memory at this point, once this is done, then our shellcode will be injected into
1183.40s - 1188.60s |  inside of URL mon, which is an external process. So we have gone from one process to a
1188.60s - 1194.88s |  completely different process, and the shellcode is just sitting there waiting for us. So how
1194.88s - 1199.02s |  do we cause it to execute? The answer is very simple, it's create remote thread, but the
1199.02s - 1203.76s |  actual technique is not so simple. So we'll have a moody reference and also push add
1203.76s - 1209.86s |  pattern, and then we'll have a sequence of moody references. We'll go inside the other
1209.86s - 1218.04s |  space of VU player, and then we do the push add. So here is some of our ROP, we can
1218.04s - 1222.64s |  provide the LP parameter as well as the address, and then we follow that up after push
1222.64s - 1228.48s |  add, and finally with create remote thread, our injected shellcode will execute. We have
1228.48s - 1236.52s |  achieved our goal. Let's do a demo. We start the things with create help 32 snapshot and
1236.52s - 1241.78s |  we have been given a handle. Let's write the enum process function to memory byte by
1241.78s - 1248.42s |  byte. We invoke the function using push thread. Now we are inside the function, special
1248.42s - 1254.56s |  function that we created, and let's take the process entry. Let's see what we have as the
1254.56s - 1261.58s |  first entry. We have system. Let's move forward until we find our desired PID, and we
1261.64s - 1268.34s |  finally found the PID for VU player. That's good. We'll keep moving forward, and we'll do
1268.34s - 1274.78s |  the create file A. We'll get a handle from create file A. Let's verify what we have. We
1274.78s - 1279.62s |  have the URL mount, that's good. Let's map that out using empty map section, and let's
1279.62s - 1283.52s |  check the base address. Right now we don't have any base address, but right after the
1283.52s - 1291.65s |  function execution, we'll get the base address, and base address has been provided. We'll
1291.67s - 1297.11s |  change the permissions for the base address, and we'll see, we have, we have the base
1297.11s - 1304.99s |  execute read write permissions. We have the MZ, it's a PE file, and let's inject the shellcode
1304.99s - 1311.89s |  using write process memory. And let's see what we have. We have successfully injected the
1311.89s - 1316.89s |  shellcode into external process. And finally, create remote thread. We got it.
1325.73s - 1332.80s |  Thank you Shiva. So we're going to wrap things up very briefly here. So, I just want to say,
1333.02s - 1337.48s |  our, you know, our goal is not to enumerate all process injection techniques. We've seen
1337.48s - 1341.86s |  talks like that before, but we really want to provide a methodology in terms of how we can do
1341.86s - 1346.16s |  that with ROP, and focus on the practicalities. We want to provide a novel concept of
1346.16s - 1352.20s |  building a enumerate processes function purely via ROP, which can be extendable to other
1352.20s - 1356.68s |  process injection techniques, and then create a rich set of patterns that we can utilize
1356.68s - 1360.98s |  for that purpose. With that, we'd like to thank you, and invite you to check out the ROP
1360.98s - 1361.58s |  Rocket tool.


url: https://www.youtube.com/watch?v=-KXgcWuv-Ug
title: DEF CON 32 - Secrets & Shadows: Leveraging Big Data for Vulnerability Discovery - Bill Demirkapi
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=-KXgcWuv-Ug",
  "title": "DEF CON 32 - Secrets & Shadows: Leveraging Big Data for Vulnerability Discovery - Bill Demirkapi",
  "description": "When we consider the conventional approaches to vulnerability discovery, be it in software or websites, we tend to confine ourselves to a specific target or platform. In the case of software, we might reverse engineer an application's attack surfaces for untrusted input, aiming to trigger edge cases. For websites, we might enumerate a domain for related assets and seek out unpatched, less defended, or occasionally abandoned resources.\n\nThis presentation explores the untapped potential of scaling security research by leveraging unconventional data sources. We'll walk through design flaws that enable two examples: forgotten cloud assets and leaked secrets. Instead of starting with a target and finding vulnerabilities, we'll find vulnerabilities and relate them to our targets. We won't just stop at discovery. We'll also discuss the incentives that create them and how to solve the ecosystem issues as an industry.\n\nWhile you can't easily scale every issue, this project has led to tens of thousands of highly significant yet seemingly trivial weaknesses in some of the world's largest organizations. Prepare to shift your perspective on vulnerability discovery, learn scalable approaches to address commonly overlooked bugs, and understand how even the simplest misconfiguration can have a devastating impact.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2544,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 You're killing me, dude.
6.46s - 7.30s |  All right, everyone.
7.30s - 9.86s |  Thank you so much for coming out to this talk.
9.86s - 11.54s |  It's called Secrets and Shadows,
11.54s - 15.36s |  Leveraging Big Data for Vulnerability Discovery at Scale.
15.36s - 17.52s |  I'm so excited to be here for another year
17.52s - 19.02s |  at another DEF CON,
19.02s - 22.38s |  and I really do have something in store for you today.
22.38s - 26.91s |  Let's get right into it.
26.91s - 29.21s |  So just a disclaimer,
29.21s - 30.83s |  everything we're gonna talk about today
30.83s - 33.59s |  was done completely independent of my employer,
33.59s - 38.27s |  outside of work, with my own money, my own resources.
38.27s - 39.97s |  If you wanna talk about this work
39.97s - 41.87s |  outside of this presentation,
41.87s - 42.83s |  just please refer to me
42.83s - 44.91s |  as an independent security researcher.
44.91s - 51.44s |  It helps me be able to do work just like this.
51.44s - 53.70s |  So my name is Bill Demerkappa,
53.70s - 57.60s |  and I am a security researcher with a diverse background
57.60s - 61.36s |  in low-level software security and also cloud security.
62.38s - 63.82s |  Could we boost the mic a bit?
64.82s - 67.94s |  I'm interested in defense and offense.
67.94s - 70.82s |  I love solving hard security problems,
70.82s - 74.54s |  and while I did start with a software security background,
74.54s - 76.26s |  I feel like the impact we can have
76.26s - 79.48s |  with cloud security is much wider.
79.48s - 80.74s |  For example, you could have
80.74s - 83.50s |  the most complex software vulnerability in the world,
83.50s - 84.96s |  but at the end of the day,
84.96s - 89.40s |  a simple ID check or missing ID check in a cloud environment
89.40s - 92.10s |  can lead to a much broader impact.
92.14s - 94.74s |  And that's what really got me interested in the cloud.
94.74s - 97.22s |  It's the ability to have an impact
97.22s - 100.18s |  without the same technical complexity
100.18s - 105.79s |  that comes with exploiting low-level vulnerabilities.
105.79s - 106.91s |  So in this talk,
106.91s - 111.47s |  we're gonna discuss vulnerability discovery at scale.
111.47s - 113.87s |  And what I mean by that is we're gonna take a look
113.87s - 117.19s |  at how we traditionally approach vulnerability discovery
117.19s - 119.51s |  with two common bug classes,
119.51s - 123.55s |  dangling cloud resources and leaked secrets.
123.55s - 125.79s |  The goal is to identify the limitations
125.79s - 128.03s |  of our historical approach
128.03s - 135.42s |  and shift our perspective through some practical examples.
135.42s - 138.86s |  So some background.
138.86s - 140.10s |  Now, from a high level,
140.10s - 142.46s |  everyone knows what cloud computing is.
142.46s - 145.94s |  It's basically a way where you can create infrastructure
145.94s - 148.06s |  like servers, websites, and more
148.06s - 150.38s |  without needing to actually purchase
150.38s - 152.18s |  your own physical server rack.
153.42s - 156.38s |  The cool part is this can save you a lot of money.
156.38s - 158.10s |  If you're just creating your own blog,
158.62s - 161.50s |  you really don't need that many resources at all.
161.50s - 163.58s |  Why not borrow someone else's?
163.58s - 165.66s |  And that's really the fundamental principle
165.66s - 167.62s |  of cloud computing.
167.62s - 170.62s |  All you're doing is borrowing from someone else's pool
170.62s - 177.19s |  of shared resources.
177.19s - 179.95s |  So cloud environments are managed over the internet,
179.95s - 183.15s |  but how do we actually secure this access?
183.15s - 185.55s |  Well, for AWS, the way it works
185.55s - 188.83s |  is that you can use something called an access key.
188.83s - 192.59s |  An access key can be short-lived or long-term token
192.59s - 194.95s |  that specifies credentials for your account
194.95s - 198.03s |  and allows you to manage your AWS resources
198.03s - 200.79s |  depending on the role and permissions assigned to you.
202.39s - 204.95s |  Can we please increase the microphone sound?
205.95s - 209.03s |  And for other platforms, it's similar.
209.03s - 211.11s |  For example, for Google Cloud,
211.11s - 214.67s |  the types of authentication include service accounts,
214.67s - 216.79s |  you can use CLI credentials,
216.79s - 220.83s |  and in general, tokens are how we're able to operate
220.83s - 222.83s |  with these cloud environments.
223.79s - 229.68s |  Unfortunately, tokens also present a pretty severe risk.
229.68s - 232.00s |  So cloud provider tokens are dangerous
232.00s - 236.04s |  because by default, there's little restriction
236.04s - 238.56s |  on who can use those tokens.
238.56s - 240.44s |  For example, by default,
240.44s - 243.52s |  if you create a root access key in AWS,
243.52s - 246.44s |  anyone from any IP can use that access key
246.44s - 249.04s |  to manage your cloud environment.
249.04s - 252.32s |  Now, obviously, the impact of a leaked cloud credential
252.32s - 254.84s |  will really depend on the context.
254.84s - 256.52s |  For example, a lot of websites
256.52s - 259.28s |  hard-code a Google Maps API key,
259.28s - 261.28s |  and in reality, despite the fact
261.28s - 264.80s |  that it can lead to billing overcharges and abuse,
264.80s - 266.72s |  the impact is still fairly limited.
267.64s - 269.88s |  But with a root AWS key,
269.88s - 273.08s |  the dangers are much more problematic.
273.08s - 276.72s |  For example, if you stored your database in AWS
276.72s - 279.56s |  or you store your computing in AWS,
279.56s - 281.84s |  an attacker could use your credentials
281.84s - 284.72s |  to not only access customer data,
284.72s - 289.81s |  but to interfere with your production workflows.
289.81s - 292.29s |  Now, when we talk about how everything in the cloud
292.29s - 294.01s |  is shared and borrowed,
294.01s - 297.81s |  what I mean by that is by nature, by its nature,
297.81s - 302.21s |  the cloud model introduces risk from this sharing model.
302.21s - 304.97s |  So, for example, when you create a virtual machine,
304.97s - 307.61s |  what's really happening is you're borrowing time
307.61s - 311.29s |  on a physical server that your cloud provider has bought.
311.29s - 313.61s |  And on this physical resource,
313.61s - 317.17s |  you get assigned a network IP, for example.
317.17s - 318.61s |  And the reason this is dangerous
318.61s - 321.65s |  is because once you're done with a resource,
321.65s - 324.17s |  if you still have dangling DNS records
324.17s - 325.85s |  pointing at that resource,
325.85s - 328.73s |  suddenly that exposes an opportunity
328.73s - 331.57s |  for an attacker to take advantage of.
331.57s - 332.97s |  So, from a high level,
332.97s - 335.73s |  I view cloud resources in two categories,
335.73s - 338.73s |  primitive resources and shared resources.
338.73s - 341.45s |  So, a primitive resource is something like a virtual machine
341.45s - 344.65s |  where you get assigned a dedicated IP address.
344.65s - 348.65s |  That IP address is not used by any other customer but you.
348.65s - 350.45s |  Whereas with a shared resource,
350.45s - 353.45s |  what's really going on is it's a serverless application
353.45s - 355.85s |  that serves multiple customers.
355.85s - 358.73s |  For example, if you have a serverless function
358.73s - 360.85s |  that you can call on your cloud provider,
360.85s - 364.37s |  that URL you used to connect to that serverless function
364.37s - 366.17s |  probably corresponds to an IP
366.17s - 368.65s |  that serves a lot of other customers.
368.65s - 370.69s |  The reason this distinction is important
370.69s - 374.33s |  is because it impacts what type of dangling DNS records
374.33s - 375.89s |  you need to worry about.
375.89s - 377.21s |  So, for primitive resources
377.21s - 380.21s |  where you have that unique IP address,
380.21s - 382.69s |  that includes pretty much every type of DNS record
382.69s - 384.93s |  that could be dangling, like an A record,
384.93s - 387.93s |  a C name record, a name server, and et cetera.
387.93s - 390.05s |  But whereas if it's a shared resource
390.05s - 392.85s |  where the endpoint is shared across customers,
392.85s - 395.81s |  that's gonna be limited to C names, name server,
395.81s - 397.97s |  MX, those types of records.
397.97s - 399.69s |  And the distinction there is that
399.69s - 401.65s |  when the endpoint is shared,
401.65s - 404.29s |  suddenly you don't have to worry about the A record
404.29s - 407.49s |  pointing at a IP address you no longer control.
408.65s - 411.77s |  So, what can an attacker do with that domain control?
411.77s - 413.89s |  Well, from a high level, it can enable phishing,
413.89s - 416.41s |  malware distribution, scams, et cetera.
416.41s - 418.89s |  It can lead to cross-site scripting.
418.89s - 421.57s |  And there's going to be context-specific impact,
421.57s - 424.53s |  like you can bypass the trusted host names check
424.53s - 426.45s |  in a software update installer.
426.45s - 428.33s |  That's something I've seen pretty common.
428.33s - 432.17s |  You can abuse the brand trust and reputation
432.17s - 434.73s |  in order to spread misinformation.
434.73s - 437.89s |  Now, I included a quote below from APNIC
437.89s - 441.65s |  on an article talking about this potential abuse.
441.65s - 444.37s |  So, from a high level, they found that
444.37s - 446.93s |  when it came to dangling DNS record abuse,
447.89s - 451.73s |  in general, 75% of the hijacked dangling resources
451.73s - 456.53s |  were being used for black hat search engine optimization
456.53s - 458.29s |  and really promoting bad websites
458.29s - 463.88s |  you don't want anyone going to.
463.88s - 467.40s |  So, to be clear, past approaches
467.40s - 470.80s |  for these types of bugs already exist.
470.80s - 473.52s |  Where with dangling cloud resources,
473.52s - 476.40s |  we've seen that attackers can go ahead
476.40s - 478.48s |  and enumerate cloud IP pools
478.48s - 481.00s |  and capture these resources that are dangling.
481.00s - 484.00s |  But with leaked secrets, what we've seen is
484.00s - 487.80s |  that a lot of work really relies on a limited scope.
487.80s - 490.12s |  So, what I mean by that is,
490.12s - 492.76s |  everything that happens with leaked secrets
492.76s - 495.08s |  is always about a specific target,
495.08s - 498.56s |  like a specific folder, a specific repository,
498.56s - 500.12s |  or a specific directory.
501.20s - 503.52s |  And the problem with this is,
503.52s - 506.00s |  to start with dangling resources,
506.00s - 508.92s |  some past work includes, you can buy DNS data
508.92s - 512.20s |  and then enumerate your cloud provider's IP pool
512.20s - 514.40s |  in order to find what's dangling.
514.40s - 517.00s |  So, if I go ahead and create a resource
517.00s - 519.56s |  over and over again in a cloud environment,
519.56s - 521.32s |  I'll be assigned IP addresses
521.32s - 523.88s |  that are not assigned to any other customer.
523.88s - 527.68s |  And if one of these IP addresses matches a DNS record
527.68s - 529.92s |  that I found in DNS data
529.92s - 532.40s |  that threat intelligence providers sell,
532.40s - 534.60s |  well, that's one way you can capture
534.60s - 536.80s |  a dangling DNS record.
537.68s - 539.96s |  And other attempts also include
539.96s - 541.88s |  going after a specific target.
541.88s - 543.96s |  So, instead of using DNS data you buy
543.96s - 545.80s |  from threat intelligence providers,
545.80s - 548.64s |  you'll instead go ahead and enumerate that provider pool,
548.64s - 550.64s |  but this time compare against subdomains
550.64s - 555.49s |  you've enumerated for that specific provider.
555.49s - 557.69s |  So, to give you some examples,
557.69s - 559.53s |  there's been a lot of work in this area.
559.53s - 562.97s |  Bishop Fox originally came out in 2015 with an article
562.97s - 565.57s |  where they used this passive DNS data,
565.57s - 567.29s |  or at least a variant of it,
567.29s - 570.65s |  in order to enumerate an AWS cloud IP pool
570.65s - 573.85s |  and then capture AWS IPs that corresponded
573.85s - 576.49s |  to a specific domain they were interested in.
576.49s - 578.37s |  So, in that case they used bing.com
578.37s - 580.57s |  to find those dangling DNS records.
582.25s - 586.21s |  Some other work includes flying a false flag
586.21s - 587.65s |  from Black Hat, it's a talk,
587.65s - 589.85s |  where they used passive DNS data
589.85s - 591.77s |  from these threat intelligence providers
591.77s - 596.64s |  to determine whether IPs they captured were dangling.
597.08s - 600.56s |  This project was, again, focused on creating these backends
600.56s - 602.86s |  for C2 malware platforms.
602.86s - 605.34s |  They wanted to take control of legitimate domains
605.34s - 607.12s |  so that they could abuse those domains
607.12s - 609.00s |  for a false level of trust.
610.76s - 612.56s |  One interesting note about this project
612.56s - 615.22s |  is that they noted that after releasing it,
615.22s - 619.16s |  it would appear that AWS and GCP now assign IPs
619.16s - 621.52s |  from a limited pool for your account.
621.52s - 623.16s |  We'll touch on this more later,
623.16s - 624.90s |  but this is what we're gonna be focusing on
624.90s - 627.44s |  when it comes to dangling DNS resources.
627.44s - 629.16s |  The topic is well-traversed,
629.16s - 630.42s |  but what's not well-traversed
630.42s - 632.18s |  are the modern deterrents against it
632.18s - 633.66s |  and how we can bypass them.
635.22s - 637.18s |  And finally, there's still a lot of work
637.18s - 640.82s |  where attackers simply enumerate your domain's subdomains
640.82s - 644.92s |  and then find IPs that match them.
644.92s - 646.62s |  Now, when it comes to leaked secrets,
646.62s - 648.50s |  the story's a bit different.
648.50s - 652.70s |  It's not as well-traversed as dangling DNS records at all.
652.70s - 655.48s |  So, for example, there's tools that you can use
655.52s - 659.00s |  to search a Git repository for these secret patterns.
659.00s - 661.56s |  And even GitHub has a system
661.56s - 663.78s |  where they'll scan every content,
663.78s - 666.88s |  every piece of code uploaded to their platform
666.88s - 668.96s |  for these secret patterns.
668.96s - 670.72s |  But the limitation with this work
670.72s - 674.68s |  is that it's really a very small scope.
674.68s - 676.22s |  I mean, think about how much code
676.22s - 678.04s |  is really gonna end up on GitHub.
678.04s - 680.28s |  You know, most enterprises aren't gonna put
680.28s - 683.28s |  their closed-source applications on GitHub
683.28s - 687.67s |  where this scanning would occur in the first place.
687.67s - 690.33s |  Now, going on to defender approaches
690.33s - 692.09s |  to mitigate these vulnerabilities,
692.09s - 694.81s |  well, there have been pretty limited as well.
694.81s - 698.21s |  Oftentimes, these are treated as customer vulnerabilities,
698.21s - 700.37s |  which technically is correct.
700.37s - 701.93s |  If you think about it from a high level,
701.93s - 705.37s |  if you leak a secret or leave a DNS record dangling,
705.37s - 707.39s |  that is your responsibility.
707.39s - 709.25s |  But what I think that is often missed
709.25s - 711.33s |  is the provider's responsibility
711.33s - 714.57s |  in how they encourage these insecure defaults.
715.33s - 718.85s |  So for example, tokens are really, really easy to use.
718.85s - 721.03s |  Have you ever thought about how easy it is
721.03s - 723.19s |  to use a token in your code?
723.19s - 726.41s |  And that's how it can get leaked in the first place.
726.41s - 728.49s |  Now, Fortune 500 companies might have
728.49s - 731.51s |  those standard secure development lifecycle practices
731.51s - 732.97s |  where they can avoid this,
732.97s - 736.53s |  but in reality, a lot of small to medium-sized businesses
736.53s - 738.17s |  might not understand this nuance
738.17s - 744.09s |  or be able to apply it uniform across their organization.
744.09s - 746.53s |  Now, this is something we're gonna talk about later,
747.21s - 748.77s |  but I want you to keep it in mind.
748.77s - 752.69s |  Remember, even though it's a cloud customer vulnerability,
752.69s - 754.45s |  there's incentives that lead to them
754.45s - 756.09s |  being created in the first place.
757.21s - 759.85s |  So let's talk about the traditional security mindset.
761.01s - 763.65s |  Traditional bugs discovery is often centered
763.65s - 765.33s |  around a specific target.
765.33s - 766.85s |  You know, if I'm looking for vulnerabilities,
766.85s - 769.25s |  I might go reverse engineer an application,
769.25s - 771.17s |  and with dangling domains,
771.17s - 774.37s |  one of the earliest approaches was going first,
774.37s - 776.65s |  enumerating the subdomains of my target,
776.65s - 779.29s |  and then enumerating the cloud provider IP pools
779.29s - 782.05s |  in order to identify dangling resources.
782.05s - 785.39s |  Now, for secrets, again, we start with a specific target,
785.39s - 787.29s |  whether that be a single repository
787.29s - 789.45s |  or a single platform like GitHub.
790.45s - 792.21s |  And what I really started to think about
792.21s - 794.29s |  as I looked into this further and further
794.29s - 795.97s |  was whether there's an opportunity
795.97s - 799.13s |  for some vulnerabilities to be approached differently.
799.13s - 802.99s |  For example, were we really facing tunnel vision here?
802.99s - 805.71s |  Why do we need to start with a specific target?
806.55s - 808.27s |  It's almost as if, you know,
808.27s - 809.95s |  there is a lack of focus in the industry
809.95s - 811.71s |  against finding bugs at scale,
811.71s - 814.87s |  and rather finding bugs in individual areas.
814.87s - 816.55s |  And that's what I really wanted to focus on
816.55s - 817.81s |  with this research is,
817.81s - 820.81s |  can we find these vulnerabilities at scale?
821.97s - 824.47s |  So to expand on this, with dangling resources,
824.47s - 827.35s |  the traditional mindset might include start with a target
827.35s - 829.39s |  and then capture vulnerable assets.
829.39s - 831.31s |  But as we've seen with past work,
831.31s - 834.07s |  it can often be a lot larger than that too.
834.07s - 836.03s |  For example, the security at scale approach
836.03s - 837.11s |  to dangling domains would be
837.11s - 840.03s |  to capture dangling assets first,
840.03s - 842.23s |  and then check if there's any DNS records
842.23s - 845.65s |  still pointing at them using passive DNS replication data.
846.55s - 848.71s |  Now, here's where it gets interesting.
848.71s - 851.21s |  For leak secrets, there's no such equivalent.
852.03s - 855.27s |  You know, we have approaches to scan limited scopes
855.27s - 856.93s |  for these secret patterns,
856.93s - 860.55s |  but when it comes to that security at scale mindset,
860.55s - 863.99s |  it still goes around a very limited target.
863.99s - 867.95s |  You know, we start with a repository, a folder, a file,
867.95s - 870.27s |  instead of starting with a diverse data source
870.27s - 877.64s |  that allows us to look for these secrets in a broad manner.
877.64s - 879.88s |  So this is what I really want you to take away
879.88s - 881.40s |  from this talk from a high level,
881.40s - 883.12s |  is that there's an untapped potential
883.12s - 885.38s |  to use unconventional data sources
885.38s - 887.36s |  to find these vulnerabilities.
887.36s - 888.90s |  We're about to go through some examples,
888.90s - 890.74s |  but what I really want you to think about
890.74s - 891.96s |  is not just, you know,
891.96s - 894.36s |  here's how Bill applied it to dangling domains
895.08s - 895.92s |  and leak secrets,
895.92s - 897.12s |  but rather how you can apply it
897.12s - 899.92s |  to other types of vulnerability classes as well.
899.92s - 902.56s |  This is not just about these two vulnerability classes.
902.56s - 904.60s |  These two vulnerability classes are examples
904.60s - 908.58s |  that you can apply to your own work.
908.58s - 910.90s |  So let's talk about how we would actually implement this
910.90s - 912.62s |  in practice.
912.62s - 913.50s |  From a high level,
913.50s - 916.66s |  we start with the vulnerability, not the target.
916.66s - 918.10s |  So, and then we work backwards
918.10s - 920.50s |  by using creative data sources.
920.50s - 922.42s |  Remember, for dangling resources,
922.42s - 924.18s |  we already have a playbook.
924.66s - 927.10s |  You know a DNS record is dangling
927.10s - 928.66s |  if it points at an IP address
928.66s - 931.26s |  that the customer no longer controls.
931.26s - 933.88s |  How do you know if an IP is no longer controlled
933.88s - 934.94s |  by a customer?
934.94s - 936.98s |  Well, we can enumerate the cloud IP pool
936.98s - 940.42s |  and determine every IP that we get in our attacker account
940.42s - 942.86s |  is likely something that no other customer controls
942.86s - 945.42s |  because that IP is assigned to us.
945.42s - 946.94s |  But how do we know if it's dangling?
946.94s - 949.82s |  Well, again, that passive DNS replication data.
949.82s - 951.00s |  And if you're not familiar with this,
951.00s - 953.78s |  how it works is that threat intelligence providers
954.46s - 956.26s |  will work with DNS providers
956.26s - 960.14s |  to sell this aggregate DNS traffic data.
960.14s - 963.14s |  For example, you can give these threat intel providers
963.14s - 965.14s |  an IP address and they'll give you
965.14s - 969.84s |  every single DNS record that points at it.
969.84s - 973.52s |  Now, again, we can capture assets first with DNS records
973.52s - 975.60s |  instead of starting with a target.
975.60s - 978.48s |  What we'll do is we'll go through a cloud provider pool
978.48s - 981.14s |  and we'll go and enumerate every IP address
981.14s - 982.28s |  that we're able to get
982.28s - 985.16s |  and look for DNS records that point at it.
985.20s - 986.60s |  What we're gonna do in the next section
986.60s - 989.76s |  is apply this generic technique we've seen in past work
989.76s - 992.10s |  against modern deterrence.
993.76s - 995.52s |  But what about secret scanning?
995.52s - 996.68s |  So this is the interesting one.
996.68s - 1001.10s |  This is one that we still have a lot of research to do in.
1001.10s - 1003.12s |  We have passive DNS replication data
1003.12s - 1007.04s |  for dangling resources, but what about leaked secrets?
1007.04s - 1009.32s |  From a high level, the ideal data source
1009.32s - 1012.56s |  needs to be diverse, needs to be sufficient in volume,
1012.60s - 1017.28s |  and it needs to include a diverse set of websites,
1017.28s - 1020.68s |  executables, not just open source applications,
1020.68s - 1024.36s |  but we need to include closed source applications too.
1024.36s - 1026.16s |  And we need to make sure that this is done
1026.16s - 1027.56s |  in a feasible way.
1027.56s - 1030.92s |  For example, even if we have a large data set
1030.92s - 1033.56s |  of these files, we need to make sure we can scan it
1033.56s - 1034.84s |  in a practical manner.
1035.80s - 1038.00s |  So where can we find this large collection
1038.00s - 1039.98s |  of apps and scripts?
1039.98s - 1043.84s |  So what about virus scanning platforms?
1045.38s - 1047.62s |  This is where it's gonna get really interesting.
1047.62s - 1050.38s |  So what we've seen with past work
1050.38s - 1053.30s |  is a lot of people focusing on these platforms
1053.30s - 1055.38s |  with limited diversity.
1055.38s - 1057.42s |  You know, we look at GitHub, it's really gonna only be
1057.42s - 1060.18s |  open source repositories that are being scanned
1060.18s - 1062.58s |  and automatically revoking keys.
1062.58s - 1064.18s |  You know, we look at these tools,
1064.18s - 1067.30s |  they all focus on scanning individual targets
1067.30s - 1070.34s |  like folders, specific repos, et cetera,
1070.34s - 1072.72s |  but what we're missing is that diverse data source,
1072.72s - 1075.70s |  and that's what I really focused on in this research.
1075.70s - 1078.46s |  What I found was that virus scanning platforms
1078.46s - 1080.72s |  were actually a really interesting target
1080.72s - 1083.34s |  because think about it, think about all the stuff
1083.34s - 1086.22s |  that people upload to virus scanning platforms.
1086.22s - 1087.92s |  You know, think about all the websites
1087.92s - 1090.50s |  that are automatically scanned, all the applications,
1090.50s - 1092.84s |  all the mobile apps that are included
1092.84s - 1094.98s |  in this virus total data source,
1094.98s - 1096.88s |  and as well as other platforms.
1097.94s - 1100.10s |  Now, with these scanning platforms,
1100.10s - 1102.90s |  it would be infeasible to go ahead and, you know,
1102.90s - 1105.82s |  download what, a billion, nine billion files
1105.82s - 1108.18s |  and scan each of them individually,
1108.18s - 1109.30s |  but we don't need to do that
1109.30s - 1112.38s |  because we can use the tools that they already provide us.
1112.38s - 1116.42s |  Nearly every virus scanning platform lets you search
1116.42s - 1119.26s |  for specific patterns, specific strings,
1119.26s - 1121.18s |  like they're literally spoon feeding us
1121.18s - 1122.86s |  to perfect data source here.
1122.86s - 1125.50s |  And traditionally, what we've used this data source for
1125.50s - 1128.90s |  is to find malware, you know, find malicious use, et cetera,
1128.90s - 1131.30s |  but what's really interesting about them is that
1131.30s - 1133.22s |  what if we use secret patterns
1133.22s - 1135.34s |  instead of malicious patterns?
1135.34s - 1136.98s |  What if instead of looking for malware,
1136.98s - 1138.78s |  we look for secrets instead?
1140.34s - 1142.20s |  And with virus total, this is retro hunt,
1142.20s - 1143.44s |  but seriously, if you look at
1143.44s - 1145.80s |  nearly every other virus scanning platform,
1145.80s - 1149.46s |  what you'll find is that they have a similar future,
1149.46s - 1151.06s |  at least if you have an account.
1152.50s - 1157.64s |  So let's apply this in practice.
1157.64s - 1160.88s |  So with secret scanning, the plan is from a high level.
1160.88s - 1164.04s |  We wanna make sure that we look for secret patterns.
1164.04s - 1165.44s |  And what that really means is,
1165.44s - 1168.48s |  think about your AWS access key.
1168.48s - 1169.40s |  I don't know if you've noticed,
1169.40s - 1172.36s |  but it'll often start with A-K-I-A.
1172.36s - 1174.88s |  And what we can do is we can create these regex strings
1174.88s - 1177.52s |  for identifying these secrets,
1177.52s - 1180.24s |  and we can look for them using the same tools
1180.24s - 1182.72s |  we have available for malware hunting.
1182.72s - 1186.80s |  So most virus platforms allow you to search by a Yara rule.
1186.80s - 1189.60s |  And so what we can do is we can create a Yara rule
1189.60s - 1191.64s |  for these secret patterns,
1191.64s - 1194.76s |  and then we can search samples uploaded to the platform
1194.76s - 1197.64s |  for whether these patterns exist in them.
1197.64s - 1200.00s |  Now, one thing interesting that I did in this research
1200.00s - 1202.96s |  was also focused on validating these secrets.
1202.96s - 1205.46s |  So I've looked at a lot of past work into leaked secrets,
1205.46s - 1208.44s |  and what I've found is there's a lot of theoretical research
1208.44s - 1210.12s |  that discusses things like,
1210.12s - 1212.32s |  oh, we looked for these secret patterns,
1212.32s - 1214.76s |  and we found these unique keys,
1214.76s - 1216.48s |  but you read into it a little deeper,
1217.16s - 1219.24s |  and they didn't even check if those keys are legitimate.
1219.24s - 1221.48s |  That's something that didn't really make sense to me.
1221.48s - 1223.32s |  There's gonna be thousands and thousands
1223.32s - 1226.48s |  and tens of thousands of keys that match a specific pattern
1226.48s - 1229.08s |  but are not active in practice.
1229.08s - 1232.32s |  And so what we did was that I used a platform
1232.32s - 1233.82s |  to actually validate these keys,
1233.82s - 1235.36s |  at least with basic metadata,
1235.36s - 1239.36s |  and validate that they're legitimate for our use case.
1239.36s - 1241.68s |  Now, some patterns are gonna be really noisy,
1241.68s - 1244.80s |  but if the provider doesn't make it easy
1244.80s - 1246.56s |  to identify their secrets,
1246.56s - 1248.04s |  you're gonna find that you're gonna have to scan
1248.04s - 1251.00s |  thousands and thousands of secret patterns
1251.00s - 1253.36s |  in thousands of thousands of files.
1253.36s - 1255.98s |  So how do we deal with this large volume?
1255.98s - 1257.88s |  Well, what I did to do it on my budget,
1257.88s - 1260.20s |  remember, I'm doing this everything out of pocket,
1260.20s - 1262.48s |  was leverage serverless computing.
1262.48s - 1267.48s |  So I needed a capacity of having several physical server racks
1267.60s - 1271.56s |  but I don't have money to buy several physical server racks.
1271.56s - 1273.96s |  Instead, I can rent them using the cloud,
1273.96s - 1277.64s |  and what that really means is I made a serverless function
1277.64s - 1280.60s |  in order to scan these files,
1280.60s - 1282.28s |  and I also made a serverless function
1282.28s - 1284.86s |  to validate the keys that were found.
1284.86s - 1287.84s |  And this way, I don't actually have to pay that much
1287.84s - 1289.88s |  because I only pay for what I use.
1289.88s - 1292.08s |  In practice, my costs were actually
1292.08s - 1293.92s |  fairly reasonable for an individual.
1295.44s - 1296.80s |  Now, for dangling resources,
1296.80s - 1298.80s |  again, the methodology from a high level
1298.80s - 1302.84s |  was to reallocate resources over and over and over again.
1302.88s - 1304.28s |  And then it was to cross-check them
1304.28s - 1307.00s |  with passive DNS replication data.
1307.00s - 1309.38s |  Remember, this isn't necessarily new,
1309.38s - 1312.46s |  but what's interesting about them is that
1312.46s - 1315.88s |  we're gonna be talking about bypassing modern deterrents.
1315.88s - 1317.90s |  And what I mean by that is a lot of cloud providers
1317.90s - 1320.72s |  have implemented these mitigations to make it harder
1320.72s - 1323.68s |  to do this dangling DNS record enumeration,
1323.68s - 1327.04s |  and we're gonna bypass them.
1327.04s - 1329.08s |  So from a high level,
1329.08s - 1331.84s |  one thing I wanna call out is that earlier no.
1331.84s - 1334.72s |  Remember, it would appear that AWS began
1334.72s - 1339.08s |  serving Elastic IPs from a small, specific pool
1339.08s - 1340.76s |  similar to GCP.
1341.60s - 1345.12s |  This severely limits the diversity of addresses received.
1345.12s - 1348.20s |  And so let me tell you what this really means in practice.
1348.20s - 1351.52s |  So what's going on here is that AWS and GCP
1351.52s - 1354.96s |  have a mitigation where when you are asked
1354.96s - 1357.00s |  to assign me an IP address,
1357.00s - 1359.96s |  whether that be an Elastic IP or in GCP case,
1359.96s - 1362.74s |  nearly every resource that you can go ahead and allocate
1362.74s - 1364.24s |  that needs an IP,
1364.24s - 1366.30s |  these cloud providers will only give you
1366.30s - 1371.00s |  a specific set of IPs assigned to a shared pool
1371.00s - 1374.40s |  that's limited to your account and maybe a few others.
1374.40s - 1378.92s |  And for AWS, this is gonna be largely Elastic IP sharing.
1378.92s - 1382.68s |  So that means whenever you ask for a dedicated Elastic IP,
1382.68s - 1385.16s |  you'll notice if you free an Elastic IP
1385.16s - 1386.32s |  and allocate another one,
1386.32s - 1388.64s |  you're gonna be assigned the same one over and over again,
1388.64s - 1389.70s |  or in general.
1390.44s - 1391.66s |  It's really hard to actually enumerate that pool
1391.66s - 1393.28s |  using Elastic IPs alone.
1394.52s - 1397.98s |  Now with AWS, they also introduced a mitigation.
1397.98s - 1399.10s |  I don't know if it's intentionally
1399.10s - 1401.50s |  to go against dangling DNS enumeration,
1401.50s - 1404.42s |  but they did introduce a mitigation in 2024
1404.42s - 1406.58s |  where every IP address you received
1406.58s - 1410.02s |  was actually had an increased surcharge.
1410.02s - 1413.46s |  So now every IP you got allocated costs you extra money.
1413.46s - 1416.54s |  And this deters attacks by making it more expensive
1416.54s - 1418.62s |  to enumerate their public IP pools
1418.62s - 1423.50s |  and capture these dangling DNS records.
1423.50s - 1425.58s |  Now for Google Cloud, it's interesting.
1425.58s - 1428.14s |  They actually had quite a lot more than I expected.
1428.14s - 1430.02s |  So for project levels,
1430.02s - 1433.62s |  so every account can have about 10 to 15 projects
1433.62s - 1434.78s |  assigned to them.
1434.78s - 1436.58s |  By default, you can request an increase,
1436.58s - 1438.20s |  but you need justification.
1438.20s - 1442.50s |  Now IPs are again assigned from a small pool just like AWS.
1442.50s - 1445.26s |  You only have eight IPs you can use by default
1445.26s - 1446.86s |  in per region and globally.
1447.74s - 1449.34s |  And with these accounts,
1449.34s - 1452.42s |  you also had something called a billing account restriction.
1452.42s - 1454.06s |  So with Google Cloud,
1454.06s - 1457.54s |  every credit card can be created into a billing account.
1457.54s - 1459.18s |  Now you can create a few billing accounts
1459.18s - 1460.88s |  based off of one credit card,
1460.88s - 1462.78s |  but if you try to create more than a few,
1462.78s - 1465.06s |  you'll automatically hit their suspension
1465.06s - 1466.42s |  and you'll have to go justify
1466.42s - 1469.94s |  why are you creating a 50th credit card account
1469.94s - 1472.14s |  or billing account with one credit card.
1472.14s - 1475.30s |  And so all these deterrents really make it difficult
1475.30s - 1478.38s |  for attackers to enumerate these dangling domains.
1478.38s - 1480.02s |  In fact, with Google Cloud,
1480.02s - 1482.74s |  while managed DNS enumeration was always a thing
1482.74s - 1484.60s |  and has been for the past few years,
1484.60s - 1486.78s |  attackers haven't been able to enumerate
1486.78s - 1490.50s |  Google Cloud's public IP pools for quite some time,
1490.50s - 1495.16s |  at least none researched that I could find online.
1495.16s - 1497.26s |  So with those AWS mitigations,
1497.26s - 1499.14s |  they're actually pretty simple to bypass.
1499.14s - 1500.98s |  Instead of allocating elastic IPs,
1500.98s - 1505.26s |  we can just restart EC2 instances with ephemeral IPs
1505.26s - 1508.10s |  and we can perform the enumeration by just restarting,
1508.66s - 1513.66s |  restarting, and my IP address that my EC2 instances assigned
1514.06s - 1518.02s |  will generally rotate a lot faster through unique IPs
1518.02s - 1520.98s |  than if you tried with elastic IPs.
1520.98s - 1523.30s |  In fact, I actually was able to enumerate
1523.30s - 1526.26s |  nearly 2.4 million unique IP addresses
1526.26s - 1529.62s |  in a span of six months by using this methodology.
1530.50s - 1532.26s |  Now with Google Cloud, again,
1532.26s - 1535.18s |  they had a harder set of mitigations,
1535.18s - 1538.50s |  but those mitigations were deterrence.
1538.50s - 1541.78s |  So how it worked was that I used a backend bucket
1541.78s - 1544.54s |  with a load balancer in order to assign IP addresses
1544.54s - 1545.78s |  to my resources.
1545.78s - 1547.74s |  But this still didn't let me get past
1547.74s - 1549.62s |  these cloud resource restrictions.
1549.62s - 1551.14s |  How do we do that?
1551.14s - 1553.10s |  Well, once we have this primitive
1553.10s - 1555.16s |  for enumerating cloud IPs,
1555.16s - 1557.16s |  we can talk about those limitations.
1557.16s - 1559.62s |  But for high level information,
1559.62s - 1562.46s |  where we used forwarding rules instead of virtual machines
1562.46s - 1564.42s |  in order to enumerate these IPs.
1566.10s - 1569.18s |  So with Google Cloud, remember all those restrictions?
1569.18s - 1572.02s |  Well, we can actually bypass all of them fairly cheaply.
1572.86s - 1575.18s |  So number one, with a billing account,
1575.18s - 1576.38s |  one interesting thing I found
1576.38s - 1577.98s |  was that you can assign billing accounts
1577.98s - 1579.74s |  across Google accounts.
1579.74s - 1580.94s |  This was a useful primitive
1580.94s - 1583.62s |  where if I could create a billing account in one account,
1583.62s - 1585.88s |  I can actually assign it across several accounts.
1585.88s - 1587.94s |  And the reason this is interesting is,
1587.94s - 1589.96s |  well, what about those quotas?
1589.96s - 1591.50s |  Well, with account quotas,
1591.50s - 1594.06s |  remember you can only create a certain amount of projects.
1594.06s - 1596.54s |  Now again, you can request an increase in this limit,
1596.54s - 1599.10s |  but you don't wanna have to do this justification.
1599.10s - 1600.58s |  I felt that it would be inappropriate
1600.58s - 1601.68s |  to assume that an attacker
1601.68s - 1603.78s |  would be able to get this quota increase.
1603.78s - 1604.74s |  What I found was though,
1604.74s - 1607.12s |  you can create a Google Workspace environment.
1607.12s - 1610.32s |  So what that means is I can create a fakebusiness.com,
1610.32s - 1612.62s |  I can create Google Workspace environment for it,
1612.62s - 1615.70s |  and I can create practically as many Google accounts
1615.70s - 1620.26s |  as I want for about $6 per account per month.
1620.26s - 1622.62s |  And this way, each of those accounts
1622.62s - 1624.58s |  gets a dedicated quota limit
1624.58s - 1627.10s |  and allows you to bypass these quota limits
1627.10s - 1629.46s |  by creating, for example, 10 accounts.
1629.46s - 1633.78s |  Now that's $60, but now your quota has been 10-timed.
1633.78s - 1636.54s |  And finally, to bypass billing account restrictions,
1636.54s - 1638.52s |  remember those credit card restrictions,
1638.52s - 1640.16s |  billing accounts can only be associated
1640.16s - 1642.46s |  with a certain number of projects.
1642.46s - 1645.62s |  Well, we can instead then use virtual credit cards.
1645.62s - 1648.58s |  And I use privacy.com, that's not a recommendation,
1648.58s - 1651.06s |  it's just one of the easiest that worked for me.
1651.06s - 1653.26s |  And what really this means is
1653.26s - 1655.98s |  it's not like they're bypassing KYC practices,
1655.98s - 1657.74s |  they verified my identity,
1657.74s - 1659.40s |  but it still allows me to create
1659.40s - 1661.66s |  as many credit card numbers as I want
1661.66s - 1663.98s |  and be able to create as many billing accounts as I want
1663.98s - 1666.04s |  to be able to bypass every single restriction
1666.04s - 1668.22s |  we discussed with Google Cloud.
1668.22s - 1670.46s |  And so this is what I really wanna mention
1670.46s - 1671.42s |  from a high level,
1671.42s - 1673.56s |  is Google Cloud implemented all these deterrents
1673.56s - 1675.94s |  to try to make sure you can't enumerate
1675.94s - 1678.42s |  their dangling IPs,
1678.46s - 1679.70s |  but in practice,
1679.70s - 1682.30s |  these deterrents weren't addressing the root cause,
1682.30s - 1684.74s |  which was the fact that the dangling IPs
1684.74s - 1691.30s |  still existed in the first place.
1691.30s - 1694.60s |  So let's talk about a little bit of the discovery process
1694.60s - 1698.32s |  and what I was able to find with these techniques.
1699.94s - 1702.70s |  So with dangling resources,
1702.70s - 1705.30s |  I was able to enumerate over 2 million IP addresses
1705.30s - 1707.18s |  for Google Cloud and AWS.
1707.18s - 1709.10s |  These are unique IP addresses
1709.10s - 1711.48s |  and they're mostly primitive resources.
1711.48s - 1713.60s |  So these IPs were created by,
1713.60s - 1716.96s |  remember, restarting an EC2 instance
1716.96s - 1719.82s |  or creating forwarding rules over and over again.
1720.80s - 1721.64s |  As far as I'm aware,
1721.64s - 1723.00s |  this is one of the first methodologies
1723.00s - 1726.54s |  to successfully bypass every single Google Cloud deterrent
1726.54s - 1728.98s |  that is intended to stop this type of attack
1728.98s - 1730.54s |  in the first place.
1730.54s - 1735.54s |  I captured over 60,000 unique fully qualified domain names.
1735.84s - 1738.52s |  And this reflects past research into this area
1738.52s - 1742.10s |  where researchers found that these FQDNs,
1742.10s - 1743.68s |  there are a lot of different A records
1743.68s - 1747.52s |  that pointed at IPs that were no longer being controlled.
1747.52s - 1750.28s |  Now out of these 60,000 FQDNs,
1750.28s - 1753.88s |  there are about 54,000 unique second level domains.
1753.88s - 1754.92s |  And what that really means
1754.92s - 1756.96s |  is that once you take away the subdomain,
1756.96s - 1759.04s |  let's say a.b.com,
1759.04s - 1761.60s |  we're just focusing on the unique number of APEX
1761.60s - 1763.60s |  or second level domains.
1763.60s - 1766.64s |  Well, that was over 54,000.
1766.64s - 1770.40s |  And finally, over 5,000 of the domains
1770.40s - 1771.80s |  that I was able to capture
1772.84s - 1775.56s |  were included in the Tranco top 1 million list.
1775.56s - 1778.76s |  So Tranco is a listing of every domain
1778.76s - 1781.76s |  that they're aware of within a certain ranking.
1781.76s - 1783.64s |  And it allows you to compare
1783.64s - 1786.02s |  what is supposed to be an objective metric
1786.02s - 1789.30s |  for ranking of the domain based on DNS data.
1789.30s - 1793.00s |  Now, there are a lot of Fortune 500 companies impacted.
1793.00s - 1796.22s |  And what I found really interesting was that with AWS,
1796.94s - 1799.14s |  we had a roughly 25,
1799.14s - 1802.98s |  a rate of 25 dangling domains per 1,000 IPs.
1802.98s - 1806.74s |  But with Google Cloud, it was nearly 36.
1806.74s - 1811.06s |  And so what I suspect this discrepancy is as a result of
1811.06s - 1814.02s |  is that Google Cloud hasn't been able to been enumerated
1814.02s - 1817.72s |  for quite a few years.
1817.72s - 1819.40s |  Now, this talk isn't gonna focus
1819.40s - 1822.32s |  on the actual impact against customers
1822.32s - 1824.08s |  because I promised DEF CON review board
1824.08s - 1825.82s |  I wouldn't get stuck on it.
1825.82s - 1827.94s |  But you can see that I was able to compromise
1827.94s - 1830.14s |  some of the world's largest organizations,
1830.14s - 1834.60s |  including the Western District Court of Texas,
1834.60s - 1836.46s |  the New York Times,
1836.46s - 1841.10s |  the State Government of California, and Dior.
1841.10s - 1843.52s |  And yeah, it was a pretty fun time.
1843.52s - 1844.94s |  There was a lot more examples here.
1844.94s - 1847.30s |  Again, this isn't intended to cover it.
1847.30s - 1849.74s |  That's on a separate blog post as well.
1849.74s - 1852.58s |  I really go into detail about the impact.
1852.58s - 1854.34s |  And for a secret scanning,
1854.34s - 1855.94s |  again, what was really interesting
1855.94s - 1860.26s |  was that I scanned over 5 million unique files
1860.26s - 1862.30s |  from various platforms, not just VirusTotal.
1862.30s - 1863.86s |  That was just one of them.
1863.86s - 1867.62s |  And I discovered over 15,000 validated secrets.
1867.62s - 1868.96s |  And out of these secrets,
1868.96s - 1872.90s |  they included over 2,500 unique, again, validated.
1872.90s - 1875.20s |  These aren't just, you know, may match a pattern.
1875.20s - 1876.42s |  These are validated.
1876.42s - 1878.98s |  To over 2,500 validated secrets,
1878.98s - 1881.98s |  over 2,400 unique AWS keys,
1881.98s - 1884.78s |  over 2,200 GitHub personal access tokens
1884.78s - 1886.52s |  and fine-grained tokens,
1886.52s - 1889.76s |  over 600 Google's cloud service accounts,
1889.76s - 1892.38s |  over 460 Stripe accounts,
1892.38s - 1895.54s |  and the rest are largely from miscellaneous providers
1895.54s - 1896.70s |  added up together
1896.70s - 1899.34s |  that I didn't feel the need to include in this slide.
1900.30s - 1912.12s |  And again, there will be a blog to recap this,
1912.12s - 1913.92s |  but from a high level,
1913.92s - 1915.64s |  it's some of the largest organizations
1915.64s - 1917.00s |  in the world were impacted.
1917.00s - 1918.82s |  You know, just a fun example a few months ago
1918.82s - 1923.00s |  was Slack, Stanford's entire Slack workspace,
1924.18s - 1926.98s |  Samsung's workspace for Bixby.
1926.98s - 1928.96s |  I was able to get a bot token
1928.96s - 1931.42s |  for this Samsung Bixby tenant,
1931.42s - 1933.48s |  and which allowed me to read messages
1933.48s - 1935.06s |  from nearly every channel,
1935.06s - 1937.62s |  every single channel that the bot had access to
1937.62s - 1940.68s |  because of a default scope that was quite broad.
1940.68s - 1941.94s |  You know, some other interesting things
1941.94s - 1944.54s |  included the Supreme Court of Nebraska.
1944.54s - 1945.58s |  That was a fun one,
1945.58s - 1948.58s |  where they uploaded a password list to VirusTotal
1949.32s - 1951.38s |  with like 300 credentials from different,
1951.38s - 1954.18s |  like, I don't know, different AWS providers,
1954.18s - 1955.22s |  different cloud providers,
1955.22s - 1957.36s |  their security solutions, et cetera.
1957.36s - 1959.02s |  That was a really fun one.
1959.02s - 1960.72s |  You know, there are database backups
1960.72s - 1962.54s |  with a lot of these AWS keys
1962.54s - 1965.10s |  that had broad access to S3 buckets.
1965.10s - 1967.38s |  Anyways, you'll be able to read a lot more about this
1967.38s - 1968.54s |  this following week.
1969.70s - 1972.74s |  So by leveraging a security at scale mindset,
1972.74s - 1975.14s |  we can help protect thousands of organizations
1975.14s - 1977.14s |  far beyond a limited scope.
1977.98s - 1980.98s |  Remember, instead of starting with a specific target,
1980.98s - 1983.02s |  by starting with a diverse dataset,
1983.02s - 1985.58s |  we were able to have a much wider impact
1985.58s - 1988.48s |  than any of past work into leaked secrets.
1989.42s - 1991.30s |  You can read more about some of this impact
1991.30s - 1995.14s |  in an article that should be released right now
1995.14s - 1997.06s |  by Matt Burgess from Wired.
1997.06s - 1999.34s |  And I'll be releasing a detailed technical blog
1999.34s - 2000.58s |  later this week,
2000.58s - 2003.36s |  once I figure out whether a certain cloud provider
2003.36s - 2007.62s |  can actually revoke some of these keys or not.
2007.62s - 2012.70s |  So bringing it all together.
2012.70s - 2016.18s |  Hard coding secrets is the path of least resistance.
2016.18s - 2019.10s |  So remember, these are customer vulnerabilities,
2019.10s - 2024.10s |  but what enables them is these bad incentives.
2024.16s - 2025.00s |  Think about it.
2025.00s - 2026.38s |  Think about how easy it is to go ahead
2026.38s - 2028.58s |  and generate an AWS access key
2028.58s - 2031.10s |  or generate a Google Cloud Service account
2031.10s - 2033.86s |  and then put that into your executable directly.
2033.86s - 2036.80s |  You know, the libraries for these different providers
2036.80s - 2040.02s |  allow this direct interface in the first place.
2041.52s - 2043.28s |  Now, the reason this is really important
2043.28s - 2044.68s |  is because a lot of developers
2044.68s - 2047.82s |  are gonna follow the path of least resistance,
2047.82s - 2050.54s |  especially from smaller to mid-cap businesses.
2051.46s - 2054.88s |  And with dangling DNS records, the same problem exists.
2054.88s - 2057.12s |  It's the path of least resistance.
2057.12s - 2059.80s |  I created an AWS EC2 instance,
2059.80s - 2063.44s |  I put my DNS record pointing at that AWS EC2 instance,
2063.44s - 2065.52s |  and the path of least resistance
2065.52s - 2068.56s |  is leaving that DNS record even if I deallocate it.
2069.44s - 2071.56s |  And what I think we need to really focus on
2071.56s - 2074.28s |  is making sure that the path of least resistance
2074.28s - 2076.12s |  is the secure path.
2076.12s - 2080.48s |  And what this really means is with dangling resources,
2080.48s - 2082.64s |  I think we need to have better ownership
2082.64s - 2086.84s |  of cloud resources and DNS records, better association.
2086.84s - 2088.60s |  So for example, some cloud providers
2088.60s - 2092.28s |  have tried to associate their DNS services
2092.28s - 2095.72s |  with their EC2 resources, as one example.
2095.72s - 2098.52s |  And the problem with this is a lot of different customers
2098.52s - 2100.46s |  are gonna use different DNS providers,
2100.46s - 2101.84s |  different cloud providers.
2101.84s - 2104.52s |  What we really need is an industry-wide solution
2104.52s - 2108.44s |  of tracking DNS records and tracking cloud resources
2108.44s - 2112.96s |  and putting them together.
2112.96s - 2115.92s |  Now, for hard-coded secrets,
2115.92s - 2117.68s |  what I really think we need to focus on
2117.68s - 2119.72s |  is making sure that it's hard
2119.72s - 2122.32s |  to include secrets in your code.
2122.32s - 2124.88s |  So don't have short-access tokens
2124.88s - 2130.55s |  that your library just blindly accepts from a string,
2130.55s - 2150.08s |  but instead for, all right, thank you for that.
2150.08s - 2151.64s |  That was a nice wake-up call.
2153.88s - 2156.16s |  All right, anyways, so yeah,
2156.16s - 2157.48s |  with these hard-coded secrets,
2157.48s - 2158.88s |  what I really think we need to do
2158.88s - 2161.76s |  is make sure to limit the secrets
2161.76s - 2164.40s |  so that they can only be inserted from the environment
2164.40s - 2165.84s |  or from a file on disk,
2165.84s - 2168.00s |  and make it hard to hard-code these secrets
2168.00s - 2170.28s |  inside of an executable in the first place.
2170.28s - 2171.88s |  Now, again, you can have exceptions.
2171.88s - 2174.10s |  You can have it so a customer can opt out
2174.10s - 2175.98s |  from the secure default,
2175.98s - 2182.13s |  but we need to make sure that the secret default is secure.
2182.13s - 2185.69s |  So what about remediating these vulnerabilities?
2185.69s - 2188.53s |  Well, remember, for dangling records at a high level,
2188.53s - 2191.37s |  it's gonna be hard to contact every single host
2191.37s - 2193.89s |  of every 60,000 dangling domain
2193.89s - 2195.69s |  that I was able to discover.
2195.69s - 2199.49s |  What we really need is a way to tie ownership to DNS records.
2200.25s - 2201.37s |  And we need to do this across the industry
2201.37s - 2205.83s |  because of that multi-cloud approach.
2205.83s - 2209.75s |  Now, for secrets, this is where it gets really interesting.
2209.75s - 2212.33s |  So I went ahead and asked a bunch of organizations
2212.33s - 2214.49s |  that I found secrets for, including GitHub,
2214.49s - 2217.01s |  including AWS, including OpenAI,
2217.01s - 2219.01s |  whether I could report secrets to them
2219.01s - 2221.17s |  and they could revoke them automatically.
2221.17s - 2223.97s |  Now, GitHub has that program for scanning secrets
2223.97s - 2225.85s |  on their platform already.
2225.85s - 2228.07s |  Remember, if you actually go ahead and post a,
2228.07s - 2231.85s |  for example, OpenAI access key on a public repository,
2231.85s - 2235.43s |  that access key will be revoked within a few minutes.
2235.43s - 2237.03s |  And what I was curious was, hey, GitHub,
2237.03s - 2240.35s |  can I please use this mechanism you already have?
2240.35s - 2242.75s |  Well, unfortunately, they said no.
2242.75s - 2246.47s |  And in fact, several providers said no, like AWS,
2246.47s - 2249.45s |  despite the fact that they already had given this mechanism
2249.45s - 2251.47s |  to GitHub and despite the fact
2251.47s - 2254.51s |  that an attacker could access the mechanism
2254.51s - 2258.35s |  by posting a public git or public commit.
2258.35s - 2260.75s |  Now, one exception to this was OpenAI,
2260.75s - 2263.19s |  who immediately responded with an endpoint
2263.19s - 2265.47s |  for reporting these keys and allowed me
2265.47s - 2267.35s |  to automatically revoke the keys
2267.35s - 2269.85s |  that I discovered in the wild.
2269.85s - 2272.51s |  But what do we do about everyone else?
2272.51s - 2274.59s |  So the problem with these secret keys
2274.59s - 2277.55s |  is that the impact is far, far, far greater
2277.55s - 2279.59s |  than dangling DNS records.
2279.59s - 2280.95s |  In fact, we just saw some
2280.95s - 2282.55s |  of the world's largest organizations
2282.55s - 2285.19s |  and there were several more impacted.
2285.19s - 2287.07s |  I didn't feel comfortable releasing this work
2287.07s - 2288.87s |  without at least some stopgap
2288.87s - 2292.67s |  until these cloud providers could take the secure default.
2292.67s - 2296.23s |  So what I actually did was I developed a mechanism
2296.23s - 2299.45s |  that used GitHub's mechanism anyway
2299.45s - 2303.41s |  for revoking these secrets because they said no,
2303.41s - 2304.59s |  but I don't care.
2305.63s - 2308.39s |  But yeah, so what I did was I have this system now
2308.39s - 2311.23s |  where whenever new secrets are discovered,
2311.23s - 2313.57s |  I'll go ahead and create a gist
2313.57s - 2315.11s |  and the way I create this gist
2315.11s - 2319.23s |  is by automating the entire GitHub login process
2319.23s - 2321.55s |  and then just am using an UI endpoint
2321.55s - 2322.99s |  for creating a public gist.
2322.99s - 2325.59s |  And this way, it'll actually trigger
2325.59s - 2327.55s |  the GitHub secret scanning mechanism
2327.55s - 2330.03s |  that they could have given me direct access to anyway.
2330.03s - 2337.37s |  So yeah, anyways.
2337.37s - 2338.61s |  Now, what's really cool about this
2338.61s - 2341.73s |  is that almost every secret that you saw listed
2341.73s - 2343.17s |  in the previous section,
2343.17s - 2345.01s |  a lot of them are gonna be revoked.
2345.01s - 2347.05s |  There's an exception to that though.
2347.05s - 2349.49s |  One of the largest providers which did have leaked secrets
2349.49s - 2351.01s |  was AWS.
2351.01s - 2353.67s |  Now, AWS takes an interesting approach.
2353.67s - 2355.81s |  When you post your AWS access key
2355.81s - 2358.99s |  on a public GitHub commit or post,
2358.99s - 2362.53s |  what they do is that they'll create a support case for you
2362.53s - 2366.09s |  and restrict to write access using that key.
2366.09s - 2367.13s |  I found that kind of interesting.
2367.13s - 2369.81s |  So what's really happening is AWS
2369.81s - 2371.49s |  is aware of these secret keys,
2371.49s - 2374.71s |  but they're choosing not to revoke them for some reason.
2375.73s - 2377.29s |  Yeah, that's an interesting one.
2377.29s - 2381.25s |  So effectively, if you find a leaked AWS access key
2381.25s - 2384.77s |  on GitHub, you can still use that key to read S3 buckets,
2384.77s - 2389.33s |  read RDS database data, to read download files from S3.
2389.33s - 2392.41s |  You know, I remember I looked at a AWS key last weekend
2392.41s - 2395.01s |  for a casino that was dealing,
2395.01s - 2400.01s |  well, alleged to deal with over $1 billion of bets a month.
2400.57s - 2402.37s |  And I was like, okay, wait a minute.
2402.37s - 2403.33s |  Was this reported?
2403.33s - 2404.71s |  We should get this revoked.
2405.41s - 2406.79s |  But in reality, what happened was
2406.79s - 2409.23s |  AWS created this support case.
2409.23s - 2410.75s |  The customer never saw it
2410.75s - 2413.39s |  because the support email was sent
2413.39s - 2415.31s |  to their generic billing account.
2415.31s - 2417.35s |  You know, a lot of people, a lot of enterprises
2417.35s - 2420.59s |  set up an AWS account and use a generic billing email
2420.59s - 2421.91s |  that no one really looks at.
2421.91s - 2423.83s |  And so the support case was ignored,
2423.83s - 2426.31s |  and this key is still active today.
2426.31s - 2427.63s |  You know, it's disappointing
2427.63s - 2430.15s |  because I don't know what more I can do for my shoes.
2430.15s - 2431.31s |  You know, I've created a mechanism
2431.31s - 2433.87s |  that can help automatically revoke most of these keys.
2433.87s - 2435.75s |  But what do we do about keys
2435.75s - 2438.51s |  that the provider doesn't take action on?
2438.51s - 2439.91s |  And so this is where I really think
2439.91s - 2441.75s |  providers need to switch up is,
2441.75s - 2444.83s |  number one, if someone's secret key,
2444.83s - 2447.39s |  you have both components, is on the internet
2447.39s - 2451.31s |  and you know about it, you need to revoke that immediately.
2451.31s - 2453.75s |  I mean, it's crazy to me to think that even on GitHub,
2453.75s - 2455.59s |  if you post your AWS access key,
2455.59s - 2457.51s |  that's not gonna be automatically revoked.
2457.51s - 2460.31s |  Every other provider I looked at does automatically revoke.
2460.31s - 2464.23s |  Google Cloud revokes, Slack revokes, OpenAI revokes.
2464.23s - 2470.49s |  The largest cloud provider by market share does not revoke.
2470.49s - 2473.89s |  Now, if you're interested in starting this sort of research
2473.89s - 2477.05s |  yourself, what I'd focus on is breaking down
2477.05s - 2479.37s |  the traditional methods of finding vulnerabilities.
2479.37s - 2481.77s |  So with dangling domains, that was checking
2481.77s - 2483.93s |  if the DNS record is actually pointing
2483.93s - 2486.53s |  at a uncaptured IP address.
2486.53s - 2489.85s |  And with secrets, it was trying to find
2489.85s - 2493.05s |  those secret patterns in a diverse data source.
2494.01s - 2496.57s |  So in this case, we used virus scanning platforms,
2496.57s - 2498.93s |  but you can use a similar methodology
2498.93s - 2503.37s |  against a larger set of vulnerability classes.
2503.37s - 2505.69s |  And what you really wanna do is correlate those steps
2505.69s - 2507.69s |  with these large data sets,
2507.69s - 2509.69s |  regardless of their intended usage.
2511.29s - 2513.73s |  Thank you so much for coming out to this talk.
2513.73s - 2521.19s |  What a fun time.
2521.19s - 2525.58s |  We do have a few minute for questions.
2525.58s - 2530.03s |  Oh, we apparently don't have microphones, that's...
2530.03s - 2531.39s |  All right, yeah, if you have questions,
2531.39s - 2534.55s |  feel free to come up and we can have a chat over on stage.
2534.55s - 2536.51s |  Thank you so much for coming out to this talk.
2536.51s - 2537.35s |  What a fun time.
2537.35s - 2539.87s |  And yeah, I look forward to working with these providers
2539.87s - 2541.51s |  to address these vulnerabilities.


