# Media

url: https://www.youtube.com/watch?v=pTSEViCwAig
title: DEF CON 32 - On Your Ocean's 11 Team, I'm the AI Guy (technically Girl) - Harriet Farlow
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=pTSEViCwAig",
  "title": "DEF CON 32 - On Your Ocean's 11 Team, I'm the AI Guy (technically Girl) - Harriet Farlow",
  "description": "One of the best parts of DEF CON is the glitz and glam of Vegas, the gambling capital of the world. Many have explored hacking casinos (on and off stage). Unfortunately, it\u2019s just not like it is portrayed in the Oceans franchise.. in real life there\u2019s much less action, no George Clooney, and it\u2019s a lot harder to pull off a successful heist.\n\nFortunately I\u2019m not your typical hacker, I\u2019m an AI hacker. I use adversarial machine learning techniques to disrupt, deceive and disclose information from Artificial Intelligence systems.\n\nI chose my target carefully: Canberra Casino. It\u2019s the best casino in my city.. It\u2019s also the only casino but that\u2019s not the point. The casino industry is at an interesting inflection point. Many large casinos have already adopted AI for surveillance and gameplay monitoring, smaller casinos are starting to make the transition, and there\u2019s only a couple of companies in the world that provide this software. It\u2019s ripe for exploitation.\n\nIn this talk I\u2019m going to show you how I bypassed Casino Canberra's AI systems - facial recognition, surveillance systems and gameplay monitoring. AI Security is the new cyber security threat, and attacks on AI systems could have broad implications including misdiagnoses in medical imaging, navigation errors in autonomous vehicles.. and successful casino heists.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2261,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.08s - 2.76s | This text was transcribed using whisper model: large-v2

 Are there any Australians here in the room?
2.76s - 8.40s |  Yes, so you might be able to tell from my accent I'm from Australia and back home
8.40s - 11.80s |  we have a drinking tradition as well for special occasions and it's called a
11.80s - 17.56s |  shoey. I don't know if any of you have heard of it but basically you pour like a shot in a
17.56s - 21.72s |  shoe and you drink it from the shoe which sounds disgusting but it's a thing
21.72s - 26.24s |  that Aussies do so you know this this shot is a lot of fun but you'll have a
26.24s - 32.08s |  lot to learn from Australians. All right so yeah thank you very much for being
32.08s - 38.12s |  here I'm really stoked. The presentation today is called On Your Oceans 11 Team
38.12s - 42.80s |  I'm the AI Guy even though I'm a girl that it just has a better ring to it I
42.80s - 47.92s |  need to maybe find a better title but this is my second time at DEF CON and my
47.92s - 52.44s |  first time speaking and I'm a little bit jet-lagged because of the the trope and
52.44s - 57.48s |  I'm speaking four times this week so forgive me if I'm a bit tired like
57.48s - 60.64s |  forgetting all the the order of the slides for various presentations you
60.64s - 64.92s |  sort of submit things and I didn't actually expect to get all of them in so
64.92s - 68.48s |  I'll be giving this talk a little later in the AI village as well and I gave a
68.48s - 74.48s |  similar one at B-Sides but yeah as you can probably tell from the the
74.48s - 79.04s |  description and the title of the talk I'm an AI person so maybe the casino
79.04s - 83.52s |  part has kind of been shoehorned into an AI security talk but I think it makes
83.52s - 88.32s |  sense for Vegas right we want it to be to be sort of relevant I thought it'd
88.32s - 92.42s |  be an interesting topic to sort of go through AI security but before I get
92.42s - 98.16s |  into the topic can I get a show of hands if you're like a cyber person if you can
98.16s - 103.68s |  see yourself a cyber person okay and what about the people who would consider
103.68s - 110.00s |  themselves an AI person cool okay and anyone who finds these robot tests
110.00s - 113.28s |  these days really hard and isn't sure if they're a person at all I feel like
113.28s - 117.44s |  that's the camp I sometimes sit in okay so I suspected that the crowd would
117.44s - 125.24s |  mostly be cyber people so the talk is focused on sort of explaining AI
125.24s - 128.80s |  security in a way for for cyber folks so there's a little bit of theory at the
128.80s - 132.36s |  beginning and I apologize for that and if you're an AI person please don't come
132.36s - 138.92s |  at me but before I now I know a little bit about who you are who am I I'm
138.92s - 144.12s |  pretty sure I'm a human even though I failed the robot test sometimes but I'm
144.12s - 148.44s |  in AI security I've been working at the intersection of AI and security for
148.44s - 152.32s |  about 10 years now my undergraduate was in physics and I didn't really know what
152.32s - 156.16s |  to do with it so like many physicists I went into data science and so I worked
156.16s - 160.64s |  as a data scientist in Australia in a consulting company for a while mostly on
160.64s - 164.72s |  defense projects I had my quarter-life crisis and moved to the United States
164.72s - 168.76s |  and worked at a startup then during COVID I moved back to Australia and
168.76s - 172.16s |  worked in the Australian government and that's when I did my PhD in machine
172.16s - 176.48s |  learning security and I found that at the time when I started working in the
176.48s - 180.64s |  field in 2021 no one was really talking about machine learning security people
180.64s - 185.52s |  are now fortunately but that's why about a year ago I left my job and I started
185.52s - 190.52s |  my company more ever security labs and we're an Australian based startup we
190.52s - 193.48s |  provide workshops and training in AI security and we just got funding to do
193.48s - 197.68s |  our first tech product which is exciting but you can also find me at Harriet hacks
197.68s - 201.92s |  on various social media platforms maybe you can find me there if you want it's
201.92s - 206.20s |  it's a bit hacky like we all got to start somewhere so please be forgiving
206.20s - 211.52s |  but our objectives today are to hack the casino we've probably all heard of some
211.52s - 216.00s |  pretty high-profile casino related hacks in the cyberspace but I really wanted to
216.00s - 220.84s |  explore the AI dimension specifically because we are at the sort of inflection
220.84s - 224.16s |  point where so many organizations including casinos are adopting AI now
224.16s - 228.48s |  and most of them are inherently insecure so I wanted to test this so we're going
228.48s - 232.12s |  to start with some exploration work I didn't know much about casinos when I
232.12s - 236.64s |  like to come out with this topic so that that was part of it then we're going to
236.64s - 241.52s |  hack the facial recognition AI and then I guess we have to think of some lessons
241.52s - 246.20s |  learned in AI security right so why did I pick the casino apart from thinking it
246.20s - 251.48s |  would sort of fit for the Las Vegas DEF CON context so much AI is vulnerable
251.48s - 255.50s |  however people only seem to care when you lose a lot of money or when there's
255.50s - 259.92s |  a big hit on your brand reputation and casinos are a really good example of an
259.92s - 265.12s |  organization like this where you know the casino always wins right so bringing
265.12s - 268.88s |  people in the door and having people trust your brand and want to you know
268.88s - 271.80s |  have entertainment when you're definitely statistically going to lose
271.80s - 275.84s |  money is tough and so thinking about security from that context is really
275.84s - 279.68s |  important but it's also a good analogy for literally every organization right
279.68s - 285.72s |  now that's adopting AI so a few disclaimers before I start I worked with
285.72s - 290.52s |  casino Canberra on this and you know that I'm from Australia well I'm from a
290.52s - 296.92s |  town in Australia called Canberra does anyone know Canberra yay yeah Canberra's
296.92s - 299.76s |  I don't know I have a love-hate relationship with Canberra it's pretty
299.76s - 305.44s |  boring but it's got a great quality of life and you know it's got some things
305.44s - 310.16s |  going for it but we it's our political capital for those of you who might not
310.16s - 313.80s |  know that a lot of people think Sydney's our capital but it's it's actually
313.80s - 321.52s |  Canberra so imagine DC but like 1 14th of the size because Australia is 1 14th
321.52s - 325.20s |  of the population of the United States so we only have one casino and I'm
325.20s - 328.56s |  really glad that they were willing to be you know really cooperative with with
328.56s - 333.36s |  me on this so I'm you know massive thank you to casino Canberra so they are our
333.36s - 338.64s |  town's best casino so that that's pretty exciting as a side note in my uber ride
338.64s - 345.32s |  over here my uber driver said that his son vacationed in Australia and their
345.32s - 348.80s |  honeymoon was in Canberra and they loved it so much that they named their child
348.80s - 355.76s |  like Giovanna Canberra and I don't know any anyone who's familiar with Canberra
355.76s - 359.56s |  would just find that shocking but anyway um so going on with the disclaimers um
359.56s - 364.72s |  so obviously the attacks are real but you know I'm an ethical hacker I you
364.72s - 368.24s |  know I care about casino Canberra I'm not literally showing you how to attack
368.24s - 373.56s |  their systems or you know specific AI systems and like I said the talk is
373.56s - 380.16s |  aimed at cyber cyber folk so a little bit about casinos for the people like me
380.16s - 384.24s |  who might not have known about casinos they obviously like a lot of money they
384.24s - 387.60s |  have a controversial history and there's a lot of reasons why that history is
387.60s - 392.56s |  sort of controversial casinos are a hotspot for money laundering because
392.56s - 396.44s |  it's an easy way to move funds around particularly in Australia there's been
396.44s - 401.84s |  some controversy lately our two big casino brands star and crown had to pay
401.84s - 406.56s |  big fines because they didn't comply with any money laundering laws and
406.56s - 410.44s |  there's been Royal Commissions and stuff and it's the same in other countries as
410.44s - 415.52s |  well casinos are getting a little bit of heat so security is important they use
415.52s - 420.16s |  AI obviously otherwise this talk wouldn't have gone as I planned and they
420.16s - 425.56s |  use AI for lots of different reasons and as I'll go into later they rely
425.56s - 430.20s |  specifically on facial recognition and person detection but the landscape is
430.20s - 432.72s |  really interesting when it comes to casinos because just like any
432.72s - 435.96s |  organization they're trying to figure out exactly what the most strategic or
435.96s - 440.64s |  the best way of actually adopting and integrating AI is and just like any
440.64s - 444.08s |  organization they have to rely on third-party providers for the most part
444.08s - 446.44s |  or they can bring in their own consultants but that's sort of
446.44s - 451.04s |  expensive and not all casinos can necessarily do that and there are also a
451.04s - 457.16s |  few companies that provide AI services to casinos that are you know already
457.24s - 461.28s |  providing things like chips and and cards to casinos as well so it's a very
461.28s - 467.24s |  small space. When I first started this talk I thought that things like card
467.24s - 473.24s |  counting would be a use of AI in casinos and it's not so you're probably
473.24s - 477.44s |  familiar with card counting and it's not illegal it's considered advantage play
477.44s - 482.12s |  so a casino however does have the discretion to like prevent people from
482.12s - 485.80s |  playing there for any reason so if a person is very ostentatiously card
485.88s - 489.68s |  counting and winning a lot of money probably the casino is going to not want
489.68s - 494.12s |  to have them there but it was interesting because I expected that
494.12s - 501.08s |  things like card counting would be a big use case for AI and it wasn't. So how do
501.08s - 508.88s |  we actually hack an AI? Sorry this is the first bad joke of the day so when I
508.88s - 512.60s |  first told my mum I worked in AI she said oh darling what are you doing
512.60s - 517.60s |  working in artificial insemination because I know that was a pretty laugh
517.60s - 522.60s |  but thank you. She works in medicine and so to her that's what AI is and so
522.60s - 527.40s |  obviously for most people here AI is artificial intelligence but even though
527.40s - 531.28s |  we know it means those two words what people have in their mind when they
531.28s - 535.92s |  think of what artificial intelligence is definitely differs. Some people imagine
535.92s - 540.64s |  Skynet and things like artificial general intelligence, some people imagine
540.64s - 544.52s |  algorithms, machine learning systems, some people just imagine anything that's
544.52s - 548.64s |  sort of at the cutting edge of technology. So when we think about how to
548.64s - 552.32s |  hack an AI system we really have to think about like the actual technology
552.32s - 555.84s |  that we're trying to hack rather than sort of a some sort of AGI related goal
555.84s - 560.52s |  so I'm focusing very much on machine learning models but if we really think
560.52s - 564.40s |  about the history of AI and if we think about it as just something that does
564.40s - 569.52s |  something a human might otherwise have done I mean the idea of hacking AI has
569.52s - 575.72s |  been around for a long time. So this is an example from a casino context as we
575.72s - 578.88s |  know that there are no random numbers in computers right it has to be an
578.88s - 582.32s |  algorithm and so there are some pretty high-profile cases of people being able
582.32s - 586.76s |  to basically hack the algorithm. People who have access to sort of like the
586.76s - 591.08s |  seed information of these algorithms have been able to like steal money
591.08s - 595.92s |  pretty large sums. In 1995 Ron Harris was able to steal $100,000 this way
595.92s - 599.16s |  because he knew about the algorithm was able to predict the next numbers very
599.16s - 603.72s |  successfully in in a game of Keno. I hope they're not having more fun than
603.72s - 607.84s |  us because they're very loud. Do I need more bad jokes? I don't think you really
607.84s - 612.84s |  want that either. So that's one example of hacking an AI I guess and the other
612.84s - 617.16s |  is sort of card counting. So if we think about it the reason that the casino
617.16s - 620.60s |  always wins right is because the game is statistically in their favor and that
620.60s - 625.88s |  goes anywhere from sort of a 2% to a 25% advantage where 25% would sort of be
625.88s - 629.80s |  like the slot machines and then 2% would be a game of blackjack and that's
629.80s - 635.00s |  why card counting and blackjack is most likely to be able to reduce the casinos
635.00s - 640.40s |  favor because if you if you use like perfect strategy which is just doing the
640.40s - 644.84s |  the plays that are statistically most likely to have you win plus card counting
644.84s - 649.48s |  you can reduce that to like closer to closer to zero and the only reason that
649.48s - 653.80s |  the slot machines are 25% max is because of regulation anyway otherwise the
653.80s - 656.92s |  casinos would probably want them to be higher but that's an example of algorithm
656.92s - 660.00s |  hacking too because you're hacking the statistical process of being able to do
660.00s - 664.92s |  that. So when we think about the modern iteration of hacking an AI system we
664.92s - 668.44s |  come to the realm of adversarial machine learning and everyone probably has seen
668.44s - 671.96s |  this picture before so I feel like I have to show it but basically the idea
671.96s - 677.76s |  is that you're able to create specifically crafted adversarial
677.76s - 682.26s |  examples that you can then input into a machine learning model to make it not do
682.26s - 687.14s |  what it's meant to basically. So this example is from ten years ago and this
687.14s - 691.90s |  is like an image of a panda where you can have an adversarial example
691.90s - 696.86s |  superimposed on top of that which is just perturbations to the image
696.86s - 700.62s |  specifically crafted based on the target model that you're trying to attack and
700.62s - 705.54s |  it can disrupt or deceive the model really successfully even though a human
705.54s - 709.78s |  can't recognize it. So adversarial machine learning is the field that my
709.78s - 714.86s |  PhD was in and you can consider it sort of the offensive side of AI security
714.86s - 719.38s |  it's basically the field that is coming up the attacks but it's traditionally
719.38s - 723.70s |  been very academic. Recently we're starting to see more examples of these
723.70s - 730.10s |  kinds of things in real life so being able to actually you know implement some
730.10s - 733.66s |  change in the physical world that's able to prevent say autonomous vehicles from
733.66s - 738.62s |  being able to recognize stop signs so they drive straight through. And in terms
738.62s - 743.38s |  of the landscape of adversarial machine learning attacks it's massive it's just
743.38s - 747.42s |  exploded over the last ten years and if we think about all of the different
747.42s - 752.34s |  attack surfaces represented by AI systems and so on the top things like
752.34s - 755.98s |  convolutional neural networks which is a machine learning model really good at
755.98s - 761.02s |  computer vision versus something like a transformer along the bottom which is
761.02s - 764.98s |  very good at natural language processing in the backbone of things like GPT.
765.82s - 769.90s |  They're very different attack surfaces but many different adversarial machine
769.90s - 774.58s |  learning methods now exist that are able to very successfully do bad things at
774.58s - 779.62s |  each stage of that attack at that attack surface. So most of the time these
779.62s - 783.70s |  attacks require you to actually change something about the object itself right.
783.70s - 788.90s |  So you have the panda example before we have things like adversarial glasses
788.90s - 793.38s |  that prevent a person being recognized from detection. You have like a jumper
793.42s - 798.26s |  that can also hide a person from person detection. And the example I love on the
798.26s - 803.18s |  bottom right is this DARPA model that was meant to be used in sort of urban
803.18s - 807.14s |  warfare environments to detect people and they asked their Marines to try and
807.14s - 810.74s |  red team that model and they found that the Marines could just act not like
810.74s - 814.10s |  people and very successfully deceive the model. So they did things like put
814.10s - 817.62s |  cardboard boxes on their heads. They waved branches around and acted like
817.62s - 821.10s |  trees whatever that means. And they were very successfully able to hack the
821.10s - 826.76s |  model. The the challenge with all of these things is that you're actually
826.76s - 830.20s |  required to change something about the object itself that's being classified.
831.40s - 835.52s |  There are some examples of like attacks where you don't need to change the
835.52s - 839.56s |  thing itself. This is called an adversarial sticker. So if I put this next
839.56s - 845.52s |  to something else a model is going to like predict that this is a toaster. So
845.52s - 848.96s |  if I put this next to a banana which is the sort of the example that they they
848.96s - 853.40s |  give instead of recognizing the banana the model is going to see a toaster
853.40s - 857.84s |  instead. However this is sort of challenging because like this is very
857.84s - 860.76s |  obvious like if I put this next to a banana I'd be like that's not meant to
860.76s - 866.60s |  be there. That's a banana. But a model doesn't see it that way. So I had a
866.60s - 871.00s |  thought I was like what if you could like change something about what's in
871.00s - 875.92s |  the image frame itself but you didn't have to perturb the actual image. And so
875.92s - 880.92s |  I came up with this technique called distributed adversarial regions. And this
880.92s - 885.00s |  is part of my PhD where I was sort of coming up with this attack. And so the
885.00s - 889.12s |  intent for this was largely in urban camouflage environments. So being able to
889.12s - 895.96s |  do things like have specially crafted buoys around ships for example like
895.96s - 899.96s |  military ships. So you think it's a container ship instead or having it
899.96s - 904.92s |  around other different kinds of military platforms. And if I can easily get the
904.92s - 914.22s |  video working. This is just a very quick example of what this would look like. So
914.22s - 918.82s |  if you have these sorts of buoys around that's a Japanese U-boat. You can
918.82s - 925.22s |  actually prevent the model from recognizing that platform. Also don't
925.22s - 927.94s |  come at me for them not being real buoys. It would have been a very expensive
927.94s - 933.38s |  endeavor to like put buoys around a vessel. The thing about being able to
933.50s - 938.70s |  digitally manipulate the images is that um you know it's a really good surrogate
938.70s - 941.86s |  for not being able to actually change the physical environment. Um and being
941.86s - 946.86s |  able to test it. So I I wanted to see if I could apply this technique to things
950.78s - 955.78s |  like um facial recognition for this casino context. So how does this relate to
957.06s - 962.06s |  casinos? I assume everyone here is familiar with the Oceans 11 franchise. Yes
963.42s - 966.82s |  I mean it's it's a heist. You know like we don't need to get too too thinking
966.82s - 971.90s |  about it. The idea is that we're basically just bypassing all of these different um
971.90s - 976.30s |  security levels that they have in a really cool way. Ideally there's um like
976.30s - 980.84s |  bourbon and and suits and George Clooney. Um I did not get to have a George Clooney
980.84s - 985.88s |  in my life. I'm doing this talk but that's okay. Um so we get the premise of the
985.88s - 990.88s |  heist. This is what I wanted to do. I wanted to understand uh casino Canberra's I
990.88s - 995.88s |  don't know AI operational environment. Um then I'm going to pick some target
998.12s - 1003.80s |  models to create this attack. And then going to you know implement the the the
1003.80s - 1007.54s |  DAS, the distributed adversarial regions. I'm going to test how I can sort of
1007.54s - 1012.54s |  disguise them in different ways and then lessons learned and sort of next steps.
1014.40s - 1019.22s |  So the first step. I I mentioned my PhD. I've been doing it part time for a really
1019.22s - 1024.02s |  long time. So I feel like I should be finished but I'm not. Um now this is annoying
1024.02s - 1028.30s |  because it's really hard to like simultaneously try and build a start up and also
1028.30s - 1033.00s |  finish a PhD. My supervisors only one of them knows I'm here right now. The other
1033.00s - 1037.68s |  thing comes in Canberra like working working from the university. Um so don't tell
1037.68s - 1042.54s |  them. But the good thing about still doing a PhD is not only do I get really good
1042.54s - 1048.18s |  student discounts but people are very helpful. So if I reach out to people and I tell
1048.18s - 1052.82s |  them that I want to do something as part of my PhD, people generally say yes. It
1052.82s - 1056.68s |  helps that I'm also sort of like nice and polite and you know people are always just
1056.68s - 1061.76s |  very helpful. Um so this is what I did with Casino Canberra. And they were very
1061.76s - 1067.40s |  willing to help which was nice of them. So this is Casino Canberra. Maybe it doesn't
1067.40s - 1072.90s |  look like the Bellagio or the MGM Grand but like they have a a red carpet. Um it's
1072.90s - 1076.48s |  very nice. It's right next to our civic centre. Um it's between there and the
1076.48s - 1081.88s |  convention centre. Um it's you know they they do okay. Um they're very excited
1081.88s - 1085.28s |  about a new upgrade that that they're doing. They're gonna get a lot bigger.
1085.28s - 1091.28s |  There'll be a hotel. Um they they've got it going on. So as part of this upgrade
1091.28s - 1095.70s |  they're thinking about implementing artificial intelligence for the first time.
1095.70s - 1100.96s |  Something I was really interested to learn through doing this sort of research was
1100.98s - 1105.98s |  that um facial recognition and person detection was by far the largest um like the
1108.62s - 1113.86s |  most important form of AI for casinos. But it's obviously very unequal in how casinos
1113.86s - 1120.00s |  are able to adopt them. So all of the casinos we have here in Vegas would very much rely
1120.00s - 1124.04s |  on using AI and they would have very mature practices around it. And in fact they
1124.04s - 1128.18s |  would actually build their casinos using this AI in mind. So when we walk around the
1128.20s - 1132.94s |  casino you might notice that sometimes there are like sort of narrow corridors that you're
1132.94s - 1136.24s |  forced to walk through. And that's to make sure that your faces are actually caught by
1136.24s - 1142.04s |  these cameras. So as as a casino like Casino Canberra is thinking about their redesign
1142.04s - 1146.78s |  this is very much inherent in how they actually decide to design the casino. So that they
1146.78s - 1152.22s |  can use things like facial recognition to identify money launderers or known criminals
1152.22s - 1157.40s |  or card counters I guess. Um also problem gamblers. Um there are some you know nice
1157.42s - 1160.52s |  use cases for it as well. They want to make sure that people aren't gambling too much.
1160.52s - 1165.26s |  Just the right amount. Um and things like number plate recognition for cars is also
1165.26s - 1169.80s |  really important. Um but in terms of AI this is very much a computer vision problem. So
1169.80s - 1173.50s |  being able to see things in the environment and understand it. They don't really have a
1173.50s - 1178.60s |  lot of use for other kinds of AI right now anyway. Not not things like chat bots or signal
1178.60s - 1183.88s |  processing. That's not that's not really in their realm. Um but right now they're also
1183.90s - 1188.80s |  very much dependent on people. Just being able to um like identify those known people and
1188.80s - 1193.40s |  then log them in the system. Um that's that's very much still dependent on on humans even
1193.40s - 1198.40s |  here. So what I did next was I need to choose a victim right? Um like I said Casino Canberra
1200.62s - 1205.92s |  doesn't currently use AI so I couldn't really use any like live facial recognition that
1205.92s - 1211.62s |  they were using right now. So instead I had to pick uh an appropriate victim that would
1211.66s - 1216.30s |  be close enough to something they would use. And you might think that this is a problem.
1216.30s - 1220.44s |  However it's not fortunately because of this principle in machine learning and its
1220.44s - 1226.88s |  convergence. I don't know if this works with a big crowd. Um but I might try some audience
1226.88s - 1230.42s |  participation. I don't know. Does anyone want to shout out and guess what this number
1230.42s - 1238.57s |  might represent? I actually can't hear anyone anyway. So I'm gonna assume that maybe one
1238.61s - 1243.61s |  of you was right. Um so this number actually represents um some significant research into
1246.95s - 1251.95s |  similarity of models. So if you have a model trained on similar data to do similar things
1254.45s - 1259.43s |  you end up with a similar model. Like basically the same model. Um and this is actually
1259.43s - 1264.43s |  really significant because a lot of the models that companies rely on and produce as part
1264.43s - 1269.43s |  of their IP are very much or like you know exactly the same as open source models. And in
1272.63s - 1276.17s |  fact a lot of the time they do actually just use open source models and then do a bit of
1276.17s - 1280.15s |  fine tuning. And that doesn't necessarily change the model itself. Certainly doesn't change
1280.15s - 1284.05s |  the architecture. It might change uh you know sort of how you apply it to different use
1284.05s - 1289.05s |  cases. But it a lot of research has been done to show that if you compare two models an open
1289.91s - 1294.91s |  source model with uh like a a model that is a company's IP to do things like facial
1296.75s - 1301.75s |  recognition. They are 95 to 99 percent similar. It's a minimum of 95 percent similarity.
1303.35s - 1308.23s |  Which is really significant because it means that I don't really need to you know do
1308.23s - 1313.23s |  anything to um difficult to be able to find a good victim model. So that's convergence.
1315.52s - 1320.52s |  So there's a lot of different victim models that I wanted to test. Um like I mentioned I
1322.62s - 1326.26s |  already did this attack for things like urban camouflage. So being able to do things like
1326.26s - 1330.26s |  object detection and testing some of those models. Um I also added some of these facial
1330.26s - 1334.94s |  recognition models um as well. These are just a few of the the open source models available
1334.94s - 1339.94s |  at the moment. So the next step is to create these distributed adversarial regions. Um and
1340.82s - 1345.82s |  this is a fairly boring diagram. So maybe I'll show you instead a slightly less boring video.
1348.34s - 1353.34s |  Um it it's very hard trying to create fun demos for this. I don't know. So um maybe I need to
1357.04s - 1362.04s |  find a way. So so this is the um the the video that I'm testing on right. This is me walking
1362.18s - 1367.18s |  up to the the detection. And this is uh me implementing the attack on one of my target
1372.02s - 1377.46s |  models. Um so I'll talk through the method because it takes a couple of minutes. But
1377.46s - 1382.90s |  basically all I need to do to implement this attack is to uh perform an optimization
1382.90s - 1389.74s |  algorithm on the video in question. To identify different regions where if I perturb them in
1389.74s - 1395.22s |  certain ways um they're going to cause a misclassification which sounds really easy. Um but
1395.22s - 1400.82s |  the the difficult thing is in sort of making those areas not too obvious or at least being able
1400.82s - 1405.82s |  to pick uh a few different regions that could reasonably actually be altered. And so this
1407.86s - 1412.86s |  code shows me being able to like perform that optimization uh based on one of these victim
1413.20s - 1418.20s |  models. Um making a prediction on on this video. If you're not a person who finds the code
1424.73s - 1428.59s |  interesting uh maybe at least the thing you can take away is that it only takes a minute to do.
1428.59s - 1434.57s |  Like it it's very easy. Um and I don't even need to use like an existing um pre-built library
1434.57s - 1438.03s |  or anything. It it's just an optimization algorithm. So so when I said before that there's
1438.03s - 1444.55s |  over a hundred different kinds of adversarial machine learning attacks. Um it's it's really
1444.55s - 1452.76s |  easy to just sort of build them yourself. It it's all optimization at the end of the day. So we
1452.76s - 1457.86s |  can see on the screen here that the the code read out no match found. And then when I add the
1457.86s - 1463.96s |  perturbed image um sorry so that there was a match found um for the clean image and then when
1463.96s - 1475.69s |  I added the distributed adversarial regions there was no match found. So the interesting thing
1475.69s - 1482.09s |  about being able to like do the testing or maybe not the most interesting thing actually. Um but
1482.09s - 1487.09s |  the the process of actually thinking about the attack surface and let me skip through here. Um
1490.63s - 1496.37s |  thinking about the actual attack surface and what we're like affecting in this attack. So all
1496.37s - 1500.87s |  computer vision most computer vision relies on convolution convolutional neural networks
1500.87s - 1506.47s |  because they're the most powerful sort of model to be able to do this. Um and being able to
1506.47s - 1510.75s |  create attacks that work for most of them it's actually pretty easy. So if we think about facial
1510.77s - 1517.71s |  recognition the way that it works is that it it sort of takes your facial geometry and then is able
1517.71s - 1523.05s |  to compress it into an embedding space. Um and being able to identify clusters and sort of
1523.05s - 1530.03s |  relationships between them and then um based on that mapping you know be able to identify me
1530.03s - 1535.47s |  versus not me I guess. And so when I have that information I can do things like create specific
1535.49s - 1540.49s |  patterns that change that distribution. So if I go back and play um this other recording I want to
1550.63s - 1556.07s |  be able to test doing things like um creating jewelry. So this is this is the example that I'm
1556.07s - 1561.07s |  testing. So the the challenging thing about building models or thinking about model
1561.99s - 1566.99s |  security is that all of these models that are that I'm testing on it doesn't actually take much to
1570.67s - 1575.67s |  be able to disrupt them. Um creating this attack is really very simple. Let me skip back to the
1590.01s - 1597.67s |  slides while this uh while this loads. So maybe it doesn't look so interesting but being able to
1598.21s - 1603.21s |  do that attack and like have it not recognize me um I guess that's a way of saying that I hacked the
1604.75s - 1609.75s |  model right. I mean it was able to not recognize me because I created these sort of adversarial
1611.59s - 1616.59s |  earrings that you know when the model looks at that that image of me um it doesn't recognize me.
1618.13s - 1622.83s |  When I test it um that's the important part of the process right from machine learning
1622.83s - 1627.93s |  perspective. This looks very boring too. Um I I tested all of those different models and I
1627.93s - 1632.41s |  wanted to see the extent to which the attack actually works and decreases the confidence level
1632.41s - 1637.41s |  of that attack. Um as a way of distilling all of the sort of the boring columns in the graph, the
1639.01s - 1644.01s |  number that we ended up with was a 40.4 percent reduction in like confidence. Um so what does
1646.11s - 1651.93s |  that actually mean? Is is that significant? Um when I implemented this attack on the urban
1651.95s - 1658.57s |  camouflage environments um it was more successful honestly. It's it's a bit easier for things like
1658.57s - 1664.81s |  ships and military platforms because those models tend to rely a lot more on context and in
1664.81s - 1670.11s |  facial recognition it's a little bit harder because a lot of models would tend to um look at the
1670.11s - 1676.49s |  geometry um slightly differently. But 40.4 percent on the whole of all of the models that I
1676.51s - 1682.09s |  tested is actually really significant because that means that if I have say a confidence
1682.09s - 1687.09s |  threshold of um like 90 percent. So a model looks at an image of me and says with 99 percent
1689.29s - 1694.29s |  confidence that it is me, being able to decrease that confidence by around 40 percent means that
1696.83s - 1701.97s |  if it was originally 99 percent then it's going to be um 40 percent less than that and it's not
1701.99s - 1708.37s |  going to meet that threshold. So I don't actually need to affect a massive change in the model to
1708.37s - 1714.67s |  be able to have it not recognize who I am. And I guess a way of thinking about that is by
1714.67s - 1719.91s |  calling it context. But really what it means is that most of the models that are already out
1719.91s - 1725.01s |  there, all of the open source models that we use and data scientists use and organizations in
1725.03s - 1732.03s |  fact use and then fine tune are vulnerable to an attack like this, which is really very
1732.03s - 1737.03s |  simple you know. Um what I did by adding uh you know regions of perturbation to myself is
1741.01s - 1746.01s |  really is definitely not the most sophisticated the most sophisticated kind of attack. Um
1746.01s - 1750.85s |  yesterday I was at an AI security forum and it was amazing because everyone was sort of
1750.85s - 1756.33s |  talking about all of the latest breakthroughs in in AI security and how we can make models
1756.33s - 1761.53s |  extremely secure and the technical and the governance things. The the really challenging
1761.53s - 1767.61s |  thing though is that most organizations don't have that existing level of maturity and the
1767.61s - 1772.05s |  kinds of models that they're using are these kinds of open source models that only take a few
1772.05s - 1777.05s |  regions to be disrupted and to cause a misclassification. And thinking about the uh I guess
1777.89s - 1782.89s |  thinking about what this actually means is really significant because while I've applied
1785.03s - 1790.57s |  this to a computer vision use case, so this could work for things like retina scanning,
1790.57s - 1795.07s |  number plate recognition as well, without actually having to change the object itself but
1795.07s - 1800.91s |  just changing things around the object um really just highlights how brittle most models
1800.95s - 1805.95s |  are. Um it also highlights that while I did this in a computer vision use case because
1809.05s - 1815.33s |  that's sort of what what works for this um facial recognition casino context, exactly the
1815.33s - 1820.43s |  same kind of attack could be applied to different domains as well. So things like uh
1820.43s - 1825.43s |  natural language processing and signal processing. And when we think about what natural
1825.67s - 1831.73s |  language processing and signal processing actually are in an AI uh use case context, natural
1831.73s - 1836.61s |  language processing does all the the cyber security applications as well. So being able to
1836.61s - 1841.61s |  identify uh malware, being able to um identify like good versus bad code, um they're natural
1844.15s - 1849.85s |  language processing problems. And if we can add perturbances that are actually not about
1849.85s - 1853.99s |  the the thing that we're trying to classify, but it's still able to disrupt the model, that's
1853.99s - 1859.33s |  a real problem. It's the same in the signal processing space, that's things like um RF and
1859.33s - 1864.33s |  audio and um and LIDAR, you know all the signal processing problems we have, medical
1865.67s - 1871.47s |  imaging, um being able to add perturbances that aren't even related to the thing that you're
1871.47s - 1876.47s |  trying to classify represent a massive problem. Um I did some other research that looked at
1876.67s - 1881.67s |  this in large language models as well. Uh this isn't exactly a cool demo, though I I wish it
1885.07s - 1890.35s |  could be, but basically I was looking at being able to add different sort of ideas to
1890.35s - 1895.35s |  language models and see if they could um if they would sort of take up that information and
1897.39s - 1902.39s |  have it alter the messages that they were giving. And we found that um after sort of a few
1902.39s - 1907.39s |  simulations and a few iterations of being able to add this additional kind of like noise
1909.13s - 1914.13s |  material, they did actually successfully adopt these other um these other ideas, even if
1916.13s - 1921.13s |  that wasn't um sort of encoded into them already. The when when we think about attacking
1923.11s - 1928.51s |  machine learning models, the the challenging thing as well is that it's not the same as
1928.53s - 1934.47s |  cyber security. Like when we think about testing a model and identifying uh what what makes a
1934.47s - 1939.45s |  good model, data scientists will use scores like this. Um so they look at accuracy, they look
1939.45s - 1944.25s |  at precision, uh recall an F1 score sort of related to precision as well. They look at all
1944.25s - 1949.25s |  the statistical um functions for a model that makes it um like largely accurate. But the
1952.59s - 1957.57s |  security is rarely ever considered and it's very it's a very different problem to a
1957.59s - 1963.37s |  cyber security problem. I mean what does it mean to hack an AI system itself? You know I I sort
1963.37s - 1970.01s |  of looked at that 40.4 percent number and felt a little bit disappointed. Like I sort of wished
1970.01s - 1974.27s |  that it was a bit more definitive. But the thing with hacking an AI system is that it's not
1974.27s - 1980.31s |  really a a binary um did it work or did it not. But it's more about on the whole we were able
1980.31s - 1985.99s |  to reduce the classification confidence of a model. So it's more it's better to think about it
1986.01s - 1992.11s |  as part of the kill chain. And quite a lot of the attacks at the moment are very much um sort of
1992.11s - 1996.69s |  like a Stuxnet equivalent. You know they're they're very complicated, they're very difficult
1996.69s - 2001.85s |  to implement. That's why there's this idea that they're a bit more academic than than realistic
2001.85s - 2007.87s |  or practitioner based. Whereas even though being able to add like these these random
2007.87s - 2013.27s |  distributed regions to an image um isn't all that sophisticated that the fact that it works
2013.29s - 2017.49s |  and it actually disrupts a model most of the time is a real problem. And it's it's sort of more
2017.49s - 2023.23s |  akin to like the the DDoS attack equivalent in a machine learning sense. Because even though
2023.23s - 2028.23s |  that number was 40.4 percent um in our experience if you're able to leverage some sort of AI attack
2030.93s - 2036.21s |  or some sort of adversarial machine learning attack you're able to hack the system 100 percent
2036.21s - 2041.35s |  of the time. Because there's always a way that you can adapt it for whichever case study you need
2041.39s - 2047.07s |  to. So the fact that so many organizations are reliant on these like inherently insecure
2047.07s - 2053.86s |  models is a real problem. Because AI security is real. So if if we're thinking about like next
2055.16s - 2059.84s |  steps and and lessons learned from an attack like this um we already have a few companies
2059.84s - 2064.84s |  starting to put out reports about the incidence of AI security related attacks. Uh and it's it's
2066.74s - 2072.92s |  changing a lot like it's uh encouraging that since I started in the field it's definitely uh
2072.92s - 2077.84s |  being taken more seriously and we're starting to see these incidents. Um but it's it's really
2077.84s - 2082.50s |  unfortunate because we have so many lessons from the field of cyber security that we could bring
2082.50s - 2087.44s |  into the field of AI security but they just aren't. So it's really important that all of the
2087.44s - 2091.42s |  cyber folk in the room are thinking about how to solve these sorts of problems in AI security
2091.42s - 2098.42s |  as well. Some of the um as I mentioned the the the interview with uh Casino Canberra was part
2098.46s - 2104.90s |  of um many of the interviews we've done and we we've got these interesting insights already.
2104.90s - 2111.20s |  Um 94 percent of the like people and organizations we spoke to could articulate how they use AI.
2111.20s - 2115.74s |  Um even if maybe it's not what everyone would define as AI they they had an idea of how they
2115.74s - 2120.92s |  use AI. Um but only 8 percent could articulate how they secure their AI and most of the time
2120.92s - 2126.22s |  it's never really considered at all. The other reason I wanted to use the Casino case study was
2126.26s - 2133.26s |  because a casino is a really good sort of analogy for a society that it's starting to um be built
2133.26s - 2139.40s |  around surveillance as well. Like casinos are built with surveillance in mind and societies
2139.40s - 2144.84s |  are increasingly sort of moving towards using more AI specifically facial recognition AI to do
2144.84s - 2149.84s |  important things as well. So the the the important thing to think about from like the the the
2156.58s - 2162.02s |  perspective of actually what you can do with the knowledge of these attacks is that even now in
2162.02s - 2167.02s |  the casino environment it's it's still entirely reliant on people and process. And especially as
2171.44s - 2175.94s |  organizations like casinos are going through this inflection point in adopting different AI
2175.94s - 2181.72s |  technologies. Um being able to actually like govern that and implement it well is still really
2181.72s - 2187.48s |  hard. And even though over here we have lots of very um you know technical and and mature
2187.48s - 2191.62s |  conversations about it most organizations aren't are out there are still really grappling with how
2191.62s - 2196.62s |  to do it. It's you know it's still so so reliant on having people to surveil it. And at the end
2200.10s - 2204.76s |  of the day you know I went into you know Casino Canberra I asked very nicely if I could you know
2204.76s - 2209.90s |  try hacking their things and they said yes. So what does it really mean? Um in terms of what
2209.92s - 2214.62s |  Casino Canberra was able to do with this it's it's tough because they're reliant on third party AI.
2214.62s - 2219.26s |  So all you can do is sort of ask the questions and hope that you know you keep it in mind. But
2219.26s - 2224.00s |  there we're really so reliant on these organizations that provide the AI and there's no
2224.00s - 2228.64s |  regulation around how they have to actually secure them or make sure that they're robust. So it's
2228.64s - 2233.64s |  really challenging but at least being able to ask the question um it sort of helps. So um so
2234.02s - 2239.02s |  that's it. I am talking tomorrow as well um about my experience in the Australian government.
2241.66s - 2246.40s |  I worked at an intelligence agency so I'm also speaking in the policy village. Um I'm one of the
2246.40s - 2251.40s |  creative stages about um sort of the policy element of these AI security attacks as well. Um so
2253.90s - 2256.04s |  thank you so much for coming and please do keep in touch.


url: https://www.youtube.com/watch?v=lF8NEsl3-kQ
title: DEF CON 32 - Where’s the Money-Defeating ATM Disk Encryption - Matt Burch
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=lF8NEsl3-kQ",
  "title": "DEF CON 32 - Where\u2019s the Money-Defeating ATM Disk Encryption - Matt Burch",
  "description": "Holding upwards of $400,000, ATMs continue to be a target of opportunity and have seen over a 600% increase in crime in just the last few years. During this time, I led security research with another colleague into the enterprise ATM industry resulting in the discovery of 6 zero-day vulnerabilities affecting Diebold Nixdorf\u2019s Vynamic Security Suite (VSS), the most prolific ATM security solution in the market. 10 minutes or less is all that a malicious actor would need to gain full control of any system running VSS via offline code injection and decryption of the primary Windows OS. Diebold Nixdorf is one of three major North American enterprise class ATM manufacturers with a global presence in the financial, casino/gaming, and point-of-sale markets. Similar attack surfaces are currently being used in the wild and impact millions of systems across the globe. Furthermore, VSS is known to be present throughout the US gaming industry, including most of the ATM/cash-out systems across Vegas.\n\nIn this session, I will publicly disclose this research, review the discovery process, and dive into the technical intricacies of each vulnerability. The Full Disk Encryption module of VSS conducts a complex integrity validation process to ensure a trusted system state, performed as a layered approach during system initialization. Examination of the workflow will highlight various deficiencies that I will demonstrate through PoC exploitation.\n\nEach vulnerability presented in this session has been observed to have a recursive impact across all major versions of VSS and represents a systemic ongoing risk. We will explore the root-cause, vendor remediation steps, and short-comings thereof \u2013 perpetuating the attack narrative. In conclusion, proper mitigation techniques and procedures will be covered, providing valuable insights into defending against potential compromise.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2313,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.11s - 6.81s | This text was transcribed using whisper model: large-v2

 Over the past several years, this content has been both a passion and an obsession of mine
6.81s - 11.35s |  that has led me down some very interesting paths.
11.35s - 17.11s |  And I am very honored and privileged to be able to finally do public disclosure
17.11s - 25.14s |  of this content here today.
25.14s - 30.44s |  So, my name is Matt Birch, and I am an independent security researcher
30.44s - 33.44s |  with a passion for IoT and hardware devices.
33.46s - 39.10s |  I have developed several MFA bypass tools affecting various MDM solutions.
39.10s - 43.54s |  I have performed expert opinion against a major ATM manufacturer,
43.54s - 51.65s |  and I have had the opportunity of examining cartel-designed ATM black box devices.
51.65s - 55.93s |  For today's agenda, we'll take a brief look at the ATM industry,
55.93s - 60.65s |  and then we'll introduce Diebold Nixdorf's dynamic security suite.
60.65s - 64.45s |  We'll then dive a little bit deeper into the pre-boot authentication process
64.45s - 70.65s |  implemented within that software, and finally wrap up with a little bit of cat and mouse.
70.65s - 75.33s |  So, starting off, let's take a look at the industry.
75.33s - 79.73s |  The ATM market is essentially divided into two classes of systems.
79.73s - 84.77s |  You have consumer-grade platforms, and these are the standalone units you typically see
84.77s - 90.61s |  in your local grocer or at the gas station, pretty much all over the place in the market.
90.61s - 95.57s |  These devices usually run Windows CE and lack a lot of the enterprise security controls
95.57s - 98.41s |  that you typically see within your corporate environment.
98.41s - 104.25s |  On the other hand, the financial-class systems are the enterprise-class ATMs.
104.25s - 108.97s |  These are the ones that are specifically located at your banking institution,
108.97s - 115.37s |  and they're represented as the larger standalone units or the through-wall devices.
115.37s - 119.25s |  These are equipped with Windows Embedded 10.
119.25s - 122.13s |  Some of the newer models are starting to introduce 11,
122.13s - 126.09s |  and each manufacturer has their own proprietary security stack,
126.09s - 130.89s |  offering various endpoint detection and full-disk encryption.
130.89s - 137.29s |  Here in the States, there are only three major financial institution ATM manufacturers,
137.29s - 144.40s |  and those are Hyosung, NCR, and Diebold Nixdorf.
144.40s - 150.24s |  So, opening up an ATM, the system is essentially divided into two hemispheres.
150.24s - 153.36s |  You have the top portion, or the top hat.
153.36s - 157.76s |  This contains all the PC peripherals and components of the device,
157.76s - 164.96s |  and then the bottom portion, aka the vault, carrying the cash cassettes and all the system's currency.
164.96s - 169.72s |  Each component of the ATM is physically isolated from each other,
169.72s - 175.32s |  but the physical security controls between those hemispheres vary drastically.
175.32s - 179.84s |  The bottom portion of the ATM is equipped with multi-factor authentication,
179.84s - 186.28s |  usually implemented with a digital combination lock and an I button for authorization verification.
186.28s - 191.80s |  It's designed to have about one inch thick steel, has a very heavy bolt locking mechanism,
191.80s - 197.24s |  and will be equipped with seismic detectors or tamper detection to indicate of any malicious entry.
197.24s - 203.28s |  However, in contrast to that, you have the top hat of the ATM,
203.28s - 206.84s |  and this only has about one-eighth inch thick steel.
206.84s - 212.68s |  It is equipped with numerous vent holes for PC ventilation, airflow,
212.68s - 217.88s |  comes with default tubular locks that you can actually pick up pretty easily online,
217.88s - 221.92s |  and the locking mechanism is a cantilever-style lock
221.92s - 225.92s |  that's activated from a cable that's hooked up to the cylinder of the lock.
225.92s - 230.68s |  Because of the plastic components that are usually presented in the front of the ATM,
230.68s - 234.68s |  it's very easy to get access to the locking mechanism via destructive entry
234.68s - 240.21s |  or just shoving a coat hanger in through a PC speaker.
240.21s - 244.73s |  So, when we start taking a look at the attack factors affecting these platforms,
244.73s - 251.09s |  there's one thing in common. Most of the attack factors require some level of physical access to the device.
251.09s - 255.77s |  Uh, some of the most common attacks that we see are black box devices.
255.77s - 260.01s |  Uh, and these are small little units that are placed inside or outside the ATM
260.01s - 268.49s |  with the goal of manipulating, uh, dispense requests and, uh, simulating the ATM hosting network.
268.49s - 272.77s |  We are all familiar with card skimmers. Uh, they attach to the front of the ATM.
272.77s - 280.29s |  They're designed to steal your card data. Uh, and then there's the significant physical attacks, uh, RAM raiding.
280.29s - 283.69s |  Really awesome, you wrap a chain around an ATM, hook it up to your Ford pickup,
283.69s - 285.69s |  and just rip it right out of the ground.
285.69s - 290.29s |  Or you just borrow your local construction company equipment and bust a hole right through the wall.
290.29s - 296.21s |  Uh, some of the less common attacks, though, that we see here in the States are explosive attacks against the ATMs
296.21s - 301.81s |  because our currency, uh, is mostly paper derived and when you ignite it, it tends to catch on fire.
301.81s - 304.37s |  So, it's very counterproductive to do that attack.
304.37s - 308.41s |  However, internationally, where there's a higher plastic consistency of the money,
308.41s - 310.97s |  uh, you do see a lot more explosive attacks.
310.97s - 318.77s |  Uh, and they actually have started designing explosive proof ATMs to prevent this attack procedure.
318.77s - 329.29s |  So, looking at the landscape, the ATM market is full of thousands of devices, all of which hold very large sums of cash.
329.29s - 336.93s |  And despite the need of physical access, criminal activity has exponentially grown over just the last several years.
336.93s - 344.73s |  But the logical infrastructure, uh, within these platforms provides little resistance against a logical attack.
344.73s - 353.05s |  The foundation of how the ATM works relies on an unauthenticated API known as Extension for Financial Services, or XFS.
353.05s - 361.65s |  This is the abstraction layer between the software and the hardware allowing vendor agnostic, uh, cash cassettes to be installed in the ATM.
361.65s - 367.85s |  Additionally, most of the software on these ATM platforms all run in the context of high privilege
367.85s - 377.61s |  and systems are designed with layers of default credentials to get into operator mode, system administration, and various other functions of the ATM.
377.61s - 383.93s |  As a result, these devices have become a very lucrative target for organized crime.
383.93s - 390.41s |  So, we can't really talk about ATMs without briefly discussing the network in which they work.
390.41s - 396.93s |  In order for you to free your money from the bank, the ATM needs to be connected to the ATM network,
396.93s - 403.69s |  uh, which is essentially a private network that's controlled through the hosting provider or gatekeeper.
403.69s - 409.41s |  However, not all systems are provided access to the network and there's a specific certification approach
409.41s - 415.81s |  where only certain pieces of software and hardware combinations are allowed access to the ATM network.
415.81s - 421.41s |  So, in an environment or a financial institution that has ATMs across various vendors,
421.41s - 428.33s |  administration of that platform can be very difficult, uh, because it's different software, different patch levels,
428.33s - 435.53s |  which usually results in banking institutions working with a managed service provider.
435.53s - 442.09s |  This all brings us to Diebold Nixdorf and their proprietary Dynamic Security Suite software.
442.09s - 449.93s |  Unlike the other ATM security stacks, Dynamic, or Diebold, has multi-vendor certification,
449.93s - 457.81s |  allowing their software to be installed on any ATM hardware platform and gain access to the ATM network.
457.81s - 463.73s |  In 2015, they were assumed to represent about 35% of the ATM market.
463.73s - 472.61s |  And in 2018 and 19, they partnered with two of the largest financial institutions representing the U.S. gaming industry.
472.61s - 479.29s |  AKA, Dynamic Security is present in almost every casino across the United States,
479.29s - 485.97s |  if not most or all of the casinos right here in the Vegas Strip.
485.97s - 491.93s |  So, now that we have a little brief background of what the network looks like,
491.93s - 495.29s |  let's introduce Dynamic Security.
495.29s - 499.17s |  So, like all security stacks, it comes with a number of security features.
499.17s - 506.81s |  Uh, you get USB filtering, firewall policy, tamper detection, delegated access, and then it also does disk encryption.
506.81s - 513.09s |  But, it's not really full disk encryption, uh, and there's two unencrypted partitions on the disk.
513.09s - 520.01s |  The standard partition is UEFI, and this isn't, uh, pretty common in most enterprise configurations.
520.01s - 526.77s |  But, what isn't common is an unencrypted Linux partition, and that's somewhat of a red herring.
526.77s - 534.73s |  Uh, initially investigating what that Linux partition is, it self-identifies itself as Super's Chaff.
534.73s - 542.13s |  And online reconnaissance against that doesn't actually result in much information being identified.
542.13s - 546.41s |  But, it does lead us to a very interesting game known as Worms Armageddon.
546.41s - 550.57s |  In Worms Armageddon, you launch sheep as mobile projectiles against your enemy.
550.57s - 555.17s |  The game's really fun. I think we wasted several minutes playing the game once we identified it.
555.17s - 559.45s |  But, unfortunately, it has absolutely nothing to do at all with ATMs.
559.45s - 570.69s |  But, what it did do is help us identify what Super's Chaff was actually a German translation for Super Sheep.
570.69s - 579.69s |  And, Super Sheep actually is the install directory located in user that contains most of the system binaries.
579.69s - 586.89s |  Interestingly enough, this resulted in much more information from OSINT Discovery.
586.89s - 592.61s |  Specifically, in 2016, a consulting firm known as SecConsult wrote a blog article
592.61s - 598.21s |  detailing a code execution vulnerability in a piece of software known as Cryptware CryptoPro.
598.21s - 602.45s |  And, the underlying Super Sheep Linux operating system.
602.45s - 607.85s |  In the article, there were several similarities between the Vynamic Security Linux operating system
607.85s - 614.69s |  and that of Super Sheep, leading us to go back and look at DeepWorld's user license agreements.
614.69s - 621.85s |  Specifically, identifying Cryptware CryptoPro as a third-party integrator as part of Vynamic Security.
621.89s - 629.85s |  However, that third-party integration was only mentioned once in version 3.0.
629.85s - 638.53s |  Versions 4.0, 4.1, 4.2, 4.3 all remove any reference to the integration of Cryptware CryptoPro.
638.53s - 641.73s |  So, who is Cryptware CryptoPro?
641.73s - 648.89s |  It's a cryptographic spinoff started in 2002 with the objective of enhancing Microsoft BitLocker functionality.
648.89s - 653.45s |  Specifically, by introducing a pre-boot authentication process.
653.45s - 663.21s |  Today, the organization exists across numerous countries and drastically different domain and website presence.
663.21s - 670.73s |  Each website has a significantly different representation of the content than any of the other websites put together.
670.73s - 676.21s |  However, despite the suspicious online presence, they boast over half a million licenses sold
676.21s - 681.53s |  and advertise that employees love their encryption, so it's gotta be good, right?
681.53s - 687.89s |  So, let's dive a little bit deeper into the pre-boot authentication process.
687.89s - 692.61s |  So, Vynamic Security essentially uses a dual-boot operating system.
692.61s - 699.05s |  From UEFI, it launches a Super Sheep Linux operating system, which performs some magic against the desk.
699.05s - 702.65s |  It then shuts down, goes back through UEFI and launches Windows.
702.65s - 710.93s |  Windows will perform an auto-logon and then initiate or launch all the ATM software, bringing the system operational.
710.93s - 717.33s |  Any attempts to modify the content on a Linux partition result in an integrity error.
717.33s - 719.93s |  However, not all files on the system are treated the same.
719.93s - 725.73s |  Modifying different file content or directories results in a significantly different error message to be presented.
725.73s - 729.57s |  However, this one provides a little bit more detail.
729.57s - 734.85s |  Designating about 253 elements are validated on the desk, which is interesting.
734.85s - 738.29s |  I wonder what those elements are.
738.29s - 749.33s |  So, we go back to the Linux partition and look to identify any directory contents that may contain a SHA index or representation of what's validated.
749.33s - 751.73s |  We stumbled across the log directory.
751.73s - 758.37s |  Inside the directory, there was content evaluating about 2,500 files on the desk.
758.37s - 763.01s |  The full Linux operating system had slightly under 11,000 files.
763.01s - 767.97s |  This gave us a delta of about 8,000 files, which are potentially not validated.
767.97s - 779.09s |  Although drastically more than 253, evaluating 8,000 files and determining whether or not they have any impact against the boot-up sequence is a rather daunting process.
779.09s - 783.61s |  So, I prefer to step back and then take a look at background images.
783.61s - 785.13s |  Those are really easy to modify.
785.13s - 786.45s |  They're very representative.
786.45s - 789.01s |  If there's any impact against the system.
789.01s - 793.93s |  So, randomly pick an image, shut down and reboot.
793.93s - 798.81s |  Although unfortunately, when the system powers back up, the default background is presented.
798.81s - 803.73s |  However, after just a few seconds later, we did get our hacked image.
803.73s - 809.45s |  Specifically indicating that the pre-boot authentication process is not completely infallible.
809.49s - 817.93s |  And there is a way to take advantage of the pre-boot authentication process and maliciously execute something.
817.93s - 829.81s |  Ultimately, using the modified background image and modifying content within the Linux partition, we're able to map out the different phases of the pre-boot authentication process.
829.81s - 839.93s |  The 253 elements are validated in UEFI during BIOS initialization in the boot XSA or boot XSA2 system binaries.
839.93s - 850.25s |  Upon completing that validation check, Linux is then initialized, doing the rest of the validation of the other 2,500 files.
850.25s - 856.05s |  Those 2,500 files are then used to unlock the TPM and recover the disk encryption key.
856.05s - 866.89s |  Unfortunately, ATMs are equipped with secure boot and the ability to modify boot XSA or boot XSA2 within UEFI is not possible.
866.89s - 874.37s |  Because all the UEFI binaries are digitally signed and that signature is associated to the BIOS.
874.37s - 882.61s |  So, in order to take advantage of the system, we need to specifically map out what files are validated as part of phase one.
882.61s - 896.79s |  And then look to identify anything that's not checked but may allow uh redirection of the execution workflow in Linux before phase two is initiated.
896.79s - 901.97s |  Fair enough. Challenge accepted. Let's play cat and mouse.
901.97s - 911.97s |  We'll start off in version 18.x. So, version 18.x, the PBA authentication process scans about 253 elements on the disk.
911.97s - 922.25s |  This is executed out of boot XSA2. Upon completing that process, Linux is bootstrapped through the system V architecture and several RC initialization scripts.
922.25s - 929.01s |  After which, root performs an auto logon and phase two is initiated from root's profile script.
929.01s - 935.93s |  Phase two then scans the other 2,500 files, ultimately unlocking the TPM.
935.93s - 941.17s |  The run state of Linux operating system is designed through several temporary file systems.
941.17s - 946.05s |  And these are designed to give the system a somewhat pseudo read only perspective.
946.05s - 961.65s |  Uh, those temporary file systems are then populated from several tar archives, which unfortunately are validated during phase one.
961.65s - 980.05s |  So, there isn't much of, so there isn't much of an ability to modify that content because they are validated during the phase one initialization process.
980.05s - 992.17s |  Ultimately, in order to identify the attack surface, we take our phase one integrity index and then we examine that against the full system V initialization architecture.
992.17s - 1001.29s |  Look to identify any RC scripts or other ancillary scripts that are pulled in during the boot up sequence, but aren't validated during phase one.
1001.29s - 1012.05s |  Unfortunately, going through this process, most of the RC initialization scripts, the whole architecture, uh, is relatively locked down and there isn't much of an attack surface.
1012.05s - 1021.21s |  However, taking a step back, there was one file that was overlooked. Etsy init tab.
1021.21s - 1030.37s |  By having control over Etsy init tab and it not being validated during phase one, we have the ability to now gain a foothold in the architecture.
1030.37s - 1040.05s |  However, we still need a staging directory. Like any good security solution, SuperSheep doesn't scan its own installation files.
1040.05s - 1048.23s |  And since our objective is code execution on the ATM, what better staging directory to use than SuperSheep Avira?
1048.23s - 1058.67s |  So, all we need to do is clone the RC initialization script over to our safe directory, patch global variables, inject our POC into X,
1058.67s - 1073.91s |  and then call our new run level three from Etsy initialization. With that, I have a small demo for CVE-2023-24064.
1073.91s - 1082.29s |  Inside this demo, uh, the dynamic security is virtualized. Initially powering on the system, we receive the integrity error.
1082.29s - 1091.33s |  Shutting down the system, patching the disk, moving the RC initialization process, then gives us the ability to obtain code execution on the platform.
1091.33s - 1112.26s |  Once we power the system back up, root will perform an auto log on, will receive, will gain code execution, and receive our callback shell.
1112.26s - 1128.97s |  There we go. We have control of Linux. Although, vanilla code execution isn't enough. So what? We're on Linux. Windows is still encrypted.
1128.97s - 1137.01s |  How are we gonna go from Linux to Windows? Luckily, SuperSheep has an app for that. Mount Winpart.
1137.01s - 1148.79s |  Mount Winpart, as a command line argument, takes the TPM disk encryption key, decrypts Windows, and initializes a third phase of the integrity validation check.
1148.79s - 1165.07s |  That, so, all we need to do to gain that key, is restart the integrity check, and monitor proc command line. Doing so, after a few seconds, we get our TPM disk encryption key,
1165.07s - 1183.81s |  we're able to decrypt Windows, from here, we can install malware, directly interacting with the XFS API, and dispense money out of the ATM on demand.
1183.81s - 1192.11s |  Alright, let's talk about timeline. This vulnerability was observed to only impact version 18 of the dynamic security suite.
1192.11s - 1201.59s |  Uh, vulnerability was identified December of 21, and then confirmed remediated just a few days later when we looked at the next major release of dynamic security.
1201.59s - 1215.49s |  It's somewhat misleading, uh, because from version 18 to version 3.0, D-Build actually changed the version strategy to introduce minor versioning, restarting the number from, from 3, uh, 3.3.
1215.49s - 1229.21s |  So, the next major supported release actually was 3.0. So, inside this, the way that they patched the attack surface, is scinit-tab is now validated as part of phase 1.
1229.21s - 1242.75s |  No longer able to manipulate the system that way. However, interestingly enough, the phase 1 integrity check is now reduced by 20%, going from 253 elements to only 56.
1242.75s - 1256.42s |  Okay? Reporting this to D-Build, they had indicated that this is not a security vulnerability, because of the superior protections of IMA. Okay, what's IMA?
1256.44s - 1272.02s |  IMA is a kernel signature verification check where all binaries on the system are digitally signed along with the kernel. That digital signature is applied as an extended attribute to each file, validating the file name, file path, and various details about the I-known.
1272.02s - 1284.66s |  The kernel then validates the parent-child process of any executable, determining whether or not it's actually allowed to execute. However, what IMA doesn't do, is it doesn't validate script interpretation.
1284.66s - 1307.82s |  For example, your, uh, bench shell is certified and allowed to execute, needed to run the Linux architecture, but then it, when it interprets a file such as profile, it goes through and performs all, any execution commands within that interpreted script in the context of a certified binary.
1307.82s - 1329.90s |  Let's continue with service release 9. So, in service release 9, the Linux architecture is relatively unchanged from what was pre-release, previously discussed. But, reviewing the mountfs initialization script, we're able to identify mtab is deleted before the mount command is called.
1329.90s - 1357.82s |  So, since there's a delete call before the mount command, and the security architecture of the system is based around temporary file systems, which are executed from fstab, we just replace mtab with fstab. Fstab gets deleted before the mount command is called, giving us persistence to root's home directory, allowing us to patch the profile script, and again, obtain code execution.
1357.82s - 1395.66s |  With that, here is CVE-2023-24063. Inside this demo, we patch the offline desk, and we relocate fstab to mtab, powering back on the virtual system. Once root performs its auto logon activity, we'll receive code execution, and our callback shell. There we go. Again, we have control of the Linux architecture.
1395.66s - 1425.02s |  So, let's go back to timeline. This vulnerability was observed to impact all prior versions of 3.3.0. Vulnerability was identified in June of 2022, and then confirmed or mediated the following day, magically, preemptively, in service release 10. In service release 10, the delete call to mtab is now removed from the mountfs initialization script, removing the opportunity to delete fstab before the temporary file systems are initialized.
1426.34s - 1450.54s |  Alright, let's dive a little bit deeper into service release 10. So, service release 10, init-tab is validated, mtab does nothing, but what about the mount logic? So, mount is used to actually build a temporary file system architecture, but there's one interesting limitation with mount. The default behavior of mount is if you call
1450.54s - 1456.88s |  mount against a mount point that's previously mounted, the call to mount will fail. And
1456.88s - 1461.98s |  what's the default mount point associated with any Linux file system? The root file
1461.98s - 1467.86s |  system. So if we flatten the file system and re-associate our critical mount points to
1467.86s - 1473.40s |  that of root, we're able to regain persistence to root's home directory, patch the profile
1473.50s - 1478.50s |  script, and then again obtain code execution. Here's CVE 2023-24062. Inside this demo, again,
1486.39s - 1491.55s |  we patch the offline disk, we flatten the file system, uh gain persistence to root's home
1491.55s - 1496.97s |  directory and power back on the virtual system. Once root performs its auto logon, we'll
1496.97s - 1518.83s |  receive code execution and again our callback shell. Taking a look at the timeline here, it's
1518.83s - 1524.17s |  a little bit different. So once again, all prior versions of 3.3.0 were made vulnerable to
1524.17s - 1529.17s |  this attack surface, but now we have a patch for version 4.0, 4.1, and 4.2. Representing at
1531.47s - 1538.05s |  the point in time, the entire software release of dynamic security. The vulnerability was
1538.05s - 1544.35s |  identified in June of 2022 and I confirmed remediation in December of 22 as part of
1544.37s - 1550.74s |  service release 12. In service release 12, MountFS is updated again. This time, adding several
1554.06s - 1560.06s |  delete calls to remove root temp var amount and then recreate those directories. This
1560.06s - 1565.80s |  essentially removes any sim links that we've defined or any other uh persistent content
1565.80s - 1572.24s |  that we may have placed on that disk. Fair enough. Let's look at service release 12. So, in
1573.24s - 1578.24s |  service release 12, how do you work around a delete call? Well, interestingly enough, there's
1583.08s - 1588.08s |  still some black magic amount. Specifically, the uh kernel extension mount points are
1589.88s - 1596.62s |  initialized earlier in the initialization process. And what's interesting about this is when
1596.62s - 1601.42s |  you place a file in a mount point, once the mount point is mounted, the content is no longer
1601.44s - 1608.44s |  accessible. Since all the previous mitigation checks were implemented within MountFS, why
1608.44s - 1614.46s |  don't we just move MountFS to proc? Then once the kernel initializes, the file is no longer
1614.46s - 1620.82s |  accessible, it doesn't delete our root directory and we again, regain persistence to root, patch
1620.82s - 1625.84s |  the profile script, and gain code execution. Here's CVE 2023-28865. Inside this demo, again,
1626.30s - 1632.74s |  we patch the offline disk, relocate MountFS to proc, power back on the virtualized system. Once
1639.18s - 1665.05s |  root performs its auto logon, we again, gain code execution. Just as before, this vulnerability
1667.39s - 1672.39s |  impacted all prior versions of 330. In addition, also required new patches for 4.0, 4.1, and
1672.71s - 1677.71s |  4.2. Also representing the entire security stack of dynamic security. The vulnerability was
1682.29s - 1687.29s |  identified in December of 2022 and then confirmed remediated in February of 23 as part of
1689.93s - 1694.93s |  service release 15. Service release 15 is a slightly more complex remediation strategy. This
1694.95s - 1699.95s |  time, phase one integrity checks are expanded to include a number of null sum indexes
1704.75s - 1710.59s |  against critical mount points. This essentially confirms the content in those mount points has
1710.59s - 1715.63s |  not been modified and those directories are truly empty before Linux is allowed to
1715.63s - 1724.60s |  initialize. Let's look at service release 15. So, in service release 15, I like to fall back on
1724.98s - 1729.98s |  the idea that the more complicated a security control is, the more likely something is going to
1736.66s - 1741.66s |  be overlooked. However, in order to identify those barriers, we need to first understand how
1744.00s - 1749.00s |  that security control is implemented. So, if we create a file or we create a SIM link to a known
1749.60s - 1754.60s |  file, it produces a hash sum as part of the phase one integrity check and the system fails to
1756.54s - 1761.54s |  boot. However, if we create a directory or a tree of empty directories, no sum value is
1762.98s - 1767.98s |  created and the system boots successfully. Interestingly enough, null SIM links also
1772.06s - 1778.37s |  produce a null sum value. In order to take advantage of that, we need to return, uh, and
1779.37s - 1784.37s |  identify a new staging directory that allows us to establish a transversal point, uh, with a
1788.71s - 1793.61s |  directory path that doesn't previously exist. In order to identify one, we return to our
1793.61s - 1799.75s |  previous attack surface and look at what directory structures are created once the Linux
1799.75s - 1804.75s |  kernel is initialized that may not actually exist in the offline desk. Allowing the creation
1805.25s - 1810.25s |  of a transversal SIM link that will represent as a broken link on the offline desk during
1812.95s - 1817.95s |  phase one integrity, but then becomes valid once Linux is launched, allowing us to redirect and
1819.13s - 1824.13s |  gain access to our new root location. Luckily after just a few seconds, it wasn't hard to
1826.17s - 1831.17s |  find dev block, which is actually a special mount point, routing or mounting the block device
1831.19s - 1836.19s |  of the system itself. Uh, this special mount point was also observed to exist, uh, be
1840.17s - 1845.77s |  contained in all prior versions of dynamic security, also giving some persistence against the
1845.77s - 1850.77s |  other versions of software. So, we just move our mount points to the, uh, secondary mount
1853.45s - 1858.45s |  points, VAR to VAR2, ROOT to ROOT2, and we SIM link to those via dev block. Offline desk
1859.11s - 1864.11s |  link is broken, no SIMs are created, Linux powers up, links are valid, we get access to ROOT's
1866.95s - 1871.95s |  home directory. Here's CVE-2023-33206. Again, the offline desk is patched, we relocate to
1879.76s - 1885.76s |  our new mount points and establish the transversal SIM link. Powering back on the system,
1885.78s - 1891.18s |  ROOT's gonna perform it's auto logon, we'll receive code execution and again, our callback
1891.18s - 1913.78s |  shell. So, at this point, I kinda feel like I've been here before. All prior versions of
1913.78s - 1918.78s |  3.3.0 were vulnerable to this, including 4.0, 4.1, 4.2, and 4.3. Again, the entire dynamic
1920.58s - 1926.22s |  security stack. The vulnerability was identified in April of 23, and then confirmed
1926.22s - 1931.22s |  remediated in July of 23 as service release 16. In service release 16, the vulnerability
1934.26s - 1939.26s |  release 16, the PBA phase one process now validates the integrity of SIM links. So, if
1941.94s - 1947.04s |  there's a broken SIM link, the PBA integrity process will fail and the system doesn't boot
1947.04s - 1952.04s |  up. However, what's also interesting are the prior, prior mitigation strategy of deleting
1954.98s - 1960.56s |  the directories or the mount points in the ROOT or in the mount FS initialization script
1960.56s - 1965.04s |  are now commented out and removed. Unfortunately, this didn't seem to reproduce the
1965.04s - 1970.54s |  attack surface because we have null sum checks and SIM link validation as part of phase
1970.54s - 1975.54s |  one. But it is an interesting approach to back out previous, uh, remediation strategy. With
1979.57s - 1986.36s |  that, let's look at service release 16. So, service release 16. SIM link validation, null
1986.56s - 1991.56s |  sums, bummer, that's pretty good security control. However, the entire integrity process of
1998.70s - 2003.70s |  the system is based on the need to create hash sums and hash sum validation of files. You
2007.28s - 2012.28s |  know what doesn't change the hash sum of a file? It's file attributes. So, for example, if we
2013.28s - 2018.28s |  remove execute permissions from something, it has the same hash sum value. So, if we just
2022.57s - 2027.77s |  remove the execute permissions of IMA, we disable the entire security architecture of
2027.77s - 2032.77s |  dynamic security and have the ability to execute any unsigned binary we want. Here's CVE
2038.48s - 2045.27s |  2023-40261. In this demo, we remove execute permissions from IMA, gaining the ability to
2046.19s - 2051.19s |  execute anything that we want, power back on the system, root performs its auto log on, and we
2055.41s - 2077.91s |  receive our callback shell. Alright, just as before, the entire security stack of dynamic
2080.41s - 2085.41s |  security is vulnerable to this attack surface. All prior versions of 330, all prior versions
2086.99s - 2091.99s |  of 4.0, all prior versions of 4.1, all prior versions of 4.2, and all prior versions of 4.1
2093.75s - 2099.49s |  and all prior versions of 4.3. The vulnerability was identified in July of 2023, and I've been
2099.49s - 2104.51s |  informed from dbold that this was mitigated as part of the November 2023 release of service
2107.27s - 2112.27s |  release 17. Additionally, version 3.3 was designated to be end of life at the end of December
2112.27s - 2117.29s |  uh 23. So with that, do you need defense? Well, during the content of this talk, I've been
2128.06s - 2134.00s |  able to demonstrate impact of the entire dynamic security suite and their hard drive
2134.00s - 2139.00s |  encryption model. I've also identified that the attack surface is recursive, where new
2139.60s - 2144.60s |  versions of the patch system are recursively vulnerable against, against those attacks. Um, but
2150.98s - 2156.16s |  it's all based around the root cause of the Linux file system being unencrypted. So
2156.16s - 2161.26s |  technically, it's a continuous cat and mouse game to defend against this attack surface, and
2161.26s - 2166.26s |  there are likely going to be new attacks. But, you can rest assured, because physical access is
2166.36s - 2171.36s |  required to take advantage. So, let's discuss some mitigation strategies. First and foremost,
2177.54s - 2182.54s |  the dynamic security platform should be patched up to the latest release of any uh of the
2185.44s - 2190.44s |  major service releases that have been discussed here. In addition, I am very proud to announce
2191.44s - 2196.44s |  that this security research has directly influenced Diebold Nixdorf to redesign the SuperSheep
2201.54s - 2207.92s |  architecture, and as of April this year, they have released version 4.4 that is supposed to
2207.92s - 2216.50s |  offer full encryption of the SuperSheep operating system. In addition, there is a security
2216.50s - 2221.50s |  configuration check known as enable security check. If this is disabled in the dynamic
2229.94s - 2234.94s |  security configuration, also first introduced in version 4.0 of the software, this disables
2237.74s - 2244.12s |  the TPM key from being sent to mount winpart. Without that TPM key being sent as a command
2244.14s - 2249.88s |  line argument, it does significantly reduce the attack surface. Because from just the Linux
2249.88s - 2254.16s |  operating system itself, there is not much of an advantage point to attack the Windows
2254.16s - 2259.76s |  operating system. Additionally, you can just choose to replace dynamic security with an
2259.76s - 2264.76s |  industry recognized disk encryption solution, such as Microsoft BitLocker. Um, there are
2267.76s - 2273.84s |  also a number of secondary actions. Uh, ensure the top hat entry is properly monitor-
2274.80s - 2280.30s |  uh, any malicious entry to that system should be, uh, triggered as an alert. Disable all
2280.30s - 2285.30s |  unused USB ports, ensure the USB ports validate what peripherals are connected, and lock the
2287.08s - 2293.02s |  hard drive screws. There is no business justification for a hard drive on an ATM to be
2293.02s - 2299.26s |  removed without having to completely pull out the chassis. That should significantly reduce
2299.28s - 2304.28s |  the attack surface. With that, I'd like to thank all of you for, uh, coming here today and, uh,
2307.72s - 2308.72s |  listening to this content.


url: https://www.youtube.com/watch?v=vad7FiHlgMU
title: DEF CON 32 - Welcome to DEF CON 32 - The Dark Tangent
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=vad7FiHlgMU",
  "title": "DEF CON 32 - Welcome to DEF CON 32 - The Dark Tangent",
  "description": "Opening remarks from our founder The Dark Tangent.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 1216,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.21s - 5.21s | This text was transcribed using whisper model: large-v2

 just a it's what I'm trying to get at is at the end of it when you boil down DEF CON it's
5.21s - 10.45s |  community. Sense of community. People want to see each other, people want to talk to each
10.45s - 14.69s |  other, they want to share experiences and if they don't have to walk to three or four
14.69s - 23.50s |  different hotels that's awesome. So okay so I want to sort of officially start this off. I'm
26.40s - 31.42s |  dark tangent um I started DEF CON 32 years ago and over the decades it has grown and grown and
34.42s - 37.82s |  and uh and so I'm just going to give you a couple little insights that I've picked up along
37.82s - 42.82s |  the way and then send you off into the stream of the con. We have fantastic speakers, we have
45.36s - 49.30s |  great creators and I'm just going to try to orient you a little bit about kind of what's
49.30s - 54.30s |  going on. Um something you'll hear frequently is that the con is what you make of it and the
56.74s - 62.38s |  thinking here is that there's an unlimited number of things you could do. You can't do them
62.38s - 67.38s |  all. So please be okay with yourselves when you can't do it all. My big moment for this was I
70.48s - 75.48s |  think DEF CON 3 or so. DEF CON 1 I knew it all. I was there. I saw it. It was awesome. DEF CON
78.12s - 84.80s |  2 woo there's more people. This is great. DEF CON 3 after the con people are coming up to me
84.80s - 89.80s |  and saying that was great. Did you see the thing that happened? Like no I didn't see the thing.
92.50s - 99.18s |  It's my con. I didn't see the thing. It's like I'm missing out. DEF CON 4 rolls around you're
99.18s - 104.92s |  like okay I'm never seeing all the things. Like I just have to be okay with that. And then
104.92s - 109.62s |  when you make that mental shift then it's like well then I want to create more things I won't
109.62s - 115.52s |  see so I don't feel so guilty you know like I'll just be able to internalize that there's
115.52s - 120.56s |  absolutely no way in the world and then other fuckers they also will have stuff that they
120.58s - 126.12s |  don't see right and then we'll all be in the same boat together and it just kind of grew that
126.12s - 135.36s |  way. So then that's where the phrase came. It is what you make of it. If you want to be
135.36s - 142.38s |  social we try to create social experiences. If you want to be technical get at it. And so
142.38s - 146.98s |  what's going on there is let's say there's a thousand people and then years later there's
146.98s - 151.98s |  10,000 people 20,000 people. It's hard to be social with 20,000 people. So we have to figure
154.46s - 160.32s |  out a way to get you into smaller groups. So a lot of behind the scenes engineering is how to
160.32s - 166.30s |  break up large groups into sort of affinity groups, car hacking and then break that up into
166.30s - 171.70s |  like ODB hacking and now you're at a table with 10 other people doing the thing you're
171.70s - 175.34s |  interested in at that moment and now you can make friends if you're at a table with 8 or 10
175.34s - 181.68s |  people. You can do that physical security, lock picking, high security lock and now you're at a
181.68s - 188.00s |  table with 10 lock pickers. And so when people say there's too many people here it's like yes
188.00s - 192.34s |  we know that but we spend a lot of time trying to figure out how to get you to have more
192.34s - 197.18s |  personal experiences like the food court. You sit at a table. People will join you and they
197.18s - 207.18s |  will talk whether you like it or not. So that's part of it. Also we really try to instill this
207.22s - 212.16s |  thing of like ask questions. Maybe at DEF CON 1 there was a handful of people that knew how the
212.16s - 217.96s |  world worked. Not anymore. There's no way any of us can understand how any of this technology
217.96s - 225.76s |  works at any depth because the market forces have required specialisations in our careers.
225.76s - 231.72s |  You will be like 9 miles deep on some tech stack and the guy next to you has never fucking heard
231.72s - 239.42s |  of that tech stack because he's not in your area. He's in aerospace or in IOT or OT or something.
239.42s - 246.38s |  And so that's super cool because now you have licence to ask what you think are dumb questions.
246.38s - 253.30s |  So just ask questions. I'm not going to tell anybody if you ask me a dumb question. It's our
253.30s - 260.92s |  secret. And so now we're creating this environment. You get these individual experiences. You can
260.92s - 271.12s |  ask dumb questions. You can wear whatever you want. And we just want you to like so the origin
271.12s - 276.50s |  story I'm sure probably many of you have heard it but when I started DEF CON I couldn't go to
276.50s - 284.38s |  cons because they were all invite only. There was one con or two cons that weren't invite only.
284.38s - 290.84s |  No. Summer con was invite only. Ho ho con. So they were all named after seasons. Ho ho con was in
290.84s - 298.08s |  Christmas. Christmas con or Xmas con. Then there was pump con in Halloween. Summer had summer
298.08s - 304.34s |  con. And so we named DEF CON or I named DEF CON not after a season because I didn't like how that
304.34s - 311.46s |  locked me in and I wanted to make it not invite only because I had been excluded. So that meant I
311.46s - 317.00s |  had to let everybody attend. I couldn't limit it. And so that's the biggest fork in the road
317.00s - 323.54s |  that DEF CON ever had to make. Open or close. And since I'd been excluded by the open or closed
323.54s - 330.38s |  I made it open. Okay now you're open. How do you limit attendance? You can't limit attendance
330.38s - 337.95s |  because now you're rewarding type A personalities and I hate those fuckers because they get up
337.95s - 345.61s |  early. They go down their checklists. So I needed to be able to balance them out with the
345.61s - 353.15s |  type team type B. And so that's been one of our challenges right. As we grow we turned into
353.15s - 359.37s |  through those two forks in the road we became a reflection of the community. Right. If people
359.37s - 365.41s |  are complaining oh no there's too much aerospace this year. Sorry. That's the way the world's
365.45s - 371.03s |  going then. Those people decided to show up so that must mean something. It wasn't artificially
371.03s - 377.91s |  created. So sometimes when you look around you're like why are things the way they are. It's
377.91s - 388.57s |  largely the result of extrapolating some of these early decisions. One other thing I say is so I
388.69s - 397.69s |  was in college. Madonna had a documentary movie or something come out. And in it she's having
397.69s - 402.07s |  this camera follow her around everywhere. And some other celebrity wants to talk to her
402.07s - 407.77s |  privately and asks hey can you turn off the cameras. And she doesn't turn off the cameras
407.77s - 413.03s |  because she says well if it's not recorded does it even exist? Did it even happen? And it's a
413.03s - 419.15s |  famous other people have said this for years. But my first exposure to that quote was in this
419.15s - 424.77s |  Madonna documentary. And so I was like aha. I have to record the first DEF CON. Because
424.77s - 430.35s |  there's going to be people who wanted to come that didn't. So we audio record all the talks. And
430.35s - 433.89s |  now I'm trying to sell these talks. And they're in cassette tapes and I'm duping them in a
433.89s - 439.31s |  cassette tape duplicator. Not a hard drive duplicator. A cassette tape duplicator. And I'm
439.31s - 443.05s |  trying to sell these things. And I do that for about a year or two. And then the next DEF CON I
443.05s - 448.81s |  got another stack of tapes. But by the third DEF CON streaming has come along. We have real
448.81s - 454.55s |  streaming. I'm like oh yes. I am still selling these tapes. So I just encode everything and I put
454.55s - 460.71s |  it online. And I just give away the talks for free. So much less hassle. And now that became
460.71s - 470.21s |  the tradition. Just recorded and gave away all the content. Part of that was because again in
470.21s - 476.71s |  the early days there was limited access to information. There was no Google or Alta Vista. No
476.71s - 483.57s |  Amazon. No excuse me. You would spend half your energy trying to find the information. The
483.57s - 488.49s |  person that knew the answer. Another half trying to understand it. Nowadays the time for you to
488.49s - 495.07s |  reach the information is like I don't know a couple minutes. Doing a couple searches. Not the
495.07s - 500.99s |  case. And so to accelerate that in the early days we gave away all the content. Well then when we
500.99s - 507.19s |  started Black Hat, Black Hat gave away all the content. Now basically that's the norm. Every
507.19s - 514.07s |  conference at least in the hacking space gives away their content for free. And I like to say
514.07s - 520.77s |  that's a master. It's weird. It was not. It was because I was type B and lazy. I didn't want to
520.77s - 529.85s |  keep shipping those tapes. It's patched. I see it here. But I'm not getting it out of the actual
529.85s - 541.53s |  channel. I mean there's something cool being at the music concert and seeing the artist. But you
541.53s - 548.49s |  can also enjoy their music later. Same thing here. If you miss a talk you want to see, it's okay.
548.49s - 554.49s |  We'll release it. You just do what you want to do. Make a couple bullet points each day of what you
554.49s - 561.49s |  want to explore. If you get your two or three things done, victory. But don't feel bad. The other
561.49s - 572.95s |  thing is we are not an InfoSec event. We are not RSA. We are a hacking event. What does that
572.95s - 579.07s |  mean? It's one of the things the CFP review team does. It's basically our filter. When you submit
579.07s - 587.03s |  to DEF CON, one of the first questions that goes through our mind is, is this hacker? Is there a
587.03s - 593.91s |  sense of joy of discovery? Is there like a spontaneous aha moment that the speaker, the
593.91s - 598.37s |  presenter had? Oh, my gosh, that's how this chip really works? I would never have figured that
598.37s - 609.71s |  out. Unless I spilled vodka on it. And so we don't have attendees that work on Oracle million
609.75s - 618.05s |  dollar database servers. Who here has an Oracle million dollar database server? Nobody. So they
618.05s - 623.89s |  might at RSA or Black Hat. That's where they're working. Corporate environments have that stuff.
623.89s - 628.63s |  Not here. So the idea is if you're going to hear a talk, it should be with technology you can
628.63s - 632.89s |  download. The tools that people are talking about should be released. You should be able to hear
632.89s - 637.43s |  something and go and play with it. And so that means it limits our pool. We're not going to have
637.43s - 641.79s |  the cool super Oracle database hacking talk, but we'll have other cool talks that are also
641.79s - 650.87s |  accessible to you. So we start trying to choose content that is more hacker, that gives you an
650.87s - 657.51s |  idea how to think. And I had a friend, I might have told this story last year, I had a friend
657.51s - 663.41s |  that I asked him, hey, are you sending anybody to DEF CON or Black Hat this year? And he was
663.43s - 668.43s |  involved in a, let's say a part of the government that does stuff to people that don't like us. And
673.17s - 678.35s |  so I'm always curious like what his thought process is. And he said, well, no, I'm not sending
678.35s - 684.49s |  anybody to Black Hat, but I'm sending my team to DEF CON. It's like, well, that doesn't like, why
684.49s - 690.33s |  would you do that? He said, well, my guy's pretty good. I mean, they're really good. And it's
690.45s - 696.55s |  like polishing the edge of a knife, like you're honing it, sending it to Black Hat. Like they'll
696.55s - 701.45s |  get a little bit better technical skills, but I mean, hey, look, it's pretty fucking sharp. But I
701.45s - 706.43s |  send them to DEF CON to learn how to think, how to approach the problem, how to think
706.43s - 711.77s |  differently. That's more valuable to me now, right? They can sharpen their knives all day long
711.77s - 717.11s |  elsewhere. And when he said that to me, it was this aha moment because running the con, you're
717.11s - 722.53s |  very close to it. And you see all the problems. They're like in your face because everybody has
722.53s - 728.87s |  no problem telling me where all the problems are. And so I sometimes don't see the big picture.
728.87s - 734.33s |  But when somebody far away explains what they're seeing, it's like, okay, now that I understand
734.33s - 740.15s |  that, we'll do things to try to help you learn how to think differently. I mean, we were doing
740.15s - 745.25s |  that already, but it was never like up front and center. So that's super cool. And then the
745.25s - 750.79s |  final thing is we really try to support the community. That's why I said hacker. We're a
750.79s - 757.13s |  community. DEF CON is one part of the community. We've been around a long time. Maybe we're
757.13s - 760.93s |  one of the biggest cons in the community, but there are lots of communities with lots of
760.93s - 767.41s |  different like norms and behaviors. One of the things we like to do here is not stop. So we go
767.41s - 773.99s |  to 2 in the morning or so and we have music and we have all these entertainment performances.
773.99s - 778.83s |  And the hacking community is big enough. We have our own musical style, right? We've got
778.83s - 785.91s |  nerd core. And when you go to other countries or when we were doing, we did DEF CON in China
785.91s - 789.33s |  and Beijing for a couple of years. And I remember we get over there and we're like, yes, okay,
789.33s - 794.33s |  what's the music scene like in China and Beijing? Are you into rock? Is it jazz? Like what is it?
794.33s - 797.75s |  Like we've got to get people from the community. We've got to showcase people from the
797.75s - 802.89s |  community and have them play music at our parties. And they're like, oh, yes, okay, yeah, we'll
802.91s - 807.19s |  get music for the parties. I'm like, yeah, but who are they? What's the cool thing? It's like,
807.19s - 812.91s |  oh, no, we don't have that. What do you mean? It's like, well, there's nobody does that here.
812.91s - 821.91s |  Like there's no style or musical bands. Like, oh, no. What else does the community not do over
821.91s - 828.83s |  here? And so it's made me think like something is more unique here where people have created
828.87s - 835.87s |  musical genres around it. They've had enough space to express themselves to grow the community
835.87s - 841.45s |  in different ways. And a lot of the questions we got when we were in China, like a dude in a
841.45s - 846.83s |  giant fucking banana outfit would jump on stage and run around. And the Americans would be like,
846.83s - 852.63s |  oh, hey, banana guy. And they'd just keep going. And the Chinese people would be like, what the
852.63s - 858.05s |  hell is going on here? There's a banana on the stage. Does that mean something? And they're
858.05s - 862.99s |  looking in the program. It's like, when the banana shows up, am I supposed to do something?
862.99s - 869.03s |  It's like, no, that's just the banana guy. And we were trying to inject a certain amount of
869.03s - 876.17s |  weirdness. And it didn't go so well because they're not programmed for weird. You know, like
876.17s - 881.01s |  the question they would get is like, okay, there's a scavenger hunt. Now, what do I get? Like,
881.01s - 887.75s |  why would I do that? Why would I invest 8.2 minutes of my energy into that if it doesn't help
887.75s - 891.95s |  my career? So, well, yeah, it's not going to help your career, but you're probably going to have
891.95s - 900.29s |  fun doing it. And you can see them like really working through that. And so, the hacker spirit
900.29s - 904.33s |  and the mentality I think is universal. But the way in which people get there is quite
904.33s - 909.17s |  different, right? And we were really lucky in the States that we got a lot of time between high
909.17s - 913.31s |  school and college and having to have a career that we could screw around. Like, if I had to do
913.31s - 919.87s |  my effort I put in college in high school years, I wouldn't be a hacker. I'd be too busy. And
919.87s - 925.89s |  so, we're also really lucky the way that people got into hacking and allowed this amount of
925.89s - 930.45s |  creativity. We want you, especially I think in America, you're allowed to fail. You're supposed
930.45s - 935.65s |  to fail. If you don't fail, how do you learn? Like, we love the underdog. We love the comeback
935.65s - 941.77s |  story. And partially I think it's because it shows somebody failing and then exceeding or
941.79s - 948.93s |  succeeding. That's not such a universal story, you know, around the world. So, one of the things
948.93s - 954.77s |  we do, before I run out of time, just to explain the back story, is you'll see around the
954.77s - 960.87s |  con we have these signs up. It's our code of conduct. And it lays out what we do. The code of
960.87s - 965.49s |  conduct applies to everybody. It applies to me. It applies to everybody in the Goonsher. It
965.49s - 975.89s |  applies to you. Everybody. And the idea here is that we should respect each other and not make
975.89s - 982.33s |  people feel afraid, unwelcome, you know. So, if you don't like what someone's saying, great,
982.33s - 988.37s |  just move on. You don't have to get into a fist fight with them. But what's the natural
988.37s - 993.51s |  consequence of having a policy is you have to enforce the policy. If you don't enforce the
993.53s - 998.77s |  policy, people are watching and they'll see if we don't enforce the policy, it doesn't mean
998.77s - 1004.21s |  anything. So, then a few years later we came up with our transparency report. And you'll hear
1004.21s - 1008.55s |  this at closing ceremonies. Everything that we figured out that happened during the con that
1008.55s - 1012.45s |  violated the code of conduct policy, we'll just kind of give you a quick summation at the
1012.45s - 1019.15s |  closing ceremonies. And this is sort of a hack to make us accountable to ourselves. Because if
1019.17s - 1027.21s |  we didn't know we were going to have to report all this stuff, there's an incentive to then,
1027.21s - 1032.91s |  how would the community ever know we're actually taking their concerns seriously? Oh, yes,
1032.91s - 1040.75s |  thank you for your report. Oh, sorry, no problems this year. And so, it's kind of painful.
1040.75s - 1046.53s |  It's sad when we have serious things on the transparency report. But I also think it's
1046.53s - 1053.15s |  absolutely a healthy thing that we have to do. And we must maintain to show the community
1053.15s - 1057.39s |  that we're holding ourselves accountable. And I'm always open for ideas and rooms for
1057.39s - 1063.09s |  improvement. Because ultimately, right, the con is what you make of it. And I want you guys
1063.09s - 1069.03s |  to feel, gals, any, but you can do whatever you want. We're trying to create this experience.
1069.03s - 1077.31s |  And the other thing is, I have 35 seconds. The other thing is, the origin story of DEF CON,
1077.31s - 1083.65s |  of the speakers, was that there was so much bullshit online, or on voice bridges, about what
1083.65s - 1089.19s |  was real and what was fake, what technically worked and what didn't. You know, if you call
1089.19s - 1095.37s |  this one number and put in this code, the next phone call you make can't be traced. Like,
1095.37s - 1101.61s |  really, can't be traced. What is that number you're calling? I don't know. It's a no-tracing
1101.61s - 1107.79s |  phone number. Why does the no-tracing phone number exist? I don't know, but it's a no-tracing
1107.79s - 1113.26s |  phone number. Oh, God, I've got to find somebody from the telco to come and explain what this
1113.26s - 1119.68s |  number is. If you have a bulletin board and you put on the login page, law enforcement's not
1119.68s - 1126.18s |  allowed to log in. No law enforcement. And they create an account and they log in. That's
1126.18s - 1134.12s |  entrapment. Really? So, if the FBI's investigating you and you just put these signs up, like,
1134.12s - 1140.46s |  FBI, you must raise your hands. Identify yourself. They got to do that? Oh, yeah. Yeah, that's
1140.46s - 1147.30s |  called entrapment. I don't think that word means what you think it means. Like, Al Capone would
1147.30s - 1153.14s |  have used that somehow to his advantage. Okay, I got to find a prosecutor now. So, we got the
1154.00s - 1157.76s |  prosecutor that was prosecuting a bunch of people and she got up there and, you know, laughed
1157.76s - 1163.68s |  about that. We got people from telco. We got people from Sun Microsystems talking about how
1163.68s - 1168.68s |  exploitation and, you know, managing large systems actually worked. Hearing from the horse's
1168.68s - 1175.02s |  mouth. From the source. And that's why sometimes you'll see speakers like our next speaker,
1175.02s - 1179.92s |  previous director of the National Security Agency, General Nakasone, it's like, now you're
1179.92s - 1185.98s |  hearing from the source. These aren't people you might normally come into contact with. So,
1185.98s - 1191.16s |  that's why sometimes you see these big name VIPs. It's because we're trying to expose you to
1191.16s - 1194.70s |  people and content that you just, you might read about, but you don't normally bump into in
1194.70s - 1200.04s |  your life. And luckily, we're big enough and they're interested in us enough. They want to
1200.04s - 1204.34s |  come and meet us now. It's not just a one-way street. It's not just us wanting to know what
1204.34s - 1209.98s |  they're doing. So, with that said, thank you very much. Sorry my voice is shot. I sound like a
1209.98s - 1214.48s |  frog. Have a great time. Thank you very much. And I'll see you around.


url: https://www.youtube.com/watch?v=v6VMEeUcqzo
title: DEF CON 32 - The edges of Surveilance System and its supply chain - Chanin Kim, Myounghun Pak
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=v6VMEeUcqzo",
  "title": "DEF CON 32 - The edges of Surveilance System and its supply chain - Chanin Kim, Myounghun Pak",
  "description": "With the development of artificial intelligence and image processing technology, the video industry such as CCTV is developing greatly. However, CCTV video may infringe on an individual's privacy, and personal information may be leaked due to hacking or illegal video collection. As such, Surveillance System's Security issues are also increasing, the importance of the video surveillance industry is becoming more prominent.\n\nIn order to prevent hacking or illegal video collection, research on camera security is being conducted. However, there is a lack of awareness of NVR (Network Video Recorder), a device that actually watches videos recorded by cameras, and research on this is also insufficient.\n\nWe selected Hikvision and Dahua, which have a high NVR market share, as target vendors, and also selected Synology's NVR-related package, Surveillance Station, as targets. Before proceeding with vulnerability analysis, several problems occurred during the file system extraction process, but U-Boot mitigation was successfully bypassed through various methods. Afterwards, various types of vulnerabilities were discovered through analysis, and OEM verification was also conducted to increase impact. We present exploit scenarios for surveillance devices through vulnerability linkage and present supply chain security issues in the Surveillance System.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2628,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 Hello DEF CON. Thank you for coming to our presentation.
5.75s - 8.75s |  We are excited to share our talk titled,
8.75s - 12.75s |  Watchers Being Watched, Exploiting the Surveillance System and Its Supply Chain.
12.75s - 17.75s |  We'll talk about our vulnerability research on surveillance system devices.
17.75s - 19.75s |  Please enjoy.
19.75s - 22.75s |  First, let us introduce our research group.
22.75s - 27.75s |  I'm Chani Kim, and I'm currently working as an offensive researcher at S2W.
27.75s - 34.75s |  He's Myungwoo Park, and he's a student attending a university in Korea, enjoying offensive research.
34.75s - 39.45s |  And this is what we'll show you in this talk.
39.45s - 46.45s |  We'll be talking about a $30,000 bounty and a four-month journey to become a DEF CON speaker.
46.45s - 49.45s |  In our talk, we'll cover how we extract the firmware,
49.45s - 52.45s |  then the steps we took to analyze the vulnerabilities,
52.45s - 58.45s |  and after that, the various vulnerabilities that could be exploited in the war and their scenarios.
58.45s - 62.45s |  In the last, the impact of our research on the supply chain.
62.45s - 66.45s |  That's it. Please look forward to it.
66.45s - 70.45s |  This video will be the final goal, which happened in the real world.
70.45s - 74.45s |  We wanted to see why we're doing this research.
74.45s - 76.45s |  This was posted by Iranian hackers,
77.45s - 83.45s |  and we would like to show that we have successfully demonstrated what the video is showing.
83.45s - 85.45s |  Let's watch the video.
85.45s - 107.39s |  That's like a hacker from a movie, isn't it?
107.39s - 112.77s |  Next, why is making our surveillance device more securely important?
112.77s - 116.77s |  We can see surveillance devices everywhere in our lives.
116.77s - 119.77s |  Because of the COVID-19 pandemic outbreak,
119.77s - 124.77s |  the demand for surveillance devices has been surging for various purposes,
124.77s - 129.77s |  such as a main store, smart cities, and for those access control.
129.77s - 135.77s |  Thus, the global surveillance device market is currently worth $4.1 billion.
135.77s - 139.77s |  So, in these circumstances, surrounding by such devices,
139.77s - 145.77s |  MVRs are taking on a more essential role in our lives and those users.
145.77s - 149.37s |  Next is our target.
149.37s - 152.37s |  Many people don't know much about MVR,
152.37s - 154.37s |  but as we just highlighted,
154.37s - 160.37s |  MVR is more than just important since it plays a brand-like role in all the surveillance systems.
160.37s - 164.37s |  Therefore, we selected MVR as our target.
164.37s - 168.26s |  So, what is an MVR?
168.26s - 175.26s |  A network video recorder called MVR stores recorded video from CCTVs and live cameras
175.26s - 178.26s |  and monitors or manages real-time video.
178.26s - 180.26s |  Due to the nature of managing these videos,
180.26s - 183.26s |  many devices can access them over the Internet.
183.26s - 186.26s |  And the screen you see below is the MVR screen.
186.26s - 192.18s |  This is our detailed research motivation.
192.18s - 195.18s |  First, as we investigated enough online,
195.18s - 201.18s |  there was not as much as studies on it compared to CCTV or IP camera system.
201.18s - 205.18s |  And as a result of a showdown search,
205.18s - 210.18s |  we found that more than 30,000 devices are exposed to the Internet.
211.18s - 216.18s |  However, there are cases where critical vulnerabilities have been discovered previously.
216.18s - 221.18s |  There was a case when the Miraebonnet became popular in 2021,
221.18s - 227.18s |  Hikvision's pre-auth RCE vulnerability was maliciously used for a DDoS attack.
227.18s - 233.18s |  So, we are motivated by such examples which are serious vulnerabilities.
233.18s - 237.81s |  Next is vendor choice.
237.81s - 240.81s |  We chose four vendors, Hikvision and Tawa,
240.81s - 245.81s |  because they have the highest market share in the world's surveillance system.
245.81s - 250.81s |  We chose vendor A, which has the highest market share in Korea.
250.81s - 253.81s |  Lastly, regardless of market share,
253.81s - 258.81s |  we also selected Shinology's surveillance station package as a target vendor.
258.81s - 265.81s |  This is because Shinology is famous for security and has an image of being safe,
265.81s - 273.82s |  so we wanted to check whether surveillance-related packages were also the same.
273.82s - 277.82s |  Next, let us tell you about our firmware extraction methodology.
277.82s - 281.82s |  We tried a variety of methods to extract the firmware,
281.82s - 284.82s |  and this picture is a list of what we tried.
284.82s - 290.65s |  Since three of these products had UART ports available,
290.65s - 293.65s |  we tried to extract the firmware through UART.
293.65s - 299.65s |  Shinology allowed root share access via SSH, so no other method was needed.
301.65s - 306.65s |  Before that, let us tell you why we didn't perform the extraction via remote access.
306.65s - 312.65s |  Hikvision and Tawa supported remote access, but only limited share access was possible.
312.65s - 319.65s |  We tried many ways to bypass it, but they failed, so we had no choice but to use UART.
320.65s - 327.65s |  We identified the UART port on the PC board and connected the cable to make it interactable with the U-boot share.
327.65s - 333.65s |  However, all three devices were not regular U-boots but modified U-boots,
333.65s - 337.65s |  so we couldn't use the U-boot share as shown in the picture on the right.
337.65s - 340.65s |  We started looking for a way to bypass it.
340.65s - 351.34s |  First, in the case of Hikvision, we couldn't bypass UART mitigation on the first NVR we purchased,
351.34s - 358.34s |  so we used the downgrade method of repurchasing an older version of the Hikvision device.
358.34s - 361.34s |  The older version device had lower UART versions,
361.34s - 366.34s |  and there were differences from mitigation applied to the latest U-boot.
366.34s - 376.46s |  We were able to access the U-boot share using Hikvision's U-boot mitigation bypass technique we could find on the Internet.
376.46s - 384.06s |  And last, we updated the older version of the product to the latest firmware.
384.06s - 389.53s |  The bypass technique already known in the older version…
389.53s - 411.82s |  On the latest version, there was no reaction even though we tried our best on giving command input.
411.82s - 416.82s |  But as shown in the picture on the right, which is the older version,
416.82s - 423.82s |  using setenv and semicolons caused the command injection, so we were able to insert U-boot command.
424.82s - 430.82s |  Since we could use the U-boot command list, we were able to obtain a kernel share for the device
430.82s - 434.82s |  by adding bin share to the rdnid argument in bootargs.
434.82s - 439.26s |  Next, the case of Dahua.
439.26s - 442.26s |  In Dahua, several U-boot command lists were available,
442.26s - 447.26s |  but the most important command list such as printenv did not exist,
447.26s - 451.26s |  so we used setenv to print the changed argument once again
451.26s - 456.26s |  to check the value of the environment variable with the keys we know.
456.26s - 460.83s |  However, bigger problem awaited us.
460.83s - 466.83s |  We modified bootargs and booted the device, but we couldn't see the kernel output.
466.83s - 470.83s |  In order to use the kernel share, of course, there must be kernel output.
470.83s - 474.83s |  So we looked for a way to check the kernel output.
474.83s - 481.46s |  First, we knew that the environment section exists using the mtdpart command
481.46s - 485.46s |  and to print the contents of this environment section,
485.46s - 490.46s |  we used the ntdump command to print the contents of the environment variable.
492.46s - 497.46s |  Now that we were able to check the key values of the environment variable,
497.46s - 505.46s |  we changed the value of each environment variable one by one to see if we could grab the kernel output.
505.46s - 510.46s |  We found out that there was an environment variable called dhkeyboard
510.46s - 516.46s |  that specifies the kernel output mode, so we could change it to 0 to get kernel output.
516.46s - 519.78s |  Next is vendor A.
519.78s - 523.78s |  In the case of vendor A, unlike the previous two cases,
523.78s - 526.78s |  it was not possible to even use the ubuntu share.
526.78s - 530.78s |  As you can see, as soon as we booted the device,
530.78s - 534.78s |  type password has appeared and we couldn't use any ubuntu command list.
535.78s - 541.78s |  Vendor A was calling the secure UART and we started doing a lot of research to bypass this.
541.78s - 547.15s |  We learned about the glitching attack through a lot of research
547.15s - 550.15s |  and let the ubuntu code to perform this attack.
550.15s - 555.15s |  By reading the code, booting algorithm in the ubuntu system says that
555.15s - 559.15s |  if the initialization process was successful or lost the kernel,
559.15s - 563.15s |  and if it fails, it restarts the bootloader share.
563.15s - 568.15s |  We assumed that vendor A wouldn't have exception handling for this method,
568.15s - 573.91s |  and we found a way to make the initialization process fail.
573.91s - 576.91s |  Let us tell you how to perform this attack.
576.91s - 581.91s |  First, we will explain the process of loading kernel during the normal boot sequence.
582.91s - 586.91s |  First, load the kernel into RAM from flash memory.
586.91s - 591.91s |  Second, the CPU rests the kernel loaded into RAM and decompresses it.
592.91s - 598.91s |  If the decompression is successful, the CPU starts the kernel and terminates the execution of uboot.
599.91s - 606.91s |  Now, let us tell you the boot sequence's difference between performing the attack and vice versa.
607.91s - 612.91s |  As with the normal process, load the kernel into RAM from flash memory.
612.91s - 619.91s |  At this time, we gave it an electric shock which caused the kernel to be broken and to be loaded into RAM.
620.91s - 625.91s |  As the CPU tries to decompress the broken kernel in RAM, it naturally fails.
626.91s - 632.91s |  When this happens, the CPU restarts the bootloader share as I mentioned earlier.
633.91s - 637.91s |  Through previous research, we learned that the attack is carried out
637.91s - 642.91s |  by connecting the chip select and data out on the pad of flash memory.
642.91s - 647.91s |  Therefore, we checked the data sheet of the flash memory available at vendor A
647.91s - 650.91s |  and found out which chip should be connected.
650.91s - 654.91s |  We are now all set, but how do we connect these two pads?
655.91s - 661.91s |  We created a specialized tool for performing this particular attack
661.91s - 664.91s |  by attaching the heads of jumper cables together.
664.91s - 666.91s |  Looks very easy, right?
667.91s - 669.91s |  Here is a demo of this attack.
670.91s - 681.74s |  If we give it an electric shock and boom, we can use the bootloader share.
682.74s - 692.19s |  Once we had the kernel shares for all devices, we needed to extract the file system.
692.19s - 697.19s |  We ejected out the file system to our NAS using NFS and USB.
697.19s - 705.19s |  One thing we didn't know was that the USB had to be formatted as XFS for the device to recognize it.
706.19s - 713.60s |  As you can see, we were able to successfully transfer all devices' file systems to our NAS.
715.60s - 721.60s |  However, we encountered a big failure while configuring the AWS analysis environment
721.60s - 727.60s |  because most file systems were read-only, so no files could be modified or written.
727.60s - 732.60s |  Now, even though we had a root share, the shares become unusable once the device boots up,
732.60s - 734.60s |  so we had to bypass it.
734.60s - 741.98s |  We found out that only the root file and device directory were modifiable,
741.98s - 744.98s |  so we decided to use bind-mount.
744.98s - 749.98s |  We discovered that when we bind-mount an arbitrary file in a writeable directory,
749.98s - 752.98s |  the file becomes editable.
752.98s - 757.98s |  We immediately bind-mounted ETC password to a writeable location.
758.98s - 761.98s |  Now, we can modify ETC password.
762.98s - 767.98s |  However, the main binary ran an integrity check and rebooted the device
767.98s - 770.98s |  when changes to file contents were detected.
770.98s - 775.42s |  So, we found a way to get around this.
775.42s - 779.42s |  First, we cloned ETC password to a writeable directory.
779.42s - 786.42s |  If you look at the picture on the right, you can see that the root share is set to DSH, a restricted share.
786.42s - 794.30s |  Second, bind-mount is performed in the RCS script after the initialization process is completed
794.30s - 798.30s |  and immediately before starting the main binary.
798.30s - 806.16s |  Next, we ran the main binary, and when the web service becomes available,
806.16s - 809.16s |  we changed the contents of the bind-mounted file.
809.16s - 815.60s |  Finally, we have a restricted root share access via SSH.
815.60s - 819.60s |  Now, we can replicate the file system using NFS.
819.60s - 825.60s |  Additionally, this bind-mounting replaces the original file contents when the device is rebooted,
825.60s - 830.60s |  so we created the previous process as a share script and used it.
830.60s - 839.85s |  Next, we'll discuss the vulnerabilities we discovered and the MBR hacking scenarios we created by linking these vulnerabilities.
839.85s - 844.85s |  Here, we will explain one scenario for each vendor we targeted.
844.85s - 849.22s |  First, let's look at the scenario for vendor A.
849.22s - 853.22s |  The code on the left is the query string parsing logic used in the web page.
853.22s - 860.22s |  It calculates the start and end of the parameters based on the equal and n% characters.
860.22s - 866.22s |  This parameter named length is used as the parameter for SDRN copy.
866.22s - 873.22s |  Therefore, since the length is a controller parameter by the attacker, it can cause a buffer overflow.
873.22s - 880.54s |  So, let's insert a large number of characters into the query string parameter.
880.54s - 888.54s |  As you can see, the return address is overwritten because there is no canary successfully manipulating the PC register.
888.54s - 893.14s |  However, we encountered a few problems.
893.14s - 898.14s |  First, Annex was enabled, so we needed to perform the ROP.
898.14s - 906.14s |  Next, since the payload must be successfully delivered to the server, we could only insert printable characters.
906.14s - 913.14s |  All gadgets in the binary start with 1, so we could not use gadgets within binary.
913.14s - 918.14s |  For this reason, we also couldn't leak the libc address.
918.14s - 921.14s |  So, how do we write the exploit code?
921.14s - 923.14s |  We found several solutions.
923.14s - 929.14s |  First, we discovered that the R0 register holds a stack address at a certain size.
929.14s - 935.14s |  We confirmed that this stack address contains the string we inserted into the query string.
935.14s - 942.14s |  Next, since the main binary has a 32-bit address space, it has low entropy.
942.14s - 950.14s |  Lastly, the Lydie binary spawns a new child process whenever the child process dies.
950.14s - 955.14s |  What do you think? Doesn't it seem like everything except for protocols?
955.14s - 963.14s |  Look here. As I mentioned, the R0 register holds a stack address containing the string we can manipulate.
963.14s - 967.14s |  At that time, we can control the fish register.
967.14s - 974.14s |  Now, we needed to reboot the binary until the fish register holds the libc system address.
974.14s - 976.14s |  Here is the method.
976.14s - 982.14s |  We send a request that makes the R0 register to hold the libshare command payload.
982.14s - 987.14s |  Then, we set an arbitrary libc system address in the fish register.
987.14s - 990.14s |  Now, let's start brute-forcing.
990.14s - 992.14s |  Before long, we obtained a share.
992.14s - 1001.14s |  Fortunately, we got the share within 600 tries, not the expected 2 to the power of 16 tries.
1001.14s - 1003.14s |  Great, we got a root share.
1003.14s - 1005.14s |  But what can we do with it?
1005.14s - 1011.14s |  All critical files like video, account, user password were encrypted.
1011.14s - 1018.14s |  So, we found additional vulnerabilities in the device so we can take over the admin web page.
1018.14s - 1025.14s |  Unfortunately, since this vulnerability has not been patched yet, we cannot disclose it in here.
1025.14s - 1031.14s |  Alright, we can now access the device management page with admin privileges.
1031.14s - 1033.14s |  Now, we can do anything.
1033.14s - 1040.14s |  This is the real-time video manipulating scenario created by chaining the explained vulnerabilities.
1040.14s - 1044.14s |  The attacker infiltrates the MVR through RCE.
1044.14s - 1057.41s |  Then, using a vulnerability we cannot disclose here, the attacker gains access to the admin web page.
1057.41s - 1068.45s |  Finally, the attacker manipulates the real-time video.
1068.45s - 1072.45s |  Here is the demo video of this scenario.
1072.45s - 1079.45s |  When we send a payload, the MVR screen is tampered.
1079.45s - 1084.66s |  Thank you.
1084.66s - 1089.66s |  Next, let's discuss the missing authorization scenario for Synology.
1089.66s - 1094.66s |  Synology performs a load of MVR through the surveillance station package.
1094.66s - 1098.66s |  Let's look at the authorization code of this package's API handler.
1098.66s - 1105.66s |  First, it verifies if the user sending the request is logged in through the isAuthorized function.
1105.66s - 1111.66s |  Then, it checks if the user has permission to use the surveillance station package.
1111.66s - 1113.66s |  Doesn't it seem like something is missing?
1113.66s - 1122.66s |  It doesn't check if the user has necessary permissions to use specific features, whether the user is an admin or a guest.
1122.66s - 1130.66s |  So, we found that even with guest permissions, one could abuse all features of the Synology surveillance station.
1130.66s - 1137.66s |  We discovered that surveillance station features include reboot, shutdown, and package installation.
1137.66s - 1141.66s |  Additionally, we found something unusual.
1141.66s - 1147.66s |  Some requests usable in surveillance station are forwarded to the NAS's core package.
1147.66s - 1156.66s |  Regardless of how the requesters identify, these requests are forwarded to the core package as admin,
1156.66s - 1163.66s |  allowing a guest using surveillance station to request to the Synology NAS with admin privileges.
1163.66s - 1170.66s |  We received a CVE with CVESS score 9.9 from Synology.
1170.66s - 1175.66s |  Next, let's look at the scenario of hijacking real-time video.
1175.66s - 1182.66s |  In a normal flow, guests do not have access to the camera, so they cannot view video on the front end.
1182.66s - 1188.66s |  However, due to the vulnerability, even guests can obtain video information.
1188.66s - 1199.66s |  Synology returns the RTSP server address and access credentials in the response, granting attackers unlimited access to the videos.
1199.66s - 1204.66s |  Let's look at the scenario. Here, we included a request to terminate the layout.
1204.66s - 1207.66s |  The attacker sends a request to terminate the layout,
1207.66s - 1218.82s |  disconnecting all live video layouts connected to Synology on all computers.
1218.82s - 1224.82s |  Then, the attacker sends getLiveViewPath request to steal the video information,
1224.82s - 1234.50s |  and requests the video from the RTSP server using the stolen information.
1234.50s - 1242.31s |  Now, the attacker has hijacked the real-time video.
1242.31s - 1247.38s |  Here is the demo.
1247.38s - 1250.38s |  When we send the payload,
1250.38s - 1257.38s |  and boom, the layout is terminated and we can watch the live video.
1257.38s - 1259.70s |  Thank you.
1259.70s - 1275.80s |  Next, we will introduce the vulnerabilities and scenarios of DAWA.
1275.80s - 1281.80s |  The first vulnerability is called reachable assertion, and we will explain how we found it.
1281.80s - 1286.80s |  While analyzing the login function, we discovered that there are many login options.
1286.80s - 1292.80s |  As shown in the table below, there are six types of assert time and password type pairs.
1292.80s - 1296.80s |  By default, the assert type and password type are set to default.
1297.80s - 1304.80s |  The data sent in the request includes the username, hashed password, session, assert type, and password type.
1304.80s - 1310.80s |  If the request is successful, a response containing true is received.
1310.80s - 1317.80s |  We are curious about what will happen when attempting to log in with different authentication types
1317.80s - 1321.80s |  will lead us to unable to analyze the login options.
1321.80s - 1327.80s |  During the analysis, we found a developer's mistake in the processing of the login request data
1327.80s - 1332.80s |  and were able to shut down the device with a reachable assertion as a result.
1332.80s - 1335.80s |  Now, let me explain the vulnerability.
1335.80s - 1342.80s |  First, before processing the login logic, the function's getPasswordType and its password value are called.
1342.80s - 1347.80s |  The getPasswordType function extracts assert type and password type by parsing
1347.80s - 1352.80s |  and compares specific strings such as default and default, respectively.
1352.80s - 1357.80s |  If the strings match, the function returns a type for their own.
1357.80s - 1364.80s |  If the type is both default, it returns 4, and if it is OTP and SSC, it returns 7.
1364.80s - 1370.80s |  The next function is called isPasswordValid and parses the login parameters
1370.80s - 1375.80s |  based on the type value returned by the previous function getPasswordType
1375.80s - 1377.80s |  and creates a string object.
1377.80s - 1383.80s |  The series of process enters when assert type and password type are set to default.
1383.80s - 1390.80s |  You can see that there is an exception handling logic that checks to see if those parameters are null
1390.80s - 1394.80s |  before generating a string object for both parameters.
1394.80s - 1400.80s |  Most of the branches have this null exception handling logic, but not all of them.
1401.80s - 1407.80s |  The following code handles the case when the authentication type is OTP and WSSC.
1407.80s - 1414.80s |  As seen in the code below, string objects for authority input and password type variables are created,
1414.80s - 1419.80s |  but there is no exception handling logic for these objects.
1419.80s - 1427.80s |  So, we remove the authority input parameter, set the authentication type to OTP, WSSC, and send a request.
1427.80s - 1433.80s |  As a result, the authority input is set to null, which causes a retrieval assertion to be drawn
1433.80s - 1439.80s |  when creating a string object for that parameter, causing the main binary to exit.
1439.80s - 1444.80s |  When the main binary terminates, the watchdog causes the device to reboot.
1444.80s - 1447.80s |  This is a pretty simple vulnerability.
1447.80s - 1453.80s |  The following vulnerabilities are very important because they require the device to reboot.
1454.80s - 1458.80s |  The second vulnerability is LP injection.
1458.80s - 1462.80s |  First, that will set permissions by group, and once creating an account,
1462.80s - 1468.80s |  it can only perform tasks included in the permissions of the assigned group.
1468.80s - 1475.80s |  This group information is stored in a file named groupsec and is encrypted using ASCBC.
1475.80s - 1479.80s |  We tried analyzing the source code to find the key in IV,
1479.80s - 1484.80s |  but it was quite complicated and eventually failed to find it.
1484.80s - 1490.80s |  However, since the configuration information must be decrypted and loaded into memory
1490.80s - 1496.80s |  during the main binary boot process, so we performed a dynamic analysis of the boot process,
1496.80s - 1502.37s |  and unfortunately, we were able to find the decrypted data.
1502.37s - 1506.37s |  The structure of the decrypted groupsec file is as follows.
1506.37s - 1510.37s |  The columns are ID, name, authority, and memo.
1510.37s - 1517.37s |  Each column is separated by a column, and each line is separated by a line feed.
1517.37s - 1522.37s |  When adding or modifying group information, the getline function is called
1522.37s - 1526.37s |  as part of the process of saving the changed data.
1526.37s - 1531.37s |  This function generates a line with the ID, name, authority, and memo,
1531.37s - 1535.37s |  extracted from the logon request separated by columns.
1535.37s - 1540.37s |  We found out that there was no validation checking procedure of the input value
1540.37s - 1544.37s |  until generating a line with the getline function.
1544.37s - 1551.90s |  So, we added a line feed to the memo to tamper the structure and restarted the device
1551.90s - 1556.90s |  to see what would happen during the parsing process of the groupsec file.
1556.90s - 1561.90s |  As a result, the device entered the initialization routine
1561.90s - 1564.90s |  and recreated the groupsec file.
1564.90s - 1569.90s |  When entering the initialization routine, the user can change the add-in password on the web
1569.90s - 1571.90s |  and perform any actions.
1571.90s - 1577.90s |  We were curious if the initialization routine would still be entered if the file was deleted.
1577.90s - 1580.90s |  After deleting the file and rebooting the device,
1580.90s - 1585.90s |  we found that it still enters the initialization routine.
1585.90s - 1591.90s |  Let me introduce the first scenario of DAWA using two vulnerabilities mentioned above.
1591.90s - 1594.90s |  By using Retrieval Assertion and Alpha Injection,
1594.90s - 1599.90s |  an attacker can take over the device and obtain admin privileges.
1599.90s - 1606.90s |  First, the attacker obtains an account with UsUserManagedPrivileges through credential stuffing.
1606.90s - 1611.90s |  Next, the structure of the groupsec file is tampered through Alpha Injection.
1611.90s - 1618.88s |  Then, the attacker reboots the device using Retrieval Assertion.
1618.88s - 1627.65s |  When rebooted, the device enters the initialization routine,
1627.65s - 1633.65s |  allowing the attacker to change the admin password and perform malicious activities.
1633.65s - 1641.99s |  Next is Stack Overflow.
1641.99s - 1648.99s |  First, this vulnerability occurs not in the main binary but in a background service called AOL.
1648.99s - 1653.99s |  This service is used to attempt online recovery when the device is abnormal
1653.99s - 1656.99s |  and is open on port 8088.
1656.99s - 1661.99s |  Since this port is not forwarded, it can only be accessed from the same network.
1661.99s - 1666.99s |  It consists of 16 bytes of fixed size of headers and data.
1666.99s - 1672.99s |  For header, the constitutional data byte index 0 indicates the function index
1672.99s - 1676.99s |  and the byte chat indexes 4 to 7 indicate the data size.
1676.99s - 1682.99s |  The data is then used as an argument for the input handler remitted by the data size.
1682.99s - 1687.99s |  However, the pinpoint is that the data size can be publicated.
1687.99s - 1691.99s |  Now, let me explain the request processing procedure.
1691.99s - 1698.06s |  The following function is called PerMessage.
1698.06s - 1704.06s |  First, this function uses the structure with the way which consists of functions
1704.06s - 1708.06s |  and variables related to each feature.
1708.06s - 1711.06s |  As shown in the table on the left,
1712.06s - 1717.06s |  each structure includes the permission level index verification function,
1717.06s - 1720.06s |  parameter parsing function, handler function,
1720.06s - 1724.06s |  parameter allocation free function, and next table pointer.
1724.06s - 1727.06s |  There are about 20 such tables.
1727.06s - 1730.06s |  Here is how it works internally.
1730.06s - 1736.06s |  The function iterates through a loop calling the index verification function of each structure
1736.06s - 1740.06s |  with the first byte of the header as an argument.
1740.06s - 1744.06s |  The index verification function, as seen in the code on the bottom right,
1744.06s - 1751.06s |  checks if the value obtained by subtracting a specific constant number from the argument is not 0.
1751.06s - 1754.06s |  If the result is 0, it returns 0.
1754.06s - 1757.06s |  Otherwise, it returns minus 1.
1757.06s - 1759.06s |  Referring back to the code on the left,
1759.06s - 1764.06s |  if the return value is greater than 0 or meaning a matching index is found,
1764.06s - 1769.06s |  the current table pointer is told in the A to variable and 0 is returned.
1769.06s - 1776.06s |  If the matching index is found, minus 1 is returned and the request is not processed.
1776.06s - 1780.76s |  Next, the dpStackParse function is called.
1780.76s - 1786.76s |  This function retrieves the table corresponding to the index and calls the parseParam function.
1786.76s - 1789.76s |  As shown in the parseParam function on the right,
1789.76s - 1796.76s |  it appropriately processes the data according to the requested function and then returns the result.
1796.76s - 1800.76s |  Finally, once all preprocessing steps are complete,
1800.76s - 1806.76s |  the dpHandleQuery function is called to register the input handler and then execute it.
1806.76s - 1811.14s |  There are many different functions that could be called,
1811.14s - 1816.14s |  including login, query, and update, but they all require the login.
1816.14s - 1820.14s |  So, we started analyzing the login function first.
1820.14s - 1825.42s |  The function is executed if the first byte is A0.
1825.42s - 1832.42s |  The data consists of username, password, and a random value with a double ampersand used as a delimiter.
1832.42s - 1838.42s |  The vulnerability occurs when parsing this data, which we'll explain in a moment.
1838.42s - 1841.66s |  As you can see in the code on the right,
1841.66s - 1849.66s |  the strings for the username and password are set to 128 and 160 bytes respectively,
1849.66s - 1853.66s |  and the memory is initialized with a memset.
1853.66s - 1860.66s |  Next, the addStringString function is called to find the positions of the double ampersands and null.
1860.66s - 1864.66s |  The data before the first double ampersand is copied to username,
1864.66s - 1869.66s |  and the data before the next double ampersand is copied to password.
1869.66s - 1874.66s |  The problem is that there is no length validation checking during the copying process,
1874.66s - 1877.66s |  allowing us to input data of any size.
1877.66s - 1881.66s |  As a result, a buffer overflow occurs.
1882.66s - 1887.66s |  You can cover the return address by putting 156 bytes of random data,
1887.66s - 1893.98s |  the desired value, and the password location, as shown below.
1893.98s - 1898.98s |  Since there was no stack canary, we couldn't manipulate the PC register.
1898.98s - 1903.98s |  However, we encountered an issue where we couldn't include a null in the payload,
1903.98s - 1905.98s |  making our pain possible.
1905.98s - 1909.98s |  We didn't want to conclude with just a simple buffer overflow,
1909.98s - 1913.98s |  so we began analyzing the source code.
1913.98s - 1916.98s |  Fortunately, we found some useful functions.
1916.98s - 1921.98s |  There were functions for rebooting, starting SSH, removing intersettings,
1921.98s - 1925.98s |  performing a soft recovery, and killing all MBR-related binaries.
1925.98s - 1929.98s |  Among these, the most interesting function was the soft recovery.
1929.98s - 1935.98s |  This function deletes the configure directory, resetting all configuration information.
1936.98s - 1941.98s |  As seen in the previous vulnerability, if the groupseq file is deleted or tampered,
1941.98s - 1944.98s |  the initialization routine is entered upon reboot,
1944.98s - 1948.98s |  allowing the admin password to be changed.
1948.98s - 1953.98s |  Therefore, we manipulated the PC register to call the soft recovery function.
1953.98s - 1957.98s |  However, soft recovery deleted even the network files,
1957.98s - 1960.98s |  making external access impossible.
1960.98s - 1965.22s |  Unfortunately, we faced another challenge.
1965.22s - 1968.22s |  After several days of analysis and contemplation,
1968.22s - 1972.22s |  it soon came to my head that during the boot,
1972.22s - 1977.22s |  there is a process where configuration files in the configure directory
1977.22s - 1980.22s |  are decrypted and loaded into memory.
1980.22s - 1983.22s |  So, we began analyzing the boot loads.
1983.22s - 1988.22s |  As a result, we found that the network configuration file is loaded first,
1988.22s - 1993.22s |  and then the account file is loaded around 5 seconds later.
1994.22s - 2000.22s |  I was curious to see what would happen if the main binary center soft recovery failed
2000.22s - 2004.22s |  within 5 seconds of loading the network configuration file.
2004.22s - 2010.22s |  The most fortunate point is that AOR is loaded before the main binary boots.
2010.22s - 2017.22s |  First, we kill the main binary using the recover assertion, causing the device to reboot.
2017.22s - 2021.22s |  Then, we wait until the network configuration file is loaded.
2021.22s - 2026.22s |  In our case, it took approximately 10 seconds for the device.
2026.22s - 2033.22s |  Next, we send the soft recovery failure to AOR, which deletes all configuration files.
2033.22s - 2038.22s |  Then, the main binary can't access the account configuration file
2038.22s - 2041.22s |  and enters the initialization routine.
2041.22s - 2045.22s |  As a result, we are able to change the admin account.
2046.22s - 2052.22s |  Let me explain the admin takeover vulnerability using recover assertion and stack buffer overflow.
2052.22s - 2056.22s |  First, we will reboot the device via recover assertion.
2056.22s - 2063.27s |  After rebooting, wait for the network configuration file to be loaded,
2063.27s - 2072.03s |  and then send the soft recovery failure to AOR to remove all configuration files.
2072.03s - 2079.26s |  In the process of loading account setting files such as groupsec,
2079.26s - 2084.26s |  it enters an initialization routine because the files do not exist.
2084.26s - 2091.74s |  The attacker changes the admin password and gains access to the admin page.
2091.74s - 2093.74s |  This is a demo.
2093.74s - 2110.34s |  The last vulnerability is from HikeVision.
2110.34s - 2116.34s |  HikeVision was much more solid compared to other devices, making it more challenging.
2116.34s - 2121.34s |  However, we found an interesting vector, a local subs component.
2121.34s - 2126.34s |  That is a plugin that must be installed for users to view video from the web.
2126.34s - 2134.34s |  This plugin runs with admin privileges on Windows and is accessible on port 33686,
2134.34s - 2137.34s |  meaning anyone on the same network can access it.
2137.34s - 2144.34s |  It was a very interesting plugin, so we started analyzing it and found the vulnerability.
2144.34s - 2151.34s |  Due to an ending associated with a bounty for this vendor, we can't disclose detailed root cause.
2151.34s - 2157.34s |  In short, it is a vulnerability that allows RCE by sending a crafted message.
2157.34s - 2160.34s |  Instead, we will show you a demo.
2160.34s - 2164.34s |  Through RCE, we can completely take control of Windows.
2164.34s - 2168.34s |  With admin privileges, we can perform any actions.
2168.34s - 2179.18s |  The next vulnerability is OS command injection,
2179.18s - 2185.18s |  which allows a user with admin privileges to execute arbitrary commands.
2185.18s - 2192.18s |  We create a scenario to take control of the internal network using these two vulnerabilities.
2192.18s - 2197.18s |  First, we obtain admin privileges through credential stuffing.
2197.18s - 2203.81s |  Next, we offer a reversal through command injection to enter the MVR.
2203.81s - 2214.50s |  Then, we perform network scanning to find Windows computers using the application named local subs component.
2214.50s - 2221.50s |  Finally, by exploiting the plugin RCE, we could take control of Windows and perform malicious activities.
2221.50s - 2225.14s |  Here is the demo.
2225.14s - 2236.91s |  By just pressing the button, we can automatically take control of Windows computer in the...
2253.07s - 2260.07s |  One of the things we learned during the project is the Hikvision and our Huzy OEM supplier.
2260.07s - 2270.07s |  Both companies also sell under their own brands, but they are relabeled and sell to various retailers in the U.S. such as Lorex and Luma.
2270.07s - 2277.07s |  This means that devices are being used all around us without realizing that they are made in China.
2277.07s - 2282.07s |  First, OEM stands for Original Equipment Manufacturer.
2282.07s - 2292.07s |  It refers to the manufacturing method in which a company outsources the production of its products to another company and then sells them under its own brand.
2292.07s - 2299.07s |  If a product is made by Company A, it's sold under the brand name of Company B.
2299.07s - 2304.07s |  Company A becomes the OEM supplier and Company B becomes the OEM vendor.
2304.07s - 2308.07s |  The images below show Dallas MVR and OEM MVR.
2308.07s - 2311.07s |  They look very similar, don't they?
2312.07s - 2315.07s |  This picture illustrates the OEM sales process.
2315.07s - 2324.07s |  Products manufactured by OEM suppliers like Hikvision and Dahua are relabeled by OEM vendors and sold to users.
2324.07s - 2335.07s |  If a vulnerability occurs in a product produced by an OEM supplier, it can affect the products sold by the OEM vendor as well.
2335.07s - 2340.07s |  This means that many devices can be impacted by the same vulnerability.
2340.07s - 2347.07s |  So, we decided to check if the vulnerabilities were valid for OEMs using the same firmware.
2347.07s - 2355.07s |  First, we ran bin-deep on the main binaries of Dahua and OEM vendor Bush and found that the logic was similar.
2355.07s - 2360.07s |  Hikvision also confirmed similar through deeping.
2360.07s - 2368.07s |  After confirming that OEM vendors use similar firmware, we decided to purchase devices and test them.
2368.07s - 2375.07s |  For Hikvision, we purchased Anki and Ampibis. 4 out of 6 vulnerabilities were valid.
2375.07s - 2382.07s |  For Dahua, we purchased Zhiyun and EGPS. 4 out of 6 of the 7 vulnerabilities were valid, respectively.
2382.07s - 2391.07s |  We confirmed that the vulnerabilities were validly exploited and reported them to Mitre, KISA, which is the Korean CNA,
2391.07s - 2400.07s |  to get CBs and KBEs, which increased the number of recognized vulnerabilities by 61%.
2400.07s - 2406.35s |  Finally, we will show you a video of vulnerability testing on OEM vendors.
2406.35s - 2410.35s |  The first video is the OEM vendor testing for Dahua.
2410.35s - 2415.35s |  By sending Dahua's recover assertion payload, we could shut down all devices.
2415.35s - 2422.26s |  The second video is OEM vendor testing for Hikvision.
2422.26s - 2431.26s |  After sending the voice command injection payload, we could connect a reverse shell and input the shutdown command to turn off all devices.
2431.26s - 2439.61s |  Also, we were curious about how many devices were affected by the vulnerabilities we found.
2439.61s - 2442.61s |  So, we searched using Shoda.
2442.61s - 2452.95s |  In the case of Hikvision, most model devices' names or firmware versions were not present in the banner data.
2452.95s - 2457.95s |  So, we needed a different approach to identify as many as possible.
2457.95s - 2465.95s |  We found that for MBR devices, when accessing the login page, a config.json file is requested.
2465.95s - 2470.95s |  This file contains the configuration information related to MBR.
2470.95s - 2481.95s |  For version information, we used the web version and plug-in version coded in the C.js to search for devices with versions equal to or lower than the one we did our study.
2481.95s - 2488.95s |  As a result, we found that approximately 130,000 devices were vulnerable.
2488.95s - 2494.95s |  For Dahua, since the device name was present in the banner, we simply searched for it.
2494.95s - 2499.95s |  As a result, we found approximately 100,000 devices.
2499.95s - 2503.95s |  Finally, we came to the conclusion part.
2503.95s - 2509.95s |  First of all, this is what we would like to comment to offensive researchers in MBR field like us.
2509.95s - 2514.95s |  The vulnerabilities we discovered during our research period include.
2514.95s - 2520.95s |  Even when analyzing one-day cases, we found that these vulnerabilities were statically numerous.
2520.95s - 2527.95s |  So, when you want to analyze your MBR, we recommend that you focus on these vulnerabilities.
2528.95s - 2540.95s |  We conducted an analysis focusing on HTTP communication process of domain binary in order to achieve good results as much as possible over the project of four months.
2540.95s - 2550.95s |  However, MBRs have numerous attack surfaces, including private protocols with their cloud service, SDK communication with VMS,
2550.95s - 2558.95s |  private protocols used to communicate with MBRs or IP cameras, and communication with other sensors.
2558.95s - 2568.95s |  Therefore, we recommend that you do not focus solely on analyzing the HTTP process, but analyze various attack surfaces.
2568.95s - 2573.95s |  The following is what we would like to recommend to users.
2574.95s - 2583.95s |  What we felt while conducting a one-day case study is that as long as MBR is not exposed to the external network, it is safe from these attacks.
2583.95s - 2594.95s |  Major MBR vendors provide solutions that allow external access using things like DDNS without exposing the device to an external network.
2594.95s - 2600.95s |  You can take advantage of these solutions to keep your devices safe from these attacks.
2600.95s - 2606.80s |  Thank you to people who helped us with research.
2606.80s - 2612.30s |  Especially, thank you to Dr. Junsang Yoo.
2612.30s - 2614.30s |  Thank you for listening to our presentation.
2614.30s - 2618.30s |  If you have any questions, please contact us on Twitter below.
2618.30s - 2622.30s |  More details of our research can be found via the QR code on the right.
2622.30s - 2623.30s |  Thank you.


url: https://www.youtube.com/watch?v=asd33hSRJKU
title: DEF CON 32 - OH MY DC Abusing OIDC all the way to your cloud - Aviad Hahami
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=asd33hSRJKU",
  "title": "DEF CON 32 - OH MY DC  Abusing OIDC all the way to your cloud - Aviad Hahami",
  "description": "As DevOps and developers are slowly shifting away from storing long-lived static credentials to the more secure, still kinda-new, OIDC alternative - the underlying logic, mechanisms and implementations tend to feel like complicated magic and are mostly overlooked.\n\nIn this talk, we'll begin by recapping what OIDC is, who are the interacting entities when OIDC is used, and how OIDC is taking place to securely access one's cloud using CI/CD flows.\n\nOnce covered, we will be able to alternate our point-of-view between the entities in play and demonstrate potential vulnerabilities in various setups.\n\nStarting with the user PoV, we will show what \"under-configurations\" look like, and continue by demonstrating how new OIDC configuration options can actually be misconfigurations that can result with a compromise.\n\nWe will then see another attack vector where leaking an OIDC token from a single repository in an organization can allow an attacker to abuse under-configurations and access private clouds.\n\nAfter that, we will shift our PoV to be of the Identity Provider (IdP) so that we can look into what happens if an IdP is misconfigured, and disclose a real-world security vulnerability found in one of the most popular CI vendors that allowed us to access any of their customers' cloud environments.\n\nI'll refer to this talk by the Tinder Security team link where they show how they could \"claim\" in the name of other identities due to under-configured WIFs.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2259,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.66s - 5.66s | This text was transcribed using whisper model: large-v2

 Yeah, yeah, yeah. What's up? Good to go? Okay. So, uh, hi everybody. Today's talk is, uh,
9.50s - 15.50s |  called Ohm IDC, where we gonna, uh, learn and see how we can we abuse OIDC setups in the
15.50s - 21.54s |  context of CI. Um, this is extremely exciting for me. That's my first time speaking in the
21.54s - 27.32s |  con, so thank you very much for showing up. And thank, thank you very much for having me.
27.32s - 32.56s |  That was the first voice breakdown, so it's fine. Okay, uh, by the way, if Adnan and John are
32.56s - 39.56s |  here, thank you for the build up. I hope I'll satisfy that. So, I'll, uh, present myself. My
39.56s - 46.04s |  name is Aviad Hachami. This is my, uh, Twitter handler. I do security research at Palo Alto. Um,
46.04s - 51.64s |  I do CI domain mainly. Uh, I welcome you to check my latest publication. Uh, this is Azure
51.64s - 58.44s |  CLI, um, information leakage with the 8.6 core somehow. Um, but it probably affected all
58.44s - 63.44s |  your ASG, uh, usages. I also do bug bounty, I DJ, I do graph theory, and FPV drones. Not
65.28s - 72.28s |  necessarily in this order. Okay. So, before we go into the agenda, I want to try and
72.28s - 78.00s |  convince you why you should listen. Um, so first thing first, if you're completely new to
78.02s - 83.36s |  this world or you have like a rough idea of what OIDC is, I hope you get today the full
83.36s - 89.20s |  context of what's up with that. What's up internally. There's noise. What's up internally and,
89.20s - 94.24s |  uh, how does it play? If you're already a user, I hope you're gonna learn some pitfalls and
94.24s - 99.34s |  misconfiguration. I'm gonna, I hope I'm gonna save you some weekends. And if you're a
99.34s - 103.52s |  bounty hunter, um, like most of us here, I hope you're gonna get some new ideas for
103.54s - 108.54s |  exploitation. Alright. So, with that, let's go into the agenda. We're gonna start with an
111.24s - 115.92s |  OIDC overview. Okay, for those of you who are familiar with this, uh, topic, uh, hold on
115.92s - 122.42s |  tight for a sec. Um, after this, we're gonna move into no configs. Uh, this is just a weird
122.42s - 128.96s |  term I set up. Um, I'm gonna explain about it, uh, soon enough. We're gonna move into, uh,
128.96s - 133.36s |  advanced configurations, misconfigurations, and we're gonna learn what happens when the
134.20s - 139.20s |  CI vendor, um, makes a misconfig and why do we care about the CI vendor in that context. Alright.
141.38s - 147.58s |  So, first thing first, let's begin with an OIDC overview. So, when I actually rehearsed this
147.58s - 153.38s |  talk, um, to some of my friends, some of them are, uh, uh, good researchers, uh, used terms
153.38s - 158.76s |  like workflow, job, uh, the CI config, et cetera, et cetera, and they were, they said at some
158.76s - 164.94s |  point, this is nice, but I'm not sure how CI works. So, in the case you're like my friend and
164.94s - 170.08s |  you slept under a rock for the past 10 years, I'm gonna show you what CI is in one slide so we
170.08s - 176.18s |  can move on. So, extremely quickly, what is CI? Assuming you're a developer, you performed
176.18s - 181.12s |  some GitHub, uh, operation, maybe push, pull request, et cetera, this was, uh, pushed to your
181.12s - 186.06s |  VCS provider, GitHub, GitLab, you name it. Um, and it was reflected in your online
186.06s - 190.86s |  repository. So far, so good. Now, since you've configured your CI provider, cause this is what we
190.86s - 196.44s |  care about, then the VCS provider notified your CI provider that something happened using a
196.44s - 201.44s |  webhook with payload, nothing special here. Uh, in, in turn, the CI providers, uh, spin a
203.78s - 208.78s |  machine for you, it can be any OS according to your configuration, aka workflow. Um, these
209.48s - 214.48s |  machines do whatever you want, it can be lints, builds, compilations, and since we're in
216.28s - 222.28s |  2024, they also push to your cloud environments. It can be GCP, AWS, Docker Hub, basically
222.28s - 228.96s |  everything out there. This is CI, welcome. So, something I want to emphasize is that those are
228.96s - 233.20s |  all split entities, okay? We're gonna come into that later on, we're gonna show this diagram
233.22s - 239.26s |  again, but I want you to remember that these are split entities. Cool. Our problem space is
239.26s - 245.00s |  this small arrow, welcome to the OIDC and CI niche. This small arrow, which basically makes us
245.00s - 250.04s |  ask, uh, an important question, we're in a machine to machine world, so how does
250.04s - 255.04s |  authentication happen, right? How can we access Docker Hub, for example? An easy answer,
257.04s - 262.06s |  right, will be to hard code your secrets, this is great for my bug bounty, please do that. Um,
262.12s - 266.92s |  but, yeah, continue. Um, the second option will be secrets, right, uh, this is a feature by
266.92s - 271.66s |  the CI providers, et cetera. Um, but we all know that at some point or another it's gonna leak,
271.66s - 275.86s |  right? We're gonna see some articles saying company whatever was leaked, was breached
275.86s - 280.86s |  because of a leakage. So we don't want to do that anymore. And then OIDC comes into help. So
283.60s - 289.84s |  OIDC is uh, open identity, this is uh, initials for open identity, something I forgot
289.86s - 294.16s |  because I'm stressed, obviously, but that's fine. Uh, but what I want to emphasize is that it's a
294.16s - 299.20s |  simple OAuth extension. I believe most of you know what OAuth is at this point in time. If
299.20s - 304.68s |  you're on YouTube and you're not familiar with, pause now, go learn OAuth, come back. Yeah,
304.68s - 308.98s |  um, it's, it's the basics. So OIDC comes into help and gonna help us solve this whole
308.98s - 313.72s |  credentials problem and it's gonna allow us to use um, uh, something called identities that
313.72s - 318.82s |  we're gonna see in a second. So, what is this OIDC flow? We're gonna learn the vanilla
318.84s - 323.04s |  version and then the CI version cause they're a bit different. Um, this is just a slide taken
323.04s - 328.48s |  from Microsoft. Um, you are all familiar with the try to log in, go to the identity provider,
328.48s - 333.38s |  come get like uh, the token, come back, exchange it. But now we see something different.
333.38s - 337.56s |  Instead of access token and refresh token, we're relying on something called ID token.
337.56s - 342.62s |  Welcome. Um, so we're gonna learn what ID tokens are in a second, but I just want to plug
342.62s - 347.30s |  in some terminology. This is the authent part, the authentication where you actually put
347.34s - 353.42s |  credentials and this is the auth Z part where you actually authorize someone to access
353.42s - 357.38s |  something regardless of their authentication state. Obviously they should be authenticated by
357.38s - 362.40s |  this point in time. So ID tokens. Um, standard JWTs, right, JWTs, base 64. Uh, we're gonna
365.40s - 370.00s |  decode them and we're gonna get the header which we don't care about for the sake of this
370.00s - 375.60s |  talk. I'll just add that this is how you verify the integrity of an incoming ID token, but
375.60s - 380.92s |  I'm not gonna touch this any further. Don't care symbol. And the second part is the actually
380.92s - 386.02s |  ID token body and we're gonna dive into the contents of it in a sec, but for the, for the
386.02s - 391.66s |  purpose of this slide, I want you to remember that ID tokens, um, the body of it is a simple
391.66s - 396.50s |  dictionary where each key is called claim. So now onwards I'm gonna say the token claims
396.50s - 403.14s |  something. Okay? Good. So let's conclude the OIDC in the vanilla version of it. Um, it's an
403.14s - 407.92s |  OAuth extension and it allows it to rely on short-lived tokens that are based on identity.
407.92s - 412.92s |  That's it. TLDR of the whole magic. Right, so let's put it in the context of CICD. If I'm
415.06s - 419.70s |  bringing back this small snippet here, right, and I told you this is our problem space, we
419.70s - 424.80s |  have two important questions now. First, this is a machine, how does it authenticate? We
424.80s - 430.20s |  don't know, we no longer have credentials, so how do we log in? Second question is, is
430.20s - 435.78s |  assuming this ID token, how do we verify it? What do we verify it and who does this for us?
435.78s - 442.02s |  Okay? So let's address these questions, um, this is the diagram that you all saw like a few
442.02s - 447.36s |  slides ago and if I'm gonna call her back, who's in charge of what? And we see that the only
447.36s - 452.36s |  entity that is in charge about, of the CI machine is the CI provider, right? So what
454.76s - 459.36s |  actually happens behind the scene, and again I'm gonna pop up this question, how do we get
459.36s - 464.56s |  the credentials? The CI provider records, reacts, sorry, in accordance to our
464.56s - 469.24s |  configuration, right? And when we were configured, we were authenticated to the CI
469.24s - 474.34s |  provider. So in a sense, you can say that when a CI executes, the machine runs on our
474.34s - 480.12s |  behalf. Hence, it's associated with our identity. And this is important to remember. A CI
480.12s - 486.22s |  invocation is in the context of the owner of the CI integration. So, in the context of
486.22s - 491.26s |  CI CD, uh, the CI vendor also gets to be the identity provider. It's the only one that can
491.26s - 495.70s |  give this machine who it is. Okay? Otherwise, it's just an ephemeral machine, right? Nobody
495.70s - 500.06s |  knows what it is. Like, why should I give you access to something? So this is the first
500.06s - 505.80s |  question answered. Now, the second question was, assuming I do have this ID token, who
505.80s - 510.82s |  authorizes this and how exactly? So, I'm gonna close the global protect. So, um, I'm gonna
511.82s - 516.82s |  bring back this ID token and this, the Auth Z part is actually composed of two components. The
519.92s - 524.56s |  first is the ID token. And this is an example ID token that is shipped by, uh, GitHub's
524.56s - 528.70s |  identity provider. Most of these, uh, example are gonna be on GitHub. I really like you
528.70s - 534.18s |  folks. Um, so, and if you look at the contents, you see various claims like, uh, the Git
534.18s - 539.68s |  SHA, the repository name, run ID, et cetera, et cetera, et cetera. Like, claims. And the most
539.70s - 545.04s |  important for us to remember is, uh, to note, sorry, is the sub. Sub short for subject. And
545.04s - 550.32s |  this is the default property to assert. When the, uh, basically when we check those claims,
550.32s - 555.98s |  it's called assertion. Um, and this is the default property to assert. Now, if we actually
555.98s - 561.60s |  dissect this for a second, we know the following. The repo, short for repository, contains
561.60s - 567.94s |  the value of the repository claim. Okay? And the ref, right, the ref prefix contains the
567.96s - 573.54s |  value of the Git ref coming from the ref claim. So, we can actually see that there's a
573.54s - 579.00s |  format behind the scenes. And we're gonna come back to that later on. So, an ID token, in
579.00s - 583.64s |  the context of CI, I'm gonna summarize that, contains information about the Git event that
583.64s - 587.74s |  triggered the pipeline, uh, alongside other vendor information. And we're gonna see
587.74s - 593.86s |  later on what this other vendor information, where exactly does it bite us. The second
593.88s - 598.74s |  part, the second component of the AuthZ is the, something called identity federation. As
598.74s - 604.22s |  the name implies, it, it federates identities coming in. Um, this is an example
604.22s - 610.56s |  configuration, uh, for AWS specifically. And the file is pretty simple. Um, you have the
610.56s - 615.30s |  identity name, just a string, the identity provider, this is usually the URL of it. Um, and
615.30s - 621.54s |  then you set up conditions for who can claim to be this identity. Um, then we see what
621.58s - 627.32s |  claims we assert, right? We have the sub, does it work? Okay. We have the sub and then we
627.32s - 631.46s |  have the odd, odd short for audience by the way. And then we see that there, we can define
631.46s - 636.76s |  the comparators, right? We can do string like or string equals and set the values. Okay, so
636.76s - 642.86s |  this is roughly, this is how it goes. So, per the question, how exactly do we authorize
642.86s - 647.58s |  someone? Then we have this entity called identity federation and it's gonna assert tokens
647.58s - 654.32s |  claims coming, uh, from, uh, CI machines. In this case, obviously. Alright, so now that we
654.32s - 659.22s |  know that the CI provider is also the identity provider, right? This is something new. And we
659.22s - 665.64s |  also know that this, uh, we have this federation. Then let's redraw the, the OIDC flow in
665.64s - 672.14s |  the context of CI. So in the context of CI we actually have this diagram. Now the CI
672.14s - 677.54s |  provider also gets to be the identity provider, so it hosts both, uh, like both the CI and
677.54s - 683.12s |  itself, the identity. And also we see on the cloud provider, we have the federation. So the
683.12s - 688.26s |  flow is as follows. You ask for an ID token, you get an ID token, you go to your cloud, you
688.26s - 694.42s |  say I wanna access, the clouds verify the integrity, this is done using the header. And then
694.42s - 699.20s |  it's gonna assert the incoming token against its policies and assuming everything was fine,
699.20s - 705.10s |  you're gonna get a set of short-lived credentials. This, this microphone hiccups, right? Right?
705.10s - 710.10s |  Uh, oops. The mic hiccups. It doesn't work. Roughly. Halfway. Okay, Asi, take care of that.
713.58s - 720.08s |  Okay. Um, I'm gonna plug back in the terminology. This is the auth n bit, okay? And this is
720.08s - 725.08s |  the auth z bit. Now since the flow is different, what does it imply? I'm gonna border this
725.08s - 730.08s |  square and let's zoom in. Since everything here happens within the CI provider, if we are
734.02s - 739.02s |  able to trigger a CI pipeline, we basically granted the owner's identity, okay? Now you can
740.96s - 747.96s |  limit that using, you can limit that using specific, uh, uh, orders we'll see later on, but if
747.96s - 753.94s |  you're able to trigger a CI machine, you're basically passed the auth n part, okay? This
753.96s - 758.50s |  leaves us with the auth z part to guard everything, basically, cause we have the CI machine
758.50s - 764.08s |  running. And in a sense, if we're able to trigger a CI pipeline, all that stands between us
764.08s - 768.62s |  and accessing a target's resources is just the policy pattern matching, right? So you can see
768.62s - 774.16s |  on the bottom part, examples for, uh, subclaims. It can begin with repo, uh, multi-banana
774.16s - 779.52s |  Zurich, um, the name of the, uh, uh, repository, the git ref. And on the right hand side, you
779.54s - 785.24s |  can see an example of assertion, for example, repo colon star, and where star will expand to
785.24s - 791.58s |  everything using pattern matching. Okay, so this was the summary for, uh, OIDC in the
791.58s - 797.50s |  context of CI. This is how it works. This is the whole magic. So, in the context of CI, we can
797.50s - 802.00s |  say that it is done by asserting incoming ID tokens from CI machine using an identity
802.00s - 807.00s |  federation in exchange for credentials. That's it. Easy. Cool. We can move on to the next
809.54s - 815.68s |  no-configs, and let's have some fun. So, no-configs is basically when there is no one at the
815.68s - 820.56s |  door. If you think about the Auth Z as the bouncer, if the bouncers allows anyone into the
820.56s - 826.76s |  club, then anybody can get in, right? So, a no-config is a state, uh, where the federator is
826.76s - 833.10s |  asserting lax rules, if any. Um, and they will, it will authorize almost any ID token. Okay,
833.10s - 838.14s |  what does it mean? So let's take a look at these 3 snippets. These are snippets from the
838.16s - 842.70s |  identity federation example you just saw, but different assertions. So, the first one, we
842.70s - 847.70s |  have, uh, uh, an asterisk, right? Using pattern matching, it's gonna expand to anything.
847.70s - 852.38s |  Obviously, you didn't check anything here. Um, second option, repo column star, so
852.38s - 856.58s |  everything begins with repo. There's nothing specific to your account here. So, again, you
856.58s - 860.62s |  didn't check anything. And the last one is everything that begins with my org, and
860.62s - 866.66s |  something to note, there is no slash between the org and the star. So, if you open a GitHub
866.68s - 872.32s |  organization called my org one, it will satisfy this as well. Cool. Now, this was already
872.32s - 877.86s |  talked about in, uh, in, uh, 2 talks. One by, uh, Rojan of Tinder, and one by Christoph that
877.86s - 883.76s |  maybe sits in the audience here. So, hi, Christoph. Um, I also talked about it, uh, on the
883.76s - 889.50s |  latest, um, b-sides. And basically, I, I really, I highly recommend watching these talks.
889.50s - 894.68s |  They explain exactly how those misconfigs look like, okay? And how to hunt for them, and how
894.70s - 900.56s |  to exploit them. I'm not gonna talk about, uh, when there's no config kind of situation, um, and
900.56s - 906.48s |  yes, go ahead and watch them. So, since we're not talking about the no config situation, what
906.48s - 912.48s |  happens when I have partial configs? How safe are they, if at all? Let's zoom in. So, the
912.48s - 916.62s |  first one, we're gonna assert everybody in the org name, right? Repo column org name. Let's
916.62s - 922.46s |  say I can say anybody in Palo Alto can access this identity. Is this okay? Is this safe? What
922.46s - 927.74s |  about everybody in Palo with respect to a branch? So, the answer is, the first one is
927.74s - 931.82s |  potentially unsafe, so does the second one. We're gonna see later how we can exploit and
931.82s - 938.62s |  abuse such cases. And the workflow example is actually the worst. This is very bad. If you
938.62s - 943.52s |  configure using the workflow, you're exploited immediately, okay? And we're gonna see how. And
943.52s - 948.20s |  another thing you gotta ask yourself, how come this claim begins with workflow? All you've
948.20s - 954.08s |  seen was repo column. How come we're at workflow column? What happened here? Alright, so
954.08s - 959.64s |  let's move to misconfiguration when you do some configurations, but they're insufficient. Uh,
959.64s - 964.02s |  we're gonna see some pitfalls for advanced configurations, including a demo. And then we're
964.02s - 969.92s |  gonna see how you can abuse, uh, pipelines. This is partially what Adnan, uh, talked about in
969.92s - 976.26s |  the, in the last talk. Um, but we're gonna see how we can abuse lax policies and access, um,
976.30s - 981.30s |  various identities. So, misconfigs. We're gonna start with a short demo. Um, and just click
985.42s - 991.66s |  here. Okay. So, what you see here is a video that was uploaded by, uh, JFrog explaining to
991.66s - 997.00s |  their customers how to configure OIDC in front of, uh, JFrog. So, you can access the
997.00s - 1001.56s |  artifactory, x-ray, et cetera. So, this is a great feature, by the way. Nothing bad to say
1001.56s - 1006.60s |  about them. And what we see in this example is how they configure the identity provider on
1006.60s - 1011.64s |  JFrog's side and how they configure the identity. Here we see the example, uh, claims
1011.64s - 1016.84s |  GitHub allows us to rely upon. And we can see on the right-hand side that they instruct us to
1016.84s - 1023.42s |  assert workflow equals JFrog NPM. This is according to their video. Alright. Um, I'm a
1023.42s - 1029.32s |  naive user. I'm gonna copy-paste that, right? Uh, I just learned OAuth and, and OIDC. So,
1029.32s - 1035.56s |  this is me creating the same identity provider at JFrog. Um, just naming it my provider,
1035.56s - 1040.90s |  et cetera, et cetera. Nothing fancy. I mean, some arbitrary, arbitrary identity. And I'm
1040.90s - 1045.40s |  gonna do the same instruction. I'm gonna assert that the workflow equals corporate usable
1045.40s - 1050.40s |  workflow. This is coming from my corporation. Alright. Um, I'm gonna save it, uh, and then
1053.14s - 1056.84s |  I'm gonna copy the snippet. This is for GitHub Actions. Uh, for those of you who are
1056.84s - 1062.38s |  unfamiliar somehow with this product, this is GitHub's CI. Um, once I saved it, I'm gonna go
1062.40s - 1067.84s |  to my leaking pond repository and I'm gonna create a new GitHub Actions file. I'm gonna
1067.84s - 1072.58s |  commit everything. If you are unfamiliar with how the workflows of GitHub Action looks like,
1072.58s - 1077.26s |  then this is it. This is the recipe. And all you gotta know for the sake of this demo is that
1077.26s - 1083.06s |  assuming a success, the machine invocation as a whole will be successful. Otherwise, it will
1083.06s - 1088.06s |  fail. So, uh, I've committed the CI React to my Git event. So, it fires. Um, we're gonna see a
1088.32s - 1093.32s |  machine being run. And then we're gonna see that this account, as the video instruct us, was
1095.66s - 1100.46s |  indeed able to access GitHub. Now, let's exploit that. Okay? We're gonna use the special
1100.46s - 1106.76s |  technique called copy paste. I'm gonna copy the exact same workflow configuration file. And
1106.76s - 1111.68s |  I'm gonna commit it to my own private, uh, uh, account. Which I was told that it's not safe to
1111.68s - 1116.72s |  do at Defcon, but whatever. Um, gonna do a special commit message cause it's important for
1117.60s - 1123.64s |  nothing. And in reaction, the CI will trigger again. Now, what we will see, uh, we're gonna go
1123.64s - 1127.82s |  into this logs. We're gonna count one, two, three. Worker's gonna pick it up. And we were able
1127.82s - 1132.82s |  to successfully access the same account. Right? From a different account. Amazing. Magic.
1132.82s - 1137.82s |  What happened? Right? What happened here? On JFrog's end, we defined the identity
1140.60s - 1145.20s |  federation to be something, whatever the name of the, uh, provider, but workflow. I'm gonna
1145.22s - 1150.22s |  set the workflow to be corpusable workflow, correct? Good. When my token showed up and said,
1151.48s - 1156.46s |  hi, I'm coming from a Vias repository, et cetera, et cetera, and the workflow is called
1156.46s - 1162.00s |  corpusable workflow, so the federation said, yeah, it's the same claim, get in. And you gotta
1162.00s - 1167.84s |  ask yourself, where is this value coming from? And the answer is, as always, user input. So
1167.84s - 1172.84s |  you can just, this is the name of the workflow, you can put any string there and, yeah. So,
1172.92s - 1177.92s |  copy paste for the win. And we can see, by showing one example, that not all claims are safe,
1181.36s - 1186.06s |  right? I've showed you once, this is sufficient to say that not all are safe. If we look
1186.06s - 1192.04s |  into the RFC of RDC, then basically we're instructed to have five required claims, issuer,
1192.04s - 1196.88s |  subject, audience, expiration, and issued at. Let's translate them to an attacker point of
1196.88s - 1202.18s |  view, the URL of the provider, the target, just a string that you can modify if you have an
1202.18s - 1207.66s |  RC in the case of odd. Expiration time for the RDC token is roughly four minutes, and
1207.66s - 1215.00s |  nobody cares when it was issued. On top of these five claims, we have a plethora of other
1215.00s - 1219.76s |  custom claims. These are given by the CI vendors, which get to be the identity providers,
1219.76s - 1225.70s |  right? For example, GitHub supplies with various claims, but all of these are unique to GitHub,
1225.70s - 1230.48s |  right? Repository owner, runner, environment, run number, whatever, whatever, these are all
1230.48s - 1235.92s |  GitHub unique. If we go to Circle, they have their own world, right? Workflow ID, VCS origin,
1235.92s - 1242.80s |  whatever, whatever, and GitLab has their own stuff, right? Nobody, like, what's going on? So,
1242.80s - 1247.24s |  it adds up to a lot of confusion. If you're at DevOps for a company and you're trying to set up
1247.24s - 1252.40s |  using custom claims, you can get lost really quickly, because you have so many and there's
1252.40s - 1258.40s |  almost zero instructions on which values are safe in this context. So, if you'd like to have
1258.40s - 1264.20s |  a situation like I just showed, a rule of thumb for using custom claims coming from the
1264.20s - 1269.00s |  vendor is to remember that they're provided regardless of their strength. By strength, I mean
1269.00s - 1277.34s |  how hard they are to fraud. So, check where the values come from, okay? Now, a hidden pitfall
1277.34s - 1287.36s |  of this behavior or this basically behavior is the custom claim format feature, okay? So, as
1287.36s - 1293.60s |  the name suggests, it's a custom format, and it comes to answer a problem where some federators
1293.60s - 1298.84s |  do not assert custom claims directly, like we saw with JFrog asserting workflow. Some just don't
1298.84s - 1304.32s |  want to do that. Why? I don't know. It's just a JSON. But therefore, some identity providers
1304.32s - 1309.64s |  allow reformatting the structure of the subclaim to contain custom claims values, okay? What do I
1309.64s - 1315.72s |  mean by that? Consider the top option. This is what you're familiar with. It begins with repo
1315.72s - 1320.64s |  and then the ref, right, the git ref. But now you can put actor ID, this in GitHub's world. So,
1320.64s - 1325.96s |  now you can put actor ID and repository ID, and it will be later populated with the values with
1325.96s - 1332.56s |  respect to where this was fired from, where the CI ran from. So, something that can be easily
1332.56s - 1339.48s |  missed with this feature is that the claims order is critical, all right? Let's see why. Consider
1339.48s - 1344.60s |  this format and this claim. So, we're going to have repo, my org, and then the name of the
1344.60s - 1350.84s |  workflow, fine. So, we all know by now that this is very unsafe, right? I just showed you how it
1350.84s - 1357.00s |  can be abused. But this one is actually safe. The prefix is safe. Why? Because GitHub will
1357.00s - 1361.08s |  actually put the name of the organization and repository. You can't just fake that, at least not
1361.08s - 1366.56s |  in this talk. But you can't just fake that. So, this is fine. This is an example of fine, although
1366.56s - 1372.32s |  it relies on unsafe claim for the second half of it. If you flip it, however, then you're done
1372.32s - 1380.88s |  with, okay? So, let's see how. In order to abuse such a case, basically, all you have to do is
1380.88s - 1387.40s |  create a workflow, name it everything after the workflow prefix, go to your favourite CI provider,
1387.40s - 1393.08s |  change the subclaim to be workflow only, and they will grant you with a pretty and beautiful
1393.08s - 1398.08s |  signed token that has the exact same claim like the other organisation asserts. Obviously, you
1398.08s - 1405.28s |  can put whatever, my org in Palo Alto, Microsoft, you can just write whatever. So, a rule of
1405.28s - 1409.68s |  thumb for this feature is that the claims order is critical. I haven't seen even one manual page
1409.68s - 1414.44s |  that mentions that. When you use custom claims, they just let you use it, but they don't tell you
1414.44s - 1422.60s |  what not to do. So, the order is critical. In order to help everybody here to either escape from
1422.60s - 1430.00s |  these bugs or to exploit them, I've created this tool. You can scan the QR code to get the latest
1430.00s - 1436.40s |  zero click for your Android. But basically, it lists all the GitHub possible custom claims with
1436.40s - 1441.00s |  information about the strength of each one. This is a nice guide. It can check your subclaim
1441.00s - 1446.28s |  format for safety, and it will allow you to modify the subclaim if you want to attack with it or you
1446.28s - 1450.52s |  just want to fix it for your organisation or repository. There is some hierarchy option, so
1450.52s - 1455.60s |  it's interesting. This is how the tool looks like. All you've got to bring is your favourite
1455.60s - 1461.64s |  GitHub token with admin permissions, not necessarily of your organisation, but, yeah. And,
1461.64s - 1465.16s |  for example, in the inspect mode, you can see that these are the claims, and they're not safe
1465.16s - 1473.52s |  because it's set right surplus, so go ahead, get a zero click, and, yeah. Okay. Now, this is
1473.52s - 1479.96s |  behind us, and let's move into pipeline abuses that can lead to OIDC abuse. Basically,
1479.96s - 1486.32s |  misconfigs that lead to abuses, abuses, sorry, of lax policies. So we saw that this was very
1486.32s - 1493.04s |  bad, right? We now know why this is, this sucks. But what about these two? We did just say
1493.04s - 1500.76s |  that, for example, saying everybody in Apollo is fine, right? Or not? So let's abuse those. The
1500.76s - 1505.56s |  answer is pretty simple. Poison pipeline execution, which is the most common entry vector
1505.60s - 1512.44s |  for CIs, right? And lax policies. So let's explain for a second. A PPE is a pull request from a
1512.44s - 1516.92s |  fork that will trigger a vulnerable CI execution in the context of the target, right? We're all
1516.92s - 1523.64s |  familiar with this by now. I hope so. The second bit, the lax policies, they will allow a token
1523.64s - 1529.56s |  from the same, from the targeted organisation, sorry, to slip through lax policies, okay? Now
1529.60s - 1536.32s |  what do I mean by that? Let's see how it plays. Demo. In order to demo that, we have to define a
1536.32s - 1540.84s |  few entities, right? Let's begin with the identity federation on the resource side. So we're
1540.84s - 1546.32s |  gonna set up something like this. We wanna assert that the audience equals, uh, the Amazon AWS
1546.32s - 1551.56s |  thing. Um, and we wanna assert that all the identities coming in from the banana multi
1551.56s - 1557.28s |  organisation are okay to go in. This is the federation. If you put it, by the way, on AWS, it's
1557.28s - 1562.60s |  gonna look something like this. And although AWS did some changes in order to enforce more
1562.60s - 1569.60s |  strict policies, they will allow you to do that. This is fine by AWS. Now for the git part,
1569.60s - 1575.80s |  let's see what's our setup. We have this organisation called banana multi and we have two, uh,
1575.80s - 1582.32s |  basically pipelines including the git repo itself. And let's explain. So the upper one, um, is a
1582.32s - 1588.20s |  pipeline that is configured to connect using OIDC to an S3 role that is, uh, an admin. Um, this
1588.20s - 1594.20s |  policy is the policy that we just saw, so it's lax. Um, and this is our target. The second pipeline
1594.20s - 1600.38s |  is called any updateser and, uh, it contains, it's connected to a vulnerable pipeline and then
1600.38s - 1606.52s |  it's using an OIDC token again to access a restricted S3, uh, uh, bucket or a role and we
1606.52s - 1613.50s |  obviously cannot use that. So let's see our attack vector. Pretty simple. We're gonna fork the
1613.50s - 1620.16s |  any updateser and we're gonna, uh, um, basically invoke the CI machine of the, the CI workflow,
1620.16s - 1625.34s |  sorry, of, uh, and we're gonna invoke the vulnerable CI workflow and we'll try to access the
1625.34s - 1631.38s |  other accounts. Um, the workflow, by the way, looks something like this. It has to react to pull
1631.38s - 1636.28s |  request, maybe pull request or pull request target for the GitHub world. Um, and you have to
1636.28s - 1642.92s |  specify that you want an ID token that the workflow has to say it. Um, the pipeline is gonna
1642.92s - 1646.90s |  check out the fork. This is the head for the pull request. Uh, we're gonna skip the part where it
1646.90s - 1652.40s |  actually assumed the AWS role. We don't, we can't use that so we don't care. And then there's an
1652.40s - 1658.08s |  invocation of a file from the file system which was just cloned from the fork and yeah, we have
1658.08s - 1663.92s |  RCE. So what we need to do now is make the fork pull request. This is what's called IPP,
1663.92s - 1670.72s |  indirect points of pipeline execution. And this is the exploit script. Don't rush and, and, and
1670.72s - 1676.22s |  take pictures. It's just chat GPT. Um, but basically all you have to do before you make this
1676.22s - 1682.56s |  exploit code, you have to, uh, to do some recon and collect various id- accounts that are, are
1682.56s - 1687.40s |  connected through using OIDC. Okay? I'm not gonna talk about it in stock, but this is
1687.40s - 1691.80s |  something you have to do. In this example I'm having 2 roles at the top that I'm gonna try to
1691.80s - 1697.60s |  exploit. Let's see it in action. So this is the prepare.sh file that is gonna be invoked at
1697.60s - 1702.60s |  some point. Uh, this is my fork. Any updates sir? And I'm gonna open a pull request. So, uh,
1705.00s - 1709.32s |  hello it's me. The diff is the same file, nothing but this file. And I'm gonna open the pull
1709.32s - 1717.27s |  request and it's gonna invoke the CI in response to the trigger. Cool. 3 seconds from now we're
1717.29s - 1722.29s |  gonna see the machine logs. 1, 2, 3, as I promised. And now in the logs we will see in the
1724.83s - 1729.89s |  prepare step that it, we will see the output of my script and if we're successful we'll see
1729.89s - 1735.03s |  sets of credentials. And I wouldn't be here if it would work, so yeah, we have sets of
1735.03s - 1739.11s |  credentials. So we were able to assume a role that was not allocated to the pipeline we were
1739.11s - 1743.71s |  running at. While we were not able to assert others, but again you can just spray OIDC
1743.75s - 1748.43s |  tokens. So this is a very nice technique. You can just collect tokens, find vulnerable
1748.43s - 1752.99s |  pipelines and start spraying for, to find the locks policies internally, right? You're
1752.99s - 1760.14s |  already past the auth end. You have the credentials. So give it a shot. 1 second. Okay, uh,
1763.36s - 1768.16s |  some nice disclosure. I was able to, this is by the way from last year already and, and I was
1768.16s - 1773.00s |  able to find this, uh, a month ago in Azure and this allowed to access basically all the
1773.00s - 1778.58s |  identities that had Azure slash star. So yeah, nice technique. Um, the rest did not allow
1778.58s - 1783.58s |  disclosure, but you're out there. Cool. So rule of thumb in order to avoid this type of stuff,
1786.46s - 1791.46s |  one is for the CI, please follow the best practices. We're at 2024. Um, we, my team, we've
1793.46s - 1799.36s |  released plenty of guides on how to, uh, harden your pipelines. Please do so. The second
1799.36s - 1804.36s |  thing, pursue, uh, policies that are not with wildcards as much as you can or, uh, use other
1806.56s - 1811.58s |  claims that are safe in order to assert identities. Okay, this brings us to our last topic
1814.54s - 1818.38s |  of the day and this is when, when the vendor misconfigures. Now that you know that the vendor,
1818.38s - 1823.46s |  the CI vendor is also the identity provider, now they have to put, to give more attention to
1823.46s - 1828.32s |  the details, right? They have various products at their hand now and they have to be very
1828.32s - 1833.32s |  careful. So this is a disclosure for a Circle CI. Um, and basically if you're unfamiliar with
1834.92s - 1839.82s |  Circle, they're a great CI product. Um, they provide various machines, right? In order for you
1839.82s - 1845.80s |  to run your workloads and they're super nice and professional folks on a personal level. Okay?
1845.80s - 1850.48s |  When I looked into, oh, just to explain, uh, Circle, sorry, um, this is you, you perform Git
1850.48s - 1854.88s |  push. You're all familiar with this diagram by now. Well, you notify Circle with a payload and
1854.90s - 1859.84s |  they did your CI thing for you. Now when GitHub notifies Circle, by the way, they do that with
1859.84s - 1865.64s |  the webhook and the payload is everything that was, that is in your Git context. So in a way,
1865.64s - 1871.02s |  and just to add to the confusion, Circle can supply you with a super set of claims on top of
1871.02s - 1874.36s |  GitHub's claims. If you think about it, just to add to the confusion from earlier, I see your
1874.36s - 1880.56s |  faces, so yeah, it's confusing. Um, okay, so when I looked into Circle CI system state, I
1880.58s - 1884.78s |  noted the following. First, pipelines reacted to fork pull requests if and only if, there's no
1884.78s - 1889.98s |  typo, uh, the project is configured to do so. Now this is actually a good limitation, right? We
1889.98s - 1894.46s |  don't want anybody on the internet to run machines for us. Putting aside security, someone's
1894.46s - 1900.46s |  gotta pay for that. Okay, but second thing that I noted is that pipelines were triggered, uh, on a
1900.46s - 1906.16s |  workflow change, even from a fork. Okay? And this is not good. Why? This implies every pull
1906.20s - 1911.20s |  request can be an RC, you can just commit, basically pull request a malicious workflow. Okay,
1913.88s - 1919.34s |  doesn't look good, but the third part was the, the cherry on top. An IDC token was always
1919.34s - 1925.18s |  granted to the machine regardless of anything. And this is credentials mishandle and misuse.
1925.18s - 1931.86s |  Okay? So combining those, I was granted an ID token in the context of any Circle CI project
1931.86s - 1936.50s |  that allowed fork pull requests. Okay, what does it imply? What does it mean? Is that I was
1936.50s - 1941.80s |  able to access OIDC gated resources of any Circle CI organization that allowed fork pull
1941.80s - 1947.88s |  requests. Right, that's basically everybody on Circle that has pull requests and OIDC. Nice
1947.88s - 1953.02s |  amount. Um, the attack flow is pretty simple, you just saw a demo of that using, uh, another
1953.02s - 1956.68s |  file, right, the prepare, so I'm not gonna show the same thing, all you've, you had to do
1956.68s - 1961.16s |  basically is, uh, pull request the workflow. So I'm not gonna show that, I will talk about the
1961.16s - 1966.96s |  disclosure, however. So in order to show Circle CI that this was indeed a bug, I looked for
1966.96s - 1973.40s |  instances in the wild to support my case. Um, it wasn't long ago until I found this file. Now,
1973.40s - 1978.38s |  this was by a company called Darklang, anybody here familiar with those folks? Hands up? No?
1978.38s - 1984.28s |  Okay. Um, just to explain this file, this is an identity federation for, uh, GCP, and even
1984.28s - 1988.42s |  though you don't know this, this cell language, uh, GCP's language, you can understand the
1988.42s - 1992.76s |  mapping here, right? We know that CircleCI.com, we know this is the provider, and we know
1992.76s - 1997.66s |  project ID is the claim, and we're gonna map it to project, audience to organization ID, and
1997.66s - 2002.60s |  sub to sub, right? We now know what these claims are. Um, per the condition, the condition was
2002.60s - 2007.60s |  that any one of these three project IDs is okay to access. And something that I cared, but
2010.04s - 2015.64s |  then didn't care for the exploitation was that the issue URL and the allowed audience had to
2015.66s - 2020.84s |  be the organization, uh, ID. Now this is fine as long as you create a pull request within the
2020.84s - 2024.64s |  organization, Circle will just provide you with the ID, right? You're in the context of the
2024.64s - 2030.74s |  organization, so this part is fine, we don't need to care about that. Um, so basically, a
2030.74s - 2036.28s |  fork PR to any of those projects, um, which indeed they allowed fork PRs, uh, granted access
2036.28s - 2040.96s |  to their clouds, that was it, as simple. Okay, just detect the misconfig, pull request,
2040.98s - 2046.68s |  enjoy the cloud account. So, good summary on me, I'll disclose to the company so they can fix it,
2046.68s - 2053.06s |  and meanwhile, meanwhile I'll go to Circle. I went to Darklang's, uh, Discord, asking for, uh,
2053.06s - 2059.16s |  bug bounty cause I like it, and, but there was none, so I was told to DM, uh, DM someone, um,
2059.16s - 2063.60s |  this is the someone, PBigger, I don't know if someone is familiar with this name, but yeah, we're
2063.60s - 2068.88s |  gonna see exactly how you are familiar. But, um, yeah, he told me DM me, which I did, I sent, uh,
2069.10s - 2073.26s |  I sent them everything, and I also added the line, the reason, at the bottom, sorry, the reason is
2073.26s - 2076.60s |  not safe, it's not because of you, it's because of a bug in Circle, right? I mean, you're fine,
2076.60s - 2081.98s |  just defend yourself, it's them, not you. Um, I also asked them to not disclose right now, I
2081.98s - 2085.74s |  don't know who is aware of that, I don't want anybody to exploit, I'm, uh, white hat at that
2085.74s - 2090.88s |  point, uh, I don't want anybody to exploit, um, so don't talk to anybody. Um, PBigger replied
2090.88s - 2094.82s |  that he was investigating, and then he confirmed it and blocked all access. By the way, this is
2094.82s - 2101.10s |  exactly where OIDC kicks in. By ticking one box, he was able to kill all the GitHub, basically
2101.10s - 2106.44s |  all the, um, OIDC connections coming from Circle, okay? This is very powerful. No rotations
2106.44s - 2112.44s |  needed, no credential changes, just one box. Um, he was fixing that, and we were, we
2112.44s - 2116.88s |  continued chatting, later on, he said again that he was very happy to seal it, to which I
2116.88s - 2122.62s |  replied, no problem. To which he replied, uh, by the way, I sent a note to the security folks
2122.62s - 2127.62s |  at CircleCI, I wasn't sure if you knew, but I founded Circle. Yeah. So, just a random dude
2134.56s - 2141.58s |  on Discord, right? So, a good advice here would be to attempt to not disclose directly to the
2141.58s - 2148.34s |  board member, or the CEO, it can be a bit awkward and odd. So, yeah. This was, uh, June 23,
2148.34s - 2153.20s |  Circle since then fixed this bug and sealed it, and now if you look into their OIDC page, you
2153.20s - 2158.62s |  see this message, what about forks, and basically, uh, you have to opt in now. Like in GitHub, I
2158.62s - 2162.88s |  told you you have to set up ID token, right? This is the same thing, you have to opt in, this is
2162.88s - 2168.06s |  done in a different manner, but the same idea. You have to opt in in order to provide a fork, a
2168.06s - 2174.12s |  machine that is running for fork pull request, an OIDC token. Um, this changes this state, and
2174.14s - 2180.48s |  now we have a proper handling. You can see that, um, part two is still there. Uh, some
2180.48s - 2185.48s |  integrations in Circle still react to that, so, enjoy the misconfig. Um, and this is roughly,
2188.16s - 2192.52s |  this is our conclusions and takeaways. So, first of all, I hope that now you know what OIDC is.
2192.52s - 2197.30s |  It's not that hard, right? I was talking to folks before and they were giving me weird faces, like
2197.30s - 2202.30s |  yeah, I know, know OIDC, know. So, I hope you know it now, relax, it's fine, it's chill, okay? Um,
2204.40s - 2209.54s |  plus you already learned OAuth, this is the big thing to, to swallow here. Um, second thing, and
2209.54s - 2215.18s |  this is actual takeaways, so, for in using OIDC NCI, do the following, uh, learn the origin of
2215.18s - 2219.42s |  each claims, I've provided the tool for GitHub again, but, um, learn the claims for your
2219.42s - 2225.46s |  identity providers, uh, pursue policies without wildcards, and always think, always think which
2225.46s - 2230.46s |  other identities can satisfy my conditions. Last bit, please harden your pipelines, sometimes
2230.70s - 2235.70s |  it's too easy, that's it. So, yeah. Um, and yeah, but that's basically it, thank you very much. Um,
2241.18s - 2250.53s |  yeah, I'm here for questions, if there are any. Questions? Beers? Shots? No? See you around.


url: https://www.youtube.com/watch?v=mKRS5Iyy7Qo
title: DEF CON 32 - MaLDAPtive: Obfuscation and De-Obfuscation - Daniel Bohannon, Sabajete Elezaj
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=mKRS5Iyy7Qo",
  "title": "DEF CON 32 - MaLDAPtive: Obfuscation and De-Obfuscation - Daniel Bohannon, Sabajete Elezaj",
  "description": "DAP is no stranger to the security spotlight. While LDAP is a protocol (Lightweight Directory Access Protocol) and Active Directory is the most popular directory services system that supports a subset of LDAP, the terms \u201cLDAP\u201d and \u201cAD\u201d are tightly coupled when discussing the execution, detection and prevention of attacks targeting directory services data.\n\nIn the last decade the widespread offensive value of querying AD data via LDAP was cemented with the release of open-source tools such as BloodHound and PingCastle. However, proper visibility of LDAP queries mostly remains a privileged asset for those organizations with deep pockets, and the commercial security tools providing this visibility are often woefully fixated on simple signature-based detections.\n\nMaLDAPtive is the 2,000-hour (and counting) quest of offensive and defensive LDAP exploration and tool-building. This research includes mind-bending depths of obfuscation across all elements of LDAP queries (many undocumented and most never seen in the wild), all baked into an obfuscation/de-obfuscation/detection framework built upon our ground-up custom LDAP search filter tokenizer and syntax tree parser.\n\nCome witness the release of our MaLDAPtive research and open-source framework: transforming LDAP from \u201clightweight\u201d to \u201cheavyweight.\u201d",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2802,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 How's everyone doing? I'm genuinely surprised. So either
12.76s - 15.14s |  y'all went to bed early or you never went to bed. So thank you
15.14s - 18.70s |  so much for being here. This talk is maladaptive. It's diving
18.70s - 22.70s |  really, really deep into LDAP obfuscation, deobfuscation and
22.70s - 26.62s |  detection. My name is Daniel Bohannon. Everyone I know calls
26.62s - 29.78s |  me Debo for short, so feel free to call me that. I'm a principal
29.78s - 32.58s |  threat researcher for a startup company called Permiso Security
32.58s - 35.52s |  doing cloud and identity stuff. For the last better part of a
35.52s - 39.08s |  decade, I've been really focused on end point security, doing
39.08s - 42.38s |  some IR and threat research at Mandiant, Microsoft. And I have
42.38s - 45.56s |  a little bit of a problem with obfuscation. It's kind of an
45.56s - 48.20s |  obsession of mine of taking things that look normal and
48.20s - 52.16s |  making them look just absolutely crazy. And then as a defender,
52.20s - 54.90s |  looking for ways to detect those things. Another thing I'm really
54.90s - 57.04s |  passionate about is coffee and books and all the great
57.04s - 59.04s |  conversations that happen around both of those things.
59.04s - 66.14s |  Hello, everyone. So I'm Sabayita. You can call me Sabi for
66.14s - 70.34s |  short. I'm originally from Albania, recently moved to
70.34s - 74.48s |  Germany, Berlin, working for Solaris as a senior cyber
74.48s - 78.48s |  security engineer. I'm passionate about cyber defense.
78.52s - 83.30s |  Currently, I'm also working on the field, doing a little
83.30s - 86.40s |  incident response detection engineering and time and time
86.42s - 90.36s |  allows threat hunting. I do have also some experience in
90.36s - 94.50s |  consulting and government. Love mountains. You can see even the
94.50s - 98.70s |  gold there. And enjoy moving a lot at the Great Espresso.
98.70s - 103.39s |  All right. So to kick things off, we're going to do a little
103.39s - 106.41s |  historical lesson on Active Directory and LDAP. And then
106.41s - 108.63s |  we're going to break down kind of the components of LDAP so we
108.63s - 111.15s |  know which pieces we're talking about when we get into the main
111.15s - 114.13s |  piece of the talk, which is diving crazy deep into all the
114.13s - 116.77s |  obfuscation. And then at the end, we'll talk more about our
116.79s - 119.73s |  solution. We don't like to just create problems. We want to
119.73s - 121.33s |  actually have some real solutions there so that
121.33s - 123.99s |  defenders can walk away equipped with something really
123.99s - 128.47s |  beneficial. And then we'll do a demo and a tool release at the
128.47s - 132.87s |  end. So let's get going. We are going to go back in time to the
132.87s - 135.31s |  days of disco balls and DeLoreans, talking about the
135.31s - 139.85s |  1980s. The Directory Access Protocol, or the DAP, was a
139.85s - 142.81s |  directory service kind of at that time. LDAP is the
142.83s - 147.23s |  lightweight version. That's the L in LDAP. Between 93 and 97,
147.23s - 149.03s |  you have three different versions of LDAP come onto the
149.03s - 154.17s |  scene. In 1998, the Open LDAP Project released Open LDAP. And
154.17s - 156.01s |  then what's important for this presentation is in the year
156.01s - 160.11s |  2000, Microsoft released Active Directory in which they kind of
160.11s - 163.75s |  ensured compliance with LDAP. So it's important to remember
163.75s - 167.29s |  there's a server and client side component here. So Active
167.29s - 169.99s |  Directory, we chose that because it's the most popular, most
170.01s - 173.51s |  widely used application service or directory service
173.51s - 176.21s |  application in use. And so we wanted to make sure all the
176.21s - 179.39s |  rules of obfuscation that we were discovering and building
179.39s - 183.01s |  would work against an Active Directory server. So that's the
183.01s - 185.83s |  server side component. You have clients that will issue LDAP
185.83s - 189.93s |  queries or LDAP, what are called search filters. And then LDAP is
189.93s - 191.83s |  literally the protocol that allows that exchange of
191.83s - 195.89s |  information between the client side and the server side. On the
195.93s - 200.87s |  offensive side, LDAP or AD in general is quite a popular
200.87s - 203.27s |  topic. And you look at open source tooling in the last
203.27s - 206.01s |  decade, you have things like PowerView from the folks at
206.01s - 209.25s |  SpectreOps, BloodHound, SharpHound, SoapHound, any kind
209.25s - 211.89s |  of hound, right? Looking for really quick ways to get
211.89s - 214.59s |  information from an offensive perspective, but also for
214.59s - 217.59s |  defensive perspectives. With BloodHound and PingCastle,
217.59s - 220.63s |  looking for ways to give defenders quick visibility into
220.63s - 225.63s |  attack paths so that they can make better choices and
226.41s - 230.45s |  increase the complexity for an attacker just to come in and get
230.45s - 233.91s |  a really short path to DA or whatever else they want. So as
233.91s - 236.41s |  defenders, we should then ask, okay, if attackers are using
236.41s - 240.29s |  this, what are our data sources for defending? And so this is
240.29s - 243.05s |  actually kind of a point of frustration for us. When we
243.05s - 245.95s |  started this research, even till today, there's not that many
245.95s - 249.43s |  options for production ready telemetry gathering for LDAP
249.43s - 253.49s |  search filters. What we use in our lab environment was Silk ETW
253.49s - 256.53s |  by Ruben Boonen, and actually one of the modules that were
256.53s - 259.79s |  released with Mount Adaptive is a telemetry module to allow you
259.79s - 261.93s |  to install these things, configure them, so you can have
261.93s - 264.41s |  locally that client-side visibility. And then on the
264.41s - 267.41s |  server side, there are options like, kind of like debug mode
267.41s - 269.57s |  options, but those are not generally recommended to turn on
269.57s - 272.97s |  in production. So if you want this visibility in production,
272.97s - 277.05s |  the best case right now is get Microsoft Windows Defender.
277.05s - 279.45s |  CrowdStrike has some stuff I've heard as well, but in terms of
279.45s - 283.15s |  like, if you want to just trust the detections they have, cool.
283.15s - 286.31s |  If you want to have all the data so you can validate, then maybe
286.31s - 290.39s |  explore your options a little bit. So another thing to keep in
290.39s - 292.65s |  mind is there are big differences between client-side
292.65s - 296.03s |  and server-side logs when it comes to LDAP. For all the
296.03s - 298.69s |  hackers in the room, you're going to love client-side logs
298.69s - 302.07s |  because it's basically like WYSIWYG. Like any obfuscation
302.07s - 305.13s |  we're going to talk about, you put that in, that's exactly what
305.13s - 307.63s |  it looks like in those client-side logs. Awesome for
307.63s - 311.27s |  obfuscation evasion. With an important caveat, it depends how
311.29s - 315.47s |  you're issuing that query. So a lot of the mechanisms, like the
315.47s - 321.41s |  ADDZ accelerator in PowerShell, will use the WLDAP32.dll to
321.41s - 324.67s |  route that request. If that's the case, then the data will show
324.67s - 327.75s |  up in an ETW stream for the LDAP provider and you can scoop it
327.75s - 331.55s |  out. However, some folks have noticed there are many other
331.55s - 335.15s |  ways to talk to an Active Directory server. So Soap Hound
335.15s - 337.83s |  is an example from Falcon Force where they said, hey, let's just
337.83s - 340.69s |  make soap requests directly to the domain controller and avoid
340.71s - 344.75s |  any kind of client-side logging. So because of this, it's still a
344.75s - 347.65s |  valuable data source, but it's important to look at the server
347.65s - 352.33s |  side logs as well. There is significant normalization that
352.33s - 355.59s |  occurs in server-side logs. So a lot of the obfuscation we'll
355.59s - 358.53s |  talk about is normalized, but there are still some interesting
358.53s - 362.27s |  tricks that do persist. And yeah, that's all I'll say about
362.27s - 366.91s |  that right now. So over the next 40ish minutes, we're going to be
366.91s - 370.55s |  doing an absolute speed run through all of the obfuscations
370.57s - 375.05s |  that we've enumerated and built out for this research. This is
375.05s - 378.95s |  something we've spent over 2,000 hours of R&D on. For the record,
379.25s - 382.21s |  that's too much R&D. Don't recommend it to anybody. But
382.21s - 386.09s |  here we are. So we're really happy to get this out there and
386.09s - 388.85s |  then let our minds think about something else. And as I
388.85s - 390.73s |  mentioned earlier, we're going to be doing a demo and tool
390.73s - 394.07s |  release for maladaptive. And the name comes from maladaptive
394.07s - 396.37s |  because typically people would think of LDAP queries as like a
396.37s - 400.31s |  pretty simple, rigid kind of a language. So how flexible can it
400.33s - 402.93s |  really be? And we hope to convince you pretty quickly
402.93s - 406.77s |  that it can be pretty flexible. So with that, let's look at the
406.77s - 409.45s |  LDAP overview so we know which pieces of an LDAP search
409.45s - 412.15s |  request we're talking about for each obfuscation technique.
414.56s - 420.16s |  So we're going to let's dive deep into the anatomy of an LDAP
420.16s - 424.74s |  search request. We'll be looking at RFC 4511. There are many
424.74s - 428.40s |  components to an LDAP search request, but we're going to be
428.40s - 434.40s |  focused on the four main ones, which is the base object, where
434.40s - 437.60s |  in the active directory structure to start the search,
437.88s - 442.24s |  the scope that says how far to let the search run, the filter,
442.28s - 445.76s |  which is the logic of what to look for in the directory
445.76s - 449.04s |  structure, and the attribute selection, which are the
449.08s - 454.72s |  properties that we want to bring back. As defenders, most people
454.72s - 459.12s |  focus on the filter for detecting malicious LDAP
459.12s - 462.84s |  queries. So for this reason, it's also going to be our
462.84s - 468.72s |  primary obfuscation focus. We don't want to overlook also the
468.72s - 472.20s |  base object and attribute selection. So they are going to
472.20s - 477.28s |  be our secondary and tertiary obfuscation focus. As filter is
477.28s - 481.08s |  the main one, let's see what it's made, what makes up a
481.08s - 485.12s |  filter. So well, it's made up of tokens, there are five
485.12s - 489.48s |  required tokens that we have group start and group end, they
489.48s - 493.56s |  hold in the middle the attribute and the value for it, and the
493.56s - 497.68s |  comparison operator. So here, for example, we are looking, I'm
497.68s - 503.52s |  looking for myself, basically. There are also two optional
503.52s - 507.44s |  tokens, which is boolean operator and extensible match
507.44s - 511.56s |  filter. Debo is going to talk about these in the upcoming
511.56s - 515.12s |  slides. But just so you know, these are bitwise values, they
515.12s - 518.60s |  have different meanings based on the attributes, and Microsoft
518.60s - 522.48s |  documents all of these per attribute. So different numbers
522.48s - 529.12s |  mean actually different things to different attributes. In this
529.12s - 532.00s |  one, basically, we're looking for objects that are not
532.00s - 536.44s |  disabled, let's say. Most people actually do not write simple
536.44s - 540.56s |  filters like this, they do try to combine multiple filters, and
540.56s - 544.84s |  they do that with a boolean operator to create a filter
544.84s - 552.68s |  list. So it's not going to look actually as a pretty tree just
552.68s - 557.48s |  like this one, but as a single row, usually. So it's going to
557.48s - 560.52s |  be composed of two filters, which together they make up a
560.52s - 564.20s |  filter list. And the whole string is actually called the
564.20s - 566.52s |  search filter for an LDAP search request.
569.33s - 573.01s |  Oh, sorry. No, we don't don't need help with PowerPoint
573.01s - 574.77s |  transitions. Moving on.
578.16s - 581.36s |  Hold on. It looks like you could use some help with crowd
581.36s - 586.84s |  where hilarious. Oh, clippy. I have trivia and jokes. I don't
586.84s - 588.60s |  know I could use that on a Sunday morning. How about y'all?
590.24s - 593.16s |  What do you call the biggest LDAP search request in history?
594.08s - 599.68s |  Any takers? It's pronounced 10 and a half megabytes. Because
599.68s - 603.36s |  that's the limit for a search request. Now, clippy actually
603.36s - 607.16s |  comes armed with sources. But just know that that's a lot of
607.16s - 609.68s |  data. And keep in mind LDAP is not just for querying
609.68s - 612.04s |  information. It's also for updating records. But for the
612.04s - 615.60s |  purpose of recon, I encourage anybody in this room to issue
615.60s - 618.96s |  something even close to 10 and a half megs and see how much
618.96s - 623.52s |  shows up in your logs. All right. Thanks, Sabi. So now that
623.52s - 625.84s |  we had a good idea of the different components of LDAP
625.84s - 628.40s |  that we're going to be looking at, let's actually do the fun
628.40s - 632.20s |  stuff of obfuscation. For all the defenders in the room, it's
632.20s - 635.36s |  going to get dark and bleak before it gets bright again. But
635.36s - 638.96s |  we promise there is a light at the end of the tunnel. So as
638.96s - 641.00s |  Sabi mentioned, the filter is going to be the primary
641.00s - 644.12s |  obfuscation focus because it really is kind of the primary
644.12s - 647.48s |  defensive detection focus today. And we're going to spend most of
647.48s - 649.92s |  our time on the filter. And then a lot of the techniques
649.92s - 652.52s |  that work on the filter will then be applied to the base
652.52s - 657.12s |  object and attribute selection as well. There's a lot of things
657.12s - 660.76s |  that we discovered that are not documented. Some of it was sheer
660.76s - 663.24s |  luck. Some of it was brute forcing. Some of it was the fact
663.24s - 664.92s |  that when you build an obfuscation framework, you're
664.92s - 667.24s |  kind of defining the boundaries of a language and it's going to
667.24s - 670.56s |  break out sometimes and teach you things that still work. And
670.56s - 674.12s |  so we'll try to mention things that are undocumented and then
674.16s - 677.68s |  also put this undocumented icon at the top. So we're going to
677.68s - 680.76s |  start by looking at these five tokens and looking at
680.76s - 683.40s |  obfuscation that can be applied to each, beginning with the
683.40s - 684.12s |  attribute token.
687.48s - 692.60s |  So let's see how what we can do to obfuscate the attribute. We
692.60s - 696.08s |  can actually do casing. It is case sensitive, so we can play
696.08s - 703.00s |  with it. We can use object, our OID object identifier. OID
703.00s - 706.56s |  object identifier, Microsoft defines it as a dotted string
706.56s - 710.64s |  of numbers, which is actually quite true, because you can also
710.68s - 713.80s |  add this OID prefix at the beginning of it, and it's still
713.80s - 718.12s |  going to work, which is also case sensitive. Another thing
718.12s - 722.52s |  that is really fascinating and undocumented is that we can add
722.52s - 727.44s |  prefixes of zeros to each octet on this part, and it executes
727.44s - 731.00s |  just fine. It will also show just like this also on client
731.00s - 736.24s |  sidelocks. Another thing we can do for attribute obfuscation is
736.28s - 741.48s |  ambiguous name resolution. So the same applies as above. So we
741.48s - 746.12s |  can use insensitive casing and OID notation even for the ANR.
746.72s - 751.32s |  But what is exactly ANR? So in case you know some name, but you
751.32s - 756.40s |  don't know in which property it actually is, you can search and
756.40s - 759.00s |  what it would actually do depending on the version of
759.00s - 762.64s |  Active Directory, it will logically transform this single
762.64s - 768.04s |  term into this query. So basically everything is ended in
768.04s - 771.72s |  a wildcard, except for some attributes that do not support
771.72s - 776.56s |  this. And in case your search actually contains a space just
776.72s - 781.28s |  like us, we are looking for domain admins. Then it's going
781.28s - 785.84s |  to be added another this one. So these four ones, because it
785.84s - 788.56s |  will treat it as a first name, last name, last name, first
788.56s - 793.92s |  name. Some nice obfuscation tricks. So we can use ANR, for
793.92s - 797.96s |  example, if we're trying to search for curb TGT. And we can
797.96s - 801.68s |  also use which is the second example, only the some parts of
801.68s - 805.44s |  it, and it's going to be an explicit wildcard. So we'll
805.44s - 808.24s |  still even on the second example, we are still going to
808.24s - 812.80s |  have the same results. And the third example, which is very
812.80s - 816.64s |  nice, we actually discovered that if you add an implicit
816.64s - 822.40s |  wildcard, after that, everything you add is going to be ignored.
822.96s - 826.76s |  So you can play with it, but you're still going to be to get
826.76s - 834.52s |  the result of ANR and return the curb TGT. And just as this also
834.52s - 838.24s |  going to be handled from our detection framework. If you
838.24s - 842.60s |  don't want to do all the crazy stuff with a wildcard, and just
842.60s - 846.76s |  be explicit, you can actually just add an equal sign, which is
846.76s - 849.20s |  document the which is the documented way to get the
849.20s - 855.16s |  information. As a recap, for attribute obfuscation, we can
855.16s - 858.84s |  do casing, object identifier notation, and ambiguous name
858.84s - 864.72s |  resolution. Oh, sleepy again. Do you know where else ambiguous
864.72s - 869.88s |  name resolution exists? We don't know Clippy where Microsoft
869.92s - 872.96s |  what is more ambiguous than resolving to rename your
872.96s - 875.52s |  products every six months. Am I right?
877.40s - 880.08s |  I did not know Clippy was allowed to make Microsoft burns.
880.08s - 883.96s |  I don't know if that was cleared. Thanks, Clippy. So one
883.96s - 886.56s |  token down, we've talked about attributes. Next, we're gonna
886.56s - 889.24s |  look at the comparison operator. Most of the time, this is an
889.24s - 892.56s |  equal sign. When it comes to active directories implementation
892.56s - 896.32s |  of LDAP, you also have the approximately equal to because
896.32s - 899.48s |  casing doesn't matter. But it does. It doesn't prevent you
899.48s - 902.32s |  from using the wildcard and hex characters that we'll be talking
902.32s - 904.88s |  a lot more about later. But we're really going to focus on
904.88s - 907.76s |  the range operator. So greater than equal to less than equal
907.76s - 910.48s |  to. So here's an example a lot of red teamers would be familiar
910.48s - 913.32s |  with service principal name equal star means give us the
913.32s - 916.16s |  objects that have an SPN, any value, I don't care, but it must
916.16s - 919.48s |  be defined. Well, technically, we could rewrite this with a
919.48s - 922.84s |  string operator and say, hey, make sure it's present, it has a
922.84s - 924.92s |  value that is greater than or equal to the alphabetical
924.92s - 928.56s |  sorting of a string that begins with equals, or the exclamation
928.56s - 932.36s |  point, or is less than ZZZ. So there are other ways logically
932.36s - 935.36s |  that you can accomplish this equivalence, this presence
935.36s - 939.24s |  filter. One really important note, if you think about the
939.24s - 942.12s |  printable range of ASCII characters, this is the proper
942.12s - 944.92s |  ordering that we all know and love and have agreed upon as a
944.92s - 948.36s |  standard as an industry. We do not know why, but there is an
948.36s - 952.52s |  abnormal range or sorting for strings in Active Directory.
952.52s - 954.76s |  Casing doesn't matter, so we get rid of those, but you have all
954.76s - 956.96s |  of the digits and alpha characters at the end. You have
956.96s - 959.92s |  this very specific grouping of special characters, and then all
959.92s - 962.48s |  the other characters fall right into the middle. This took us
962.48s - 965.28s |  probably five days to find because it only occurred, this
965.28s - 968.64s |  bug only occurred like one out of 1,000 iterations. But this
968.64s - 972.12s |  is, this is the ordering. So our obfuscation framework handles
972.16s - 975.60s |  that, but just know it's kind of weird. Another thing we can do
975.60s - 979.04s |  is use the range filters for precise values. So SAM account
979.04s - 982.32s |  type equals this number ending with 368. This is another
982.32s - 984.88s |  bitwise value, but let's say that detections were looking at
984.88s - 987.36s |  this. Well, you could also, instead of saying ends with
987.36s - 991.96s |  368, say greater than equals to 7, less than equal to 9, and
991.96s - 994.96s |  then specifically exclude the 7 and 9, so logically you're left
994.96s - 998.64s |  with an 8. If you're like me and are a more visual person, I like
998.64s - 1002.00s |  to think of it as a timeline. And so greater than equal to 7,
1002.00s - 1005.44s |  less than equal to 9, and then let's just pop off the 7 and 9,
1005.44s - 1009.32s |  so you're left with the 8. There are a lot of kind of flavors or
1009.32s - 1012.72s |  recipes we built into the obfuscation module, showing a
1012.72s - 1015.28s |  couple of them here. One of my favorites is actually using
1015.28s - 1018.76s |  ranges for exclusions. In this last example where you can say
1018.76s - 1021.92s |  give me the presence filter, but then exclude everything outward
1021.92s - 1025.40s |  and inclusive of the numbers 7 and 9, so you're left with 8. So
1025.40s - 1027.44s |  again, those are all random options in the obfuscation
1027.44s - 1030.88s |  filter, the obfuscation module. This works for numbers. It also
1030.92s - 1033.56s |  works for strings with a caveat that suffixes are a little
1033.56s - 1038.46s |  tricky, but yeah, it is still quite effective for those
1038.46s - 1040.80s |  things. So in review for the second token type of comparison
1040.80s - 1043.96s |  operator, we have approximately equal to, we have the logical
1043.96s - 1046.04s |  equivalence for the presence filter, and then we can use the
1046.04s - 1048.74s |  range operators to do some really fun stuff for precise
1048.74s - 1051.58s |  values, whether they're strings or numbers. And defenders should
1051.58s - 1054.08s |  be pretty familiar with some of these we just looked at, because
1054.08s - 1058.48s |  it's actually part of the sharp hound project. So that same
1058.48s - 1061.38s |  account type, service principal name. So again, these are pretty
1061.38s - 1064.06s |  relevant examples, and you can see that if a detection was
1064.06s - 1066.32s |  looking for this, it would probably get smoked by what we
1066.32s - 1070.26s |  just showed you. So the third token type is the Boolean
1070.26s - 1072.94s |  operator. Mostly we think of ANDs and ORs, but when it comes
1072.94s - 1077.54s |  to LDAP, the NOT is where things get really crazy really fast. So
1077.54s - 1079.54s |  let's take a really practical example. Let's say you're
1079.54s - 1081.80s |  looking for country equals Albania. You want to have all
1081.80s - 1084.34s |  those objects that come out of active directory. One thing you
1084.34s - 1087.12s |  can do is just throw a bunch of Boolean operators inside of it,
1087.12s - 1089.46s |  and logically it doesn't matter if you AND and OR one thing,
1089.46s - 1092.12s |  it's still going to be that same one thing. Additionally, you can
1092.12s - 1095.42s |  also put in double negation. Again, logically this is still
1095.42s - 1098.26s |  going to give you country equals Albania, the same number of
1098.26s - 1103.14s |  objects. Additionally, if you wanted to do a Boolean operator,
1103.14s - 1105.54s |  you can technically slide it right inside of the filter
1105.54s - 1107.74s |  itself. So in this case, if we're looking for location
1107.74s - 1110.84s |  equals KUKES, which is a city inside of Albania, you can see
1110.84s - 1112.88s |  that bottom example, that Boolean is sitting directly
1112.88s - 1116.72s |  inside of the group start, group end filters, or tokens. In our
1117.38s - 1120.22s |  parser that we wrote for this research, we handle this
1120.22s - 1122.42s |  similarly, but do call out the distinction because it is
1122.42s - 1125.52s |  extremely important for certain kinds of detections, as well as
1125.52s - 1128.72s |  obfuscation and deobfuscation scenarios. Most of the time
1128.72s - 1131.12s |  though, you're dealing with a slightly more complex filter
1131.12s - 1134.20s |  like this. So this is saying, I want to know when the country is
1134.20s - 1139.26s |  Albania, and either the location is KUKES or Tirana, two cities.
1139.26s - 1141.74s |  It's important to know that the Boolean operator has kind of a
1141.74s - 1145.00s |  scope of influence. So in this case there are two Booleans, and
1145.02s - 1148.12s |  you can see the boxes around the filters that they affect. If we
1148.12s - 1151.20s |  added in a third set, there are now three groups. And so as
1151.20s - 1153.64s |  we're parsing it, we basically create a stack of Boolean
1153.64s - 1156.76s |  operators to know exactly how many Booleans are affecting the
1156.76s - 1160.64s |  filter that we're looking at. One really, really fun feature
1160.64s - 1163.48s |  is the not Boolean operator. So let's slide that in there. The
1163.48s - 1167.08s |  not only affects the first filter, or the first Boolean
1167.08s - 1170.84s |  operator that it modifies. So we can see location equals KUKES is
1170.84s - 1173.58s |  modified by that not, but the filter just below it is
1173.60s - 1177.64s |  completely, it doesn't modify it at all. So this is another one
1177.64s - 1180.94s |  that we have to track, as well as a lot of crazy things like
1180.94s - 1183.72s |  negation, traversal, because you can have lots of layers in
1183.72s - 1186.38s |  between and you have to track the Booles all the way. Lots of
1186.38s - 1189.82s |  fun, honestly a lot of headaches, but yeah, it's built
1189.82s - 1191.82s |  into the parser so we don't have to think about that anymore, and
1191.82s - 1195.06s |  we'll see that in the demos towards the end. My personal
1195.06s - 1197.86s |  favorite obfuscation technique with Boolean operators is logical
1197.86s - 1200.64s |  inversion. So for any math nerds in the house, this is known as
1200.66s - 1205.20s |  De Morgan's law, but basically not A or B is the same as not A
1205.20s - 1208.20s |  and not B with the inverse sitting below. So what you can
1208.20s - 1211.90s |  do is take any LDAP search filter, choose a spot and negate
1211.90s - 1214.14s |  it. In this case, we're going to choose the whole filter and now
1214.14s - 1216.68s |  everything else kind of to the right of that is going to be in
1216.68s - 1220.58s |  scope for obfuscation. So step number two is identifying within
1220.58s - 1224.22s |  that in scope section, all the ands and ors and inverting them.
1224.22s - 1227.12s |  And then the third step is locating all the filters and
1227.12s - 1229.42s |  inverting them from a negation perspective. So none of these
1229.44s - 1232.08s |  filters are negated, so we're going to add that not and those
1232.08s - 1235.54s |  are now negated. Now, this is logically the same as what we
1235.54s - 1238.22s |  started with. Again, this is a lot of headaches if you're
1238.22s - 1241.56s |  parsing this manually, and so in the parser, we basically have a
1241.56s - 1244.62s |  concept of what's the logical inclusion. Is this included true
1244.62s - 1247.66s |  or false? What's the logical Boolean? Is it and or? And we
1247.66s - 1250.42s |  also maintain a stack of all those Boolean operator tokens
1250.42s - 1253.24s |  for your convenience. So in review for the third token type
1253.24s - 1256.80s |  of Boolean operator, we have the additive nature, double negation
1256.82s - 1261.72s |  and then DeMorgan's laws for the Boolean operator inversion. Oh
1261.72s - 1265.92s |  goodness, okay. What is my least favorite LDAP token type? I'm
1265.96s - 1268.20s |  assuming Boolean operator, but let's see what happens here.
1268.92s - 1271.52s |  Yep, Boolean operator because I'm afraid of getting tied up
1271.52s - 1275.74s |  in knots. Oh, that's cringe, Cliffy. Cliffy's losing steam
1275.74s - 1278.24s |  fast. Yeah, get that out of the way. Okay. All right, the fourth
1278.24s - 1281.28s |  token type, extensible match filter. So Sabi mentioned this
1281.28s - 1284.16s |  before. This is for attributes that have bitwise values. It's
1284.16s - 1288.20s |  an integer, uh, number, but it actually represents a base two
1288.20s - 1291.40s |  add-ins, um, for all the bitwise flags based on which attribute
1291.40s - 1296.58s |  that it is. Uh, so, uh, it is, um, there are four values that
1296.58s - 1299.96s |  are supported by, uh, the, by Active Directory's LDAP
1299.96s - 1302.84s |  implementation. We're going to focus on the first two because
1302.84s - 1304.92s |  they're the most interesting in terms of obfuscation and that's
1304.92s - 1308.12s |  the and and the or. Um, for me, I remember the or because it
1308.12s - 1314.64s |  ends with dot 804. So 804 is or, 803 is not or. All right. So
1314.64s - 1317.00s |  here's an example. User account control, and you can see in the
1317.00s - 1319.40s |  red is the extensible match filter. Um, in this case, it's
1319.40s - 1323.16s |  an 803, so that's an and, and it's the number 515, which is
1323.16s - 1326.92s |  the base two add-ins 1, 2, and 512. So one of the things we
1326.92s - 1329.32s |  can do is what we've called bitwise breakout. So we can
1329.32s - 1333.16s |  break that, uh, 515 out into 1 and 514. Again, as long as we
1333.16s - 1337.00s |  have the proper grouping of add-ins, we can do this. 514 is
1337.00s - 1340.44s |  actually 2 and 512. So we can break that out even further. So
1340.44s - 1343.08s |  from a detection perspective, we can spread our logic across many
1343.08s - 1346.88s |  different filters, which is really, really complicated, but
1346.88s - 1349.92s |  it's also fun. Uh, if you started with an or, the same
1349.92s - 1351.96s |  trick applies. Just make sure that the Boolean operator you
1351.96s - 1354.36s |  add is an or instead of an and and that it matches the
1354.36s - 1358.68s |  extensible match filter. Um, this is a pretty trivial example,
1358.68s - 1361.48s |  but a lot of real world examples can get pretty crazy. Like this
1361.48s - 1364.68s |  is a git domain user from PowerView. Massive number. You
1364.68s - 1367.24s |  can imagine all of the random groupings and regroupings of,
1367.24s - 1370.44s |  uh, base two add-ins to produce the same value in your overall
1370.44s - 1375.08s |  search filter. Um, so another thing we can do is if you have a
1375.08s - 1378.60s |  filter that is a precise value. So this is looking for the exact
1378.60s - 1383.16s |  ones and zero set to equal this number. Um, what you can do is,
1383.16s - 1385.76s |  uh, use this little formula. You can and, you can add the
1385.76s - 1388.56s |  extensible match filter of and for all the one bits. You can
1388.56s - 1391.40s |  add the or extensible match filter for all the zero bits and
1391.40s - 1395.24s |  negate it and then and both of those filters together. What's
1395.24s - 1398.28s |  really cool about this is now we have extensible match filters
1398.28s - 1401.00s |  and we can use the first breakout type to break those
1401.00s - 1404.20s |  into smaller and smaller random groupings of those base to add
1404.20s - 1406.52s |  in. So we're not going to take this further, but this could
1406.52s - 1409.80s |  explode into 10, 15, 20 different filters all slammed
1409.80s - 1413.48s |  together. So interview for the fourth token type of extensible
1413.48s - 1415.56s |  match filter. We have the bitwise breakout with the and
1415.56s - 1418.20s |  and or, and then also the precise breakout, uh, which kind
1418.20s - 1424.32s |  of combines the second one, uh, with the first one. Thanks
1424.32s - 1428.88s |  Debo. Let's look at what we can do to obfuscate a little, the
1428.88s - 1433.68s |  value. We are still in the filter section. So excluding a
1433.68s - 1437.44s |  couple of attribute types, just like seeing here, it is still
1437.44s - 1442.64s |  casing doesn't matter. So it's cases sensitive and we can also
1442.64s - 1446.56s |  do prepended zeros to anything that are bitwise digits or
1446.64s - 1451.44s |  numbers. And we got some undocumented feature regarding
1451.44s - 1456.32s |  timestamps is that we originally noticed that sometimes
1456.32s - 1460.24s |  milliseconds were present, but it didn't actually seem to
1460.24s - 1464.00s |  matter. If you change the millisecond seconds values or
1464.00s - 1468.32s |  remove them, it turns out you can actually add literally
1468.32s - 1474.80s |  anything as long as you have a capital Z in it. So, and
1474.80s - 1478.16s |  technically it is going to be treated still as a correct
1478.16s - 1482.08s |  timestamp in the results. And it doesn't need to be only
1482.08s - 1486.08s |  capital Z. It can also be it's hex encoding representation,
1486.72s - 1491.84s |  which leads us to the next point, which is hex encoding
1491.84s - 1495.92s |  for value obfuscation. And it's our favorite thing to do, to be
1495.92s - 1501.60s |  honest, the hex encoding itself, it exists to be able to, to
1501.68s - 1505.20s |  escape certain special characters, which Microsoft has
1505.20s - 1509.20s |  detailed here very well, but you can also escape any printable
1509.20s - 1514.88s |  characters that you want to as well. So you can swap these with
1514.88s - 1518.08s |  the hex representations, and it's still going to be to give
1518.08s - 1521.44s |  you the same results. And is going to show just like this on
1521.44s - 1526.80s |  the client side logs. Again, our parser, our parser parses
1526.80s - 1530.88s |  codes, decodes all the values. So it's all being handled.
1532.08s - 1536.32s |  One undocumented thing is that Microsoft says that the hex
1536.32s - 1539.04s |  representation should be followed by two characters,
1540.08s - 1544.64s |  representative SK hex character. But that's actually not true for
1544.64s - 1548.96s |  the first 16 characters, you can drop the leading zero, and it's
1548.96s - 1554.08s |  still going to work. Wildcards, we mentioned a little bit, even
1554.08s - 1558.08s |  the wildcards. So for example, instead of looking for the
1558.16s - 1562.48s |  wildcard TGT, you can also just look for RBG and see what you
1562.48s - 1568.24s |  get. These, actually, for wildcards, we are not the only
1568.24s - 1572.40s |  ones who have been looking for evasion purposes. So even the
1572.40s - 1577.44s |  researcher Hope Walker, these are two very well great posts,
1577.44s - 1581.20s |  blog posts recent, it's a researcher at SpectreOps. And
1581.20s - 1587.52s |  she outlines using wildcards for evasion purposes. As a recap,
1587.52s - 1591.20s |  for value, we can do casing, we can do prepended zeros, time
1591.20s - 1596.40s |  steps, hex encoding, and wildcards. The good news is,
1596.40s - 1600.16s |  that's all you can do with obfuscation. Nah, I'm lying,
1600.16s - 1604.32s |  you guys, we got much more. So until now, we actually were
1604.32s - 1608.00s |  looking for top and obfuscation. Let's see outside of it a
1608.00s - 1612.88s |  little. And for example, for filter wide obfuscation, you can
1613.52s - 1617.68s |  actually add group start and group end as long as as much as
1617.68s - 1622.40s |  you want, as long as you stay until the depth of 99. You can
1622.40s - 1627.52s |  also add white space all over, and it is significant. And it
1627.52s - 1634.16s |  can be new line tab, etc. Garbage filters, again, need
1634.16s - 1637.84s |  here, actually, you need to be careful if you're looking for if
1637.84s - 1641.76s |  you're actually using logical or or logical end, because in
1641.84s - 1645.84s |  case you're looking for logical end, you need to make sure the
1645.84s - 1651.68s |  properties exist. But you can go crazy with ours. And lastly,
1651.68s - 1657.84s |  is filter filter reordering. So until now, we only handled the
1657.84s - 1662.88s |  filter. Let's see what we can do with base object. As a
1662.88s - 1666.80s |  reminder, the base object is where in the active directory
1666.80s - 1670.16s |  structure, we want to see we want to start the search, there
1670.16s - 1672.96s |  are some good detection opportunities that we feel
1672.96s - 1677.44s |  aren't discussed as much. And for example, like some offensive
1677.44s - 1681.52s |  tools, just like certify, they have a very benign common and
1681.52s - 1685.60s |  super search, super common search filter. So in this case
1685.60s - 1688.88s |  is the base object, and it's looking for public key services,
1689.68s - 1695.44s |  we are going to focus from a syntax perspective on a simple,
1695.44s - 1699.76s |  really simple object like this. All the tricks we've seen until
1699.76s - 1703.04s |  now, okay, for example, they still work, which is the casing
1703.04s - 1707.44s |  we can play, you can do also the hex encoding for the value
1707.44s - 1713.20s |  portion, you can use the ID notation of the attributes, and
1713.20s - 1719.44s |  also supports the ID prefix as well as the or prefix. And
1719.44s - 1723.84s |  whitespace, it actually can be added at the end, as well as
1723.84s - 1729.20s |  between the slashes of the LDAP prefix. Something interesting
1729.28s - 1733.36s |  is that it's true for the base object, but not for the value in
1733.36s - 1737.60s |  the filter is that as long as hex is not present, you can
1737.60s - 1740.80s |  actually encapsulate it with double quotes. And it will show
1740.80s - 1745.28s |  up this way in client log side logs, but it's not going to look
1745.28s - 1751.12s |  like this on server side logs. Lastly, is the attribute
1751.12s - 1754.64s |  selection basically is which attributes properties do you
1754.64s - 1759.36s |  want to be returned in the results. And here also case in
1759.36s - 1763.68s |  doesn't matter, you can substitute just like previously,
1763.68s - 1767.52s |  you can also use object identifier notation also
1767.52s - 1773.20s |  supports adding ID prefix and prepended zeros, add whitespace
1773.20s - 1778.08s |  only after the attributes that are on the ID syntax. Not sure
1778.08s - 1782.00s |  why but yeah, a lot of trial and error to be honest. We have
1782.08s - 1787.04s |  the option also to add duplicate attributes and garbage
1787.04s - 1791.92s |  attributes, literally anything you want. And the person who's
1791.92s - 1797.60s |  going to to answer about this is no one else than Clippy. Hey,
1797.60s - 1801.68s |  Daniel, what do you call this character? Asterix, wildcard or
1801.68s - 1802.16s |  splat?
1804.08s - 1807.52s |  I think this is an ages question. But all three are
1807.52s - 1809.84s |  true. But there's a lot of there's a lot of space down
1809.84s - 1813.60s |  there. So let's see what Clippy has to say. F all the above. So
1813.60s - 1816.00s |  two more important things here is from an input perspective and
1816.00s - 1819.04s |  the attribute selection. If the only value defined is a wild
1819.04s - 1822.88s |  card, it will return all the properties, even just the same
1822.88s - 1825.28s |  as if you don't define any attribute selection. What's
1825.28s - 1828.32s |  fascinating is that in the server side logs, that wild card
1828.32s - 1831.12s |  is going to literally be printed as the string square brackets,
1831.12s - 1835.76s |  all all all lowercase. Now, if you'll notice, he is that if you
1835.76s - 1838.96s |  have a list of attributes, and any one of those is a wild card,
1838.96s - 1842.32s |  then it will, the server side logs will translate that wild
1842.32s - 1846.00s |  card into this other string all with list. If you are and you
1846.00s - 1848.40s |  should be if you are parsing these attribute selection
1848.40s - 1852.40s |  values, you need to know that this weird string is prepended
1852.40s - 1854.64s |  to the first attribute. So you have to do a really specific
1854.64s - 1858.00s |  split and translation that we that we do in the logging
1858.00s - 1860.00s |  module. But just know there's some weirdness that goes on
1860.00s - 1864.40s |  there. Thanks, Clippy. All right, now that is actually the
1864.40s - 1867.20s |  end of the obfuscation portion. So we've talked about the search
1867.20s - 1869.20s |  filter, we've talked about the base object, the attribute
1869.20s - 1872.80s |  selection. So for all the defenders in the room, what now?
1872.80s - 1876.08s |  So from a solution perspective, we're going to focus on three
1876.08s - 1879.76s |  steps. One is parsing, two is enriching, and then three is the
1879.76s - 1882.88s |  actual detection itself. So from a parsing perspective, when we
1882.88s - 1885.84s |  started this research, there was no parser for LDAP search
1885.84s - 1889.36s |  filters. And so we naively said, let's just build a parser. How
1889.36s - 1891.84s |  hard could it be? To be honest, that was over half of the
1891.84s - 1894.64s |  research, but it was one of the most interesting and
1894.64s - 1897.68s |  fulfilling parts of this. And so we wrote a C sharp state
1897.68s - 1901.04s |  machine parser to firstly do tokenization. So that means when
1901.04s - 1903.36s |  you have a string come in, that's the entire search filter,
1903.36s - 1905.68s |  let's break it into tokens. So we know which ones are
1905.68s - 1908.96s |  attributes, values, comparison operator, etc. Next, you want to
1908.96s - 1911.76s |  organize those tokens into a representation that allows you
1911.76s - 1915.28s |  to understand the structure of nested Boolean operators and
1915.28s - 1917.68s |  filters and filter lists and all those sorts of things. And
1917.68s - 1920.16s |  then you can move on to actual enrichment, which is step
1920.16s - 1923.12s |  number two. So here's an example of using all the conversion
1923.20s - 1926.64s |  modules within Mount Adaptive to start with a string, break it
1926.64s - 1929.68s |  into tokens, and then every step of the way, we try to decode
1929.68s - 1932.48s |  and enrich however much we can. So as Sabi mentioned, when
1932.48s - 1934.88s |  there are hex values, we'll automatically decode them for
1934.88s - 1939.04s |  you. But we leave the original syntax as well. One distinction
1939.04s - 1942.96s |  between, so in our parsing, we do tokenization, and then we
1942.96s - 1946.48s |  basically create a parse tree or syntax tree, which is almost
1946.48s - 1949.44s |  an abstract syntax tree, but we drop the abstract part because
1949.44s - 1952.00s |  abstract says, let's drop things that don't need to be there,
1952.00s - 1954.64s |  like insignificant white space. Well, by definition,
1954.64s - 1956.88s |  obfuscation doesn't need to be there. So we actually want to
1956.88s - 1960.00s |  keep all those insignificant things so we can recreate the
1960.00s - 1963.52s |  input from that parse tree. And then after we break this into
1963.52s - 1965.68s |  tokens and do those enrichments, we'll then group them into
1965.68s - 1968.80s |  filters and branches and a tree structure to do certain kinds of
1968.80s - 1971.28s |  obfuscation and detections that require that kind of tree
1972.00s - 1975.52s |  grouping functionality as we go through and parse it. And then
1975.52s - 1979.12s |  the final step is actually detect. So we try to make it as
1979.12s - 1981.52s |  simple as possible. We wrapped all this inside of a single
1981.52s - 1984.48s |  function called find evil. So you can pipe any number of
1984.48s - 1986.80s |  search filters you want into find evil. And for each of those
1986.80s - 1989.36s |  filters, it will parse it, do all the enrichment we just
1989.36s - 1991.60s |  talked about. It will run it through all our complete
1991.60s - 1994.24s |  detection rule set, which we are releasing with maladaptive. So
1994.24s - 1997.36s |  65 rules and counting. And then for each of those detections,
1997.36s - 2000.32s |  the rule carries with it a dynamic score or weight, if you
2000.32s - 2002.88s |  will, as well as an explanation. So it'll give you an example of
2002.88s - 2005.12s |  what kind of thing it's looking for. And then it will actually
2005.12s - 2008.32s |  show you the specific part of your search filter that flagged
2008.32s - 2011.84s |  on that rule, as well as in the name, you can see. It'll
2011.84s - 2014.48s |  actually pull out specific values. So it should be really
2014.48s - 2017.36s |  colorfully obvious, as you'll see in the demo, of exactly why
2017.36s - 2019.92s |  this thing was flagged for this rule. And if you look at the
2019.92s - 2023.04s |  bottom, as I said, we spent over half the time just building
2023.04s - 2026.24s |  this parser. We wrote and rewrote every piece of this
2026.24s - 2029.04s |  parser two to three times to make it as fast as we possibly
2029.04s - 2032.24s |  could. And in this example, we're parsing this search filter
2032.24s - 2036.56s |  100,000 times, doing full parsing, full detections, and
2036.64s - 2040.16s |  it's clocking in at just under 4.4 seconds. And that's on a
2040.16s - 2043.28s |  moderately spec laptop, because we know that the number the
2043.28s - 2045.44s |  volume of search filters in production environments is
2045.44s - 2048.24s |  massive. And so we wanted this to be really usable right out of
2048.24s - 2052.88s |  the box. Oh, and shout out to Olaf Hartung at Falcon Force.
2052.88s - 2055.12s |  He was really instrumental in taking all these rules for us
2055.12s - 2057.84s |  and running them multiple times across his entire client data
2057.84s - 2060.64s |  set, since we don't have that data set, and then giving us
2060.64s - 2062.96s |  feedback and stats on hey, which rules need to be tuned a little
2062.96s - 2065.28s |  bit. So, Olaf, if you're watching, thanks so much, buddy,
2065.28s - 2068.48s |  we really appreciate it. So, instead of talking more about
2068.48s - 2070.88s |  the solution, let's go into the last section and actually just
2070.88s - 2073.76s |  show a demo. If you haven't picked up on it by now, we
2073.76s - 2076.48s |  really like to have fun. When you spend 2,000 hours on
2076.48s - 2078.88s |  something, you have to trick yourself into being motivated,
2078.88s - 2082.48s |  so we added colors however we can. This is our ASCII art, and
2082.48s - 2084.96s |  it's actually a fully functioning LDAP query that
2084.96s - 2088.88s |  will return any object that has a name property. Clippy seems
2088.88s - 2090.64s |  to like it as well. I can't tell if he's hanging out or
2090.64s - 2094.00s |  trying to eat the terminal or what's going on. So, in the
2094.00s - 2097.60s |  first example, this is that Albania, Kukiz, Tirana filter
2097.60s - 2100.40s |  example with a little bit of obfuscation. So, if we tokenize
2100.40s - 2103.44s |  it, we can see it breaks out which things are attributes,
2103.44s - 2106.56s |  values, et cetera. If we do the enriched tokens, we can now see
2106.56s - 2109.12s |  it says hey, this is a defined attribute, and it translates to
2109.12s - 2112.32s |  the letter L, and we have these other context objects as well.
2112.32s - 2114.64s |  So, if we look at the context object, remember this is things
2114.64s - 2117.28s |  like the Boolean operator. We group all these things into
2117.28s - 2120.32s |  filters so that we can write detection logic against the
2120.32s - 2122.88s |  entire filter. So, we can easily access the string values, but
2122.96s - 2125.36s |  then we have a dictionary and list of the full token objects.
2125.36s - 2128.00s |  So, all the metadata nested from tokenization we can find in
2128.00s - 2130.56s |  the filter, and then if we look at the context object for the
2130.56s - 2133.84s |  Boolean operator, we'll see this is a logically inclusive filter.
2133.84s - 2136.16s |  This is tracking that full stack of Boolean operators that
2136.16s - 2139.12s |  you still have direct access to, and then every single value
2139.12s - 2142.08s |  goes through the full value parsing. So, any hex characters
2142.08s - 2144.72s |  are parsed. At any time, you can look for the raw content or
2144.72s - 2147.44s |  the decoded content. Pipe that into Find Evil, and we can see
2147.44s - 2150.08s |  these are the individual rules that matched for this
2150.08s - 2152.56s |  particular search filter. This is just showing a couple
2152.56s - 2155.12s |  properties. In the next demos, you'll see a little better view
2155.12s - 2158.80s |  of the entirety of the rules. Let's do another parsing
2158.80s - 2160.96s |  example, this time using the bitwise value. So, remember all
2160.96s - 2164.88s |  the bitwise breakout were like 515 can be 1, 2, 5, 12. Well,
2164.88s - 2167.28s |  here's a rule that flag and says, hey, if user account
2167.28s - 2171.12s |  control attribute has the flag 128 set to true, then flag this
2171.12s - 2173.04s |  alert. I won't go into the details of why that's an
2173.04s - 2176.24s |  interesting detection, but what we want to show you is when we
2176.24s - 2178.16s |  parse this value, we automatically know this is a
2178.16s - 2181.28s |  bitwise attribute, and we parse the value to get those base two
2181.28s - 2184.88s |  add-ins, either in a dictionary format or a list format. So,
2184.88s - 2187.68s |  you can immediately write detections for combinations of
2187.68s - 2190.64s |  true and false. Now, keep in mind this is per filter, so that
2190.64s - 2192.96s |  breakout stuff does complicate it a bit, but you can at least
2192.96s - 2197.04s |  extract the flags and aggregate it back together for your final
2197.04s - 2200.88s |  detections across the entirety of the search filter. The last
2200.88s - 2204.96s |  parsing example is looking for some actually kind of crazy
2204.96s - 2207.28s |  stuff. So, decoding hex characters in this first
2207.28s - 2210.16s |  example, that's easy sauce. So, this is trusted domain, easy
2210.16s - 2213.36s |  detection, but when it's things like wildcards, they're actually
2213.36s - 2216.24s |  missing characters. So, we can't precisely say what the person
2216.24s - 2219.60s |  was looking for, but in our detection module, you have the
2219.60s - 2222.72s |  ability to define strings of interest, like curb TGT, domain
2222.72s - 2225.36s |  admins, domain controllers, and the parser and the detection
2225.36s - 2227.76s |  rules will go through and actually expand the wildcards
2227.76s - 2230.48s |  and say, hey, does this wildcarded string match any of
2230.48s - 2233.44s |  your sensitive terms? And that also handles the two ANR
2233.44s - 2235.60s |  scenarios that Sabi mentioned earlier, with the implicit
2235.60s - 2239.28s |  wildcard or the explicit wildcard. So, yeah, those are
2239.28s - 2241.20s |  some really fun detections that go beyond just pure
2241.20s - 2244.08s |  deobfuscation, but really kind of logically looking at some
2244.08s - 2245.84s |  suspicious strings of interest.
2247.76s - 2252.40s |  And finally, we've put all this together into a colorful
2252.40s - 2256.48s |  interactive menu to make it fun to explore. We can test our
2256.48s - 2261.28s |  input, the LDAP search filter, and we can explore the
2261.28s - 2265.20s |  obfuscation menus for all the techniques we covered in this
2265.20s - 2272.08s |  presentation. Wildcards are also supported. We can add
2272.08s - 2276.40s |  obfuscation layer by layer, and we can also remove it. And if
2276.40s - 2280.32s |  you're lazy, you can use all wildcards to randomly apply all
2280.32s - 2280.88s |  the options.
2282.88s - 2288.56s |  Let's test again. The search filter still works. Detection
2288.56s - 2293.12s |  module is built in, and find evils shows a full summary of
2293.12s - 2297.76s |  detections, scores, explanations, and more colors.
2299.52s - 2302.88s |  Lastly, if you don't like interactive menus, we have full
2302.88s - 2308.32s |  CLI support. So the interactive menu lets you randomly choose
2308.32s - 2313.28s |  ingredients, and you can copy out the receipt for non-interactive
2313.28s - 2317.36s |  user. All the functions for pretty printing and detection
2317.36s - 2320.40s |  summaries are also available via CLI.
2330.00s - 2332.88s |  Thank you. It's always awkward in Blue Teamer talks, and they're
2332.88s - 2336.08s |  like, was that a shell? Like, do we clap or not? And so, yeah,
2336.08s - 2338.72s |  our apologies for not including a dramatic pause. But yeah,
2338.72s - 2342.08s |  hopefully that was really fun for everyone. So we're almost
2342.08s - 2344.32s |  done here, but we just want to reiterate that Sabi and I are
2344.32s - 2346.56s |  both defenders, and from the very beginning of this research,
2346.56s - 2349.92s |  we knew that we had not seen people talking about this, and
2349.92s - 2352.48s |  to be honest, attackers didn't really need this help. So why
2352.48s - 2355.44s |  hand them a fully loaded machine gun when defenders still often
2355.44s - 2357.52s |  don't even have the telemetry in the first place? So from the
2357.52s - 2359.60s |  very beginning, we weren't strong-armed. We decided that
2359.60s - 2362.56s |  we wanted to release this in a unique kind of two-stage
2362.56s - 2365.20s |  approach. So today what we've released is everything we've
2365.20s - 2368.40s |  talked about, minus the obfuscation module. We're
2368.40s - 2372.64s |  releasing a corpus of 1,337 benign obfuscated examples, so
2372.64s - 2374.96s |  you don't even have to run our code to look at examples of
2374.96s - 2378.56s |  obfuscated search filters. For anyone who's really ambitious,
2378.56s - 2381.60s |  you have the full parser, and the deobfuscation modules look
2381.60s - 2384.08s |  suspiciously like the obfuscation ones. So if you want
2384.08s - 2386.64s |  to do a little bit, go for it. But just keep in mind, we spent
2386.72s - 2389.12s |  over 1,000 hours on the obfuscation module, so there is
2389.12s - 2392.24s |  a heck of a lot of craziness that we put in there. Our goal,
2392.88s - 2395.76s |  pending a CFP response, is hopefully by the end of this
2395.76s - 2399.12s |  year to do a part two of this presentation to focus really
2399.12s - 2402.88s |  deeply on all the differences in client and server-side logging,
2402.88s - 2405.44s |  a lot of the weird scenarios we had to build into the parser to
2405.44s - 2408.48s |  support all of this, and then at that point, releasing the
2408.48s - 2412.24s |  obfuscation module. So yeah, just want to make that really
2412.24s - 2414.08s |  clear. That's clear on the GitHub, which will be on the
2414.08s - 2416.96s |  last slide as well. But again, as defenders, we wanted to try
2416.96s - 2419.76s |  to be as creative as possible and help defenders not be
2419.76s - 2423.12s |  completely throwing tomatoes at us up on the stage. And we made
2423.12s - 2425.84s |  this very clear in the CFP process. Big red text, no
2425.84s - 2429.12s |  surprises. So we're really happy that there was support in us
2429.12s - 2432.96s |  doing that kind of a release. So the final takeaways. LDAP is
2432.96s - 2436.80s |  still widely used by attackers. It's very valuable. And in our
2436.80s - 2439.76s |  opinion, defensively, it's still kind of immature in terms of
2440.56s - 2443.04s |  detection. It seems to be a lot of kind of string-based
2443.04s - 2445.68s |  detections. And even looking at blog posts of people doing LDAP
2445.68s - 2448.32s |  hunting, there just aren't as many of them as I would like to
2448.32s - 2452.24s |  see, that we would like to see. And then lastly, we released
2452.24s - 2455.68s |  Maldaptive to help try to bring awareness to what can happen to
2455.68s - 2458.08s |  show that we shouldn't just be doing string-based detections,
2458.08s - 2460.88s |  and we're providing the parser in all of our detection modules
2460.88s - 2463.36s |  so that hopefully you can right out of the gate start using it
2463.36s - 2465.52s |  in your environment if you already have a mechanism to get
2465.52s - 2470.00s |  all of those search filters. Our unofficial takeaway is we
2470.00s - 2471.60s |  wanted to leave you with something a little different.
2472.40s - 2476.32s |  And so we wanted to leave you with each of our favorite
2476.32s - 2479.04s |  Albanian proverb. So I'm going to go first. I'm not a native
2479.04s - 2482.72s |  speaker, so forgive my pronunciation. But mine is
2482.72s - 2486.72s |  rošsa malet, which literally means live long like a mountain.
2486.72s - 2489.76s |  It's kind of a blessing of well-being. I like to think of
2489.76s - 2492.00s |  it in this scenario as we just climbed a crazy mountain
2492.00s - 2495.44s |  together. I'm a little out of breath personally. But in this
2495.44s - 2498.24s |  industry, we have to help each other out. We have to recognize
2498.24s - 2501.36s |  the shoulders that we stand on. And so when you see someone else
2501.36s - 2503.20s |  struggling up the mountain trying to understand what
2503.20s - 2506.16s |  you're learning, help them up. Get them to the top, and then
2506.16s - 2508.00s |  they'll be able to see the next mountain they're going to climb
2508.00s - 2509.52s |  and the person they're going to bring along with them.
2511.93s - 2516.57s |  And my favorite expression, and I think the audience would
2516.57s - 2521.05s |  agree with me here, Diba, is to ljutem jo mokap se letraš,
2521.05s - 2524.49s |  which it means please no more paperclips.
2528.09s - 2531.69s |  It was fun while it lasted. All right. And with that, we just
2531.69s - 2534.41s |  want to say thank you so much for your time. Thank you DefCon
2534.41s - 2537.53s |  and to all the organizers. We had such a great time putting
2537.53s - 2540.17s |  this research together, and we're really happy to be here.
2540.17s - 2542.97s |  Here's all of our contact information. Here's the link to
2542.97s - 2545.21s |  Maldaptive. Please reach out, and we'll be up here for
2545.21s - 2558.17s |  questions. But thank you again for your time. Any brave souls
2558.17s - 2563.23s |  for questions? Questions or criticisms, everything is
2563.23s - 2575.77s |  welcome. One right here, yeah. So the question is what was our
2575.77s - 2579.93s |  process for finding all the undocumented stuff? Well,
2579.93s - 2584.25s |  sometimes luck, sometimes I think the best answer that we
2584.25s - 2587.13s |  can give is people ask us why do you make obfuscation
2587.13s - 2590.57s |  frameworks? It's kind of a little twisted, but it's really
2590.57s - 2593.77s |  a way of kind of working backwards and defining a
2593.77s - 2596.41s |  grammar, because it's all a language, right? What's
2596.41s - 2599.29s |  linguistically, syntactically allowed in a language, whether
2599.29s - 2602.33s |  that's PowerShell or LDAP or anything else? So our
2602.33s - 2606.57s |  understanding is, let's say, actually when Sabi wrote the
2606.57s - 2609.29s |  hex encoding function to take values and do hex encoding,
2609.93s - 2612.01s |  we wrote that function, we plugged it into our test
2612.01s - 2614.89s |  harness, and one out of every 500 examples would fail. It
2614.89s - 2617.05s |  wouldn't return the same results we expected. And we
2617.05s - 2619.77s |  eventually realized that's because hex values or hex
2619.77s - 2623.21s |  characters in the value is not allowed when the extensible
2623.21s - 2625.45s |  match filter is defined, right? So that is now an
2625.45s - 2628.57s |  incompatibility that no one said anywhere, but our tool
2628.57s - 2630.97s |  helped us find because it found an example that broke what we'd
2630.97s - 2633.53s |  expected to see. So that's how we found a lot of these
2633.53s - 2635.53s |  examples. And then just some tricks you kind of learn along
2635.53s - 2637.77s |  the way, like, hey, pre-pinning zeros, that seems like
2637.77s - 2639.77s |  something that someone might have thought to ignore because
2639.77s - 2642.17s |  it's insignificant, but it still shows up in logs,
2642.17s - 2644.57s |  therefore it's meaningful to us. And so some of those tricks
2644.57s - 2646.25s |  you just kind of pick up along the way and keep carrying
2646.25s - 2660.81s |  forward. But yeah, great question. Thank you. Yeah. Yeah,
2660.81s - 2663.77s |  good question. So the question was in our research against the
2663.77s - 2667.13s |  obfuscation techniques we found, how effective was Windows
2667.13s - 2669.77s |  Defender or other tools like that? We don't have access to
2669.77s - 2675.05s |  those tools, so I actually don't know. In general, I'd say I've
2675.05s - 2677.77s |  spent the last decade doing real-time detections, actually
2677.77s - 2680.33s |  spending some time at Microsoft in Defender telemetry looking
2680.33s - 2683.61s |  at how we detect processes and stuff like that on the
2683.61s - 2686.41s |  endpoint. So what I would say that a lot of red teamers
2686.41s - 2688.89s |  criticize blue teamers for is why do you make static kind of
2688.89s - 2692.41s |  rigid detections? Sometimes it's out of ignorance. Sometimes
2692.41s - 2694.97s |  more likely it's out of performance. So I mean, there
2694.97s - 2697.05s |  are millions and millions and millions of search filters
2697.05s - 2701.29s |  flying around doing crazy regexes to try to find these
2701.29s - 2703.85s |  bizarre scenarios probably is going to bring down performance
2703.85s - 2706.33s |  overall. So from a product's perspective, that's, I think,
2706.41s - 2708.49s |  why a lot of decisions are made, but we don't have any direct
2708.49s - 2711.85s |  insight into Defender or anyone else on how they're stacking up
2711.85s - 2716.01s |  against this. If anyone from Microsoft or anyone else wants
2716.01s - 2717.77s |  to reach out, we'd be more than happy to share more of the
2717.77s - 2720.49s |  research in detail and help if there's anything that we can do
2720.49s - 2723.85s |  to protect the community in that regard. Great question. Thank
2723.85s - 2735.47s |  you. Any last questions? Yes. The question was did we have
2735.47s - 2739.95s |  trouble with all the colors for formatting? Trouble to who? The
2739.95s - 2756.97s |  answer is yes. So we actually did, we split our programming
2756.97s - 2759.29s |  actually partially. We use PowerShell core. So we did a lot
2759.29s - 2761.45s |  of it in Windows, a lot of it on Mac, a little bit in Linux,
2761.45s - 2763.77s |  just to test compatibility. But yeah, in terms of color
2763.77s - 2765.85s |  differences, we actually stuck with the original colors, the
2765.85s - 2769.37s |  original 16. We experimented with the dark colors for things
2769.37s - 2774.25s |  like distinguished name values. Those are the darkened version
2774.25s - 2778.33s |  of all the RDNs to represent the overall tokens. But that
2778.33s - 2781.29s |  darkness shows up better on Windows. On Mac, it actually
2781.29s - 2784.81s |  doesn't quite show up as much. But yeah, so that was a factor
2784.81s - 2788.65s |  we had to kind of play around with. But yeah, I like the color
2788.65s - 2793.34s |  question. I've never gotten that before. So thank you. All
2793.34s - 2795.02s |  right. I think with this, we're out of time. We'll be around
2795.02s - 2796.86s |  front if anyone else wants to talk or ask questions. But
2796.86s - 2798.70s |  again, thank you everyone for coming to the talk. Have a good
2798.70s - 2799.50s |  one.


url: https://www.youtube.com/watch?v=GPODCSvZMyM
type: video
author: DEFCONConference
ingestion_date: 2024-11-09
transcription_model: large-v2
chunking_status: completed
title:
DEF CON 32 - Open Sesame: how vulnerable is your stuff in electronic lockers -Dennis Giese, braelynn

content:
{
  "webpage_url": "https://www.youtube.com/watch?v=GPODCSvZMyM",
  "title": "DEF CON 32 - Open Sesame: how vulnerable is your stuff in electronic lockers -Dennis Giese, braelynn",
  "description": "Physical security is often overlooked in many organizational threat models. An increasing amount of physical security devices with smart components are being introduced to the market with widespread adoption. This creates an enticing attack surface for physical red teams.\n\nLockers and cabinets equipped with electronic smart locks can be found in many places such as offices, factories, hospitals, labs, and gyms. With remote and hybrid work increasing in popularity, shared use office setups becoming the default. Co-working spaces in offices are now commonplace with lockers being installed for employee device storage. People generally trust that their belongings will be secure in these lockers and entrust the locks with sensitive information, like their personal PIN.\n\nIs there a more stealthy way to get into lockers that don't involve using a crowbar?\n\nIn this talk we will analyze the vulnerabilities affecting locks manufactured by the \"global leader in keyless lock solutions,\" Digilock and Schulte-Schlagbaum AG (SAG). Both companies have been in the physical security industry for many decades. What went wrong in the development of these devices and how can these vulnerabilities be fixed? We will also discuss several other vendors operating in this space and compare findings.\n\nWe will demonstrate practical physical and side-channel attacks targeting locks that accept a standard PIN and RFID. Learn why it is poor practice to reuse the same secret PIN for lockers and safes and devices such as mobile phones and laptops (especially if they are stored inside the lockers).",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2408,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

2.22s - 7.54s | This text was transcribed using whisper model: large-v2

 Hello DEF CON! Thank you for being here on a Saturday morning. I know everyone was
7.54s - 13.14s |  partying yesterday until 5 a.m. probably, so I'm glad that you're here. So yeah, now
13.14s - 18.10s |  we're talking about our talk, Open CSAM or how secure is your stuff in your
18.10s - 21.14s |  lockers? And this is the main question, basically, which we will talk through the
21.14s - 26.10s |  talk. As you might have heard, there have been some issues with the talk in the
26.10s - 32.06s |  past, so I will address it later. So before we start with the topic, let me
32.06s - 36.70s |  introduce myself real quick. So I'm Dennis, I'm a security researcher or also
36.70s - 41.34s |  a hardware hacker, and I basically am interested in wireless and embedded
41.34s - 44.58s |  security and privacy. So I take a look at all kind of interesting devices which
44.58s - 50.18s |  are around me. Primarily this is vacuum robots, but I generally like look at all
50.18s - 54.98s |  kind of things. That's why I call myself also a vacuum robot and IoT collector, so
54.98s - 60.14s |  I have probably way over 600-700 devices and, you know, 60 or 70 vacuum robots by
60.14s - 65.66s |  now. So my main goal typically is to root vacuum robots, but, you know, again I
65.66s - 68.46s |  look at all the other things. And if you're interested in vacuum robots, by the
68.46s - 72.50s |  way, I have a website which documents all the, you know, hardware and
72.50s - 80.78s |  everything. Yeah, one thing which is kind of new in the slides, so I have been a
80.78s - 84.78s |  target of a seasoned assistant at DEF CON, so I think this is like a, you know,
84.78s - 89.14s |  interesting thing. Which, by the way, was withdrawn as today in the morning or at
89.14s - 98.21s |  night, so yeah. And now we would like to introduce Braylyn. Cool. Hi, I am Braylyn.
98.21s - 102.41s |  I hack things for the Leviathan Security Group during the day, but I'm here
102.41s - 105.73s |  representing myself as an independent security researcher, and this talk does
105.73s - 110.93s |  not reflect their views. My general focus has been application security and APIs,
110.93s - 116.93s |  but I've started hardware hacking for fun, looking at things like robots,
117.05s - 122.85s |  cameras, and smart locks. And this is my first DEF CON talk, and I was also named
122.85s - 134.41s |  in the C synthesis, so that's pretty fun. All right, so let's talk about some
134.41s - 137.65s |  previous work. So this is not necessarily the first lock which we took a look at.
137.65s - 142.05s |  Like exactly 10 years ago, well a little bit more than 10 years ago, I was working
142.05s - 145.73s |  on a group which looked at Siemens and Foss door locks, and we published a paper
145.73s - 150.93s |  about that. Also some while ago I was taking a look at Schlage electronic
150.93s - 154.01s |  locks, which you find especially in America, like, you know, in government
154.01s - 160.77s |  buildings, universities. So what are the goals of this talk? Well, first we want
160.77s - 164.41s |  to give you some overview of the reverse engineering of digilock and SAG locks.
164.41s - 169.65s |  We want to tell you something about vulnerabilities, and we want to show you
169.65s - 173.13s |  some ideas and methods how you can extract typically firmware and
173.13s - 177.77s |  configurations from that kind of devices. One thing which is the most important
177.77s - 182.25s |  part of this talk is basically we want to raise awareness about pin numbers. As
182.25s - 186.37s |  a general side note, we use digilock and SAG as an example, and we are not
186.37s - 189.49s |  claiming that they are more or less secure than other companies. We're kind of
189.49s - 193.09s |  just unlucky that they're one of the market leaders and that they build good
193.09s - 197.53s |  products. So yeah, so we basically have chosen them because we have a good
197.53s - 200.61s |  reputation, they have a quality of products, we just might have made some
200.61s - 205.49s |  mistakes. We reported the things also to the vendors, and digilock is actively
205.49s - 209.65s |  working on fixing the issues, and I will tell, give you some information later on
209.65s - 215.93s |  that. So about this talk, it's basically a continuation of my Nulcon talk
215.93s - 222.21s |  at Nulcon Berlin 24. The focus, and this is the important part, on offline locks
222.21s - 225.37s |  which are managed. So if there's like a master key or something, if you think of
225.37s - 230.49s |  a gym or, you know, master keyed systems. And we do not cover a couple things. For
230.49s - 233.41s |  example, we do not cover management software, we do not cover
233.41s - 237.17s |  reprovisioning, so how to, you know, factory reset the lock. We also don't
237.17s - 241.13s |  talk about physical attacks using magnets or destructive attacks like
241.13s - 246.13s |  drilling, you know, decapping, all other kinds of things. And later on, we have
246.13s - 251.17s |  included a statement of digilock in regard to their cease and desist.
251.17s - 257.01s |  Alright, so what is our motivation here? So generally, back then when I was, you
257.01s - 261.89s |  know, looking at locks, I realized quite quickly that hacking locks is not that,
262.41s - 267.25s |  you know, new. There's a lot of people who were hacking like high security locks, so
267.25s - 270.29s |  a lot of researchers were kind of focusing on that, especially like safe locks,
270.29s - 275.09s |  because there's probably very important stuff in there. A lot of research has
275.09s - 279.29s |  been put into side channel attacks, you know, safes contain expensive things, and
279.29s - 284.53s |  the impact is like very high if they're insecure. The general problem is for, you
284.53s - 287.77s |  know, manufacturers or for even companies who have this kind of devices, it's very
287.81s - 292.21s |  hard to defend against physical attacks and highly motivated attackers. So if I'm an
292.21s - 295.53s |  attacker, if I have unlimited time and money, then I will get into whatever it
295.53s - 300.49s |  is. In regard to consumer devices, it's slightly different. So consumer locks,
300.49s - 304.81s |  safes, and cabinets are known to be bad, and there's mechanical flaws, there's
304.81s - 308.53s |  trivial bypasses, you know, using magnets and other things, and there's insecure
308.53s - 313.05s |  software. And I have an example here from one of my favorite YouTubers, a lock
313.05s - 316.85s |  picking lawyer, where he has like a, you know, gun safe kind of thing where you
316.85s - 322.13s |  put the gun in, and you just pry open the plastic handle, and you can just pull
322.13s - 327.05s |  the gun out, you don't care about the lock. So, you know, sometimes you don't
327.05s - 332.21s |  need to even attack locks, you know, there's other ways around that. Okay, so
332.21s - 336.29s |  how did we start with this particular research? So I was at Northeastern
336.29s - 340.77s |  University like around 2018, and they introduced lockers in the labs. And one
340.77s - 344.17s |  of the idea was like, you know, you can put your stuff in, and you just choose
344.17s - 347.37s |  your own pen, lock it, and, you know, if you come back, you unlock it again, and
347.37s - 351.37s |  the next one can use it. But also when we were traveling around, we saw like these
351.37s - 355.65s |  locks in many, many co-working spaces, banks, airports, hotels, gyms, so we were
355.65s - 359.37s |  literally everywhere. At some point, you develop an eye for like interesting
359.37s - 364.29s |  things around you. And one thing which we figured out very quickly is
364.29s - 367.81s |  there's only a few widely used vendors which are out there, so there's like, you
367.81s - 370.57s |  know, the groups like in the US in particular, like the DigiLock, or like
370.89s - 375.93s |  in Europe, SAG, there's some very limited kind of vendors out there. And these kind
375.93s - 379.09s |  of locks, they stay for a very, very long time in use, because why would you change
379.09s - 383.01s |  gym lock like, you know, after five years or after four years or whatever? So these
383.01s - 386.25s |  things typically stay in use like for 10 years, 20 years, until they're broken
386.25s - 392.21s |  basically. Okay, the question is now why do we hack cabinet lockers or lockers
392.21s - 396.49s |  generally and not safes? Well, lockers and cabinets are basically everywhere, and
396.49s - 399.97s |  they're used in public spaces or spaces which are accessible to the public or
400.09s - 403.65s |  shared workspaces. And there might be many reasons why you want to hack them.
403.65s - 406.85s |  For example, you forgot your pin, you lost your key, or you do a red team
406.85s - 410.93s |  penetration test. Also, you know, sometimes the audit locks are not super
410.93s - 415.93s |  correct, so you want to, you know, correct them. And they might contain a lot of
415.93s - 418.93s |  interesting stuff, and including our own. And this is like what I want to say is
418.93s - 421.49s |  like, I mean, one of the reasons why we do the research is because we're kind of
421.49s - 425.33s |  slightly annoyed because our stuff is also that kind of lockers, so this is one
425.33s - 428.73s |  big motivation from us. So what kind of things do you might store there?
429.13s - 432.89s |  Well, you might store your backpack, laptop, employee ID, phone, keys, money,
432.89s - 440.37s |  credit cards, USB sticks, important documents, your bitcoins, or candy. So the
440.37s - 444.81s |  question is, well, did you use the same pin which you use to lock the locker also
444.81s - 454.06s |  for your phone, notebook, or credit card? Quick survey, who has a friend that does
454.18s - 462.18s |  this? Who reuses their pins? No, you're not supposed to admit that.
462.18s - 464.98s |  To be fair, I mean, in the beginning, before I was doing the research, I caught
464.98s - 468.30s |  myself using the same pin all over again. So that, you know, it gets a little bit
468.30s - 472.74s |  complicated. Anyway, so what kind of attack ideas do we have and how do we do
472.74s - 477.18s |  it? So what are we looking for generally in this kind of devices? Well, we try to
477.18s - 480.78s |  extract somehow the firmware, because firmware can give us like some secret
480.78s - 484.98s |  backdoors or bugs. It helps us to understand functionality, and it can
484.98s - 488.74s |  allow also an attacker to create, you know, custom firmware. You know, like
488.74s - 493.98s |  basically declouding or n-certification of smart locks. The other thing is, which
493.98s - 498.34s |  is obviously the crown jewels here, is the interesting data in terms of like key
498.34s - 503.58s |  IDs, user pins, RFID IDs, or log files. And the other thing, if you do
503.58s - 507.50s |  lockpicking, you know it, you try to find like any easy way to bypass things and
507.50s - 512.94s |  to open locks. So our idea, and this is like why we want to kind of stress on
512.94s - 516.26s |  that, it's not necessary, but we want to steal your stuff. But we don't want to
516.26s - 519.78s |  steal your stuff anyway, but I mean, theoretically as attackers. But lateral
519.78s - 524.26s |  movement, and that's the core idea of our talk. So how do we do it? So we have, in
524.26s - 528.66s |  this particular example, three cabinets. Basically one of them is open, two of them
528.66s - 531.78s |  are locked. One is locked with a pin, the other one is locked with an RFID. And so
531.78s - 535.14s |  what we do is, like, we try to extract a manager key from the locker which is
535.14s - 538.62s |  open. As soon as we have the manager key, this is like a key which you use to kind
538.62s - 541.58s |  of unlock the locker, to audit things in there, so that there's nothing, you know,
541.58s - 546.38s |  like the Defcon hotel, it's like sketchy things, your flipper. And you can lock it
546.38s - 550.50s |  again without resetting the pin. So by having this manager key, what we can do
550.50s - 557.38s |  is basically we can unlock other lockers, and we can extract from the lockers, like
557.38s - 561.26s |  with the pin, we can extract the user pin. At the same time, we can obviously
561.26s - 564.50s |  access whatever is in the locker. So if you have a laptop in there, and if you
564.50s - 568.34s |  have your phone in there, well, we might be able to use the pin which you use to
568.34s - 572.62s |  lock the locker to, you know, unlock that. But it gets even more interesting, because
572.62s - 578.50s |  well, we can also extract the RFID, you know, ID or secret, in some cases, from a
578.50s - 582.46s |  lock which was used to lock the locker with an RFID or employee badge. And then
582.46s - 585.66s |  we can go to an interesting door, like a server room or something, and can use that
585.66s - 590.62s |  to unlock that. Especially SAG, they use test fire encryption, so they store the
590.62s - 595.62s |  keys, which gets very, very interesting here. All right, so how do you get that
595.62s - 600.10s |  kind of locks? What's the logistics behind that? The problem is, if you do that
600.10s - 603.78s |  kind of research, you need to invest a lot of time and money, and experiments
603.78s - 607.74s |  typically require multiple devices. And you obviously cannot use someone else's
607.74s - 611.46s |  property, because there might be one or two bricks in the process of, like,
611.46s - 616.46s |  reverse engineering that. These locks are also expensive, so typically you pay
616.50s - 621.10s |  between, like, more than $100 for a lock, and more than $50 for a key, or, like, way
621.10s - 625.78s |  more than $50. We will talk about that later. But the good thing was, for us,
625.78s - 630.02s |  there's surplus on eBay. And it's a little mean, but COVID kind of helped us a little
630.02s - 633.30s |  bit, because a lot of gyms kind of got bankrupt, so they kind of offset their
633.30s - 637.46s |  locks and other things on eBay. And we got a lot of, like, cheap provisioned locks,
637.46s - 640.10s |  so locks which were already provisioned through some manager key or programming
640.10s - 644.74s |  key, which we were able to play around with. And the other thing is, especially
644.74s - 647.90s |  in Germany, we got a lot of locks from failed projects. Basically, we have been,
647.90s - 651.02s |  like, a big, like, kind of gym, which kind of, you know, didn't happen. So we had,
651.02s - 653.94s |  like, stacks and stacks of these locks, and we kind of sell them on eBay for a
653.94s - 659.18s |  cheap price. So we spent probably more than $1,000 or $2,000 on buying random
659.18s - 665.14s |  locks, which we don't even have so many lockers for. So, as mentioned, I mean, we
665.14s - 669.74s |  were going on a shopping tour on eBay, and, you know, bought, like, a lot of locks.
669.74s - 673.78s |  So let's talk about the DigiLock ecosystem, and this is, like, our first
673.78s - 678.76s |  candidate for which devices we looked at. So DigiLock itself, we're, like, a
678.76s - 682.54s |  brand of Security People Inc., which is US-based, and they are in the industry for a
682.54s - 685.10s |  very, very long time. So they're very experienced, especially also with
685.10s - 688.74s |  mechanical locks. They call themselves the global leader in keyless lock
688.74s - 692.14s |  solutions, and they have many different bands of locks. So they have connected
692.14s - 694.94s |  locks, which we're not talking about. We have offline locks. We have mechanical
694.94s - 699.22s |  locks. And as access media, you can use, like, RFIDs, the pins, key fobs,
699.22s - 703.26s |  smartphones with the newest generation. And you might see them under different
703.26s - 707.50s |  brands. For example, DigiLock, Nex, Numeris, so there's different ones. If you take a
707.50s - 710.14s |  look at their website, I mean, they kind of say, like, they're literally in all the
710.14s - 714.18s |  industries, which is, like, I mean, that's the reason why we kind of saw them in the
714.18s - 717.58s |  first place, because we're, like, in education, in gyms, in some professional
717.58s - 721.78s |  sports organizations, so we're literally everywhere. The way how you can typically
721.78s - 727.14s |  identify them is, this is some examples right now, by the three-pin connector,
727.14s - 730.78s |  which we use, like, which is very specific for DigiLock. Other lock vendors use
730.78s - 733.42s |  slightly different kind of connectors, but this is, like, a thing, if you see
733.42s - 737.18s |  that, it's kind of, like, you know, kind of know what it is. If you take a look at
737.18s - 740.80s |  the lock hardware itself, the good thing for us is that they use more or less the
740.80s - 745.50s |  same or very similar hardware, so they use a similar type of MCU. So if you're
745.50s - 748.66s |  kind of familiar with one of them, you kind of know how the arrows work in a way.
748.66s - 753.62s |  So this makes it also a great kind of thing for us as reverse engineers. And
753.62s - 757.34s |  they didn't have tamper switches, so if you just assemble one, then there's
757.34s - 760.46s |  nothing which triggers, which is, by the way, very, very normal for, like, you know,
760.46s - 764.78s |  kind of low security or middle security locks. Only safe locks have, like, some
764.78s - 768.38s |  tamper switches and other things. The lock state is controlled by the latch,
768.38s - 770.86s |  which is kind of interesting for us, and we'll kind of talk about that later.
770.86s - 775.02s |  And because we have so much experience with mechanical locks, we added a lot of
775.02s - 778.58s |  mechanical protections against physical attacks. So, for example, you cannot use,
778.58s - 782.22s |  like, bypassing things. We tried a couple things with needles, so there's no way to
782.22s - 786.46s |  kind of, you know, bypass things. So we did a very good job there. The features
786.50s - 790.42s |  which you get per lock are kind of dependent on the brand. So some of them
790.42s - 794.18s |  support audit locks, so you can basically record who opened or locked the locker.
794.18s - 799.50s |  And they have assigned and shared locker functionality, which means sometimes you
799.50s - 803.90s |  can give an employee just one locker and only that person can use it, or you
803.90s - 807.98s |  have a scenario like in the gym. If you take a look closer at the hardware, one
807.98s - 811.18s |  thing which is kind of great for us is all of them have a PIC programming
811.18s - 815.62s |  interface exposed. Many of them have EEPROM. We have obviously an MCU. We have a
815.62s - 820.22s |  connection to the inside unit, which kind of contains the latch and the motor,
820.22s - 824.98s |  and it gets all the power from there. We have a piezo for the sound. And the most
824.98s - 828.90s |  interesting thing for us was the interface. As you see, we soldered
828.90s - 834.22s |  some wires to that to kind of intercept that, which is basically one wire.
834.22s - 838.38s |  Hardware-wise, if you take a closer look at the microcontrollers, we use most of
838.38s - 842.26s |  the time PIC18 controllers, but sometimes, especially newer models,
842.26s - 847.70s |  we use PIC24s. We have EEPROM for audit locks and for credential storage in some
847.70s - 853.10s |  of them devices. And if you have a device which supports RFIDs, you have an ST
853.10s - 859.06s |  kind of controller for NFCs, or the newer ones have a logic IC, which is
859.06s - 863.78s |  also an HSM. And from what they told us, basically in new generations of
863.78s - 867.74s |  these locks, we use the HSM to store some kind of secrets, which we can
867.74s - 872.10s |  confirm because it's not on eBay right now, so I need to wait until it shows up
872.10s - 878.30s |  on eBay. So if you look inside at the locker hardware, the thing which
878.30s - 881.18s |  works for me, as someone who's doing physical security for quite a while, is
881.18s - 884.94s |  it's extremely well built and engineered. And what I mentioned
884.94s - 887.82s |  before is that the inside lock kind of defines if it's locked and unlocked. You
887.82s - 891.50s |  have some read contacts, which are kind of sensing if the latch is
891.50s - 896.90s |  locked or not locked. There's also different variants of the lock,
896.90s - 901.02s |  like where everything is just in the front, and we have, again, read contacts,
901.02s - 905.10s |  which kind of detect a couple things. But all of the locks have some kind of
905.10s - 910.70s |  debug pins. So let's talk about the keys. So there's a bunch of keys, and you see
910.70s - 914.86s |  we have a stack of them because we were going on shopping trips. The most
914.86s - 918.66s |  important one is the yellow key, which is the programming key. Only one of them
918.66s - 922.46s |  exists in the locking system. This is basically the main provisioning key. It
922.46s - 925.66s |  allows you to add manager keys, to remove them, to overwrite the lock, so if you
925.66s - 930.22s |  need to open the lock. It also is used to power deadlocks, so if the battery is
930.22s - 933.34s |  empty, you can use it to power jump it. And it has some additional
933.34s - 936.22s |  functions like cloning functionality, audits, and some other
936.22s - 941.26s |  things. Another key which is important is the black key, which is the manager key.
941.26s - 944.54s |  And this is basically, typically, your administrator or whatever has it to
944.54s - 948.62s |  kind of, you know, you forgot your pin, to open the locker so that you can get
948.62s - 953.50s |  your stuff, or to kind of check if you have a flipper in there, a legal flipper
953.50s - 957.18s |  in there. So this is kind of things which it's used for. And one thing which is
957.18s - 960.06s |  very, very special for Digilock, and this is like kind of, I think, one very
960.06s - 963.98s |  important feature for a lot of people, is the so-called ADA key, which is in blue.
963.98s - 969.30s |  And ADA means Americans with Disabilities Act. So this key allows you
969.30s - 974.78s |  basically, for people who cannot enter a pin physically, you just tap the key fob,
974.78s - 980.82s |  and it will kind of act as a pin, or as a key. Yeah. So if you take a look closer
980.82s - 984.18s |  into these keys, well, all of them are kind of the same. So programming the
984.18s - 986.46s |  manager keys, by the way, have exactly the same hardware, just the case is
986.46s - 991.70s |  different, but price-wise, they are very different. They have a battery in there,
991.70s - 995.50s |  they have a PIC-18, and they have, again, very nice for us, a PIC programming
995.50s - 1001.60s |  interface. The ADA key is basically an I button, which will be, later, we will use
1001.60s - 1006.54s |  for some things. There's one special key, which we're not going too deep into it,
1006.54s - 1010.38s |  it's a so-called data key, and what it does is, basically, it connects over USB
1010.38s - 1014.06s |  to a tablet, and you can basically use it as a programming or manager key, you can
1014.06s - 1017.18s |  have, you know, audit logs, you can pull things, you can clone logs, and some other
1017.18s - 1020.82s |  things. So this is like an additional thing, which I think they have in their
1020.82s - 1025.70s |  fifth generation or something. It's a little more expensive, but it doesn't
1025.70s - 1031.72s |  matter for us. All right, so what is the key communication between, the
1031.72s - 1035.06s |  communication between lock and key? And the thing here is, which you probably
1035.06s - 1038.90s |  figured out very quickly already, is OneWire. And OneWire, by the way, is a
1038.90s - 1041.62s |  very standard protocol. You find it in a lot of alarm systems, you find it, like,
1041.66s - 1045.22s |  if you go to a restaurant, for to unlock the cash register, and some other things,
1045.22s - 1049.86s |  it's a, you know, it's a very standard kind of thing, which makes it great to be
1049.86s - 1052.70s |  intercepted with a logic analyzer. So there's some tools out there which you
1052.70s - 1057.30s |  can use to kind of basically decode the stream. They use the read ROM command to
1057.30s - 1062.62s |  kind of, you know, ask the key for, like, its ID, and the key returns eight bytes
1062.62s - 1067.34s |  of ID to the lock, and this is, like, basically authentication. And the key
1067.38s - 1072.10s |  types are identified basically by the first byte of the ID. One thing which is,
1072.10s - 1075.26s |  like, important if you want to do side-channel attacks or timing attacks, the
1075.26s - 1079.50s |  bus resets after every transaction. In our talk at Nulcon, we kind of described
1079.50s - 1083.58s |  how, you know, you potentially could do side-channels. One key thing to take away
1083.58s - 1087.42s |  here is we don't use any crypto, so we kind of rely on whatever security
1087.42s - 1094.46s |  guarantees OneWire has. All right, I want to give a quick rundown of PIC MCUs
1094.58s - 1098.42s |  because it's kind of important to understand what's going on here. So PICs
1098.42s - 1103.10s |  generally are microcontrollers by microchip. They are very common in locks, so
1103.10s - 1106.18s |  literally everyone is using them. Siemens of us use them, Schlage use them,
1106.18s - 1112.10s |  Kitlock uses them, so everyone uses them. And they are ideal because they are
1112.10s - 1115.42s |  low-power and ideal for battery operations. There's two flavors which we
1115.42s - 1119.62s |  see for DigiLock in particular, or for other locks. It's a PIC18, which is
1119.62s - 1124.90s |  an 8-bit MCU, which was released back in 2000, and a PIC24, which has a 16-bit
1124.90s - 1131.26s |  MCU, which has no EEPROM data on board. So basically, you can flash the firmware
1131.26s - 1135.14s |  onto it, but you need to store your data somewhere else. Okay, so this is an
1135.14s - 1141.26s |  example of a random PIC18. So we have some SRAM, we have flash, we have EEPROM,
1141.26s - 1145.70s |  as mentioned, and they have support for some protections. For example, you can
1145.70s - 1148.46s |  enable code protection, you can enable write protection, and there's also like a
1148.46s - 1152.42s |  thing which is called external block table read. And on the right, you can see
1152.42s - 1157.34s |  it's like consisting of multiple blocks, and at the bottom is like the EEPROM part.
1157.34s - 1161.82s |  So let's talk about the code protection. Speaking of which, code protection is, I
1161.82s - 1166.06s |  think, a very PIC-specific term. If you work with other processors, you might
1166.06s - 1170.14s |  know it as readout protection. And the basic idea is we have here an example
1170.14s - 1173.78s |  lock, which is not an example lock, just an example chip, where the first two
1173.78s - 1177.46s |  blocks are protected, the data is protected, and if you connect our
1177.46s - 1181.06s |  programmer to it, what will happen is we will get, for the blocks which are
1181.06s - 1186.86s |  protected, all zeros, but the blocks which are not protected, we get data back. So
1186.86s - 1190.48s |  write protection, similar thing. The first two blocks are protected, the last one is
1190.48s - 1195.02s |  protected. If you try to write with our programmer something to that, the
1195.02s - 1199.66s |  writes will fail for them, but the other blocks are programmed. Speaking of
1199.66s - 1205.58s |  security of these chips, these MCUs, they offer basically only basic protection
1205.58s - 1209.34s |  against attacks, so there's many attacks which exist for these chips, even if
1209.34s - 1215.02s |  protections are enabled. There's optical laser attacks back in 2002, there's UV
1215.02s - 1219.10s |  erasure attacks, there's glitching, there's like overwriting of individual
1219.10s - 1222.98s |  blocks, so there's a lot of attacks out there. So a lot of people kind of
1222.98s - 1228.06s |  already figured out how to break these chips. Okay, let's talk about
1228.06s - 1234.10s |  the attacks. So our naive approach was like, hey, what happens if you just
1234.10s - 1237.30s |  connect a debugger and we do some magic with power and other things, it's not as
1237.30s - 1243.70s |  terrible as it seems, and we try to dump the MCU. We had the luck that we exposed
1243.70s - 1249.26s |  the data pins, both for the locks and the keys, and one thing which we found is
1249.26s - 1252.30s |  basically that the protection settings which we did on the locks were very
1252.30s - 1257.54s |  inconsistent. So what do we mean with that? So typically, as mentioned, if readout
1257.54s - 1261.22s |  protection is enabled, you get all zeros back, like on the right
1261.22s - 1265.90s |  side. And one thing which we saw very quickly is that we didn't have the right
1265.90s - 1270.02s |  protection enabled, which is by itself not really an issue. But the bigger thing
1270.02s - 1273.38s |  was that if you use an external EEPROM, like an external chip, but it's not
1273.38s - 1277.22s |  encrypted, so you can dump it basically. And this is basically the result which
1277.22s - 1280.66s |  we had for the manager keys, for the data keys, and everything. One
1280.66s - 1285.30s |  thing which you will see is for most locks which use more modern
1285.30s - 1290.34s |  chips, they are not protecting the code, and all of them are not protecting the
1290.34s - 1294.14s |  EEPROM, which is in the case of some of them doesn't matter too much, but for
1294.14s - 1302.58s |  especially the locks, it matters a lot. So what are we doing? So for unprotected
1302.58s - 1306.74s |  devices which don't have any code protection enabled, we can just dump the
1306.74s - 1310.26s |  the code memory and the EEPROM directly. So we need a programmer, we need some
1310.26s - 1313.06s |  other hardware, but generally if you work with embedded systems, you
1313.06s - 1316.14s |  know how to do that. For partially protected devices, it gets a little bit
1316.14s - 1319.34s |  more tricky. So this is an example for a lock which had the first three blocks
1319.34s - 1324.46s |  protected, but the code was creeping into the fourth one which was not
1324.46s - 1329.66s |  protected. So what we were doing is we can dump the fourth block and you can
1329.66s - 1334.50s |  put a custom dumper into that block which hopefully gets hit by some code
1334.50s - 1339.38s |  or branch link, and then we can dump the other ones. There's some other methods
1339.38s - 1341.90s |  out there, but because we kind of cash-strapped and don't want to spend
1341.90s - 1344.98s |  too much time on buying more locks of the same kind of thing and
1344.98s - 1348.34s |  hoping that it's the same firmware, this is basically one of the
1348.34s - 1353.26s |  things you can do. Otherwise you can just access the EEPROM data directly, so
1353.26s - 1358.10s |  it's the same as the other ones. We described this attack at NuCon in the
1358.10s - 1361.42s |  talk, so if you're interested in that, but it's a very generic attack, it's kind of
1361.42s - 1366.78s |  well-known for quite a while. So basically the firmware extraction can
1366.78s - 1371.14s |  be successful for all the locks, so we can get back the firmware. You can
1371.14s - 1374.10s |  analyze the firmware, you can modify it if you want, you can basically load it
1374.26s - 1379.02s |  into GDRAW because it has big support. There's no real signatures, integrity
1379.02s - 1382.74s |  checks, which is kind of normal for that kind of thing, and the methods are well
1382.74s - 1387.98s |  established. But the thing for us is we don't necessarily need to
1387.98s - 1390.62s |  even look at the firmware if you have the data, so that's just a thing.
1390.62s - 1394.54s |  So let's talk about the EEPROM contents, because that's where the cron jewels are.
1394.54s - 1398.74s |  One thing is it requires quite a while and a lot of trial and error to
1398.74s - 1401.62s |  figure out which data fields are for what, especially if you have only
1401.66s - 1404.22s |  provisioned locks and you don't have clean locks which are provisioned,
1404.22s - 1408.34s |  you kind of see what the differences are. And the data fields also differ
1408.34s - 1411.62s |  slightly between lock generations and between lock types, so this is not
1411.62s - 1414.90s |  accurate for other locks, it's just one example for an older fourth
1414.90s - 1418.78s |  generation lock. But what we see typically is we have a partial
1418.78s - 1422.66s |  programming ID, we see the amount of manager keys, we see what kind of
1422.66s - 1428.86s |  manager key is provisioned on that, we see if a pin was set, ADA key ID,
1428.98s - 1435.98s |  or RFID UID, so if you tap the RFID. And there's also failed pin counter,
1435.98s - 1438.66s |  and for older locks, bad things might happen if you run over that.
1438.66s - 1445.06s |  Just don't. As a general observation, some locks don't wipe the user pin
1445.06s - 1449.58s |  or the key after it had been unlocked by the user, and some, especially
1449.58s - 1452.14s |  newer versions do, so at some point I think we figured out there's a problem
1452.14s - 1454.30s |  and we kind of fixed that.
1454.30s - 1457.02s |  All right, so let's talk about emulation and cloning keys.
1457.34s - 1462.54s |  And this kind of thing applies to both RFIDs and keys, so we only need
1462.54s - 1467.66s |  the ID basically to clone the key, and we cannot extract from the key
1467.66s - 1472.18s |  or the flash depending on what kind of media we have. And we can emulate
1472.18s - 1477.94s |  it with an Arduino, with a Flipper Zero, or in case of RFIDs with a Proxmark.
1477.94s - 1481.02s |  The thing is it looks a little bit easy, but you have to kind of build
1481.02s - 1484.98s |  like a custom PCB which does a couple things to kind of wake up the lock
1484.98s - 1487.90s |  in a particular way, so it's not as trivial as you can do it right now.
1487.90s - 1490.70s |  You need to kind of put some effort into that, so don't go home and just
1490.70s - 1493.22s |  program an Arduino. It won't work.
1493.22s - 1496.66s |  All right, what kind of other ideas could you have if you want to attack them?
1496.66s - 1499.78s |  Well, you could try to brute force pins and keys, which works for older locks
1499.78s - 1503.26s |  very well, but for newer locks not so much. You can do side-channel attacks,
1503.26s - 1505.82s |  which works for all of them as far as we know, but it's very complicated,
1505.82s - 1509.66s |  takes like days. You can clone the lock configuration by one wire if you have
1509.66s - 1514.38s |  a valid key, and you can try to modify the contents of EEPROMs.
1514.38s - 1517.74s |  Also, you could think of like building a malicious firmware.
1517.74s - 1521.94s |  We thought about that, but I mean, it's not really necessary to do.
1521.94s - 1524.66s |  If you're interested in the first two attacks, you can take a look at the
1524.66s - 1529.86s |  slides at NuCon. Now probably one of the reasons why you guys are here is the
1529.86s - 1534.06s |  cease and desist incident. So our talk was basically meant to be on Friday
1534.06s - 1539.46s |  at 11 a.m., and the day before at 2 p.m., we basically got an email,
1539.46s - 1542.42s |  cease and desist, which kind of came to a couple of things, like copyright act,
1542.42s - 1546.78s |  Defend Trade Secrets Act, you know, obviously other things like the Computer
1546.78s - 1551.46s |  Fraud and Abuse Act and the DMCA. And the interesting thing here is,
1551.46s - 1556.66s |  and I want to especially thank Corey to kind of connect us so quickly,
1556.66s - 1561.42s |  who's sitting in the front. Thank you. By 3.30, basically slightly more than an
1561.42s - 1564.82s |  hour later, we were sitting already in a hotel room and talking to lawyers from the
1564.82s - 1570.30s |  EFF and also from Kurt, and we were basically figuring out what was going on.
1570.30s - 1573.66s |  And so to kind of, because it was very short notice, we kind of moved the talk
1573.66s - 1576.62s |  from Friday to Sunday. We probably could have given the talk on Friday,
1576.62s - 1580.46s |  but we decided like, okay, it might be worth to kind of figure out what's going on.
1580.46s - 1583.62s |  On Saturday, so yesterday, we had a phone call in both of everyone.
1583.62s - 1587.42s |  We kind of exchanged views. We kind of resolved our differences.
1587.42s - 1590.18s |  And in that call, we kind of pulled the cease and desist back.
1590.18s - 1593.18s |  And officially today, shortly after midnight, we got like the withdrawal
1593.18s - 1597.70s |  in writing for the cease and desist. One thing which I want to quickly say is
1597.90s - 1600.78s |  there's like a kind of official response from DigiLog.
1600.78s - 1603.50s |  They kind of acknowledged that we communicated with them prior to DEF CON.
1603.50s - 1607.94s |  We gave them the slides even, which was maybe a mistake, maybe not.
1607.94s - 1611.94s |  They promised to do some improvements. For example, they want to enable code
1611.94s - 1615.70s |  protection on their logs. For the data blocks, they want to enable
1615.70s - 1619.98s |  for the firmware. They want to encrypt somehow the
1619.98s - 1625.18s |  communication between the keys and the log so that you cannot clone the UID
1625.18s - 1629.02s |  anymore, and they want to encrypt EEPROM data if it's external.
1629.02s - 1633.30s |  They also told us that in over 32 years, we'd had no reported security incidents
1633.30s - 1636.46s |  due to a hacked log, which I think, I believe.
1636.46s - 1642.14s |  And they're also very committed to the security solution for their customers.
1642.14s - 1645.30s |  And I put their full statement, which they sent us, on slide 70.
1645.30s - 1649.06s |  So if you look later on the slides, you'll find it in the back.
1649.06s - 1652.42s |  All right, that's all for DigiLog. Let's move on with the next company
1652.46s - 1656.90s |  and Brayden.
1656.90s - 1661.58s |  Cool. So let's shift gears and talk about a couple of other brands that we took
1661.58s - 1667.94s |  a look at as far as logger locks go. The first one being Schulte Schlagbaum AG.
1667.94s - 1672.54s |  So this is a German company. They've been in business since 1833,
1672.54s - 1676.46s |  so quite an old company. These are more widely used in Europe
1676.46s - 1679.78s |  and Germany. They produce both mechanic and electronic
1679.78s - 1682.42s |  logger locks. We took a look at the brand called
1682.42s - 1688.98s |  Safotronic. They also produce door locks, but we didn't take a look at those.
1688.98s - 1692.82s |  We think they might be on the same platform, but we're not entirely sure.
1692.82s - 1700.02s |  So the electronic locks accept both PIN and RFIDs or RFID plus PINs as access
1700.02s - 1704.30s |  mediums, and they do provide audit log support.
1704.30s - 1709.90s |  So let's talk about the LS series of locks. These are based on the STM32 MCU,
1709.90s - 1714.18s |  and they also have SPI EEPROM. As for security, we found that SWD
1714.18s - 1719.30s |  and debugging was not disabled, and their EEPROM is not encrypted.
1719.30s - 1724.10s |  And we noticed a lack of physical tamper switches in the locks.
1724.10s - 1729.10s |  So as you can see, these are PCBs for three different locks.
1729.10s - 1735.02s |  We think that they tried to save money by using the same design for nearly a decade.
1735.02s - 1738.86s |  They use the same PCB, but they leave ICs unpopulated.
1738.86s - 1745.22s |  So if you buy a lock that has PIN support, you'll get an MCU for the keypad and a
1745.22s - 1752.10s |  different MCU for RFID, and you'll get both for the RFID and PIN-supported locks.
1752.10s - 1757.46s |  We also noted a difference in SPI EEPROM sizes.
1757.46s - 1765.58s |  Okay, so let's talk about the management keys for some of the RFID SAG locks.
1765.58s - 1771.90s |  So their RFID locks support MyFair Classic, MyFair DeskFire, and some ISO-compatible tags.
1771.90s - 1776.38s |  For the higher-end locks, there are special RFID keys that are required for programming.
1776.38s - 1781.70s |  There's a master key 1 and 2. Those are used for unlocking and relocking lockers.
1781.70s - 1786.30s |  There's also a data RFID tag for data transport, if you need to, like,
1786.30s - 1791.58s |  pull audit logs off of certain locks. There's also, like, a physical communicator device,
1791.58s - 1795.82s |  which is, like, an advanced handheld programmer, but we didn't take a look at that.
1795.82s - 1802.86s |  We tried to procure a set of these programming keys, but they were $1,400 for eight MyFair
1802.86s - 1810.74s |  Classic tags, so we didn't think it was worth the money, so we didn't take a look at those.
1810.74s - 1816.98s |  So just a quick overview on how we dumped EEPROM contents, just using an SOIC clip.
1816.98s - 1823.22s |  We were able to interface with the EEPROM and dump the context, as you can see in the hex file.
1823.22s - 1828.98s |  We were able to pull the master pin and the user set pin, so this is just totally unencrypted
1828.98s - 1835.54s |  EEPROM with pins that are available for anyone who can read it to see it.
1835.54s - 1839.06s |  We also found that there are audit logs on the EEPROM as well.
1839.06s - 1845.66s |  There are 500 entries, including a timestamp and a status code, with the status code 50
1845.66s - 1851.62s |  allowing you to see used pins and the RFID UIDs that have been used, so the last 500
1851.62s - 1856.18s |  you can see, yeah, all of that.
1856.18s - 1858.14s |  So how did we extract firmware?
1858.14s - 1864.50s |  We noticed on the PCB there was solder mask covering the SWD, like, copper pads, so we
1864.50s - 1869.98s |  scratched that off and we were able to interface with it and connect to SWD, and that allowed
1869.98s - 1874.94s |  us to see that the devs didn't set the read protection byte.
1874.94s - 1880.20s |  And as such, we were able to get the full firmware from these locks.
1880.20s - 1884.36s |  So there are a couple of physical flaws on these locks.
1884.36s - 1889.20s |  We noticed that the motor power wires and potentially debug pins are accessible from
1889.20s - 1894.68s |  outside of the lock through, like, a clipped plastic cover.
1894.68s - 1904.64s |  So there's just a huge gap, as you can see, the power wires to the actual, like, motor.
1904.64s - 1909.52s |  And yeah, as you can see on the right, we were able to fit a whole card under there,
1909.52s - 1917.08s |  so that might allow us to tamper with the lock motor and do some physical hacking there.
1917.08s - 1923.32s |  So we'll talk about a couple of other manufacturers now, one of them being Compex Security Company.
1923.32s - 1928.44s |  This is a U.S. company founded in 1903, so again, another pretty old company.
1928.44s - 1930.64s |  We took a look at the regulator series.
1930.64s - 1936.64s |  These use the PIC-16 MCU, and these locks accept user pins, technician pins, master
1936.64s - 1941.88s |  pins, and there is some audit logging support for some models.
1941.88s - 1946.44s |  As for security, we found that code data and write protection were enabled on all these
1946.44s - 1949.24s |  locks, so that's good for them, but not very fun for us.
1949.24s - 1954.56s |  So we kind of moved on, but we took a look at their documentation and saw what they were
1954.56s - 1960.72s |  using for a programming slash audit tool, an Excel spreadsheet.
1960.72s - 1965.28s |  I don't know what kind of Excel macro hell is happening here.
1965.28s - 1969.96s |  I'm glad I'm not the person who has to maintain this and write this, but if it works for them,
1969.96s - 1973.56s |  I'm happy for them.
1973.56s - 1975.64s |  So next we'll talk about Kitlock.
1975.64s - 1978.54s |  This is a sub-brand of CodeLocks.
1978.54s - 1981.84s |  This is a U.K.-based company founded in 1991.
1981.84s - 1988.96s |  This also uses the PIC-16 MCU and again accepts user pins, technician pins, and master pins,
1988.96s - 1994.96s |  and again, they had code data and write protection enabled, so good for them, not fun for us.
1994.96s - 2001.72s |  So for good measure, we took a look at a couple of no-name RFID locks from Amazon and eBay.
2001.72s - 2004.44s |  These are just like $20 locks, super cheap.
2004.44s - 2009.68s |  We took them apart and found that they had EEPROM and some kind of mystery MCU.
2009.68s - 2015.08s |  If you like mystery MCUs and know what this is, let us know.
2015.08s - 2023.84s |  Obviously, you can't really have many expectations of security on these cheap devices, so there's
2023.84s - 2031.12s |  no encryption, no protection, and plain text RFID UIDs are just there for anyone to read it.
2031.20s - 2038.80s |  Okay, so we're going to do a quick demo now to show how you can hack some of these locks.
2038.80s - 2044.12s |  All right, due to the season, we will change the demo slightly, so usually we were kind
2044.12s - 2048.84s |  of thinking of doing a whole rundown of how we can extract manager keys and other things.
2048.84s - 2053.20s |  What I would do instead is I would showcase our custom PCB, which we built ourselves and
2053.20s - 2055.44s |  took us some time to develop it.
2055.44s - 2059.44s |  What it basically does is it emulates the same function as a manager key, so I will
2059.44s - 2060.44s |  just show you.
2060.44s - 2064.84s |  I locked all the lockers from DigiLock in this case, and I will just kind of show how
2064.84s - 2067.76s |  I can hopefully open them again.
2067.76s - 2068.76s |  Yeah.
2068.76s - 2075.92s |  Okay, just like a quick example of a theoretical scenario, so we're going to assume that the
2075.92s - 2084.00s |  attacker has access to any open locker or cabinet with the tools, the microchip picket
2084.00s - 2088.64s |  three debugger, a Phillips screwdriver, and an Arduino and or flipper.
2088.64s - 2099.92s |  We're using the flipper here, so our criminal has already set the key onto the flipper,
2099.92s - 2104.95s |  and we are able to access the locks.
2104.95s - 2110.95s |  Yeah, so to be fair, we put a lot of effort into figuring it out already, so this is like
2110.95s - 2115.77s |  basically if you got access to a lock, you somehow extracted that, you built that kind
2115.77s - 2116.77s |  of tool.
2116.77s - 2121.29s |  It's a magic back side which we don't show.
2121.29s - 2123.33s |  The attack will work very quickly after that.
2123.33s - 2126.77s |  Now the obvious thing is if you want to extract secrets from these locks, you need to kind
2126.77s - 2129.05s |  of disassemble them, so you need a screwdriver.
2129.05s - 2131.81s |  The locks which are kind of just having the front part are super annoying because you
2131.81s - 2137.97s |  need a very special key to unscrew them, but generally, to open and relock them again without
2137.97s - 2142.49s |  resetting the original pin, that's basically all you need, but this might take you some
2142.49s - 2143.49s |  time to do.
2143.49s - 2144.49s |  All right.
2144.49s - 2149.29s |  So with that, for that, let's go to the conclusion.
2149.29s - 2150.45s |  Okay.
2150.45s - 2157.45s |  In summary, we were able to extract firmware and keys from these brands of locks, so access
2157.45s - 2163.49s |  to one lock can give you access to all locks in one system or one location.
2163.49s - 2169.87s |  Cloning and emulating keys is possible, and these attacks don't require complicated tools
2169.87s - 2172.37s |  and are sometimes cheap unless you're using the flipper.
2172.37s - 2174.81s |  It's a little bit more expensive, but...
2174.81s - 2178.29s |  So how secure is your stuff in electronic lockers?
2178.29s - 2183.13s |  Not super secure, but we need to be fair because these locks are not being sold as high-security
2183.13s - 2184.37s |  devices.
2184.37s - 2187.65s |  They're not promising, like, military-grade security or anything.
2187.65s - 2190.93s |  These are just standard-use locks.
2190.93s - 2193.49s |  So how can we fix this?
2193.49s - 2197.37s |  Of course, we would recommend a security-by-design approach from the beginning.
2197.37s - 2201.85s |  So enable all security features and always expect physical attacks when you're producing
2201.85s - 2203.69s |  locks.
2203.69s - 2207.13s |  Encrypt your secrets, store them in a secure way.
2207.13s - 2211.29s |  So the best solution for vulnerable locks would be to have firmware updates for all
2211.29s - 2216.73s |  of them, but depending on the age of the locks, this might not be possible, and it's...
2216.73s - 2217.73s |  We...
2217.73s - 2220.03s |  In our opinion, it seems unfixable.
2220.03s - 2224.47s |  So the workaround could be to use a programmer to enable code protection, but this only works
2224.55s - 2228.67s |  if data is stored on the MCU and not on an external EEPROM chip.
2228.67s - 2235.31s |  So this task is kind of complicated for an average and non-tech-savvy user, so it's not
2235.31s - 2237.15s |  a reasonable expectation.
2237.15s - 2241.45s |  So the likely solution would be to buy new locks or just ignore the problem and hope
2241.45s - 2245.15s |  it goes away.
2245.15s - 2247.43s |  So takeaway lessons.
2247.43s - 2252.87s |  Please don't reuse your important pins for lockers, like, public-use lockers.
2252.87s - 2257.11s |  Again, don't reuse your pins for your debit cards, your phone.
2257.11s - 2258.11s |  Use separate things.
2258.11s - 2259.11s |  Use, like...
2259.11s - 2263.75s |  We're all using separate passwords now for everything, I hope.
2263.75s - 2269.15s |  So treat your pin like a password, and never loan out your electronic keys, and always
2269.15s - 2274.95s |  be aware of security limitations of devices, and you cannot trust audit logs of these devices
2274.95s - 2277.27s |  because they can be tampered with.
2277.27s - 2281.95s |  So even experienced and big companies make mistakes, and developing stuff is way harder
2282.03s - 2288.47s |  than breaking it in 90% of cases, so be nice to developers.
2288.47s - 2291.11s |  It's hard when people are attacking your stuff.
2291.11s - 2295.19s |  And always remember there might be interesting cyber-physical systems around you.
2295.19s - 2298.05s |  So don't forget the human factor.
2298.05s - 2302.67s |  Can you just ask nicely for the manager key?
2302.67s - 2304.27s |  So final notes.
2304.27s - 2306.63s |  Please don't break into lockers you don't own.
2306.63s - 2312.87s |  I know these systems are in a lot of places, hotels and such, but please don't.
2312.87s - 2316.91s |  Anything with these locks can also permanently break them, which is kind of the standard
2316.91s - 2318.71s |  expectation when you're hardware hacking.
2318.71s - 2321.27s |  You can always break things quite easily.
2321.27s - 2322.27s |  Be careful.
2322.27s - 2325.97s |  There are more attacks that we haven't covered here.
2325.97s - 2331.47s |  And other companies and products are possibly vulnerable too, and just because they claim
2331.47s - 2337.11s |  that they've never been hacked doesn't mean they're unhackable, of course.
2337.11s - 2338.11s |  And yeah.
2338.11s - 2339.11s |  Thanks, all.
2339.39s - 2340.39s |  Cool.
2345.69s - 2350.49s |  So I would like to also give special thanks to Cori, who kind of connected us with Dolores,
2350.49s - 2356.89s |  to Tara, who did that too, to our console, Hannah and Kurt, and to Andrew, and everyone
2356.89s - 2357.89s |  at EFF.
2357.89s - 2364.93s |  And this kind of gave me, again, a motivation to definitely donate a lot of money to EFF.
2364.93s - 2370.51s |  One maybe side story is that Braylon was at B-Sides before this event and was getting
2370.51s - 2374.11s |  a membership for EFF and was kind of joking, like, oh, we might need you tomorrow.
2374.11s - 2379.67s |  And lo and behold, literally one day after that, on her birthday, of all the facts, both
2379.67s - 2381.59s |  of us got a cease and desist letter.
2381.59s - 2384.51s |  So if you have questions, we might be still around here.
2384.51s - 2388.15s |  Otherwise, feel free to contact us.
2388.15s - 2390.55s |  And thank you very much for being here.
2390.55s - 2391.83s |  Right.
2391.83s - 2395.43s |  So yeah, if you also want to read the statement, it will be in the slides.
2395.43s - 2398.83s |  And I hope we will find a solution also to kind of fix the older locks.
2398.83s - 2402.07s |  So there's probably a way we will figure it out together.
2402.07s - 2402.27s |  Thank you.


url: https://www.youtube.com/watch?v=4xjRgr4dbzU
title: DEF CON 32 - 1 for All, All for WHAD: wireless shenanigans made easy - Romain Cayre, Damien Cauquil
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=4xjRgr4dbzU",
  "title": "DEF CON 32 - 1 for All, All for WHAD: wireless shenanigans made easy - Romain Cayre, Damien Cauquil",
  "description": "A lot of security research have recently focused on various wireless communication protocols, targeting smartphones, wireless mice and keyboards and even cars. In order to demonstrate these attacks, researchers developed dedicated tools that for most of them include some specialized firmware of their own but also rely on various unique custom host/device communication protocols. These tools work great but are strongly tied to some specific hardware that at some point will not be available anymore, or require hackers to buy more hardware to carry on to have fun with. Why not making these tools compatible with more hardware ? And why researchers always have to create their own host/device protocol when it comes to using a dedicated hardware ? Why not having one flexible protocol and related tools to rule them all ?\n\nWe will present in this talk WHAD, a framework that provides an extensible host/device communication protocol, dedicated protocol stacks and way more for hackers who love having fun with wireless protocols. WHAD makes interoperability possible between tools by allowing different hardware devices to be used if they provide the required capabilities, giving the opportunity to create advanced tools without having to care about the hardware and its firmware in most of the cases!",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2680,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

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

 the way from France. One for all and all for WHD wireless shenanigans made easy. Please
6.99s - 14.08s |  welcome to the stage Damian and Roman.
14.08s - 22.15s |  Hello DEF CON. Ok so this is uh last talk for today on this track and we are going to
22.15s - 29.09s |  present you uh something we've been working on uh since more than two years now and this
29.09s - 40.07s |  is what? Oh. As usual. Ok so uh let me introduce ourselves. I'm Damian, Damian Coquille from
40.07s - 44.87s |  Squawk- Squawkstab. I'm the maintainer of a tool called B-T-E-L-E-J-A-C-K or B-T-E-L-E-J-A-C-K
44.87s - 51.11s |  call it what you want. Uh this is a BLE Swiss Army- Swiss Army tool and uh I love reversing
51.11s - 56.75s |  stuff as well on embedded systems. And this is Roman, the maintainer of Mirage, another
56.75s - 62.75s |  BLE Swiss Army tool but not only BLE does ZigBee and some other protocol as well. And uh he
62.75s - 67.23s |  loves cross pro- cross protocol attacks and we are going to talk a bit uh about this later in
67.23s - 72.23s |  the talk. So what is what and why we had to create this uh framework? So basically wireless
76.27s - 81.33s |  tools are a mess. A lot of researchers did a lot of research on wireless protocols and they
81.33s - 86.35s |  create a lot of tools. Different tools with different protocols and different devices and
86.35s - 91.65s |  different firmwares. Uh each firmware communicates with a host or a computer with a- a
91.65s - 97.19s |  specific protocol designed by uh each person. And basically everyone reverses the wheel
97.19s - 102.19s |  because why not? And if you are into, yep, if you are into wireless protocol hacking, you may
105.33s - 110.71s |  have to use a lot of different tools. So for BLE the classic tools B-T-E-L-E-J-A-C-K,
111.03s - 118.15s |  Mirage, uh Gattacurl, SniffID, uh are the best way to to capture information and test some
118.15s - 123.15s |  devices. And in the end you end up with a lot of devices. So if you want to be able to tackle
125.59s - 132.09s |  with all these protocols, you need to buy at least all of these. And the problem is um that it
132.09s - 138.03s |  takes a lot of space. It costs a lot uh as well. And most of this hardware uh can be
138.05s - 144.05s |  discontinued at any time. So if you want to to hack some wireless protocol, there is this tiny
144.05s - 149.73s |  hardware you didn't buy 2 years ago. And it's the only hardware that is supported for hacking
149.73s - 155.17s |  this specific protocol. So that's uh that's a shame. And basically this is just a waste of
155.17s - 159.97s |  time. And because uh you need to create a different uh each researcher create different
159.97s - 166.31s |  firmware and uh um each researcher or each person hacking, trying to hack a wireless
166.33s - 171.63s |  protocol, uh is going to face the same issues other people have already had before and uh with the
171.63s - 177.51s |  same solution as well. And uh all of this in fact creates fragmentation. And uh this is uh this is
177.51s - 188.07s |  not good for us uh this kind of fragmentation. So we uh talked a lot together and uh we try to find
191.35s - 197.35s |  a solution to solve this fragmentation issue. So uh it leads us to uh come with a solution to
199.03s - 207.03s |  three main ideas. So uh the first one uh would be to design uh communication protocol for the
208.83s - 215.33s |  communication between the host and uh the hardware that would be extensible. And either it is that
215.33s - 220.91s |  would support multiple wireless protocols, multiple physical layers uh at the same time. And of
220.93s - 228.93s |  course uh that could be open source and easy to extend. Uh the second uh big idea uh would be to
230.67s - 238.67s |  create a set of libraries, a framework, and basically a wall ecosystem uh that will allow uh some
239.51s - 247.51s |  reuse of uh various ready to use features for different hardware, different platforms. And that
247.55s - 255.55s |  be available both for the host and the firmware. And uh the third main uh idea we came with is uh that
258.47s - 266.47s |  for uh these two works uh it must uh from the beginning encourage the interoperability and the
266.47s - 274.47s |  collaboration between researchers. So uh it motivated us to build everything as open source software
274.55s - 282.55s |  to uh easily document both the use of the tools but also uh its design. So uh here comes the main uh
288.09s - 296.09s |  part uh of WAD for this project which is the WAD protocol. So we have several guidelines that have
296.67s - 302.67s |  motivated uh its development. So first uh it's a standardized protocol so we properly define the
304.71s - 312.71s |  it. Everything uh is uh documented and explained. It's uh generic so it covers uh a set of wireless
313.59s - 321.59s |  capabilities that are uh already uh in the ecosystem. It's modular so you can support multiple uh
322.25s - 329.53s |  wireless protocols. Uh and uh if you want to add more and put your own, it's a protocol which is
329.57s - 337.57s |  evolutive. So the protocol has been designed to be easily extended and improved over time. And finally
337.57s - 346.55s |  uh we also tried to make it as user friendly as possible. So uh we developed a set of C, C++, and
346.55s - 354.55s |  Python parsing libraries uh allowing to facilitate uh its integration into uh your firmware uh and so on.
355.35s - 366.35s |  So another uh key uh idea behind WAD is uh to offload most of the complexity from the firmware side to
366.35s - 374.37s |  the uh outside. So of course on the firmware side we have some CPU uh some memory limitations. And so
374.37s - 384.37s |  the idea was uh to keep only uh what is uh needed. So some atomic uh wireless primitives uh as basic as
384.43s - 391.43s |  possible. Uh and of course the operations that are time critical and that could not be offloaded to the
391.43s - 397.91s |  host. So for example the channel opening, this kind of stuff. So we keep uh a minimal logic in the
397.91s - 404.89s |  firmware and all the attack, the protocol stacks, the packet detectors and so on are implemented on the
404.89s - 415.89s |  host. So finally uh WAD has been designed uh not only uh for hackers even if we are in a hacker
415.89s - 423.89s |  conference. But uh also for uh everyone. So if you are a security researcher uh you can use it. If you are
423.89s - 431.91s |  just a wireless uh enthusiast and you want to control uh your IoT devices. Uh or if you are just uh a
432.03s - 442.20s |  curious user and you want to understand how uh your favorite wireless toy uh works.
442.20s - 448.84s |  Alright so uh what is WAD in fact? Uh Romain introduced the main concepts behind this uh this
448.84s - 454.82s |  framework. But in fact uh technically uh first the name. Because you know when you start a project you
454.82s - 461.06s |  get you got to find a name. And it's always a pain in the ass to find something yeah meaningful. Uh so
461.10s - 466.44s |  WAD stands originally for Wireless Hacking Devices because it was uh supposed to support a lot of
466.44s - 473.32s |  wireless uh uh so a lot of devices to hack into wireless protocols. And after having used this
473.32s - 480.72s |  project uh during more than a year uh yeah wireless hacking for them is also a great name because it's
480.72s - 487.42s |  uh makes things easier. And we are going to show that in multiple demos. Uh like Romain said it's
487.42s - 492.14s |  more than a protocol uh because designing a protocol a communication protocol between a host and a
492.14s - 498.50s |  device that's a thing. And this is something uh we we already did uh two of us uh for our respective
498.50s - 505.64s |  tools. But in fact providing uh uh an ecosystem with uh the protocol all libraries in Python and in C
505.64s - 511.92s |  and C++ that you can embed in your firmware and use to communicate with the host without having uh you
511.92s - 519.30s |  know uh without worrying about how the data is encoded and so on. This is uh this is a lifesaver. Uh
519.30s - 526.34s |  you when you develop a firmware compatible with this uh ecosystem you the only thing you need to worry
526.34s - 533.64s |  about is the specific code that runs and that handles all the radio frequency stuff. And uh also we
533.64s - 540.42s |  provide a lot of tools uh command line interface tools and uh maybe some are more evolved and provide
540.42s - 546.50s |  more features. But if you want to create all your own applications based on a web on this ecosystem you
546.50s - 553.64s |  can do as do it as well. And you can just use the Python client library and use it uh yeah. It's very
553.64s - 559.94s |  simple to to develop something. From the protocol perspective it's based on protocol buffers. So yeah
559.94s - 567.52s |  no surprise here. And um the protocol has been thought uh in a way that the uh host can query the
567.52s - 574.90s |  device uh about what uh the devices or capabilities are. And so basically the each device compatible
574.90s - 581.44s |  device can announce itself to the uh what ecosystem and especially to the host. Telling okay I I
581.44s - 587.58s |  support this protocol uh I can do this with this protocol packet injection or just sniffing scanning
587.58s - 596.16s |  anything. And the host adapts uh the the tools based on the uh capabilities announced by the device. And
596.16s - 601.64s |  this is a discovery protocol that has been included in WAD. And this one is mandatory for any device. Uh you
601.64s - 610.48s |  can have uh uh some hardware on the ZigBee protocol and the BLE or or even just modulation modulation
610.48s - 616.68s |  and demodulation as well. Uh but in fact you can have some you can have multiple protocols supported by a
616.68s - 625.12s |  single device with using this uh this system. Um we created a lot of firmware uh a lot of firmware. We
625.12s - 631.46s |  actually we support uh if you have a look at the top uh top half of the screen. We support basically
631.46s - 639.90s |  and natively four devices. Um some of them are based on Nordic Semiconductor NRF52 uh system and
639.90s - 649.72s |  chips. Uh so basically the there is the ESP32WROOM from Espressif. The Nucleo WL55 which is uh uh
649.72s - 658.36s |  LoRa and the Sigfox uh transceiver from STMicro uh that's supported. And uh also yeah I told you about the NRF52.
658.36s - 665.66s |  But the most interesting part is that we uh managed to create some uh adaptation layer between WAD and the old
665.66s - 673.48s |  tools such as the uh Yardstick one or the Herbatools. And in fact we we we can use all these old devices if you
673.48s - 680.44s |  can say with WAD. And this is totally transparent for you. So it's uh just it appears like a classic WAD tool or WAD
680.44s - 689.67s |  device and you can use it to do whatever you want. The WAD protocol supports a lot of uh modulations uh file
689.67s - 697.35s |  layers and other protocols. So basically this is the FSK, GFSK, MSK modulation on the physical layer. Uh so you can
697.35s - 703.69s |  do demodulate and modulate signals using your specific device. And uh obviously the BLE protocol ZigBee and so on
703.69s - 712.55s |  are also supported. Uh based on some previous research we made, Romain and I, we also added into WAD the result of
712.55s - 721.03s |  this research. So Romain published in uh 2021 uh the Wasabi uh attack. So basically this is an attack on uh or not an
721.03s - 731.27s |  attack. This is uh just a uh a way to divert the uh radio transceiver from an NRF52 uh system and chip to to make it
731.29s - 741.99s |  able to sniff and uh inject ZigBee packets. And uh last year we presented also uh some uh research at WOOD uh um which is
741.99s - 751.27s |  basically how to turn an ESP32 into a uh a device uh that can sniff and inject raw PDUs in Bluetooth no NRG uh
751.27s - 758.17s |  communication. So yeah this uh this is also supported in the firmware and uh in the WAD protocol. Not not WAD protocol but WAD
758.17s - 766.45s |  ecosystem. Uh if you want to add new protocols to this uh like Romain said it's uh extensible. So you can uh just modify the
766.45s - 774.83s |  protocol and add what you need to to implement it. All the uh uh all the translation between these messages and so on is
774.83s - 780.03s |  performed by the framework. And uh the protocol is version as well. So it is backward compatible. If you have a device with
780.03s - 788.01s |  version 1, protocol version 1, it will be supported uh as well as a protocol device with a protocol version 2 and so on. And
788.01s - 798.31s |  uh obviously we hope that uh many hackers may want to contribute to to WAD and add new protocols we didn't think about because we
798.31s - 809.93s |  maybe don't know this protocol or so on. Um we also designed our own flexible stack model. So speaking of wireless protocol,
810.33s - 819.97s |  we provide a specific flexible stack model sorry uh that is easy to modify. So basically take a BLE stack. You can just swap a
819.97s - 827.81s |  specific layer and replace it with your one with your own. You can develop your own stack layer and replace it in a in the stack. So
827.81s - 835.99s |  basically you can implement some very specific behavior if you want to test some uh unexpected uh behavior. This is a way to to do. Uh
835.99s - 843.19s |  there is a complete stack snapshot that is implemented from scratch uh in the in this model. So for it, every protocol supported,
843.19s - 851.63s |  every protocol stack we got in WAD, you can do at any time a snapshot of the old stack. Uh save this snapshot on the on your disk and
851.63s - 859.21s |  reload this snapshot later if you want to test uh something on this uh this framework. And also this uh all uh flexible stack
859.21s - 868.91s |  model uh makes uh writing unique tests very easy because you can just isolate a layer. Send inputs and check what outputs uh came and
868.91s - 879.75s |  if it's uh what you are expected from this layer. And um in WAD actually we provide uh multiple protocol stack. Uh BLE for version 4,
879.97s - 889.45s |  version 5 is on its way. Uh Logitech Unifying, uh NShock Burst from Nordic, Zigbee, RF um RFOC and lower one. So all these stacks have
889.45s - 897.13s |  been uh implemented from scratch and are flexible in a way that you can make the stack behave the way it's not really expected by the
897.13s - 905.63s |  specifications. So this uh allows uh security research uh if you want to try uh unexpected ways to to go through the stack. And uh if you
905.81s - 913.59s |  just want to use the protocol as well you can just use them and it works as expected. So this is uh this is why Romain said it was made for uh
913.59s - 923.97s |  secure cyber security specialists, researchers and also uh just uh enthusiast, wireless protocol enthusiast or just user. Um and uh uh we also
923.97s - 933.51s |  love KISS uh not the uh rug band uh obviously but the keep it simple stupid uh principle. And WAD provides a set of simple common tools and um
933.51s - 942.87s |  a mean to combine them uh to combine all these tools into uh in order to create more complex tools. Uh and we also provide some
942.87s - 950.01s |  full feature tools for those who want to just to experiment with uh a protocol. And um yeah if you are a newcomer in wireless protocol
950.01s - 959.27s |  expectation or or just if you want to play with some protocol you we got you covered. Uh just to give you an idea of what's going on with WAD
959.27s - 968.33s |  and this uh KISS principle. Um I don't know if it's really readable in the screen but uh basically we are using uh a first program called WBD
968.33s - 977.67s |  Connect to initiate a BLE connection onto a device. Then there is a pipe with the WShark which is a uh wrapper for Wireshark. And then another
977.67s - 987.65s |  pipe with WBD central profile and basically what this command does is just tells WAD to first initiate a connection to a device. Then to ask uh the
988.13s - 997.27s |  the device it's a BLE services and characteristics or just basically an enumeration performed by the uh WBD central. And every packet sent between
997.27s - 1008.41s |  the connection and the uh central which is a GATT client is monitored by Wireshark in real time. And you can compose all the tools this way. You
1008.41s - 1019.75s |  create a processing packet chain uh yeah that's it. Maybe I get it wrong. But um you create a chain of packet processing and you can do whatever you
1019.75s - 1029.43s |  want. We are going to show you some other tool we developed and it allows very some yeah some a lot of flexibility you know in the what can be
1029.43s - 1038.67s |  done with this uh this uh the things. And obviously we also created in the framework a lot of uh um wrappers for creating a command line
1038.67s - 1047.91s |  application. So if you need to create some command line tools or do your own tools you got everything you need to um wrap the connection to the
1047.91s - 1061.95s |  hardware and so on. Yep. The clicker. Yeah. So uh I'm going to start with the first demo. This is uh we got uh 13 demos to show you what WAD is
1061.95s - 1074.43s |  capable of. Uh so the first one is the BLE exploring demo. So basically we are I'm going to show you the WBD central tool. So this is basically uh a
1074.49s - 1083.77s |  GATT client and uh and what I'm going to do here is to scan devices, connect to the device, a specific device, innovate services, BLE services and
1083.77s - 1102.11s |  characteristics and write and write some data from this. So I guess nope. Okay so the setup is just should be this one. So basically we launch a scan
1102.11s - 1112.91s |  using WBD central. We are using uh an HCI adapter for BLE. We can get all the information, all the advertising records sent by the um the device.
1112.91s - 1121.65s |  Once you found your your device or target device you can connect to it through the connect command. So this is an interactive shell provided by WBD central.
1121.65s - 1131.43s |  Then the connection is made and we uh launch a profile command to start enumerating services and characteristics. We can find uh we have found a device
1131.43s - 1140.09s |  name characteristic uh and a manufacturer name characteristics in two different services and we are going to read the content of this characteristics using
1140.09s - 1149.81s |  the read command and we get everything and uh we can also write into characteristics and subscribe for notification. The basics a GATT client can do.
1149.81s - 1175.39s |  Oh this is for the next demo. So basically this is just an example of a full feature tool uh in WAD and this is a very basic one.
1175.39s - 1193.39s |  So uh second uh full feature tool we developed uh is a tool named uh ZigBee and device uh that will allow to interact with uh ZigBee networks uh and uh emulate basically ZigBee and device.
1193.39s - 1204.89s |  So thanks to this tool you will be able to detect uh the surrounding ZigBee networks uh to join a specific network uh perform all the cryptographic operation this kind of stuff
1204.89s - 1216.97s |  and get the network key uh associated with the network enumerate the devices on the network and interact uh with the various ZigBee devices.
1216.97s - 1228.67s |  So uh here you have a small demo showing a small ZigBee network um on the camera and you have an example of the use of this tool.
1228.67s - 1244.49s |  So first we perform a scan operation to discover the surrounding networks. So it takes some time but uh finally uh we can see that we have one uh ZigBee network.
1244.49s - 1263.11s |  So let's join uh this network and perform the association procedure so we are able to see the network key and now we are associated and we can uh interact and discover the nodes in the networks and the endpoints for every nodes.
1263.11s - 1312.78s |  So then uh we have a list of clusters that allows us to uh interact with uh the nodes and we can use the cluster command to toggle uh a light bulb for example uh toggle it off and so on.
1312.78s - 1342.76s |  So sorry uh we are also uh another tool named the Wadsniff which is a generic tool so it's a multi-protocol sniffing tool uh so Wadsniff uh works with all uh the protocols that are supported uh by WAD so ZigBee, BLE, RFC you can even uh directly sniff uh PHY uh so uh physical layer um configured as you want.
1342.84s - 1365.94s |  Uh it provides different uh output formats so you can directly display the SCAPI packets uh with the different fields uh correctly dissected uh or directly a next dump uh version of the packet uh and it allows to uh monitor the traffic and do value stuff like exporting data to a PCAP uh monitoring uh with Wireshark.
1366.54s - 1387.62s |  So here you have uh some uh basic uh use cases of uh Wadsniff so here we are going uh to uh display uh some BLE advertisements so here you can see the SCAPI uh representation.
1388.62s - 1395.62s |  Then we can switch the format to Xdump and so here we have the Xdump version of our packets.
1396.62s - 1412.90s |  We can uh also uh collect these uh packets using uh directly the physical uh layer of Bluetooth energy so we provide the modulation, Gaussian frequency shift gain, then the deviation.
1415.25s - 1433.25s |  Uh we provide the frequency uh and uh finally the size uh of the packets and here we get a raw dump uh straight out the demodulator output so uh it can be useful for specific analysis.
1433.25s - 1458.38s |  And uh finally we can also uh for with this Wadsniff tool uh directly export the traffic to a PCAP for further analysis so here all the traffic is simultaneously displayed on the screen and exported to a PCAP.
1476.79s - 1484.79s |  So an interesting uh feature of WAD is that you can combine uh several tools uh with pipes.
1485.79s - 1498.79s |  So Wadsniff can be trained with uh several tools so for example you can use WADfilter that may allow to apply some filtering uh on the received packets.
1498.79s - 1518.79s |  Uh you can transform uh the packets on the fly uh if it matches a specific filter or uh you can also use some tools like WADextract uh that may allow to extract uh a specific uh field uh from the packets.
1519.79s - 1522.79s |  So let's go uh for an example of that.
1522.79s - 1539.79s |  So here it's uh the same example with Wadsniff and uh we are going to pipe uh Wadsniff with uh WADfilter and in WADfilter we are going to provide a filter to keep only a specific kind of other types of packets.
1539.79s - 1549.79s |  And finally if we want uh to extract a specific field we can use uh WADextract.
1550.79s - 1560.79s |  We provide the field we want to extract so here is the BG address and we also export a part of the metadata so the RSSI.
1561.79s - 1568.79s |  And of course you can then grab this output and provide it uh to classical Unix tool.
1569.79s - 1581.79s |  So uh Wadsniff uh has a lot of uh usage and it may even allow to perform uh some complex uh attacks.
1582.79s - 1591.79s |  So typically uh in this demo we are going to attack an RF4C communication between a remote uh controller and a set-top box.
1591.79s - 1598.79s |  So uh typically RF4C is a lightweight variant uh of ZigBee for remote controller.
1599.79s - 1605.79s |  So here you have a set-top uh with the remote controller on one side and Wadsniff on the other side.
1606.79s - 1618.79s |  So here we are performing a pairing with the remote controller and uh Wadsniff has been configured to automatically perform a brute force uh attack.
1619.79s - 1632.79s |  And so in the input you can notice that the key uh has been uh automatically uh derived and extracted from the communication.
1633.79s - 1640.79s |  And the packet which is uh normally encrypted can be decrypted uh on the fly.
1640.79s - 1648.79s |  So it allows to sniff the various buttons that are pressed on the remote control.
1649.79s - 1665.55s |  And it uh can also sniff the audio stream which can be transmitted uh using the mic of the remote controller.
1666.55s - 1683.96s |  And uh we can even export uh the voice command to a bad WAV file but yeah it's working.
1689.82s - 1693.82s |  So uh next demonstration is about uh using Wireshark to sniff uh some traffic.
1694.82s - 1700.82s |  So basically uh we showed this uh a bit earlier but uh we are going to go a bit deeper in this demo.
1701.82s - 1703.82s |  So uh you can monitor everything with WShark.
1704.82s - 1717.82s |  So this example is about BLE but it could be ZigBee or even your if you are trying to demodulate packets through the file layer you can get it in Wireshark in real time and you can monitor everything you are working on.
1718.82s - 1725.82s |  If you use WFilter to modify your packet on the fly you can see the result in real time with the WShark.
1726.82s - 1728.82s |  So uh the demo is the following.
1729.82s - 1731.82s |  I'm going to be very quick about this one.
1732.82s - 1743.82s |  Yeah so basically we are again connecting to a device and so on and performing uh um uh services and characteristics in emulation.
1744.82s - 1752.82s |  And everything uh can be monitored uh in Wireshark while the terminal shows you the results of this uh of this operation.
1752.82s - 1756.82s |  So this is basically uh what WShark can do.
1757.82s - 1763.82s |  And the most interesting thing is that uh we talked about uh Gatacore and BTLEJuice at the beginning of the talk.
1764.82s - 1772.82s |  So basically these tools are based on not on some Node.js uh library uh which are not no more maintained at the moment.
1773.82s - 1780.82s |  So if you want to perform a man-in-the-middle attack on BLE with WAD this is very simple.
1780.82s - 1788.82s |  Because you can combine tools you can create for instance if you want to you know set up a man-in-the-middle attack on a device uh like Gatacore.
1789.82s - 1798.82s |  You uh just create a command line starting with WBAD-spawn that will spawn a device with uh corresponding parameters that will mimic the target device.
1799.82s - 1806.82s |  And then you can pipe all the packets that will go uh from the this uh fake device or spoof device into Wireshark.
1807.82s - 1814.82s |  You can so you can monitor in real time what's going on and then uh once the smartphone for instance is uh is connected onto the spoof device.
1815.82s - 1819.82s |  Uh then you are going to initiate a connection into the target device.
1820.82s - 1829.82s |  And every packet sent by the smartphone uh or the target or the target device will be uh just forwarded as uh uh as it goes.
1830.82s - 1831.82s |  And you can monitor everything in WShark.
1832.82s - 1834.82s |  So this is uh the next demo I'm going to show you.
1834.82s - 1848.82s |  Uh here so we are setting up uh Gatacore like man-in-the-middle attack using uh WAD using simple tools again WBAD-spawn this is very small tool like WBAD-connect.
1849.82s - 1858.82s |  And uh we first the system is going to spawn a spoof device that just advertise itself like the target device.
1859.82s - 1862.82s |  And the smartphone uh here is going to detect this device.
1862.82s - 1871.82s |  When we initiate the connect when we push the connect button on the on the smartphone then the connection to the our spoof device is uh initiated.
1872.82s - 1874.82s |  We can see on Wireshark what's going on with the BLE PDUs.
1875.82s - 1884.82s |  And if you really try to read the characteristics for instance then all the PDUs are directly forwarded to the target device and back and forth and we can monitor everything.
1885.82s - 1886.82s |  With Wireshark you can see what's going on.
1886.82s - 1887.82s |  You can save it as a pick up.
1888.82s - 1898.82s |  And what we do here with Wireshark you can do it with any other generic tool we develop such as WFilter or WX not WX type WFilter.
1899.82s - 1904.82s |  And you can if you want make some changes into the packets using some specific filters.
1905.82s - 1912.82s |  If you want to modify the answer uh the um response uh from a read operation on the characteristics you can do it on the fly.
1912.82s - 1917.82s |  And you can also monitor what's going on because you can pipe WFilter with WShark as well.
1918.82s - 1923.82s |  So this this is powerful even if this demo is not uh really powerful but yeah.
1924.82s - 1925.82s |  Anyway.
1926.82s - 1931.82s |  And if you want to emulate a BLE peripheral you can you can use uh the full feature of WBLE peripheral.
1932.82s - 1933.82s |  Uh so basically it goes like this.
1934.82s - 1941.82s |  This is a command line tool you can use to just uh spawn a BLE device and populate the device with whatever you want.
1942.82s - 1946.82s |  So basically you can change the name of the device and say that I'm going to create a device called Defcon32.
1947.82s - 1950.82s |  Uh add a service and a characteristic to the device.
1951.82s - 1955.82s |  Um I'm going to write the value of this characteristic as well.
1956.82s - 1957.82s |  It should be Defcon32 I guess.
1957.82s - 1962.82s |  And then uh I'm going to start the device on the uh right hand side of the screen.
1963.82s - 1965.82s |  You got the uh screen of the smartphone.
1966.82s - 1970.82s |  So let's start this uh spoof device or emulated device to be more precise.
1971.82s - 1973.82s |  Uh yeah come on.
1974.82s - 1980.82s |  Okay so it will pop on uh the um smartphone and we can connect to it.
1981.82s - 1985.82s |  Um it will start the discovery process of services and characteristics.
1985.82s - 1988.82s |  There is a single service with a single characteristic.
1989.82s - 1991.82s |  And we can read the content.
1992.82s - 1997.82s |  Each time we read from the smartphone the content of this characteristic this is caught by the BLE PRF uh tool.
1998.82s - 2004.82s |  And uh if uh the smartphone subscribe to notification then it got notified by the uh the system and so on.
2005.82s - 2011.82s |  So this is a good way to play with uh uh applications and BLE applications to mimic some device.
2011.82s - 2017.82s |  If you want to see what happens when you are modifying some uh some properties of this uh of this device.
2018.82s - 2029.82s |  Uh in practical situation this is not what we are going to use because it's uh you know just a uh interesting way we want to play with uh a device.
2030.82s - 2032.82s |  But uh a more interesting use is the following.
2033.82s - 2038.82s |  Uh if you want to implement a very specific device with specific services and characteristic with a specific behavior for the characteristics.
2039.82s - 2040.82s |  Here a small example.
2041.82s - 2044.82s |  We are going to create a battery device exposing your battery service with a battery level.
2045.82s - 2050.82s |  Except that each time we are going to read the battery level we will decrease the level by 10%.
2051.82s - 2055.82s |  And goes like this when you emulate this uh peripheral.
2056.82s - 2061.82s |  So basically uh we start the Python script that uh instruments everything.
2062.82s - 2063.82s |  The device appears on the screen.
2063.82s - 2064.82s |  So there is a battery device.
2065.82s - 2070.82s |  When the discovery goes with the services and characteristic we get one service with one battery level characteristics.
2071.82s - 2078.82s |  And each time I read the characteristic value getting the percentage of uh battery level percentage then it is decreased.
2079.82s - 2081.82s |  So this is just 10 lines of Python to do this.
2082.82s - 2091.06s |  And uh we did the same with other protocols because we are talking a lot about BLE.
2092.06s - 2094.06s |  Uh we got a LoRaWAN gateway implemented in WAD.
2094.06s - 2103.06s |  So if you want to create a LoRaWAN network and get some device uh to associate with this uh with this um fake network.
2104.06s - 2105.06s |  You can do it and it works pretty well.
2106.06s - 2108.06s |  Uh I guess the demo will be a nightmare on the screens.
2109.06s - 2110.06s |  So I will skip it.
2111.06s - 2116.06s |  Um but the media server of DEF CON has this demo.
2117.06s - 2118.06s |  So if you want to have a look at it.
2119.06s - 2120.06s |  Uh please do.
2121.06s - 2122.06s |  But uh I am going to still skip this one.
2122.06s - 2124.06s |  Uh and let Romain explain the rest.
2125.06s - 2126.06s |  Yeah.
2127.06s - 2138.06s |  So uh another uh example of what you can do uh with uh WAD is uh the emulation of various uh devices.
2139.06s - 2143.06s |  And for example uh you can take a proprietary protocol like Logitech Unifying.
2144.06s - 2146.06s |  And you have a protocol stack which is implemented.
2146.06s - 2156.06s |  And various tools that will allow to uh perform uh keyboard emulation, mouse emulation uh for Logitech Unifying devices.
2157.06s - 2164.06s |  So typically here we are going to use it to perform a scan operation of surrounding Unifying devices.
2165.06s - 2169.06s |  Uh spoof uh the address of uh mouse.
2170.06s - 2180.06s |  And then we are going to emulate the keyboard with this address to reproduce a vulnerability uh from mouse jack to inject an encrypted keystrokes to the computer.
2181.06s - 2191.20s |  So here we start by uh using a small command line tool to perform a scan operation.
2192.20s - 2195.20s |  It allows us to get the address of a mouse.
2195.20s - 2203.20s |  And we provide it uh in uh as argument of a Python script that will perform the injection.
2204.20s - 2210.20s |  And as you can see uh we have a keystroke injection uh performed and fully emulated by WAD.
2211.20s - 2214.73s |  Yeah.
2214.73s - 2215.73s |  So you can see hello Defcon.
2216.73s - 2217.73s |  Sorry.
2220.73s - 2228.77s |  So uh we can uh emulate uh Logitech Unifying keyboard.
2228.77s - 2232.77s |  We can also emulate a Logitech Unifying uh dongle.
2233.77s - 2241.77s |  Uh and uh on the other side on BLE we are able to emulate a peripheral.
2242.77s - 2253.77s |  So here comes uh very useless idea which is to uh create a bridge uh which is cross protocol between uh Logitech Unifying uh keyboard for example.
2254.77s - 2260.77s |  And a smartphone uh that will be connected to an emulated uh BLE keyboard.
2261.77s - 2263.77s |  So uh we have a small script.
2264.77s - 2266.77s |  You can see the screen uh of the smartphone.
2267.77s - 2274.77s |  And uh you can see uh a video with the keyboard uh at the bottom.
2275.77s - 2278.77s |  So first we connect uh we emulate the BLE keyboard.
2279.77s - 2284.77s |  We connect and pair the smartphone uh with this uh emulated BLE keyboard.
2285.77s - 2294.38s |  And once the pairing uh is uh successful.
2295.38s - 2309.38s |  Now we can just press some key on the Logitech Unifying keyboard and it will be forwarded uh through the uh BLE emulated keyboard to the smartphone.
2310.38s - 2311.38s |  So yeah.
2312.38s - 2314.38s |  Completely useless but funny.
2314.38s - 2333.85s |  And finally our last demo uh is uh uh based on the idea that it's uh cool that what allow to uh access various hardware uh perform uh different operations.
2334.85s - 2339.85s |  Uh but it would be even cooler if you could access it over internet.
2339.85s - 2347.85s |  So uh we wrote a what server that will allow you to expose a what device uh over TCP.
2348.85s - 2359.85s |  And so uh with any tool, any script, you will be able to connect uh to this what uh TCP server uh like if it was a local device.
2360.85s - 2366.85s |  And uh for example it can be useful to build relay attacks and that kind of stuff.
2366.85s - 2375.85s |  So uh in this next demo, so we are in two different uh cities in France.
2376.85s - 2383.85s |  And I'm exposing uh my uh Bluetooth dongle uh using what server.
2384.85s - 2392.85s |  Damien will use uh BLE central to connect to uh this uh remote devices.
2392.85s - 2396.85s |  And he's able to connect to the light bulb next to me.
2397.85s - 2400.85s |  Perform a profile uh discovery.
2401.85s - 2416.92s |  And uh now he will be able to uh turn the light bulb on, turn the light bulb off, and modify uh the color.
2417.92s - 2423.92s |  So typically uh it's interesting uh for building relay attacks.
2424.92s - 2428.92s |  It can be interesting in uh various experiment uh setups.
2429.92s - 2430.92s |  So Sky is the limit here.
2431.92s - 2437.92s |  Yeah uh and the interesting part here is yeah again we show it with BLE but it can be done with any protocol as well.
2437.92s - 2445.92s |  You can uh accept the Logitech unifying because you have some keep-alives that are messed up with the network.
2446.92s - 2450.92s |  But in fact you can once you are connected to a device you can just discover everything.
2451.92s - 2456.92s |  And yeah just like uh it's the same if you connect the device on your computer.
2457.92s - 2460.92s |  So basically it opens a wide range of possibility.
2461.92s - 2473.92s |  So uh we are developing this project uh since uh a few years now.
2474.92s - 2483.92s |  And uh it has been used uh internally uh so in Damien's company uh and uh in my research lab.
2483.92s - 2495.92s |  So for example uh one uh intern uh at Quark's lab uh Batiboye uh developed uh BLE GAT fuzzer uh using uh WAD.
2496.92s - 2504.92s |  That leads to a CV uh linked to the expressive controller uh expressive uh BLE stack sorry.
2504.92s - 2514.92s |  Uh and uh we also uh used it in a research project uh to evaluate the screaming channel attacks.
2515.92s - 2522.92s |  So we told us to uh instrument uh the BLE protocol uh with uh custom uh link layer traffic.
2523.92s - 2530.92s |  Uh it's also a project which is uh already uh easily used in uh some other LCTF.
2530.92s - 2535.92s |  So for example uh this year uh edition of other I.O.
2536.92s - 2540.92s |  Uh all the BLE challenges were fully emulated uh with WAD.
2541.92s - 2547.92s |  And WAD has also been used in a lower one challenge to emulate a lower one gateway.
2548.92s - 2557.92s |  So to conclude this talk uh we uh are releasing today uh publicly uh this project.
2557.92s - 2560.92s |  So uh it's available uh on pip.
2561.92s - 2564.92s |  The documentation is available uh on read.docs.
2565.92s - 2571.92s |  So we are going to improve uh the documentation and the project over time.
2572.92s - 2574.92s |  Uh feel free to contribute to it.
2575.92s - 2583.92s |  We have also uh the firmware files that are available uh on GitHub in uh some sub repositories.
2583.92s - 2589.92s |  And globally all the code uh is available uh on GitHub under MIT license.
2590.92s - 2598.92s |  So uh of course uh we are we also uh are making a call for contributors.
2599.92s - 2606.92s |  So uh feel free to uh create compatible firmwares for uh your preferred hardware.
2607.92s - 2611.92s |  To report any bugs, any issues you would encounter uh on GitHub.
2611.92s - 2617.92s |  And if you want to help uh us by writing some documentation,
2618.92s - 2621.92s |  by adding support for other protocols or other devices,
2622.92s - 2624.92s |  uh we would be uh happy to have contributors.
2625.92s - 2629.92s |  And if you like it uh spread the word and tell your friends.
2630.92s - 2632.92s |  So uh two last words.
2633.92s - 2637.92s |  So this is uh a work we initiated two years ago.
2637.92s - 2641.92s |  Uh and uh here it was a very high level uh presentation.
2642.92s - 2646.92s |  Uh so we only scratched the surface of what WAD is capable uh of.
2647.92s - 2651.92s |  And uh we also want to uh warmly thank uh the many researchers
2652.92s - 2655.92s |  that have uh better access uh to this project.
2656.92s - 2661.92s |  And that uh helped us and provided some feedback uh on it.
2662.92s - 2664.92s |  So I won't name them all but uh they know.
2665.92s - 2666.92s |  Thank you very much.
2667.92s - 2670.92s |  Uh and uh sorry for the small technical issues.
2671.92s - 2673.92s |  We are ready if you have any question.


url: https://www.youtube.com/watch?v=I1RqhGGRmHY
title: DEF CON 32 - Your AI Assistant has a Big Mouth: A New Side Channel Attack - Yisroel Mirsky
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=I1RqhGGRmHY",
  "title": "DEF CON 32 - Your AI Assistant has a Big Mouth:  A New Side Channel Attack - Yisroel Mirsky",
  "description": "AI assistants like ChatGPT are changing how we interact with technology. But what if someone could read your confidential chats? Imagine awkwardly asking your AI about a strange rash, or to edit an email, only to have that conversation exposed to someone on the net. In this talk we'll unveil a novel side-channel vulnerability in popular AI assistants and demonstrate how it can be used to read encrypted messages sent from AI Assistants.\n\nBefore our disclosure, major players like OpenAI, Microsoft, Cloudflare, Quora, and Notion were at risk. We'll reveal the technical details of this exploit and show real-world examples of intercepted conversations. This talk isn't just about the problem \u2013 learn how to identify this vulnerability in other AI assistants as well! We'll dissect network traffic, discuss attack models, and explore the far-reaching consequences of this discovery.",
  "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
  "duration": 2398,
  "channel": "DEFCONConference",
  "uploader": "DEFCONConference",
  "upload_date": "20241016"
}

0.37s - 6.13s | This text was transcribed using whisper model: large-v2

 Hello DEF CON! Thank you so much for being here. It's like the second-to-last
6.13s - 10.93s |  talk. There's a great turnout. I'm very honored to be here. My name is Yusriel
10.93s - 16.05s |  Emerski. I'm a Zuckerman Faculty Scholar at Ben-Gurion University and head of the
16.05s - 21.09s |  Offensive AI Research Lab there. And with me here today are my brilliant graduate
21.09s - 24.57s |  students who will be coming up on stage also to present. They did all the hard
24.57s - 30.13s |  work. There's Daniel Eisenstein and Roy Weiss in collaboration with Guy Amit
30.13s - 36.53s |  who couldn't make it. Okay, so today we're going to talk about a new side-channel
36.53s - 41.61s |  attack against AI assistants that enables adversaries to read encrypted
41.61s - 50.65s |  response traffic, such as responses from chat GPT. Okay, so I'm not going to go
50.65s - 53.69s |  into, you know, what are AI assistants. You guys all know this very well. You have
53.69s - 59.05s |  OpenAI's chat GPT, you have Google's Gemini, you have Microsoft Copilot, and
59.05s - 63.89s |  the list goes on and on. And these AI assistants are integrated throughout
63.89s - 68.25s |  industry in all different kinds of use cases. What's more interesting to me is
68.25s - 73.65s |  the use cases of the personal level, right? A lot of users are using these AI
73.65s - 79.09s |  assistants, such as chat GPT, to get personal advice. So, for example, you may
79.09s - 83.45s |  ask it some medical questions, like, why do I have a rash on my back, right? And
83.45s - 86.93s |  chat GPT will get back to you and say, oh, I'm sorry to hear you have a
86.93s - 91.33s |  rash on your back. Let me give some tips how to take care of that. Or maybe
91.33s - 96.29s |  you may ask chat GPT for some relationship advice. What are the signs
96.29s - 102.21s |  I'm having, my wife is having an affair, right? And get some good tips on there. Or
102.21s - 105.29s |  maybe you're getting into hacking and you're gonna ask chat GPT how to get
105.29s - 110.29s |  into your neighbor's Wi-Fi, right? Lots of good use cases. Or my favorite, a lot of
110.29s - 115.25s |  people are using chat GPT to edit their documents. They'll take whole documents
115.25s - 120.17s |  or emails, dump it into chat GPT and say, hey, make it better. Or, you know, finish
120.17s - 124.13s |  this paragraph, or what have you. And these are all very good and legitimate
124.13s - 128.17s |  use cases. We're actually very productive for our society to help us, you know,
128.17s - 133.65s |  progress and automate things. But the problem is that what happens if these
133.65s - 138.41s |  chats aren't actually private? What happens if somebody could read these
138.45s - 144.17s |  chats beyond, for example, OpenAI? Right, so this would be a huge breach in
144.17s - 152.09s |  privacy. So, in truth, we know they're encrypted, right? So, you know, OpenAI is
152.09s - 157.05s |  encrypting all the traffic going between the client and the servers. But is that
157.05s - 162.49s |  enough? You know, maybe a little foreshadowing. So, let me go back to the
162.49s - 167.17s |  beginning of this story here. So, several months ago, you know, late at night, I was
167.17s - 172.17s |  using chat GPT for very important stuff, such as trying to figure out, you know,
172.17s - 177.01s |  what would the world be like if the entire, every country had ninjas, but
177.01s - 183.45s |  Japan had the worst ninjas, right? So, as I'm looking at the text glide across the
183.45s - 188.01s |  screen and looking at this very insightful and thoughtful response, it
188.01s - 194.25s |  kind of hits me. Wait a second. Could it possibly be that OpenAI is sending
194.29s - 200.25s |  every single word as a separate packet? And could it be that every single packet
200.25s - 208.01s |  has no padding, so I can count the number of characters in each of these words? Hmm.
208.01s - 213.45s |  So, I open up Wireshark, and sure enough, what do I see? For every single word
213.45s - 218.53s |  that's being sent from the AI assistant, I see another packet, and the size of
218.53s - 223.41s |  that packet increases. And if I take the Delta between these packets, I know
223.53s - 228.25s |  exactly how many characters in every single word. And I could use this, for
228.25s - 234.73s |  example, to try and guess what those words are and potentially learn or
234.73s - 241.05s |  identify what is being said in those responses. Now, before I go on to explain
241.05s - 244.21s |  how we figured out what those words are, I need to take a little bit of a
244.21s - 248.89s |  technical aside and clarify something. That what chat GPT and all these
248.89s - 253.05s |  different AI services are sending are not exactly words, but rather something
253.05s - 259.97s |  called tokens. What tokens are, are basically the basic building block of AI
259.97s - 265.29s |  language models. When you give text to a language model, it's going to first parse
265.29s - 269.69s |  it down into these tokens, and then each token goes to the model, and the model
269.69s - 275.69s |  generates text using these tokens as well. So, in general, these tokens more or less
275.69s - 279.97s |  correlate directly to words, but there are some cases where these tokens won't.
280.13s - 284.53s |  So, for example, here, Lama's tokenizer will split the word cream into two
284.53s - 290.61s |  separate tokens. But what's important to note is that although there's not a
290.61s - 295.41s |  direct correlation from token to word, these tokenizers are public information.
295.41s - 299.89s |  It doesn't matter if it's open AIs, if it's metas, you can go through the entire
299.89s - 304.25s |  list, you can get the tokenizer, you can learn the exact mappings. So, for all
304.25s - 307.65s |  intensive purposes, these are words, and we're trying to guess what these words
307.65s - 317.47s |  are. So, what's the threat model? So, the victim types some private chat into his
317.47s - 323.95s |  web browser, hits enter, and that encrypted text goes across the wire. Now,
323.95s - 326.27s |  we're not gonna be able to figure out what that prompt was, because that's just
326.27s - 331.27s |  one big block of encrypted text. But what happens after that is the AI assistant
331.27s - 336.59s |  starts responding token by token by token back, and we can count exactly how
336.59s - 339.71s |  many characters are in each of these tokens. And once again, if we can guess
339.71s - 346.15s |  what those words are, then boom, we know exactly what the response was. So, why do
346.15s - 349.99s |  we care? I mean, I can't figure out what the prompt was, I can't figure out what
349.99s - 356.79s |  the exact question was, but it turns out that a lot of information is
356.79s - 361.55s |  leaked by the response itself. So, imagine I read one of the responses off the
361.55s - 366.39s |  network that somebody was receiving, and it said, I'm sorry to hear that you have
366.39s - 371.23s |  a rash, right? I think it's pretty clear we know exactly what that user was
371.23s - 377.75s |  asking for. So, basically this boils down to a big Wheel of Fortune game, right,
377.75s - 382.63s |  where I have to start guessing what those words are. And this can be a
382.63s - 385.75s |  particularly challenging problem, because, you know, there's many different ways you
385.75s - 390.11s |  can solve this puzzle. But it gets even more challenging when you think about
390.11s - 394.19s |  real responses from these AI assistants, right? They're not just one sentence, they
394.19s - 398.39s |  typically hold paragraphs with hundreds of words. So, how do we solve this
398.39s - 404.31s |  problem? So, we turn to the age-old solution, which is AI, and we look towards
404.31s - 409.15s |  a task which is very popular, which is language translation, right? But here,
409.15s - 414.59s |  instead of going from a language such as French to English, we're gonna go from
414.59s - 420.83s |  token length sequences to plain text English. And what we'll do is we'll train
420.83s - 427.07s |  an AI with lots and lots of examples of these token lengths to real English, and
427.07s - 432.67s |  we'll be able to translate them very effectively. In our case, we used a
432.67s - 437.99s |  state-of-the-art model called a Large Language Model, or LLM, and this is the
437.99s - 443.23s |  exact same technology that's being used in AI assistants such as ChatGPT. I'm
443.23s - 446.63s |  not gonna go too much into detail how it works, leave that for other YouTube
446.63s - 450.91s |  videos. Alright, so what's the entire attack end-to-end? How does it look like?
450.91s - 454.03s |  So, the attacker is looking through the network, looking for responses from a
454.03s - 458.59s |  particular AI service such as ChatGPT, sees the traffic going across the
458.59s - 463.19s |  network, and records down the token length sequence from those packets. It
463.19s - 467.75s |  then passes that token length sequence to his trained model, which has seen lots
467.75s - 471.87s |  and lots of examples, and it predicts what it thinks the original plain text
471.87s - 478.91s |  was. So, there's something else we can do to make this even better. So, if we just,
478.91s - 484.11s |  you know, give our model random arbitrary text, it's gonna do so-so. It's not gonna
484.11s - 486.75s |  do so great, because as I said, you know, there's lots of ways we can solve that
486.75s - 492.39s |  puzzle. But as it turns out, AI assistants have a very specific style of speaking,
492.39s - 495.63s |  right? They're not just gonna respond with some arbitrary sentence, they
495.63s - 499.23s |  typically start with something like, oh sure, yeah, I can give you a recipe for
499.23s - 503.99s |  tomato soup, right? So, there's a certain style that's intrinsically in those
503.99s - 508.75s |  responses. So, what I can do is, if I'm, let's say I'm trying to target Microsoft
508.75s - 514.59s |  Copilot, I can send lots and lots of prompts to Microsoft Copilot and build a
514.59s - 520.11s |  huge data set of responses. And those responses capture the style of that
520.11s - 525.11s |  particular AI service. And once I have that, I can fine-tune my model on that,
525.11s - 530.07s |  I'll get much, much better results. And as it turns out, I can get something
530.07s - 535.15s |  around 55% attack success rate. So, more than half of the responses that we
535.15s - 540.87s |  receive, if we see in the encrypted traffic, we can decipher. Okay, so let's
540.87s - 545.63s |  look at some examples. So, on the screen here is the first sentences that we're
545.63s - 550.23s |  trying to decipher. The first line is the original text that is being sent from
550.27s - 555.39s |  the AI assistant. And the second line is our prediction. So, sometimes you can see
555.39s - 559.27s |  in the first example there, we get it right on the first go. And sometimes we
559.27s - 565.15s |  make some mistakes. So, for example, in the bottom there, the original response
565.15s - 570.03s |  was, yes, there are several important legal considerations that couples should
570.03s - 575.91s |  be aware of when considering a divorce. And then, if we look at the inferred
575.99s - 581.91s |  response, we got, yes, there are several potential legal considerations that
581.91s - 585.59s |  someone should be aware of when considering a divorce. So, even though we
585.59s - 590.19s |  had some mistakes in the words, we're still, it's very, very clear what was the
590.19s - 598.35s |  topic that the user was trying to ask the AI assistant. And then, if we move
598.35s - 603.11s |  over to entire paragraphs, we get something around a 35% attack success
603.11s - 608.07s |  rate, which is also very significant, considering how hard it is to try and
608.07s - 613.27s |  guess what all these words are. And since we're using AI models, this isn't a
613.27s - 616.99s |  perfect science. You know, we're using a lot of heuristics here. So, we sometimes
616.99s - 621.79s |  get it wrong. So, here's some fails. So, in the ground truth, it was something
621.79s - 624.59s |  like, I would like to suggest some following strategies for team leaders to
624.59s - 628.79s |  balance the needs of individual team members with the needs of the team as a
628.79s - 634.03s |  whole. And we inferred it as, I would suggest the following strategies, so far
634.03s - 639.07s |  so good, but then for film studios to balance the needs of production, so on
639.07s - 642.39s |  and so forth. Something that's completely unrelated. And sometimes it gets even
642.39s - 646.27s |  worse, right? So, here's a case where the response has something to do with apple
646.27s - 650.39s |  cider, and we thought it had to do with coral bleaching. Okay, so it's not a
650.39s - 653.99s |  perfect science, but what's interesting to note is that because we're using
653.99s - 657.99s |  machine learning model, the model also gives us a confidence score. How
657.99s - 663.59s |  confident it is that this prediction is correct, right? So, what we can do is we can
663.59s - 666.99s |  look, and we're trying to attack a particular, you know, token-linked
666.99s - 670.11s |  sequence that we see in the network. We can try to look at the confidence of the
670.11s - 676.89s |  model and say whether or not we should trust this inference or not. Alright, so
676.89s - 683.61s |  how common is this vulnerability? So, you know, around the time of our disclosure,
683.61s - 688.89s |  or prior to our disclosure around February 2024, nearly every major AI
688.89s - 693.33s |  vendor out there had this vulnerability. And, you know, when you start wondering
693.33s - 697.37s |  why is that the case? How do they overlook the seemingly obvious side
697.37s - 702.45s |  channel? And there's a few reasons that might come to mind. First, you know, they
702.45s - 705.65s |  might, perhaps they didn't think that token links the same as word links, so
705.65s - 709.65s |  maybe there was just a simple blunder. Or maybe they thought there's no way that
709.65s - 713.93s |  an adversary can guess entire paragraphs of text. That's just too hard of a
713.93s - 717.85s |  problem. But what I think is more likely the case is that it has something to do
717.85s - 722.65s |  with the big AI gold rush, right? There's so many industries that are jumping on
722.65s - 726.97s |  the AI chatbot idea and throwing it into services willy-nilly, and they don't
726.97s - 729.93s |  really think about security by design. They're saying, you know, the text is
729.93s - 735.33s |  encrypted, not a big deal, let's move on, right? So this is probably more likely
735.33s - 741.13s |  what happened there until they, of course, patched it after the fact. So why are
741.13s - 745.73s |  they even sending, you know, text to streaming, or token streaming across the
745.73s - 750.97s |  network? Why don't they just send as one big batch, right? So for example, Google's
750.97s - 755.81s |  Gemini does this already. When you get a response from Google Gemini, it's not
755.81s - 759.57s |  sending a token, token, token, it sends as one big block, and therefore they're not
759.57s - 762.57s |  vulnerable to the side channel attack. So why aren't the other vendors doing this?
762.57s - 767.37s |  So there's a simple answer for that, and the answer is that, you know, these AI
767.37s - 771.93s |  models are actually incredibly complex, and it takes a lot of effort to execute
771.97s - 775.97s |  them. So instead of having the user wait there for, you know, a good, you know, 30
775.97s - 780.21s |  seconds for this loading screen to go by to get their response, it makes perfect
780.21s - 785.13s |  sense to send those words or tokens one at a time in real time, so they can read
785.13s - 791.61s |  it as it's being generated. All right, so to recap so far, what we've accomplished
791.61s - 796.09s |  here is that we've discovered a novel side channel attack, which we call the
796.09s - 801.29s |  token length side channel, and we found it's common in LLM services all over. And
801.29s - 807.77s |  we've also found a way to exploit that side channel to read the hidden
807.77s - 813.05s |  information behind it directly using AI, and improve that performance using a
813.05s - 819.58s |  known plaintext attack. Okay, so for the rest of this talk, we're going to get
819.58s - 823.10s |  down into the nitty-gritty details, and first we're going to talk about how we
823.10s - 829.02s |  identified response traffic inside network traffic, and how we then extract
829.02s - 832.94s |  the token length sequences from there, and after that we'll talk a little bit
832.94s - 838.54s |  about how we train AI models, and our specific RAI model, and finally we'll end
838.54s - 841.90s |  off with some demos, defenses, and we'll talk about some bug bounties that we got
841.90s - 846.02s |  along the way. So with that I'm going to hand it off to Daniel, who's going to
846.02s - 857.62s |  take it from here. Thanks Israel. So let's jump to the nitty-gritty details. So we
857.62s - 861.18s |  will talk about how to find the sign channel, and how to extract the token
861.18s - 869.77s |  length sequence. So the first thing we'll have to do is to capture the traffic
869.81s - 874.17s |  containing the response from the assistant. So we'll need to be positioned
874.17s - 879.69s |  between the victim and the assistant. Or we can be in the same local network as
879.69s - 885.73s |  the victim, for example sitting in the same cafe using WiFi. So we collected a lot
885.73s - 890.61s |  of traffic, and not all of it containing our response data from the AI assistant.
890.61s - 894.81s |  So we'll need to filter the traffic. We can do that by filtering by the IP
894.81s - 900.35s |  address of the assistant. Uh that information can be collected by OSINT, or by
900.35s - 905.09s |  connecting as a legitimate client to the assistant server for through different times
905.09s - 911.13s |  a day, from different locations, and making our own data set of those IP addresses, and
911.13s - 918.01s |  basically filtering by those. Also what we can do is filter by the protocol. So every uh
918.01s - 923.31s |  vendor is using different protocol. For example ChetGPT is using quick protocol, so we
923.31s - 929.45s |  would like to search for UDP packets that are coming from port 443. And again, every
929.45s - 934.39s |  vendor is using different protocol, so we'll need to account for that. And also there is a
934.39s - 939.09s |  slight problem because it will add us more complexity when we will try to extract the token
939.09s - 944.43s |  length uh sequence, because again, every protocol looks differently on the wire, and it
944.43s - 952.45s |  has its own metadata. So we captured the traffic, we filtered out most of the traffic
952.45s - 957.25s |  that don't contain our tokens, we have the traffic that contains the response from the
957.25s - 964.72s |  assistant, let's extract the token length sequence. So our objective is to find the token
964.72s - 970.16s |  lengths. We need to remember that the traffic is encrypted, so we can't really see where are
970.16s - 976.16s |  the tokens, and what packets contain them. But what we can see is the bandwidth patterns,
976.16s - 994.34s |  basically the packet sizes. I'm sorry. So we found that there is two main ways that the
994.34s - 999.78s |  vendors are using to send their tokens. The first way is base plus next token. Basically
999.78s - 1005.88s |  each token is sent in a separate packet by itself, so we can infer the size of the token by
1005.88s - 1011.72s |  just analyzing the size of the packet. The second way is token accumulation. Basically the
1011.72s - 1017.16s |  tokens accumulate. We are sending each time the token with all of the tokens that were
1017.16s - 1022.84s |  previously sent, so the packets are increasing in size. In the next slides we'll talk more
1022.84s - 1028.74s |  about token accumulation, because this is the way uh that Microsoft and OpenAI are using, so
1028.74s - 1033.74s |  basically our tar- main target was JGPT, so we'll talk about this more. So to simplify the
1036.02s - 1042.18s |  problem, we'll first try to identify which uh messages, which packets are containing the
1042.18s - 1047.20s |  response. So to simplify it, let's try to find the start and the end. So again we can analyze
1047.56s - 1052.56s |  the bandwidth patterns and we found out that at the beginning, at the end of the response, we
1055.50s - 1060.84s |  saw uh bumps like increases in the packet sizes. That's because at the beginning you have
1060.84s - 1065.94s |  this all of those handshakes and establishing of the new channel and at the end you have
1065.94s - 1071.58s |  those uh communication of the end of the response. So you have those increases and we can
1071.60s - 1077.28s |  basically find the start and the end. Between those two points, the start and the end, we'll
1077.28s - 1084.13s |  try to search for this incremental pattern, the red line that you see. The packets that
1084.13s - 1089.77s |  follow this trend contain our tokens, but sometimes we have packets that don't follow this
1089.77s - 1095.51s |  trend. Those are sometimes control packets that do not have our tokens, so we'll filter those
1095.51s - 1102.51s |  out and we will be left after that filtering with a nice and smooth incremental pattern from
1102.53s - 1107.53s |  which we can extract our token links by calculating the delta as Israel said. So it sounds
1110.87s - 1115.87s |  pretty simple and some would say even easy and too good to be true and in reality it's really
1118.21s - 1124.35s |  the case so we have more challenges. The first challenge is message size limits and the
1124.35s - 1129.61s |  second one is message buffering uh that will cause message groupings. So let's talk about
1129.65s - 1135.63s |  that. Message size limits. In the internet we have this thing called MTU, Maximum
1135.63s - 1140.97s |  Transmission Units. Basically a maximum size that the packet can have and if we go above this
1140.97s - 1145.97s |  value we we can be fragmented on the IP layer. And what we found is ChetGPT over QUIC has even
1148.91s - 1153.91s |  a lower maximum size uh of 1,200 bytes. And as you remember ChetGPT is accumulating its
1153.91s - 1158.93s |  tokens so at certain point it will reach this maximum size. So what will happen is basically
1163.83s - 1169.93s |  that the payload will overflow to the next packet. So now we have two packets that are sending
1169.93s - 1175.33s |  this token because our payload is just too big. And what will happen is basically the sort of
1175.33s - 1181.47s |  pattern that you see now and also as the conversation grows and goes deeper and deeper and
1181.47s - 1186.05s |  makes it more and more long we basically can also overflow to the third and fourth and fifth
1186.05s - 1191.59s |  packet and at the filtering phase we'll need to account for that because we don't want to
1191.59s - 1199.12s |  throw those packets they contain our tokens. Another challenge is that the busyness of the
1199.12s - 1205.40s |  network will cause uh basically buffering that will cause our groupings. What does it mean?
1205.40s - 1212.40s |  So when the network is busy and lots of clients are connecting to the assistant servers and
1212.40s - 1217.40s |  many chat with ChetGPT what happens is that the servers tend to buffer their responses. And
1219.68s - 1226.44s |  what it looks for the user is that basically he has a small freezes that he sees and for us
1226.44s - 1231.42s |  what it looks like is that some packets will contain more than one token, more than one new
1231.42s - 1236.42s |  token. So uh basically this new packet will be double the size of the original trend and what
1237.18s - 1242.18s |  we can infer from that size is the size uh is the sum of those uh tokens that are contained
1246.02s - 1251.02s |  in the packets. But what we cannot infer is the size of each individual token. And this
1253.36s - 1259.64s |  problem will be overcome in the next uh phase which uh Roy will talk about uh with uh
1259.64s - 1264.64s |  exploitation with AI. So we will worry about that later. You probably wonder how the
1266.48s - 1271.68s |  we find all of this out. So we basically reverse engineer the traffic. We connected as a
1271.68s - 1276.52s |  legitimate client to the assistant servers. We got the SSL key, the encryption key between our
1276.52s - 1281.70s |  computer and the assistant server. Uh we plug this into Wireshark and we were able to watch the
1281.70s - 1288.20s |  decrypted traffic, learn it like analyze the metadata and make rules to extract the token
1288.20s - 1296.06s |  length sequence from the encrypted traffic. So to sum this up, we capture the traffic, we
1296.08s - 1301.56s |  filter the traffic and then we extracted the token length sequence. And now we would like to
1301.56s - 1308.10s |  translate those token length sequence to plain text English and that's what Roy will talk about
1308.10s - 1316.43s |  next in the next part, exploitation with AI. Right. Thank you Daniel. Um let's indeed talk about
1318.67s - 1323.87s |  how to exploit the side channel using uh a machine learning. But don't worry I'm not a typical
1323.89s - 1329.73s |  machine learning guy, we'll keep it simple. So the first step in training a machine learning
1329.73s - 1335.47s |  model is to basically gather a data set. We need to have a data set which will contain inputs
1335.47s - 1341.15s |  and outputs. Then we train the model by feeding him examples of the inputs and what the output
1341.15s - 1346.15s |  should look like. Training an LLM is no different. So in our case, the attacker will first gather a
1346.51s - 1351.51s |  huge corpus of text. He will transform the text into token length sequences and then pass them
1354.95s - 1361.09s |  to the model. We hope that the outputs of the model, if not exact, will have the same similar
1361.09s - 1366.09s |  semantic meaning. Alright, so now begs the question, how do you how do you even use the model?
1367.09s - 1372.09s |  When uh um LLM output you uh gives you a response and output, each time you get it a bit
1376.73s - 1382.59s |  differently. As Israel said, each time with the output you get a confidence score. Then you can
1382.59s - 1389.17s |  basically uh prompt the model many times and so the outputs based on the confidence score and
1389.17s - 1394.17s |  most often the most confident output will have um will be the closest to the real thing. So
1396.67s - 1403.05s |  that sounds really simple and uh fun and that's what we did. We took the AI system response,
1403.05s - 1408.05s |  transformed it into token length sequence, passed it to our trained uh model and it failed
1410.09s - 1415.09s |  miserably. Well the problem was too hard, even for an LLM. But we still had a glimpse of hope
1418.07s - 1423.07s |  because although the semantic meaning uh similarity was nowhere uh to be found, the model
1423.29s - 1428.29s |  still learned the high level structures such as list structure. So we started to look around
1431.97s - 1436.97s |  on ways to improve our approach. Um we noticed a really interesting phenomena about AI system
1439.47s - 1444.47s |  responses. The first sentence almost always holds the essence of the entire response. The first
1446.17s - 1451.17s |  sentence is like a an introduction to the coming paragraph. Learning from history, we took
1453.55s - 1460.41s |  the hard problem and divided it into smaller problems to deal with each at a time. Because uh
1460.41s - 1466.23s |  the first sentence is really unique, we first tackled it and tried to solve it and then all of
1466.23s - 1471.73s |  the others because if you think about it, if we crack down the first sentence, we will win. We
1471.73s - 1476.73s |  could because we could build upon that with a preserved topic in mind. But wait, hold on.
1476.87s - 1481.87s |  Isn't the traffic encrypted? What do we even have in the end? Token length sequence. How are we
1484.97s - 1489.97s |  able to divide it into segments of sentences? Well, most tokenizers encode punctuation marks as
1493.41s - 1498.41s |  a separate token. This means that almost always a token length of one is a punctuation mark. So
1500.53s - 1505.53s |  this means we can basically look at the token length sequence, search for one and divide it.
1506.83s - 1513.13s |  But um we want to avoid false positives. For example, too short of a sentence because comma at
1513.13s - 1518.83s |  the start. So we apply the simple heuristic that uh basically says we won't divide it if the
1518.83s - 1525.41s |  sentence is too short. All right, with this idea, because the first sentence is really unique, we
1525.41s - 1530.41s |  train the model only on first sentences, meaning its data set contain only first sentences. Uh and
1530.47s - 1535.47s |  we train another model for all of the other sentences to further help the second model try to
1538.65s - 1545.05s |  figure out what is the right topic. We took the output which was generated by the first
1545.05s - 1551.89s |  sentence and then passed it as part of the input to the next model. And then uh with other
1551.89s - 1556.89s |  generations we did the same and uh just like that, we we have preserved the context in mind when
1557.05s - 1562.05s |  generating the entire paragraph one by one. All right, um this approach is nice and we got 10%
1567.23s - 1574.19s |  attack success rate, but it's not enough. Uh we are at DEF CON after all. So uh there is one
1574.19s - 1582.39s |  more thing that could help us improve. As we said, AI assistant responses are not just random
1582.41s - 1588.45s |  Wikipedia pages. They are not random text. This may uh they have predictive predictable style
1588.45s - 1594.63s |  and low response diversity. This means that we can use it to our advantage and relate to this
1594.63s - 1602.68s |  problem as a known plain text attack. AI assistant responses have predictable style, they have
1602.68s - 1607.68s |  warnings, templates, they follow safeguards and structure. This means that if we will train a
1607.96s - 1612.96s |  model on those responses, the model will be able to learn those patterns and it it will make
1616.74s - 1621.74s |  our life easier. Also, as we can see here, many different prompts that talk about the same
1624.48s - 1631.38s |  rather topic will have the same response. This means that a a model which is trained on AI
1631.42s - 1636.42s |  system responses will be able to generalize to many different prompts. So, to summarize, the
1639.26s - 1644.26s |  entire process is first collecting a data set of prompts. Then we will pass it to our target
1647.20s - 1652.20s |  model like JGPT4. Then we will collect the responses, transform them into token length
1654.74s - 1659.74s |  sequences and train the model as we saw. This combined approach yield in huge amount of
1661.38s - 1666.38s |  boost of performance. This plot compares uh the uh performance of the combined approach, the
1668.92s - 1675.56s |  green one, the blue one which is uh training the model on random text and the red one which is
1675.56s - 1682.00s |  plainly asking JGPT please help me solve this side channel. And we can see uh that all of the
1682.00s - 1687.98s |  examples to the right of the vertical line are considered successes and the green one was much
1688.02s - 1695.02s |  better than all of the other approaches. And the numbers we as as we said before we got about 55%
1695.02s - 1701.60s |  attack success rate on first sentences and 38 on entire paragraphs. We have also encountered a
1701.60s - 1706.60s |  really interesting phenomena. Different topics were susceptible uh than others. In our example
1710.90s - 1716.58s |  a mental health and financial status were much more susceptible than for example sex sexual
1716.58s - 1721.58s |  health. This is mainly to the fact that those topics were much more common in the data set.
1724.56s - 1729.66s |  This means that we've we've if we have an attacker with a specific goal in mind he can train his
1729.66s - 1736.64s |  own model on those subtopics and get better results. Alright so what about the network noise
1736.64s - 1741.64s |  and traffic and all of the stuff Daniel said? Um when we have high network uh traffic we get
1742.64s - 1749.34s |  grouping and buffering. So we first wanted to evaluate how much groupings were actually there.
1749.34s - 1754.34s |  We ran a 24 hour experiment against open AI JGPT and we measured the amount of groupings we got
1758.22s - 1765.22s |  in each hour of the day. As expected in the day there were much more groupings than in the night.
1765.22s - 1770.22s |  But as we will see it is manageable. To solve this challenge we took our training process and
1772.98s - 1779.46s |  our data set and just applied random groupings on the token length sequences. Then as we can
1779.46s - 1784.46s |  see in the first row we still got 35% attack success rate on first sentences which is really nice
1786.90s - 1792.84s |  because the it is way more challenging. Also when looking around on different uh susceptible
1792.86s - 1797.86s |  vendors we found out that open AI API transmitted their messages as paired tokens. Meaning each
1800.20s - 1805.20s |  packet holded two tokens. Okay this is more challenging but we wanted to evaluate if we can
1808.44s - 1813.44s |  break it and award more and get more reward. So uh we took our training process and applied uh
1816.58s - 1822.82s |  random uh not random sorry and we applied pairing uh pairing on the tokens. Meaning we
1822.86s - 1828.50s |  took the token lengths and just paired them. We still got 17% attack success rate on first
1828.50s - 1833.50s |  sentences with this approach. Alright so after I've yucked you out with theory let's talk business.
1838.22s - 1843.22s |  So um as we all know training an LLM from scratch is really hard. It takes a month of computer
1847.42s - 1852.52s |  time and millions of dollars in hardware and energy. We didn't have to go through such
1853.36s - 1857.86s |  hustle, rather we used a common technique called fine tuning which means we took a trained
1857.86s - 1862.86s |  model and further trained it on our own translation task. We took a model called T5 which
1865.84s - 1868.84s |  was trained-
1868.84s - 1869.84s |  announcement.
1869.84s - 1874.39s |  We have a small disruption.
1874.39s - 1875.39s |  Sorry.
1875.39s - 1876.39s |  Attention down code hackers.
1876.39s - 1877.39s |  Halls 2 and 4 are now closed.
1877.39s - 1878.39s |  Heavy equipment will begin operation soon.
1878.39s - 1879.39s |  All humans need to vacate the premises before they become trapped and are forced to become
1879.39s - 1880.39s |  goons for eternity.
1880.39s - 1881.39s |  Villages and contests have now closed.
1881.39s - 1882.39s |  All hacking of the planet must be done elsewhere.
1882.39s - 1883.39s |  Please join us for the contest closing ceremonies in chapters 1 and 2.
1884.17s - 1885.17s |  Attention down code hackers.
1885.17s - 1912.17s |  You must vacate the hall before you become impaled by a forklift.
1914.41s - 1917.49s |  OK, good day to you too.
1917.49s - 1920.13s |  So let's recap.
1920.13s - 1922.65s |  Our model was based on the T5 model,
1922.65s - 1925.09s |  which is trained by Google.
1925.09s - 1929.05s |  And it is publicly available.
1929.05s - 1931.49s |  We also didn't have to go through the hassle
1931.49s - 1933.33s |  of gathering our own data set.
1933.33s - 1934.93s |  Rather, we used an open source one
1934.93s - 1937.61s |  called UltraChat, which basically contains dialogues
1937.61s - 1939.53s |  with GPT-4.
1939.53s - 1945.29s |  We also used Hugging Face as our framework trainer,
1945.29s - 1948.77s |  which makes the technicalities of training a model much
1948.77s - 1951.97s |  easier, even for a guy like me.
1951.97s - 1956.69s |  OK, our model was trained for two days of compute time.
1956.69s - 1960.73s |  And if we have an attacker with no GPU in hand,
1960.73s - 1963.61s |  he can use Azure, for example, for only $200,
1963.61s - 1965.77s |  which is fairly affordable.
1965.77s - 1968.81s |  So let's see some demos.
1968.81s - 1976.45s |  In this case, we have the victim, Microsoft Copilot.
1976.45s - 1978.77s |  He asked the random question of, what
1978.77s - 1981.33s |  are some of the latest developments in machine
1981.33s - 1983.93s |  learning and AI that could revolutionize the health
1983.93s - 1984.85s |  industry?
1984.85s - 1989.29s |  Besides him, the attacker eavesdropped the entire traffic.
1989.29s - 1992.65s |  He collects traffic using Wireshark.
1992.65s - 1996.13s |  And after collecting for a bit of time,
1996.13s - 1998.57s |  he will try to filter the traffic.
1998.57s - 2002.01s |  As Daniel said, one of the common techniques to filter
2002.01s - 2004.09s |  is based on the IP.
2004.09s - 2008.93s |  So the attacker does just that.
2008.93s - 2012.81s |  And in this case, the attacker manually
2012.81s - 2014.97s |  figures out where the start is.
2014.97s - 2016.73s |  Well, of course, the traffic is encrypted,
2016.73s - 2021.13s |  so you just need to do it by hand and by eye.
2021.13s - 2024.85s |  And after figuring out where the start is,
2024.85s - 2027.09s |  the attacker will put inside the tool
2027.09s - 2032.01s |  the token length, excuse me, the packet sizes.
2032.01s - 2034.69s |  Then the tool will calculate the deltas
2034.69s - 2037.05s |  between the packet sizes.
2037.05s - 2039.77s |  And we will have a token length sequence.
2039.77s - 2042.49s |  Then basically, the tool will pass it to the model
2042.49s - 2045.93s |  to try to generate the ground truth.
2045.93s - 2052.13s |  And as we will see in a bit, hold on.
2052.13s - 2054.13s |  Yes, we got the token length.
2054.13s - 2056.81s |  And now the model thinks.
2056.81s - 2058.49s |  Actually, really fast.
2058.49s - 2060.21s |  And all right.
2060.21s - 2063.33s |  So it will be, it will zoom out in a bit.
2063.33s - 2066.17s |  We basically got the same rather topic.
2066.17s - 2068.41s |  Several recent advancements in machine learning
2068.41s - 2070.01s |  and artificial intelligence.
2070.01s - 2074.21s |  That could be a game-changing tool, yada, yada.
2074.21s - 2076.33s |  All right, so for the public use,
2076.33s - 2079.45s |  we've deployed a full plug-and-play tool
2079.45s - 2083.37s |  on GitHub called GPTKeylogger.
2083.37s - 2087.61s |  The tool has two main models, the attacker model
2087.61s - 2088.69s |  and the trainer model.
2088.69s - 2090.65s |  I will elaborate them in a bit.
2090.65s - 2094.89s |  And our model is also publicly available.
2094.89s - 2100.85s |  And it is trained on JGPT-4 responses from February 2024.
2100.85s - 2102.41s |  The first model, the attack model,
2102.41s - 2107.01s |  is for you guys to try attack different vendors.
2107.01s - 2110.81s |  It can receive as input packet lengths, as we saw in the demo,
2110.81s - 2113.01s |  token lengths, which is straightforward,
2113.05s - 2114.17s |  and the original text.
2114.17s - 2117.97s |  The tool will basically tokenize the text,
2117.97s - 2120.17s |  calculate the token length sequence,
2120.17s - 2122.41s |  and try to predict.
2122.41s - 2126.57s |  And you can use it with this simple command.
2126.57s - 2129.05s |  If you want to target a different vendor
2129.05s - 2132.81s |  with a different back-end LLM, you should train your own model.
2132.81s - 2134.73s |  Because every LLM works differently.
2134.73s - 2138.05s |  And our model is based on GPT-4 responses.
2138.05s - 2142.25s |  So if you want to target a model like Llama,
2142.25s - 2143.29s |  you should train.
2143.29s - 2148.09s |  And we offer this for you to make life much more easier
2148.09s - 2149.69s |  with those commands.
2149.69s - 2151.61s |  Also, the configuration file is also
2151.61s - 2155.81s |  available in the GitHub page, which is nice.
2155.81s - 2159.89s |  And all right, so let's talk some defenses.
2159.89s - 2161.81s |  We have contacted all of the vendors
2161.81s - 2166.33s |  that we found vulnerable up to February 8 this year.
2166.33s - 2168.89s |  All of the major vendors were really responsive.
2168.89s - 2171.77s |  And they patched the problem really quickly.
2171.77s - 2175.25s |  Until March 1, and we came public
2175.25s - 2179.53s |  with this vulnerability on Ars Technica
2179.53s - 2182.61s |  on the 14th of March this year.
2182.61s - 2186.97s |  Out of the vendors, those five had bug bounty programs,
2186.97s - 2191.53s |  which awarded us a small reward, which was really nice.
2191.53s - 2194.89s |  All right, so although this side channel is really
2194.89s - 2197.61s |  difficult to exploit, as we saw, the defenses
2197.61s - 2199.25s |  are really easy to make.
2199.25s - 2202.21s |  After consulting with the engineers
2202.21s - 2204.69s |  of the different vendors, we came up
2204.69s - 2207.49s |  with three solutions.
2207.49s - 2211.49s |  Random padding to the packets, padding to the nearest value,
2211.49s - 2215.49s |  like nearest 100 size, or applying more buffering.
2215.49s - 2218.73s |  Here is the mapping between the different vendors
2218.73s - 2221.41s |  and the deployed defenses.
2221.41s - 2226.01s |  When diving a bit deeper, OpenAI basically
2226.01s - 2230.09s |  did padding to the nearest, to the closest 32 value
2230.09s - 2234.49s |  by adding a pad field on the transmitted JSON.
2234.49s - 2238.69s |  And as we can see on Wireshark, the size is a line.
2238.69s - 2243.65s |  And CloudFlare, for example, deployed random padding.
2243.65s - 2247.49s |  And we can see that the sizes are all messed up.
2247.49s - 2251.21s |  All right, let's wrap things up.
2251.21s - 2253.05s |  So what did we discover?
2253.05s - 2256.05s |  We have identified a new side channel vulnerability
2256.05s - 2257.85s |  based on token lengths.
2257.85s - 2260.49s |  This is significant because, as we saw,
2260.49s - 2265.37s |  it impacts multiple vendors exposing sensitive information
2265.37s - 2268.17s |  through their AI systems.
2268.17s - 2272.93s |  This work has shown how to break a side channel used
2272.93s - 2274.77s |  with generative AI.
2274.77s - 2278.13s |  And it is the first work to do so.
2278.13s - 2281.33s |  While some vendors have patched this vulnerability,
2281.33s - 2285.41s |  there is still a real concern about how new AI services
2285.41s - 2288.81s |  will handle this issue.
2288.81s - 2290.65s |  Now on to the key takeaways.
2290.65s - 2295.33s |  First off, it is crucial to use encryption schemes correctly.
2295.33s - 2297.49s |  This has repeated itself throughout history,
2297.49s - 2301.53s |  time and after time, and yet leading
2301.53s - 2305.05s |  to multiple side channels and cracking of encryptions.
2305.05s - 2308.33s |  Similarly, in modern times, even subtle details,
2308.33s - 2311.73s |  like token lengths, can leak sensitive data
2311.73s - 2314.09s |  if not properly protected.
2314.09s - 2317.13s |  AI services are no exception to this rule.
2317.13s - 2319.37s |  They must be designed and implemented
2319.37s - 2321.77s |  up to the highest security measures
2321.77s - 2324.41s |  as any other software domains.
2324.41s - 2326.69s |  Remember, AI is your friend.
2326.69s - 2329.77s |  It is a powerful tool both for offensive and defensive
2329.77s - 2330.81s |  applications.
2330.81s - 2334.13s |  We should harness its potential to identify and mitigate
2334.13s - 2335.41s |  vulnerabilities.
2335.41s - 2338.05s |  What seemed impossible is now possible
2338.05s - 2341.09s |  thanks to advancements in AI.
2341.09s - 2344.65s |  Finally, our discovery raises an important question.
2344.65s - 2347.69s |  What other side channels are vulnerable?
2347.69s - 2350.01s |  We encourage the community to explore and secure
2350.01s - 2352.17s |  these potential weak points.
2352.17s - 2354.69s |  To sum it up, we have joined throughout the process
2354.69s - 2357.37s |  of identifying, exploiting, and defending
2357.37s - 2359.25s |  against this new side channel.
2359.25s - 2361.65s |  This research highlights the importance
2361.65s - 2366.13s |  of considering even the smallest details in data transmission
2366.13s - 2367.85s |  within AI systems.
2367.85s - 2370.93s |  I hope this inspires you to think creatively
2370.93s - 2375.01s |  about both offensive and defensive capabilities of AI
2375.01s - 2377.61s |  in cybersecurity.
2377.61s - 2380.09s |  Thank you all for your attention.
2380.09s - 2382.97s |  Check out our tool, GPTKeylogger, and our labs page
2382.97s - 2385.89s |  when we update on more research.
2385.89s - 2389.97s |  Stay secure, stay curious, and enjoy the rest short bit
2389.97s - 2391.73s |  of DEF CON.
2391.73s - 2392.17s |  Thank you.
2392.17s - 2393.89s |  Thank you.


