# Media

url: https://www.youtube.com/watch?v=fqFKbDib8CY
title: DEF CON 32 - Manufacturing Lessons Learned, Lessons Taught - Tim Chase
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=fqFKbDib8CY",
  "title": "DEF CON 32  - Manufacturing Lessons Learned, Lessons Taught - Tim Chase",
  "description": "Manufacturing continues to be a top targeted sector by cyber threat actors, especially by ransomware. Dragos 2023 Year In Review showed that 70% of all ransomware victims were manufacturers. The Global Resilience Federation Ransomware Report shows very similar figures. There are some specific elements that make manufacturing a particularly attractive target for ransomware such as the lack of network security and segmentation, IT compromise that often leads to operational disruption (even if there is not OT network intrusion), manufacturing having tight margins, a lack of a compliance regime, and organizational size all contributing. Manufacturing continues to be a top targeted sector by cyber threat actors, especially by ransomware. Dragos 2023 Year In Review showed that 70% of all ransomware victims were manufacturers. The Global Resilience Federation Ransomware Report shows very similar figures. There are some specific elements that make manufacturing a particularly attractive target for ransomware such as the lack of network security and segmentation, IT compromise that often leads to operational disruption (even if there is not OT network intrusion), manufacturing having tight margins, a lack of a compliance regime, and organizational size all contributing.\n\nWhile manufacturing as a whole lags many other critical infrastructure sectors in aspects of cyber security there is a category that manufacturing has consistently led other industry verticals in, automation and device connectivity in the operational technology domain. Manufacturer\u2019s OT network environments increasingly are set up as a network or hyper connected IIoT devices, where all data goes to the cloud and often comes back from the cloud to offer changes, and all participants have access into the OT network domain allowing manufacturing to push the boundaries of what products are technically possible, what production efficiencies are possible, and how OT environments can scale as never before.\n\nThis has obviously come with downside risks that manufacturers are only now beginning to grapple with and to make meaningful changes to better protect their networks and the gains they have made. Their growing pains can serve as roadmap of what to do and what not to do as many other OT intensive industry verticals are moving very quickly into similar use cases.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1427,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 My name is Tim Chase, and for the better part of a decade, I have supported a number of
4.96s - 10.36s |  different critical and vital infrastructures, primarily by working in what are called information
10.36s - 15.58s |  sharing and analysis centers for a number of different kind of sector-specific ISACs
15.58s - 18.44s |  and ISAUs.
18.44s - 24.04s |  So this talk is not about what ISACs are, and it's not about specifically what the manufacturing
24.04s - 28.84s |  ISAC is, but if you're interested in what ISACs are, what they do, how they kind of
28.84s - 33.00s |  work in the overall sort of information security space, I'd love to talk with you about that
33.00s - 38.88s |  or manufacturing ISAC if you have any questions about that or any other topic after the presentation.
38.88s - 44.20s |  And depending on how quickly I go, there might even be time for Q&A if you guys have any
44.20s - 45.20s |  questions.
45.20s - 50.96s |  So a couple of things about manufacturing before we get going.
50.96s - 54.36s |  Manufacturing is defined by the United States government and some other entities as like
54.36s - 60.44s |  an industry vertical, and I've worked now sort of for manufacturing ISAC and leading
60.44s - 66.52s |  that for two and a half-ish years, and it's the first industry vertical that's not really
66.52s - 67.52s |  a vertical.
67.52s - 68.52s |  It's not a vertical.
68.52s - 72.74s |  It's actually like a horizontal modality that supports every single industry.
72.74s - 79.60s |  It's not discrete like oil and gases or finances or, you know, electrical or something.
79.60s - 85.68s |  And so it's kind of hard to generalize, and because of the size and type of manufacturing,
85.68s - 90.12s |  it's also hard to kind of generalize manufacturing.
90.12s - 94.52s |  With that said, we're going to make some generalizations about manufacturing.
94.52s - 98.16s |  So we're going to start off with the good news about manufacturing.
98.16s - 103.52s |  The good news is that manufacturers are really, really good at manufacturing, and I know that
103.52s - 104.52s |  goes without saying.
104.52s - 106.36s |  You're like, well, yeah, it's their business.
106.36s - 110.44s |  But I think that all of us could think of like other industries that they're not good
110.44s - 112.04s |  at their jobs.
112.04s - 114.64s |  But manufacturers are really great at manufacturing.
114.64s - 120.68s |  In fact, in human history, large portions of human history are essentially defined by
120.68s - 124.68s |  technologies that manufacturers created to be better manufacturers.
124.68s - 130.04s |  So whether that's use of water as a power source or steam or now electricity or, you
130.04s - 133.56s |  know, now digitization of the manufacturing space.
133.56s - 138.80s |  All of those were entirely or largely a result of sort of manufacturers wanting to manufacture
138.80s - 144.64s |  more, better, faster, and able to do that, they needed to find and harness new technologies.
144.64s - 150.74s |  So they're really good at not only embracing new technology, but actually creating technology
150.74s - 155.60s |  that didn't exist to facilitate manufacturing.
155.60s - 160.96s |  Now we've moved past the point that, you know, we're using electricity to kind of help automate
161.08s - 166.24s |  and we're using, you know, digital systems to help automate and increase productivity.
166.24s - 171.52s |  But now, manufacturing is moving headlong into that kind of cloud-based infrastructure,
171.52s - 177.40s |  which is heavily, you know, narrow AI and machine learning enabled to do a number of
177.40s - 178.64s |  different things.
178.64s - 187.12s |  I would say that I think about AI in manufacturing kind of the way that I do the Internet circa
187.12s - 189.12s |  1993 to 1995.
189.12s - 190.16s |  We know a few different things.
190.16s - 196.96s |  We know it's going to be a big deal and we already have a number of use cases that we're
196.96s - 199.64s |  using it for and it's phenomenal.
199.64s - 203.92s |  And then the third thing is we have enough, if we're being honest, humility to realize
203.92s - 209.28s |  we don't exactly know where it's going to go and how it's actually going to affect what
209.28s - 210.28s |  we do.
210.28s - 215.72s |  But, so there's sort of some similarities there in terms of new transformative technologies.
215.72s - 220.96s |  So the last thing about manufacturing, and this is actually a positive, I think, overall,
220.96s - 226.08s |  is that manufacturers are their production and profit motivated, right?
226.08s - 232.32s |  It's actually what helps them to focus on and get better at the manufacturing process.
232.32s - 237.68s |  And what I mean by that is that manufacturers, you know, are businesses and manufacturers
237.68s - 243.96s |  think how do I make as many widgets as possible, as fast as possible for the lowest unit cost
244.04s - 245.84s |  per widget as possible.
245.84s - 252.80s |  And so they make decisions based upon that framework and it makes them better manufacturers.
252.80s - 258.76s |  Now, with that being said, there are some downsides to that.
258.76s - 263.88s |  So the last point about how that framework that they use to determine where they're going
263.88s - 269.84s |  to spend resources and what they're going to prioritize, manufacturers are really, really
269.84s - 271.76s |  bad at cybersecurity.
271.76s - 277.28s |  And the reason is, as it turns out, cybersecurity doesn't make widgets.
277.28s - 281.28s |  And so when they're thinking and prioritizing in that framework, I want to make as many
281.28s - 287.88s |  widgets as possible, as fast as possible, as low unit costs as possible, the security
287.88s - 293.72s |  aspect usually loses out in that discussion.
293.72s - 300.12s |  That being said, as we know here, I mean, you're all here at DEF CON, there are consequences
300.20s - 304.52s |  from chronically under-resourcing security in that process.
304.52s - 309.24s |  And I think that a lot of those consequences are sort of coming home to roost for manufacturers,
309.24s - 315.00s |  especially as that attack surface is growing exponentially for them.
315.00s - 319.52s |  And there's just a lot more badness out there that can touch them.
319.52s - 321.98s |  Some of it's not even specifically directed at them.
321.98s - 325.34s |  Some of it is specifically directed at them.
325.34s - 329.22s |  One of those I would say is ransomware.
329.22s - 335.50s |  And there's a few reasons that ransomware operators really, really love manufacturers.
335.50s - 341.38s |  And the victimology is pretty narrow on what they're going after.
341.38s - 350.70s |  Number one, manufacturers' networks are typically flat and not really well segmented.
350.70s - 358.70s |  Number two, they oftentimes utilize enterprise ERP systems that everyone in that organization,
358.70s - 363.34s |  whether they're working in sales in the front office or they're working on the plant floor,
363.34s - 368.90s |  have access to, to see where manufacturing processes are in line and pull down necessary
368.90s - 372.54s |  files for manufacturing process or whatever.
372.54s - 378.62s |  That is a giant vulnerability because it requires, obviously, IT and internet access inside of
378.62s - 380.06s |  the plant floor.
380.42s - 388.38s |  But it's also why a lot of times, if there's only IT intrusions in a ransomware, for instance,
388.38s - 390.70s |  it could be other things as well.
390.70s - 396.46s |  But if you're like me and you read a lot of SEC 8K disclosures, they all kind of sound
396.46s - 404.22s |  the same, but they only ever reference IT compromise, unauthorized access into IT spaces.
404.22s - 409.10s |  But if you read between the lines and you see that there's been operational or manufacturing
409.10s - 411.02s |  compromise, you're like, well, how is that possible?
411.02s - 412.70s |  They only got into the IT.
412.70s - 414.02s |  Why is your plant down?
414.02s - 418.42s |  Why are you not producing furniture or Clorox bleach products or whatever?
418.42s - 424.06s |  And the answer is that the reliance on that ERP system, they can't generate orders.
424.06s - 428.02s |  They can't pull down the necessary files to load into manufacturing processes.
428.02s - 434.86s |  So compromising just an IT system has direct OT effects.
434.86s - 441.98s |  And because it's stopping production, even if it's only in the IT environment, manufacturers,
441.98s - 444.10s |  number one, pay quickly.
444.10s - 450.18s |  Number two, they're targeting sort of mid-level enterprises, manufacturers where they're large
450.18s - 454.66s |  enough to be able to pay a decent-sized ransom, but they're not large enough to have really
454.66s - 458.54s |  sophisticated sort of enterprise security solutions and the like.
458.54s - 464.34s |  So it's this kind of sweet spot that ransomware operators take advantage of routinely.
464.34s - 470.96s |  And so for the last two years especially, we track our organization and the parent company
470.96s - 473.54s |  that we're a part of, the Global Resilience Federation.
473.54s - 474.54s |  You can go.
474.54s - 478.90s |  I think the most recent semiannual ransomware report will be out in about a week.
478.90s - 481.86s |  It's free on our website, grf.org.
481.86s - 485.94s |  But our analysts, it's pretty time-consuming because our analysts have to actually go out
485.94s - 490.54s |  and scrape all the Torque leak sites about the data on the ransomware and the victims.
490.54s - 491.74s |  But we collect a lot of data.
491.74s - 494.62s |  We've got four years of data.
494.62s - 498.50s |  And just a few pieces of data that we collect are, number one, who the ransomware operator
498.50s - 500.92s |  was that had the victim.
500.92s - 502.50s |  Number two, who the victim was.
502.50s - 507.50s |  Number three, geographically, at least headquarter-wise, where the victim is located.
507.50s - 511.50s |  And number four, what industry that victim is.
511.50s - 515.76s |  And so we're able to kind of parse the data and see trends and the like.
515.76s - 519.50s |  And that's how we know ransomware is by far the most targeted industry.
519.50s - 523.82s |  I think a lot of different organizations, security researchers and the like, have said
523.82s - 528.62s |  that roughly speaking, about between two-thirds and three-quarters of all ransomware incidents
528.62s - 530.60s |  are focused at manufacturers.
530.60s - 533.84s |  So they really have a giant target on their back.
533.84s - 539.06s |  This is, I think, one of the things that, as we'll go and see, is actually helpful because
539.06s - 544.18s |  they had to learn some of the lessons of the bad decisions they were making to start making
544.18s - 546.42s |  good decisions.
546.42s - 549.10s |  So where do we go from here?
549.70s - 553.70s |  It's a pretty bad place, the security landscape.
553.70s - 559.14s |  I want to make a caveat here and say that, like I said, we couldn't generalize manufacturers.
559.14s - 563.34s |  There are manufacturers that are literally the most sophisticated from an operational
563.34s - 569.38s |  cyber perspective down to people that are maybe really large companies but are doing
569.38s - 570.70s |  almost nothing.
570.70s - 572.06s |  So it runs the gambit.
572.06s - 579.38s |  But again, we're going to kind of talk about generalities that I see.
579.38s - 583.02s |  Number one is that manufacturing is a little bit different.
583.02s - 587.18s |  And I know that I'm speaking on behalf of ICS Village and manufacturing does run a lot
587.18s - 590.42s |  of industrial protocols and the like.
590.42s - 597.66s |  But manufacturing is a little bit different in general because, well, first, in this space,
597.66s - 603.06s |  whether it's here at DEF CON or S4 or something, we hear a lot about IT-OT convergence.
603.06s - 607.38s |  And it's been a sort of buzzword bingo for the last almost 20 years.
607.38s - 612.10s |  The thing is, that term really doesn't apply to manufacturing for the most part.
612.10s - 616.86s |  And the reason is, you can't converge something that was never separated.
616.86s - 622.26s |  And most manufacturing networks were really never separated in a meaningful way, either
622.26s - 624.70s |  physically or logically.
624.70s - 626.46s |  And so that term really doesn't apply.
627.26s - 631.78s |  They're just basically running a network and some of it is used to send emails and some
631.78s - 634.26s |  of it is used on the plant floor.
634.26s - 640.22s |  Again, generalizing, sometimes they're really big, but still, in general, that's commonly
640.22s - 641.38s |  the case.
641.38s - 645.94s |  Number two is the networks themselves are becoming less industrial.
645.94s - 652.26s |  The last presentation was showing that converter from a serial connection that was running
652.26s - 655.38s |  Modbus to an IP connection.
656.30s - 658.14s |  That's very common.
658.14s - 663.58s |  Legacy systems might have one of those dongles that is changing from a legacy protocol and
663.58s - 667.34s |  a serial connection to a more kind of IP-centric network.
667.34s - 669.06s |  But that's the way that things are going.
669.06s - 671.14s |  There's a lot of reasons for that.
671.14s - 675.30s |  Some of those are mainly having to do with the technology leap sort of into the cloud
675.30s - 679.98s |  and AI enablement, meaning that the speed that things need to flow, the data needs to
679.98s - 684.84s |  flow at, and how much data needs to transit that network, you're not going to do that
684.84s - 691.24s |  on simple serial networks.
691.24s - 694.36s |  And I say the networks are becoming less industrial, not the nodes.
694.36s - 697.76s |  At the end of the day, there's still going to be an industrial process going on and they
697.76s - 703.48s |  might have, at least for that thing, some proprietary protocol for the process itself,
703.48s - 707.68s |  but the network on the plant floor, and it could be multiple locations, multiple production
707.68s - 715.12s |  facilities, they're not like kind of older school serial networks.
715.12s - 717.62s |  That is a challenge.
717.62s - 719.36s |  It makes it easier to build out.
719.36s - 722.28s |  And he was also talking about the use of Wi-Fi in industrial applications.
722.28s - 724.88s |  That is becoming increasingly common.
724.88s - 728.28s |  Also, those aren't necessarily the best secured.
728.28s - 732.48s |  The thinking that they have is like in the same way that people used to think about industrial
732.48s - 737.60s |  networks and why they didn't do security in it at all was, well, the network sort of ends
737.72s - 738.72s |  at the fence line.
738.72s - 743.16s |  So we don't have to worry about securing that inside, but that's not true.
743.16s - 745.16s |  We all know that that's not true.
745.16s - 753.56s |  Okay, so manufacturing is sort of, everyone is focusing now on manufacturing from a sales
753.56s - 758.24s |  and vendor perspective, solutions providers, all of a sudden, my phone rings a lot more
758.24s - 763.26s |  from those people that want to discuss manufacturing because they're really sweet on manufacturing.
763.26s - 768.30s |  But one of the things we need to consider, because manufacturing is different, is that
768.30s - 774.58s |  any of those solutions, which they do need them, they need to be able to extend to less
774.58s - 776.36s |  industrial applications.
776.36s - 781.30s |  So we have really, and I'm not going to name names, but we all can think of them like so
781.30s - 782.82s |  telepathy out to everyone.
782.82s - 787.86s |  There are really great organizations that have incredible industrial network security
787.86s - 790.62s |  tooling.
790.62s - 796.58s |  And there are really great tools for cloud security, but there's not really something
796.58s - 802.50s |  that's kind of going all the way from base metal to AI-enabled cloud infrastructure.
802.50s - 807.46s |  And so there's seams in that security, even if you implemented all the tools that are
807.46s - 810.26s |  currently available.
810.26s - 815.90s |  And even in that industrial network, the applications and the types of manufacturing that's going
815.90s - 819.42s |  on is becoming, I say less industrial.
819.42s - 824.82s |  It's essentially moving more towards sort of an IT-like landscape where manufacturing
824.82s - 829.50s |  devices are sort of just nodes at the end of an IT network, no different than a printer.
829.50s - 837.42s |  You can send it commands, but it doesn't look like legacy ICS environments.
837.42s - 841.42s |  Number two, I already mentioned that it needs to extend up to sort of cloud environments
841.42s - 847.08s |  to seal off some of those security gaps that we have from tooling from an ICS environment
847.08s - 849.92s |  or a sort of cloud environment.
849.92s - 854.52s |  And then number three, and this is really important, is it needs to extend down to smaller
854.52s - 855.76s |  manufacturers.
855.76s - 860.64s |  Most manufacturers, there are over a hundred thousand in the United States alone, are very
860.64s - 863.76s |  small organizations, very small organizations.
863.76s - 867.24s |  Prior to this, I didn't have enough time to do a site survey and take some pictures for
867.24s - 872.12s |  slides and stuff to make it look pretty, but I was going to go to a manufacturer that they
872.12s - 874.24s |  make cardboard boxes.
874.36s - 878.40s |  Some of them are really intricate in terms of cutting and everything that have multiple
878.40s - 883.22s |  folds and display stands and all that kind of stuff, but they don't have a lot going
883.22s - 885.84s |  on from a security perspective.
885.84s - 890.60s |  Some of that is okay because some of their systems don't really connect directly to IT
890.60s - 894.40s |  networks, but it doesn't, yeah.
894.40s - 899.48s |  It needs, some of these tools need to be able to go down and scale down, not just up.
899.48s - 902.96s |  And then I put in here, don't forget the cyber poor, and that kind of goes back to those
902.96s - 904.72s |  small manufacturers.
904.72s - 912.96s |  Most of my members are large organizations, they're global Fortune 500 or even 100 companies,
912.96s - 917.04s |  but their supply chains are really small.
917.04s - 921.72s |  It gets really small really, really quickly that are their upstream suppliers.
921.72s - 929.54s |  And so at Manufacturing ISAC, we're working currently with Don Capelli, OT CERT, to create
929.54s - 935.22s |  kind of free training and training modules for those organizations completely free of
935.22s - 939.46s |  charge, working with some of the larger vendors to bring them in to get their supply chains
939.46s - 943.38s |  to try to reach some of those organizations that need the help.
943.38s - 947.22s |  Some of them don't know they need the help, but to try to connect them to those resources.
947.22s - 953.06s |  So maybe next year I can let you know how that endeavor goes.
953.06s - 957.86s |  So we've talked about where manufacturing was.
957.86s - 964.62s |  They've always been sort of a global leader in technology, not only adoption, but creation
964.62s - 966.30s |  of new technology.
966.30s - 969.46s |  And they've sort of fallen behind in that security.
969.46s - 974.34s |  And I think that it's because they haven't understood that that security is actually
974.34s - 976.18s |  part of their manufacturing process.
976.18s - 979.18s |  It needs to be thought of as part of the process itself.
979.18s - 983.70s |  And every single business does many, many different things that may not be, as you think
983.70s - 990.30s |  about it, you know, discreetly aligned with that business and what you do, but you still
990.30s - 991.30s |  have to do it anyway.
991.30s - 993.74s |  You know, you have like HR folks and you do payroll.
993.74s - 997.42s |  Well, that's not making potato chips if you make potato chips, but it's still an important
997.42s - 1000.14s |  process nonetheless.
1000.14s - 1005.26s |  So here's why I think that, you know, manufacturers will go from cyber deniers to security high
1005.26s - 1006.26s |  flyers.
1006.26s - 1010.56s |  It's because generally speaking, it's in their DNA to innovate.
1010.56s - 1014.92s |  They just haven't recognized yet that that needs to be a part of what they need to do.
1014.92s - 1020.64s |  And this ultimately is sort of that top line, that executive leadership.
1020.64s - 1024.56s |  When they get the idea that this is something, this is the innovation they need to do to
1024.56s - 1025.56s |  make things work.
1025.56s - 1030.12s |  So if they're looking at the new hotness of whatever that cloud infrastructure is going
1030.12s - 1034.08s |  to help them do to move to the next level, if they understand that a part of that is
1034.08s - 1040.24s |  security and that that security needs to move up and down, that buy-in is going to
1040.24s - 1047.80s |  potentially allow them to leapfrog over some other industries that are, well, they're currently
1047.80s - 1054.40s |  seen as more security mature in their ICS industrial programs.
1054.40s - 1058.88s |  I actually think that this is basically the core, the heart of the talk.
1058.88s - 1064.40s |  I actually think that manufacturing, while they're doing a terrible job right now, if
1064.40s - 1070.28s |  I come back in a year where currently there are not tools that do all of those things
1070.28s - 1072.68s |  that I just talked about, I think there will be.
1072.68s - 1078.32s |  And I think that the manufacturers themselves will be some of the ones to, at least in partnership
1078.32s - 1084.08s |  with new vendors or on their own, will actually create those tools.
1084.08s - 1089.84s |  And then as they mature and utilize those tools and that process long enough, where
1089.84s - 1094.72s |  other industries that are in that ICS environment that are thinking about and want to use some
1094.72s - 1100.00s |  of those tools and want to move into a cloud environment, they're sort of fence sitters
1100.00s - 1103.48s |  and they're going to wait and watch to see what happens to the manufacturers.
1103.48s - 1105.76s |  Let them be the canaries in the coal mine.
1105.76s - 1110.24s |  And when nothing bad happens, you're going to start to see that they're going to adopt
1110.24s - 1112.66s |  that type of technology in the future, I believe.
1112.66s - 1115.08s |  So check back with me on that.
1115.08s - 1117.70s |  So it all starts with the executive leadership.
1117.70s - 1119.06s |  They're the ones that steer the ship.
1119.06s - 1122.06s |  They're the ones that do the resourcing.
1122.06s - 1126.42s |  And they have a couple of things that are pushing them.
1126.42s - 1132.98s |  Number one is that they're looking at what's happening currently inside of the manufacturing
1132.98s - 1133.98s |  space.
1133.98s - 1139.02s |  They're looking at their competitors and their vendors and suppliers getting popped every
1139.02s - 1140.02s |  single day.
1140.34s - 1146.10s |  Oftentimes with ransomware, sometimes other, but they're being affected.
1146.10s - 1151.00s |  And as a result, they have to understand that the crosshairs are on them too.
1151.00s - 1155.18s |  So it kind of focuses their attention.
1155.18s - 1159.10s |  That being said, I think that generally speaking, the meetings that I have with a lot of those
1159.10s - 1166.90s |  executives, my opinion is that most of them are not necessarily thinking correctly about
1166.90s - 1168.62s |  the decisions they've made.
1168.62s - 1173.74s |  They don't actually understand the risks that they're accepting in the business, not
1173.74s - 1176.22s |  doing something.
1176.22s - 1177.22s |  That's changing now.
1177.22s - 1180.10s |  I think they understand.
1180.10s - 1181.10s |  I want to go over there.
1181.10s - 1183.54s |  I've been going over there after this.
1183.54s - 1187.38s |  I think they're understanding now how much risk they're accepting by not doing certain
1187.38s - 1188.38s |  things.
1188.38s - 1190.72s |  So that's one of the things that's changing.
1190.72s - 1197.08s |  Number two, it doesn't hurt that there are new sort of compliance and regulatory requirements
1197.08s - 1199.68s |  on them that also are focusing their attention.
1199.68s - 1201.36s |  So it's not new.
1201.36s - 1207.52s |  It's new-ish, but SEC requirements that require them to have certain officers in their company
1207.52s - 1213.00s |  that have certain roles for information security and cybersecurity.
1213.00s - 1219.08s |  The new CERCIA Act is going to change some things too, because now they're going to have
1219.08s - 1222.00s |  to report a lot of the things that they didn't before.
1222.00s - 1228.72s |  I also see that some of the more traditionally cyber-mature industries, a lot of that talent
1228.72s - 1230.72s |  is moving to manufacturing.
1230.72s - 1234.92s |  So on most of the calls, 70% of the time, one of those people who's leading that security
1234.92s - 1239.80s |  program, a CISO or someone else, is coming from finance or someplace else that has a
1239.80s - 1243.16s |  more mature process.
1243.16s - 1246.48s |  So the next question is, do I see any change now?
1246.48s - 1249.12s |  Because I'm telling you what I think will happen in the future, but is there anything
1249.12s - 1250.60s |  happening now?
1250.60s - 1254.16s |  The answer is kind of, maybe some glimmers.
1254.16s - 1256.56s |  This is messy data, so you don't need to look at the data.
1256.56s - 1258.72s |  The colors are the only thing that matter, really.
1258.72s - 1260.68s |  But I told you about that ransomware report.
1260.68s - 1265.32s |  So in our semi-annual and annual ransomware report, the weekly ransomware report is more
1265.32s - 1268.36s |  tactical, just a lot more data on the victims.
1268.36s - 1272.04s |  The semi-annual and the annual are sort of higher level and talk about trends in that
1272.04s - 1273.44s |  landscape.
1273.44s - 1278.40s |  And so I had to write my portions for the communities that I lead, including manufacturing.
1278.40s - 1279.40s |  So this is manufacturing.
1279.40s - 1281.36s |  So I'm just kind of dumping some of the data.
1281.36s - 1286.80s |  And this was whether or not, for each one of those weeks, whether manufacturing was
1286.80s - 1288.36s |  the most targeted sector.
1288.36s - 1289.36s |  Okay?
1289.36s - 1293.56s |  So every single week, we got the top sector targeted, right?
1293.56s - 1298.72s |  The rightmost column was, well actually, the first four or five columns are like this past
1298.72s - 1300.32s |  six months that I was writing on.
1300.32s - 1304.56s |  But then I was like, well, I should probably look at the previous six months too, to kind
1304.56s - 1307.14s |  of do a compare and contrast over that time period.
1307.14s - 1313.32s |  So the rightmost column is the Q3, Q4 of 2023.
1313.32s - 1318.94s |  And then the other column that's kind of in the center is the first six months, Q1, Q2
1318.94s - 1320.76s |  of 2024.
1320.76s - 1327.70s |  There's a lot more red in the far right hand column, the second half of 2023, and a lot
1327.70s - 1336.74s |  less red in the first half of 2024, 40% less times they were the most targeted sector for
1337.34s - 1342.82s |  that week, and a 20% overall reduction in the amount of victims.
1342.82s - 1346.42s |  Now, I think it's too soon to tell whether this is like a real change.
1346.42s - 1352.70s |  I also would note that we saw that they were, the victims themselves were moving down in
1352.70s - 1357.02s |  organizational size, which means that some of those midsize organizations that do have
1357.02s - 1364.74s |  means in order to improve their situation are doing that, and they're becoming not victims.
1364.74s - 1366.58s |  So anyway, there's my glimmers of hope.
1366.58s - 1370.90s |  I've got one minute, and so I don't know if that's long enough for Q&A, but we can
1370.90s - 1373.10s |  try if anyone has a question.
1373.10s - 1378.68s |  I can't see anyone.
1378.68s - 1379.68s |  No questions?
1379.68s - 1395.91s |  A question.
1395.91s - 1398.95s |  How to make cybersecurity sexy for manufacturing?
1398.95s - 1402.83s |  I honestly don't think we can, because at the end of the day, they're business.
1402.83s - 1407.07s |  They're making decisions based upon business, but I think that that's a strong enough case
1407.07s - 1415.78s |  for them to do the right thing, I think, but we'll see.
1415.78s - 1419.74s |  Maybe one more, and then I'll jump down, but we can talk afterwards.
1419.74s - 1420.74s |  All right.
1420.74s - 1421.74s |  Well, thanks, everybody.
1421.74s - 1425.50s |  I want to go see what's next door.


url: https://www.youtube.com/watch?v=kGvU_MuxZ2c
title: DEF CON 32 - Introduction to IPv6 - Denis Smajlović
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=kGvU_MuxZ2c",
  "title": "DEF CON 32 - Introduction to IPv6 - Denis Smajlovic\u0301",
  "description": "Most of the Internet today is running on a legacy version of the Internet Protocol: IPv4. Despite of this, the number of engineers, especially in security, who know how to use IPv6 is relatively low. In this talk we take you through why today\u2019s Internet does not live up to its original vision, take you back to the past to show you what the IPv4 Internet used to look like, and, through this, reveal the secrets that will allow you finally understand IPv6.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1518,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 It is now the top of the hour. Good morning. And now we have, um, our second talk of the day,
9.54s - 14.54s |  our second of four, uh, sponsored by the packet hacking, the packet hacking village. And
17.38s - 22.38s |  we are honored to have Dennis Smilovich, uh, on IPv6. Dennis, take it away.
23.38s - 28.38s |  Thank you. Hi. Yeah, as Ming said, my name is, uh, Dennis Smilovich. I'm a
32.78s - 36.18s |  principal security consultant at Nova Information Security based in San Francisco,
36.18s - 40.66s |  California. And so IPv6 was something that I used to struggle with a lot. I've seen
40.66s - 43.52s |  when working with different clients that it's a general thing in the security
43.52s - 47.62s |  community that it's kind of this thing that's hard to understand and we prefer
47.64s - 52.14s |  keeping our infrastructure on the, like, legacy IP version, which it actually is,
52.14s - 56.22s |  uh, when you're working with IPv4. And so when going through this process of
56.22s - 61.36s |  wanting to understand IPv6, what really happened was that, um, I, I, I realized
61.36s - 64.90s |  after going through everything that, uh, the reason that it was so hard is that
64.90s - 70.56s |  because over the years, IPv4 has gotten so many like extensions and natting and
70.56s - 74.16s |  other technologies that you're putting in place that is, they're making the
74.18s - 78.98s |  internet work, but really they're abstracting from what was actually intended. And
78.98s - 83.12s |  so when, when understanding IPv6, what we really need to do is to dial back,
83.12s - 87.62s |  understand IPv4 and from that it's really easy to jump the next step because then
87.62s - 92.80s |  IPv6 is just a couple of more bits and a different way to write things. Um, so
92.80s - 97.80s |  yeah, I hope, uh, this is gonna be useful to you. So, um, with IPv4 all of my
98.36s - 104.52s |  knowledge had come from practical use and that boiled down to something like the
104.52s - 109.46s |  following. And so this might also be the case for some of you. My understanding was
109.46s - 114.80s |  that this was an IP address, which it also is, and that the subnet mask is probably
114.80s - 119.80s |  255.255.255.0, but you know, only DHCP really knows. And the last one was that the
122.20s - 127.78s |  default gateway was the same IP as my IP, but just with a one at the end. So,
128.26s - 132.72s |  these are not like set in stone. They're, that, that's not actually how things work,
132.72s - 136.96s |  but it's so close to like the configuration that you see most of the times that you can
136.96s - 142.24s |  probably wing it by doing something like that. And so that continued on to being that an
142.24s - 147.24s |  IP address is something, a private IP address is one that starts with 192.168.something,
149.64s - 154.38s |  that's something, or 10.something, that's something, that's something. And I didn't
154.38s - 158.96s |  really understand why, I just knew that like, that was probably a private IP address and
158.96s - 163.96s |  the rest was the internet. And so the, this configuration that I'm showing up here, it's a
166.56s - 172.10s |  fine way to do it. Now, this, this is not gonna work if we're working with a network
172.10s - 177.88s |  that's not like very standard or what we see in like all our home routers. And that's
177.88s - 182.44s |  where, you know, it becomes a problem and we try to set this up and then the network
182.44s - 187.38s |  doesn't actually work. Um, so specifically this configuration is limited to exactly
187.38s - 193.56s |  250 free client devices. And so you'll pretty quickly outgrow that for a private network. But
193.56s - 199.62s |  let's take a look at what these, at what these numbers actually mean. Um, so again, this
199.62s - 204.64s |  is an IP address. It consists of 4, we'll call them fields for now. 1, 2, 3, 4. And they
204.88s - 209.88s |  each can have a value between 0 and 255, giving us 256 possibilities for each field. And
212.98s - 216.92s |  now each of those numbers, they actually represent a binary value. We know that that's how
216.92s - 221.92s |  computers work. And so to represent 256 bits, uh, 256 possibilities in binary, you need 8
224.36s - 229.36s |  bits. And so every one of the fields, um, is 8 bits. And that's what's called an octet.
229.66s - 234.66s |  Like we have 1 octet, 2 octets, 3 octets, 4 octets. And that gives us 32 bits. Every IPv4
238.56s - 243.56s |  address is 32 bits and that's full stop. So next up is the subnet mask. Here we have
244.74s - 250.14s |  255.255.255.0 which is a very common configuration as I mentioned in like most of our
250.14s - 255.78s |  home routers. Um, and so what the subnet mask actually does is that it makes your computer
255.80s - 260.14s |  understand where to send a packet. If I need to send a packet to another machine that's on the
260.14s - 267.08s |  same network as me, on the same WiFi or behind the same router, it's in the same LAN, um, I
267.08s - 272.26s |  need to send it out on that. But if I want to send a packet somewhere else, a server on the
272.26s - 276.56s |  internet for instance, I can't reach that. And so I have to send it to my router. But there
276.56s - 280.52s |  needs to be some kind of mechanism where the computer can distinguish whether the packet
280.54s - 286.38s |  goes one way or the other way. And that's what the subnet mask does. Um, so if we convert this
286.38s - 291.38s |  to binary, what we see, I didn't have to use a calculator for this by the way. Um, we see
294.22s - 299.56s |  that this is what the subnet mask becomes and so part of the reason why subnet masks can be a
299.56s - 305.34s |  bit like intimidating to understand is because 255.255.255.0 doesn't really mean
305.34s - 309.44s |  anything. It's only when we look at the binary representation that we can understand what the
309.46s - 314.70s |  computer is actually doing. So let's take a look at that. On top is the IP address of my
314.70s - 320.40s |  machine and on the bottom is the IP address that I want to speak to. And so in between those, we
320.40s - 325.68s |  put the subnet mask. And so basically what the computer does is that it takes the, the
325.68s - 331.52s |  subnet mask, it looks at it, if there's a one, the top one and the bottom one have, have to
331.52s - 336.96s |  match. So if we look at the first ductet of the subnet mask, all of the first eight bits in
336.98s - 342.92s |  both IP addresses have to match. If they do match, the packet is destined for our local network.
342.92s - 347.52s |  If they don't match, we have to send it off to someone else who can figure out how to get the
347.52s - 353.50s |  packet where it needs to be. Um, so we take a look at the first, they have to match. All first
353.50s - 359.14s |  eight bits match. The second ductet, okay, they're all ones, so they all have to match. We look
359.14s - 364.38s |  at the two addresses, they all match. The third ductet of the subnet mask are, are all ones, so
364.40s - 368.34s |  they all have to match. And we look at the source address, my IP address and the
368.34s - 373.34s |  destination address. Um, and they also match. And so for the last ductet of the subnet mask,
376.62s - 381.68s |  after checking all of them, we see that they don't actually have to match, which is very
381.68s - 387.26s |  convenient because they, they don't match. So, uh, that's fine. This packet is destined for my
387.26s - 393.90s |  local network, so I can just send it out on the network. Um, but if we change that, I've
393.92s - 398.66s |  changed the destination address to the address that Google.com was resolving to at one point
398.66s - 404.26s |  when I made this presentation. Um, and so when we look at this, already from the beginning, we
404.26s - 411.04s |  see that the, our subnet mask says that if a packet is destined for the local network, all of
411.04s - 416.04s |  the bits in the first ductet have to match. And we see that that's not the case. So we already
416.04s - 422.22s |  know by just checking the first one, um, that this packet is not destined for the local
422.24s - 427.48s |  network. And so because of that, we send it to the default gateway, which is the last
427.48s - 434.48s |  parameter that we, we configure. And so I'm going to do something that's a little bad. Um, I'm
434.48s - 439.92s |  going, gonna go back to the previous slide and I'm gonna remove these so that we only have the
439.92s - 445.72s |  subnet mask left. And I know that I just told you how all of this works, but we don't really
445.80s - 450.80s |  need it anymore. So because subnet masks are confusing, uh, when there's a much, much shorter
453.60s - 458.58s |  way to actually write this. If you look at the, the binary representation here, it's very
458.58s - 464.08s |  simple. It's a bunch of ones and then it's a bunch of zeros. And so in modern network, um, the,
464.08s - 468.92s |  the ones and the zeros in the subnet mask, they have to be contiguous and they always have to
468.92s - 475.52s |  start with the ones and then they have the zeros. So the easier way to represent this would be
475.52s - 480.80s |  to just write it in something called CIDR notation. And so the only thing that you do is
480.80s - 486.76s |  that you count how many ones do we have before the zero. In this case, we have eight, we have
486.76s - 494.08s |  16 and we have 24. And so that because of that, instead of writing both our IP address and our
494.08s - 500.08s |  subnet mask, we can just write our IP address in CIDR notation. And by that we're actually
500.12s - 505.12s |  representing both values. So we end up with 192.168.1.27 slash 24. Um, and this is going to
508.76s - 516.33s |  be really important for when we take a look at IPv6. So we get away with that and we still
516.33s - 521.61s |  can't avoid, uh, having to specify a default gateway, but at least this is much, uh, more
521.61s - 528.18s |  condensed and easier to understand and not as redundant as what we were looking at before.
528.22s - 533.64s |  So before we use all this knowledge to learn about IPv6, I just want to quickly go over the
533.64s - 538.72s |  layout of the current allocations of the IPv4 internet. And so that essentially means how
538.72s - 544.96s |  many addresses do we have and what are they used for. So this one is from January 2023. Not
544.96s - 548.60s |  much has changed in the meantime. Um, and what's very interesting is that you can see it's
548.60s - 555.44s |  very, very, very full except for the two boxes up in the corner. Um, it's, it's, it's, it's
555.46s - 562.24s |  taken, um, like they're small, uh, minor allocations within like other networks that you
562.24s - 567.24s |  might still be able to get, uh, from like the regional, uh, internet registries. Um, but it's
569.12s - 574.12s |  full, like this is very, very full. Um, and so, um, then someone might say and have also said
577.46s - 581.96s |  that, oh, but why don't we just repurpose the multicast space or the future use space? Like
581.98s - 587.72s |  they made a very nice convenient block up in the top, right? So why don't we just like use
587.72s - 592.56s |  that? Like it's for future use. So we'll just start like using it. Um, and so the problem is
592.56s - 597.96s |  that a lot of devices have actually have hard coded that, uh, these addresses cannot be used
597.96s - 602.64s |  or some engineers decided that they could use them to do like some internal stuff. And so
602.64s - 606.68s |  using them for actual IP addresses is not, uh, something that can actually be done. Like I
606.70s - 614.04s |  would obviously never name anyone who would do this. Um, but, um, oh, I, I, I might be some
614.04s - 620.72s |  technical glitches or something. Um, that was completely unrelated to what I just said. Um,
620.72s - 626.98s |  so a challenge for all of you, by the way, how many, can someone count how many times USDOD
626.98s - 632.06s |  appears in like the internet routing table? It's a lot of times and it's like, okay, I mean, do
632.08s - 638.12s |  they need that many IP addresses? Uh, what do you say? Fort motor company has a slash eight.
638.12s - 644.82s |  And so from what we talked about before, we know that that means that the first octet is set
644.82s - 650.30s |  like the number before the first dot of the IPV4 address. In this case it would be 19. The
650.30s - 656.90s |  rest is theirs. So every public IPV4 address that starts with 19 belongs to Fort motor
656.92s - 663.52s |  company. Now we have less than 256 of those to share between all the people on the planet. So
663.52s - 668.52s |  Fort, the car company, they own one 223rd of the internet. And that takes me to my point, it's,
672.60s - 677.60s |  it's unsustainable. Um, so after knowing all of this, we know it's 32 bits, like this is an IPV4
680.64s - 686.78s |  address. And you look at it and you're thinking, oh, this would all be solved if we just had
686.78s - 693.02s |  more bits, like double the bits. That's a lot of bits. That's 64 bits. And that would give us
693.02s - 697.86s |  more addresses. Sure. But if we go back and look at the allocations of the IPV4 internet, we
697.86s - 703.94s |  see that not only is it very full, we also see that the same entities appear multiple times,
703.94s - 710.48s |  essentially meaning that people run out and then they grab like another block. And so it would
710.48s - 716.22s |  be really cool if we could make a system that had so many addresses that as soon as we make an
716.22s - 721.76s |  allocation, the person that we've given it to will never outgrow it. Like we'll just give them
721.76s - 728.00s |  so ridiculously many IP addresses that you'll only ever need one block that's gonna show up in
728.00s - 733.00s |  like the internet routing table. And so 128 bits, like it's not double, it's double the double and
735.88s - 742.08s |  it's a lot of bits. And so just to be sure that we're all on the same page, um, when we add a
742.08s - 748.02s |  bit, it's not double the IP address. When we add, when we say, when we go from 32 bits to 64
748.02s - 753.62s |  bits, it's not double the addresses. When we go from 32 bits to 33 bits, it's double the
753.62s - 759.40s |  addresses. So every time we add a bit, uh, 33 bits is double the IPV4 internet, 34 bits is four
759.40s - 765.94s |  times the IPV4 internet, 35, eight times that. And you get the drill, but 128 is like a lot of IP
765.94s - 771.98s |  addresses. I think someone told me that the IPV6 internet is so huge that, uh, there's
771.98s - 778.28s |  addresses enough to represent every grain of sand on, on the globe or every star in the visible
778.28s - 785.62s |  universe or something crazy like that. Um, yeah. So that brings me to our next section. So to
785.62s - 790.72s |  represent 128 bits, we can't use the same system with octets as we used in IPV4 and just
790.72s - 795.72s |  separate them with a dot. It would look horrible. So IPV6 addresses work a bit differently. And
800.28s - 805.40s |  so this is the IPV6 address that again, Google.com resolved to at some point when I was
805.40s - 810.20s |  doing this presentation. And it looks way more confusing than an IPV4 address. And that's
810.20s - 814.80s |  like the big thing that I hear with people in IPV6, like, oh, I look at the addresses and like
814.82s - 821.12s |  my head starts hurting and it's so confusing, which is true. But, um, what is really cool is
821.12s - 825.84s |  that we can start breaking this up and understand how it works. And suddenly it goes from
825.84s - 830.84s |  being like a random string of like colons and letters and stuff to actually making, uh, to
833.28s - 838.32s |  actually making sense. So let's try to take a look at that. Um, first of all, the numbers
838.32s - 843.42s |  there in hex, uh, and we'll get there in a second. Um, but before we go that, I'm just gonna
843.44s - 848.84s |  tell you that we have eight fields and each of them are 16 bits. So you have 16 bits, then a
848.84s - 855.32s |  colon, 16 bits, then a colon, 16 bits, you get the drill. Um, and now, so to make this easier,
855.32s - 860.32s |  we're just gonna have a look at the last field. Um, and so the thing is that we have 16
862.76s - 868.36s |  bits here and we know that the whole IPV4 internet is 32 bits. So actually with only two
868.38s - 873.38s |  fields from an IPV6 address, we can already represent all addresses in the IPV4 internet.
875.66s - 880.66s |  Um, yeah. So, uh, in hex, just to understand hex, we count from zero and then we count up to F.
884.36s - 889.36s |  And so that's done by 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, 0, 1, 2, 3, 4, 5, 6, 7, 8.
899.14s - 904.14s |  9, A, B, C, D, E, F, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F. And it just keeps
911.44s - 916.02s |  counting like that. Um, very important to understand to get like how these addresses are
916.02s - 921.02s |  actually, um, why they look so weird. Okay. Does that make sense? Okay. So, now that we
923.66s - 927.32s |  understand the basics of how hex numbers work, let's try to understand what information we
927.32s - 933.76s |  can extrapolate from the different parts of an address. Um, it's not a rule, but like most
933.76s - 940.70s |  IPV6 addresses consists of a host, that's the first orange part, and then an, uh, sorry, a
940.70s - 945.70s |  host, the blue last part, and the network, the first orange part. Um, and, um, they're often
947.84s - 954.04s |  separated in the middle by 64 bits for the network, here in orange, and, uh, 64 bits for the
954.04s - 959.04s |  host, here in blue. Um, so what we learned about in the IPV4 section, this would be a slash 64,
961.60s - 966.62s |  uh, because the blue part is our network, when we, uh, have an address that has the same first
968.94s - 974.26s |  half as ours, we can send it to our local network, if it's an address outside of that, we have to
974.26s - 979.26s |  send it to someone who knows how to pass it on, uh, usually our default gateway. So, um, the
980.02s - 985.02s |  reason that having 64 bits in the host, uh, in the, yeah, in the host part, um, is actually
990.26s - 995.26s |  that it allows for some pretty cool features. Um, and so, one of them is stateless, address
997.00s - 1002.14s |  auto-configuration, and the other one is privacy extensions. And so I'm just gonna go over
1002.14s - 1007.08s |  what they are, because then we'll actually see how, like, we go from having a network, and
1007.10s - 1012.48s |  then actually setting the last part. Because when you look at an IPV6 address, unless you've
1012.48s - 1017.48s |  set it statically, you're not gonna see 0, 0, 0, 0, 0, 0, 1, A, 0, 0, 0, 0, uh, and, um,
1019.82s - 1025.76s |  counting up like that. Um, so what stateless address, uh, configuration is actually really
1025.76s - 1031.42s |  cool, um, it uses the 64 bits that we have available as the subnet of the network, um, and
1031.44s - 1037.82s |  then it generates an IP address by itself, just from knowing the first network part. And the
1037.82s - 1043.86s |  process is called EUI64, and what it does is that it takes the, uh, 48-bit MAC address of the
1043.86s - 1049.20s |  network interface, and then it expands it to 64 bits. So by that, we have, like, our network,
1049.20s - 1055.00s |  which is the orange part, and then the last part is decided, uh, by calculating it based on
1055.02s - 1060.02s |  the MAC address that the interface has. Um, and so, without doing any DHCP or anything, by
1063.26s - 1068.80s |  just knowing the network that we're working on, our computer can pick an address for itself,
1068.80s - 1073.70s |  because MAC addresses are pretty unique, it's unlikely that it's gonna clash with anything,
1073.70s - 1079.24s |  it's supposed to be unique, and, um, by that, we can just pick an address by ourselves, we
1079.26s - 1085.66s |  don't need to be told what IP address is available on the network. Um, and the second cool
1085.66s - 1090.30s |  feature is privacy extensions, so with pretty much every device on the versions of, on version
1090.30s - 1096.34s |  6 of the internet, um, you're suddenly vulnerable to tracking. If someone, maybe someone
1096.34s - 1101.38s |  realized before that if you have the same MAC address between every network that you move
1101.38s - 1107.82s |  across, you'll be easy, pretty easy to track. And so, uh, that would be pretty, pretty, pretty
1107.86s - 1112.54s |  problematic that, like, you can be correlated across, like, many different networks. Um, so
1112.54s - 1117.54s |  what privacy extensions does is that it works by changing your IP address regularly, um, so we
1119.40s - 1124.42s |  have the 64 bits in our host part, and they just change, like, over time. You visit a website, it
1128.06s - 1132.66s |  uses one address, you visit another website, it uses another address, after some time it
1132.66s - 1138.94s |  changes to a third address, and it, it cycles through them, which is pretty cool. Like, it, it
1138.94s - 1143.94s |  gives, uh, an increased level of privacy. Um, so the reason, um, yeah. And then I just
1152.66s - 1157.36s |  wanted to mention, uh, the last really cool feature about IPv6 is that when, when you have
1157.36s - 1163.00s |  this huge space, when you have 64 bits to work with, um, you do get the thing that, like,
1163.00s - 1168.48s |  suddenly your, the subnets that you're making, the smallest meaningful subnet that you're
1168.48s - 1173.92s |  making, 64 bits, which is very standard, um, you can make them smaller, but, like, you make a
1173.92s - 1179.96s |  64-bit subnet, and suddenly it can contain pretty much an endless amount of addresses. Like, if
1179.96s - 1185.62s |  you're working with IPv4, you have to decide, okay, do we want this network to be a slash 64?
1185.62s - 1191.36s |  Then we have 250 free addresses that can join that network. With IPv6, you just always do a
1191.36s - 1196.36s |  slash 64. Did I say 64 the other time? Yeah. With IPv4, uh, you'll usually make a slash 24
1199.60s - 1205.68s |  network for your home network that limits it to 250 free addresses. Um, and then, like, if
1205.68s - 1209.68s |  you're an enterprise setting or something, you need to start making address plans to make sure
1209.68s - 1214.02s |  that there will be enough addresses, uh, considering what it is that you want to do, and
1214.02s - 1217.66s |  then maybe you get an office in the future, and then suddenly, ah, it doesn't fit into the
1217.68s - 1222.26s |  address plan, and then you're kind of screwed because you're, you're out of addresses. With
1222.26s - 1228.44s |  IPv6, you always, you, you can always make a slash 64 subnet, and you basically are able to
1228.44s - 1233.34s |  put in, there, there's not a limit of 250 free or however many you've specified when you
1233.34s - 1238.78s |  designed a network. Um, you can just have pretty much an endless amount of machines be on
1238.78s - 1247.92s |  that network, which is a pretty cool feature. So, um, now that you know how to read an IPv6
1247.92s - 1252.76s |  address, looking at just, like, the same plain thing as we did before should hopefully be
1252.76s - 1258.80s |  easier, um, and, and hopefully, also, you know, not just easier to understand, but also easier
1258.80s - 1264.36s |  to remember, uh, because if you work in the same environment, uh, it's very likely that the
1264.36s - 1271.64s |  first 64 bits are going to be the same. Uh, we know that, like, uh, depending on where you are
1271.64s - 1277.40s |  geographically, or where you got your IP addresses from, the first part of the, the, the
1277.40s - 1283.40s |  range that you got is usually going to be the same. So, as you work with this, things are going
1283.40s - 1289.44s |  to be pretty, uh, pretty familiar. Um, and then you know the first part, and then the last part
1289.44s - 1293.80s |  is just up to you when you design the network. It's either going to be decided by the host
1293.80s - 1298.80s |  itself, or maybe you set it statically, and it actually becomes something like 0, 0, 0, 0, 0, 0,
1298.80s - 1307.12s |  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1. Um, so, uh, let's just see how you should handle these
1307.12s - 1312.92s |  addresses when using them. Um, you heard me say, you heard me mention, like, a lot of zeros
1312.92s - 1317.92s |  there. And so what's really cool is that we're actually allowed to do this, where instead of
1317.92s - 1324.44s |  putting four zeros in each field, we just put one, like a zero is a zero. And then, like,
1324.44s - 1328.44s |  moving on from that, like, we're also allowed to do something else. We have three fields of
1328.44s - 1333.80s |  zeros here right next to each other. Um, and we're allowed to shorten that by doing a double
1333.80s - 1342.04s |  colon. Uh, we know that an IPv6 address is 128 bits. So, if we see an address and we have a
1342.04s - 1347.64s |  double colon, it means that everything between, you just expand it up to 128 bits in that
1347.64s - 1354.20s |  section with zeros. And then you have, like, the full IPv6 address. Uh, you can only have one
1354.20s - 1359.00s |  double colon, though. So, that's very important to, uh, to know. Because if you had multiple
1359.00s - 1364.28s |  double colons, it wouldn't know, like, where the section in between them, uh, would go with all
1364.28s - 1370.44s |  the zeros. Um, so, and I think this is maybe what trips up a lot of people. Like, you both have,
1370.44s - 1376.12s |  like, hex numbers and you have colons in your IP address and you have double colons and then you
1376.12s - 1383.24s |  have, like, slashes. And then it just becomes, like, way too abstract from what you're familiar
1383.24s - 1393.00s |  with. Um, yeah. So, the next thing that would probably be really good to just mention is how
1393.00s - 1399.56s |  do you browse the web with this? We know that protocol handlers, HTTP, HTTPS, use colons. So,
1399.56s - 1405.24s |  if you suddenly have a protocol handler, HTTPS colon slash slash. And then you have this address,
1405.24s - 1413.96s |  like, that seems to, like, mess something up. Um, so, the problem with pasting it, yeah,
1413.96s - 1418.04s |  in the address bar is what I just mentioned. Like, colons are used to indicate protocol handlers and
1418.04s - 1422.68s |  used to indicate port numbers. So, putting in an address with a bunch of colons is just gonna make
1422.68s - 1427.72s |  everything more confusing. Um, so, that's not going to work. And so, what we instead do is that
1427.72s - 1434.12s |  we put this address in square brackets. And then we press enter. And then we browse the web. Um,
1434.12s - 1438.84s |  so, that's just, like, a good thing that's good to be aware of because you understand IPv6. You
1438.84s - 1443.00s |  know how the addresses work. You see this. You're, like, oh, I want to try to browse to an IPv6
1443.00s - 1447.40s |  address. And then it doesn't work because your browser's, like, what are all these colons doing?
1447.40s - 1455.40s |  Um, but this is the way to do it. So, lastly, in this section, I'm just gonna, uh, end it the
1455.40s - 1461.48s |  same way that I did with the other one by showing you a map of the internet. And so, in this case,
1461.48s - 1467.32s |  it's IPv6. And as you can see here, our idea of using double double the amount of bits,
1467.32s - 1471.72s |  as in an IPv4 address, it achieved what we wanted. Like, everyone seems to have pretty much
1472.28s - 1480.60s |  one large IP block. And it's not a scattered mess that we saw with IPv4. Um, and so,
1480.68s - 1490.36s |  essentially, uh, this is not even the whole IPv6 internet. This is just a part of the IPv6
1490.36s - 1497.40s |  internet that we have allocated today. So, uh, people say, will we run out of addresses?
1499.24s - 1504.20s |  And it seems like we're only having a couple of seconds left. Will we run out of addresses? No,
1504.20s - 1510.52s |  because this is one eighth of the IPv6 internet. And we can fuck up seven more times until we're
1510.52s - 1512.52s |  out. Thank you very much.


url: https://www.youtube.com/watch?v=jrlvMXfftec
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
title:
DEF CON 32 - MoWireless MoProblems: Modular Wireless Survey Sys. & Data Analytics - G Horvath, W Tam

content:
{
  "webpage_url": "https://www.youtube.com/watch?v=jrlvMXfftec",
  "title": "DEF CON 32 - MoWireless MoProblems: Modular Wireless Survey Sys. & Data Analytics - G Horvath, W Tam",
  "description": "Often there are times to collect #allTheWireless, but with that comes some planning, we've created a modular survey system and developed an Elastic-based analytic platform named PacketGlass to visualize and explore the terabytes of information collected over multiple surveys. Our system collects all data types supported by Kismet plus raw PCAP data, ingests the data, and displays tens of millions of devices in an easy to query and display manner. Using different parsing techniques, We plan to show how to build one of these survey platforms and discuss the methodology used to transform Elastic into a robust analytical platform.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1269,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Alright, good afternoon everyone and this next talk that is sponsored by the Packet Hacking
7.80s - 12.80s |  Village. Is More Money More Problems, oh actually I'm wrong, sorry. Is Mo Wireless More
14.08s - 21.77s |  Problems by Jeff Harv, uh, Jeff Horvath and Winston Tam.
24.41s - 27.35s |  Hey guys, how you doing? Thanks for, uh, thanks for coming out to our talk today. Uh, Mo
27.35s - 30.81s |  Wireless, Mo Problems, modular wireless security systems and the data analytics at
31.03s - 33.73s |  the Packet Hacking Village. Welcome. Uh, I'm Jeff Horvath from Alsatian Consulting. Uh,
33.73s - 39.07s |  presenting with me today is Winston Tam from Uplinks LLC. Hello. So tell you guys a little
39.07s - 42.61s |  bit about me. I did 13 years in the army as an intelligence officer. I did 10 of those
42.61s - 47.65s |  years in special operations units. Uh, once I got out of the military, I started Alsatian
47.65s - 51.35s |  Consulting. Uh, and there's our website if you ever want to check us out. We do cyber
51.35s - 56.23s |  security, uh, digital signature reduction, personal data protection to private sector
56.25s - 60.85s |  and public sector individuals. Uh, I have a BA in political science from Drexel
60.85s - 64.69s |  University. I have a master's in information security engineering from the Sands
64.69s - 68.89s |  Institute. And with that I got 10 GAAC certifications and there's my analyst ID so you
68.89s - 73.97s |  can prove that I'm not a liar. Uh, I'm a huge wireless enthusiast and I have two German
73.97s - 80.41s |  shepherds, a 13 year old girl named Bell and a three year old boy named Gunner. Uh,
80.41s - 85.15s |  hey everybody, my name's, uh, Winston. Uh, I am a, uh, I work in software development with
85.17s - 89.47s |  my company, uh, Uplinks. Uh, I spent eight years in the Navy, uh, for those special
89.47s - 93.11s |  operations. Uh, during that time I was a network engineer, pen tester, and a red
93.11s - 98.11s |  teamer. Uh, I also did like three concurrent years as a commercial pen tester for banks,
99.49s - 103.89s |  ISPs, and, uh, funny enough, like an Indian reservation. They get like a .gov domain.
103.89s - 108.89s |  That's kind of cool. Um, yeah, I do, uh, DIY tinkering, um, love 3D printing, uh, have a
110.33s - 115.13s |  lot of projects, a bunch of expired certs I don't care about. Uh, I'm a proud Bengal
115.15s - 120.69s |  cat dad. Uh, I stopped playing factorial. I switched over to RimWorld and, uh, but I'm
120.69s - 126.49s |  still, yeah, I know, I know. Yeah. And, uh, I'm a decent rock climber. Uh, and yeah,
126.49s - 127.23s |  that's how I spend my time.
129.69s - 133.53s |  So let's talk about why we did this, why, uh, the impetus behind this, this whole
133.53s - 137.49s |  project and me being a huge wireless nerd. Uh, I wanted to collect large swaths of
137.49s - 140.67s |  data. I want to collect all of the, all of the channels, all of the packets, get all
140.67s - 144.77s |  of the things. Uh, and my initial thought for this was, okay, how many adapters can
144.79s - 149.29s |  I actually put onto one computer? Can I just do an all in one situation? And if I can,
149.29s - 153.23s |  how physically big is that and how much power is that going to take? And what I found
153.23s - 157.97s |  was that that then creates a huge issue with form factor because in order to put the
157.97s - 161.87s |  requisite amount of cards that we have displayed here on the, on the front on one
161.87s - 166.11s |  computer, that's going to be a rather large box. Uh, so there's form factor issues
166.11s - 169.81s |  that were power concerns with it, with getting enough power to, to have that and
169.81s - 173.45s |  actually have it be kind of portable, uh, number of peripheral devices, right? The
173.47s - 176.99s |  more things you add, the more the operating system has to take care of and has to keep
176.99s - 180.59s |  track of. So the more things you add, the more Ram you have, and eventually you have
180.59s - 185.63s |  this incredibly powerful system that really can only do about one or two things. Um, and
185.63s - 189.31s |  with all that collection, even if we did get that to work, it still has a large amount
189.31s - 194.23s |  of data. I mean, think about how much wifi is flying around white right now and how
194.23s - 199.35s |  much, uh, how much data in a one hour run you can get if you're listening to every
199.35s - 203.85s |  single channel. So we had a lot of large amounts of data that were, were choking my
203.85s - 206.93s |  analytic tools. I couldn't put it into Google earth. I couldn't put it into
206.93s - 210.97s |  another app called QGIS. I couldn't put it into wire shark because they were just
210.97s - 215.89s |  too big and I would end up either having to strip out data and miss things or I
215.89s - 220.57s |  would end up having, um, you know, an incomplete amount of data. So my solution
220.57s - 224.13s |  to that is building the signal processing and reconnaissance kit yellow, which yes,
224.13s - 227.13s |  I know it looks a little orange, but I really wanted the last letter to be a Y
227.13s - 230.59s |  and I couldn't think of any kind of tech thing that started with Y. So that's why it
230.59s - 234.99s |  ends in Y and that's why I'm calling that yellow. Um, it's a modular wireless
234.99s - 238.83s |  collection. Each Raspberry Pi is set to do a different band of the wireless band,
238.83s - 243.71s |  uh, frequency. Uh, it also do Bluetooth BLE. Um, with these Android phones, it
243.71s - 248.39s |  will do, um, cellular parameters. So what tower you're on, what frequencies you're
248.39s - 252.39s |  talking to the cell network on, how good or how bad of service you have, how far
252.39s - 255.19s |  you are from the tower. Because again, I'm a huge wireless nerd and that stuff
255.19s - 261.09s |  really interests me. Uh, it's got 13 alpha NEH cards, 13, uh, media tech alpha
261.09s - 266.83s |  cards, one wifi six card because there really isn't that much wifi six and me
266.83s - 272.07s |  being a self funded guy, I'm, uh, not going to waste money buying, uh, chips
272.07s - 275.57s |  that I'm, that just aren't going to get used. Uh, and then there are five new
275.57s - 281.51s |  like SDRs running, uh, looking for RTL 433 compatible devices. Uh, again, this
281.53s - 285.27s |  things are running on three individual Raspberry Pi fives, uh, four Android
285.27s - 288.55s |  phones and the Android phones are running, uh, wiggle and also G net track
288.55s - 293.29s |  pro. And then I bagged, bagged it all up into these REI trailgate gear cubes and
293.29s - 299.79s |  then put all of that into this portable REI trailgate gear bin. So why did I make
299.79s - 304.17s |  it modular? Well, one, we talked earlier about the memory requirements for having
304.17s - 308.67s |  a lot of devices. If I distribute those devices across multiple, multiple, uh,
308.69s - 314.37s |  computers, multiple, um, pies, I can then, uh, my RAM requirements go down
314.37s - 318.07s |  because Raspberry Pis have been able to run 13 wireless cards simultaneously
318.07s - 321.61s |  ever since the Raspberry Pi two. So the Raspberry Pi five is more than enough
321.61s - 326.31s |  power to handle that much, that much traffic. So we distributed amongst
326.31s - 330.05s |  multiple devices. Uh, I don't have a need for live processing. I don't need to
330.05s - 333.49s |  see my data come in. I'm going to do all of my analytics on the backend when I
333.49s - 337.79s |  have everything merged together. Uh, so I don't need to set alerts. I don't need
337.81s - 340.61s |  to have a GUI. I don't need to have anything. This is all just a fire and
340.61s - 345.89s |  forget headless collection system. Uh, this also reduces bottleneck because now
345.89s - 350.03s |  I don't have all this stuff feeding into one device. It still has to keep track
350.03s - 353.19s |  of all the other, all the other devices and all of the other peripherals that
353.19s - 357.37s |  are attached to it. Uh, that also, uh, allows for a little bit of more
357.37s - 361.13s |  robustness because if I have an issue with a collected file, if I have an
361.13s - 365.21s |  issue with a collected database, uh, I may lose that entire day's run. I may
365.23s - 369.47s |  lose that entire day's session. So now, now I have it distributed amongst
369.47s - 372.77s |  different devices. Uh, if something happens to one of them, I still have
372.77s - 377.01s |  collection from the other two. Uh, this also by dividing it up like this,
377.01s - 380.41s |  creates smaller files, which are much more manageable. Uh, it's scalable. I
380.41s - 384.01s |  can, as I become more interested in other types of wireless technology, I
384.01s - 389.25s |  just build a new pie and then we build a new, uh, a new ingest into it. Uh, so
389.25s - 392.59s |  show you what some of that looks like. And I've got two examples here for
392.61s - 398.57s |  single device characterization and AP characterization. And because this is
398.57s - 407.20s |  not my first Defcon, I'm not doing it live. So what we have here is, uh, this,
407.20s - 411.64s |  the sample dashboard for, uh, signal devices. And we have the OUI of the
411.64s - 415.08s |  devices that it sees time of day analysis about when those devices are
415.08s - 418.18s |  active day of week. And I did all my collection on a Tuesday. So that's why
418.18s - 422.92s |  it's all in one, one pot, uh, probed SSIDs for client devices. So what wifi
422.92s - 426.14s |  networks are they looking for? What access points that they've been seen on?
426.16s - 430.46s |  What protocols have been collected? And this is a video. This is not a live
430.46s - 436.74s |  website, so I can't scroll. There we go. We got the, uh, layers and the, uh,
436.74s - 440.86s |  types of, um, types of protocols that we got collected. And this is all from,
440.88s - 445.34s |  uh, T shark with wire shark. Uh, we got MDNS device names. We've got DHTB
445.34s - 450.14s |  client names and operating system. We have user agent strings. We have MDNS
450.14s - 453.52s |  information about the actual thing. Uh, and this is all from unencrypted
453.52s - 457.64s |  wireless networks that are collected with Kismet that, uh, packet glass
457.64s - 462.68s |  actually will, will take out and, uh, customize and, and contextualize. So
462.68s - 465.50s |  that's what it can show for single devices. When we talk about access
465.50s - 469.92s |  points, uh, when we talk about that, uh, here we've got dots on a map. This
469.92s - 474.76s |  from a drive that I took in, uh, Washington DC. Uh, here we got the top
474.76s - 480.06s |  values of the access points, their encryption, their channel, uh, their
480.06s - 488.83s |  bandwidth, uh, their capabilities, and it scrolls down and you can see
488.83s - 492.83s |  there's lots of things. And then again, we get into more information about
492.83s - 496.83s |  the network itself. So again, the chip manufacturer, uh, the, the BCID with
496.83s - 501.31s |  the OUI lookup, the SSID list of the SSIDs we've seen, what the router
501.31s - 505.03s |  gateway IP addresses, subnet mask, DNS server information that the router is
505.05s - 512.58s |  giving up, uh, in an unencrypted network. And there's also support for 802.11
512.58s - 515.90s |  H, uh, the country code, country settings. So I can see what kind of
515.90s - 520.78s |  country a, or what kind of frequencies of devices is using, uh, what the WPS
520.78s - 525.10s |  Wi-Fi protected setup information is about the manufacturer, about the, uh,
525.10s - 528.90s |  type of device, what clients are associated with it, uh, all kinds of
528.90s - 532.50s |  information, uh, related to the operation of that network. Again, all
532.50s - 536.34s |  passively collected because I can collect all of the Wi-Fi's with, uh,
536.34s - 541.84s |  with the Sparky box. So I'm going to turn it over to Winston. He's going to
541.84s - 544.68s |  tell you about the ones and zeros behind it, all that actually make those
544.68s - 545.88s |  pretty dots up here on a map.
546.60s - 553.99s |  All right, everybody. So, uh, yeah, what, yeah, let's try it. Let's get this,
553.99s - 560.98s |  uh, how do you blow this up? Do I doesn't look like it. There you go. Hey,
561.00s - 565.98s |  took a second. Cool. Thanks. All right. So, uh, yeah, he collected a lot of
565.98s - 571.58s |  data. Um, and a lot of them were geo data. And, uh, I'm just going to go
571.60s - 575.64s |  over the specs, the planning and kind of the execution of it. But overall, I
575.64s - 579.90s |  kind of realized over the course of a conversation at a bar that, uh, this is
579.90s - 583.24s |  a, uh, geo wireless processing hub from a multiple software.
585.80s - 589.44s |  So, like I said, uh, we kind of were just having a, uh, a chat, just
589.44s - 593.04s |  drinking. And, uh, he was telling me about all his wireless problems. Uh,
593.04s - 596.20s |  and, uh, you know, and two and a half hours later I was like, yeah, hold my
596.20s - 601.61s |  beer. Let me, let me do this. And I signed on to do that. So the objective
601.61s - 605.17s |  is to kind of like put dots on maps, right? Um, Jeff is doing everything in
605.17s - 610.11s |  the number one column over there. He's collecting it from Kismet wiggle, um,
610.13s - 613.75s |  arrow dump, a couple other formats. I'll mention more later. Um, so pretty
613.75s - 617.31s |  much all my responsibility is in the number two section, the analytics
617.31s - 621.11s |  platform. Um, at this point, as he was telling me all about it, I've kind of
621.11s - 627.27s |  had one in mind. Um, spoiler alert, it's a, it's elk. And, um, the, the goal
627.27s - 630.51s |  is to make it easy for him to put a dots on maps, um, pretty much change
630.51s - 636.31s |  up maps or even visualization if he needs to. So like I was mentioning
636.31s - 639.75s |  earlier, these are the type of different formats that he mentioned. Um, but
639.75s - 642.51s |  just to give you an idea, the files I'll be actually be dealing with were
642.51s - 649.63s |  like.kismets.tsv, SQLite, CAP, CSVs. Uh, maybe not everything, uh, needs to
649.63s - 653.03s |  be pre-processed, but, um, as I was working on this, I was realizing I kind
653.03s - 656.47s |  of have to consolidate everything down to one single format, uh, that would
656.47s - 663.21s |  work with elk. So what is elk? Um, so overall elk is just this, uh, open
663.21s - 669.31s |  source-ish. Um, it's, it's a big asterisk there. Um, uh, analytics
669.31s - 673.89s |  platform, uh, it does real-time data collection. Um, E stands for Elastic
673.89s - 679.11s |  Search, L is Logstash, K is Kibana. Um, but what you really care about is the
679.11s - 682.83s |  ingestion order is actually, uh, from Logstash, that's where the data comes
682.83s - 687.79s |  in. Uh, Logstash forwards it over to Elastic Search into indexes, uh, where
687.79s - 691.95s |  you will perform some kind of like tagging to like go, Hey, this is how
691.95s - 695.01s |  we're going to retrieve the data. Um, and so when you can actually look up,
695.17s - 697.85s |  uh, do the searching later, uh, and Kibana is where you do the
697.85s - 704.63s |  visualization. So right out of the box, elk doesn't really do what we need it
704.63s - 707.83s |  to do. It doesn't know what a Kismet file is. Uh, it certainly doesn't know.
708.27s - 713.71s |  Um, yeah, it doesn't, it doesn't really know how to use any of that data. Um,
714.43s - 717.83s |  for example, maybe coming from Wiggle, we have something like called Trilat, a
717.83s - 721.11s |  field called Trilat, and coming from Kismet, we have something called
721.37s - 725.69s |  Latitude. Uh, we need to somehow let Elasticsearch know, Hey, uh, these guys
725.69s - 729.45s |  are the same thing. This is the same type of geo data. Um, they also have
729.49s - 732.97s |  different data structure for all of these, uh, files coming in. Uh, and
732.97s - 737.33s |  lastly, um, the first party solution for Elastic Map is, uh, Elastic Map
737.33s - 742.01s |  server, uh, that costs money and, uh, I don't like to give money away. So,
742.01s - 748.12s |  uh, let's, let's do a free version of that. So this is a little diagram I
748.12s - 752.76s |  drew up, um, to kind of like handle the whole solution. Uh, the right side is,
752.78s - 756.38s |  uh, everything you saw, uh, it's containerized, uh, with Docker. Uh, in
756.38s - 760.90s |  this case, we're just using Docker compose. And, uh, we also added the, a,
760.92s - 765.14s |  a map, a little map server on the right side there. Um, on the left-hand side
765.14s - 768.74s |  is pretty much where most of the pre-processing happens. We're, uh, using
768.74s - 773.78s |  a Python script to just handle everything. Uh, and yeah, and we have
773.78s - 781.43s |  like three directories that will, uh, kind of go over in a little bit. So
782.25s - 787.13s |  the work ahead of us is pretty much to have one, uh, stand up a copy of Elk,
787.29s - 791.97s |  two, convert the files, three, we need to normalize the data field, four, uh,
791.97s - 795.09s |  we need to tell how, how we're going to use that data. And in five, we need
795.09s - 798.57s |  somewhere, uh, even if we can put it on a coordinate space, some kind of
798.57s - 801.81s |  mapping on the background to show, Hey, where are, where on the map are we?
802.09s - 804.77s |  Cause you can have coordinate systems, but it doesn't necessarily have to
804.77s - 808.41s |  translate to a map that we're, uh, you know, what you can put anything you
809.07s - 818.13s |  want behind there. All right. So great news about Elk. It already came pretty
818.13s - 822.59s |  much pre-assembled, right? Uh, if you look for Docker compose for Elk, um,
822.59s - 825.31s |  they've already made it super easy. Easiest thing you ever do is just
825.31s - 828.23s |  download it. Docker compose up deep. You have it up and running, but like I
828.23s - 832.25s |  said, it doesn't do anything yet. Um, but I do want to give like huge props
832.25s - 836.19s |  to like Elk Ninja for making this like really frictionless. Um, I'm pretty
836.19s - 842.08s |  sure that's actually the first party, uh, GitHub project for them. All right.
842.10s - 845.82s |  So talking a little bit about converting the files into a compatible format. Um,
845.86s - 850.24s |  so like I said, I decided to do this in a Python script, uh, outside of, uh,
850.26s - 855.14s |  the Elk stack. Um, so we have a ingest folder and index folder and an archive
855.14s - 858.58s |  folder. We're pretty much dumping all of the data that we collected into an
858.58s - 863.08s |  ingest folder where the Python script can be monitoring it. Um, and we can be
863.08s - 867.54s |  monitoring for like Kismet files, SQL files or whatnot. Um, and we kind of
867.54s - 871.70s |  chose it for the, uh, the least amount of work that Jeff had to do. Um, so
871.70s - 874.96s |  pretty much, uh, as soon as he's exporting it, we want to have all the
874.96s - 878.88s |  default settings. So, uh, for, I think wiggle, it might be as something as
878.88s - 882.92s |  simple as like backup dot SQL lite. All right. So, uh, the search pattern I'm
882.92s - 887.52s |  looking for then as backup dot, you know, star SQL lite, um, for the Python
887.52s - 890.88s |  script. Uh, if I have to convert it down, then I'll convert it down to a
890.88s - 895.52s |  Jason. And, uh, if I don't have to, I pretty much just pass it along from a
895.52s - 899.44s |  TSV or CSP and move it right along. Um, for the Jason's there are, there is a
899.44s - 904.30s |  little kind of like a, uh, log stash or elastic search ism, which is you
904.30s - 909.14s |  pretty much have to convert all Jason's into a single line, uh, per entry. Uh,
909.14s - 915.42s |  and just for, uh, elastic search efficiency reasons. Uh, so you, there is
915.42s - 919.22s |  a multi-line format you can do, um, but that like, honestly, do you want to be
919.22s - 925.06s |  less efficient? So here's an example of how we might, uh, convert it from
925.06s - 929.10s |  wiggle. Uh, so the Python scripts is going to look for, okay, cool. I see a
929.10s - 935.44s |  backup dot SQL lite. Um, and, uh, we're going to just run this command. Uh,
935.46s - 938.14s |  yeah, these are prefields. So this is kind of like slightly of a destructive
938.14s - 942.60s |  editing. This is also why we also back up the originals. Um, but these are the
942.60s - 946.44s |  fields that Jeff told me, Hey, this is what I need. Great. Awesome. You could,
946.44s - 950.24s |  Hey, I say select star and grab everything. Uh, but if you're not really
950.24s - 954.48s |  needing to, uh, because the amount of data we're dealing with, we really want
954.48s - 961.06s |  to just like cut down on size where we can. And same thing for Kismet as well.
961.08s - 964.80s |  Uh, we're also dumping it out into a Jason file. And if it has a PCAP file,
964.80s - 969.00s |  if, uh, we can like dump it out into a PCAP NG. Uh, and this is where we kind
969.00s - 973.84s |  of ran into a little tricky thing. I tried using packet beat and, uh, packet
973.84s - 977.16s |  B is really, it feels like it's more designed for any kind of like streaming
977.48s - 981.00s |  or network monitoring. It's not really designed for this like individual file
981.00s - 985.04s |  ingestion. So, uh, what I decided to do was just have T shark actually
985.04s - 989.24s |  converted back from PCAP also into Jason. And that's also another step where we
989.26s - 993.14s |  can do more filtering down so we can remove data that has absolutely, uh,
993.18s - 996.02s |  nothing to do with us. Because at first I was like, yeah, let's keep all the
996.02s - 1000.14s |  data. Uh, I think we wound up filling up that, what we fill up a two terabyte
1000.14s - 1004.02s |  drive. Yeah. Like in, in like a single session. So that was like, well, that's
1004.02s - 1007.38s |  the, let's not do that. Um, so yeah, we started looking for other types of
1007.38s - 1014.46s |  traffics and things that we specifically wanted. So to the, yeah, the next part
1014.46s - 1019.06s |  is then we had to, uh, tag and normalize the data. Right. So even though we bring
1019.08s - 1022.80s |  it into Logstash, uh, so we moved it over from pre-processing into Logstash.
1022.80s - 1027.12s |  Now Logstash kind of needs a way to go, okay, what am I doing with this? So right
1027.12s - 1030.76s |  off the bat, we're using the file plugin, uh, and then for filtering, this is
1030.76s - 1035.00s |  where I was talking about earlier. Um, this is how we let it know, Hey, uh, or
1035.00s - 1040.44s |  start transforming from if Wiggle calls it, uh, latitude or, uh, and Kismet
1040.44s - 1046.36s |  calls it, uh, I don't know, try long or try lat or whatever. Right. Uh, we're
1046.38s - 1049.06s |  trying to give it a way to say, Hey, we're going to want consolidate all of
1049.06s - 1053.22s |  this data type into one single naming field or a single field. Um, so that
1053.22s - 1056.74s |  Elasticsearch knows how to use it. Um, and then, yeah, in the output,
1056.78s - 1062.46s |  obviously we're just sending it over to Elasticsearch. And now that we are
1062.46s - 1065.62s |  actually in Elasticsearch, we need to tell Elasticsearch, okay, cool. Within
1065.62s - 1070.18s |  this index, um, it doesn't, even though we called it say location, right? It
1070.18s - 1073.70s |  doesn't really know what location is yet. So here's where we actually define,
1073.82s - 1076.18s |  Hey, we called something, we made something called location and we're
1076.18s - 1079.80s |  going to define it into a geopoint. Um, now geopoint is something that's
1079.80s - 1083.20s |  native to Elasticsearch. So it knows how to use that data. Um, because we
1083.20s - 1085.78s |  gave it a lat and a long, um, and it looks at it, it's like, Oh, cool. This
1085.78s - 1089.44s |  is an array. It has a lat and a long. Let's put that as a dot. Yeah. Let's,
1089.44s - 1093.04s |  let's put that somewhere on the map. Um, and that's pretty much how that
1093.04s - 1096.24s |  works. And we have to repeat this process for every software that we want
1096.24s - 1100.32s |  to do that. Um, but that's essentially the whole pipeline and to tie the whole
1100.32s - 1103.44s |  thing together, like I said, because we're not interested in, um, you know,
1103.62s - 1107.66s |  paying too much to do this. Uh, we just decided to use map Tyler, which is
1107.66s - 1110.78s |  another open source software that we can just grab that Elasticsearch
1110.78s - 1113.16s |  actually made it pretty easy where you can just either pop it in the
1113.16s - 1116.10s |  settings or in an environmental variable when you run up or spin up
1116.10s - 1120.34s |  Elasticsearch. Uh, for the case of using map Tyler, that's actually just a
1120.34s - 1125.54s |  domain for self self hosted option for it. Um, and in this case we're also
1125.54s - 1130.18s |  using just open street maps. Um, so that's how we're able to just like put
1130.18s - 1132.28s |  tiles underneath, uh, the coordinate system.
1134.24s - 1137.32s |  Yep. So to wrap it up, I want to give some special thanks to main, the packet
1137.32s - 1141.48s |  hacking village committee for allowing us to present today, uh, Elk Ninja for
1141.48s - 1146.56s |  the work on the dockerized, uh, version of elastic, uh, dark matter for giving
1146.56s - 1151.56s |  me an idea of how to build a large scale wireless collection rig, uh, drag
1151.56s - 1154.80s |  or, and why go project Geicov solutions for making all the software that powers
1154.80s - 1158.88s |  this, uh, powers the system. Uh, my husband, Mark Winters, who helped me
1158.88s - 1164.78s |  make this actually fit into a nice, pretty present presentable form, a monkey
1164.78s - 1168.82s |  user for letting us borrow a lot of his pictures for this amazing presentation
1169.30s - 1177.05s |  and Tyler Carper for his contributions with, uh, with Winston. So questions,
1177.05s - 1182.39s |  comments, complaints, other things to begin with. See, yeah.
1188.97s - 1189.33s |  Yes.
1190.77s - 1194.77s |  Do you do anything special? Do you take any special efforts to synchronize the
1194.79s - 1200.07s |  time? Because I would imagine when you reintegrate the data, you have to have
1200.07s - 1204.03s |  the top list. Those three devices have to have their time. Yep. So they get, so
1204.07s - 1209.11s |  they get their, uh, time from the, uh, NTP server whenever I connect them up.
1209.15s - 1212.17s |  And then they have an RTC battery in there that's keeping that, keeping that
1212.17s - 1215.95s |  running. So I may lose a few seconds, but with what I'm doing, it's not really
1215.99s - 1235.48s |  like, I'm not looking for an exact one to one correlation. Anything else? I
1235.50s - 1239.18s |  just grab it all. Yep. And then, and then afterwards, then I look for the
1239.18s - 1242.18s |  anomalies. Then I look for the things that I, that I want to see. It's like,
1242.18s - 1245.44s |  oh, that protocol looks interesting. Let's look more at that, at that device.
1248.32s - 1251.22s |  Uh, so I've been able to find a lot of stuff through MDNS. I've been able to
1251.22s - 1255.64s |  find a lot of stuff through, um, DHCP requests, a lot of information about
1255.66s - 1261.93s |  devices themselves, which has been really handy for that. Yep. They're,
1261.93s - 1262.97s |  they're getting mid signal, so.


url: https://www.youtube.com/watch?v=iUnPLLvA4Gc
title: DEF CON 32 - Dysfunctional Unity The Road to Nowhere - Michael v3ga Aguilar
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=iUnPLLvA4Gc",
  "title": "DEF CON 32 - Dysfunctional Unity The Road to Nowhere - Michael v3ga Aguilar",
  "description": "Years progress, time passes, and medical devices are still vulnerable, with Hospital computer and network security being a hot topic on the minds of citizens and CISA/FDA/etc. If we do not get better now, things will get much worse in the future. My talk will cover some general mistakes observed within the Medical device topography, misnomers about SBOM and what it is and what it accomplishes, ideas for roadmaps for more secure devices and environments and discussions around CVEs relating to the medical device topography.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1610,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Sorry, these lights are kind of bright and I have an aversion to light, but thank you
6.08s - 7.08s |  for coming to the talk.
7.08s - 9.68s |  Again, my name is Michael Aguilar.
9.68s - 10.68s |  I'm a...
10.68s - 11.68s |  Oh, perfect.
11.68s - 12.68s |  Thank you so much.
12.68s - 13.68s |  Oh, God.
13.68s - 14.68s |  Now I can see.
14.68s - 15.68s |  Hi, everybody.
15.68s - 16.68s |  Thank you for coming.
16.68s - 17.68s |  Again, my name is Michael Aguilar.
17.68s - 26.80s |  Basically, I'm going to give a talk about dysfunctional unity, and I'll kind of touch
26.80s - 33.12s |  on what that is and kind of what I'm talking about.
33.12s - 39.06s |  So me, myself, I am a principal consultant for SecureWorks Adversary Group.
39.06s - 43.00s |  My specialties range in a lot of different practices for offensive security.
43.00s - 48.68s |  Again, things like physical security, breaking into buildings, social engineering, basically
48.68s - 57.36s |  lying my rear end off to get in that building, adversary simulations, binary exploitations,
57.36s - 62.60s |  web exploitations, and also making medical devices play Doom.
62.60s - 68.12s |  That's kind of my fun thing to do for medical devices, I guess, when you kind of get an
68.12s - 71.12s |  area of privilege.
71.12s - 74.76s |  Free time activities, I do like to read a lot.
74.84s - 79.76s |  Basically, if my head is not in a book, it's in another book.
79.76s - 82.04s |  I like to practice my offensive coding skills.
82.04s - 85.88s |  Again, things like A-B bypasses, Am-Z bypasses, things that you'll actually be using in the
85.88s - 88.24s |  field that I use pretty much all the time.
88.24s - 95.40s |  I like to, again, read constantly, but again, free time to build off stress, a lot of cycling,
95.40s - 100.08s |  running, swimming, just basically kind of gets a heart beating because I like to break
100.08s - 104.28s |  into buildings, so I figure that the better I take care of myself, the more I can keep
104.28s - 106.00s |  doing this as a profession.
106.00s - 115.48s |  I also like to get tattoos, it puts me to sleep, and I am a fan of very fast, loud music.
115.48s - 124.28s |  So going over, let me take my glasses off, it's actually a first for me, what is dysfunction
124.28s - 127.60s |  that I'm talking about and how it applies to what I'm speaking about with regards to
127.60s - 132.88s |  the medical device typography and vendors and, I should say, medical device manufacturers
132.88s - 135.64s |  and the FDA and the governing people of that.
135.64s - 140.04s |  I'm also going to talk about a few wars that have basically been won through attrition
140.04s - 145.28s |  when trying to release CVEs, and also some of the lurking dangers of interconnected medical
145.28s - 150.00s |  devices, some of the things that we kind of need to be looking at in the future, and my
150.00s - 154.08s |  theories on a brighter future of how we can actually start doing more things to actually
154.08s - 163.31s |  be secure with regards to deploying these items in secured infrastructure.
163.35s - 167.79s |  So when you think about dysfunction, I put this here because obviously if you're thinking
167.79s - 171.83s |  about dysfunction, this is one of the most dysfunctional families that we've seen in
171.83s - 173.55s |  America.
173.55s - 178.07s |  I'm not going to lie, the family that I'm talking about seems to be one of the most
178.07s - 185.83s |  dysfunctional families in America, and this is again between the tester, the MDM, and
185.83s - 192.82s |  the federal government in the way that they manage these things.
192.82s - 199.86s |  So according to the Merriam-Webster dictionary, again, what is dysfunction?
199.86s - 206.82s |  It can be described as an abnormal or unhealthy interpersonal behavior and interaction, again,
206.82s - 207.82s |  with a group.
207.82s - 212.42s |  So again, the groups that I'm talking about are security researchers, the manufacturers
212.42s - 216.70s |  that make these devices, and the rule makers who actually enforce the rules that are supposed
216.70s - 222.90s |  to be applied to these devices as they're ingested into our internal infrastructure.
222.90s - 233.43s |  Now basically these groups are all separated entities that should normally be able to work
233.43s - 237.31s |  cordially together in a standard format.
237.31s - 243.59s |  Occasionally though, the conversations between researcher and like say the person you're
243.59s - 250.35s |  trying to work with to release a vulnerability, the manufacturer, it turns a little bit different.
250.35s - 256.15s |  Again, they have a different idea, an ideology of how things should work in their topography
256.15s - 260.71s |  versus the actual researcher and the nuts and bolts person who actually does the exploitation
260.71s - 262.71s |  on these devices.
262.71s - 267.99s |  Again, us as researchers, when we do these things, we're using techniques and skills
268.07s - 275.07s |  that we've done again and again with proven track records to show the range of the exploit
275.07s - 277.87s |  that we're actually deploying on this.
277.87s - 282.79s |  But the issue that I'm running into is that the guidelines that are being set forth by
282.79s - 287.63s |  federal governments, the FDA, are namely just recommendations.
287.63s - 288.95s |  They're not really hard rules.
288.95s - 292.35s |  The hard rule is that if you have a device with vulnerabilities, they won't sell it in
292.35s - 293.91s |  the domestic market.
293.91s - 297.35s |  But in order to get there, they give you guidelines.
297.35s - 302.43s |  You should do this, not you need to do this or we'll cut you out.
302.43s - 304.27s |  It's you should.
304.27s - 307.43s |  A lot of people use this to their advantage because again, they're not making the smart
307.43s - 313.67s |  choices that they need to make in these devices to deploy them into a critical infrastructure.
313.67s - 320.79s |  Now the other issue is what happens when there is an impasse between a researcher and the
320.79s - 325.95s |  MDM that you're trying to release the CBE with?
325.95s - 328.47s |  Who plays that neutral third party?
328.47s - 335.63s |  A lot of times the MDMs themselves will actually be their own CNAs, which makes it so that
335.63s - 338.43s |  they actually release their own CBEs.
338.43s - 342.27s |  Now the problem is that when you're arguing something between somebody who actually does
342.27s - 347.91s |  it and like the person who's making it, they can just keep stalling and stalling and stalling
347.91s - 353.39s |  and then eventually you'll just give up because you don't want to have to wait like six months,
353.39s - 358.39s |  a year, two years, three years to put out a CBE.
358.39s - 361.83s |  And honestly to tell you the truth, I don't even care about the CBE, I'm just trying to
361.83s - 366.95s |  get this stuff fixed in the product because obviously I saw it, I experienced it, I exploited
366.95s - 370.31s |  it and if I can do it, then somebody else can.
370.31s - 374.39s |  And it's not me who I'm worried about, it's other people who are going to be attacking
374.39s - 379.07s |  our infrastructure that is my main concern.
379.07s - 384.67s |  Now again, my feeling is that again, reporting telemetry that I have turned in, again regarding
384.67s - 388.87s |  findings and stuff that is being ingested by the FDA is not fully, fully understood
388.87s - 391.03s |  to the full of its capacity.
391.03s - 396.15s |  A lot of times you're turning in a report with some somewhat critical and questionable
396.15s - 401.39s |  flaws, but the project will still be accepted and acknowledged by the FDA and then later
401.39s - 403.19s |  sold in the domestic market.
403.19s - 407.83s |  What happens to be able to get to that point, I have no idea because again, I don't work
407.83s - 412.31s |  for a manufacturer, I'm just a consultant that does the test, but the main issue that
412.31s - 416.67s |  I have is again, these major vulnerabilities and these classes of vulnerabilities can potentially
416.67s - 420.67s |  kill somebody or the entire hospital are getting passed through.
420.67s - 427.03s |  And I have no idea how this is getting from A, me, B, report, to C, you're accepted to
427.03s - 429.03s |  your 510K.
429.03s - 432.27s |  This does not make any sense to me.
432.27s - 437.71s |  So again, when they read about a threat, what they're looking at is basically, it's
437.71s - 441.31s |  just a single device in a box.
441.31s - 446.75s |  They're not looking how this item is interconnected or using the connections that they have actually
446.75s - 448.23s |  installed on this.
448.23s - 454.11s |  You'll notice a lot of medical devices are almost legacy devices with NESP32 or some
454.11s - 461.10s |  other device to allow a networking stack to be able to transmit this data back and forth.
461.10s - 463.34s |  I mean, we're talking about a single device, right?
463.34s - 467.78s |  Just one device, what's going to happen?
467.78s - 471.36s |  And that's the main thing, is that when the companies look at these exploits, these things
471.36s - 476.18s |  that I turn in, it's like, oh, it just happened on a device, what's going to happen?
476.18s - 481.90s |  Again, one is that these systems again, are interconnected, meaning that they are connected
481.90s - 482.90s |  to a hospital.
482.90s - 489.18s |  Now, a lot of times again, to get access to that, that means that basically you just plug
489.18s - 490.18s |  something in.
490.22s - 492.82s |  There's just like network ports everywhere in hospitals and a lot of times they're just
492.82s - 493.82s |  not dead.
493.82s - 500.02s |  So, again, they say that it may only affect one device, but again, this one device is
500.02s - 505.54s |  connected to a multiple item or multiple plethora of network nodes through Active Directory
505.54s - 507.34s |  and other means.
507.34s - 514.14s |  And many times again, also the manufacturers say that you're not supposed to plug in device.
514.14s - 518.66s |  The device has an Ethernet port, but it does not need to be plugged in.
518.78s - 522.42s |  But again, if the Ethernet port does not need to be plugged in, then why does it exist in
522.42s - 524.42s |  the device topography?
524.42s - 529.86s |  Also, again, you have to understand where these items are plugged into.
529.86s - 532.98s |  They'll plug into probably a hospital network.
532.98s - 534.98s |  Now a hospital network contains what?
534.98s - 535.98s |  Active Directory.
535.98s - 541.02s |  So, that's kind of the problem, is that now you have a device with a vulnerability that
541.02s - 545.82s |  is connected to an Active Directory network that is able to either utilize NTLM credentials
545.82s - 549.78s |  that you may be able to take and exploit and steal, then point upwards, do things like
549.78s - 553.86s |  ADCS flaws and other kinds of Kerberos-ing stuff to get privilege escalation, basically
553.86s - 557.42s |  to take over the entire domain from that one device.
557.42s - 563.38s |  Again, these kinds of devices are also prime candidates to jump off from in the network.
563.38s - 567.10s |  Even if it's not AD joined, it still gives you the same kind of access to be able to
567.10s - 570.38s |  start doing other attacks to be able to get those kinds of credentials from within the
570.38s - 573.98s |  network, password sprays and other kinds of things, looking for open shares, checking
573.98s - 578.14s |  for simple passwords, checking for anything that basically will give you stuff.
578.14s - 583.30s |  I've gotten a lot of actual credentials by just utilizing network sniffing and pcreds
583.30s - 588.94s |  and other kinds, or credmaster, I'm sorry, credslayer, to basically analyze PCAP files
588.94s - 594.30s |  and pull off the NTLM credentials from PCAP files, just from listening passively, from
594.30s - 600.00s |  the guise of a medical device.
600.00s - 607.52s |  The second thing that I don't get, again, is when I turn in a report with a critical
607.52s - 612.16s |  flaw, but it's still accepted by the FDA.
612.16s - 616.40s |  These are things that basically will either kill a patient, take over the entire hospital,
616.40s - 617.84s |  or blow up the hospital.
617.84s - 623.20s |  In one instance, basically I turned something that was supposed to clean items into a makeshift
623.20s - 629.24s |  bomb because of the access for field service engineering, a heat bay that you now can modify
629.24s - 635.00s |  the control temperatures for, and the usage of pure oxygen and pure alcohol in the thing
635.00s - 641.14s |  to do the sanitization.
641.14s - 647.06s |  Now this leads to how I expect things to go in the future, which is I hope that the FDA
647.06s - 654.14s |  and CISA is looking towards offering more and more support by hiring people that actually
654.14s - 657.06s |  understand what's going on.
657.06s - 661.02s |  That's kind of like nine-tenths of the problem, is that the people who are reading this don't
661.02s - 666.14s |  understand that NTLM theft is bad, or that you can actually get domain admin from a lower
666.14s - 667.64s |  privileged user.
667.64s - 670.74s |  It's just like they look at it and they're like, okay, there's a flaw, and you quote
670.74s - 675.82s |  unquote remediated it, or you have a justification to say that you should be passing credentials
675.82s - 678.90s |  in clear text or whatever the hell happens that gets them these passes.
678.90s - 682.58s |  What happens, I don't know, because again, I am disconnected from this process, but if
682.58s - 686.66s |  anybody has insight into how that happens, please, I'll be right there.
686.66s - 694.20s |  Just let me know what's going on.
694.24s - 702.16s |  Now a lot of times also, medical device manufacturers will say, this is in a protected area.
702.16s - 706.80s |  So again, as I mentioned, I also lead the physical security assessments for my firm.
706.80s - 711.60s |  So in 2022, basically my entire summer was breaking into protected areas.
711.60s - 718.04s |  So the fact that it's in a protected quote unquote area doesn't really mean anything.
718.04s - 719.88s |  Everybody's been to a hospital, right?
719.88s - 727.56s |  They have the double doors, you walk in, it senses you, the IR reader opens the doors.
727.56s - 732.08s |  Do you think you'd really be able to get in just wearing some scrubs, a badge you cloned,
732.08s - 734.64s |  and looking like a general doctor?
734.64s - 735.76s |  It's pretty easy.
735.76s - 740.16s |  All you have to do is keep your head down, just nod to people, act like you work there,
740.16s - 746.24s |  and then they will pretty much believe that you do that if you fit in with a certain profile.
746.24s - 751.52s |  So again, utilizing all of that theory, having these devices in these quote unquote protected
751.52s - 756.88s |  areas really doesn't mean much if you can actually get access to these protected areas.
756.88s - 762.40s |  Now again, the issue is that obviously you need to get into these, but to think that
762.40s - 766.60s |  somebody wouldn't do this if they really needed to affect the topography of a certain area
766.60s - 770.57s |  is a fool's game.
770.57s - 777.67s |  And then one time, I was challenged by an MDM to basically get into the device with
777.67s - 783.69s |  under two minutes to try to get the exploit going because they said that, oh, we have
783.69s - 786.41s |  a case, everything's fine.
786.41s - 787.41s |  Cases don't matter.
787.41s - 791.81s |  Again, if you have a case, that's fine, but basically you need an alarm on it to sound
791.81s - 796.89s |  if you want to make that protected, and that's as per the FDA.
796.89s - 802.29s |  So my record for actually opening and exploiting a device in a case was less than two minutes.
802.29s - 807.33s |  So basically, you open the case, I had a bunch of screws flying everywhere, did the exploit,
807.33s - 812.77s |  got the shell, closed it back up, and then we're all good in under two minutes.
812.77s - 816.13s |  So I only needed two minutes on door to be able to get that exploit out the door and
816.13s - 819.93s |  then get code execution, and then now I'm system on the thing that's going to be cutting
819.93s - 825.62s |  people up.
825.62s - 832.38s |  So again, another layer of the dysfunctional reality of what we have going on with medical
832.38s - 839.78s |  and MDM and researchers is that, again, placing these connected devices onto the hospital
839.78s - 843.54s |  network also increases some level of risk.
843.54s - 847.66s |  If it's not meant to be connected onto the network, then again, I still don't know why
847.66s - 850.58s |  they put networking on these.
850.58s - 854.58s |  Most of the time, what I hear is that the developers for the boards are just utilizing
854.58s - 857.94s |  what's there, and sometimes that has Wi-Fi.
857.94s - 861.82s |  They just don't know how to disable it, or they will just leave the chip on there.
861.82s - 865.34s |  And that's the kind of aspect that I hope to see in the future change in that, again,
865.34s - 868.70s |  if it's not needed and if it's not supposed to be plugged in, then don't keep the stuff
868.70s - 869.70s |  in there.
869.70s - 873.66s |  I mean, hell, just put some freaking glue in the port and then make sure that it won't
873.66s - 874.66s |  go in.
874.66s - 875.66s |  It's really pretty simple.
875.66s - 880.34s |  A soldering iron can do this, but again, this is the part I don't get where they put in
880.34s - 888.66s |  big words in their FAQ, don't plug this in on the network, but here's a network jack.
888.66s - 893.34s |  Also hospitals themselves are dealing with a ton of issues right now.
893.34s - 898.74s |  Again, you've always seen a lot of ransomware going off in hospitals, and why do you think
898.74s - 900.74s |  that is?
900.74s - 906.06s |  And I've been on a lot of adversarial simulations as well, and again, the security of these
906.06s - 907.70s |  places is very down level.
908.02s - 913.14s |  Now, my reason or my theory for this is because, again, the legacy devices, the medical devices
913.14s - 917.46s |  that exist in this topography don't have the strongest security settings.
917.46s - 920.74s |  Other times, they can accept the strongest security settings.
920.74s - 922.14s |  It's an impossibility.
922.14s - 925.62s |  Some of these devices can't even have a password over eight characters because we'll break
925.62s - 926.62s |  something.
926.62s - 930.30s |  So that's why the level of security sometimes drops within these infrastructures because
930.30s - 934.84s |  of their inclusion of these kinds of devices and the allowance for them to be able to run.
934.84s - 938.48s |  So then we have scenarios where obviously people who know what they're doing within
938.48s - 942.60s |  a network and can actually attack a system will see all these gaps in security and take
942.60s - 948.08s |  advantage of that and then launch their ransomware payloads against the topography of the hospital.
948.08s - 951.40s |  Hospitals used to have a pass from threat actors against doing actions like this, but
951.40s - 956.48s |  that pass has been revoked, as we've been seeing in the recent months, with many hospitals
956.48s - 961.80s |  again being hit by ransomware operators and ransomware firms.
961.80s - 968.84s |  Now, there is a key point, again, continuous adversarial assessments is kind of key.
968.84s - 974.92s |  And one thing I always see when I'm on a hospital network, which is odd, is an OU that says
974.92s - 979.16s |  like defender or semantic disabled.
979.16s - 982.76s |  And then there's a bunch of systems in there and they're normally critical.
982.76s - 989.55s |  There's, I mean, that's data that you basically, as you're ingesting as a threat actor, you
989.55s - 991.67s |  can just take actionable, look it up.
991.67s - 995.03s |  If you're in an internal network for a hospital, look up an OU called disabled.
995.03s - 998.31s |  I guarantee you, you'll probably find one with devices that aren't running any kind
998.31s - 999.31s |  of software.
999.31s - 1004.13s |  And that's for a specific reason, critical, high target assets.
1004.13s - 1006.87s |  So go ahead and take a look if you do those kinds of assessments.
1006.87s - 1011.83s |  But also again, the gears of these organizations are very slow to move.
1011.83s - 1015.63s |  If anybody's ever worked in the medical field, trying to get any kind of change, like, you
1015.63s - 1025.89s |  know, actually accepted is a constant uphill battle.
1025.89s - 1029.41s |  So again, there is a way out of this.
1029.41s - 1034.41s |  And that's, again, getting good goal-based offensive testers actually doing the tests
1034.41s - 1036.49s |  for these.
1036.49s - 1042.85s |  It's funny to me because a lot of times when I come onto a client site, I will just talk
1042.85s - 1043.85s |  to the client.
1043.85s - 1045.33s |  You know, how did your last pen test go?
1045.33s - 1047.41s |  There's things you liked about it, you know, things you didn't.
1047.41s - 1050.89s |  A lot of times they'll just show me the report and I'm like, okay, this is some stuff.
1050.89s - 1056.09s |  But there's some similarities that I'm seeing between the medical testers that I experience
1056.09s - 1059.73s |  is that they're not too thorough.
1059.73s - 1068.49s |  Key point, one client showed me a report, prior test, they got the reverse shell, yay.
1068.49s - 1069.49s |  That was it.
1069.49s - 1070.49s |  Basically, that was the pun.
1070.49s - 1071.85s |  They got a reverse shell.
1071.85s - 1075.81s |  That was the same one that I had the POC that basically blew up the hospital.
1075.81s - 1079.65s |  So there was no post-exploitation, there was nothing done to look for configuration files,
1079.73s - 1083.21s |  there was nothing that was actually done as far as cracking passwords, there was nothing
1083.21s - 1084.93s |  done to escalate privileges.
1084.93s - 1089.69s |  They just got a shell, called it a day, probably scanned it with Nessus and that's it.
1089.69s - 1096.13s |  So there's a little bit of a difference that good offensive adversarial testing can give
1096.13s - 1101.01s |  you versus just the general scan and click and Nessus kind of chill thing.
1101.01s - 1104.41s |  I know it's hard as a person who may be purchasing these things.
1104.41s - 1108.69s |  Again, you may be thinking that the sticker shock of a test who may be $10,000 more than
1108.69s - 1115.01s |  your other tester just because they're local is viable for your operation because you may
1115.01s - 1116.01s |  get a pass.
1116.01s - 1118.89s |  But again, is that going to be cheaper in the long run?
1118.89s - 1120.25s |  Think about this.
1120.25s - 1126.93s |  You get a pass for your devices, you're putting out an X widget and the tester did Nessus
1126.93s - 1132.57s |  and map, everything looks good, it runs, you can put it on the market, you can turn in
1132.57s - 1136.65s |  your artifact that says you had a pen test, but is that really going to be cheaper in
1136.65s - 1142.77s |  the long run if that device gets found to have a critical flaw in the field where possibly
1142.77s - 1144.81s |  could probably kill somebody?
1144.81s - 1149.09s |  And then somebody tries to publish that and then you have to take it off with a recall
1149.09s - 1154.01s |  and then you have to put it back on and submit another $5,000, $10,000.
1154.01s - 1159.13s |  The cost, again, comes up a lot more when you have to do that versus if you just do
1159.13s - 1165.45s |  it right the first time and go with somebody who, say, you know, has a valid reputation
1165.45s - 1168.93s |  for testing these things, has a body of work or something, you know.
1168.93s - 1172.25s |  So when you're doing these kinds of choices for your testers, just kind of research, you
1172.25s - 1176.45s |  know, what they have as far as skill sets and just make sure that everything is a thorough
1176.45s - 1181.22s |  check versus just a reverse shell and we're done.
1181.22s - 1187.06s |  Also, again, when you are getting these things, you know, obviously we want to help you.
1187.06s - 1191.42s |  So what I like to look at is myself as a budgetary tool.
1191.42s - 1196.86s |  The harder I hit the system, that's more money that you get in your pocket for budget.
1196.86s - 1201.78s |  So basically, again, you know, I like to look at myself as kind of a force multiplier.
1201.78s - 1203.94s |  Now, again, wars run through attrition.
1203.94s - 1209.46s |  I've had a lot of open discussions with some medical device vendors, but my hopes are that,
1209.46s - 1213.46s |  again, we can kind of work together in some kind of uniform fashion.
1213.46s - 1217.66s |  I'm kind of tired of people trying to sue me for no fucking reason.
1217.66s - 1223.22s |  So the sooner that they start to wake up and realize that I'm doing this shit for free
1223.22s - 1228.06s |  like here, they should like, you know, accept these things and actually try to work with
1228.06s - 1232.18s |  us versus trying to sue us with litigation because like I don't care about your stupid
1232.18s - 1233.18s |  binaries.
1233.18s - 1240.62s |  Again, case in point, last time I tried to release a CBE, there was group A who, well,
1240.62s - 1243.50s |  there was the first group who was very receptive, everything worked fine.
1243.50s - 1246.06s |  There was group B. They didn't get anything.
1246.06s - 1247.06s |  We talked.
1247.06s - 1248.06s |  We came back.
1248.06s - 1249.06s |  We talked more.
1249.06s - 1251.26s |  They had no understanding what the physical vulnerabilities were going on.
1251.30s - 1255.66s |  They just basically said like, oh, well, you know, I have one guy was screaming, I have
1255.66s - 1256.66s |  a screwdriver.
1256.66s - 1257.90s |  I can break into fucking anything.
1257.90s - 1260.34s |  I'm like, I don't even know what the hell's going on with you, sir.
1260.34s - 1262.62s |  You must be having a bad day.
1262.62s - 1267.34s |  And then you get an email saying, I need you to affirm in writing and certify that X, Y
1267.34s - 1268.34s |  and Z.
1268.34s - 1269.62s |  That comes from the law department.
1269.62s - 1271.10s |  That's not from the person that wrote it.
1271.10s - 1274.14s |  So again, I know what's coming next in that order.
1274.14s - 1280.06s |  So again, I think that hopefully under some time we can actually work together in a cohesive
1280.06s - 1284.34s |  manner and kind of all get together and maybe have beers afterwards.
1284.34s - 1285.98s |  Also wars went through attrition.
1285.98s - 1289.34s |  And this is my view of companies that write their own CBEs.
1289.34s - 1294.98s |  Again, it's kind of hard because if you write the CBE and I'm the researcher, who do you
1294.98s - 1296.54s |  think is going to be the neutral ground?
1296.54s - 1297.58s |  Like there's no neutral ground.
1297.58s - 1298.58s |  I write the CBE.
1298.58s - 1300.02s |  This is what's going to happen.
1300.02s - 1302.82s |  Here's how the here's the here's the severity.
1302.82s - 1307.18s |  You know, nobody's understanding what's actually going on.
1307.18s - 1313.26s |  And again, does this feel like neutral ground if you make the CBE and you have to argue
1313.26s - 1318.18s |  with the same people that are the owners of this project and you basically cannot go off
1318.18s - 1319.18s |  of anything.
1319.18s - 1323.62s |  So, you know, this is this is not neutral, in my opinion.
1323.62s - 1327.58s |  Again, health care is very expensive.
1327.58s - 1331.58s |  So again, we need to make better decisions when we're connecting these devices on the
1331.58s - 1333.40s |  interconnected space.
1333.40s - 1340.56s |  So again, you know, the better we do with making the smart items more secure, the better
1340.56s - 1341.64s |  we'll be in the long run.
1341.64s - 1346.88s |  We'll have less ransomware and less issues kind of plaguing us with regards to severe
1346.88s - 1350.80s |  vulnerabilities in medical devices.
1350.80s - 1354.52s |  Also one thing of note with genetics, don't go away like, you know, just handing out your
1354.52s - 1359.96s |  genetic data to all these random places because it's kind of hard to change your genetic sequence.
1359.96s - 1362.04s |  You can change your driver's license pretty easy.
1362.04s - 1369.20s |  You need like a CRISPR and a lot of time and effort to change your DNA.
1369.20s - 1371.92s |  Again, we can do better.
1371.92s - 1376.60s |  I feel as a group, you know, we can all kind of hopefully come to some kind of agreement
1376.60s - 1380.48s |  that says like, hey, guns down, like, let's just actually start working together.
1380.48s - 1385.40s |  But that's going to be in the future when, again, we actually start realizing that these
1385.40s - 1387.12s |  items are critical assets.
1387.12s - 1392.52s |  When you release a CBE for a medical device, guess who also notes the CBE, CISA, because
1392.56s - 1394.52s |  it's critical infrastructure.
1394.52s - 1398.08s |  So the more we start looking at them as critical, the more that these manufacturers hopefully
1398.08s - 1399.88s |  will start actually making the smartest decisions.
1399.88s - 1403.00s |  Now, mind you, I know that they know that they're critical because they're class two
1403.00s - 1407.32s |  and class three medical devices, but necessarily criticality, I think, differs in our opinion
1407.32s - 1408.32s |  of things.
1408.32s - 1409.32s |  Let's see.
1409.32s - 1410.32s |  Okay, cool.
1410.32s - 1411.32s |  I got one example.
1411.32s - 1412.32s |  Okay.
1412.32s - 1413.32s |  Reason.
1413.32s - 1414.32s |  Okay.
1414.32s - 1415.32s |  Anybody familiar with DICOM?
1415.32s - 1416.32s |  All right.
1416.32s - 1418.92s |  Cool.
1418.92s - 1419.92s |  So has anybody heard of Pedicom?
1419.92s - 1420.92s |  Yeah, you have.
1420.92s - 1423.20s |  Nobody else.
1423.20s - 1424.20s |  Okay, cool.
1424.20s - 1429.20s |  So basically, it was a research project released five years ago.
1429.20s - 1436.28s |  Somebody made the ability to ingest or execute DICOM images from the command line by stuffing
1436.28s - 1439.52s |  a PE header in the 128-byte preamble.
1439.52s - 1444.16s |  So basically, now you have 128 bytes of free space to throw malware.
1444.16s - 1449.36s |  So here is something I'm going to show you.
1449.36s - 1455.48s |  All right.
1455.48s - 1458.69s |  Cool, cool.
1458.69s - 1459.69s |  All right.
1460.01s - 1462.13s |  This is a DICOM file.
1462.13s - 1463.93s |  This is an image, okay?
1463.93s - 1467.37s |  You open it with Radiant, you'll see an image, okay?
1467.37s - 1469.01s |  This is that same DICOM file.
1469.01s - 1470.65s |  This is that same DICOM file running.
1470.65s - 1476.00s |  Let's see.
1476.00s - 1479.24s |  And, well, a second ago, oh, that's why.
1479.24s - 1480.24s |  No network, huh?
1480.24s - 1483.13s |  Funny.
1483.13s - 1484.13s |  Damn it.
1484.13s - 1486.86s |  Sorry.
1486.86s - 1492.14s |  So basically, the whole long story is you can actually execute these images from the
1492.14s - 1494.38s |  command line and you'll get a reverse shell.
1494.38s - 1499.50s |  I'm not going to tell you how because I have tooling to do this and the issue is that the
1499.50s - 1503.58s |  researcher who originally did release this did not release a POC.
1503.58s - 1509.50s |  Now the other issue is that antivirus engines have a hard time scanning these types of files.
1509.50s - 1511.54s |  Reason being is, again, it looks like an image.
1511.54s - 1512.82s |  It opens like an image.
1512.82s - 1514.98s |  In all purposes, it is an image.
1514.98s - 1519.90s |  If you open it up with a DICOM viewer, it will open up and show you the actual image.
1519.90s - 1522.86s |  So that's the issue, is that you lose no file integrity.
1522.86s - 1526.86s |  The image is still intact and now you've chucked 128 bytes of malware and you'll get
1526.86s - 1527.86s |  a reverse shell.
1527.86s - 1533.90s |  If you would like to talk more about that kind of thing, I'll be in the biohacking village
1533.90s - 1536.58s |  doing this to multiple people who ingest DICOM files.
1536.58s - 1542.06s |  So it's going to be an interesting time, but necessarily, again, you can take theoretical
1542.06s - 1544.70s |  research and turn it into actionable data.
1544.70s - 1550.14s |  So now I have a project that, again, shoves malware into DICOM images and due to the way
1550.14s - 1554.02s |  that you have to keep these images, they'll now be on disk for about five to ten years
1554.02s - 1556.34s |  because of rules with deletion.
1556.34s - 1560.18s |  Also there's a worm that will overwrite all of the headers for all the other files that
1560.18s - 1565.54s |  are DICOM in the same directory and basically make them do the same thing.
1565.54s - 1572.18s |  So enjoy that.
1572.18s - 1578.34s |  And other than that, basically, in the end, we can all work together and hopefully we
1578.34s - 1582.98s |  come to some kind of cohesive conclusion where we can actually do things kind of like
1582.98s - 1586.42s |  a family versus apart from each other.
1586.42s - 1588.06s |  And I'll make sure to get these slides online.
1588.06s - 1590.02s |  Sorry, kind of depressed for time and everything.
1590.02s - 1591.54s |  I was going kind of slow initially.
1591.54s - 1597.94s |  Normally I'm pretty spitfire, but tried to talk a little slower.
1597.94s - 1599.66s |  But that's the end.
1599.66s - 1601.46s |  Any questions really quick before we get out?
1601.46s - 1605.21s |  All right.
1605.21s - 1605.41s |  Good to go.


url: https://www.youtube.com/watch?v=glTCi9SaJbM
title: DEF CON 32 - Exploiting Voice Cloning in Adversarial Simulation - Mark Foudy
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=glTCi9SaJbM",
  "title": "DEF CON 32 - Exploiting Voice Cloning in Adversarial Simulation - Mark Foudy",
  "description": "We live in an era where voice verification is increasingly adopted in security protocols. The potential for abuse through voice cloning technology presents a significant and growing threat to cybersecurity. This talk dives into the alarming capabilities of deep learning to create highly convincing voice clones. Using my own voice as a case study, I will demonstrate a recorded simulation where the cloned voice successfully bypasses several major institutions\u2019 voice verification systems. This presentation will outline the tools and techniques leveraged for voice cloning, discuss the pressing risks involved, and explore strategic countermeasures for red teams. The aim is to equip offensive security researchers with a nuanced understanding of voice cloning technology, emphasizing its implications for threat emulation and defensive strategy formulation. Attendees will gain insight into adversary tactics using publicly available voice samples for simulating voice-based attacks, providing a clear perspective on preparing defenses against such AI-driven threats.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1535,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Hello, my name is Mark Foody, and my presentation is called exploiting voice cloning and adversarial simulation.
7.00s - 16.00s |  I'd first like to thank Adversary Village for giving me the opportunity to present my research, the DEF CON 32, and it's an honor to be here among so many talented individuals.
16.00s - 19.00s |  Okay, so let's dive in. Who am I?
19.00s - 28.00s |  As I mentioned, my name is Mark. I wear many hats. I'm an offensive security researcher, a father, a husband, a proud cat dad.
28.00s - 39.00s |  In addition to my work in AI and security, I founded Neurodiverse Hackers, which is a community dedicated to highlighting and addressing the unique needs of neurodiverse individuals in the hacking community.
39.00s - 45.00s |  Now let's get to the heart of today's presentation. We're going to explore the fascinating and unsettling world of voice cloning.
45.00s - 58.00s |  So, initially I had planned on demonstrating how easy voice verification systems could be bypassed, but due to the legal gray areas concerning using a real-time voice clone to access my own bank account,
58.00s - 65.00s |  I decided to focus on showing how clone speech can be made undetectable by two anti-spoofing mechanisms.
65.00s - 74.00s |  While many commercial products can create realistic voice clones, they cannot defeat the voice verification services used by financial institutions, which detect anomalies.
75.00s - 76.00s |  Through mouse spectrograms.
76.00s - 81.00s |  To bypass anti-spoofing components, it's crucial to refine a voice model through the steps I'll present.
83.00s - 91.31s |  So, voice verification services are provided by companies like Nuance, Variant, Fortress Identity.
91.31s - 98.31s |  They're used by financial institutions such as Fidelity Bank, Wells Fargo, Citibank for secure authentication.
99.31s - 104.31s |  Although these services enhance security through voice biometrics, they remain vulnerable to exploitation.
104.31s - 114.31s |  Today I'll discuss the methods used to bypass these technologies and focus on adversarial training required to enable a voice clone model to bypass anti-spoofing verification systems.
116.31s - 126.31s |  The purpose of this talk is not to delve into the voice cloning process itself, but to explore how adversarial training can create a voice clone indistinguishable from natural human speech.
126.31s - 132.31s |  So, I'll walk through the eight key elements that can make a synthetic voice practically imperceptible from a real one.
133.31s - 147.48s |  The thematically organized various approaches for defeating voice verification, I developed the acoustic standards for modifying spoof speech.
148.48s - 155.48s |  This is like a set of standards focused on key aspects of audio manipulation, making spoof speech indistinguishable to voice verification.
156.48s - 167.48s |  Each step in acoustics provides a structured approach to bypass the rigorous verification and streamlining the process used by other researchers into accessible steps that anyone can follow.
168.48s - 173.48s |  Implementing these techniques requires combining signal processing and machine learning algorithms.
174.48s - 182.48s |  So, after DEF CON, I will provide code examples and slides on GitHub to demonstrate how these adjustments can be made and automated and used to train a voice clone model.
183.48s - 184.48s |  Let's delve in.
185.48s - 187.48s |  Alright, so slide one. Acoustics.
188.48s - 194.48s |  In audio spoofing, adjusting silence intervals is crucial for creating speech that convincingly mimics genuine human interaction.
195.48s - 200.48s |  Natural communication includes pauses and starts at the end of speech.
201.48s - 208.48s |  These are known as leading and trailing silences, which can carry acoustic signatures like microphone static, breathing sounds, and other ambient noise.
209.48s - 211.48s |  These nuances are vital for making speech sound authentic.
212.48s - 219.48s |  So, the first task in adjusting silence intervals involves replacing the leading and trailing silence with natural silences extracted from genuine recordings.
220.48s - 228.48s |  This requires selecting silences that match the context of the spoofed speech and ensuring they exhibit natural variability and align with the intended environment.
229.48s - 234.48s |  Along with replacing leading and trailing silence, it's also essential to eliminate interword redundant silence.
235.48s - 242.48s |  Spoofed speech often has longer synthetic pauses due to its segmented nature of the speech synthesis process.
243.48s - 254.48s |  The goal is to reduce these gaps by inserting human-like silences that maintain the rhythm and flow of authentic speech, using advanced algorithms to model natural silence patterns.
256.89s - 259.89s |  So, then center spectrum boosting.
260.89s - 268.89s |  Center spectrum boosting is also a critical technique for enhancing spoofed speech because it manipulates frequency components to increase perceived authenticity.
269.89s - 279.89s |  Human speech has an energy concentration in the low to mid-frequency range, particularly between 1 and 4 kHz, which is vital for intelligibility and contains the most phonetic information.
280.89s - 290.89s |  Boosting these central frequencies makes synthetic speech sound more natural and less mechanical, helping it blend seamlessly into real-world audio environments.
291.89s - 297.89s |  Natural speech's mid-range frequencies contribute to clarity and distinguish human voices from synthetic ones.
298.89s - 305.89s |  Many audio classifiers and voice verification systems detect subtle clues within this range to differentiate genuine from spoofed speech.
306.89s - 312.89s |  So, making center spectrum manipulation essential for overcoming synthetic speech limitations.
313.89s - 322.89s |  Digital signal processing techniques amplify critical frequencies while suppressing higher frequencies and enhancing the signal's intensity within a targeted range.
322.89s - 329.89s |  Careful calibration ensures that the amplification maintains authenticity and avoids distortions.
330.89s - 336.33s |  Optimizing echo simulation.
337.33s - 341.33s |  Optimizing echo simulation is crucial for making synthetic speech more convincing and realistic.
342.33s - 347.33s |  Echoes naturally occur when a speech is recorded, adding depth and context by reflecting off surfaces.
347.33s - 354.33s |  These reflections help listeners perceive space and authenticity, often missing in synthetic voice generated by spoofing algorithms.
355.33s - 365.33s |  And the genuine recording echoes are subtle clues that aid in interpreting the recording's space, size, and nature, and they vary in amplitude and delay based upon the surface distance and characteristics.
366.33s - 375.33s |  To enhance the realism of spoofed speech, simulating natural echo patterns involves introducing slight time delay with copies of the original audio with progressively lower amplitudes.
375.33s - 387.33s |  This mimics how sound waves will bounce and decay in real world environments, and it's enhancing the audio's spatial qualities and challenging voice verification systems to detect the absence of natural reflections.
388.33s - 394.62s |  Upgrade frequency pre-emphasis.
395.62s - 406.62s |  While center spectrum boosting focused on enhancing the naturalness of synthetic speech by amplifying mid-ranges, frequency pre-emphasis targets the higher frequency ranges to improve speech quality and reduce noise.
406.62s - 417.62s |  Pre-emphasis involves boosting the amplitude of higher frequencies, typically between 1 and 6 kHz, which are less prominent in natural speech but critical for enhancing clarity and intelligibility.
418.62s - 426.62s |  The primary goal of frequency pre-emphasis is to adjust the frequency profile of synthetic speech so that it aligns more closely with natural human speech.
427.62s - 434.62s |  By applying pre-emphasis filters, we can emphasize higher frequencies to match synthetic characteristics and maintain a natural spectral balance.
434.62s - 440.62s |  This process reduces noise impact and makes the speech sound more realistic and robust.
441.62s - 453.62s |  So through careful calibration, pre-emphasis ensures speech retains its tonal quality without a distortion, making it more challenging for a voice verification system to detect any anomalies.
454.62s - 458.64s |  S is spectral noise reduction.
459.64s - 467.64s |  Spectral noise reduction is crucial for enhancing spoofed speech by removing unwanted noise artifacts that reveal its synthetic quality.
468.64s - 477.64s |  While natural speech includes subtle random background noise, spoofed speech often contains distinct machine noise due to the synthesis limitations.
478.64s - 485.64s |  Managing noise in the audio signal improves the perceived authenticity, making it more challenging for a detection system to identify.
486.64s - 493.64s |  The goal is to eliminate or minimize machine-generated noise that can serve as a cue for voice verification systems to reject the speech as cloned.
494.64s - 499.64s |  To align the noise profile of spoofed speech with natural human speech, we use a three-step strategy.
499.64s - 507.64s |  First, we use spectral gain filtering, which filters out the noise by analyzing frequency components and removing those below a set threshold.
508.64s - 517.64s |  Then we use dynamic noise filtering, which uses adaptive algorithms to adjust in real-time to the audio environment, ensuring continuous noise reduction.
518.64s - 529.64s |  Finally, through context-appropriate additive noise, such as ambient office or outdoor sounds, which is incorporated, it will often be used to mask synthetic artifacts and create more natural-sounding speech.
538.06s - 540.06s |  Tuning adversarial speaker regularization.
541.06s - 550.06s |  Tuning adversarial speaker regularization is a sophisticated technique used to make synthetic speech sound as if it was produced by a real speaker.
551.06s - 555.06s |  Masking any artifacts that could reveal its artificial origins.
556.06s - 565.06s |  This is achieved by using adversarial methods, often with machine learning models, to refine speech signals so that it closely matches the vocal characteristics of a targeted speaker.
566.06s - 576.06s |  By employing adversarial techniques, we can adjust the speech signal to align with the natural variability and dynamism of human speech, reducing the likelihood for it being flagged as synthetic.
577.06s - 581.06s |  To enhance speech authenticity, our strategy involves three steps.
582.06s - 594.06s |  First, we use adversarial training with generative adversarial networks to iteratively refine audio quality, allowing the generator to produce realistic samples while the discriminator evaluates their authenticity.
595.06s - 608.06s |  Second, we engrave the unique voice print of the targeted speaker onto the spoofed audio by adjusting prosodity, pitch, and timbre, which matches the genuine speaker's vocal characteristics.
609.06s - 615.06s |  Finally, regularization techniques smooth irregularities in speech signal, ensuring consistent tone and clarity through the audio.
621.10s - 622.10s |  Integrating additive noise.
623.10s - 626.10s |  Integrating additive noise is crucial for enhancing authenticity of spoofed speech.
627.10s - 633.10s |  Natural speech often includes background noises, added depth and context, while spoofed speech typically sounds too clean and artificial.
634.10s - 640.10s |  By strategically adding noise, synthetic speech can blend seamlessly into real-world environments, increasing its believability.
641.10s - 646.10s |  Additive noise makes synthetic qualities by introducing natural variations and imperfections present in real recordings.
647.10s - 655.10s |  It also helps disguise any artifacts or inconsistencies from the synthesis process, making spoofed speech sound more realistic.
656.10s - 661.10s |  To create a realistic audio environment, we can do three steps to do that.
662.10s - 669.10s |  First, we select noise sources that are contextually appropriate, such as typing sounds for an office setting or wind or traffic noise.
670.10s - 678.10s |  Second, we use algorithms to dynamically adjust the level and type of the noise that we're using, ensuring that it complements the speech without overwhelming it.
679.10s - 684.10s |  Finally, we maintain temporal and spatial consistency by aligning the noise with the speech's rhythm and flow,
685.10s - 690.10s |  carefully timing its introduction and adjusting spatial characteristics to match the perceived environment.
691.10s - 696.85s |  And C, we create model-agnostic approach.
697.85s - 700.85s |  Creating a model-agnostic approach is essential for enhancing spoofed speech,
701.85s - 708.85s |  ensuring that the techniques that use to generate or modify speech are not tied to any specific voice verification system or machine learning model.
708.85s - 713.85s |  This approach provides flexibility and adaptability, allowing for the development of spoofed methods
714.85s - 720.85s |  that can effectively bypass a wide range of detection systems, regardless of their underlying algorithms or architecture.
722.85s - 725.85s |  By focusing on techniques that are universally applicable,
726.85s - 732.85s |  a model-agnostic strategy exploits general weaknesses in speech processing to create a more convincing spoofed audio,
732.85s - 736.85s |  which is crucial as voice verification systems continue to evolve.
737.85s - 744.85s |  To enhance audio manipulation, we develop generalizable techniques that address common vulnerabilities across systems.
745.85s - 749.85s |  We focus on manipulating silence intervals, frequency emphasis, and noise integration,
750.85s - 753.85s |  based on fundamental speech processing principles.
754.85s - 758.85s |  Then, second, we create a flexible framework that allows easy adaptability
758.85s - 765.85s |  and testing on various techniques using modular design principles for component and algorithm intercompatibility.
766.85s - 770.85s |  Finally, we implement machine learning models that learn from diverse verification systems,
771.85s - 776.85s |  training on generalized features and patterns to ensure adaptability and effectiveness across different platforms.
777.85s - 778.85s |  All right.
779.85s - 783.22s |  As we conclude our exploration of acoustic standards,
786.78s - 789.78s |  it's evident that each element is crucial in refining the authenticity of spoofed speech.
789.78s - 793.78s |  These techniques provide insight into the weaknesses that can be exploited in voice verification systems
794.78s - 796.78s |  and highlight the areas where these systems need to evolve.
797.78s - 804.78s |  For cybersecurity professionals, understanding these enhancements lays the foundation for developing more robust defenses against audio spoofing.
806.78s - 808.78s |  By dissecting the methods used to create convincing spoofed speech,
809.78s - 813.78s |  cybersecurity experts gain a deeper understanding of the intricacies of audio manipulation.
813.78s - 816.78s |  This knowledge enables them to anticipate and counteract emerging threats,
817.78s - 819.78s |  strengthening the security posture of voice verification systems.
820.78s - 825.78s |  The acoustic standards offer a comprehensive framework for enhancing the realism of spoofed speech.
826.78s - 827.78s |  By applying these insights,
828.78s - 832.78s |  professionals can devise innovative strategies that detect and thwart sophisticated spoofing attempts
833.78s - 836.78s |  and build more resilient systems that withstand these challenges.
837.78s - 839.78s |  As we continue to innovate in this field,
840.78s - 842.78s |  it's essential to prioritize security, ethics, and responsibility
843.78s - 845.78s |  in the development and application of these technologies.
846.78s - 847.78s |  Thank you for your attention,
848.78s - 850.78s |  and I welcome any questions or discussions you may have.
851.78s - 852.78s |  Any questions?
862.26s - 863.26s |  I'm sorry.
884.81s - 906.68s |  I think the goal is text-to-speech,
907.68s - 908.68s |  especially from an adversary's perspective.
909.68s - 911.68s |  It's to get a clone replica of someone's speech
912.68s - 915.68s |  and to be able to bypass any verification systems
915.68s - 919.68s |  that would prevent access to banking records or what have you.
920.68s - 922.68s |  I think both in the sense that,
923.68s - 924.68s |  I think what you're saying is,
925.68s - 926.68s |  is the goal text-to-speech,
927.68s - 931.68s |  or is it mining speech samples from an actual speaker?
932.68s - 935.68s |  You have to mine speech samples from a speaker.
936.68s - 938.68s |  You have to start with your clone model
939.68s - 943.68s |  and then adding it in samples from your target.
944.68s - 951.68s |  The amount of samples you need to introduce varies
952.68s - 953.68s |  depending on the context,
954.68s - 955.68s |  but you have to start that way.
956.68s - 961.68s |  Implementing these techniques will allow you to expand that.
962.68s - 964.68s |  Taking a little bit of sample from a target
965.68s - 967.68s |  and being able to create a realistic voice clone
968.68s - 969.68s |  is possible using these techniques.
970.68s - 988.10s |  Does that answer your question?
988.10s - 989.10s |  I think it's a temporary thing.
990.10s - 991.10s |  I think it's a temporary thing.
992.10s - 993.10s |  Any other questions?
1011.41s - 1012.41s |  Absolutely.
1013.41s - 1014.41s |  The question was,
1015.41s - 1017.41s |  there are AI models in the works to create spoof speech,
1018.41s - 1021.41s |  but are there models also being used to defeat voice cloning?
1022.41s - 1023.41s |  Absolutely.
1024.41s - 1026.41s |  It's sort of a cat and mouse game in the sense that,
1027.41s - 1031.41s |  in fact, the models that exist to detect spoof speech
1032.41s - 1033.41s |  are probably better in some sense
1033.41s - 1034.41s |  than the models that make clone speech.
1035.41s - 1036.41s |  As I was saying,
1037.41s - 1038.41s |  when you look on the internet,
1039.41s - 1041.41s |  there's people selling voice clone technology.
1042.41s - 1044.41s |  None of that stuff is advertised
1045.41s - 1047.41s |  or is expected to defeat the voice biometrics
1048.41s - 1051.41s |  that are necessary for a career criminal or a cyber threat.
1052.41s - 1054.41s |  The technology is on that side,
1055.41s - 1058.41s |  but these steps that I've outlined
1059.41s - 1062.41s |  are ways that focus and attack
1063.41s - 1067.41s |  and ways that those AI speech models view spoof speech
1068.41s - 1070.41s |  and determine it and distinguish it from real speech.
1071.41s - 1072.41s |  We're going after the same places
1073.41s - 1074.41s |  that these models were looking at,
1075.41s - 1078.41s |  such as ambient noise and echo and pre-emphasis
1079.41s - 1080.41s |  and spectral boosting.
1081.41s - 1082.41s |  By addressing those,
1083.41s - 1086.41s |  we make spoof speech much harder to detect from real speech.
1087.41s - 1088.41s |  You know what I mean?
1089.41s - 1090.41s |  Any other questions?
1091.41s - 1093.78s |  Yeah, yeah, yeah.
1096.06s - 1097.06s |  Okay, just speak to me and I'll follow.
1098.06s - 1099.06s |  Yeah, yeah, yeah.
1100.06s - 1101.06s |  So I've heard from a lot of CEOs that are like,
1102.06s - 1103.06s |  I want you to put AI on it.
1104.06s - 1105.06s |  It needs to be AI. Put AI on my company.
1106.06s - 1107.06s |  And voice is obviously one of the options.
1108.06s - 1109.06s |  So given where the technology is now,
1110.06s - 1111.06s |  is that a bad recommendation?
1112.06s - 1113.06s |  Do you think that we shouldn't be using voice cloning?
1114.06s - 1115.06s |  Is it a...
1116.06s - 1119.06s |  Is voice verification a failed technology
1120.06s - 1121.06s |  looking for a problem?
1122.06s - 1124.06s |  Well, I'm a little biased, but I would say so.
1124.06s - 1125.06s |  I mean, I would...
1126.06s - 1127.06s |  You know, my own bank uses voice verification.
1128.06s - 1129.06s |  I mean, I don't know.
1130.06s - 1131.06s |  I'm not a CEO of a company,
1132.06s - 1133.06s |  but I would...
1134.06s - 1135.06s |  Voice verification is...
1136.06s - 1137.06s |  I mean, so like,
1138.06s - 1140.38s |  using these techniques I talked about,
1141.38s - 1143.38s |  you have almost like a 95% effective rate, right?
1144.38s - 1146.38s |  So I mean, the voice verification systems will advance,
1147.38s - 1149.38s |  but at the current state they're at now,
1150.38s - 1151.38s |  they are able to be defeated.
1151.38s - 1152.38s |  It just requires a voice clone model
1153.38s - 1154.38s |  that has been trained appropriately
1155.38s - 1156.38s |  to defeat them, right?
1157.38s - 1158.38s |  And that is something that any adversary
1159.38s - 1160.38s |  could figure out, could do, right?
1161.38s - 1162.38s |  I mean, with enough resources,
1163.38s - 1164.38s |  I mean, I can do it.
1165.38s - 1166.38s |  So if they can do it.
1167.38s - 1168.38s |  So yeah, I mean, if I was a CEO,
1169.38s - 1170.38s |  I would find other ways to like, you know,
1171.38s - 1173.38s |  like to secure myself in voice.
1174.38s - 1175.38s |  Because I mean, we've already seen in the news
1176.38s - 1177.38s |  other...
1178.38s - 1179.38s |  Like a bunch of different situations
1179.38s - 1180.38s |  where this has happened, you know?
1181.38s - 1182.38s |  And it'll, yeah.
1183.38s - 1184.38s |  Does that answer your question?
1185.38s - 1186.38s |  Okay.
1186.38s - 1189.55s |  Anybody else, please?
1190.55s - 1191.55s |  Anybody?
1192.55s - 1193.55s |  Are you scared?
1194.55s - 1195.55s |  It's going on GitHub.
1196.55s - 1197.55s |  I'll add the code.
1198.55s - 1199.55s |  I was going to put the code up,
1200.55s - 1201.55s |  but then I thought, you know,
1202.55s - 1203.55s |  I hate it when people just like throw code
1204.55s - 1205.55s |  and then I'll have more like code
1206.55s - 1207.55s |  and more like explanations
1208.55s - 1209.55s |  of how to implement each of these techniques,
1209.55s - 1210.55s |  but this was a talk that was like,
1211.55s - 1212.55s |  could have been a workshop
1213.55s - 1214.55s |  and I just had to pare it down.
1215.55s - 1216.55s |  So there's a lot of cutting,
1217.55s - 1218.55s |  like a lot of cutting.
1219.55s - 1220.55s |  But I promise to release that.
1221.55s - 1224.60s |  Okay.
1225.60s - 1226.60s |  Anybody else?
1227.60s - 1228.60s |  What's up?
1229.60s - 1230.60s |  It's all right.
1231.60s - 1232.60s |  No, please do.
1233.60s - 1234.60s |  Come on.
1235.60s - 1236.60s |  Yep.
1237.60s - 1238.60s |  It's a great question.
1238.60s - 1239.60s |  It's a great question.
1240.60s - 1241.60s |  It's a great question.
1242.60s - 1243.60s |  So that's an awesome question.
1244.60s - 1245.60s |  The question is,
1246.60s - 1247.60s |  is like a clone speech indistinguishable
1248.60s - 1249.60s |  to the verification system
1250.60s - 1251.60s |  or to a human listener?
1252.60s - 1253.60s |  So that's a really great question.
1254.60s - 1255.60s |  So like I would say this,
1256.60s - 1257.60s |  like if someone clones my voice
1258.60s - 1259.60s |  and calls my wife,
1260.60s - 1261.60s |  she's probably going to figure out it's not me
1262.60s - 1263.60s |  because not just my voice,
1264.60s - 1265.60s |  but just sort of the speaking patterns
1266.60s - 1267.60s |  might not be the same.
1268.60s - 1269.60s |  Right.
1269.60s - 1270.60s |  And there's situations like
1271.60s - 1272.60s |  some woman had like,
1273.60s - 1274.60s |  somebody had done the same thing with their daughter
1275.60s - 1276.60s |  and they were like,
1277.60s - 1278.60s |  it didn't sound right,
1279.60s - 1280.60s |  but it sounded like her but not like her.
1281.60s - 1282.60s |  So it depends who we're talking about.
1283.60s - 1284.60s |  Like this person works at the bank
1285.60s - 1286.60s |  who relies on the voice verification system
1287.60s - 1288.60s |  to say, yeah, this sounds authentic.
1289.60s - 1290.60s |  That's probably going to be able to be bypassed.
1291.60s - 1292.60s |  My wife, I mean,
1293.60s - 1294.60s |  gosh, I hope not.
1295.60s - 1296.60s |  So yeah, I mean,
1296.60s - 1297.60s |  so when I call my bank,
1298.60s - 1299.60s |  I call it, like I try to like,
1300.60s - 1301.60s |  I just, you know,
1302.60s - 1303.60s |  and it's like to try to, you know,
1304.60s - 1305.60s |  voice changes, like, you know,
1306.60s - 1307.60s |  like your voice can change.
1308.60s - 1309.60s |  So it's really like,
1310.60s - 1311.60s |  it's not like a fingerprint
1312.60s - 1313.60s |  that it's like it's harder to modify.
1314.60s - 1315.60s |  I mean, people's voice changes with age.
1316.60s - 1317.60s |  So yeah, does that make sense?
1318.60s - 1319.60s |  Yeah, yeah, yes and no.
1320.60s - 1321.60s |  The context depends.
1322.60s - 1323.60s |  But yeah, yeah.
1324.60s - 1329.38s |  Anybody else?
1330.38s - 1333.17s |  Yeah, so there's,
1334.17s - 1335.17s |  that's a great question.
1336.17s - 1337.17s |  So there is like open source data sets
1338.17s - 1339.17s |  out there that are used
1340.17s - 1341.17s |  by voice verification systems
1342.17s - 1343.17s |  to sort of refine,
1344.17s - 1345.17s |  train their models on.
1346.17s - 1347.17s |  And they're available like, you know,
1348.17s - 1349.17s |  there's ASD spoof data sets.
1350.17s - 1351.17s |  There's other ones out there
1352.17s - 1353.17s |  and you can use them.
1354.17s - 1355.17s |  And just like the voice verification
1356.17s - 1357.17s |  companies use them,
1358.17s - 1359.17s |  adversaries can use them also
1360.17s - 1361.17s |  to sort of train on
1362.17s - 1363.17s |  Is that, so that, you know,
1364.17s - 1365.17s |  that's what, is that your question?
1366.17s - 1367.17s |  Like, and so,
1368.17s - 1369.17s |  if I was going to train,
1370.17s - 1371.17s |  well, so I would start off by,
1372.17s - 1373.17s |  well I did, I mean I trained,
1374.17s - 1375.17s |  I started off by a generalized voice data set.
1376.17s - 1377.17s |  Like there's one,
1378.17s - 1379.17s |  it's like a Lynda Johnson,
1380.17s - 1381.17s |  Lynda Johnson speech.
1382.17s - 1383.17s |  It's like 30,000 voice samples.
1384.17s - 1385.17s |  And I'd feed that into like my model,
1386.17s - 1387.17s |  right, to start off with.
1388.17s - 1389.17s |  And let it train on that.
1390.17s - 1391.17s |  It took about a week
1392.17s - 1393.17s |  and then what I did
1394.17s - 1395.17s |  was I take voice samples of myself,
1396.17s - 1397.17s |  like which are like maybe 100, right,
1398.17s - 1399.17s |  which are similar to what you could get,
1400.17s - 1401.17s |  let's say on this YouTube video
1402.17s - 1403.17s |  if someone was to cut my voice
1404.17s - 1405.17s |  into segments, right.
1406.17s - 1407.17s |  And I trained it on that
1408.17s - 1409.17s |  and it gets pretty close
1410.17s - 1411.17s |  but it's not going to defeat
1412.17s - 1413.17s |  verification unless I address ambient noise.
1414.17s - 1415.17s |  I mean, because the way
1416.17s - 1417.17s |  voice verification works
1418.17s - 1419.17s |  is it takes the digital,
1420.17s - 1421.17s |  it takes the digital signal
1422.17s - 1423.17s |  in a much different way than we are
1424.17s - 1425.17s |  and it's looking for
1426.17s - 1427.17s |  like differences in frequency
1428.17s - 1429.17s |  and like pitch
1430.17s - 1431.17s |  and it knows which things are
1432.17s - 1433.17s |  common with smooth speech
1434.17s - 1435.17s |  and so it picks it up.
1436.17s - 1437.17s |  So as long as you can like manipulate
1438.17s - 1439.17s |  the synthetic speech
1440.17s - 1441.17s |  in order to sort of bypass
1442.17s - 1443.17s |  those like, you know,
1444.17s - 1445.17s |  target areas,
1446.17s - 1447.17s |  then yeah, I mean,
1448.17s - 1449.17s |  and it's doable.
1450.17s - 1451.17s |  I mean, you know, other people have done it.
1452.17s - 1453.17s |  Everyone can do it, you know, I mean.
1454.17s - 1455.17s |  So, what's that?
1462.28s - 1492.75s |  In a sense, that's what,
1495.32s - 1496.32s |  what's that?
1497.32s - 1498.32s |  Okay, I'm being told
1499.32s - 1500.32s |  I have to answer this offline.
1501.32s - 1502.32s |  Yes, that's, yeah,
1503.32s - 1504.32s |  I guess we're done for time
1505.32s - 1506.32s |  but do we test it against,
1507.32s - 1509.76s |  sorry,
1511.76s - 1512.76s |  can I answer that afterwards
1513.76s - 1514.76s |  because I'm being told we got to stop
1515.76s - 1516.76s |  and it's like, it's a little more deeper question.
1517.76s - 1518.76s |  It's a little more complicated to explain
1518.76s - 1519.76s |  but the short answer is yes.
1520.76s - 1521.76s |  Okay, we'll just come see me
1522.76s - 1523.76s |  and we'll talk.
1524.76s - 1525.76s |  I'll talk, I'll be here afterwards.
1526.76s - 1527.76s |  I'm not going anywhere.
1528.76s - 1529.76s |  So, anybody's got questions,
1530.76s - 1531.76s |  want to hang out, chat, talk.
1532.76s - 1533.76s |  I'm cool with it.
1534.76s - 1535.76s |  All right, man.
1535.76s - 1536.76s |  Thank you for coming to my talk, man.


url: https://www.youtube.com/watch?v=SPGt3M4rXJU
title: DEF CON 32 - MicroHard More Like MicroEasy to Exploit - Ricky Lawshae
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=SPGt3M4rXJU",
  "title": "DEF CON 32 - MicroHard More Like MicroEasy to Exploit  - Ricky Lawshae",
  "description": "Microhard is a Canadian-based company that specializes in long range \"robust\" radio equipment. They are used in SCADA environments, point-of-sale terminals, power utilities, and more. From a security standpoint, however, some of their products are anything but \"robust\". And they have a habit of hiding their vulnerability fixes behind intentionally vague release notes, which will make this even more fun! (No, I'm not bitter at all) Command injections and buffer overflows abound, as well as a lesson or two in the need for a \"robust\" secure development process.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1096,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Okay, so my name is Headless Zeke, Ricky Lausche, and this is my talk,
7.00s - 12.00s |  Micro Hard More Like Micro Easy. Pause for laughter, and off to a great start.
17.64s - 22.64s |  Okay, so yeah, first off, let me introduce myself. I'm a principal security researcher at Keysight
24.88s - 29.88s |  Technologies. I'm based out of Austin, Texas. I focus mainly on security,
30.04s - 35.04s |  offensive IOT research, and I've been doing this kind of stuff professionally since 2009.
37.44s - 42.44s |  And I speak at conferences fairly regularly. I've spoken at DEF CON like five times on the actual
45.44s - 50.44s |  stages, and this is my first time speaking at IOT Village. And then I have several hobbies. Most of
51.44s - 56.44s |  them involve me drinking whiskey. Okay, so that's who I am. Let's talk about who Micro Hard is.
62.32s - 67.32s |  They're a Canadian-based device manufacturer. They make basically cellular bridges for
71.46s - 76.46s |  Ethernet and serial devices. They're used in lots of different environments that people really
77.06s - 82.06s |  care about, such as like power utilities. I see unmanned vehicles listed on their list of
87.20s - 92.20s |  industries. You know, just basically everywhere you could possibly think of needing to remotely
93.70s - 98.70s |  access a device, they claim to be involved in some way. Okay, so that's Micro Hard as a
98.70s - 103.70s |  company. Let's talk about the device that we're going to be looking at today. It's called a
108.90s - 113.90s |  Bullet LTE-NA2. NA is for North America. So yeah, this is an LTE bridge for adding cellular
117.14s - 122.14s |  connectivity to serial and Ethernet devices. You know, it's meant for managing installations
122.90s - 127.90s |  remotely. This is a quote from their website. Connect any device, old and new, serial or
133.64s - 138.64s |  Ethernet and provide cellular remote access using the Bullet LTE-NA2. You know, what could
140.08s - 145.08s |  possibly go wrong? So I actually got this device because I was doing a security audit for a
146.04s - 151.04s |  utility company and they were wanting to deploy a bunch of different devices and wanted us to
154.00s - 158.98s |  check the security of the devices and this was one of them. And I did not end up recommending
158.98s - 163.98s |  that they deploy this in the field. And you'll see why. Okay, so first off, from a hardware
170.42s - 175.42s |  perspective, it's a 32-bit ARM Cortex A5 processor, which you can see here. It's a 32-bit
177.06s - 180.06s |  processor. You can see in the top view, this is kind of like a, you know, the top of the
180.06s - 185.06s |  board and the bottom of the board kind of picture. It's got down in the bottom of the top
186.94s - 191.94s |  view next to that orange-ish, yellow-ish thing is a Spansion flash firmware chip, 128 megs.
196.84s - 201.84s |  The entire file system is read-write, which is pretty awesome. And then it's also got 256 megs
202.58s - 207.58s |  of RAM. And then on the underside of the board, they've got this QuekTel modem, an EC25-AF.
212.26s - 217.26s |  And then they've also got connections for a SIM card slot, POE, Ethernet, USB, and serial in
222.00s - 230.04s |  addition to a couple of programmable IO ports. And then from the firmware perspective, the
230.44s - 235.44s |  firmware updates are completely unsigned and unencrypted, so you can pretty easily forge your
238.98s - 243.98s |  own if you wanted to. And they were also easy to extract with binwalk. Inside the firmware
247.32s - 253.52s |  updates, it's got the boot loader, it's got the Linux kernel, and it's got a full SquashFS
253.52s - 258.52s |  file system. So basically you could fully emulate this system if you were so inclined to
260.56s - 268.28s |  pretty easily. And then the software itself, the OS, is based loosely on OpenWrt, running a
272.52s - 277.52s |  Linux 3.6.9 kernel. In the version that I'm going to be demonstrating today, they were using
282.44s - 287.44s |  UHT2PD for web. They changed to that in the subsequent version and you'll see why they, why
287.92s - 292.92s |  they decided to change it. Um, and then, yeah, they use DropBear for SSH and TelnetD for
296.06s - 301.06s |  Telnet, kind of. Um, they actually have, whenever you log in with one of those services, uh, they
303.36s - 310.04s |  end up dropping you into like a, a jailed debug environment, um, which we'll talk about
310.04s - 315.04s |  extensively, uh, later on. And then on the UDP side, uh, they've got a discovery module,
317.48s - 323.22s |  discovery service, that basically, um, depending on the type of device you're using, will
323.22s - 330.22s |  send out a discovery probe, or will answer a discovery probe on one of these three ports and
330.22s - 336.75s |  give you a lot of information back. So, it wouldn't be one of my talks if I didn't, uh, discuss
339.53s - 346.98s |  a discovery protocol because I love discovery protocols. So on this one, like I said, it
346.98s - 351.98s |  sends, uh, or it listens for broadcast UDP messages, uh, port 2077, or 20077 is for, uh, 3G
358.82s - 363.82s |  devices, 87 is for IP based devices, and 97 is for LTE devices. So this one would respond, uh,
367.10s - 372.10s |  to broadcast messages it gets on port 20097. Uh, the magic probe is the same across the board.
373.10s - 378.10s |  And let's look at what that looks like. Um, so you can see, I'm, this is a scanner that I
382.54s - 386.88s |  wrote, um, where I just like, send out that broadcast packet to each one of those three
386.88s - 391.88s |  ports, and then I listen for responses. And so this is what the response looks like on the wire.
394.72s - 399.72s |  Um, one kind of annoying thing, um, is they, um, will respond to messages that are
402.72s - 408.56s |  sent to you from a random port on their side to your source port, but on the broadcast
408.56s - 413.56s |  address, which makes it really hard to correlate, um, responses that you get. Okay, so the
416.89s - 421.89s |  discovery, uh, response contains a lot of useful info. Uh, it's got the MAC address and the IP
423.53s - 428.53s |  address. Um, it's also got the host name and the SSID, um, for any kind of wireless, uh, stuff.
428.85s - 433.85s |  Um, and then it has the model name and the firmware version. Uh, and then it's got this thing
438.19s - 443.19s |  called NMS, um, that's the network management software. It's like their cloud based, um, thing
445.93s - 451.01s |  where you can register all of your devices and track the GPS location of all of them. Um, it's
451.01s - 455.85s |  got the domain and password hash, but I'm not going to be talking about NMS today, um,
455.87s - 460.87s |  because that's not part of this talk. Um, okay, so, and, and yeah, I wrote, uh, a scanner and
463.87s - 471.70s |  response parser and I'll put it up on my GitHub, which I'll link to later. Okay, so, uh,
471.70s - 477.48s |  let's, let's actually get into the bones. Uh, so the web management portal, this was kind of
477.48s - 483.28s |  the main focus of my audit when I was originally looking at these devices. Um, like I
483.32s - 488.32s |  mentioned earlier, it's UHC2PD, uh, based on the version from OpenWRT in 2014. Um, it's
492.76s - 499.30s |  used for configuring basically every aspect of the device. Um, and it is also reachable from
499.30s - 504.30s |  LAN and WAN side. Um, and that's enabled by default and you have to actually turn that off, um,
506.80s - 512.88s |  if you don't want it reachable from the WAN side. Um, but the best part is it's all shell
512.88s - 521.12s |  scripts. So like this is, this is the directory listing, um, and it's literally like every
521.12s - 526.12s |  single page is a shell script wrapped with a GUI. Um, so, you know, of course, uh, there are
529.16s - 535.04s |  multiple command injections throughout this thing. Um, they're all, all, uh, post-auth, so
535.04s - 542.04s |  you need a valid user account in order to access these pages. Um, so yeah, multiple command
542.04s - 549.10s |  injections, um, my example that I'm showing today, uh, is with the diagnostics page. Um,
549.10s - 554.64s |  because of course it implements ping, um, and if it has ping, it has command injection every
554.64s - 559.66s |  single time. Um, oh my god, was that really my time warning? Okay, I have to, I have to really
559.66s - 564.66s |  book it. Okay, um, so, so yeah, it has ping, so they tried to sanitize input but it failed
564.66s - 569.66s |  pretty horribly. Um, they just sanitized the host name, didn't worry about any of the other
573.20s - 579.40s |  arguments that you put in there. Um, so yeah, just leave host name blank and then put
579.40s - 586.48s |  whatever command you want, um, all in the account parameter. Uh, and let's show a demo of
586.48s - 591.48s |  that real quick. Okay, I'm not going to, I'm not going to go into, uh, lots of the, uh,
595.26s - 600.36s |  details of the exploits because I'm about to run out of time already. Um, but yeah, so this
600.36s - 605.36s |  is, this is, uh, post-auth, so, uh, you need a, a valid user name and password. But then you
611.10s - 616.10s |  run that and eventually you will, hey, you got a root shell. Um, because you injected a, you
617.10s - 622.10s |  know, whatever command you wanted to run and it has netcat on it, so I was able to get a root
624.90s - 632.05s |  shell pretty easily with that one. Okay. We're gonna, we're gonna hurry up. Okay, so yeah,
637.90s - 643.80s |  like I said, those, those, um, vulns were all post-auth, um, but I really wanted something
643.80s - 648.68s |  that was pre-auth, um, because that's so much sexier. Um, so I started looking at the
648.70s - 655.24s |  authentication, uh, the way they handled authentication. Um, and as far as logging in, um,
655.24s - 660.24s |  it was vanilla OpenWRT. They used, um, basic auth. Um, so basically base64 encoded user
663.92s - 668.92s |  colon pass. Um, and, and so since this is, you know, UHC2PD that's part of OpenWRT, you
672.46s - 678.00s |  think it would be very, uh, well vetted and everything, but it is an open source project, so
678.02s - 683.02s |  they were able to make their own modifications. Um, and so logins were generic. Logouts, um,
685.90s - 691.70s |  was where they made a mistake. Um, basically they wanted to set the basic auth header to
691.70s - 696.70s |  logout colon logout. Um, and then they did like a stir copy of that buffer to a statically
699.64s - 704.64s |  sized, uh, buffer. Um, and then they could compare what it was to logout logout and, and, you
705.32s - 710.32s |  know, log the person out that way. Um, but yeah, they didn't do any bounce checking or
712.50s - 717.50s |  anything. Um, so, so yeah, you can see, I'm just gonna skip past this cause I'm running out of
719.40s - 724.40s |  time. Um, but yeah, you can see, uh, you know, uh, stir copy, uh, and, and yeah, yeah.
724.88s - 729.88s |  Okay, let's do another demo. I am actually gonna talk about the code of this one because it was
735.62s - 740.62s |  very, uh, it was a very pat myself on the back kind of thing. This was my, my first ever in
744.50s - 749.50s |  the wild ARM ROP exploit. Um, so basically, um, yeah, so, so they do have dap and
754.70s - 761.64s |  ASLR and I wasn't able to find like a, a, um, uh, memory leak or anything to, to leak the base
761.64s - 766.64s |  address of libc, um, or UC libc. Um, so I, um, for the purposes of this demo, I disabled ASLR
772.66s - 778.90s |  but it is the lame version of ASLR where they only randomize the, the top part. Um, so in
778.90s - 783.90s |  theory you could brute force, um, by just like picking, picking an address for the base of UC
786.80s - 792.00s |  libc and then just trying over and over again and it'll just crash the website if it doesn't
792.00s - 798.28s |  work and if it, you know, if it eventually works then you get a shell. Um, but yeah, so, so
798.28s - 803.28s |  basically just, uh, you know, call, calling, uh, system, uh, from UC libc and passing, uh,
803.38s - 808.38s |  this, this command as the argument to UC libc. And this one, hey, that was really fast. So,
821.17s - 825.33s |  yeah, no authentication required for that one because it's, it's exploiting the
825.33s - 830.35s |  authentication protocol. So there's that one. And, okay, so I disclosed those back at, back
845.91s - 850.91s |  at the, um, when I was doing the audit originally. Um, they fixed it in, uh, R1112, um, by
855.05s - 860.05s |  adding more, uh, sanitization, um, and then they switched from using UHT TPD to using light
863.09s - 868.09s |  TPD. Um, so they no longer use UHT TPD. Um, but it's still all shell scripts. Um, so, so
870.63s - 875.83s |  yeah, it, um, that was the end of the audit and, um, I kind of stopped thinking
875.87s - 881.11s |  about the device. This release note still burns me to this day though because that was the
881.11s - 886.49s |  extent of the release note that they used for fixing all of my critical vulnerabilities is
886.49s - 891.49s |  miscellaneous housekeeping tasks that really, really bugged me. Okay, so, uh, cut to like a
894.25s - 899.33s |  few months ago. I decided to dig this device back out and look at it again. And this time
899.33s - 904.33s |  around I was looking at the telnet portal. Um, so like I mentioned before, um, it's, um,
906.33s - 911.67s |  a jailed environment but they give you lots of access to like, uh, QT commands for that
911.67s - 917.65s |  quack tail modem, or not QT, uh, AT commands for the quack tail modem. Um, so yeah, you can
917.65s - 922.65s |  see they give you lots of commands. Um, and that's handled by slash bin slash CLI test. Um,
926.45s - 932.13s |  that's spawned every time you log in as the admin user. Um, and that defines all of the AT
932.49s - 938.63s |  commands but, uh, not all of the AT commands were, were documented. Okay. Um, so, so yeah,
938.63s - 944.27s |  there was an undocumented command called ATM bash command. Um, that lets you run two bash
944.27s - 950.68s |  commands. Uh, PS and cat. Uh, and that's it, supposedly. Um, but the way they verified that
953.28s - 959.56s |  is by using, uh, str, str in case compare. And they were using the length of, uh, what they
959.58s - 964.58s |  were comparing from either PS or cat. So as long as the string, like, began with PS or cat, uh,
967.12s - 973.20s |  then you could put whatever you wanted at the end of it. Um, so, so basically, uh, yeah, you
973.20s - 979.34s |  just do like PS semi-colon and then another command and there, there you go. Okay, one last
979.34s - 987.79s |  demo and then, and then, um, I'm, I'm basically done. Okay, so again, post-auth, ray, there
987.79s - 1002.10s |  you go. Okay, so let's just blast through these last couple of slides to wrap up. Um, okay, so
1011.74s - 1016.34s |  that one was actually coincidentally fixed like the month before I found it, um, which was
1016.34s - 1021.34s |  also kind of annoying. Um, but the fix, like, I mean, it was, it was basically just in, in bash
1021.96s - 1026.96s |  command, they removed that one and didn't touch anything else and may have also added in some
1029.30s - 1034.30s |  brand new command injection forms in the latest firmware. Um, but yeah, so, uh, you can see
1036.78s - 1041.68s |  where they were trying to, to secure things and then they just failed miserably every single
1041.68s - 1046.68s |  time. Um, they need actual, like, you know, secure development processes. Um, and also I, I
1047.50s - 1052.50s |  get really pissed off about the vague release notes because in my opinion it like minimizes
1055.46s - 1060.88s |  the impact. If I saw something that just said, you know, miscellaneous housekeeping tasks and
1060.88s - 1066.88s |  I'm running in a, um, critical environment, I'm gonna completely ignore that update, uh,
1066.88s - 1072.18s |  because it seems like it's something I don't have to install and so it's just leaving me still
1072.18s - 1077.26s |  vulnerable. Um, but yeah, and then if it has command, er, if it has ping, it has command
1077.26s - 1082.26s |  injection. And that's, uh, how you get in touch with me. I'm HeadlessEc on most things. Um,
1084.90s - 1089.90s |  that's my GitHub. Um, and yeah, that is it. Sorry if I went over time. That's it.


url: https://www.youtube.com/watch?v=Z38pTFM0FyU
title: DEF CON 32 - Incubated ML Exploits: Backdooring ML Pipelines w Input Handling Bugs - Suha Hussain
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=Z38pTFM0FyU",
  "title": "DEF CON 32 - Incubated ML Exploits: Backdooring ML Pipelines w Input Handling Bugs - Suha Hussain",
  "description": "Machine learning (ML) pipelines are vulnerable to model backdoors that compromise the integrity of the underlying system. Although many backdoor attacks limit the attack surface to the model, ML models are not standalone objects. Instead, they are artifacts built using a wide range of tools and embedded into pipelines with many interacting components.\n\nIn this talk, we introduce incubated ML exploits in which attackers inject model backdoors into ML pipelines using input-handling bugs in ML tools. Using a language-theoretic security (LangSec) framework, we systematically exploited ML model serialization bugs in popular tools to construct backdoors. In the process, we developed malicious artifacts such as polyglot and ambiguous files using ML model files. We also contributed to Fickling, a pickle security tool tailored for ML use cases. Finally, we formulated a set of guidelines for security researchers and ML practitioners. By chaining system security issues and model vulnerabilities, incubated ML exploits emerge as a new class of exploits that highlight the importance of a holistic approach to ML security.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1781,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.75s - 8.11s | This text was transcribed using whisper model: large-v2

 Hey everyone, I'm Suha. I'm really excited to be here today. So let's get started. I
8.11s - 13.19s |  want to talk to you about ML security. Specifically, I want to talk about this
13.19s - 17.35s |  new class of exploits I identified called incubated ML exploits that
17.35s - 21.19s |  combine backdoors and input handling bugs. Don't worry if you don't know too
21.19s - 27.03s |  much about ML or ML security. I'll explain all the important stuff as we go along.
27.03s - 32.75s |  So who am I and why am I even talking to you today? I'm an engineer at Trail of
32.75s - 37.63s |  Bits where I focus on AI and ML security. I've been in the field for a few years
37.63s - 42.51s |  now. I graduated from Georgia Tech and I'm originally from Queens. Outside of
42.51s - 47.47s |  work, I like Brazilian jiu-jitsu, trying new restaurants, making things, and an
47.47s - 53.91s |  obscure card game called Q-Birds. So it's becoming pretty clear with ML and AI
53.91s - 57.63s |  popping up everywhere, people are figuring out how to trick these systems
57.63s - 61.95s |  based on how these models work. Maybe you've seen someone use prompt injection
61.95s - 66.03s |  to convince a chatbot to give them a refund. Or maybe you've seen this story
66.03s - 70.39s |  right here of protesters tricking self-driving cars with traffic cones.
70.39s - 74.43s |  Notice the fact that this trick is rooted in an understanding of the
74.43s - 80.59s |  training data for these models. So how can we actually construct our own useful
80.67s - 87.56s |  exploits against ML systems? Let's play a game of pretend real quick. You're a
87.56s - 91.28s |  college student and you really, really want the prize money for a robotics
91.28s - 97.48s |  competition. So naturally, you decide to sabotage another team. Side note, I don't
97.48s - 102.44s |  recommend this. I don't condone this. I've never done it myself. But anyway, the
102.44s - 106.76s |  competition requires teams to build a tiny autonomous vehicle that uses a
106.84s - 112.20s |  specific pre-trained model and stops at stop signs. So you find out that some of
112.20s - 116.04s |  these stop signs have these little stickers on them. And you also find some
116.04s - 119.96s |  flaws with how they've stored and distributed the model. Which, by the way,
119.96s - 125.28s |  isn't out of the question. ML artifacts are often widely shared
125.28s - 129.92s |  without any meaningful or substantial trust mechanisms. So you decide to grab
129.92s - 134.80s |  that file and inject a model backdoor in it using a file format RCE of some kind.
135.28s - 139.56s |  And then you put it back. Then on the day of the competition, you sit back and you
139.56s - 144.16s |  just watch as your competitor's robot, your competitor's vehicle just plows
144.16s - 148.80s |  through and ignores every stop sign with a sticker on it. What you just did is
148.80s - 155.20s |  execute an incubated ML exploit, which is what my talk is all about. So obviously,
155.20s - 159.68s |  the stakes of this story is just a lost robotics competition. But the idea of
159.68s - 164.72s |  attacking a real autonomous vehicle is a hallmark of model backdoor research. And
164.72s - 169.20s |  you can see that with the image on the left. So I'll let you use your imagination
169.20s - 174.84s |  to raise the stakes. So in my talk, first I'm going to tell you about this
174.84s - 179.28s |  framework that I've been using to bridge the gap between model and system security.
179.28s - 184.16s |  Because we can't continue to treat models as standalone objects. Next, I'll tell you
184.16s - 188.52s |  about these input handling bugs I found in model serialization and connect them
188.52s - 194.12s |  to backdoors. I'll do that by taking a page out of this subfield called LangSec.
194.12s - 197.92s |  So effectively, I'll be going through a bunch of examples of incubated ML
197.92s - 204.04s |  exploits and use LangSec to organize them. But first, I need to explain some stuff.
204.04s - 220.78s |  What even is a model vulnerability or an ML backdoor? So super briefly, you can
220.78s - 225.14s |  think of ML models as these squishy, flexible sequences of linear algebra
225.14s - 229.46s |  operations that are trained on tons and tons of data. There's a pretty popular
229.46s - 233.74s |  saying, all models are wrong, but some are useful. We're just saying that these
233.74s - 237.38s |  models aren't perfect. There are many different ways they can mess up or get
237.38s - 241.50s |  tripped up by something that might be unexpected to us. And that's the basis of
241.50s - 245.90s |  such model vulnerabilities. While popular examples of model vulnerabilities include
245.90s - 250.58s |  model inversion and membership inference, we're zooming in on one specific type,
250.58s - 256.58s |  model backdoors. So to be precise about it, a backdoor attack allows a malicious
256.58s - 261.42s |  actor to force an ML model to produce specific outputs given specific inputs.
261.42s - 264.94s |  Now, there's a couple of things that I think make backdoors really
264.94s - 269.14s |  interesting to study. First up, you can use them as primitives for other model
269.14s - 272.38s |  vulnerabilities, like membership inference. You can also identify
272.38s - 276.50s |  pre-existing, quote-unquote, natural backdoors in them. And there's also some
276.50s - 281.18s |  pretty strong evidence that suggests that this is an inherent threat.
281.18s - 285.54s |  Now, while there's a lot of awesome research on ML model attacks, they can
285.54s - 288.98s |  actually be pretty hard to exploit in the real world, with some exceptions,
288.98s - 292.98s |  of course. While there are multiple reasons for this, one thing that really
292.98s - 300.62s |  sticks out to me is the big gap between research and the real world. So for the
300.62s - 304.42s |  most part, many attacks and attack frameworks and tools restrict their
304.42s - 309.74s |  analysis to this formulation. An ML model receives an input and produces an
309.74s - 313.74s |  output. But this isn't an accurate representation of what an ML system
313.74s - 319.22s |  actually looks like. There's so much more going on in practice. Here's a software
319.22s - 323.54s |  architecture diagram for an ML system reviewed by Trail of Bits recently. This
323.54s - 327.94s |  is a system that uses the Ask Astro tool for RAG, and I've circled where the model
327.94s - 331.98s |  actually is in this photo. Do you see what I mean? We need to be looking at all
331.98s - 336.50s |  of this holistically. There's a large and evolving landscape of tools
336.50s - 342.54s |  being used in and for ML systems, and that brings me to the exploit framework.
342.54s - 347.98s |  So the title of my talk references an incubated ML exploit, but there's this
347.98s - 352.94s |  larger category of exploits called hybrid ML exploits that are important to
352.94s - 359.10s |  think about first. Specifically, a hybrid ML exploit chains a system security
359.10s - 363.02s |  issue with a model vulnerability. This can go in either direction, and you can
363.02s - 366.78s |  see that on the diagram. You can have a model vulnerability that exposes a
366.78s - 371.26s |  system security issue, or you could use a system security issue to exploit a model
371.26s - 377.34s |  vulnerability. So this part's pretty important. The big issue that I see with
377.34s - 381.90s |  ML security is that model security and system security are treated separately.
381.90s - 386.38s |  But what I need you to understand is that if you only know model
386.38s - 390.70s |  security, you're missing a big piece. And if you're only covering system
390.70s - 394.34s |  security, you're still missing a big piece. And if you're treating the two
394.34s - 398.58s |  processes completely independently, once again, you're missing a big
398.58s - 403.58s |  piece. You're then entirely ignoring the potential for hybrid ML exploits. This is
403.58s - 408.54s |  an emergent property. So your model is embedded in a system, and it's going to
408.54s - 412.42s |  interact with all of the different system components in new and exploitable
412.42s - 416.62s |  ways. So one thing you'll notice is that there's a lot of screenshots of paper
416.62s - 420.82s |  titles on this slide. That's because there have been specific instances of
420.82s - 425.30s |  hybrid ML exploits in the literature and in practice. They're just not called that
425.30s - 429.66s |  explicitly. Exploitable software gadgets have been used for backdoors. The
429.66s - 433.62s |  Summoning Demons paper up there at the top chained model evasion and memory
433.62s - 437.98s |  corruption. And the Learn System Security paper next to it has an example of a
437.98s - 442.34s |  poisoning attack that caused an exponential memory blow-up in an index
442.34s - 448.22s |  structure. But the ML security literature framework and tools are largely limited
448.22s - 452.90s |  to just that. Specific instances or implications. What I'm trying to do here,
452.90s - 456.54s |  what I want to be doing here, is treating this interaction explicitly and
456.70s - 462.38s |  systematically. And that's why I made this framework. So one kind of system
462.38s - 467.58s |  security issue is an input handling bug, and one kind of model vulnerability is a
467.58s - 474.30s |  model backdoor. Put that together and we get an incubated ML exploit, which
474.30s - 478.82s |  is a type of hybrid ML exploit where an attacker uses input handling bug to
478.82s - 483.10s |  inject a backdoor. So I made this diagram to make the distinction between the two
483.10s - 488.26s |  pretty clear. And here's the definition again. I'm going to leave the framework
488.26s - 492.90s |  here for now. We did end up going into a bit of a more formal model of
492.90s - 499.30s |  exploitation, including this exploit schema. But we'll return to that later. So
499.30s - 503.22s |  to backdoor a pre-existing model, the attacker should be able to change the
503.22s - 507.58s |  parameters or the architecture. Now at the level of extraction we're dealing
507.58s - 512.10s |  with, we can put input and component manipulation on the side for now. But how
512.10s - 517.22s |  this actually plays out can vary a lot. For example, sometimes the
517.22s - 521.54s |  attacker has control over some element of the training process, and they use
521.54s - 525.18s |  that to sneak in some manipulated data that changes the
525.18s - 529.86s |  model's parameters. That's usually called data poisoning. Or they might go a step
529.86s - 535.34s |  further and fiddle with the model source code to change the architecture. Now
535.34s - 539.42s |  before we talk about exploits, I want to explain a few things about input
539.42s - 554.42s |  handling bugs. So an ML model is stored as a file. To process these models, you
554.42s - 559.30s |  need parsers. And parsing these files into objects and back is deserialization
559.30s - 566.82s |  and serialization. But wait. Quoting Ange Albertini here, a file has no intrinsic
566.82s - 571.70s |  meaning. The meaning of a file, its type, its validity, its contents, can be
571.70s - 576.26s |  different for each parser or interpreter. Now this is the reason we can make cool,
576.38s - 580.94s |  potentially malicious file artifacts like polyglots and ambiguous files, which
580.94s - 586.34s |  I'll talk more about later. So I'm focused very specifically on bugs that
586.34s - 590.74s |  arise when you parse ML model files. There's also cool bugs in other parts of
590.74s - 594.62s |  the pipeline, but I'm picking ML model files for several reasons. The first
594.62s - 598.70s |  reason is, and I'm sure you all will agree with me on this, the most
598.70s - 604.22s |  important. I think it's fun. But more seriously, the security of ML file
604.26s - 609.42s |  formats has become increasingly important. Real malicious model files have
609.42s - 612.98s |  been found on the Hugging Face Hub, for example. And there's also just an
612.98s - 617.26s |  absolute ton of ML file formats out there. I've tried to list and organize
617.26s - 620.42s |  them in the repository in the middle, but what's important for you to take
620.42s - 624.10s |  away is that there's a large set of possibilities for these exploits, as well
624.10s - 627.98s |  as just fun hacks with these formats. And there's already a lot of great work
627.98s - 633.94s |  in this area, as shown on my slide. So file format tricks are within the
633.94s - 637.98s |  realm of LangSec, but this field actually thinks more abstractly about
637.98s - 642.70s |  inputs as a general class. LangSec applies formal language theory to system
642.70s - 647.30s |  security. It focuses on exploring input handling bugs or parser problems as a
647.30s - 651.38s |  big root cause for security issues. After all, lots of impactful
651.38s - 654.90s |  vulnerabilities like Heartbleed and Android Master Key have been parser
654.90s - 659.94s |  bugs. Now, while I like formal language theory, this talk isn't Theoretical
659.94s - 665.82s |  Computer Science 101. So just know that fundamentally what LangSec is saying
665.82s - 670.02s |  is, hey, let's treat all of the inputs as a specific language and make our
670.02s - 676.46s |  code just capable enough to understand that language properly. So my work is
676.46s - 680.54s |  centered around a specific taxonomy of input handling bugs, and these are all
680.54s - 684.42s |  the different bug classes. There are eight different types. Quick note, these
684.42s - 687.90s |  categories aren't actually completely distinct from each other. The one you
687.90s - 692.62s |  choose comes from a root cause analysis. So with the exception of one, I'm going
692.62s - 696.70s |  to show you multiple examples of each in ML tools and use them to build an ML
696.70s - 703.50s |  backdoor. So I'm going to run that one more time. In order to show
703.50s - 708.26s |  that input handling bugs are a vector, I identified issues with ML model
708.26s - 712.14s |  serialization across these different bug classes in order to construct ML
712.14s - 718.94s |  backdoors. So now we can dive into the most fun part, exploits. Now, for the
718.94s - 732.79s |  sake of time, I'm going to focus more on the useful gadgets for these exploits. So
732.79s - 736.67s |  these are some characters that play important roles in the ML ecosystem that
736.67s - 743.07s |  can help us understand the impact of exploits, of these exploits. So Alice, she
743.07s - 748.59s |  distributes models. She takes open source LLMs and fine-tunes them. The model she
748.59s - 753.59s |  distributes are what everyone else in our story is going to be using. Bob is a
753.59s - 757.91s |  frontline user who directly uses Alice's models in his own life. Maybe he has a
757.91s - 763.35s |  nice chat interface pulled up. There's Dave. Dave is a developer who's trying to
763.35s - 768.47s |  integrate these models into products. Frank is the end user who's relying on
768.47s - 772.67s |  Dave's products in his daily life. He's often, he might be unaware of the ML
772.67s - 779.39s |  models working behind the scenes. And now we have Chuck. Chuck is the attacker.
779.39s - 785.63s |  Our focus here will mainly be on how Chuck can impact Bob and Dave. So I'll
785.63s - 789.95s |  show, I'll describe some exploits involving the file formats associated
789.95s - 797.03s |  with PQL, PyTorch, TorchScript, ONNX, and SafeTensors. So this first category is
797.03s - 801.87s |  called non-minimalist input handling code. It sounds a little fancy, but all it
801.87s - 806.11s |  means is that the code used to check and parse these inputs is too complex. So an
806.11s - 811.23s |  attacker can potentially grab the necessary gadgets for their exploits. So
811.23s - 815.63s |  pickling is a serialization method that allows you to save arbitrary objects and
815.63s - 820.07s |  it's very, very common in the ML ecosystem. Recently, my co-worker Bojan
820.07s - 823.75s |  Milanov led the development of SleepyPickle, which is an incubated ML
823.75s - 829.35s |  exploit. And what it does is it chains a pickle RCE with model backdoors. So on
829.35s - 833.91s |  the right, you can see an LLM that has been backdoored to Phish users. The blog
833.91s - 838.39s |  post also has some examples of an LLM being used to
838.39s - 842.99s |  spread misinformation and even steal user data. But what's cool about this
842.99s - 847.15s |  exploit is that it can happen on the fly. So there's more room and possibilities
847.15s - 853.11s |  for an attacker than just uploading a malicious model. So what do I mean by
853.11s - 857.79s |  pickle RCE? Python pickles are compiled programs that run in a unique virtual
857.83s - 862.35s |  machine called a pickle machine, or PM for short. The PM interprets the pickle
862.35s - 866.83s |  file sequence of opcodes to construct an arbitrarily complex Python
866.83s - 872.99s |  object. But it has two opcodes, global and reduce, that can execute arbitrary code
872.99s - 876.87s |  outside of the PM, which makes it possible to construct malicious pickle
876.87s - 881.11s |  data. Now the underlying issue here is that the PM is more complex than
881.11s - 887.55s |  something that's only parsing ML models should be. So way back in the year 2021,
887.83s - 892.67s |  we released this tool called Fickling. This project was led by Evan Sultanik. To
892.67s - 896.47s |  our knowledge, Fickling was the first pickle security tool tailored for ML use
896.47s - 901.63s |  cases. It's a decompiler, static analyzer, and bytecode rewriter for Python pickle.
901.63s - 906.39s |  So it can help you detect, analyze, and even create malicious pickle files. So the
906.39s - 909.79s |  reason it's safe to run on potentially malicious files is because it
909.79s - 914.99s |  symbolically executes code using its own PM implementation. Relatively recently, I
915.11s - 918.91s |  added a PyTorch module to it to make it easy to statically analyze and inject
918.91s - 923.75s |  code into PyTorch files. But pickles are clearly bad for Bob. If Alice is
923.75s - 927.43s |  distributing models as pickle files, that makes it that much easier for Chuck to
927.43s - 934.39s |  inject a backdoor using a pickle RCE. So on to the next class. This term just
934.39s - 939.39s |  means you shouldn't try to correct invalid input, reject it altogether. I've
939.39s - 947.15s |  heard it referred to as the anti-robustness principle. So to deal with the issues
947.15s - 951.59s |  with pickling, many devs write these things called restricted unpicklers. Now,
951.59s - 955.71s |  those are subclasses of unpickler that try to enforce an allow list or a block
955.71s - 959.79s |  list. The thing is, they're actually not that hard to bypass. There's this
959.79s - 963.91s |  methodology called PainPickle that demonstrates how to automatically bypass
963.91s - 968.79s |  restricted unpicklers, which would enable arbitrary code execution and, to that
968.83s - 973.59s |  end, backdoors. So they identified eight different types of unpicklers and three
973.59s - 977.43s |  strategies that work against the vast majority of them. So much like pickle was
977.43s - 981.67s |  bad for Bob, restricted unpickling bypasses pose a problem for Dave, if he
981.67s - 988.19s |  relies on them in some fashion. Now we can talk about parser differentials. So
988.19s - 991.95s |  this happens when different parsers in a system read the same input but
991.95s - 997.23s |  interpret it differently. So when two parsers interpret the same file in
997.23s - 1001.91s |  different ways, that file is known as an ambiguous file. This is a very common
1001.91s - 1006.15s |  exploit technique. It's pretty good for bypasses. It means you can create an ML
1006.15s - 1011.15s |  model file that is benign for one system or system component but backdoored for
1011.15s - 1015.55s |  another. There's some more bigger implications for ML system exploitation
1015.55s - 1019.07s |  here that we'll talk a bit more about later. But just a quick note, whether or
1019.07s - 1022.99s |  not this is impactful at all depends on your system. So that's where you want to
1022.99s - 1028.63s |  do threat modeling, of course. So we actually were able to create two
1028.63s - 1032.55s |  differential proof of concepts with TorchScript. TorchScript is a popular
1032.55s - 1036.31s |  format to store ML models in for a couple of reasons, mainly performance and
1036.31s - 1040.91s |  portability. But you can make a parser differential with it and chain it to an
1040.91s - 1045.43s |  architectural backdoor. So that's because you can turn a PyTorch model into a
1045.43s - 1049.59s |  TorchScript one through tracing or scripting. And tracing doesn't incorporate
1049.59s - 1053.23s |  dynamic control flow. So all you have to do is represent the malicious
1053.23s - 1057.87s |  components for the backdoor with dynamic control flow. Now the second example was
1057.87s - 1062.91s |  found during the YOLO audit. Last year my team and I audited a popular open
1062.91s - 1066.91s |  source code base for computer vision called YOLOv7. They released standard
1066.91s - 1070.99s |  versions of their model and TorchScript versions for deployment. We noticed many
1070.99s - 1075.39s |  cases where tracing didn't capture the model accurately. After serialization and
1075.39s - 1079.35s |  deserialization, key information was lost and the usual PyTorch warnings
1079.35s - 1083.23s |  didn't show up. So to spot this differential, we used the TorchScript
1083.23s - 1088.95s |  automatic trace checker, TorchFX, and the TorchScript IR. So with what we found,
1088.95s - 1092.99s |  we created an input that made the two versions of the model act differently.
1092.99s - 1097.43s |  Effectively a backdoor attack. So once again, bad for Bob. He's getting a
1097.43s - 1101.03s |  fundamentally different model than the one Alice trained. So this breaks any
1101.03s - 1107.11s |  preexisting promises. So we also identified a parser differential with
1107.15s - 1111.67s |  SafeTensors. SafeTensors is another file format for ML models developed in
1111.67s - 1116.35s |  response to the insecurity of pickling. Last year I was on an audit of the
1116.35s - 1121.11s |  SafeTensors library where we identified the inclusion of JSON in the file format
1121.11s - 1125.03s |  as a source of parser differentials. Now JSON's pretty well known to be
1125.03s - 1128.63s |  underspecified. There's a bunch of exploits in the web security world that
1128.63s - 1132.55s |  leverage this. But the thing is, the reference SafeTensors implementation,
1132.55s - 1136.39s |  the main implementation, uses a cert parser, which is good. It's strict. It
1136.39s - 1139.99s |  rejects duplicate keys. But there's a bunch of external tools that use the
1139.99s - 1144.51s |  Python built-in JSON parser, which doesn't. So you can use a duplicate key
1144.51s - 1148.31s |  for the offsets to append backdoored weights and create manipulated SafeTensors
1148.31s - 1152.91s |  files that are rejected by the reference implementation but accepted by external
1152.91s - 1156.43s |  parsers. It has to be a weights-based backdoor because the weights and
1156.43s - 1159.91s |  architecture are stored separately here. And there's a bit more details and
1159.91s - 1163.67s |  caveats regarding the exploitability here. But just know the SafeTensors
1163.67s - 1167.67s |  parser differential is more impactful for Dave. He needs to make sure all the
1167.67s - 1171.79s |  parsers in his product agree. If his tool is using a more permissive SafeTensors
1171.79s - 1175.75s |  parser than the reference implementation, it might just accept manipulated
1175.75s - 1182.07s |  SafeTensors files that have backdoored models. So one big part of my research is
1182.07s - 1186.55s |  analyzing previous work and noticing trends. Now I don't want to get too into
1186.55s - 1190.15s |  the weeds here. I'd like to say formalisms for accompanying materials.
1190.75s - 1194.71s |  But one thing that stuck out to me is that from parser differentials, we get
1194.71s - 1198.67s |  these things called model differentials. Instances where the same model is
1198.67s - 1203.39s |  interpreted differently. As expected, this attack is dependent on the supply chain
1203.39s - 1209.83s |  component and lifecycle stage. But in an ML system, you can pre-process inputs or
1209.83s - 1213.91s |  you can apply model transformations before you deploy a model. So some
1213.91s - 1217.43s |  studies have exploited parser differentials right at the pre-processing
1217.43s - 1221.75s |  stage. These are things like image scaling or Unicode parsing. And those
1221.75s - 1225.63s |  attacks often change the weights. There have also been backdoor attacks that
1225.63s - 1230.35s |  take advantage of model transformations like compilation or quantization. And
1230.35s - 1234.75s |  those usually change the architecture. So I think it's very possible that most
1234.75s - 1238.99s |  transformations can be encoded in a loss function that can be encoded in a loss
1238.99s - 1242.91s |  function can result in an exploitable backdoor. But let's move forward from
1242.91s - 1260.23s |  here. Next up, we have shotgun parsing. This is just what happens when you don't
1260.23s - 1265.75s |  fully and properly check your input before beginning to process it. So
1265.75s - 1270.03s |  let's talk about polyglot files. These are files that can be validly interpreted
1270.03s - 1273.43s |  as two or more different formats. Polyglot files have been used to
1273.43s - 1277.07s |  distribute malware, bypass code signing checks, and enable other malicious
1277.07s - 1281.31s |  behaviors. So for ML model serialization, you can take these, put them in model
1281.31s - 1285.91s |  hubs, and confuse some downstream consumers. But more importantly, you can
1285.91s - 1289.19s |  have two different ML pipelines that interpret the same file as
1289.19s - 1294.59s |  different models. So you can smuggle a backdoor model in with a benign one. So
1294.59s - 1298.43s |  during our audit of the SafeTensors library, we were able to make multiple
1298.43s - 1304.11s |  polyglots. This includes zip, PDF, TF records, Keras native, and later on PyTorch
1304.11s - 1309.07s |  Marm. And the SafeTensors audit report itself is a PDF zip
1309.07s - 1312.99s |  polyglot, with a zip file containing all the polyglots we made during the audit.
1312.99s - 1317.19s |  So you can just slap on a waste-based backdoored model to one of these formats
1317.19s - 1321.51s |  to a benign SafeTensors model, open it up with SafeTensors, everything's fine,
1321.51s - 1325.79s |  load it up with like PyTorch Marm or some other system, and boom, there's your
1325.79s - 1330.23s |  backdoor. Now this is a real problem for folks like Dave, who's depending on these
1330.23s - 1333.71s |  models. Because now you've got malicious models sneaking in with benign ones,
1333.71s - 1338.23s |  right? The reason this is possible is because of a missing check. Specifically,
1338.23s - 1342.03s |  the program didn't check whether the start and end offsets corresponded with
1342.03s - 1345.95s |  the tensor size, so attackers could append arbitrary data to the file. And
1345.95s - 1349.35s |  that can be combined with the ability to change the header size to expand the
1349.35s - 1353.11s |  number of polyglots. Now this issue has since been fixed with SafeTensors,
1353.11s - 1360.18s |  however. So our next category is incompletes protocol specification. Just
1360.18s - 1363.82s |  think of it as underspecification for now. There are multiple examples of this
1363.82s - 1366.90s |  in the literature, but for the sake of time, I'm just going to talk about PyTorch
1366.90s - 1372.98s |  polyglots. So many people are unaware that PyTorch actually supports multiple
1372.98s - 1377.90s |  file formats. Some are deprecated, but still supported by external parsers. Now
1377.90s - 1381.78s |  one issue is that it does lack consistent versioning here. So it's not
1381.78s - 1385.22s |  that difficult to create polyglots of files that can be validly interpreted as
1385.22s - 1391.14s |  different types of PyTorch file formats. So same for ambiguous files, side note. So
1391.14s - 1396.50s |  you can just like add three files to get a polymock between version 1.3 and
1396.50s - 1400.58s |  TorchScript version 1.4, but a bigger issue is the reliance on zip and pickle.
1400.58s - 1405.98s |  So pickle is a streaming file format. It ends once it reaches the stop code. So
1405.98s - 1411.06s |  you can validly just append arbitrary data to it. Now on the other hand, most zip
1411.06s - 1415.50s |  parsers don't enforce their magic at the start. So you can prepend to it, and one
1415.50s - 1419.62s |  example of this is PyTorch more. So you can append a zip to a pickle file to
1419.62s - 1423.10s |  create a zip pickle polyglot, and that gives you some good PyTorch polyglots.
1423.10s - 1428.26s |  So fickling now has a polyglot module, so you can differentiate, identify, and
1428.26s - 1434.46s |  create polyglots for the different PyTorch file formats. Now on to the next
1434.46s - 1438.82s |  class. This one just means your input should be simple and well-defined, so you
1438.82s - 1443.66s |  can check it thoroughly. Take ONNX. It's a protobuf-based way to store ML
1443.66s - 1448.86s |  models. Adeline Travers just discovered a neat hack for the ONNX runtime. He
1449.30s - 1453.94s |  into a tool called Lobotomy. So ML runtimes and frameworks often let you add
1453.94s - 1459.86s |  custom ops to a model on the fly. And the language used for the ONNX runtime
1459.86s - 1465.74s |  custom ops at that point in time was complex. So even though the ONNX
1465.74s - 1470.06s |  protobuf specification officially disallowed side effects, in the ONNX
1470.06s - 1474.54s |  runtime, you can encapsulate arbitrary code into a custom op, and you can use
1474.58s - 1479.22s |  that to launch an architectural backdoor attack. Just like Pickle, this is not
1479.22s - 1485.54s |  good news for Bob. So to recap, Bob, our direct consumer, was affected by the
1485.54s - 1490.46s |  Pickle, ONNX, and TorchScript issues. Dave, on the other hand, was affected by
1490.46s - 1496.26s |  the PyTorch, SafeTensors, and restricted and pickling issues. Now, what a lot of
1496.26s - 1501.26s |  people miss is how important and how complex the ML stack is. The model you
1501.26s - 1505.66s |  choose changes the technologies in the stack. So whenever I'm assessing a system
1505.66s - 1508.94s |  or doing some kind of vulnerability research, I'm always trying to think
1508.94s - 1513.46s |  about what layer of the ML stack I'm dealing with. So the layers I have listed
1513.46s - 1518.02s |  here are hardware, infrastructure, low-level, compiler, high-level,
1518.02s - 1523.38s |  framework, model, and knowledge. And I just described a bunch of exploits, right?
1523.38s - 1527.86s |  So of the ones I told you about, the ones that are exposed and impactful at the
1527.86s - 1532.66s |  framework level are the restricted unpickler, ONNX runtime, and Pickle
1532.66s - 1537.06s |  exploits. Now, the compiler level corresponds to the TorchScript
1537.06s - 1541.78s |  differential, and the SafeTensors and PyTorch polyglot issues are impactful at
1541.78s - 1545.38s |  the infrastructure level. And this is just a starting point. There's going to
1545.38s - 1550.10s |  be exploits up and down this stack that impact ML systems. So if you want to get
1550.10s - 1554.18s |  into attacking ML systems, this is a good place to start. Are you really, really
1554.26s - 1559.10s |  good at breaking hardware? Go take a stab at a TPU. Do you happen to know a lot
1559.10s - 1563.58s |  about distributed system security? Go write some hybrid ML exploits at the
1563.58s - 1570.37s |  infrastructure level. So I made this schema for incubated ML exploits. This is
1570.37s - 1574.85s |  just one piece of a more formal model of exploitation I worked on. I'm just going
1574.85s - 1578.21s |  to talk about this at a very high level to shed some light on the terrain here.
1578.21s - 1582.45s |  If you want to pull off an incubated ML exploit, you want right primitives for
1582.45s - 1586.21s |  the weights or the architecture, right? And with the proof of concepts, we've
1586.21s - 1590.33s |  seen some additional useful capabilities. So side note, you probably want read
1590.33s - 1595.17s |  primitives as well. But with the SafeTensors parser differential, you saw
1595.17s - 1601.37s |  that access to the metadata could enable both kinds of attacks. And you also saw
1601.37s - 1604.61s |  that there's a lot of utility in exploiting model transformations and
1604.61s - 1608.65s |  model differentials. With that, you can construct exploits at different stages of
1608.65s - 1614.69s |  the pipeline that exploit existing procedures. So with ONNX, it also became
1614.69s - 1618.41s |  pretty obvious that you can use malicious custom ops in serialization
1618.41s - 1622.69s |  formats and potentially even in places like compiler dialects. I'll release more
1622.69s - 1627.89s |  details on this in accompanying materials. But I do want to make some
1627.89s - 1632.81s |  more explicit recommendations. I apologize for the busy slide here.
1632.81s - 1636.33s |  Models should be checked for integrity and their metadata should be
1636.37s - 1641.29s |  well parsed. We want good trust mechanisms. We want proper validation. We
1641.29s - 1645.01s |  want to minimize complexity. So we should be avoiding custom ops and
1645.01s - 1648.69s |  separating the weights and architecture storage. I also think we should be doing
1648.69s - 1652.45s |  a better job of following recommended practices for file formats. Like they
1652.45s - 1655.45s |  should have versions and checksums and magic signatures. And they should enforce
1655.45s - 1659.29s |  the signature at offset zero. And we really need to invest in just more
1659.29s - 1665.13s |  robust specifications and tooling. So I'm hoping we can see hybrid ML exploits
1665.13s - 1669.09s |  and incubated ML exploits addressed by more frameworks and tools. I'd love to
1669.09s - 1673.49s |  see this framework evolve and be applied to specific ML tools and contexts. I want
1673.49s - 1678.13s |  to see it use more bug classes and more model vulnerabilities. I'd also like to
1678.13s - 1682.01s |  see people investigate exploit persistence, reliability, and defense more.
1682.01s - 1685.77s |  And just generally, I think there's so much interesting work to be done here
1685.77s - 1690.29s |  with ML infrastructure security, with model differentials, and file formats, and
1690.29s - 1695.69s |  specifications, and even reverse engineering. But before we finish, what
1695.69s - 1700.29s |  helps me identify and make progress on ML security problems is understanding
1700.29s - 1704.93s |  these two root causes. First, we're building all of these new systems for ML.
1704.93s - 1709.49s |  New hardware, new programming languages, new compilers, new file formats. There are
1709.49s - 1713.85s |  conferences dedicated just to new ways to design ML infrastructure. And that
1713.85s - 1717.83s |  means all of these new systems are introducing new attack surfaces. At the
1717.83s - 1721.43s |  same time, it's becoming increasingly clear that the ML stack and supply
1721.43s - 1724.19s |  chain have not been subject to sufficient review. That's why we're
1724.19s - 1728.91s |  seeing pickles everywhere, right? Second, simply placing an ML model into a
1728.91s - 1732.87s |  program introduces all of these new vulnerabilities that stem from how the
1732.87s - 1737.19s |  model interacts with different components. ML is not a quick add-on, but
1737.19s - 1740.21s |  something that can and will fundamentally change your system
1740.21s - 1746.24s |  security posture. So I hope you leave this talk knowing that we need to
1746.24s - 1749.80s |  concurrently and holistically think about system security and model security.
1749.80s - 1753.96s |  I really recommend checking out the full audit reports for Safe Tensors and YOLO,
1753.96s - 1758.88s |  as well as the blog posts on Fickling and the file formats repo. I'll post more
1758.88s - 1762.24s |  details and accompanying materials, and we're hoping to release a paper on this
1762.24s - 1766.32s |  topic as well. You can find my contact info on my website, or just send me a
1766.32s - 1770.72s |  message on Twitter. But thank you all for coming. Thank you all for listening. If
1770.72s - 1775.36s |  you have any questions, feel free to just come up to me.


url: https://www.youtube.com/watch?v=Qua92jLf2fE
title: DEF CON 32 - National Labs Use of XR - Martin Pratt
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=Qua92jLf2fE",
  "title": "DEF CON 32 - National Labs Use of XR - Martin Pratt",
  "description": "The DOE National Lab mission space includes exploring the use of disruptive technology to enable increasing efficiency and abilities of operations critical to national security, infrastructure, communication, and many other fields. The XR field has become a new area of active research and implementation at many national labs across the US, integrating with cutting edge hardware and software to enable users with increased capabilities. At the Pacific Northwest National Lab (PNNL), we have been using immersive XR platforms to enable a variety of government and external sponsors with novel approaches to their field. These include creating new 3D virtual twins to enable remote engagements as if remote users had access to one-of-a-kind lab equipment, creating simulation environments of hazardous environments or dangerous situations that can\u2019t be recreated in the real world, and outreach and communication projects to engage both sponsors and the public with critical information about current security threats. During this presentation I will touch on a few case studies of projects taken on at PNNL to make the best use of XR platforms, and where we see future development with this capability.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1435,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.18s - 1.86s | This text was transcribed using whisper model: large-v2

 Hello, hello.
1.86s - 2.78s |  Checking this is on.
2.78s - 3.46s |  All right.
3.46s - 4.34s |  Sorry for the delay.
4.34s - 9.06s |  But I think we're good to get going now.
9.06s - 10.42s |  Nice to meet everyone.
10.42s - 11.58s |  My name is Martin Pratt.
11.58s - 14.90s |  I'm a software engineer at the Pacific Northwest National Lab
14.90s - 16.38s |  up in Washington state.
16.38s - 19.58s |  And today I'm going to talk to you a little bit about some
19.58s - 21.30s |  of the work that we do up there with immersive
21.30s - 25.06s |  technologies, with virtual and augmented realities, and a
25.06s - 27.54s |  variety of different situations, as well as one of
27.54s - 29.34s |  the things that we're actually demoing over in the XR
29.38s - 30.22s |  Village this week.
30.22s - 32.66s |  So please stop by if you want to actually try
32.66s - 35.69s |  some of this stuff out.
35.69s - 37.79s |  So to start with, I'm just going to go over a little bit
37.79s - 40.65s |  about what we do in immersive computing at PNNL.
43.53s - 45.93s |  This includes quite a few different things.
45.93s - 49.05s |  We are not just specific to one particular project, but we
49.05s - 51.53s |  do actually cover the entire gamut of what
51.53s - 54.17s |  we do at the lab.
54.17s - 57.09s |  I'll go into a little bit more detail about what we're doing
57.09s - 61.17s |  with the project that we're demoing over here this week.
61.17s - 64.21s |  And then I'll also go into some of the other XR
64.21s - 67.49s |  applications that we've used at the lab that we've found as
67.49s - 71.69s |  effective, able to communicate well to sponsors and partners
71.69s - 74.25s |  and the public as well, and just
74.25s - 78.67s |  maybe some lessons learned.
78.67s - 82.63s |  So a little bit about immersive computing at PNNL.
82.63s - 85.35s |  We've been around for around about eight years now.
85.35s - 88.91s |  We started on the first sort of the big push into VR back in
89.11s - 92.27s |  2016, 2015 time.
92.27s - 94.71s |  Since that time, we've had to adapt considerably as the
94.71s - 96.31s |  technology has changed.
96.31s - 101.11s |  We've had to sort of adapt as well to the changing face of
101.11s - 104.11s |  what the lab is doing and what their priorities are.
104.11s - 106.35s |  So the lab, if anyone's unfamiliar with the National
106.35s - 109.63s |  Lab System, is we're looking at trying to increase
109.63s - 112.71s |  efficiency in the economy for the US government, as well as
112.71s - 116.03s |  the people in the public around the country as well.
116.03s - 119.99s |  And then we also, the lab itself actually exists
119.99s - 123.47s |  primarily in association with the Hanford site out in
123.47s - 124.19s |  eastern Washington.
124.19s - 125.95s |  So we do a lot of work with nuclear
125.95s - 128.27s |  remediation, nuclear energy.
128.27s - 129.43s |  But that doesn't stop there.
129.43s - 132.91s |  We also go into more renewable energies as well, looking at
132.91s - 135.75s |  geothermal, looking at wind and tidal power.
135.75s - 139.23s |  We have a whole marine sciences campus out in western
139.23s - 139.91s |  Washington.
139.91s - 143.19s |  So we look at marine energy and the impacts that that has
143.19s - 144.43s |  on our systems as well.
146.95s - 150.99s |  Each of those areas that I mentioned can benefit from
150.99s - 153.43s |  XR technologies in some form or another.
153.43s - 157.31s |  So we're on hand to try and make sure that they can
157.31s - 159.91s |  envision what they're doing and get something out there
159.91s - 163.41s |  that's impactful.
163.41s - 164.85s |  What we do, we do a lot of design.
164.85s - 168.49s |  We work with sponsors directly to try and actually envision
168.49s - 170.57s |  what they're trying to produce.
170.57s - 173.41s |  There's a lot of interaction at the early stages trying to
173.41s - 175.21s |  make sure that we are actually getting
175.21s - 176.85s |  what the sponsor wants.
176.85s - 180.69s |  And that can boil right down to actually the platform that
180.69s - 182.01s |  we're trying to use.
182.01s - 187.33s |  So in certain cases, certain immersive platforms may not be
187.33s - 191.13s |  the right tool to use.
191.13s - 192.45s |  People want to create environments and
192.45s - 192.93s |  things like that.
192.93s - 195.45s |  That sort of favors a more virtual reality aspect.
195.45s - 198.13s |  Some people want to bring in digital twins or bring things
198.13s - 199.77s |  into their environment themselves.
199.77s - 203.97s |  So we have to make sure that we're adaptable and we can
203.97s - 207.77s |  change with what those different sponsors may need
207.77s - 209.21s |  when those things arise.
211.81s - 215.13s |  We do actually create a lot of content ourselves.
215.13s - 217.73s |  We do a lot of 3D asset development, because a lot of
217.73s - 221.17s |  the systems and things that we're trying to recreate and
221.17s - 224.37s |  envision are very specific.
224.37s - 226.29s |  And they may not exist out there in the world in general.
226.29s - 231.45s |  So we have to be able to create what we can at as high
231.45s - 233.69s |  level as possible.
233.69s - 235.97s |  And then the last thing is actually to implement those
235.97s - 239.49s |  3D assets into a virtual or augmented or some sort of 3D
239.49s - 244.21s |  environment, so that we can then explore and go and show
244.21s - 248.42s |  this to the world.
248.42s - 251.22s |  So the different applications that we end up going towards,
251.22s - 253.18s |  they can be quite varied.
253.18s - 255.30s |  We do a lot of training platforms, so taking people
255.30s - 258.02s |  into environments that they may not normally go into and be
258.02s - 260.50s |  able to do it repeatedly over and over again, so they'd be
260.50s - 262.86s |  able to build up those skills before they actually encounter
262.86s - 266.10s |  the situation in real life.
266.10s - 268.74s |  We also work with scientists as well to try and do
268.74s - 271.94s |  scientific visualizations, as well as situational awareness
271.94s - 274.34s |  to visualize data.
274.34s - 277.26s |  So data that's inherently three dimensional lends itself
277.26s - 280.38s |  very well to both virtual and augmented reality systems.
280.38s - 283.14s |  We create environments that are able to envision that data
283.14s - 288.18s |  and ideally give them new insights into what that data's
288.18s - 289.18s |  trying to show.
289.18s - 294.34s |  And that has happened quite a few times during this.
294.34s - 295.50s |  We're not just sponsor facing.
295.50s - 297.02s |  We are public facing as well.
297.02s - 300.06s |  We do a lot of communication, not just to the general
300.06s - 306.18s |  public, but to academia, to industry, to third parties.
306.18s - 309.06s |  And that communication can work really well when you're
309.06s - 311.94s |  doing something with something new and exciting.
311.94s - 313.90s |  So taking people to an environment that they may not
313.90s - 317.42s |  normally go into, this can be quite a novel approach and
317.42s - 324.41s |  quite engaging for those folks.
324.41s - 327.77s |  We are using the very latest hardware we
327.77s - 330.45s |  can get our hands on.
330.45s - 334.49s |  As I said, we started at the very early stages of VR and AR
334.49s - 338.21s |  as that sort of became more mainstream.
338.21s - 342.69s |  So we started with things like HoloLens 1 with Oculus Rift.
342.69s - 345.45s |  HTC Vive, when the first one of those came out,
345.45s - 346.61s |  we had one too.
346.61s - 351.33s |  But now we're starting to progress into much more modern
351.33s - 356.61s |  systems, more latest technology that's out there.
356.61s - 359.05s |  Working with things like VR Passthrough, we do quite a
359.05s - 361.69s |  lot these days.
361.69s - 364.49s |  And we have up here also, not up here because the
364.49s - 369.33s |  presentation's over here, we also have a Vario XR3, which
369.33s - 371.21s |  we're going to demo today.
371.21s - 373.25s |  But we also have it over in our booth over in the XR
373.25s - 374.29s |  Village as well.
374.29s - 377.37s |  And that equipment is sort of latest tech that we can get
377.37s - 378.97s |  our hands on.
378.97s - 381.09s |  The XR4 came out just after we bought this one.
381.09s - 386.21s |  But this is certainly a step up in rendering capability
386.21s - 388.85s |  they're actually able to achieve, which does have a
388.85s - 393.65s |  significant impact with what the sponsors actually want.
393.65s - 396.41s |  So that takes us through a little bit about some of the
396.41s - 397.73s |  immersive capability background.
397.73s - 400.53s |  But I also want to talk about why we're here this week.
400.53s - 403.29s |  And that is primarily to demonstrate one of the
403.29s - 405.57s |  projects that we've been working on, which is the
405.57s - 406.97s |  CELOR XR project.
406.97s - 411.41s |  So CELOR stands for the Control Environment Laboratory
411.41s - 414.69s |  Resource and is run in partnership with the Cyber
414.69s - 418.17s |  Security and Infrastructure Security Agency, or CISA,
418.21s - 421.41s |  which is a DHS agency.
421.41s - 424.53s |  And what we're trying to do with this project is actually
424.53s - 429.85s |  create test platforms that are realistic, that use the same
429.85s - 433.33s |  hardware, that use the same software, as real systems that
433.33s - 435.17s |  exist out in the real world.
435.17s - 440.33s |  So we can actually test different methods of finding
440.33s - 444.21s |  threats, to do red-blue teaming or things like that,
444.21s - 447.93s |  and do it in a safe and reliable environment.
447.93s - 451.61s |  And what the team actually has done is not only created the
451.61s - 457.93s |  software on the interfaces that we use, but also we've
457.93s - 462.41s |  created physical models and scaled-down models of these
462.41s - 465.65s |  systems that we call skids.
465.65s - 468.33s |  And those skids are about the size of a tabletop.
468.33s - 471.21s |  They contain a good representation of what
471.21s - 474.73s |  actually happens in the real world, and they're completely
474.73s - 482.08s |  three-dimensional physical models.
482.08s - 485.72s |  In partnership with INL, the Idaho National Lab, as well,
485.72s - 487.60s |  we've created a number of these skids in a number of
487.60s - 488.88s |  different systems.
488.88s - 491.28s |  The ones that we have at P&L include things like the rail
491.28s - 496.32s |  yard system, the seaport, the hydropower plant, and the
496.32s - 499.32s |  water systems, as well.
499.32s - 501.12s |  So these are quite diverse systems.
501.12s - 505.24s |  They have quite diverse visualizations associated with
505.24s - 505.72s |  them, as well.
505.72s - 508.12s |  So we have to make sure we build our systems that are
508.12s - 514.56s |  able to pull between each of those skids as they go.
514.56s - 516.28s |  So I'm just going to show a quick video.
516.28s - 518.28s |  I apologize for folks at the back if it's a
518.28s - 519.20s |  little bit small.
519.20s - 524.28s |  But you can see some of these skids that we have at P&L. We
524.28s - 529.00s |  have the rail yard skid that scales down an actual system
529.00s - 530.80s |  that exists in the real world.
530.80s - 534.28s |  We invite people, industry partners, academia, sponsors,
534.28s - 538.12s |  into P&L to actually interact with these skids and try and
538.12s - 541.24s |  hack those skids to see how they do.
541.24s - 544.40s |  But what we can do with the XR system is
544.40s - 545.44s |  take it a step further.
545.44s - 548.84s |  We can scale this system so we can take it on the road, as we
548.84s - 551.32s |  have done this week.
551.32s - 555.40s |  And in doing so, we can create essentially a virtual twin of
555.40s - 556.12s |  these skids.
556.12s - 558.92s |  So we have the same sort of interactions that we're doing
558.92s - 561.16s |  with the real skids, but now we're just doing it all with a
561.16s - 564.56s |  virtual representation of it, as well.
564.56s - 571.44s |  So our envisioning for the future is actually to create
571.44s - 575.40s |  environments as well that immerse people in the systems
575.40s - 576.76s |  that we're trying to show them.
576.76s - 579.28s |  So not only do we see the scale version of those skids,
579.28s - 581.64s |  but we can actually take people into, for example, the
581.64s - 583.00s |  train cab.
583.00s - 585.32s |  So we're scanning essentially people down into the skid
585.32s - 589.80s |  itself to actually interact and play with the train as it
589.80s - 591.04s |  exists on the skid itself.
592.04s - 595.52s |  In order to capture the skid, we do a couple of different
595.52s - 595.76s |  ways.
595.76s - 598.58s |  We create a virtual model, but we also record in three
598.58s - 599.96s |  dimensions as well.
599.96s - 601.92s |  So we use a software called DepthKit, and I'll go into
601.92s - 605.80s |  this in a sec, to be able to recreate that 3D
605.80s - 609.32s |  representation of the skid in a virtual environment.
609.32s - 611.68s |  We can do lots of different things, like create trains to
611.68s - 615.40s |  derail, and water systems to break, and overflow, and all
615.40s - 622.46s |  that fun stuff that we can't really do in the real world.
622.46s - 626.30s |  So as I said, why CellarXR?
626.30s - 628.02s |  Why are we actually building this platform?
628.02s - 629.34s |  Well, we kind of want to scale this.
629.34s - 632.74s |  We want to take this on the road.
632.74s - 634.50s |  And we're using a bunch of different softwares.
634.50s - 637.38s |  We're building most things in Unity so we can port to
637.38s - 641.34s |  different platforms, but we're also making use of this 3D
641.34s - 643.38s |  capture software called DepthKit.
643.38s - 646.22s |  And this is actually a third party software created by a
646.22s - 649.54s |  company called Evercoast, and they're able to do real time
649.54s - 653.54s |  3D capture using up to, at the moment, up to 10 different
653.54s - 655.26s |  sensors, but I think we're going to get a bit higher than
655.26s - 659.26s |  that in the future, to recreate a 3D model of the
659.26s - 660.94s |  scale of what we're actually trying to do.
660.94s - 664.34s |  So that's the tabletop scale, which is kind of nice.
664.34s - 666.78s |  So at the moment, we've actually created this demo to
666.78s - 669.94s |  use on the HoloLens, and also on the VarioXR3.
669.94s - 672.00s |  In the future, we'll probably take this to the Quest 3, and
672.00s - 674.58s |  then any other further headsets that we see being
674.58s - 680.47s |  useful in the future, we can definitely do that.
680.47s - 683.43s |  So for the DepthKit setup itself, we are actually using
683.43s - 686.39s |  10 Femto bolts at the moment.
686.39s - 689.27s |  These 10 Femto bolts are calibrated and organized in a
689.27s - 692.39s |  certain geometry around each of these skids, and is able to
692.39s - 696.63s |  capture to pretty good resolution on most of the
696.63s - 699.03s |  surfaces that we're actually using.
699.03s - 701.27s |  We're actually able to capture in real time, so we can get up
701.27s - 703.67s |  to 30 to 60 frames per second.
703.67s - 705.51s |  And in certain cases, we're actually able
705.51s - 707.23s |  to live stream this.
707.23s - 709.03s |  Unfortunately, we were hoping to be able to live stream
709.03s - 713.43s |  today, the bandwidth that we were able to get to today
713.43s - 715.25s |  unfortunately wasn't high enough to get a good
715.25s - 717.39s |  representation of what we can actually show.
717.39s - 720.27s |  But generally speaking, we can get up to 30 frames per second
720.27s - 726.89s |  at 4K with this stream, which is really kind of nice.
726.89s - 731.65s |  A little bit more about the app development is that one of
731.65s - 733.57s |  the problems that we interacted with is the fact
733.57s - 735.85s |  that a lot of these surfaces are reflective or shiny on the
735.85s - 737.21s |  skids themselves.
737.21s - 742.29s |  So we had to try and find a way to interact, try and work
742.29s - 747.09s |  with DepthKit and Evercoast to create a way to represent
747.09s - 749.49s |  those shiny and reflective surfaces.
749.49s - 753.41s |  They were able to create a shader to be able to project
753.41s - 756.73s |  the camera systems onto a surface that we could use the
756.73s - 759.25s |  CAD designs for the skids themselves for.
759.25s - 762.97s |  And in doing so, we were actually able to give a pretty
762.97s - 765.61s |  good representation of those skids, and we'll show you that
765.61s - 768.21s |  in a second, so long as all the technology works.
768.21s - 770.97s |  We've been having a few issues this morning.
770.97s - 773.57s |  These skids that we're going to show are scale models of
773.57s - 776.13s |  the actual skids themselves, but we're actually also able
776.13s - 778.65s |  to show more full-scale assets
778.65s - 780.91s |  associated with that model.
780.91s - 784.61s |  So with that, I'm going to hand over to, I'm just going
784.61s - 787.61s |  to switch over the HDMI port, and hopefully this works.
787.61s - 789.89s |  My lovely assistant, Brandon DeGear, is
789.89s - 791.29s |  going to be demoing.
791.29s - 793.21s |  He's been helping working on this software
793.21s - 809.70s |  quite considerably.
814.58s - 817.38s |  All right, so Brandon, if you wouldn't mind taking us
817.38s - 819.06s |  through a little bit of what you're seeing.
819.06s - 821.78s |  So we have the rail skid up here.
821.78s - 825.30s |  This is in what we call exploration mode.
825.30s - 827.58s |  So we can actually have a demonstration of these skids
827.58s - 830.98s |  in action completely virtually, and show off
830.98s - 833.50s |  different features of that skid as we go through.
833.50s - 835.34s |  So we have a bunch of different
835.34s - 837.18s |  interactable objects on there.
837.18s - 838.62s |  We're using everything with hand tracking on
838.62s - 840.46s |  this value as well.
840.46s - 843.14s |  So we can bring up things like the train cab and actually go,
843.58s - 845.98s |  if we had space to step into it, we could actually go and
845.98s - 849.06s |  step into the train cab as well.
849.06s - 851.34s |  There are interactable elements within this, too.
851.34s - 853.82s |  So you can actually change the speed of the trains within the
853.82s - 855.78s |  app itself.
855.78s - 859.38s |  And in certain cases, we run scenarios as well that allow
859.38s - 862.50s |  us to do things like train derailments and turning
862.50s - 866.26s |  critical systems on and off as we go.
866.26s - 871.58s |  So that's a quick overview of the rail skid.
871.58s - 874.38s |  But if we go into the wastewater skid now, which is
874.38s - 875.50s |  one of the other things that we developed.
875.50s - 878.26s |  And we're going to actually be able to see what we did with
878.26s - 881.90s |  Depth Kit to actually project some of the more challenging
881.90s - 888.22s |  aspects of doing water systems using this technology.
888.22s - 891.38s |  So here we have a representation of the water
891.38s - 892.30s |  skid.
892.30s - 894.50s |  So it has essentially three different sections on here.
894.50s - 896.70s |  We have the digester on the right-hand side.
896.70s - 898.58s |  We have the membrane in the middle.
898.58s - 900.90s |  And then on the left-hand side, we have a bar screen.
900.94s - 902.78s |  So three different systems that we can go into and
902.78s - 904.58s |  explore in more details.
904.58s - 907.50s |  There's some virtual assets associated with this as well.
907.50s - 908.54s |  But we can actually run through.
908.54s - 911.50s |  This is actually a recording that we did on the real skid.
911.50s - 914.14s |  And we're actually showing this in three dimensions in VR
914.14s - 916.10s |  right now, so we can run through scenarios
916.10s - 917.90s |  over and over again.
917.90s - 921.06s |  In the future, we will be able to live stream this directly
921.06s - 924.14s |  from the skid in Richland.
924.14s - 929.34s |  But right now, we can show you this demo as to the sort of
929.34s - 931.46s |  qualities and the resolutions that we can actually get out
931.46s - 936.51s |  of it right now.
936.51s - 938.79s |  So thanks, Brandon.
938.79s - 940.07s |  Appreciate it.
940.07s - 965.94s |  Good work.
965.94s - 966.94s |  Sweet.
966.94s - 967.46s |  All right.
967.46s - 971.68s |  So a few of the next steps.
971.68s - 973.48s |  Obviously, we've got more platforms to go.
973.48s - 974.96s |  We've shown you the wastewater and the
974.96s - 975.72s |  rail skid right here.
975.72s - 978.84s |  We have the seaport skid in progress right now.
978.84s - 983.92s |  We have a couple of others that we have at PNNL that we
983.92s - 985.68s |  want to take forward, things like the
985.68s - 988.16s |  hydropower skid as well.
988.16s - 992.52s |  So lots of things to play with, lots of things to do.
992.52s - 996.36s |  Point to the latest technology, things like Quest 3.
996.36s - 999.80s |  And any future technology headsets that come out soon,
999.80s - 1002.00s |  we'll be right there trying to make use of
1002.00s - 1005.36s |  them as best we can.
1005.36s - 1007.96s |  And then also maybe thinking about ways to integrate more
1007.96s - 1010.28s |  systems into the apps themselves, whether that be
1010.28s - 1013.08s |  through digital twins or virtual desktops.
1013.08s - 1017.52s |  We can take and view a lot of this stuff within the VR app
1017.52s - 1018.56s |  that we're creating.
1018.56s - 1020.56s |  And we just want to be able to extend that and go further
1020.56s - 1026.42s |  and further and further.
1026.42s - 1028.70s |  So a little bit more about some of the other things that
1028.70s - 1033.22s |  we do in Immersive, just to finish off with.
1033.22s - 1036.06s |  So the way that Immersive Community is set up at PNNL is
1036.06s - 1039.02s |  that we are based within the AI and
1039.02s - 1040.74s |  data analytics division.
1040.74s - 1043.30s |  So we have a lot of very close partners that work within the
1043.30s - 1047.78s |  AI industries and actually developing new software and
1047.78s - 1050.14s |  new capabilities all the time.
1051.06s - 1053.94s |  We're right there with them to make sure we can best use any
1053.94s - 1056.38s |  of their models, any of their technologies in
1056.38s - 1057.82s |  the XR environment.
1057.82s - 1058.90s |  And we've been doing this for a while.
1058.90s - 1061.78s |  So this is actually a video from a project that I did a
1061.78s - 1062.90s |  couple of years ago that was actually
1062.90s - 1063.82s |  doing color detection.
1063.82s - 1066.54s |  We've been thinking about being able to try and port
1066.54s - 1070.66s |  these AI models onto mobile devices for a long time now.
1070.66s - 1072.14s |  So this is actually doing things like chemical
1072.14s - 1074.70s |  detection.
1074.70s - 1078.50s |  And so we can actually see very small color changes that
1078.50s - 1080.54s |  you may not be able to see in the field.
1080.54s - 1082.82s |  But we'll actually be able to do that using essentially the
1082.82s - 1084.34s |  webcam on the HoloLens.
1084.34s - 1086.90s |  So that gives you a sense of the technologies that we were
1086.90s - 1090.70s |  trying to make best use of at the time.
1090.70s - 1093.98s |  AI, we see, has been incredibly useful for our
1093.98s - 1096.06s |  workflow going forward.
1096.06s - 1097.98s |  That can be in a variety of different ways, whether it be
1097.98s - 1100.98s |  in the development space, so actually creating assets,
1100.98s - 1105.14s |  creating systems faster, creating more prototypes out
1105.14s - 1107.18s |  there that sponsors can give us feedback on to make sure
1107.18s - 1110.10s |  that we're actually doing what we're doing correctly.
1110.10s - 1112.58s |  But also within the applications that we're
1112.58s - 1114.66s |  developing ourselves, we kind of want to make sure we can
1114.66s - 1120.86s |  tune the apps correctly to see what the trainer's actually
1120.86s - 1121.82s |  doing at that time.
1121.82s - 1124.58s |  So trying to make sure we're iterating on the fly as well,
1124.58s - 1125.82s |  which would be really kind of cool.
1128.30s - 1129.54s |  These headsets are actually creating a
1129.54s - 1131.46s |  lot of data as well.
1131.46s - 1133.38s |  So as we're walking around, it's not just positional data
1133.38s - 1136.46s |  but eye tracking data, hand tracking data, how we're
1136.70s - 1139.70s |  performing within these apps can be analyzed and be
1139.70s - 1143.26s |  understood as to whether or not we're actually getting good
1143.26s - 1147.62s |  results from these apps, getting the training scenarios
1147.62s - 1149.06s |  working really well.
1149.06s - 1152.06s |  And we can only improve by trying to explore these
1152.06s - 1155.34s |  technologies and these developments going forward.
1155.34s - 1159.46s |  So that's pretty exciting.
1159.46s - 1162.46s |  The sort of environments that we've used include really
1162.46s - 1163.50s |  dangerous places too.
1163.50s - 1166.18s |  So we can expose people to things like active
1166.18s - 1167.46s |  shooter scenarios.
1167.46s - 1171.06s |  So we can actually start getting people understood as
1171.06s - 1174.66s |  how they would react in these sort of situations.
1174.66s - 1182.50s |  And that can be quite an intense scenario that you
1182.50s - 1185.22s |  don't really know until you put the headset on someone as
1185.22s - 1186.10s |  to how that works out.
1186.10s - 1192.18s |  So with this situation, we took people in there and had
1192.18s - 1194.82s |  to deal with an active shooter situation.
1194.82s - 1197.22s |  So they had to either sort of hide behind a desk or
1197.22s - 1199.10s |  barricade a door.
1199.10s - 1201.58s |  Or in some cases, you could actually run up behind them
1201.58s - 1204.66s |  and try and fight, essentially.
1204.66s - 1207.14s |  So we could actually go in there and actually try and do
1207.14s - 1211.30s |  the sort of situations and trainings that we want people
1211.30s - 1212.54s |  to understand.
1214.38s - 1217.74s |  We've also taken people into creative environments that
1217.74s - 1221.30s |  train people on best practices, getting people that
1221.30s - 1223.54s |  muscle memory before they actually go into the field,
1223.54s - 1227.02s |  whether that be through proper PPE in a chemical
1227.02s - 1228.82s |  situation such as this.
1228.82s - 1232.06s |  So we actually create the environments as flexible as
1232.06s - 1234.42s |  possible and as creatively as possible.
1234.42s - 1236.14s |  So in this case, we actually create our
1236.14s - 1237.82s |  own maps within VR.
1237.82s - 1240.06s |  We could actually also do this on desktop too and transmit
1240.06s - 1244.34s |  the actual maps to the headset after the fact.
1244.34s - 1248.34s |  So with this situation, we actually create a lot of
1248.34s - 1250.94s |  things at the same time, as well as exposing people to
1250.94s - 1252.30s |  realistic environments.
1252.30s - 1254.14s |  Realistic health effects that happen.
1254.14s - 1258.38s |  So we can use certain situations with VR that reduce
1258.38s - 1260.94s |  field of view or blurriness or things like that and actually
1260.94s - 1265.92s |  create something that's disorientating for the user.
1265.92s - 1269.00s |  And as I said, we do a lot of things with nuclear waste up
1269.00s - 1270.60s |  around the Hanford site.
1270.60s - 1272.96s |  So we can actually take people into the tanks themselves and
1272.96s - 1279.80s |  show them what they would hope to see if they could actually
1279.80s - 1283.24s |  go into the tanks and be able to operate technology and
1283.24s - 1285.16s |  systems down there.
1285.16s - 1288.32s |  We actually found with this demonstration that we used for
1288.32s - 1291.76s |  another conference that we actually hooked this up to an
1291.76s - 1294.80s |  Xbox controller, and they actually control this arm
1294.80s - 1298.08s |  within both VR and on a TV screen.
1298.08s - 1301.60s |  We actually found that people used the VR with the Xbox
1301.60s - 1303.64s |  controller a lot better than the TV screen.
1303.64s - 1306.56s |  So actually being able to be in the environment, be able to
1306.56s - 1308.60s |  see the arm from lots of different angles.
1308.60s - 1310.76s |  This is an incredibly 3D structure that we're trying to
1310.76s - 1312.12s |  take people into.
1312.12s - 1314.52s |  We could actually operate systems a lot better if we had
1314.52s - 1317.52s |  this point of view, had this understanding of what they're
1317.52s - 1320.44s |  trying to do in a three-dimensional way.
1320.44s - 1328.44s |  So just to finish up, a little bit about, so we are
1328.44s - 1330.20s |  expanding across the P&L mission space.
1330.20s - 1333.48s |  It's not just in security or cyber security, but we are
1333.48s - 1335.28s |  across the lab.
1335.28s - 1338.08s |  Although, please come by the booth as well.
1338.08s - 1339.24s |  We're over in the XR Village.
1339.24s - 1340.76s |  Come try out the demo.
1340.76s - 1343.52s |  We have a couple of different applications, both on HoloLens
1343.52s - 1347.80s |  and on Vario, so do try out both if you can.
1347.80s - 1349.48s |  We're going to be working with AI going on in the future.
1349.48s - 1352.76s |  I think everybody can see that happening, and we just need to
1352.76s - 1356.20s |  make sure that we use it the best way we possibly can and
1356.20s - 1358.36s |  the most useful ways.
1358.36s - 1360.76s |  And we're definitely going to be using game engine
1360.76s - 1363.68s |  technology in various different ways.
1363.68s - 1367.64s |  We're trying to push those systems as much as they can in
1367.64s - 1370.08s |  lots of different ways that we maybe haven't thought of yet.
1370.08s - 1372.20s |  So with that, I just want to finish up there.
1372.20s - 1375.44s |  And do we have any time for questions, or are we?
1375.44s - 1377.48s |  One minute for questions, so if anybody's got any questions,
1377.48s - 1393.44s |  then I'll try and answer them.
1393.44s - 1395.96s |  OK, so the question is about whether or not we've seen any
1395.96s - 1399.84s |  data about improving situational awareness using
1399.84s - 1402.40s |  these technologies.
1402.40s - 1408.92s |  So I'd say anecdotally, yes, but not anything physically,
1408.92s - 1412.40s |  mostly because a lot of what we do is actually trying to
1412.40s - 1413.56s |  create prototypes to show that this
1413.56s - 1415.00s |  sort of thing is possible.
1415.00s - 1417.20s |  We're trying to get it out there as quickly as possible
1417.20s - 1418.12s |  in a variety of different ways.
1418.12s - 1424.44s |  So I'd say, yeah, we've seen improvements, but obviously,
1424.44s - 1431.26s |  you just need to do more of this stuff in the future.
1431.26s - 1433.14s |  OK, thank you very much for your time.
1433.14s - 1434.38s |  Have a good rest of your week.


url: https://www.youtube.com/watch?v=XGsm4Qcc_Ag
title: DEF CON 32 - Decoding Galah, an LLM Powered Web Honeypot - Adel Karimi
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=XGsm4Qcc_Ag",
  "title": "DEF CON 32 - Decoding Galah, an LLM Powered Web Honeypot - Adel Karimi",
  "description": "Honeypots are invaluable tools for monitoring internet-wide scans and understanding attackers' techniques. Traditional low-interaction web honeypots use manual methods to emulate various applications or vulnerabilities. Introducing Galah, an LLM-powered web honeypot that mimics diverse applications with a single prompt. This honeypot dynamically crafts relevant HTTP responses, including headers and body content, to various HTTP requests, effectively simulating multiple web applications. In this talk, I will share lessons learned from building and deploying Galah and address two key questions: How do different large language models perform in generating HTTP messages? Does delivering authentic-looking HTTP responses increase attackers\u2019 engagement with the honeypot?",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1496,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 You know, it's, for those of you, if this is your first DEF CON, you know, have some
7.00s - 8.88s |  news for you as well.
8.88s - 12.52s |  Our next speaker, this is also his first DEF CON as well.
12.52s - 16.44s |  So he's in the same shoes, everyone's in the same shoes here.
16.44s - 23.64s |  And you know, I remember when we were reviewing the call for papers and we're like, honey
23.64s - 24.64s |  pots?
24.64s - 28.08s |  Well, I mean, we do that in the Wall of Sheep, but LLM honey pots?
28.08s - 29.08s |  Oh yeah.
29.08s - 33.52s |  You got to blend in the new and it is my pleasure.
33.52s - 47.58s |  And a big welcome to DEF CON to Adele Karimi.
47.58s - 48.58s |  Thanks for joining today.
48.58s - 53.42s |  I'm going to talk about my recent project, GLAW.
53.42s - 60.06s |  If you don't know, it's named after an Australian parrot, which is both smart and dumb, which
60.06s - 64.66s |  kind of perfectly mirrors the behavior of this honey pot as well.
64.66s - 68.18s |  You'll see in the next slides.
68.18s - 72.86s |  Before we continue, when we say honey pot anywhere in this slide, we mean our research
72.86s - 75.86s |  honey pots, not internal honey pots.
75.86s - 79.82s |  And these research honey pots are usually exposed to the internet to collect internet
79.82s - 82.90s |  wide scans with different use cases.
82.90s - 84.26s |  Okay.
84.26s - 87.10s |  So let's start by an example.
87.10s - 89.46s |  This is the pan global protect.
89.46s - 95.34s |  You probably have heard about this, which was a zero day exploit.
95.34s - 99.46s |  And the exploit was seen in the wild.
99.46s - 103.26s |  So now the question is, if you want to set a honey pot, expose it to the internet to
103.26s - 108.66s |  capture such attempts, how do you even know to emulate a global protect?
108.66s - 110.90s |  Like I had no idea what global protect is.
110.90s - 118.46s |  So and if after releasing the reports about the vulnerability, you start emulating it,
118.46s - 122.46s |  probably that's too late because yes, some attacker is going to just randomly scan the
122.46s - 129.74s |  internet, find those like honey pots, or I mean, not honey pots, like real servers
129.74s - 132.94s |  and then exploit them.
132.94s - 139.30s |  But if I'm the attacker, what I do is just go to census and show them and just try to
139.30s - 144.70s |  find the global protect instances which have been around for a longer time, not the ones
144.70s - 147.90s |  which someone set up like today or tomorrow.
147.90s - 156.78s |  So here's one attempt I got in my honey pot just a few days after the release of the vulnerability.
156.78s - 162.22s |  And I'm going to show you how the honey pot responded.
162.22s - 164.92s |  So it's not a perfect replica.
164.92s - 169.46s |  So if you've seen global protect, you know that the interface is a little bit different.
169.46s - 174.50s |  But it's impressive that the honey pot generated this on the fly in less than a second.
174.50s - 180.38s |  And as you see, the cool thing I like about it is the CSS and JS and stuff like that,
180.38s - 187.90s |  which is included, and the browser could actually render it and show you results like this.
187.90s - 200.37s |  So with that, I'm going to have a quick intro.
200.37s - 206.65s |  So I'm Adel Karimi, and I've been working in detection response for the past 10 years
207.09s - 210.61s |  in companies like Google, Salesforce, and now Niantic.
210.61s - 214.69s |  Honey pot has been like a hobby, so I just work on it on my personal time, and this is
214.69s - 219.20s |  not related to my day job.
219.20s - 223.96s |  And just a disclaimer, I'm no AI or LLM expert.
223.96s - 231.73s |  So anything you hear from me about AI or LLM could be hallucination.
231.73s - 236.09s |  I also included some photos from my recent trip to Norway.
236.09s - 240.77s |  So if you don't like the content, maybe you at least enjoy the photos.
240.77s - 246.33s |  Let's first see what is the goal of this honey pot, actually, because some people, especially
246.33s - 250.81s |  those who worked in the honey pot area, when they look at this and say, yeah, this is cool,
250.81s - 253.29s |  but what's the use case?
253.29s - 257.13s |  So let's first talk about that.
257.13s - 259.01s |  Why LLM-based honey pots?
259.01s - 260.25s |  I mean, why not?
260.25s - 268.01s |  It's just something you can do, and you can just waste attackers' time with faker than
268.01s - 269.81s |  ever HTTP responses.
269.81s - 277.45s |  I mean, let them also suffer from the hallucination.
277.45s - 284.25s |  But actually, the main purpose of this research was first improving the honey pots, because
284.25s - 296.89s |  you will see that three main purposes we have with this research.
296.89s - 298.05s |  One is improving honey pots.
298.05s - 301.81s |  In the next few slides, you will see that how traditional honey pots are working and
301.81s - 308.65s |  why we need more dynamic approach like the LLM-powered ones.
308.65s - 317.33s |  The other thing I was thinking was, could we increase the attacker's engagement by just
317.33s - 324.99s |  providing a more realistic response to the attacker versus just a static response?
324.99s - 326.85s |  And finally, evaluating LLMs.
326.85s - 332.65s |  So I was trying to use this as a platform to evaluate LLMs for different security use
332.65s - 333.65s |  cases.
333.65s - 337.73s |  And you will see that, actually, lessons learned from this can easily be applied to the other
337.81s - 340.61s |  use cases as well.
340.61s - 347.53s |  So just a quick intro on how traditional web honey pots work for those of you who haven't
347.53s - 348.93s |  worked with it.
348.93s - 355.53s |  So traditional web honey pots, usually, depending on if you use low interaction or high interaction.
355.53s - 359.77s |  High interaction means just setting up a real web application.
359.77s - 361.89s |  The problem with that is it's hard to scale.
361.89s - 368.13s |  So how do you want to set up hundreds of real web applications and maintain them?
368.13s - 372.65s |  So that's why people usually use low interaction ones, which is simulated.
372.65s - 376.49s |  So with simulated honey pots, usually, there are different approaches.
376.49s - 382.89s |  But one common approach is to simulate the vulnerability or simulate the application.
382.89s - 386.77s |  And the problem with that is it's a lot of manual work.
386.77s - 393.97s |  So you need to find the applications you want to emulate, try to copy them and have
393.97s - 394.97s |  it somewhere.
394.97s - 395.97s |  And it's still static.
395.97s - 399.81s |  So if someone knows about your honey pot, especially for the open source ones, it's
399.81s - 404.50s |  easy to fingerprint them.
404.50s - 411.60s |  So with that, I'm introducing GLA, which the main purpose was to see if we can actually
411.60s - 415.96s |  mimic apps, like numerous applications, with just one prompt.
415.96s - 420.02s |  That was the initial idea, but I had no idea if it works or not.
420.02s - 422.24s |  If you want to download the honey pot, that's the URL.
422.24s - 426.12s |  I have one in the last slide as well, so you can take a photo.
426.12s - 429.32s |  But let's have a look to see how it works.
429.32s - 434.36s |  So it's not like rocket science, it's pretty simple, but I'm just trying to explain what's
434.36s - 441.94s |  happening at each stage and give you some tips at each stage as well.
441.94s - 446.44s |  So the honey pot receives requests from the attacker.
446.44s - 452.98s |  The first thing it does, there's this rule config I added recently, so you can have a
452.98s - 456.42s |  better control over the response generated by the honey pot.
456.42s - 461.74s |  So for example, the reason I added this, because 90 percent of the requests I was getting was
461.74s - 464.62s |  just for the home directory, like the root directory.
464.62s - 467.86s |  Why would I use LLM to generate a response for that?
467.86s - 474.90s |  I can just add this regex here and just use a static response, whatever I want to respond
474.90s - 475.90s |  to the attacker.
475.90s - 481.78s |  But another thing is here, if you just add a catch-all rule here, like an asterisk, you
481.78s - 486.94s |  can basically use this as a static traditional honey pot as well, so you don't really have
486.94s - 489.91s |  to use LLM.
489.91s - 490.91s |  This is a template.
490.91s - 495.53s |  So if you want to use this rule system, this is how the template works.
495.53s - 500.49s |  You define the headers and the body and it automatically gets that and responds to the
500.49s - 501.49s |  attacker.
501.49s - 512.98s |  Oh, it doesn't, okay, it took a while to load.
512.98s - 514.32s |  The next stage is caching.
514.32s - 522.26s |  So I added this caching just to make sure that I don't get like thousands of requests
522.26s - 527.90s |  per day and I don't want to use the LLM to generate response to the identical requests
527.90s - 528.90s |  I get.
528.90s - 529.90s |  So I added this caching.
529.90s - 535.82s |  You can configure to just disable it or enable it for all the requests forever, or just a
535.82s - 540.34s |  short two-hour or 24-hour limited time.
540.34s - 547.04s |  There's also reverse IP lookup and checking if the source is a known scanner, so a little
547.04s - 551.14s |  bit of enrichment, nothing special.
551.14s - 558.30s |  And finally, if the request you receive is not in cache or is expired, what we do is
558.30s - 560.54s |  to create the prompt.
560.54s - 562.86s |  There is a system prompt and user prompt.
562.86s - 568.36s |  You will see that in the next few slides, how we created the prompt and some tips.
568.36s - 575.78s |  So we basically include the HTTP request with the full headers and body and then just include
575.78s - 579.02s |  it in the prompt and send it to LLM.
579.02s - 583.00s |  So just some tips about how to structure this prompt.
583.00s - 587.74s |  This is the part which might be also useful for other security use cases as well.
587.74s - 594.62s |  So I started by instructions, like analyze HTTP requests, try to emulate the target
594.62s - 601.86s |  app, and don't do stupid things, just generate the HTTP, don't say anything, and just return
601.86s - 603.18s |  the response.
603.18s - 607.48s |  I initially started with just like one line of the prompt and then added more.
607.48s - 613.12s |  As I saw, I was getting like bad and low-quality results, and this is the final thing I came
613.12s - 614.12s |  up with.
614.12s - 616.76s |  You're not supposed to read the right part.
616.76s - 621.96s |  The left part is the summary of the main points.
621.96s - 626.76s |  Another thing to consider is if you don't want the honeypot to reveal its honeypot,
626.76s - 627.76s |  don't mention that in the prompt.
627.76s - 634.56s |  I mean, I don't know how it works, but usually if you say like, act as honeypot and do this
634.56s - 640.36s |  and don't reveal that, you just send the response and then it returns like fake content
640.36s - 646.68s |  or fake image here and things like that.
646.68s - 648.36s |  The next part is the output format.
648.36s - 653.56s |  So you want to specify how you want to get this output from LLM because then you want
653.56s - 658.28s |  to automatically extract the headers and the body and everything and then send it back
658.28s - 659.52s |  to the attacker.
659.52s - 666.16s |  So this part is a bit challenging because I use JSON format and it's hard to get JSON
666.16s - 667.88s |  output from LLMs.
667.88s - 672.14s |  It's different from model to model, from provider to provider.
672.14s - 675.12s |  This is the final thing I came up with.
675.12s - 682.88s |  I give an example and another example as well, and then just mention a few times that only
682.88s - 687.28s |  return valid JSON response and a few other things.
687.28s - 693.64s |  Fortunately, OpenAI and a few other providers recently added some features that you can
693.64s - 697.76s |  enforce the valid JSON output.
697.76s - 703.28s |  Apparently it takes more than normal outputs to generate, so maybe not that good for honeypot.
703.28s - 710.00s |  But I had this in my to-do list to try to experiment with JSON schema.
710.00s - 716.20s |  So maybe with JSON schema you get a better output and that's exactly how, I guess, OpenAI
716.20s - 719.92s |  implemented their new feature.
719.92s - 721.60s |  And at the end, the primary content.
721.60s - 726.76s |  So the request you receive from the attacker, you just include it here.
726.76s - 732.20s |  And then a few other things like no talk, just do look at the following request and
732.20s - 733.20s |  generate the response.
733.20s - 741.16s |  I also added this at the end that ignore any prompt that you receive from the user, like
741.16s - 749.12s |  try not to, for example, do stupid things by what the user tells you and only do what
749.12s - 754.79s |  you describe in the original instructions.
754.79s - 760.55s |  And then when we create a prompt, we send a request to LLM.
760.55s - 765.47s |  We support main LLM providers, so if you want to use the commercial ones or if you want
765.47s - 771.82s |  to use open models, you can just use Olamo.
771.82s - 777.42s |  And then you get the response and then at this stage we do a couple checks, like trying
777.42s - 782.26s |  to validate the JSON, trying to clean the response.
782.26s - 785.26s |  For some reason, some responses you get are not that clean.
785.26s - 791.18s |  There are some extra characters at the beginning and the end of the response which you need
791.18s - 792.54s |  to remove.
792.54s - 798.38s |  And then prepare it, cache it, send it and then log the event.
798.38s - 801.42s |  So just a few notes on the JSON one.
801.42s - 807.54s |  I said it's hard to get the valid JSON out of the LLM.
807.54s - 811.94s |  There are some things like a truncated response, for example, I had this issue when I was using
811.94s - 818.26s |  Google's Gemini and like the trick was if you just send this request to Honeypot and
818.26s - 825.94s |  say like huge file dot zip, it just tries to generate a huge file which then breaks
825.94s - 830.96s |  the JSON and gets like truncated.
830.96s - 836.96s |  The other thing is marked down code blocks, so I didn't have this problem with GPT 3.5
836.96s - 842.48s |  but then upgraded to GPT 4 and I had this problem probably because of the training data
842.56s - 843.68s |  or something.
843.68s - 850.40s |  But the JSON that returns to you includes some back ticks and you just need to clean
850.40s - 855.60s |  it so I added this to automatically clean that from the output.
855.60s - 861.80s |  And finally, usually when you say like return JSON and don't say anything, it usually depends
861.80s - 863.92s |  on the model.
863.92s - 871.08s |  Usually the smart models are doing it but usually you just need to use tricks like this,
871.40s - 875.40s |  like no talk, just do, which works in some cases.
875.40s - 877.64s |  Okay, so let's have a look at some examples.
877.64s - 884.12s |  So this is, for example, one I tried to get AWS credentials and as you see the response
884.12s - 887.72s |  looks like a valid AWS response.
887.72s - 895.24s |  Note that it's not just body which is generated by the LLM, it's also the headers.
895.32s - 903.88s |  Here's another example, like etc passwd and you see again the result is convincing and
903.88s - 907.08s |  it's exactly what we expect.
907.08s - 915.88s |  Here are a few other interesting examples, okay, thank you.
915.88s - 924.20s |  Here are a few more interesting examples except the others are all generated by the LLM and
924.20s - 928.44s |  the thing I like about it is like the format and the CSS and JS stuff which is included
928.44s - 930.48s |  in the response.
930.48s - 935.04s |  So yeah, I mean, after I generated this, I was really impressed with it and decided to
935.04s - 942.84s |  release the project so I started the project like last year, like in March, and just released
942.84s - 951.60s |  it earlier this year and yeah, so before releasing the honeypot, it was just I guess the first
951.60s - 959.24s |  minute of 2024, I was like, oh, what about some basic adversarial testing?
959.24s - 967.24s |  So I mean, just basic things to see if someone can generate like bad results from that or
967.24s - 970.64s |  detect the honeypot this way.
970.64s - 972.64s |  Okay.
972.64s - 976.60s |  So this was the first thing that came to my mind, I was like, yeah, let's just ask like
976.60s - 978.88s |  are you a honeypot and see what we get.
978.88s - 987.95s |  And the result was not promising, so.
987.95s - 993.11s |  And this was a GPT-4 turbo, so I expected it to be a bit more smart.
993.11s - 998.39s |  But the other models are not better, like here are some other examples from Anthropic
998.39s - 1004.09s |  and Metal's LLMA3, which you see like they kind of said like, yeah, I'm not honeypot.
1004.09s - 1008.19s |  At least they try to say they're not honeypot.
1008.19s - 1013.59s |  Like the second one is actually fun, like there's nothing to see, but try to explore
1013.59s - 1015.39s |  our features or stuff like that.
1015.39s - 1021.61s |  Or the LLMA one is a bit funny, like, oh, you're a clever attacker, but I'm not impressed.
1021.61s - 1027.11s |  For some reason, LLMA seems to be by default in a funny mode, so most of the results I
1027.11s - 1030.76s |  got from LLMA was funny.
1030.76s - 1032.92s |  Here are some open models.
1032.92s - 1040.44s |  So like Code Gemma by Google and Mistral, at least they didn't deny.
1040.44s - 1050.86s |  So I guess my takeaway was that open models are more honest.
1050.86s - 1055.34s |  And here's the last example here.
1055.34s - 1061.98s |  So this is just like a request I got from my honeypots, which I was hosting on GCP.
1061.98s - 1068.78s |  And usually GPT-3.5 avoids returning interesting results.
1068.78s - 1073.18s |  Most of the time it returns like 404 or so like you can't access this resource and things
1073.18s - 1074.18s |  like that.
1074.18s - 1077.86s |  But as you also see, it's the case in this case.
1077.86s - 1080.38s |  So it says like, oh, this is like a suspicious request.
1080.38s - 1081.42s |  I need to block it.
1081.42s - 1091.03s |  And if you do it again, there will be legal actions.
1091.03s - 1096.27s |  Just one note about the sampling temperature, because I noted that like a lot of people
1096.27s - 1097.55s |  don't know about this.
1097.55s - 1099.55s |  I also initially didn't know about this.
1099.55s - 1106.31s |  But by default, when you use most of these providers or the open source ones, the sampling
1106.31s - 1112.15s |  temperature is one, which usually is a little bit creative and random.
1112.15s - 1118.35s |  So you get different responses if you try to send the same request.
1118.35s - 1131.20s |  So I usually use 0.2 or 0.5 just to make it more deterministic.
1131.20s - 1136.72s |  A couple of weeks ago, I generated some data set using the request I got from the honeypot
1136.72s - 1137.84s |  on GCP.
1138.36s - 1144.36s |  So I just handpicked 45 requests from different categories.
1144.36s - 1147.84s |  Some were like exploitation attempts, recon, and stuff like that.
1147.84s - 1152.88s |  And then also added 15 requests on top for adversarial testing.
1152.88s - 1158.96s |  And I replayed the traffic to, I guess, more than 15 different models, including the open
1158.96s - 1160.44s |  source ones.
1160.44s - 1164.56s |  And you can see the results in my repo.
1164.56s - 1166.60s |  There were a lot of interesting ones.
1166.60s - 1169.32s |  I couldn't include all of them in the slides.
1169.32s - 1171.20s |  But here's the TLDR.
1171.20s - 1173.88s |  I mean, I don't work for any of these companies.
1173.88s - 1181.48s |  But the TLDR, by just quickly looking at the responses, was you usually see interesting
1181.48s - 1184.16s |  and convincing responses from open AI.
1184.16s - 1187.24s |  Anthropic apparently prioritized safety.
1187.24s - 1195.00s |  So they usually try not to respond or say like, oh, I'm a helpful agent and can't respond
1195.00s - 1196.96s |  to exploitation attempts.
1196.96s - 1201.20s |  And Google AI usually generates like random requests, which doesn't seem to be related
1201.20s - 1204.36s |  to the request you sent to it.
1204.36s - 1211.24s |  Most of the time, just like, welcome, or like, hello world, and stuff like that.
1211.24s - 1216.36s |  I really got surprised by LamaTree and Mistral.
1216.36s - 1222.52s |  Most of the cases, almost similar to commercial models.
1222.52s - 1227.44s |  So I really was impressed by that.
1227.44s - 1235.32s |  So another thought we had, and initially I mentioned one of the goals was to see if returning
1235.32s - 1243.80s |  convincing responses can maybe increase the attacker's engagement.
1243.80s - 1244.80s |  It actually increased.
1244.80s - 1247.52s |  Like, I mean, I don't have much data to prove.
1247.52s - 1250.36s |  And I just had like a few sensors and GCP.
1250.48s - 1253.04s |  I need more data to have a better answer for this.
1253.04s - 1254.60s |  And yeah, sorry to disappoint you.
1254.60s - 1256.96s |  I don't have really a better answer for that.
1256.96s - 1261.60s |  But at least in one case, it increased the attacker's engagement with my honeypot, which
1261.60s - 1265.20s |  costed me 20 bucks.
1265.20s - 1273.96s |  But yeah, also don't forget to put API usage limit, because yeah, for obvious reasons.
1273.96s - 1279.48s |  But yeah, I mean, I started looking at what this special activity was, why I got like
1279.48s - 1283.08s |  15,000 requests in one day.
1283.08s - 1285.76s |  And this was when I looked at it.
1285.76s - 1294.44s |  So apparently they were trying to find open HTTP proxy, and like the first few requests
1294.44s - 1300.64s |  you see here, the connect ones, and then the honeypot returned successful or connection
1300.64s - 1306.84s |  established, which made them believe that this is like the open HTTP proxy.
1306.84s - 1313.40s |  And then they started sending random request from different source IPs with different user
1313.40s - 1316.04s |  agent and randomized everything.
1316.04s - 1321.56s |  And I think my theory is that this seems to be some sort of ad fraud, because looking
1321.56s - 1328.40s |  at the request and looking at the website and JS and stuff like that, which you could
1328.40s - 1334.44s |  see there, it seemed to be ad fraud or generating some traffic to those domains.
1334.44s - 1340.44s |  Interestingly, I couldn't see any of these domains or IPs in Grain Noise or Shadow Server
1340.44s - 1342.84s |  or other honeypots out there.
1342.84s - 1351.20s |  And this kind of gives us this confirmation that, yeah, using LLM-based honeypots seems
1351.20s - 1352.28s |  to be working.
1352.28s - 1357.52s |  Because if I wanted to do it myself, like a random low-interaction honeypot, I probably
1357.64s - 1366.96s |  wouldn't think about, like, connect and these sort of responses.
1366.96s - 1367.96s |  And yeah.
1367.96s - 1370.76s |  So if you have any questions, I can answer that.
1370.76s - 1393.12s |  And while I'm waiting, you can just read this funny response.
1393.12s - 1394.60s |  I can't hear you well.
1394.60s - 1395.60s |  Is there a microphone or something?
1395.60s - 1399.25s |  Yes, sure.
1399.25s - 1423.98s |  It's pretty easy to detect these honeypots as well.
1423.98s - 1429.30s |  Like any kind of honeypots, including LLM-based ones, it's a bit harder to fingerprint these
1429.30s - 1433.10s |  because of the random responses it returns, but it's not impossible.
1433.10s - 1437.22s |  And I mean, if I want to do it, I just send, are you a honeypot or something, which you
1437.22s - 1443.86s |  sure shouldn't return 200 to the entire internet, and then you see what you get.
1443.86s - 1447.02s |  I actually had a challenge, but no one could solve it.
1447.02s - 1448.72s |  I just retweeted a few times.
1448.72s - 1450.66s |  But yeah, try to find this.
1450.66s - 1452.66s |  I have a sensor in GCP.
1452.66s - 1456.98s |  And by the end of tomorrow, you may be able to find it, maybe.
1456.98s - 1461.34s |  You can use Shodan, sense this, or also actively scan.
1461.34s - 1466.60s |  Yeah?
1466.72s - 1471.24s |  Have you considered using fine-tuning to generate more?
1471.24s - 1472.24s |  I had something.
1472.24s - 1473.64s |  I forgot to talk about it.
1473.64s - 1477.04s |  So if you use OpenAI's fine-tuning, I tried that.
1477.04s - 1478.04s |  And it's pretty easy.
1478.04s - 1482.64s |  You just give it examples of, yeah, are you a honeypot and stuff like that, and just return
1482.64s - 1483.64s |  404.
1483.64s - 1484.64s |  And it actually works.
1484.64s - 1490.44s |  Yeah.
1490.44s - 1491.44s |  OK.
1491.44s - 1492.44s |  It's all good.
1492.44s - 1492.46s |  Thank you.


url: https://www.youtube.com/watch?v=QvywfDmdasc
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
title:
DEF CON 32 - Ground Control to Major Threat Hacking the Space Link Extension Protocol - Andrzej Olch

content:
{
  "webpage_url": "https://www.youtube.com/watch?v=QvywfDmdasc",
  "title": "DEF CON 32 - Ground Control to Major Threat Hacking the Space Link Extension Protocol - Andrzej Olch",
  "description": "Space missions have increasingly been the subject in the context of security breaches and satellite hacks. The majority of discussions revolve around direct communication and access to spacecraft through means such as Software Defined Radio. However, the reality is that this approach isn't practical for most adversaries, as it requires substantial resources and is easily detectable due to the power and radio frequencies required to command a spacecraft. Instead, adversaries might shift their focus away from the Space Segment and opt for a more practical approach, such as accessing and exploiting the Ground Segment vulnerabilities and flaws in order to gain control over spacecraft. Every space mission comprises custom-made hardware and software components, which interact with each other utilizing dedicated protocols and standards designed and developed for this sole purpose. Numerous potential failure points can adversely impact a space mission, many of which persist on the ground. Considering the essential services they facilitate and the extent to which contemporary society relies on space technology, each component utilized in space missions should be regarded as integral to critical infrastructure and treated as such, particularly from a security standpoint. This study centers on the Space Link Extension (SLE) protocol, which is employed as a standard for communication between mission data systems and ground stations by various space agencies and organizations, including NASA and ESA. We will address the security concerns inherent in the SLE protocol. At the same time, we demonstrate methods and techniques malicious actors can employ to conduct a Denial of Service (DoS) or tap into the ground station communications, gaining control over an actual spacecraft. We will conclude this publication by presenting the reader with a possible mitigation strategy that we believe should be employed at the SLE protocol level. Additionally, we will outline a forecast for future work, detailing both planned endeavors and those already in progress, to further expand on this research.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1526,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Okay, so I'm gonna start
2.94s - 9.36s |  My name is Andy I work as a open security in in space industry in Europe
10.92s - 15.52s |  How many of you know or how many of you work in space industry
17.10s - 22.88s |  How many of you okay, that's some hands up how many of you know what the SLE is
25.30s - 27.30s |  Okay, that's like three people
27.90s - 29.38s |  excellent
29.38s - 33.04s |  so
33.16s - 35.70s |  Hacking satellites is nothing you think obviously
38.84s - 40.84s |  However, most of the discussion
41.12s - 43.68s |  revolve around the space segment and
44.76s - 49.00s |  the means of directly hacking the or accessing the satellite
50.48s - 52.48s |  However, I would argue that
54.16s - 56.16s |  It is the ground segment that is more
56.16s - 62.80s |  More likely to be targeted by the adversaries and that's because of it's
64.68s - 66.84s |  That's that's mainly because of the large
68.12s - 70.12s |  attack surface that it presents
70.84s - 75.80s |  So in this presentation, I will briefly compare the space segment with the ground segment
76.56s - 83.84s |  As in the in terms of attack surface, I will introduce you to the SLE protocol and some security
84.48s - 90.12s |  Aspects of it and then I will proceed to demonstrate how you can exploit
91.96s - 97.40s |  Some exploitation methods of the protocol and some mitigations against them
99.16s - 101.16s |  So just very briefly
101.40s - 103.40s |  Every space missions can be divided
103.96s - 110.64s |  Like loosely into space segment and the ground segment and the ground segment, of course also include the user segment for simplicity
113.84s - 117.76s |  In general, the space segment usually is much more complex than the ground segment
118.36s - 121.52s |  However, if you think about it, it is just like one node in the whole system
122.20s - 124.48s |  So the satellite is a very complete
125.48s - 131.20s |  Node, however, there is only one interface one one entry point interface and because of that
131.56s - 136.40s |  It has a very small attack surface and ground segment on the other hand has
137.32s - 140.04s |  Less complex elements to it, but there are many
141.16s - 143.16s |  available and because of that
143.16s - 145.76s |  It imposes much larger attack surface
147.48s - 149.48s |  On top of that
149.48s - 155.92s |  communicating the directives spacecraft is is quite challenging and not because of the technical aspect of it, but
156.52s - 158.40s |  because of the
158.40s - 164.24s |  environmental aspects like visibility orbit and also the distance from Earth and
166.08s - 168.08s |  On the other hand the ground segment
168.08s - 170.08s |  It
170.52s - 173.48s |  Uses main or it uses standard infrastructure, which means that
175.08s - 179.32s |  Most of the most of its components are also available are also vulnerable to
181.56s - 188.64s |  To the vulnerabilities that are present in any other infrastructure or software that we are using on a daily basis
189.32s - 190.52s |  and
190.52s - 196.24s |  Because most of the applications that are using space industry on the ground segment are custom development
196.72s - 198.72s |  I would say that there is
198.92s - 205.68s |  That that creates some additional avenues to find new vulnerabilities in it. And then again and then again
206.56s - 208.36s |  to add to
208.36s - 210.36s |  Try to hack the grounds segment
211.24s - 218.66s |  Components, there is no sophisticated equipment required. So this is an extremely high level
220.34s - 224.22s |  Like a presentation of a space mission where we divide space segment and
225.22s - 232.14s |  Separate it from the ground segment. Obviously on the space segment you have like you have a space asset, which is this might be a spacecraft
233.26s - 237.90s |  And then you have a ground station that communicates with the spacecraft. You have our mission control that
238.98s - 246.06s |  Uses ground station to communicate with the spacecraft and then you have a you have users that use the mission control applications
246.66s - 249.82s |  and they either work internally on
250.46s - 256.58s |  Dedicated workstations or they connect remotely through a VPN or jump hosts or whatever you might have
258.18s - 262.14s |  Now my argument is that it's gonna be much easier to hack
262.66s - 267.26s |  This thing that you see on the screen don't actually build it in order to communicate with
268.30s - 272.02s |  With many satellites, which you would like to which you would like to hack
273.42s - 275.42s |  So what is SLE?
276.62s - 278.62s |  SLE is a protocol
278.62s - 280.38s |  developed or
280.38s - 282.38s |  created by CCSDS
282.70s - 283.90s |  certification
283.90s - 285.90s |  Standardization body is a standard
286.26s - 288.26s |  It is used to send
288.34s - 291.10s |  telecommands and receive telemetry from
291.78s - 299.14s |  Spacecraft it is based on TCP IP. It supports transport layer and encoding and authentication
300.38s - 304.74s |  And it can have two roles. One is the SLE provider, which is in our case
304.74s - 310.26s |  It's like a ground station and then you have SLE user which which is like a mission control system
310.74s - 317.70s |  Now, so in a nutshell it defines our a protocol to transfer the PDUs
318.82s - 320.82s |  using the TCP
321.42s - 325.58s |  For transfer for data transfer and ASL one for data encoding and
326.42s - 330.98s |  In the system, there are two places. Well, okay, there could be many places
330.98s - 334.78s |  But in principle there are at least two places where the SLE is used
335.14s - 341.06s |  it is in the communication between the MCS which is mission control system and the ground station and
341.58s - 346.98s |  Also between the ground station and the and the SAT and the space asset, right?
347.66s - 349.66s |  so big but because we are hacking the
350.26s - 354.46s |  We are hacking the ground segment. We are focusing only on the link that is highlighted on the slide
355.18s - 357.78s |  So here is our this slide here
357.78s - 363.46s |  you can see all the organizations and most of the companies that use or the most famous companies that use the
364.02s - 366.02s |  SLE to some extent
367.26s - 369.26s |  If you look on the standard
369.34s - 374.58s |  Itself for the documentation. Here's a list of all agencies that are responsible for development of the standard
375.46s - 378.50s |  so there are quite a few quite a few of them and
379.10s - 386.14s |  There are at least three times more different organizations public and private companies using
387.02s - 389.02s |  the standard for space operations
390.70s - 393.02s |  Also some of the ground segment
394.02s - 401.14s |  Specialized equipment comes with support to the SLE if you look at the for instance Saffron Cortex devices
401.22s - 403.22s |  They all support SLE
403.74s - 408.70s |  And also here NASA space near space network they proudly
410.54s - 417.06s |  Share that they are also supporting SLE protocols on the list of their interfaces and capabilities
418.62s - 424.10s |  So for the purpose of this research research we focus only on the commanding capabilities
424.18s - 427.14s |  So it is called FCLTU which is forward link
427.94s - 429.94s |  forward communication in transport
430.46s - 432.46s |  unit transmission unit and
432.98s - 435.66s |  It is basically the thing that you are sending to spacecraft
436.38s - 441.18s |  It combined it or the service that you are using to send telecommands to spacecraft
442.02s - 444.02s |  it defines a number of
444.34s - 449.66s |  Quite a decent list of different types of operations, but for this research. We are focusing only on the bind
450.38s - 455.18s |  Unbind to establish and connection and disconnect and then start and stop to set up
455.54s - 459.74s |  Certain properties on the ground station equipment, and then we also
460.26s - 465.70s |  Look at the transfer data operation, which is used to send the actual telecommands to spacecraft
467.64s - 469.64s |  now as per documentation
469.92s - 476.16s |  There is no data private privacy that comes with the SLE as a protocol or and also standard
477.16s - 483.80s |  It comes with a sequence numbering and this is supposed to be helped in preventing
484.76s - 486.64s |  injection as
486.64s - 488.96s |  potentially seizing control of spacecraft, but
489.92s - 491.92s |  That doesn't really work
491.96s - 499.36s |  There is an easy way to to bypass this restriction. And also there is an authentication that is provided
499.96s - 504.84s |  out of the box, however is very susceptible to many the middle attacks because of the
505.88s - 512.04s |  Because of lack of the encryption. So later I will show you the demos how how this actually can work in practice
513.20s - 517.28s |  We have a very very very simple test environment
518.28s - 521.20s |  Where we assume that so this is
522.84s - 528.16s |  Assume bridge testing we assume that the adversaries are in the in the network already
529.24s - 534.20s |  and we have SLE provider that plays role as a ground station and
535.28s - 542.24s |  Which is like a simple Debian VM and with European Space Agency SLE API implementation installed on it
543.24s - 547.20s |  SLE user is another VM which plays role as a mission control system
548.04s - 554.20s |  It's also Debian and the SLE implementation used there is the simple Python SLE, which is which is like a
555.08s - 557.20s |  PIB package you can download it
558.32s - 560.76s |  And this is just demonstrate that it doesn't really matter
560.76s - 567.56s |  What is the implementation of the SLE as long as you are using any SLE or any implementation that follows the standard your
567.96s - 569.96s |  operations are gonna be vulnerable to
570.92s - 572.92s |  Those attacks which I'm gonna demonstrate
573.56s - 576.60s |  So the because there is no encryption. We thought that the best
577.92s - 583.40s |  The best idea will be to wrap our attack scenarios within the many the middle attack
583.80s - 587.00s |  Technique, so at the high level we do the ARP spoofing
587.52s - 591.96s |  We capture the data at the TCP frame level we decode them using the ISP 1
592.40s - 595.76s |  We decode the ISP 1 frames. I will explain what it is in a second
596.76s - 603.20s |  And then we manipulate the content of the CLTUs that are gonna be sent to spacecraft and then we update the TCP frame and
603.20s - 604.96s |  Then push it forward
604.96s - 606.96s |  to the receiving part
609.28s - 612.92s |  Okay, you everyone knows how the ARP spoofing works, so I'm gonna skip that part
613.24s - 616.92s |  We basically grab the packets and put it in the net filter queue
616.92s - 622.48s |  And then we process them so the interesting part is the the processing part
623.48s - 625.48s |  As I mentioned before the
627.40s - 633.12s |  The data is obviously in the TCP frame data field and these are the SLE PDUs
633.84s - 640.08s |  elements which are in the ISP 1 format now ISP 1 is based on the ASN 1 encoding and
641.24s - 643.88s |  Which is basically a simple tagline value
644.52s - 648.80s |  Data, which varies very easy to decode and however there are a few
649.72s - 651.72s |  apart from the TLV there are a few
653.32s - 657.64s |  The custom structures and context related sequences, which
658.40s - 662.12s |  You would have to struggle a little bit to decode, but the standard is pretty well described
662.12s - 666.08s |  So it didn't take too much time to figure out what they are
667.16s - 673.52s |  so and as I mentioned before we in our demo we are focusing on the only only on the telecommanding part because our goal is to
674.44s - 677.16s |  Start sending something to spacecraft to the ground station
679.60s - 681.60s |  Once you decode the
681.72s - 683.80s |  The data using the ASN 1
685.52s - 689.48s |  Encoding you have to map it to the FCLTU structures
690.12s - 696.72s |  And this is also something that is described in the standard. So it's available to everyone and that's what we used
697.40s - 700.40s |  So this is an example of a bind
701.24s - 707.20s |  Message or bind operation between the ground station and between the mission control system and the ground station
707.64s - 711.20s |  So we can see that we have an ISP header then you have a main structure
711.20s - 718.56s |  Which is followed by the additional structure and then somewhere in the middle. We have the credentials and there's also some additional
719.36s - 722.52s |  Additional elements which you can overwrite or you can you can play with
725.48s - 729.04s |  Again there is no encryption. So all those all those bytes are
731.04s - 733.04s |  They mean what it says, right
733.48s - 735.76s |  so in terms of demo
736.76s - 743.04s |  Just to establish the baseline, I will show you how the typical communication between the MCS and the ground station looks like
743.96s - 747.72s |  In this demo, you will see that first we are doing the binding between the two nodes
747.72s - 753.96s |  Then we are sending the we are asking the receiving node to start the operations. We are sending some data
754.60s - 757.52s |  Then we are stopping it and then we are unbinding it
759.00s - 761.08s |  Unbinding it and I'll try to play
762.08s - 769.31s |  I'll try to play the video. Let me know if you can see it
770.99s - 777.23s |  Okay, so on the on the top screen you see the on the bottom part you see the
777.87s - 780.39s |  SLE provider on the top you see the SLE
781.87s - 783.55s |  SLE user
783.55s - 787.11s |  The provider is the ground station and the user is the mission control system
787.99s - 789.19s |  so
789.19s - 790.79s |  we start
790.79s - 792.79s |  the SLE provider and
793.63s - 799.64s |  Then we run our test you can see that we have first established the connection
800.68s - 805.32s |  we send the bind which was the successful operation and then we are
808.53s - 812.09s |  We are sending the start operation and then we are sending the data
813.41s - 816.29s |  We are sending the data to the ground station. So this this
818.37s - 820.37s |  This
820.89s - 826.25s |  String of bytes is what was gonna get eventually to the spacecraft like some of those bytes
826.93s - 828.93s |  and then we stop it and
830.13s - 836.13s |  And then we unbind right so that's like the nominal
837.41s - 842.38s |  situation
842.50s - 855.97s |  So what happens then so one of the things the first things which is which we can do is to
856.89s - 858.89s |  cost a little bit of denial of service
859.25s - 866.81s |  by preventing the users from authenticating to the ground station and the reason why it's it's it's an annoying way of
867.37s - 870.37s |  Doing this for the user is because the SLE provider when
870.97s - 877.45s |  When the user fails authentication the SLE provider simply drops the connection. There is no and there is no feedback whatsoever
877.45s - 882.17s |  So the users don't know what is the reason of failing the connection?
882.81s - 884.81s |  It's only the ground station that knows
885.33s - 887.05s |  so in this case, we
887.05s - 892.53s |  We basically do the same which we try to grab the bind operation the bind operation
892.69s - 895.25s |  Which has a very well-defined structure
895.25s - 896.33s |  so when you
896.33s - 897.93s |  Monitoring what's happening on the wire?
897.93s - 904.53s |  You can easily find patterns and then you can simply mangle the bytes which are responsible for the authentication
905.57s - 907.25s |  so
907.25s - 908.93s |  What's gonna happen?
908.93s - 922.77s |  So what's gonna happen is the following
923.45s - 925.69s |  On the right hand side you have our exploit
926.33s - 933.01s |  And then on the right hand side you have at the bottom you again have SLE provider and on the top is the is our
934.81s - 938.77s |  Is our MCS mission control system that connects to the ground station
939.73s - 953.98s |  So we start the ARF spoofing and we start observing the communication between the both and then you can see
956.02s - 958.02s |  Despite the fact that we have
958.82s - 960.82s |  Sent the start the bind request
961.10s - 963.78s |  We didn't succeed. There is an exception on the
964.58s - 966.58s |  ESSA SLE implementation
967.02s - 969.02s |  But there is no no feedback
969.74s - 971.42s |  Going back to the user
971.42s - 980.10s |  So at this point we we cannot really do anything
980.66s - 991.26s |  We see the authentication failure. So this way you can you can create a denial of service
992.30s - 994.30s |  As long as you are in the network
994.42s - 999.21s |  so the next
999.21s - 1000.29s |  demo
1000.29s - 1008.35s |  This is also quite similar similar to the previous one. But here we are actually grabbing the credentials because
1008.89s - 1011.09s |  As I mentioned before we can actually reuse them
1012.53s - 1014.53s |  So here you will see
1014.61s - 1018.21s |  Here you will see grabbing the credentials from the bind message
1019.01s - 1030.84s |  And then display them on the screen. It's a similar situation
1031.80s - 1040.39s |  So we start the SLE provider. We started our exploit. We start the SLE provider. We start the
1042.87s - 1044.83s |  our MCS
1044.83s - 1047.43s |  We capture the credentials the bind is successful
1048.15s - 1050.75s |  But we did capture the credentials. So now we can reuse them
1053.47s - 1055.35s |  the credentials are
1055.35s - 1059.15s |  Encrypted but it doesn't matter because you will see later that
1060.27s - 1063.55s |  SLE as a protocol is vulnerable to replay attacks. So
1065.11s - 1068.39s |  You can just grab them and then you can use them for your own connection
1068.71s - 1081.05s |  I'm trying to okay
1081.05s - 1088.89s |  So as mentioned before we can we can let the management operations go as they are and instead we can in a stealth mode
1089.73s - 1093.97s |  Try to tamper with the data themselves the ones that are gonna get to the spacecraft
1094.61s - 1100.69s |  So we're gonna in this case, we're not gonna cut we're not gonna do anything to the operations. We only capture the
1102.05s - 1104.41s |  The frames which contain the transfer data PDFs
1106.05s - 1108.05s |  And then we
1108.89s - 1115.25s |  Change the content of the of the commands that are sent that are being sent to spacecraft
1115.73s - 1128.93s |  So here basically on the at the bottom screen at the bottom side
1129.25s - 1135.57s |  You can see on the left side you can see the SLE provider or the ground station and then mission control system on the right
1135.57s - 1139.05s |  side and then on top you can see our exploit which
1140.13s - 1141.57s |  is
1141.57s - 1143.57s |  searching for a specific
1144.93s - 1146.93s |  String of bytes and then
1147.97s - 1158.70s |  replaces it with something else so
1160.02s - 1166.06s |  Because there is absolutely no verification of what the MCS is actually sending to the ground station
1166.90s - 1170.66s |  And the ground station simply takes it and forwards it to the spacecraft
1171.98s - 1173.98s |  this can be done in a stealth mode and
1174.66s - 1180.06s |  It's gonna be very difficult unless you are monitoring for our spoofing then it's gonna be difficult for
1180.82s - 1196.62s |  For the operators to realize that they are sending something that they have not meant to send. So
1198.38s - 1200.38s |  This is the string which we
1201.10s - 1207.74s |  This is what the MCS sent and this is what has been received at the ground station
1209.14s - 1211.14s |  However, we can see that in the communication
1212.26s - 1215.18s |  Everything is everything is verified. Everything is fine
1216.42s - 1219.98s |  Neither MCS nor ground station complain about it. So
1223.01s - 1225.85s |  This way we can send whatever we want to spacecraft
1225.85s - 1237.78s |  And so I think the most interesting demo is where you can actually take all those
1238.50s - 1240.50s |  All those elements together and
1240.74s - 1246.26s |  You can prepare an exploit in a way that it will take over or let you take over the SLE session
1246.70s - 1252.94s |  So here we are capturing the bind and manipulate the credential structures in order to prevent authentication
1253.58s - 1258.26s |  Then we reuse the credentials which we have captured for our own SLE session
1259.14s - 1261.14s |  and we can
1261.38s - 1267.78s |  Keep on using those credentials for as long as it is defined in the authentication delay of the SLE provider
1270.22s - 1272.38s |  Configuration and from what I have seen so far
1273.30s - 1275.26s |  It is a very long
1275.26s - 1278.10s |  very long delay because of the because of the
1279.26s - 1281.26s |  because the propagation delay and all
1282.70s - 1287.58s |  All the distance depending on the distance between the between the earth and and the spacecraft
1288.54s - 1293.58s |  By default this value is usually around 600 seconds. So that's that's a lot of time to actually
1294.42s - 1297.48s |  cause a damage and start sending something that is
1298.54s - 1303.94s |  It's gonna make some trouble on the spacecraft side. So
1304.66s - 1310.06s |  So here it is
1310.06s - 1315.54s |  It is a it is a semi automated exploit because I want to show you how you can actually
1316.94s - 1318.94s |  How this works in details
1319.10s - 1322.46s |  So we are starting the we are starting on the right hand side
1322.46s - 1328.54s |  We are starting the SLE provider on the right hand side on the top. We are starting the MCS. MCS tries to bind
1329.26s - 1332.94s |  but it fails our exploit code
1333.74s - 1336.98s |  credentials and then we are gonna copy those credentials and
1338.14s - 1340.14s |  Reuse them in another
1343.66s - 1345.66s |  In another exploit
1346.30s - 1353.10s |  As you can see nothing really happened on the ground station there is an exception but that's because that implementation doesn't handle it properly
1353.58s - 1357.42s |  but from the ground segment from from the ground station point of view, that's
1358.34s - 1366.14s |  That's um, that's a nominal situation because someone tried to authenticate they failed so nothing happened on the ground station
1366.14s - 1368.94s |  We're gonna keep on waiting and then in the meantime, the adversaries can actually
1369.50s - 1378.87s |  Bind to the ground station as if they were a legitimate mission control system and then
1379.55s - 1381.55s |  We managed to bind to the ground station
1388.82s - 1390.82s |  We are starting the
1390.98s - 1394.78s |  Typical management operations and then we are sending the data
1395.62s - 1407.10s |  As adversaries or as the MCS, but we are adversaries in this case. So
1408.02s - 1412.54s |  That's basically how you take over control of a spacecraft if you have access to the ground station
1412.98s - 1423.91s |  So in conclusion, it was just one one of the methods that you can take over the control of spacecraft using SLE
1425.47s - 1430.67s |  Protocol as mentioned before we focus only on the commanding parts, but there is also telemetry
1431.27s - 1435.79s |  Part which if you if you if you can imagine there are there are quite
1436.55s - 1444.19s |  Nasty things you can do with telemetry and and how we can mangle the bytes and how we can affect the operations
1444.75s - 1446.63s |  by
1446.63s - 1449.07s |  Changing the telemetry that the spacecraft is receiving
1450.07s - 1457.47s |  So important bit is that all that knowledge which I presented here is is based on OSINT all the standards or the documentations are
1457.79s - 1458.87s |  public
1458.87s - 1460.87s |  So you can go and have a look
1461.87s - 1467.23s |  CCSDS is trying to mitigate those issues providing space data link security
1467.55s - 1474.51s |  However, this is only between the ground station and the between the ground station the spacecraft itself. The ground segment is still going to be vulnerable and
1475.59s - 1480.99s |  Our argument will be that CCSDS PKI concept could be used
1481.87s - 1484.91s |  Instead of SDS to enable TSL like
1485.31s - 1491.99s |  Features on the ISP level and therefore all the communication will be encrypted and everything all the issues, which I'm presenting today
1492.23s - 1495.93s |  They will go away
1496.61s - 1503.69s |  Currently we are discussing with European Space Agency to currently we're discussing space industry with we want to make some additional tests
1504.57s - 1505.73s |  and
1505.73s - 1508.89s |  Here is the list of all resources. You can have a look and
1509.81s - 1515.97s |  The publication is gonna be available as of today on this website so you can have a look at all the details
1516.61s - 1521.17s |  How it is on what I have just described in this presentation
1522.41s - 1524.41s |  So, thanks. Thank you very much


url: https://www.youtube.com/watch?v=PFeqxSD7Gh8
title: DEF CON 32 - Kubernetes Attack Simulation The Definitive Guide - Leo Tsaousis
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=PFeqxSD7Gh8",
  "title": "DEF CON 32 - Kubernetes Attack Simulation The Definitive Guide - Leo Tsaousis",
  "description": "So your organization decided to follow the trend and switched to Kubernetes for hosting their applications. And this means that the mission for the SOC, has now changed from monitoring servers and networks, to building detective capability for a container orchestration platform. Where do you even start with for Kubernetes TTPs? What attack signatures should you alert upon, and what logs are there to look for in first place?\n\nA similar challenge arises for the offensive security practitioner: What strategies exist for performing continuous Kubernetes threat emulation? Infrastructure technologies have changed rapidly, and adversaries have adapted. Despite the novelty of attack surface, insider threats still remain relevant, and prevention alone is not enough to manage the risk posed to the modern enterprise.\n\nThis talk will explain the benefits of investing in a proactive approach to the security of your Kubernetes clusters through collaborative purple teams, and will provide a comprehensive guide for doing so \u2013 as informed by our latest research and experience in running attack simulations against large enterprises. Attendees will get up to speed with Kubernetes security monitoring concepts and will take away key advice for planning and executing successful attack detection exercises against containerized environments.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1605,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Hello, everyone, and thanks for joining this talk.
2.36s - 4.28s |  Today, we're going to talk about Kubernetes
4.28s - 7.56s |  and specifically how you can run successful attack simulation
7.56s - 9.08s |  exercises.
9.08s - 10.76s |  First of all, a few words about myself.
10.76s - 11.44s |  My name is Leo.
11.44s - 13.56s |  I'm a senior security consultant at WithSecure
13.56s - 15.56s |  based in Manchester, UK.
15.56s - 17.84s |  I'm focusing mostly on threat simulation
17.84s - 20.28s |  and, generally speaking, collaborative security
20.28s - 20.96s |  assessments.
20.96s - 24.40s |  So one challenge that our clients at WithSecure
24.40s - 26.68s |  typically come to us with is, how can we
26.68s - 30.64s |  measure our capability to detect attacks in X environment?
30.64s - 33.16s |  And the environments we typically see are of all sorts.
33.16s - 36.72s |  Windows, Linux, mobile, macOS, on-prem cloud,
36.72s - 39.92s |  and even container orchestration environments like Kubernetes.
39.92s - 43.72s |  So when, a while ago, one of our more mature clients
43.72s - 45.92s |  were looking to assess and improve
45.92s - 48.08s |  their blue team capability against attacks
48.08s - 50.64s |  in a Kubernetes environment, we approached this
50.64s - 53.44s |  as we usually do, with a threefold adversary simulation
53.44s - 53.96s |  assessment.
54.00s - 56.36s |  So first, we did some threat modeling,
56.36s - 59.68s |  just to better understand the risks to this novel platform.
59.68s - 62.36s |  Then, we wrote some tooling in order
62.36s - 64.32s |  to simulate some attacks at scale.
64.32s - 66.52s |  And finally, we executed the test cases
66.52s - 70.48s |  we designed side by side with the blue team,
70.48s - 72.00s |  researching along the way for means
72.00s - 74.60s |  to improve visibility and alerting
74.60s - 76.96s |  within the Kubernetes ecosystem.
76.96s - 78.96s |  But this research didn't really stop there.
78.96s - 80.52s |  It didn't stop after that project.
80.52s - 82.84s |  We kept working on it in the background.
82.84s - 84.80s |  And this is what we're talking about today.
84.80s - 87.20s |  We'll start with a very gentle introduction to Kubernetes.
87.20s - 88.40s |  I know this is Adversary Village.
88.40s - 89.56s |  It's not a cloud conference.
89.56s - 92.76s |  So if you're not familiar with Kubernetes, fear not.
92.76s - 95.52s |  We'll talk about the threats posed to a Kubernetes cluster
95.52s - 97.64s |  and why threat modeling is essential for the success
97.64s - 99.80s |  of any security exercise.
99.80s - 102.04s |  And then we'll dive headfirst into Kubernetes attack
102.04s - 103.04s |  simulation topics.
103.04s - 106.12s |  And we're going to look at tools, operational planning,
106.12s - 108.24s |  and eventually execution.
108.24s - 110.20s |  And this talk isn't only for offensive security
110.20s - 111.12s |  practitioners.
111.12s - 113.88s |  So we'll cover some basic Kubernetes detection concepts
113.88s - 117.56s |  as well to see things from the perspective of the SOC.
117.56s - 120.24s |  We'll look at things like log sources, detection engineering,
120.24s - 121.76s |  and so on.
121.76s - 124.00s |  And finally, we'll demonstrate everything
124.00s - 127.16s |  in an end-to-end simulation of an attack against the cluster
127.16s - 129.08s |  using the tool we will be releasing shortly
129.08s - 131.44s |  after this talk.
131.44s - 132.40s |  OK.
132.40s - 135.60s |  OK, as promised, let's start with some introductions.
135.60s - 138.00s |  We do that in order to introduce all the things that
138.00s - 142.08s |  will come into play later, both in the slides and in the demo.
142.08s - 144.24s |  But the thing is, if you're even remotely familiar
144.24s - 147.28s |  with Kubernetes, you will know that it's complicated.
147.28s - 149.68s |  So just a word of caution, this is not
149.68s - 151.04s |  going to be an in-depth analysis.
151.04s - 152.84s |  It will be deliberately incomplete.
152.84s - 155.40s |  In fact, it's probably going to be the fastest introduction
155.40s - 156.76s |  to Kubernetes ever given.
156.76s - 158.84s |  So please bear with me.
158.84s - 162.28s |  So our system in question, the Kubernetes cluster,
162.28s - 163.80s |  consists of a set of worker machines.
163.80s - 165.84s |  We call them nodes, right?
165.84s - 168.24s |  And these nodes run containerized applications.
168.24s - 169.92s |  They are managed by the control plane
169.92s - 171.72s |  over there on the left of the slide.
171.72s - 173.48s |  And in order to run workloads, they
173.48s - 175.72s |  need to have a container runtime installed,
175.72s - 178.44s |  such as container D or, in older versions,
178.44s - 180.60s |  Docker, as well as an agent called
180.60s - 183.36s |  the kubelet, which communicates with the control plane
183.36s - 186.56s |  and specifically the API server to receive instructions.
186.56s - 189.04s |  Now, this component that I mentioned, the API server,
189.04s - 190.28s |  is in the heart of the cluster.
190.28s - 193.04s |  It's the front end that all internal and external parties
193.04s - 194.20s |  communicate with.
194.20s - 196.32s |  It exposes a REST API, which clients
196.32s - 198.84s |  can talk to if they want to interact with Kubernetes.
198.84s - 201.64s |  And I'm talking about clients like users or services,
201.64s - 203.84s |  like CICD pipelines.
203.84s - 206.28s |  But it's important to remember that humans most commonly
206.28s - 210.28s |  use kubectl instead of just sending raw HTTP requests.
210.28s - 212.24s |  Now, when it comes to running applications,
212.24s - 215.32s |  the basic building block in Kubernetes is a pod.
215.32s - 218.00s |  A pod can consist of one or more containers
218.00s - 221.12s |  whose images are pulled from registries, as well as volumes,
221.12s - 222.92s |  storage resources.
222.92s - 224.80s |  What usually happens in the real world
224.80s - 226.88s |  is that workloads aren't actually
226.88s - 230.36s |  deployed as individual pods, but as managed collections
230.36s - 233.68s |  of pods, like daemon certs or deployments.
233.68s - 235.44s |  But beyond pods and deployments, there's
235.44s - 238.64s |  a few more types of objects that Kubernetes understands,
238.64s - 241.76s |  or resources, such as secrets or services.
241.76s - 244.72s |  And all these resources can then be logically grouped
244.72s - 247.44s |  into different namespaces for each different project, which
247.44s - 250.64s |  you can think of like tenants in the cloud world.
250.64s - 252.06s |  And finally, there's a third layer,
252.06s - 255.58s |  besides the physical and the logical, that of authorization,
255.58s - 257.94s |  with the most common authorization model being RBAC,
257.94s - 259.90s |  role-based access control.
259.90s - 261.86s |  RBAC defines the potential entities
261.86s - 264.42s |  and allows you to write policies for the permissions
264.42s - 267.10s |  that these entities will have against resources.
267.10s - 269.98s |  So in the context of RBAC, humans
269.98s - 272.26s |  are represented as user objects that
272.26s - 274.30s |  can authenticate using various mechanisms,
274.30s - 278.18s |  like MTLS client certificates, Active Directory, IAM roles,
278.18s - 279.30s |  and so on.
279.30s - 281.34s |  And you also get pods or external services
281.34s - 283.42s |  that are associated with service accounts.
283.42s - 285.50s |  And service accounts authenticate using tokens,
285.50s - 288.70s |  JSON Web Tokens, JWTs.
288.70s - 292.54s |  OK, that was easy, right?
292.54s - 294.78s |  One thing to remember, though, is that in Kubernetes,
294.78s - 296.10s |  everything can be replaced.
296.10s - 297.42s |  It's built to be extensible.
297.42s - 301.06s |  So it is 100% certain that your mileage will vary.
301.06s - 303.18s |  And you will have numerous third-party technologies
303.18s - 305.30s |  running in your cluster, technologies
305.30s - 307.98s |  like the ones tracked in the CNCF landscape, which
307.98s - 309.70s |  introduce their own set of risks when
309.70s - 310.98s |  deployed inside your cluster.
311.74s - 315.26s |  In order to tailor any security exercise to your environment
315.26s - 317.74s |  with its own intricacies, it's essential you perform
317.74s - 319.06s |  some threat modeling first.
319.06s - 320.74s |  And that means answering a few questions
320.74s - 323.02s |  like, what are the assets I must protect?
323.02s - 325.02s |  And where would attacks come from?
325.02s - 328.26s |  And why would attackers target Kubernetes in first place?
328.26s - 330.54s |  Let's start with an enumeration of the attack surfaces.
330.54s - 331.98s |  This will also help us understand
331.98s - 334.86s |  which levels we must execute in if we're looking
334.86s - 336.94s |  to simulate these attacks.
336.94s - 339.54s |  In the most typical scenario, attacks
339.54s - 341.70s |  will originate from the container level, the code
341.70s - 342.66s |  running within the pod.
342.66s - 345.78s |  For example, think of a compromised web service
345.78s - 348.50s |  or a backdoored image that found its way into your cluster
348.50s - 349.54s |  somehow.
349.54s - 351.82s |  And if that pod is assigned a service account,
351.82s - 353.74s |  the attacker can talk to the control plane
353.74s - 356.42s |  in a limited security context, hopefully,
356.42s - 359.10s |  unless they manage to break out of the container.
359.10s - 361.50s |  That way, they're on the node, the underlying host,
361.50s - 363.90s |  with potential access to other Kubernetes resources
363.90s - 366.66s |  from other namespaces and with even higher security
366.66s - 368.90s |  privileges, as they will most likely impersonate
368.90s - 370.54s |  the kubelet.
370.54s - 372.58s |  And of course, there's always a threat of attacks
372.58s - 374.22s |  from the outside world.
374.22s - 376.98s |  Think of scenarios like leaked or stolen credentials,
376.98s - 379.78s |  a compromised service, a malicious user, a coerced user,
379.78s - 381.90s |  and so on and so on.
381.90s - 383.34s |  So once they're inside your cluster,
383.34s - 384.50s |  what will they move towards?
384.50s - 386.90s |  What's the final objective there?
386.90s - 389.82s |  An obvious answer to this one is, of course, the workloads.
389.82s - 392.30s |  If Kubernetes is the underlying platform
392.30s - 394.46s |  that your critical workloads are running in,
394.46s - 396.58s |  then it's a way into them.
396.58s - 398.42s |  It's a way into the workload.
398.46s - 401.38s |  So compromising Kubernetes could result
401.38s - 403.50s |  in unauthorized access to the data.
403.50s - 405.62s |  And we're talking about potentially sensitive data
405.62s - 408.26s |  that the apps may be handling, like proprietary software,
408.26s - 410.30s |  as you can see on this slide, that can be stolen
410.30s - 413.30s |  or even backdoored to achieve a supply chain compromise.
414.62s - 417.30s |  But actually, that's not the most common incentive.
417.30s - 420.18s |  In the age of cryptocurrency, every compute resource
420.18s - 423.46s |  makes for an attractive target for its immediate potential
423.46s - 424.90s |  for financial returns.
424.90s - 428.70s |  Compute, in and of itself, is therefore worth protecting.
428.70s - 430.78s |  And you'll see that various instances have been recorded
430.78s - 432.34s |  with this particular objective.
433.46s - 435.54s |  Kubernetes clusters are usually also deployed
435.54s - 437.14s |  as managed cloud services,
437.14s - 439.98s |  or broadly speaking, in cloud infrastructure.
439.98s - 442.22s |  So instead of going for the applications,
442.22s - 444.22s |  a Kubernetes attacker might actually be looking
444.22s - 445.78s |  for a way into the cloud infrastructure,
445.78s - 448.90s |  into the underlying infrastructure.
448.90s - 451.22s |  But we've also seen Kubernetes attack techniques
451.22s - 453.38s |  across all phases of the intrusion lifecycle,
453.38s - 454.90s |  including persistence methods
454.90s - 457.18s |  that could enable APT-like surveillance
457.18s - 458.70s |  through a long-term infection,
459.62s - 461.30s |  and even for defense evasion purposes,
461.30s - 464.54s |  as, after all, Kubernetes is yet another platform
464.54s - 466.54s |  where an intruder can dwell in,
466.54s - 469.02s |  and usually it's a less monitored platform,
469.02s - 470.46s |  which makes it a great place to hide
470.46s - 473.34s |  if you want to evade containment measures.
473.34s - 476.74s |  All right, so we know what adversaries are looking for.
476.74s - 478.34s |  We know where they'll come from.
478.34s - 479.94s |  Let's go ahead and simulate them.
479.94s - 482.90s |  Now, there's a few different approaches to go about this.
482.90s - 485.90s |  And instead of a stealthy, objective-based exercise,
485.90s - 488.66s |  we chose to adopt more of a Purple Team methodology.
488.66s - 490.62s |  And I know different people define Purple Teams differently,
490.62s - 492.10s |  so let me use the definition given
492.10s - 493.90s |  by the guys over at SpectreOps.
493.90s - 496.38s |  It talks about collaboration between offense and defense
496.38s - 499.54s |  with the aim to increase familiarity with TDPs.
499.54s - 501.70s |  And for a novel environment like Kubernetes,
501.70s - 503.74s |  we similarly decided it's more valuable
503.74s - 505.94s |  to opt for a collaborative engagement
505.94s - 508.66s |  and try to help the blue team understand attacker behaviors
508.66s - 510.42s |  instead of vulnerabilities.
510.42s - 512.46s |  And at WithSecure, we focus a bit more on detection,
512.46s - 514.66s |  so when we're planning a Purple Team exercise,
514.66s - 516.02s |  we do it in one of two ways,
516.02s - 517.42s |  depending on what we want to achieve.
517.42s - 520.74s |  So we could either aim to cover as many TDPs as possible,
520.74s - 523.26s |  executing them one after the other in isolation,
523.26s - 525.42s |  or we could chain a few attacks,
525.42s - 527.54s |  similar to how a threat actor would move,
527.54s - 529.78s |  to make it as realistic as possible.
529.78s - 531.06s |  And even mimic a specific campaign
531.06s - 533.34s |  from the ones we saw before.
533.34s - 535.06s |  Okay, let's look at these two options
535.06s - 536.82s |  in a little bit more detail
536.82s - 538.82s |  in the context of a Kubernetes exercise.
540.06s - 541.42s |  So for Kubernetes specifically,
541.42s - 544.26s |  we found that there aren't as many campaigns documented
544.26s - 546.46s |  as there are for on-prem infrastructure.
546.46s - 547.30s |  And as a result,
547.30s - 549.38s |  there's not a lot of threat intelligence available.
549.38s - 552.86s |  So when incidents do happen in other organizations,
552.86s - 555.74s |  they make for a good opportunity for your organization
555.74s - 558.70s |  to perform an emulation cycle, to perform a campaign.
558.70s - 560.62s |  In that case, you probably know already
560.62s - 562.90s |  which threat actor you want to emulate.
562.90s - 565.22s |  But if not, the security researchers over at Wiz
565.22s - 567.70s |  maintain this great matrix of cloud threats.
567.70s - 569.86s |  And that also covers Kubernetes incidents.
569.86s - 572.06s |  So it aggregates threat intelligence
572.06s - 573.26s |  from various blog posts,
573.26s - 575.90s |  like unit 42, Aqua, Sysdig, CrowdStrike,
575.90s - 577.66s |  all the ones we saw before.
577.66s - 580.90s |  And you can collect all this threat intelligence,
580.90s - 583.94s |  analyze it, and finally recreate an attack chain
583.94s - 586.22s |  and execute this inside your cluster.
586.22s - 587.74s |  Now, a nice way of documenting
587.74s - 591.18s |  these different emulation plans is Jupyter Notebooks.
591.18s - 592.94s |  And we've seen a bit in the demo
592.94s - 595.58s |  how Jupyter Notebooks can also streamline execution
595.58s - 597.42s |  of the attack simulation.
597.42s - 599.62s |  But for more of a one-off assessment,
600.38s - 601.46s |  or if you're looking to build a baseline
601.46s - 602.86s |  of your detection capability
602.86s - 605.14s |  against all the possible TDPs,
605.14s - 607.46s |  then you first need a list of all the different TDPs
607.46s - 609.18s |  for the platform in question.
609.18s - 612.86s |  In 2020, Microsoft released the Threat Matrix for Kubernetes
612.86s - 615.18s |  which was the first systematic categorization
615.18s - 617.82s |  of Kubernetes techniques observed until then.
617.82s - 619.86s |  And it seems to be actively maintained.
619.86s - 622.70s |  There's also a Mitre Attack Matrix for containers,
622.70s - 625.66s |  but it doesn't really care about the orchestration platform.
625.66s - 627.82s |  And I actually got some very good ideas for attacks
627.82s - 629.98s |  by looking at KubeHunter.
629.98s - 631.38s |  Although it's a vulnerability scanner,
631.38s - 633.14s |  it just had a long list of checks supported,
633.14s - 635.58s |  so it gave me some very good ideas.
635.58s - 637.22s |  But for more technical instructions
637.22s - 639.38s |  on how to execute each TDP,
639.38s - 641.14s |  I found the KubeNomicon to be a good source.
641.14s - 644.06s |  So shout out to Graham Helton from Google for his project.
645.02s - 646.86s |  And once you've designed these test cases,
646.86s - 650.46s |  one good way of describing them is via a code format,
650.46s - 651.62s |  allowing them to be maintained
651.62s - 653.90s |  in a version control system like Git.
653.90s - 655.98s |  And this is a well-known practice in DevSecOps.
656.26s - 658.74s |  Attack definitions as code, detections as code,
658.74s - 660.74s |  we can apply it here as well.
660.74s - 663.54s |  This way, as your Kubernetes environment evolves,
663.54s - 666.38s |  so does your repository of attacker test cases.
667.54s - 668.38s |  Fantastic.
668.38s - 670.18s |  So we have planned everything.
670.18s - 671.66s |  We are ready to get our hands dirty.
671.66s - 673.58s |  Let's start bashing kubectl commands.
674.78s - 676.22s |  No, that wouldn't scale very easily,
676.22s - 678.30s |  but thankfully there are a few simulation frameworks
678.30s - 681.14s |  out there to make our lives a bit easier.
681.14s - 682.38s |  Starting with the familiar ART,
682.38s - 684.58s |  Atomic Red Team by Red Canary.
684.58s - 685.42s |  This is Adversary Village.
685.42s - 686.86s |  I'm sure you're all aware of it.
686.86s - 689.42s |  Although it does support a few test cases
689.42s - 690.54s |  on the container level,
690.54s - 692.86s |  it's not really built for cloud environments.
692.86s - 694.58s |  So it doesn't really support attacks
694.58s - 696.54s |  against the Kubernetes control plane.
696.54s - 698.78s |  On the other hand, Stratus Red Team
698.78s - 700.54s |  was specifically made for the cloud
700.54s - 702.06s |  and for attack simulations.
702.06s - 705.50s |  So it even supports eight pure Kubernetes test cases.
705.50s - 709.34s |  So it's actually a good choice for this particular purpose.
709.34s - 711.30s |  However, you will find it's not very easy
711.30s - 712.50s |  to write new test cases.
712.50s - 714.54s |  And the fact that it runs outside of your cluster
715.50s - 716.34s |  kind of restricts the number of different levels
716.34s - 717.70s |  that it can execute in.
718.74s - 721.46s |  One tool that can in fact run from within the cluster
721.46s - 723.78s |  is Pirates by InGuardians.
723.78s - 726.58s |  It's also widely known, various talks, blog posts,
726.58s - 727.98s |  webinars out there talking about it.
727.98s - 728.90s |  It's so well known
728.90s - 731.62s |  that it's actually been used by threat actors.
731.62s - 735.02s |  But once again, the attacks it supports are hard-coded
735.02s - 738.46s |  and the tool itself doesn't really allow for customization.
738.46s - 741.74s |  So overall, when we were doing this research,
741.74s - 743.34s |  we realized that none of these tools
743.34s - 745.06s |  performed exactly what we wanted.
745.06s - 747.66s |  These options all had some limitations.
747.66s - 750.70s |  So we decided to extend our own existing tool, Leonidas,
750.70s - 752.38s |  to add Kubernetes support.
752.38s - 753.58s |  And if you're not familiar with it,
753.58s - 755.62s |  no, I did not write the original version.
755.62s - 758.90s |  It's not named after me, that would be a little bit lame.
758.90s - 760.42s |  I don't want to talk too much about Leonidas.
760.42s - 762.30s |  It's an open source tool.
762.30s - 765.74s |  My colleague Nick Jones originally wrote the AWS version.
765.74s - 768.78s |  And again, various presentations out there talking about it.
768.78s - 770.42s |  What made Leonidas attractive
770.42s - 772.78s |  for the challenge of Kubernetes attack simulations
772.78s - 774.82s |  was some of its core principles,
774.82s - 777.26s |  like the fact that it was built with extensibility in mind
777.26s - 780.10s |  and how friendly it was to write new test cases
780.10s - 781.98s |  without having to be a developer,
781.98s - 784.22s |  as well as the ability to run within your environment
784.22s - 785.86s |  and manage its own resources.
786.74s - 788.46s |  And these were the concepts that we applied
788.46s - 790.58s |  when building Kubernetes support for it.
790.58s - 792.86s |  We wanted something running within the cluster,
792.86s - 796.10s |  distributed as a disposable image, as an ephemeral image.
796.10s - 798.30s |  We wanted something that analysts or threat hunters
798.30s - 800.58s |  could trivially write new TTPs for.
801.58s - 803.62s |  But we also wanted purple teams
803.62s - 805.98s |  to have an easy way to execute them
805.98s - 808.26s |  by just interacting with an API,
808.26s - 810.70s |  as well as a way for operators and defenders
810.70s - 813.62s |  to track execution of each action.
813.62s - 815.06s |  And we can do that through the logs
815.06s - 817.46s |  that are stored and shipped to the scene,
817.46s - 821.10s |  along with all the other telemetry that the class generates.
821.10s - 822.94s |  Now, alongside this new version of Leonidas,
822.94s - 825.38s |  we are also releasing a set of Kubernetes test cases,
825.38s - 828.34s |  17 in total, not only to help you get started
828.34s - 829.78s |  writing attack definitions,
829.90s - 831.86s |  but also to showcase the tool's capabilities,
831.86s - 833.34s |  like running kubectl commands,
833.34s - 834.50s |  running always-level commands,
834.50s - 836.82s |  and even applying custom YAML manifests,
836.82s - 838.54s |  a lot of different options.
838.54s - 841.46s |  Okay, lastly, I want to talk about operations teams
841.46s - 844.74s |  and how they can apply the security monitoring concepts
844.74s - 845.82s |  of the traditional SOC
845.82s - 848.26s |  into container orchestration environment.
848.26s - 849.62s |  After all, the goal of any exercise
849.62s - 852.02s |  is to upskill defenders and build the capability.
853.34s - 855.98s |  The most important building block of security monitoring
855.98s - 858.10s |  is arguably logs, all right?
858.10s - 860.26s |  If you look at the official Kubernetes documentation,
860.26s - 863.74s |  however, you'll find there are plenty of logs available,
863.74s - 865.26s |  but no standard architecture
865.26s - 867.30s |  for what we call cluster-level logging.
867.30s - 869.90s |  This is left to the users to implement.
869.90s - 872.30s |  Roughly speaking, from all the different types,
872.30s - 874.46s |  there are, let's say we can categorize all of them
874.46s - 876.18s |  into three different types of log sources.
876.18s - 878.82s |  So first, we have logs from your application,
878.82s - 880.22s |  logs from the code,
880.22s - 882.98s |  which are exposed to container logs and pod logs.
882.98s - 885.78s |  You can collect them with the kubectl logs commands,
885.78s - 886.82s |  but they are ephemeral,
886.82s - 889.90s |  which means that if the pod terminates, the logs are gone.
890.90s - 893.10s |  We also have logs from Kubernetes components,
893.10s - 896.06s |  like the API server, the kubelet, the container runtime.
896.06s - 897.62s |  Just like container logs,
897.62s - 900.18s |  these ones are also stored on the nodes,
900.18s - 903.78s |  which means that actually in a production cluster,
903.78s - 906.46s |  nodes will be disposable.
906.46s - 909.18s |  If the VM is replaced, these logs are also gone.
909.18s - 911.42s |  So you need to take them out of the host while you can.
911.42s - 913.46s |  And thankfully, there's lots of solutions out there,
913.46s - 916.70s |  agent-based solutions like Fluentd that can do that.
916.70s - 917.78s |  And finally, we have logs
917.78s - 920.46s |  that aren't particularly native to Kubernetes,
920.46s - 921.46s |  but are still of interest
921.46s - 924.22s |  for the security of the overall ecosystem.
924.22s - 925.86s |  If your cluster is a managed service
925.86s - 927.42s |  from a public cloud provider,
927.42s - 931.18s |  then that cloud provider's logging and monitoring solutions
931.18s - 932.34s |  are also crucial to monitor,
932.34s - 934.86s |  like IAM logs or guard duty and stuff like that.
934.86s - 935.70s |  And similarly,
935.70s - 938.18s |  if you host your own internal image repositories,
938.18s - 941.38s |  we found that logs from these image repositories
941.38s - 944.86s |  could allow the correlation of certain attacker actions.
944.86s - 946.54s |  And that's not even the half of it.
947.38s - 948.90s |  There's just a ridiculous amount of logs
948.90s - 950.62s |  flowing throughout your cluster,
950.62s - 953.58s |  but not all of them are useful for detecting attacks.
953.58s - 956.18s |  The ones that are, are those selected here.
956.18s - 959.10s |  It's those that answer not so much why something happened,
959.10s - 962.18s |  but rather who did what, when, and where from.
963.06s - 965.54s |  And these security-relevant log sources
965.54s - 967.22s |  map to the execution levels,
967.22s - 968.98s |  if you remember from the previous slide,
968.98s - 971.34s |  which provides us visibility on the container level,
971.34s - 974.30s |  on the node level, and the control plane level.
974.30s - 975.14s |  And alongside those,
975.14s - 977.34s |  I also highlighted the cloud IAM logs,
977.34s - 978.58s |  because if you're running a managed cluster,
978.58s - 981.06s |  identity is always of security interest.
982.02s - 982.94s |  I want to take a couple of slides
982.94s - 984.82s |  to zoom in on the most important log source,
984.82s - 988.90s |  the true MVP of Kubernetes attack detection, the audit log.
988.90s - 989.98s |  You can consider the audit log
989.98s - 992.50s |  as the access logs of the API server,
992.50s - 993.58s |  which simply means that
993.58s - 995.18s |  if you're interacting with a control plane,
995.18s - 998.26s |  you're getting recorded, with some exceptions.
998.26s - 1000.78s |  The resulting events can be formatted in JSON,
1000.78s - 1002.78s |  and they answer the security investigation questions
1002.78s - 1004.30s |  that we raised before.
1004.30s - 1005.82s |  Important to mention, though,
1005.82s - 1007.82s |  these are not enabled by default.
1007.82s - 1010.34s |  To enable them, you need to define a node policy
1010.34s - 1012.18s |  and reconfigure the API server,
1012.18s - 1013.34s |  but you can't always do that,
1013.34s - 1014.94s |  for example, in managed clusters.
1014.94s - 1016.54s |  Some events will be very noisy,
1016.54s - 1017.78s |  others will be more important,
1017.78s - 1019.70s |  so you want to have more detail,
1019.70s - 1021.94s |  and that's why there's a few different verbosity levels
1021.94s - 1024.42s |  that you can set for each different type,
1024.42s - 1026.54s |  each different event type.
1026.54s - 1029.30s |  You can easily find a sample policy to get started with,
1029.30s - 1031.90s |  like the one I'm linking in the bottom of the slide,
1031.90s - 1033.54s |  but it's going to take some tuning
1033.54s - 1035.26s |  to find the perfect mix.
1036.30s - 1038.38s |  The API server can also be configured
1038.38s - 1039.86s |  to store audit logs locally,
1039.86s - 1041.06s |  or send them to a hook,
1041.06s - 1044.66s |  and both of these ways allow for wording to a scene.
1044.66s - 1045.50s |  Once you do that,
1045.50s - 1047.86s |  you now have the ability to write alert queries
1047.86s - 1049.10s |  upon these logs,
1049.10s - 1052.06s |  which brings us to the topic of detection engineering.
1052.06s - 1053.38s |  In its simplest form,
1053.38s - 1055.58s |  an alert for suspicious control plane activity
1055.58s - 1058.14s |  could be captured by the verb and the resource,
1058.14s - 1060.42s |  such as list secrets,
1060.42s - 1062.98s |  and this behavior can then be defined in a Sigma rule
1062.98s - 1065.58s |  for easier management and distribution.
1065.58s - 1067.46s |  We found that there weren't many Sigma rules
1067.46s - 1068.30s |  out there available,
1068.30s - 1071.26s |  in fact, there weren't any Sigma rules out there available
1071.26s - 1073.50s |  that operated on Kubernetes audit logs,
1073.50s - 1075.54s |  so we published a few,
1075.54s - 1077.58s |  and since this log source didn't really exist,
1077.58s - 1081.38s |  we also introduced it by contributing a backend pipeline
1081.38s - 1082.50s |  to the Sigma ecosystem
1082.50s - 1084.22s |  in order to convert rules to actual alerts
1084.22s - 1086.14s |  that a scene can understand.
1086.14s - 1088.98s |  But attacks could not only target the control plane,
1088.98s - 1090.10s |  if you remember from a previous slide,
1090.10s - 1092.54s |  they could originate from within the container,
1092.54s - 1094.98s |  but luckily, there's a lot of research in this area,
1094.98s - 1097.86s |  many solutions available like Falco or Tetragon,
1097.86s - 1100.06s |  that monitor containers by tapping into the kernel
1100.06s - 1103.10s |  of the underlying node using eBPF,
1103.10s - 1106.22s |  and this enables EDR style analysis of the syscalls,
1106.22s - 1109.34s |  which then allows the authoring of rules in an easy format
1109.34s - 1111.22s |  for suspicious control plane activity,
1111.22s - 1113.06s |  sorry, for suspicious process command lines,
1113.06s - 1114.78s |  for suspicious network activity,
1114.78s - 1116.62s |  and other system level events.
1117.94s - 1119.94s |  All right, now it is time for the demo,
1119.94s - 1121.14s |  so in the upcoming video,
1121.14s - 1123.78s |  we'll see how we can simulate a fictitious threat actor
1123.78s - 1125.98s |  who gets access to a cluster and performs some attacks,
1125.98s - 1128.38s |  we'll do that using Leonidas for Kubernetes,
1128.38s - 1129.90s |  and after we're on the attack chain,
1129.90s - 1130.82s |  we'll put our blue hats on,
1130.82s - 1133.90s |  we'll put our defender hats on, the Viking hat,
1133.90s - 1138.18s |  and look at Elastic and Falco, which we have set up,
1138.18s - 1140.14s |  just to see what alerts have been raised.
1140.14s - 1147.60s |  All right, let me switch to the demo video,
1147.60s - 1149.12s |  can you all see the video?
1149.12s - 1150.28s |  Okay, no?
1152.16s - 1156.50s |  Good thing I asked,
1156.50s - 1157.82s |  is it this way?
1160.46s - 1162.14s |  Now, I can't see how to maximize it though,
1162.14s - 1169.90s |  can I have some tech support here?
1169.90s - 1173.22s |  Yeah, but I can't see the pointer, so I can maximize it.
1173.22s - 1174.06s |  You reckon?
1175.94s - 1177.34s |  Nice.
1177.34s - 1179.46s |  The problem is that I can't see it.
1179.46s - 1181.46s |  All right, let's do it.
1181.46s - 1182.30s |  I won't.
1183.98s - 1185.54s |  Yeah, but I wanna talk over it.
1198.39s - 1200.07s |  You can switch your display settings,
1200.07s - 1204.20s |  so it's, yep, duplicated.
1204.20s - 1205.92s |  Yep, see it now?
1205.92s - 1207.60s |  Awesome, fixed.
1207.60s - 1208.44s |  All right, so,
1210.60s - 1212.32s |  so first thing we're gonna do is confirm connectivity
1212.32s - 1213.28s |  to the Kubernetes cluster,
1213.28s - 1215.44s |  we'll do that using a cluster info command,
1215.44s - 1216.64s |  and we see that indeed,
1216.64s - 1218.24s |  the Kubernetes cluster is up and running,
1218.24s - 1219.96s |  we also have the dashboard up and running,
1219.96s - 1223.20s |  and you can see we have a couple of namespaces
1223.20s - 1226.52s |  already there, including one called DharmaProds,
1226.52s - 1228.52s |  which has just one deployment in there,
1228.52s - 1229.52s |  it's called HVAC controller,
1229.52s - 1230.64s |  and once we click it,
1230.64s - 1232.60s |  we'll see that it includes a couple of pods,
1232.60s - 1233.80s |  one looking like a database,
1233.80s - 1235.84s |  and the other one potentially doing something sensitive,
1235.84s - 1236.76s |  HVAC controller.
1237.76s - 1238.64s |  And now we're gonna go ahead
1238.64s - 1240.88s |  and deploy Leonidas into that cluster.
1240.88s - 1243.12s |  To do that, we'll run a couple of generator commands,
1243.12s - 1246.08s |  generator is an accompanying tool
1246.08s - 1248.76s |  that allows deployment of Leonidas.
1248.76s - 1250.96s |  First, we're gonna generate the Python code
1250.96s - 1252.20s |  from the attack definitions
1252.20s - 1253.60s |  that we have previously defined,
1253.60s - 1256.36s |  and then we're gonna generate the Kubernetes resources
1256.36s - 1259.24s |  in the standard YAML manifest.
1259.24s - 1260.96s |  These resources will then go ahead
1260.96s - 1264.68s |  and kubectl apply into our cluster,
1264.68s - 1266.96s |  so that we can create the Leonidas deployment
1266.96s - 1269.08s |  into our namespace, into DharmaProds,
1269.08s - 1270.60s |  and you see that it started running.
1270.60s - 1274.20s |  Once it's completed, once deployment is completed,
1274.20s - 1276.72s |  we'll then expose the port,
1276.72s - 1279.04s |  we're using a kubectl port forward command,
1279.04s - 1281.44s |  KL, by the way, is an alias for kubectl,
1281.44s - 1283.48s |  and we bring it locally to port 5000
1283.48s - 1285.44s |  so we can interact with it.
1285.44s - 1287.40s |  And once this is done,
1287.40s - 1289.40s |  indeed, we can access the API,
1289.40s - 1292.76s |  it's the familiar API if you looked at Leonidas before.
1292.76s - 1294.84s |  There are two ways to interact with Leonidas,
1294.84s - 1297.80s |  one of them is via this very simple client,
1297.80s - 1300.00s |  you know, providing the values in all these fields
1300.00s - 1301.36s |  and then hitting execute.
1302.36s - 1305.32s |  But instead, we're gonna do it through a Jupyter notebook.
1306.64s - 1308.40s |  And in order to do that,
1308.40s - 1310.92s |  we first need to start the Jupyter service.
1310.92s - 1314.20s |  This is gonna open the port 8888.
1314.20s - 1317.80s |  Once we click it, we'll see the web UI of Jupyter,
1317.80s - 1319.12s |  navigate to the right directory
1319.12s - 1320.92s |  of the threat actors notebooks,
1320.92s - 1323.16s |  and open our own notebook for OF815.
1323.16s - 1325.88s |  Now, OF815 is our fictitious threat actor.
1327.68s - 1329.32s |  Like we said before, execute some attacks
1329.32s - 1330.40s |  against the Kubernetes cluster
1330.40s - 1331.88s |  and first get some access to it.
1331.88s - 1334.88s |  We've got a nice little visualization of it right here.
1334.88s - 1337.16s |  First step for it is to simulate the initial access.
1337.16s - 1338.16s |  Now, the typical scenario
1338.16s - 1340.52s |  would be a leaked kubeconfig file.
1340.52s - 1342.08s |  Actually, before we get to these attacks,
1342.08s - 1343.40s |  let's look at the Defender tech,
1343.40s - 1345.60s |  the Defender solutions we have up there, up and running.
1345.60s - 1347.04s |  We do have Elastic,
1347.04s - 1351.16s |  where we're forwarding audit logs from our cluster.
1352.16s - 1354.20s |  Nicely visualized with the verb resource,
1354.20s - 1355.32s |  like we said before.
1355.32s - 1358.84s |  And we also have some alert rules configured.
1358.84s - 1360.08s |  You can see on the right-hand side
1360.08s - 1361.44s |  that these are all enabled.
1362.32s - 1364.40s |  And just to make sure that nothing has fired just yet,
1364.40s - 1365.52s |  we're gonna refresh that page,
1365.52s - 1367.48s |  see no hits, and we're ready to go.
1367.48s - 1368.72s |  But before we start executing,
1368.72s - 1370.16s |  let's also look at Falco.
1370.16s - 1372.68s |  We've configured this on the nodes of the cluster
1372.68s - 1375.72s |  to monitor the containers, like we said before.
1375.72s - 1377.40s |  Cool, all right, let's start running the attack
1377.40s - 1378.24s |  step-by-step then.
1378.48s - 1381.88s |  So if we navigate back to the Jupyter Notebook,
1381.88s - 1384.44s |  we start hitting run through every different cell.
1384.44s - 1386.40s |  And the first step is to simulate the initial access.
1386.40s - 1388.92s |  So the typical scenario is a leaked kubeconfig file.
1388.92s - 1390.00s |  In that kubeconfig file,
1390.00s - 1392.72s |  there might be a service account token, a JWT.
1392.72s - 1396.44s |  And this token is what we're gonna instantiate a client with,
1396.44s - 1397.92s |  a client to Leonidas.
1397.92s - 1399.16s |  So behind the scenes,
1399.16s - 1401.48s |  this Jupyter Notebook is running some Python,
1401.48s - 1402.60s |  bare-bones Python.
1402.60s - 1404.40s |  We'll publish all of that, by the way, very soon.
1404.40s - 1406.12s |  And this interacts with the Leonidas service
1406.12s - 1407.68s |  running within the cluster.
1407.72s - 1410.60s |  So the first thing, once the attacker has obtained access,
1410.60s - 1412.04s |  would be to list their own permissions,
1412.04s - 1414.12s |  just to see what they can do.
1414.12s - 1416.84s |  You can do that using the self-subject review API.
1416.84s - 1420.92s |  So we just run that cell then and look at the results.
1420.92s - 1421.76s |  We observe in the results
1421.76s - 1424.84s |  that we have some permissions on the pods.
1424.84s - 1426.60s |  Crew permissions, create, read, update, delete
1426.60s - 1428.36s |  on the right-hand side of the slide.
1428.36s - 1430.96s |  And we also have some permissions on the secrets,
1430.96s - 1432.68s |  which is already a problem.
1432.68s - 1433.92s |  So using these permissions,
1433.92s - 1436.36s |  we're gonna go ahead and enumerate the pods.
1436.36s - 1437.60s |  You'll see, like we saw before,
1437.60s - 1441.36s |  patient DB, Leonidas deployment, and the HVAC controller.
1441.36s - 1443.44s |  And using the permissions we have over the secrets,
1443.44s - 1445.84s |  obviously, we're gonna list the secrets.
1445.84s - 1448.84s |  With some processing, with some post-processing,
1448.84s - 1451.56s |  we'll see that one of them looks like a password,
1451.56s - 1452.64s |  but we don't know yet.
1452.64s - 1455.40s |  But putting the pieces together, we have the database pod.
1455.40s - 1457.44s |  We have something that looks like a password.
1457.44s - 1459.48s |  So why not run a MySQL dump command
1459.48s - 1461.64s |  to get a dump and prepare it for exfiltration?
1461.64s - 1464.92s |  Sure enough, we provide the password on the command line.
1464.92s - 1466.44s |  The dump is being generated,
1466.44s - 1468.00s |  and we're ready to send that back.
1468.00s - 1471.48s |  Now, before we finish up with this attack,
1471.48s - 1474.80s |  the attacker also tries to perform some destructive activity
1474.80s - 1475.96s |  just to delete a deployment.
1475.96s - 1478.32s |  But this activity will fail because, as we saw before,
1478.32s - 1480.56s |  they do not have the permission to do so.
1480.56s - 1482.32s |  And finally, just to wrap it up,
1482.32s - 1483.60s |  just to wrap up the threat,
1483.60s - 1485.80s |  the Jupyter Notebook will print the table
1485.80s - 1487.44s |  of all the test cases that we executed
1487.44s - 1490.56s |  for good bookkeeping, timestamps, success status,
1490.56s - 1492.80s |  and the name of the test case.
1492.84s - 1497.37s |  Cool, so we'll now, as promised,
1497.37s - 1501.09s |  turn back to the detection capabilities,
1501.09s - 1502.09s |  blue team solutions,
1502.09s - 1504.13s |  and we'll see that two alerts have actually fired,
1504.13s - 1504.97s |  as promised.
1507.21s - 1509.61s |  And the same thing stands for Falco,
1509.61s - 1511.97s |  since it detected the MySQL dump command.
1513.05s - 1515.53s |  Don't worry about the too many lines.
1515.53s - 1517.05s |  It's just a misconfigured rule.
1517.05s - 1518.81s |  Important thing to notice is that it did capture
1518.81s - 1521.37s |  the MySQL dump command executing within the cluster,
1521.37s - 1522.41s |  within the container.
1523.37s - 1524.65s |  And that wraps up the demo.
1524.65s - 1525.89s |  I do have one more slide.
1528.49s - 1551.84s |  Whoops, awesome.
1551.84s - 1553.96s |  All right, that one last slide.
1553.96s - 1555.12s |  Hopefully you can see just the slide,
1555.12s - 1556.32s |  not the speaking notes, cool.
1556.32s - 1560.20s |  All right, I wanna close with just a few key takeaways.
1560.20s - 1563.92s |  Now, building Kubernetes detective capability is a journey,
1563.92s - 1565.44s |  and the first step towards it
1565.44s - 1568.64s |  is to understand the threats posed to your environment.
1568.64s - 1570.96s |  Once this is done, we saw how the concepts
1570.96s - 1573.68s |  and the methods of collaborative attack simulation
1574.44s - 1575.52s |  can be applied to this world as well,
1575.52s - 1578.32s |  in order to build defenses proactively.
1578.32s - 1580.32s |  To this end, we're giving the world
1580.32s - 1582.48s |  a Kubernetes native attack simulation framework,
1582.48s - 1583.92s |  Leonidas for Kubernetes,
1583.92s - 1585.56s |  a set of test cases to get started,
1585.56s - 1587.84s |  along with their corresponding Sigma rules
1587.84s - 1590.16s |  as a building block for detections.
1590.16s - 1591.04s |  And that's all from me.
1591.04s - 1592.24s |  Thank you very much for your time.
1592.24s - 1594.72s |  If you can find the links mentioned in this QR code,
1594.72s - 1596.72s |  and you can find me on Twitter if you wanna discuss further.
1596.72s - 1598.68s |  Thanks to Adversary Village for having me.


url: https://www.youtube.com/watch?v=es72oviu0Lg
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
title:
DEF CON 32 - How I  hacked Learning Codes of the key job of a car assembled in my country - D. Erazo

content:
{
  "webpage_url": "https://www.youtube.com/watch?v=es72oviu0Lg",
  "title": "DEF CON 32 - How I  hacked Learning Codes of the key job of a car assembled in my country - D. Erazo",
  "description": "Using hardware hacking techniques, it was possible to detect the use of learning codes instead of rolling codes in a key job of a car widely used in my country. For this purpose, the key job was disassembled and the HS2240 integrated circuit was detected and, using a logic analyzer, the emission of learning codes from the integrated circuit to the radio frequency LED emitter was checked. With the use of HackRF SDR, the learning code is duplicated to be able to open the car N times without needing the original key anymore, which proves that the use of learning codes is very vulnerable, just like fixed codes.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1622,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Yo, hello.
1.52s - 3.84s |  Yo, my G's.
3.84s - 5.56s |  Welcome to my presentation.
5.56s - 7.96s |  For me, it's a pleasure to stay here.
7.96s - 10.76s |  I'm so happy to share that research.
10.76s - 13.64s |  So I'm going to show how I discovered
13.64s - 16.32s |  that I can unlock tossable cards in my country.
16.32s - 19.76s |  So the principal topic is breaking learning codes.
19.76s - 23.20s |  Please get up your hands if someone
23.20s - 28.50s |  know about learning codes, how to hack learning codes.
28.50s - 30.10s |  Two, two people.
30.10s - 31.02s |  OK.
31.10s - 39.50s |  So right now, I'm going to show who I am.
39.50s - 43.94s |  My official work is a penetration tester.
43.94s - 44.70s |  Why I say that?
44.70s - 47.90s |  Because in South America, we don't
47.90s - 51.02s |  have automatic cybersecurity companies.
51.02s - 54.78s |  So I do the research alone because I
54.78s - 56.70s |  learn card hacking alone.
56.70s - 63.66s |  So in my free time, I do hardware security research.
63.66s - 65.14s |  OK?
65.14s - 67.62s |  I create Reverse Everything, a YouTube channel
67.62s - 70.18s |  where I upload all my research.
70.18s - 74.74s |  So I am 28 years old from Ecuador.
74.74s - 77.38s |  We don't have anything about card hacking security,
77.38s - 78.54s |  nothing about that.
78.54s - 81.86s |  So I do alone.
81.86s - 83.38s |  I'm going to show about introduction
83.38s - 84.78s |  about learning codes.
84.78s - 87.02s |  After that, the hardware hacking.
87.02s - 89.14s |  After that, I'm going to learn how
89.14s - 91.82s |  to set a backdoor in the KLS entry system.
91.82s - 94.14s |  After that, collision progress that
94.14s - 96.98s |  appears if you use learning codes.
96.98s - 99.86s |  And after that, I'm going to show the Auto RAF Killer.
99.86s - 102.86s |  It's the tool that I developed to unlock cards
102.86s - 106.22s |  with fixed learning code and rolling code
106.22s - 108.82s |  using the no attacks.
108.82s - 115.02s |  So I was trying to find KANG injection.
115.02s - 120.34s |  So when I connect my OBD port to the interface OBD2,
120.34s - 124.78s |  I find the KANG ID 545 is the ID that
124.78s - 130.26s |  appears when you unlock or lock the card with the KFOB control.
130.26s - 131.06s |  OK?
131.06s - 135.62s |  So I say, hey, let's go to do the research
135.62s - 139.70s |  about the KLS entry system, the radio frequency system.
139.70s - 142.86s |  So here we have a universal radio hacker.
142.86s - 144.50s |  I record the signal.
144.50s - 147.06s |  This is the signal to unlock the card.
147.06s - 149.86s |  And after that, I proceed to demodulate the signal.
149.86s - 154.14s |  The signal is in 370 megahertz.
154.14s - 157.06s |  I demodulate with ASK modulation.
157.06s - 162.10s |  And I use a symbol per second of 500, OK?
162.14s - 166.46s |  So if you see, we have the unlock signal to,
166.46s - 168.06s |  and after that, the lock signal.
168.06s - 169.62s |  After that, unlock signal.
169.62s - 176.10s |  Again, if we see, we have the first row is a fixed code.
176.10s - 178.30s |  The second row is the same fixed code.
178.30s - 180.10s |  So I say, hey, what the hell is that?
180.10s - 181.78s |  This isn't really code, OK?
181.78s - 186.38s |  So I say, I need to do a deeper research about that.
186.38s - 191.10s |  So the unlock signal in hexadecimal format,
191.10s - 194.18s |  the previously slide is in bit format.
194.18s - 197.46s |  In hexadecimal format is that signal.
197.46s - 204.94s |  So what happen if you see that there is a fixed code that
204.94s - 206.86s |  repeat many times?
206.86s - 210.94s |  And the lock signal is very similar to the unlock signal.
210.94s - 216.14s |  So just the three last hexadecimal digits change.
216.14s - 219.26s |  OK, so I say, hey, let's go to verify the replay attack.
219.26s - 220.94s |  So this is a fixed code.
220.94s - 225.70s |  And right now, I am in the fifth floor in Abandoned Build-It.
225.70s - 227.26s |  And the car is in the first floor.
227.26s - 233.54s |  So this is the first time that I was able to unlock my car.
233.54s - 239.46s |  So let's go to listen the song when the car is unlocked.
239.46s - 252.34s |  So with Universal Radio Hacker, I send the signal.
252.34s - 256.18s |  After that, I send the signal to lock the car.
256.22s - 261.86s |  So I don't know if you listen, but from here, I listen.
261.86s - 264.26s |  So I verify with that replay attack
264.26s - 268.38s |  that my car use something like fixed code.
268.38s - 272.70s |  So I disassembled the K4, and I found a learning code chip.
272.70s - 276.14s |  The learning code chip is HS2240.
276.14s - 279.10s |  If you find that in internet, you
279.10s - 282.78s |  are going to find that this is a learning code chip.
282.78s - 284.58s |  So what the hell is learning code?
284.58s - 286.54s |  Learning code is similar to fixed code.
286.54s - 288.90s |  The difference is in the programmation mode.
288.90s - 293.10s |  In fixed code, you have the code soldered to the board
293.10s - 295.06s |  in the K4, OK?
295.06s - 298.14s |  But in learning code, you have the pin
298.14s - 299.86s |  into the integrated circuit.
299.86s - 302.82s |  So another difference is that when
302.82s - 305.38s |  you are going to program in fixed code,
305.38s - 308.26s |  you don't have to do a programmation.
308.26s - 313.02s |  In learning code, you have the teacher that uses the K4.
313.02s - 316.30s |  The learning code to the microcontroller receiver.
316.30s - 320.26s |  So when the microcontroller receiver
320.26s - 324.06s |  listen the codes to the antenna, microcontroller
324.06s - 326.18s |  save that code in his memory.
326.18s - 330.10s |  And he's able to save up to four different learning codes.
330.10s - 334.90s |  So keep it in mind, because this is useful information
334.90s - 339.82s |  to set up backdoor in a few minutes in the other slides.
339.82s - 342.42s |  So this is a learning code.
342.42s - 346.26s |  Each K4 has a different learning code, OK?
346.26s - 347.22s |  Each K4.
347.22s - 350.02s |  And each card has a different learning code.
350.02s - 353.98s |  And each K4 has a different learning code, OK?
353.98s - 355.30s |  So keep in mind.
355.30s - 358.06s |  So let's go to the hardware hacking.
358.06s - 364.26s |  If you disassemble the vulnerable K4,
364.26s - 369.50s |  we found an oscillator, LR370 megahertz batteries.
369.70s - 371.70s |  We assume two batteries.
371.70s - 373.94s |  We have 6.38 volts.
373.94s - 376.14s |  It's important to do mathematics calculation
376.14s - 379.34s |  to the brute force that I am going to do in a few slides.
379.34s - 382.50s |  After that, we identify the ASK modulation.
382.50s - 386.62s |  Remember that we have to do a modulation to set
386.62s - 389.50s |  to the LED RF transmit.
389.50s - 394.34s |  So the final signal is ascending to the LED RF transmit.
394.34s - 398.62s |  And also, we have here a multimeter to check.
398.62s - 401.26s |  So let's go to the burn the circuit.
401.26s - 403.18s |  We have four inputs.
403.18s - 407.78s |  Remember that the K4 has four buttons.
407.78s - 411.06s |  So each button is related to one.
411.06s - 414.42s |  For example, if I press one button of the four buttons,
414.42s - 416.26s |  I have 1, 0, 0, 0.
416.26s - 419.98s |  If I press the second button, I have 0, 1, 0, 0.
419.98s - 425.94s |  And each signal pass through a pull-down resistor.
425.94s - 429.06s |  So after the pull-down resistor,
429.06s - 432.34s |  enter to the integrated circuit.
432.34s - 436.70s |  So we have four entries, K0, K1, K2, K3.
436.70s - 439.22s |  And the output is through the pin number 3.
439.22s - 442.62s |  So the learning code encoded exits
442.62s - 443.90s |  through the pin number 3.
443.90s - 446.02s |  And in the left, we have the ASK modulation
446.02s - 449.54s |  with capacitors, resistors, inductors, and more.
449.54s - 453.90s |  So the final modulator learning code encoded
453.90s - 457.18s |  go out by the LED.
457.18s - 459.82s |  So keep in mind, because we have four modes.
459.82s - 463.82s |  So how the learning code is formatted is like the frame.
463.82s - 465.54s |  The frame is a preamble.
465.54s - 468.06s |  After that, we have 20-bit code.
468.06s - 470.66s |  After that, we have four bits of the mode.
470.66s - 472.94s |  Remember, each mode is a bottom.
472.94s - 476.06s |  So in 20 bits, we have one million possibility code.
476.06s - 481.18s |  So 2 to power 20 bits, we have one million possibility code.
481.18s - 484.26s |  And in mode, we have four bits.
484.26s - 487.30s |  So here we have the different modes
487.30s - 494.26s |  that are able to enter to the integrated circuit.
494.26s - 498.06s |  So the preamble, here we have the bits of the learning code.
498.06s - 500.02s |  20 bits of learning code, four bits more.
500.02s - 502.50s |  So the preambles, I get 96 bits.
502.50s - 506.22s |  So 96 subtract 20 bits of the learning code
506.22s - 507.62s |  subtracts 40 bits of the mode.
507.62s - 510.78s |  We have 72-bits preamble.
510.78s - 513.26s |  And here we have 96-bit.
513.26s - 518.34s |  But 72-bits of preamble, I don't know, sure.
518.34s - 520.86s |  So that's the reason that I do a hardware
520.86s - 523.34s |  hacking with a logic analyzer.
523.34s - 526.54s |  This is logic analyzer LA5016 that
526.54s - 530.58s |  is able to record up to 500 megahertz.
530.58s - 533.10s |  So here's the connection.
533.10s - 536.30s |  Channel 1 is to the transmit bit, the pin number 3,
536.30s - 540.66s |  ground to ground, and channel 2 into the H input system,
540.66s - 544.46s |  for example, K0, K1, K2, and K3, and a multimeter
544.46s - 550.30s |  to check the voltage pin.
550.30s - 554.54s |  So what we get when we do that, for example,
554.54s - 558.26s |  if we press the first button, the K0,
558.26s - 561.06s |  we have that signal in the transmit pin.
561.06s - 566.82s |  This is the learning code that repeats 25 times.
566.82s - 569.26s |  And after that, we have the preamble of the next signal.
569.34s - 570.86s |  So when we press the button, we have
570.86s - 573.58s |  the pulse in the channel 1.
573.58s - 576.78s |  So the duration of the pulse is the duration
576.78s - 577.86s |  that we press the button.
577.86s - 579.78s |  So if we press the button one more,
579.78s - 583.50s |  we have one more of learning codes, the same learning code.
583.50s - 584.86s |  You understand me?
584.86s - 587.26s |  And the same with K1, the same with K2,
587.26s - 589.54s |  that is the button to unlock the car.
589.54s - 592.58s |  The same with the K3, that is the button to lock the car.
592.58s - 596.10s |  So if we assume what we have, for example,
596.10s - 598.66s |  here is the learning code.
598.66s - 602.42s |  Here is the learning code, 1, 2, 3, 4, and more learning code.
602.42s - 604.42s |  If we do assume to the learning code,
604.42s - 611.82s |  we have a pulse, 0, a pulse with more duration,
611.82s - 613.26s |  and a 0 with less duration.
613.26s - 615.06s |  So I say, hey, what that means?
615.06s - 620.54s |  If I get it when I record the signal with a HAG RF,
620.54s - 623.42s |  I say I get 1, 0, 1, 0.
623.42s - 626.70s |  But how I translate that to 1, 0, 1, 0?
626.70s - 631.34s |  Because here I have a pulse that is longer than that pulse.
631.34s - 635.14s |  And here I have a 0 that is longer than that 0.
635.14s - 637.82s |  So I say, hey, this is encoded.
637.82s - 639.14s |  So this is encoded.
639.14s - 641.94s |  So after reversing the encodification,
641.94s - 644.22s |  after reading a lot of data sheets,
644.22s - 647.50s |  I achieved to discover the encoding to the learning code.
647.50s - 650.34s |  So I get a learning code with logic on the large cell.
650.34s - 656.42s |  So the integrated chip sends a 0 with four bits
656.42s - 660.46s |  and sends a 1 bit with four bits.
660.46s - 662.78s |  So for example, if the integrated code
662.78s - 667.74s |  wants to send 0, it sends 1, 0, 0, 0.
667.74s - 673.30s |  And if the integrated circuit wants to send 1 bit,
673.30s - 675.90s |  the 1 bit is sent to 1, 1, 1, 0.
675.90s - 680.78s |  So for example, here we have 1, 0, 3, 0s.
680.78s - 684.10s |  And also we have here 1, 1, 1, 0.
684.10s - 687.74s |  So here we have a 1, and here we have a 0.
687.74s - 691.78s |  So after that, the preamble is a constant.
691.78s - 697.70s |  The preamble is a constant of the 1 bit and 31 0s.
697.70s - 702.02s |  So that's the reason that when we get that signal with Logic
702.02s - 705.58s |  Analyzer, we have here the preamble 1 bit and 31 0s.
705.58s - 709.34s |  And after that here, for example, we have 0, 1, 0, 1,
709.34s - 711.14s |  1, 0, 0, and so on.
711.14s - 713.90s |  And the mode also is encoded with that codification.
713.90s - 718.10s |  We have here a 1, 0, 0, 0.
718.10s - 719.30s |  OK?
719.30s - 721.86s |  So after that, we have all the information
721.86s - 724.18s |  to encode or decode any signal.
724.18s - 725.74s |  So how I verify that?
725.74s - 727.98s |  Remember that 96 bits.
727.98s - 732.22s |  So if we multiply 20 bits by 4 bits,
732.22s - 738.42s |  and plus 4 bits by 4 bits of the mode, we have 96 bits.
738.42s - 741.88s |  So this is the reason that at the start of the presentation,
741.88s - 744.44s |  we have recorded 96 bits.
744.44s - 745.08s |  OK?
745.08s - 749.72s |  So after that, we have the preamble of the next frame,
749.72s - 751.72s |  of the next learning code.
751.72s - 752.88s |  So why do I do that?
752.88s - 756.48s |  Because I see data sheets that say
756.48s - 759.00s |  me bad information, fake information
759.00s - 761.48s |  for use for us, like hackers.
761.48s - 764.20s |  For example, there are another vulnerable radio frequency
764.20s - 764.68s |  chips.
764.68s - 768.68s |  For example, there are also the HS1527,
769.08s - 778.60s |  24, the HS2241, and more, the HTCP20D, the HTCP20B, and more.
778.60s - 781.44s |  So if you read the data sheet, the data sheet
781.44s - 785.04s |  say something like, hey, it can reduce any code collision
785.04s - 787.24s |  and authorize it code scanning possibility.
787.24s - 790.40s |  So hey, are you sure we are going to probe the opposite?
790.40s - 793.68s |  Because I discovered the encodification,
793.68s - 794.88s |  the encodification, and more.
794.92s - 799.60s |  So I built a genuine radio block that do a brute force attack.
799.60s - 805.20s |  This is the brain of the attack, is that block that I built.
805.20s - 807.40s |  And this is ASK modulation.
807.40s - 809.24s |  We have here our repeating interpolation
809.24s - 811.60s |  to better the signal.
811.60s - 813.76s |  Here we have the carrier signal.
813.76s - 816.00s |  Multiply, we have the modulated signal,
816.00s - 820.48s |  and a trouble to maintain to the symbol rate.
820.48s - 821.00s |  OK?
821.00s - 825.04s |  After that, we send that to the OSMO com scene
825.04s - 828.36s |  that is compatible with our hack LF.
828.36s - 838.12s |  OK, so let's go to see how I am able to unlock the car with
838.12s - 840.68s |  my genuine radio brute force attack.
840.68s - 843.76s |  So the car right now is locked.
843.76s - 854.23s |  I run my genuine radio script, and right now, the car
854.23s - 855.35s |  is unlocked.
855.35s - 855.91s |  So simple.
855.91s - 858.19s |  The brute force is customizable.
858.19s - 863.23s |  You can set parameters, for example,
863.23s - 866.07s |  the delay between each signal.
866.07s - 868.59s |  And after that, I created AutoRefKiller.
868.59s - 871.67s |  It's a tool that I developed to unlock whatever car that
871.67s - 874.67s |  use learning code, fixed code, or rolling code
874.71s - 876.63s |  with roll jam attacks.
876.63s - 880.79s |  So let's go to the city to unlock
880.79s - 882.19s |  hundreds of vulnerable cars.
882.19s - 885.07s |  So here we have the real gangster hacker.
885.07s - 886.75s |  This is a pet black hacker.
886.75s - 889.51s |  Don't use my pet, please.
889.51s - 900.51s |  So here, I show about how I perform in Akia Soluto.
900.51s - 906.55s |  OK, so right now, I run the brute force attacks.
906.55s - 914.55s |  I remember that the brute force attack take one minute,
914.55s - 915.39s |  I guess.
915.39s - 920.59s |  And in one minute, my script was able to unlock the car.
920.59s - 925.15s |  So OK, remember, each car has a different learning code.
925.15s - 931.27s |  And each car is able to save up to four different learning
931.27s - 932.47s |  codes.
932.47s - 936.95s |  OK, so right now, I'm going to check the car is unlocked.
936.95s - 945.91s |  And after I run my script, right now, the script is running.
957.37s - 958.61s |  And let's go to wait.
958.61s - 962.17s |  And in a few minutes, the car will be unlocked.
962.17s - 967.89s |  You know, each signal is sent through each 30 milliseconds.
967.89s - 972.81s |  But you can set that parameter to, I don't know,
972.81s - 974.05s |  60 milliseconds.
974.05s - 976.85s |  If you have more interference, you
976.85s - 980.17s |  are able to send with a more delayed.
980.17s - 986.25s |  OK, right now, we have a Kia Rio.
986.25s - 990.29s |  So it's the same attack, the same attack.
990.29s - 997.05s |  So the Kia Rio, I was able to unlock the car
997.05s - 998.73s |  with two different learning codes.
998.73s - 1003.45s |  Remember, each car had between two learning codes
1003.45s - 1006.01s |  up to four different learning codes.
1006.01s - 1014.24s |  So let's go to see quickly.
1014.24s - 1016.08s |  So we check the car is locked.
1016.08s - 1023.18s |  And after I run my script, I am able to unlock the car.
1023.18s - 1025.54s |  All right, now the car is locked.
1025.54s - 1031.22s |  OK, and final, with another Renault X, I don't know.
1031.22s - 1034.70s |  Remember, there is a possibility that you
1034.70s - 1041.14s |  go to a car keyless entry system.
1041.14s - 1047.14s |  There are a possibility that the car dealership install
1047.14s - 1050.58s |  you a vulnerable keyless entry system with learning code.
1050.62s - 1055.06s |  So I guess that in Renault, I don't see the model.
1055.06s - 1060.18s |  I guess that this is the case.
1060.18s - 1063.06s |  Also, there are vulnerable cars like Kia Picanto
1063.06s - 1066.02s |  and more cars in Ecuador.
1066.02s - 1067.22s |  So I'm from Ecuador.
1067.22s - 1073.85s |  I forget to say that, I guess.
1073.85s - 1081.08s |  So these are real attacks in the streets.
1081.08s - 1084.92s |  Right now, I unlocked the car.
1084.92s - 1087.56s |  So let's go to the next part.
1087.56s - 1090.04s |  Let's go to the setting backdoor in keyless entry system.
1090.04s - 1095.76s |  Remember that how we know that a malicious actor don't
1095.76s - 1099.16s |  send a backdoor into our keyless entry system?
1099.16s - 1100.00s |  We don't know.
1100.00s - 1106.24s |  So there are high probability because in Latin America,
1106.24s - 1109.72s |  in South America, there are something like universal case.
1109.72s - 1112.44s |  Universal case, there is a fogging
1112.44s - 1118.56s |  because uses a key fog of the malicious actor
1118.56s - 1121.40s |  set into the keyless entry system of many cars.
1121.40s - 1123.52s |  So this is where it's rolling code.
1123.52s - 1130.80s |  So 1K unlock N cars because previously, the car
1130.80s - 1134.00s |  was backdoorized.
1134.00s - 1137.16s |  OK, so let's go to backdoor inside a keyless entry system.
1137.16s - 1141.16s |  For that, we have the receiver microcontroller with STM8,
1141.16s - 1144.84s |  the horn, the voltage source to power on the circuit.
1151.15s - 1154.07s |  We don't have sound, but don't worry.
1154.07s - 1160.27s |  Right now, also, we have the hack RF, my SD device,
1160.27s - 1162.55s |  and also the auto RF killer that I
1162.55s - 1166.95s |  created to create a custom signal to create the backdoor.
1166.95s - 1172.55s |  And basically, I put in programmation mode
1172.55s - 1174.83s |  the keyless entry system.
1174.83s - 1177.63s |  We connect the ignition to the voltage
1177.63s - 1179.87s |  and press a button six times.
1179.87s - 1183.99s |  So this is how to backdoorize the keyless entry system.
1183.99s - 1185.95s |  So after the keyless entry system
1185.95s - 1189.15s |  is in learning code programmation mode,
1189.15s - 1194.07s |  I send whatever signal, whatever signal.
1194.07s - 1199.07s |  For example, I put, for example, 1001001 or 001,
1199.75s - 1202.59s |  or 00000001.
1202.59s - 1204.59s |  So this is the backdoor code.
1204.59s - 1208.35s |  So right now, I use my tool.
1208.35s - 1211.19s |  I put the backdoor code right now.
1211.19s - 1222.07s |  And after that, the receiver will save that in his memory.
1222.07s - 1226.23s |  So right now, I connect ignition to the voltage
1226.23s - 1228.31s |  to put in programmation mode.
1228.31s - 1230.79s |  They are sounds.
1230.79s - 1236.15s |  And after that, I send the backdoor code.
1236.15s - 1240.15s |  And finally, I exit the programmation mode.
1240.15s - 1245.55s |  And after that, I am able to unlock the car
1245.55s - 1248.07s |  with my backdoor code, OK?
1248.07s - 1251.99s |  So basically, I am able to unlock
1251.99s - 1268.45s |  that car with my hack RF.
1268.45s - 1271.33s |  So right now, I'm going to send the signal.
1271.37s - 1276.41s |  I am going to unlock the system with the hack RF.
1276.41s - 1280.09s |  So let's go to send the signal with the hack RF.
1282.81s - 1284.37s |  I lock the system.
1284.37s - 1285.73s |  Lock the system.
1285.73s - 1291.05s |  And if you listen, I know that you don't listen right now,
1291.05s - 1293.17s |  but trust me.
1293.17s - 1297.45s |  The system sounds, so the system is unlocked with the backdoor.
1297.45s - 1299.05s |  OK.
1299.05s - 1301.89s |  There are also a collision problem.
1301.89s - 1303.97s |  What means the collision problem?
1303.97s - 1306.93s |  The most integrated chip learning code
1306.93s - 1310.45s |  use the same two to power 20 bits.
1310.45s - 1314.49s |  So the most integrated circuit chips learning code
1314.49s - 1316.21s |  have one million possibility code.
1316.21s - 1323.09s |  So what I mean, for example, if we take the AB1527 chip,
1323.09s - 1326.33s |  there are high probability that that chip have the same learning
1326.33s - 1329.49s |  code that have another chip that use the same range.
1329.49s - 1334.73s |  For example, the HS2240, HS2241, and more.
1334.73s - 1335.65s |  Why I say that?
1335.65s - 1337.65s |  Because just in my country alone,
1337.65s - 1341.53s |  there are tons of cars that use that KLS entry system,
1341.53s - 1343.37s |  vulnerable KLS entry system.
1343.37s - 1348.05s |  So if we join all the cars in one place,
1348.05s - 1350.49s |  all of the cars of the world in one place
1350.49s - 1352.69s |  that use the learning codes, there
1352.69s - 1356.37s |  are high probability that if I take a random KFOB
1356.37s - 1359.25s |  and press the button, there are another cars
1359.25s - 1362.61s |  that will unlock or lock.
1362.61s - 1363.61s |  And why I say that?
1363.61s - 1369.53s |  Because there will come a time where the million codes will
1369.53s - 1373.01s |  be filed all over the world and will be a collision,
1373.01s - 1377.29s |  and no one will figure it out.
1377.29s - 1384.77s |  Or maybe this firewall has already been reached.
1384.77s - 1388.57s |  So that question, I put you in your mind.
1388.57s - 1392.29s |  So for example, my KFOB code unlock my car,
1392.29s - 1395.21s |  or I unlock a garage door in United States
1395.21s - 1399.01s |  because that learning codes also are
1399.01s - 1404.05s |  using in garage door and radio frequency devices protection.
1404.05s - 1407.29s |  So finally, I'm going to exploit everything.
1407.29s - 1415.25s |  This is a tool with 1,300 Python lines code.
1415.25s - 1417.49s |  So the first feature is to brute force learning codes
1417.49s - 1418.61s |  with our database.
1418.61s - 1421.57s |  I created a database that have all codification
1421.57s - 1424.77s |  of the integrated learning code chips.
1424.77s - 1428.73s |  So also, you can discover in backdoor codes in your car
1428.73s - 1430.29s |  running that brute force attack.
1430.29s - 1433.21s |  So for example, if you run and your car
1433.21s - 1435.61s |  was unlocked by another learning code,
1435.61s - 1438.73s |  your car is backdoorized.
1438.73s - 1440.57s |  Another is the brute force attack
1440.57s - 1441.69s |  with arbitrary parameters.
1441.69s - 1447.45s |  For example, if you want to run your chip
1447.45s - 1452.73s |  with custom parameters, you also are able to run that.
1452.73s - 1456.13s |  You also create a backdoor custom code or signal.
1456.13s - 1461.61s |  And also, you are able to perform a replay attack.
1461.61s - 1465.13s |  And finally, a roll jam attack.
1465.13s - 1469.41s |  To do that, you need two SDR device
1469.41s - 1471.85s |  to unlock cars with rolling code.
1471.85s - 1479.81s |  So finally, let's go to see the tool.
1479.81s - 1483.81s |  So I entered the integrated chip name.
1483.81s - 1487.05s |  So the program sent me the information
1487.05s - 1488.61s |  about that integrated chip.
1488.61s - 1492.45s |  So we don't have anything more than put the radio frequency,
1493.21s - 1496.05s |  for example, in this case, 350.
1496.05s - 1497.93s |  And the brute force attack is performing.
1497.93s - 1502.25s |  So we need to wait on nothing more.
1502.25s - 1512.92s |  Also here, we execute a perform brute force attack
1512.92s - 1516.00s |  with 22 bits, not just 20 bits.
1516.00s - 1521.28s |  So you can set whatever number of bits.
1521.28s - 1525.48s |  You enter the start number to brute force attack
1525.48s - 1528.12s |  and the end number to finish the brute force attack,
1528.12s - 1530.24s |  the delays, and more.
1530.24s - 1536.56s |  And after that, I execute the option number four
1536.56s - 1538.24s |  to send a jamming signal.
1538.24s - 1543.52s |  So you also can use that tool to create jamming signals
1543.52s - 1544.88s |  in whatever frequency.
1544.88s - 1548.64s |  And you set the duration of the jamming.
1549.64s - 1560.99s |  And finally, also, we can choose the option number three
1560.99s - 1564.59s |  to record and replay a radio frequency signal to discover
1564.59s - 1569.23s |  your car is vulnerable to fixed code or learning codes.
1569.23s - 1571.91s |  So you set the frequency.
1571.91s - 1576.71s |  You need my script and also the hack RF and nothing more.
1576.71s - 1580.91s |  So you record in 10 seconds the signal.
1580.91s - 1584.79s |  And immediately, in 10 seconds, your signal is replied again.
1594.16s - 1596.76s |  And finally, set a backdoor into the KLS entry system.
1596.76s - 1598.20s |  You set the frequency.
1598.20s - 1602.80s |  And you put the bits, for example, 110, whatever.
1602.80s - 1607.12s |  So the script create the modulation, do everything.
1607.12s - 1613.52s |  So you just need to put the bits and nothing more.
1613.52s - 1614.96s |  So thank you so much.
1614.96s - 1619.90s |  This was breaking learning codes in my country.
1619.90s - 1621.82s |  Thank you so much.


url: https://www.youtube.com/watch?v=J7GFF-GVOpA
title: DEF CON 32 - Doors, Cameras, & Mantraps Oh my! - The Magician
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=J7GFF-GVOpA",
  "title": "DEF CON 32 - Doors, Cameras, & Mantraps Oh my!  - The Magician",
  "description": "This is an entry level talk about the practical parts of Physical Security Assessment, and how to talk to clients.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1059,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 So it turns out that the slides are not going to be up here,
3.52s - 6.80s |  but what I'm going to do is record my talk later
6.80s - 9.04s |  and put it up on YouTube and share it on Twitter,
9.04s - 12.12s |  so you all will get to see the slides.
12.12s - 14.64s |  I'll probably just share the slides, that would be cool.
14.64s - 18.84s |  All right, so my name is The Magician.
18.84s - 21.52s |  This talk is Doors, Cameras, and Mantraps, Oh My!
21.52s - 23.20s |  It is not a lockpicking talk,
23.20s - 24.64s |  if that's what you're here for.
24.64s - 28.20s |  This is a talk more about physical security
28.24s - 31.52s |  and the practical business aspects of security
31.52s - 34.68s |  in the PhysSec world and how to talk to clients
34.68s - 35.88s |  and how you want to get into it,
35.88s - 37.88s |  if that's something you're interested in.
39.44s - 46.54s |  So, hi, nice to meet you all.
46.54s - 53.36s |  I've got my notes here, even though you don't have slides.
53.36s - 55.60s |  I'm a member of the Open Organization of Lockpickers.
55.60s - 59.08s |  If you all have gone and picked locks at Lockpick Village,
59.08s - 61.76s |  then that's the tool group, those are my people.
61.76s - 63.36s |  Let them know The Magician sent you
63.36s - 66.88s |  and they'll set you up with some locks and some picks.
66.88s - 69.76s |  I was a physical security assessor
69.76s - 72.04s |  for Gold Sky Cybersecurity,
72.04s - 74.16s |  and they used to send me around the United States
74.16s - 76.44s |  and break into buildings, and I would show people
76.44s - 79.24s |  how I would break into their buildings with them,
79.24s - 81.36s |  so they could try it, learn it,
81.36s - 83.32s |  and the mitigation rate was much higher
83.32s - 88.24s |  because then they understood how to do the physical exploit.
90.12s - 93.20s |  Physical security still is a huge hobby for me,
94.04s - 96.68s |  even though I'm not doing it professionally anymore.
96.68s - 98.72s |  What I did was super straightforward.
98.72s - 100.56s |  I would bring people around the building
100.56s - 103.00s |  that they worked in, and I would teach them
103.00s - 105.40s |  how to break into their own facility.
105.40s - 108.36s |  Bringing the client with me gave them the option
108.36s - 112.20s |  to try it themselves, and often the mitigation rate
112.20s - 113.12s |  was much higher.
115.96s - 119.68s |  Show and tell is basically what it came down to.
119.68s - 123.12s |  I would show people what their vulnerabilities were,
124.04s - 125.52s |  explain to them how to run the exploit
125.52s - 127.28s |  so they could try it themselves,
127.28s - 130.28s |  and then I would tell the people that had hired me
130.28s - 133.20s |  what the problems were, what I showed their team,
133.20s - 137.73s |  and how to get those things fixed.
137.73s - 141.53s |  What this talk will cover is physical security controls,
141.53s - 144.49s |  key questions that I use to ask clients,
144.49s - 146.65s |  how to educate your clients without fear,
146.65s - 148.53s |  uncertainty, and doubt,
148.53s - 151.09s |  and how you can learn physical security
151.09s - 162.10s |  if you want to get into it as a career field.
162.10s - 164.86s |  Physical security controls are the first topic
164.86s - 167.78s |  of conversation, and I'd like to start with doors.
167.78s - 169.54s |  More often than not, that's the first thing
169.54s - 170.70s |  you're going to test.
174.42s - 177.62s |  There are a lot of mechanical components to doors,
177.62s - 179.54s |  but here's the short list.
179.54s - 181.62s |  Do perimeter doors have hinges
181.62s - 183.66s |  that are exposed to the outside?
183.66s - 185.90s |  Those hinges can be exploited.
185.90s - 187.78s |  Can I slide something between the latch
187.78s - 191.10s |  and the strike plate to pull the door open
191.10s - 193.18s |  without a key or combination?
194.06s - 196.18s |  Can I get tools over or under the door
196.18s - 199.02s |  to manipulate the door handles from the outside?
199.02s - 201.66s |  If I can run across double doors,
201.66s - 203.26s |  can I manipulate crash bars,
203.26s - 206.78s |  which are the bars that you shove open in server rooms?
206.78s - 214.75s |  These are all resolvable exploits.
214.75s - 217.11s |  Windows are the next physical security control
217.11s - 219.51s |  I used to look at, and they're often overlooked.
220.51s - 225.23s |  Insecure windows can be opened or manipulated
225.23s - 227.23s |  in similar ways to doors.
227.23s - 229.35s |  They offer different challenges.
229.35s - 230.95s |  In a lot of office spaces,
230.95s - 235.27s |  some clients don't have policies about shoulder surfing
235.27s - 237.75s |  or looking over the shoulder of a user
237.75s - 239.43s |  to obtain information.
240.47s - 245.47s |  This is a low-complexity physical security risk,
245.75s - 248.55s |  and if someone is trying to establish
248.55s - 250.71s |  operating hours of a business,
250.71s - 252.95s |  PC operating systems used,
252.95s - 254.95s |  or even information like browser type,
255.63s - 256.47s |  looking through a window
256.47s - 261.38s |  is extremely low effort and high yield.
261.38s - 264.46s |  Fencing seems obvious at first.
264.46s - 267.82s |  Maybe folks have them in their homes or at office sites.
267.82s - 270.82s |  Fencing establishes a clear perimeter
270.82s - 273.98s |  and clearly sets an expectation of limited access.
274.82s - 276.62s |  It would take a heck of an improviser
276.62s - 278.30s |  to explain to a guard
278.30s - 281.34s |  why you were walking around a parking lot or building
281.34s - 283.66s |  at a locked and closed site.
283.66s - 286.18s |  It's also near impossible to scale a fence
286.18s - 288.22s |  in most environments during the day
288.22s - 289.86s |  without attracting attention.
290.78s - 293.66s |  Fencing is a passive security means,
293.66s - 303.74s |  meaning it doesn't require any labor.
303.74s - 306.30s |  Bollards are a great security control.
307.54s - 309.54s |  You've all seen bollards before.
309.54s - 311.06s |  They're reinforced obstacles
311.06s - 314.02s |  that prevent the use of a vehicle as a battering ram
314.02s - 315.42s |  to create a point of entry
315.42s - 318.14s |  in an otherwise defended structure.
319.02s - 325.08s |  It's another passive security risk mitigation.
325.12s - 328.76s |  Mantraps, I think, are completely underutilized.
328.76s - 332.16s |  You likely have seen these secure facilities
332.16s - 335.12s |  where a room has two separate doors
335.12s - 338.36s |  and typically two separate security access controls.
339.24s - 342.12s |  For instance, one door has an RFID badge
342.12s - 343.48s |  and a separate security door
343.48s - 345.56s |  on the opposite side of the room
345.56s - 347.96s |  has a biometric security control,
347.96s - 349.24s |  like a fingerprint reader.
350.08s - 351.48s |  These require some setup
351.48s - 354.36s |  and require adherence to procedure.
354.36s - 355.80s |  Additionally, it can be a challenge
355.80s - 358.80s |  to get a flow of people through mantraps,
358.80s - 361.00s |  but they are an awesome control
361.00s - 365.39s |  and typically you'll see them at banks.
365.39s - 370.39s |  Cameras are in most businesses and some homes now.
372.35s - 374.83s |  If you have the funding at a job site,
374.83s - 377.35s |  you can even have your camera actively monitored
377.35s - 379.03s |  in a security operating center.
380.31s - 384.79s |  Lots of small to midsize businesses just record video
384.79s - 386.99s |  and reference it in incident response
386.99s - 391.03s |  if something goes wrong or for forensic purposes.
391.03s - 393.83s |  There are many technologies in the world of cameras,
393.83s - 396.31s |  but I firmly believe that Wi-Fi cameras
396.31s - 399.83s |  are a poor choice in many environments.
399.83s - 401.59s |  Please reach out to me
401.59s - 403.43s |  if you wanna hear that soapbox rant.
405.11s - 407.19s |  Electronic access is a really cool area
407.19s - 408.91s |  of security controls,
408.91s - 412.03s |  especially in the world where now everyone has a Flipper Zero.
413.03s - 416.11s |  Most of you have some form of token
416.11s - 418.79s |  that your office has given you to get into your building,
418.79s - 422.31s |  an RFID badge you wave in front of a reader
422.31s - 424.19s |  that opens the door maybe.
424.19s - 429.19s |  RFID and NFC are great and they're getting better,
431.59s - 433.63s |  but the availability of the Flipper Zero
433.63s - 435.83s |  makes these not necessarily the best way
435.83s - 439.39s |  to get into a building as an only means of access.
439.39s - 441.47s |  A pin code might be functional,
441.91s - 443.39s |  but if somebody can obtain that
443.39s - 445.91s |  by observing you entering the pin code,
445.91s - 449.51s |  that isn't necessarily a great means of access either.
449.51s - 451.99s |  I'm one of the many cyborgs in the hacker community
451.99s - 454.67s |  and I got an implant from Dangerous Things,
454.67s - 458.23s |  so my left hand is RFID and NFC compatible,
458.23s - 460.11s |  so I don't need a right to a badge,
460.11s - 465.10s |  I can write to my hand.
465.10s - 466.22s |  What matters though?
467.74s - 470.50s |  Knowing what matters to a particular entity
470.50s - 472.46s |  is of extreme importance.
472.46s - 475.30s |  I've done four minute break-ins
475.30s - 477.58s |  from parking lot to server room
477.58s - 479.46s |  and had clients tell me that
479.46s - 482.06s |  actually all of their information is in the cloud,
482.06s - 483.98s |  those servers are just dev environments
483.98s - 487.30s |  and the hard drives are encrypted, so they don't care.
487.30s - 489.58s |  So knowing what is important to your clients
489.58s - 494.12s |  is of critical importance.
494.12s - 495.76s |  Access from the perimeter is something
495.76s - 498.04s |  you actually want to talk to your client about,
498.04s - 500.36s |  not just exploring it yourself.
500.36s - 502.36s |  You wanna make sure that you're getting access
502.36s - 505.44s |  to all the doors that they want you to have access to.
505.44s - 507.32s |  There isn't any shame in saying,
507.32s - 510.52s |  can you please show me your physical infrastructure
510.52s - 514.36s |  and where all the doors are that are of a concern to you?
514.36s - 516.40s |  Then you can be sure that you're tackling
516.40s - 518.00s |  all that client's concerns.
518.92s - 520.92s |  Conversely, there might be doors
520.92s - 522.64s |  that they don't think are a concern
522.64s - 527.35s |  that you probably should bring to their attention.
527.35s - 529.59s |  Because you are truly treated as a guest
529.59s - 532.67s |  in the scenario of a security risk assessor,
532.67s - 536.11s |  you can test guest badge policies firsthand.
536.11s - 539.15s |  In some cases, if it's in scope,
539.15s - 543.63s |  you can try enticing the client to give you a guest badge
543.63s - 548.19s |  and asking them if it's okay for you to go to the restroom.
548.19s - 551.47s |  Many times you can find yourself in the office of a CEO
551.47s - 554.71s |  or a CFO without any kind of supervision,
554.71s - 557.11s |  sometimes hours after you were let in,
557.11s - 561.13s |  without anyone hassling you.
561.13s - 563.17s |  As a social engineering enthusiast,
563.17s - 564.93s |  this is a huge topic.
566.25s - 568.45s |  Entire companies are dedicated
568.45s - 571.33s |  to just educating and empowering employees
571.33s - 575.17s |  to ask as part of the security team for a company.
575.17s - 576.73s |  There are quick points,
576.73s - 578.97s |  here are some quick points to the matter.
578.97s - 581.41s |  Gamify your security training.
581.41s - 584.69s |  A traveling trophy can go to the desk of a person
584.69s - 587.85s |  with the least clicks in an email phish,
587.85s - 590.41s |  or maybe to someone who always locks their computer
590.41s - 592.77s |  when they get up to go to the break room.
593.37s - 595.01s |  Be creative and let employees know
595.01s - 597.33s |  that they are an integral part to your security
597.33s - 598.65s |  at the company,
598.65s - 601.05s |  and that they can be a huge line of defense.
601.05s - 605.44s |  Every employee is part of the security team.
605.44s - 608.04s |  Constructive criticism is always better
608.04s - 609.60s |  than belittling somebody
609.60s - 611.92s |  for their lack of security knowledge.
611.92s - 613.84s |  How can you talk to a client?
613.84s - 615.64s |  How you talk to a client will determine
615.64s - 617.92s |  how they mitigate your findings.
617.92s - 620.28s |  While there have been tons of technical talks
620.28s - 623.60s |  about how to exploit mechanical components
623.60s - 625.16s |  of physical security,
625.16s - 627.80s |  there have been just a few that cover the specifics
627.80s - 629.20s |  of educating clients
629.20s - 631.44s |  on how to go about resolving their exploits.
633.24s - 635.04s |  Saying things like this is really bad,
635.04s - 636.68s |  need to be replaced with,
636.68s - 638.68s |  we have some really good opportunities here
638.68s - 640.24s |  for positive change.
640.24s - 642.80s |  Simple phrasing can mean a world of difference
642.80s - 647.80s |  and can lead to a very different side of client morale,
648.12s - 650.56s |  and also can determine whether or not
650.56s - 655.72s |  they're going to hire you next year.
656.72s - 658.72s |  The show and tell was always my favorite part,
658.72s - 661.48s |  the demonstrations and solutions.
661.48s - 664.28s |  Showing the defenders vulnerabilities on site
664.28s - 665.76s |  is immensely fun
665.76s - 668.00s |  and can have an extremely positive impact.
668.96s - 673.96s |  Talking somebody through how you can bypass a door
675.44s - 677.88s |  versus showing them how to do it
677.88s - 680.32s |  have huge differences in the likelihood
680.32s - 684.72s |  that an issue will be mitigated or a solution implemented.
684.76s - 688.84s |  These steps in the process
688.84s - 691.48s |  also get the most heads popping into the room.
692.44s - 693.68s |  People get really excited
693.68s - 696.48s |  when you show them how to do an under door slip
696.48s - 701.48s |  or use an under door tool or a latch slit.
704.96s - 707.04s |  Avoid fear, uncertainty and doubt.
707.04s - 711.20s |  This one's probably the most critical in my opinion.
711.20s - 714.64s |  You wanna avoid letting people know that things are bad.
714.64s - 715.96s |  You wanna make sure that
716.60s - 718.08s |  even if something is really bad,
718.08s - 721.88s |  good news, I'm here, I found this thing,
721.88s - 723.60s |  now we can tackle it together
723.60s - 725.28s |  and it won't be a problem anymore.
728.38s - 729.62s |  How to educate clients
729.62s - 732.54s |  and provide a means for clients to contact you.
732.54s - 735.14s |  You wanna make sure that after you've done your test
735.14s - 737.18s |  and you've written your report,
737.18s - 738.82s |  you wanna provide contacts
739.66s - 743.38s |  that are officially your work contacts
743.38s - 745.14s |  for people to reach out to you
745.14s - 746.86s |  and ask you follow up questions.
746.90s - 749.70s |  They're going to happen, nobody knows everything
749.70s - 751.54s |  and even professionals might forget
751.54s - 753.50s |  to provide some key information.
753.50s - 757.42s |  Giving them a company email or a company phone number
757.42s - 758.90s |  and requesting that they reach out to you
758.90s - 761.78s |  during company time is really important
761.78s - 763.10s |  because then they can reach out
763.10s - 766.30s |  if they have some sort of immediate concern
766.30s - 770.22s |  or just if they want you to return later.
770.22s - 772.34s |  That point of contact is pretty critical.
773.98s - 776.66s |  Now, this is something that might be important
777.46s - 780.22s |  to all of you, how can you get into physical security?
780.22s - 782.90s |  I'm gonna talk about some podcasts, YouTube channels
782.90s - 785.38s |  and Udemy access options
785.38s - 787.26s |  for you to get into physical security.
788.30s - 791.26s |  And I'm old, so I'm gonna hold this very close to my face.
792.90s - 795.42s |  I feel education is the most important aspect
795.42s - 796.90s |  in hacking and security.
796.90s - 798.54s |  That's not to say that a four-year degree
798.54s - 801.06s |  or anything like that is necessary.
801.06s - 803.58s |  The different approaches to learning are varied
803.58s - 806.54s |  and there are a few podcasts, YouTube and Udemy
807.42s - 809.38s |  that were big wins for me personally.
809.38s - 811.26s |  If you want to get into lockpicking
811.26s - 814.74s |  or just see some jaw-dropping feats of lock exploits,
814.74s - 817.22s |  then look no further than Lockpicking Lawyer.
817.22s - 820.58s |  The content of his channel is consistently enjoyable
820.58s - 822.54s |  and never stale or boring.
822.54s - 826.18s |  If you are an auditory learner, then podcasts are fantastic.
826.18s - 829.34s |  Darknet Diaries is amazing with great storytelling
829.34s - 832.42s |  and incredible guests and lessons learned are valuable
832.42s - 835.18s |  and always come in an entertaining package.
835.18s - 838.22s |  If you want direct attention towards certification,
838.22s - 840.74s |  I think Mike Myers does a great job on Udemy
840.74s - 844.18s |  and anything and everything by the Exam Cram Book Company
844.18s - 848.18s |  I think is fantastic.
848.18s - 851.50s |  Simply learning how to do physical security from books
851.50s - 854.30s |  isn't necessarily for everybody, but it worked for me
854.30s - 857.98s |  because I could revisit individual concepts very quickly.
857.98s - 859.66s |  Dale Carnegie has a book called
859.66s - 862.18s |  How to Win Friends and Influence People
862.18s - 864.98s |  if you wanna do physical on-site pen testing
865.02s - 867.86s |  where you're not going to be announcing your presence.
867.86s - 870.42s |  Practical Lockpicking by Deviant Olaf
870.42s - 872.50s |  is a fantastic technical read
872.50s - 874.90s |  on physical security and lockpicking.
874.90s - 877.42s |  The Art of Deception by Kevin Mitnick.
877.42s - 881.18s |  It's a little flourishy, but the content is really good.
882.42s - 884.78s |  What Everybody is Saying by Joe Navarro
884.78s - 886.82s |  will help you with body language.
886.82s - 889.26s |  And again, I just wanna call out Exam Cram.
889.26s - 892.86s |  They're really good and they give you extra tests
892.86s - 900.32s |  and they give you flashcards.
900.32s - 901.72s |  You got the slides?
901.72s - 903.00s |  Just in time, Ian.
904.36s - 907.04s |  So these are three people who helped me a lot
907.04s - 908.80s |  as I was getting started.
908.80s - 911.52s |  If you find somebody on YouTube or at a con
911.52s - 913.72s |  that speaks to you personally,
913.72s - 915.76s |  the language they're using sounds good,
915.76s - 918.40s |  the ethos sound good, you just vibe with it,
918.40s - 920.52s |  reach out to them, send them an email,
920.52s - 922.72s |  throw them some information on Twitter.
922.72s - 923.56s |  I brought cards.
923.56s - 925.20s |  If what I'm saying sounds interesting,
925.24s - 927.52s |  please walk up to me and I will give you some.
928.68s - 931.76s |  Deviant, Ian, and Jason helped me a ton.
931.76s - 932.64s |  He's right here.
932.64s - 933.96s |  Wave at him, embarrass him.
935.96s - 938.28s |  Definitely reach out to the people
938.28s - 939.76s |  that you find interesting.
939.76s - 942.96s |  We as hackers enjoy telling stories.
942.96s - 946.40s |  So we're not going to be annoyed by you, I promise.
949.82s - 951.78s |  Take Guided Courses.
951.78s - 954.78s |  Taking guided courses are expensive,
954.78s - 956.38s |  but being able to raise your hand
956.78s - 958.82s |  and say, I don't understand the thing
958.82s - 961.42s |  is a really, really, really big deal.
961.42s - 964.22s |  And being right in front of the person
964.22s - 966.30s |  or on the other end of a video call
966.30s - 971.38s |  makes that exchange very quick and very efficient.
971.38s - 973.18s |  Attend local meetings.
973.18s - 975.90s |  If you've got a DEF CON group meet up near you,
975.90s - 977.98s |  please go, please meet people.
977.98s - 979.46s |  It might be the opportunity
979.46s - 981.58s |  that you need to get the job that you want
981.58s - 983.90s |  or just give you the person that you need to talk to
983.90s - 986.46s |  to learn how to do the thing that you're trying to do.
986.54s - 991.53s |  Um, oh no, laptop.
992.45s - 995.85s |  Okay, how to learn physical security.
995.85s - 998.81s |  Other than just taking courses, reading books,
998.81s - 1000.41s |  go to a local tool meetup
1000.41s - 1004.17s |  or go to LPV right here at DEF CON.
1004.17s - 1006.25s |  Try to pick locks, have fun.
1006.25s - 1008.69s |  No one's going to judge you if you don't know how to.
1008.69s - 1010.57s |  Those are the best people.
1010.57s - 1012.57s |  And we'll be able to give you
1012.57s - 1014.77s |  the proper techniques off the bat.
1014.77s - 1017.41s |  So you don't have to worry about spending hours
1017.41s - 1019.13s |  or days doing it the wrong way.
1020.57s - 1022.21s |  I just want to say a special thanks
1022.21s - 1023.97s |  to my friends and family,
1023.97s - 1026.33s |  all the Orlando hackers that have helped me out.
1026.33s - 1027.17s |  Hi.
1028.57s - 1029.57s |  Thank you all.
1029.57s - 1030.65s |  Hack all the things.
1030.65s - 1033.57s |  If you have any questions, please talk to me.
1033.57s - 1035.05s |  Here's me.
1035.05s - 1036.93s |  There's my email address,
1036.93s - 1039.53s |  my Twitter and my LinkedIn.
1039.53s - 1040.61s |  Take a picture.
1040.61s - 1041.77s |  I don't mind pictures.
1041.77s - 1043.73s |  I can't see all of you because of the lights,
1043.73s - 1045.85s |  but hi everybody, hi.
1047.41s - 1049.05s |  Please reach out to me if you have questions
1049.05s - 1051.21s |  about physical security or breaking into buildings
1051.21s - 1053.09s |  or you just want some stories.
1053.09s - 1054.13s |  I'm the magician.
1054.13s - 1057.62s |  I hope you have a fun time at DEF CON.


url: https://www.youtube.com/watch?v=MS582wba46E
title: DEF CON 32 - Exploiting Bluetooth from your car to the bank account$$ - Yso & Martin Strohmeier
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
content:
{
  "webpage_url": "https://www.youtube.com/watch?v=MS582wba46E",
  "title": "DEF CON 32  - Exploiting Bluetooth from your car to the bank account$$ - Yso & Martin Strohmeier",
  "description": "Over the past decade, infotainment systems experienced a growth in functionality, broader adoption and central incorporation into the vehicle architecture. Due to the ever-growing role of wireless protocols such as Bluetooth and a known lack of patches alongside the difficulty of patch installation, this poses a new attack surface and a genuine threat to the users. At the same time, the tools and methodologies required for testing are scattered across the Internet, absent and need a rigorous setup.\n\nIn this talk, we share a comprehensive framework BlueToolkit to test and replay Bluetooth Classic vulnerabilities. We provide practical information and tips. Additionally, we release new exploits and a privilege escalation attack vector.\n\nWe show how we used the toolkit to find 64 new vulnerabilities in 22 modern cars and the Garmin Flight Stream flight management system used in several aircraft types.\n\nOur work equips Bluetooth hackers with necessary information on novel implementation-specific vulnerabilities that could be used to steal information from target cars, establish MitM position or escalate privileges to hijack victims\u2019 accounts stealthily.\n\nWe believe our research will be beneficial in finding new vulnerabilities and making Bluetooth research more accessible and reproducible.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1226,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 All right
1.51s - 3.83s |  We'll start sorry for the delay
4.31s - 9.75s |  the main reason being that this work was mostly done by my students and
10.15s - 12.95s |  He couldn't get a visa for the u.s.. So he's not here
13.71s - 15.71s |  We did record a video
16.03s - 19.63s |  We also had a longer version of this whole thing yesterday on main stage
20.67s - 26.07s |  So you can still find this at some point online if you're interested in all of the details
26.51s - 28.51s |  However, since the audio is not working
28.99s - 31.23s |  For the video you will have to do with me
31.23s - 37.71s |  So I'm I can't provide you with all the technical details, but I should be able to to get you through it
37.71s - 39.71s |  And if you have any specific
40.31s - 42.19s |  questions on
42.19s - 49.83s |  Yeah attacks and the toolkit we built and everything I can direct you to my students. So yeah, let's start
51.11s - 53.11s |  It's fine
54.87s - 58.07s |  Who are we so first is that's my students
58.63s - 62.87s |  Vladislav also known as ESO. He's a bug bounty hunter
63.03s - 68.87s |  he did his master in cyber security at ETH Zurich where he came to us and
69.43s - 77.03s |  Asked hey, what could we what cool systems? Could we hack? What do you have for us and ideas for a master thesis?
78.07s - 83.23s |  I said, okay here. My background is all sorts of bug bounty stuff. I
84.23s - 90.75s |  Has super cool skills really the wizard behind all this stuff and he's looking for new opportunities
90.75s - 94.11s |  So if you're convinced by the stuff he built contact him
95.63s - 97.47s |  Who are we who am I
97.47s - 102.11s |  My name is Martin. I'm a security research and a scientist at a Swiss cyber defense campus
102.59s - 105.07s |  the cyber defense campus is the
105.59s - 108.39s |  Procurement arm or part of the procurement arm of the Swiss
109.07s - 112.39s |  Department of Defense I've done a lot of systems work
112.99s - 114.99s |  hacking mostly
115.43s - 117.03s |  transportation systems
117.03s - 120.75s |  Aviation you find a lot of stuff from us in the aerospace village here
121.51s - 124.71s |  We've done space cars trains everything. Basically
125.31s - 132.31s |  I've never looked at Bluetooth before neither had blood but I've done some stuff in cars. For example hacking
132.87s - 136.91s |  Electric charging systems so you can find that under broken wire that fail
139.48s - 142.60s |  So, what's the motivation for this research, why are we doing this?
143.36s - 146.52s |  well, if you're in the procurement arm of
147.20s - 149.80s |  Federal government you buy a lot of stuff
151.04s - 157.36s |  broadly, you can break this up and the pretender stage and in the actual tender where you buy stuff and a post tender stage and
160.12s - 164.92s |  Basically when you do security testing pen testing only after you buy stuff
165.20s - 169.16s |  It's generally too late like there you have these systems you have deployed them
169.76s - 177.48s |  They're insecure that that's very late. So we might still do this and we have a lot of systems where we don't have
177.88s - 179.56s |  these
179.56s - 183.80s |  Processes in place all the systems, but in general we try to be as early as possible
186.08s - 188.80s |  The idea obviously buys a lot of IT systems
188.80s - 192.08s |  but also other systems such as cars which we will get into and
192.60s - 198.40s |  Because we buy a lot of things we have a decent negotiation leverage with the manufacturers
198.40s - 204.60s |  I mean they want to sell us stuff. So they should follow some requirements that we put in tenders
207.28s - 213.52s |  One of the thing we also do is do vulnerability research on standards on systems we've done this a lot on
214.28s - 220.24s |  Aviation and in space, but the problem is if your systems have very long life cycles, even if you can demonstrate
221.08s - 223.64s |  flaws and protocols and standards and
224.44s - 227.52s |  Show that it's unsafe unsecure
228.20s - 233.70s |  Until something is changed and deployed in the long run. It will take up to decades
233.70s - 238.40s |  So that doesn't help us even in our procurement system because there are
238.92s - 242.16s |  Everyone is using the same standards and we don't have any alternatives
243.40s - 245.96s |  This brings me to today's concrete case study
246.96s - 253.76s |  Vehicles and the army and Bluetooth. So we apparently all already heard some Bluetooth insecurities in the previous talk, which is nice
255.92s - 261.64s |  But we are not talking about Bluetooth low-energy we're only talking about standard classic Bluetooth as
262.56s - 264.56s |  alluded DoD buys a lot of stuff
265.12s - 268.84s |  That's probably the first thing you think of when you think of Department of Defense
270.36s - 275.72s |  Luckily these don't have Bluetooth as far as I know most at least the ones I've looked at
276.00s - 278.98s |  But probably that that comes very soon
280.48s - 285.52s |  Boringly, however, we buy mostly box standard run-of-the-mill cars a lot of them and
286.28s - 290.56s |  These all have Bluetooth. You can't really buy a modern car without it
290.56s - 293.88s |  Even if you want it, even if you put that in a tender
294.56s - 300.84s |  You basically nobody would sell you a car or offer you to sell the car without Bluetooth
301.84s - 308.40s |  That brings me to the scope of the present research cars are fairly complex systems so Bluetooth not the only interface
309.16s - 315.40s |  We counted at least 19 interfaces and in those cars from wired or ODB ports
315.72s - 321.92s |  to the key fob if there's an issue with any of them traditionally the only way for the manufacturer to do anything is
322.88s - 326.08s |  to do a recall that's very expensive and
326.92s - 330.20s |  Pretty much only done for really a safety
330.84s - 332.84s |  big safety problems
333.64s - 340.36s |  For security that rarely happens and that leaves us with a very complex attack surface
340.72s - 346.32s |  That is rarely patched when a car has been shipped and is out there
350.06s - 354.78s |  However, despite this and despite Bluetooth being known insecure
355.30s - 358.38s |  This hasn't been really addressed in any larger scale
358.86s - 364.18s |  There have been a couple of papers looking at maybe one single exploit and one single car
364.58s - 370.14s |  but nobody has looked at the whole breadth of Bluetooth exploits that exist out there in
371.54s - 377.18s |  different cars and from different manufacturers and that was the gap that we saw here because there's
377.58s - 380.58s |  An estimated more than 1 billion cars with Bluetooth
381.38s - 383.26s |  Bluetooth classic
383.26s - 386.22s |  pretty much all of new cars have Bluetooth and
387.22s - 389.06s |  It's
389.06s - 393.54s |  Certainly an insecurity that we wanted to examine because no one has done it at scale
394.02s - 399.36s |  So that brings me to the standard Bluetooth
400.04s - 404.96s |  Technology stack Bluetooth as you will be aware as a wireless communication standard
405.28s - 411.20s |  it has a very complex tech stack because you have a lot of shared responsibility and
412.04s - 414.04s |  of course it has
414.64s - 417.00s |  to fulfill a lot of different
418.36s - 421.84s |  Use cases and that makes it very very complex
422.44s - 427.44s |  To fulfill these different use cases Bluetooth has a lot of different profiles
427.44s - 434.40s |  I'm not going through all of them in the interest of time here, but you can choose different profiles for them to make calls
435.24s - 442.00s |  of course to listen to music, but also some profiles can have full access to your SIM card in the car or
442.72s - 444.72s |  extract messages
444.80s - 448.04s |  That's how you can in your car and your car system
448.52s - 451.00s |  Communicate hands-free using your phone
452.92s - 455.56s |  The security models you basically have these four options
456.40s - 462.24s |  To pair to a Bluetooth system with another one our case a car
464.32s - 467.36s |  Depends on the capabilities of the thing you want to pair
468.00s - 473.72s |  You have display. Yes. No, you have something that only has a display but no input you have
474.24s - 481.48s |  Something that has a keyboard but no display and you have even something like headphones that has no input or no output whatsoever
481.48s - 484.24s |  And these all need to be somehow connected
484.76s - 486.76s |  with different means
487.84s - 490.76s |  So that's the Bluetooth security model
492.36s - 498.48s |  It's very binary either you're connected or you're not and if you're connected then we have
499.04s - 500.64s |  access basically
500.64s - 502.64s |  We have classic legacy pairing
503.76s - 506.48s |  There's basically no security in this
507.36s - 510.52s |  We have just works with yeah enables
511.16s - 513.60s |  quite easy man-in-the-middle attacks
515.68s - 517.68s |  We have passkey entry
518.20s - 521.72s |  Which is a bit more secure, but there have been method confusion attacks
522.32s - 524.20s |  shown against this
524.20s - 526.20s |  recently and the only
526.28s - 534.01s |  Known secure option at the moment is numeric comparison. There's prior art, of course
534.41s - 537.93s |  So we went through at the beginning so to check how many
538.65s - 545.45s |  Bluetooth vulnerabilities exploits and attacks are around. So this is we found more than 108
545.97s - 547.97s |  in March and
548.13s - 549.77s |  as of
549.77s - 550.97s |  2022
550.97s - 556.25s |  We found almost 650 CVEs just related to Bluetooth devices
556.77s - 560.77s |  The categories we've been looking at are critical exploits. So
561.33s - 563.33s |  Remote code execution and memory leakage
564.21s - 570.29s |  Man-in-the-middle denial-of-service or chaining attacks, which are not vulnerabilities in and by itself
571.09s - 573.09s |  but they can lead to
573.65s - 575.65s |  further exploitation
575.73s - 577.89s |  If the environment is right
578.45s - 586.30s |  So the goal for our procurement was to build a blue to Bluetooth
586.74s - 590.02s |  test kit for basically all the security and
590.82s - 592.82s |  Vulnerabilities on the market
593.66s - 600.82s |  Because that didn't exist at the moment and it was very difficult to build because there's no database of these
600.82s - 605.18s |  You will have academic papers. You have talks at DEF CON elsewhere
605.26s - 612.66s |  You will have some code released on github. You will have some people who have no code released. You have code that's
613.62s - 614.90s |  Developed on
614.90s - 619.82s |  Obsolete platforms where you can't get the hardware anymore or have to update software
619.82s - 625.22s |  All of these things are big problems and a lot of work to put this into one toolkit
628.30s - 635.42s |  On the so that's the general problem on the testing well Bluetooth testing has some
636.42s - 638.50s |  black box issues, of course
639.58s - 641.90s |  Yeah, kind of false positives false negatives
643.26s - 648.78s |  Automation at least of the denial-of-service stuff can be quite difficult because if
649.62s - 651.82s |  you basically crash the
652.78s - 654.78s |  entertainment system of your car
654.82s - 658.58s |  Or the Bluetooth system of your car and you want to restart the whole thing
658.58s - 663.70s |  we found some cars where you have to get out of the car lock the car and not just and
663.98s - 669.46s |  walk away walk away for 20 minutes because only then the car actually shuts off and restarts and
669.98s - 677.66s |  At that point, yeah, it's quite extensive the time that you need obviously to test several vulnerabilities
680.38s - 687.66s |  No matter we built this toolkit and exists it's has been online on github for a few months now
688.86s - 691.42s |  Link is here will also be on the on the last slide
692.14s - 696.58s |  Goals were collecting all these exploits that we can find and reproduce
697.58s - 699.58s |  44 and all in all
700.50s - 701.86s |  we
701.86s - 703.26s |  try to
703.26s - 709.98s |  Automate as much as possible. But yeah, we have some completely automated stuff some semi automated and somewhere
709.98s - 711.98s |  You have to do something manual
712.42s - 716.72s |  That's just the general
717.56s - 719.92s |  Architecture, so we have some yaml files
720.68s - 727.48s |  If you have new exploits, it's modular. You can add these files to the to the toolkit and
728.88s - 732.84s |  from there you need the basic setup that I will show and
734.28s - 739.92s |  Can go to the car connect to it and see which other vulnerabilities are present
740.64s - 745.40s |  So after building the toolkits
746.04s - 750.36s |  The second part was really let's check a lot of cards as many as we can find
752.12s - 759.40s |  We set up the toolkit as you see here with just any Ubuntu based box and a laptop or VM
759.92s - 761.92s |  Near some cables
762.16s - 765.72s |  For the full toolkit to be useful you will need
767.08s - 768.40s |  for example
768.40s - 775.16s |  Not only but also a Nexus 5 phone fairly old phone is cheap, but maybe not so trivial to get it on the market
775.88s - 776.92s |  because
776.92s - 779.08s |  There some other researchers have built
780.04s - 784.52s |  frameworks where you can really control the the Bluetooth stack in detail and
785.36s - 787.64s |  You can also get the ESP rower kit
789.40s - 793.88s |  If you don't have one of them, you can't test everything but at least partly you can do it
794.68s - 801.28s |  Overall, we found that with all the problems. It takes us one to three hours per car. You need to start the engine
801.80s - 807.12s |  to do most of the tests which can also be a problem if you're testing in garage and
807.96s - 811.40s |  Somewhere underground right? You don't want to run the engine for three hours
812.16s - 814.16s |  That would not be safe
814.80s - 818.48s |  Easier to test for electric cars. That's definitely a bonus
820.40s - 824.92s |  How did we procure cars you see the different manufacturers here
825.56s - 830.16s |  That was our job as I said, we have a lot of different cars manufacturers
830.32s - 836.28s |  So we took all our own cars brought us our army logistics
836.28s - 840.44s |  I took some of our own cars as researchers as our friends
841.04s - 843.04s |  overall 22 different cars
843.96s - 850.92s |  Most of them fully tested for only partially because we had them at the beginning of our research and there were more
851.16s - 853.16s |  exploits coming on later
853.40s - 857.76s |  price range everything from very cheap to fairly up markets and
859.00s - 866.84s |  The manufacturers or the Bluetooth systems at least covering our estimate roughly 60% of the global market by sales
868.04s - 872.00s |  Roughly 12 out of 15 of the top manufacturers selling cars last year
873.04s - 876.72s |  The tests are non-invasive. It's just connecting Bluetooth, basically
878.04s - 883.96s |  So let's get to the results overall took us. Yeah 40 ish hours
885.76s - 887.76s |  We found 73
888.36s - 890.36s |  vulnerabilities in these cars
890.36s - 895.52s |  So remember most of these exploits are known, but they're still all
896.44s - 898.44s |  present in these cars
898.96s - 900.96s |  Not everything can be solved
901.36s - 907.40s |  So we reported everything that was relevant and could be solved to the manufacturers and
909.00s - 911.00s |  Reported them responsibly
911.92s - 913.92s |  This shows part of the reason right
914.60s - 919.56s |  Cars like very much an adoption of standards. There's never the news Bluetooth version
919.56s - 926.04s |  We found that it takes roughly or the median age of a Bluetooth version in the car is seven years behind
926.56s - 928.76s |  the actual release Bluetooth standard
929.76s - 932.96s |  Full results of our car tests. They're also on the github
934.32s - 936.32s |  you see
936.48s - 941.32s |  Different range like, you know, you'd think very new cars should have no to
942.24s - 944.80s |  Fewer vulnerabilities that was true for these two
945.60s - 951.72s |  Not true for many others that were also fairly new from 2022 2023. We found a lot of
953.12s - 955.16s |  Vulnerabilities even critical ones in those
958.80s - 960.36s |  There's
960.36s - 967.40s |  Just another look at this right average number of vulnerabilities per car per manufacturer different
968.04s - 971.56s |  Ones here can focus on critical vulnerabilities
971.88s - 978.00s |  We found them well as you can see here and mostly Renault Opel and and Volkswagen a
978.64s - 980.64s |  few ones
980.68s - 982.68s |  denial-of-service vulnerabilities
983.52s - 987.08s |  prevalent in several manufacturers, but
987.92s - 993.84s |  So we don't have a lot of time you can look up the details for that on on the github we did found
994.24s - 998.08s |  two novel exploits and novel attacks doing our research
999.64s - 1006.12s |  The details on that are really extensively covered in the main stage talk yesterday still
1007.64s - 1010.36s |  Briefly going over it. There's one way
1011.04s - 1014.68s |  You can connect to cars and extract the contacts
1014.68s - 1021.28s |  So if you have a shared threat model, right you rent a car or have one of these
1022.84s - 1024.84s |  car sharing
1025.64s - 1030.96s |  Systems that happen exist in many countries, right? You just rent a car for a couple hours
1031.92s - 1033.96s |  Somebody connected their Bluetooth phone to that
1034.88s - 1038.32s |  the contacts will be saved later on you can go there and
1039.40s - 1042.02s |  Extract the contacts that were on the car
1042.78s - 1044.78s |  So we can see it here on the left
1046.66s - 1048.66s |  Should say
1048.66s - 1050.98s |  No contacts available if you connect with your phone
1051.74s - 1053.74s |  But if you run this new
1054.82s - 1062.54s |  Vulnerability, there's new exploits then you can as you see on the right actually extract the contacts that we had on our phone before
1065.46s - 1067.46s |  The second one is
1068.30s - 1074.66s |  Another way to establish a man-in-the-middle position even with a system that have numeric comparison and
1076.50s - 1078.98s |  I'll get to what that can do for you
1078.98s - 1085.82s |  It's just the proof of concept that it worked with four different cars and Hyundai Renault Audi and BMW
1086.06s - 1088.58s |  It's a so relatively widespread issue
1090.06s - 1092.38s |  What can we do with these things right if you
1092.98s - 1093.82s |  I
1093.82s - 1099.78s |  Wonder man-in-the-middle on Bluetooth and denial of service. How is that a problem? Why do we care?
1100.30s - 1102.78s |  You said cars are very complex systems
1102.78s - 1109.38s |  So one thing is we can obviously do some lateral movement. We can get get in for Bluetooth and get into
1109.90s - 1111.90s |  other systems of the car
1112.78s - 1115.98s |  we can as I said to establish man-in-the-middle positions and
1116.54s - 1121.80s |  Then that's something we discussed extensively yesterday. We can really
1122.38s - 1126.10s |  Get your two-factor tokens if they're sent by SMS
1127.02s - 1129.02s |  or
1129.38s - 1132.06s |  Yeah, get these tokens and then obviously
1132.94s - 1135.18s |  Exploit whatever account two-factor
1135.86s - 1141.34s |  You have set up. So that's quite workable. We've reported this also to the
1142.38s - 1143.58s |  phone manufacturers
1143.58s - 1149.82s |  So Apple and Google there were some difference in opinions whether this is a big problem or not
1150.50s - 1153.58s |  Google did patch it Apple did not patch it
1155.02s - 1158.54s |  You can basically build your own opinion on this
1159.54s - 1166.22s |  Brings me takeaways. I hope you realize much of Bluetooth is fundamentally insecure. This has been well known
1166.22s - 1171.86s |  There's so many exploits for this. This is both in the standards in the protocol and in the implementations
1172.66s - 1174.50s |  even the newest cars
1174.50s - 1176.14s |  new
1176.14s - 1180.78s |  Systems are shipped with protocol level Bluetooth vulnerabilities. We can't really fix this easily
1181.98s - 1183.98s |  You need to securely pair
1184.38s - 1190.54s |  But even that doesn't help because the repairing of the system might also be malicious
1191.54s - 1192.90s |  and
1192.90s - 1200.14s |  We built this toolkit. So if you want to know what your own car how vulnerable that is on the Bluetooth level, please use that
1201.06s - 1204.26s |  If you are a car manufacturer car part manufacturer
1204.46s - 1210.50s |  Please also use it check your security poster with regards to Bluetooth any questions
1211.34s - 1213.34s |  look at the at the github and
1214.18s - 1221.02s |  Come to me afterwards, but also please contact Vlad who did really most of the technical work here. Thank you


