# Media

url: https://www.youtube.com/watch?v=rogtZjpyoVQ
title: DEF CON 31 - Unlocking Doors from Half a Continent Away - Trevor Stevado, Sam Haskins
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=rogtZjpyoVQ",
    "title": "DEF CON 31 - Unlocking Doors from Half a Continent Away -  Trevor Stevado, Sam Haskins",
    "description": "Contactless credentials have become increasingly popular for secure authentication and access control systems due to their convenience and efficiency. In this talk, we will discuss a specific weakness in the ISO 14443A protocol that enables replay attacks over moderate latency connections, leading to the potential for long-range relay attacks.\n\nDuring the presentation, we will delve into the history of contactless credential attacks, how manufacturers have adapted, and discuss why we focused on a relay attack. We will provide an overview of the ISO 14443A protocol and explain how the relay attack is executed and the \u2018features\u2019 of the underlying protocol that make it possible. Finally, we will demonstrate and release a new tool to make this relay attack feasible with the Proxmark, as we attempt to unlock a door in Ottawa, ON with a card on-stage in Vegas.\n\nIn addition, we will discuss the response from HID Global following our responsible disclosure against their SEOS readers and suggest mitigations to prevent these attacks on your access control systems.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 2277,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230915"
  }

  This text was transcribed using whisper model: large-v2

   Thanks for coming out. This is our talk, Unlocking Doors from Half a Continent Away. I hope you  have some fun. So, this isn't working. All right. My name is Trevor Stavato. I'm the  founder of a small cybersecurity company up in Canada called Loudmouth Security. I've  been doing offensive stuff for, I think, I counted about 15 years now, but I just stopped  counting and put 12 plus in the slides. My biggest personal or professional achievement,  it was winning a DEF CON Black Badge back at DEF CON 26. Thank you. Thank you.  Hi. My name is Sam Haskins. I'm a hacker working for Loudmouth Security. I'm also a current  computer science student at Carleton University up in Ottawa in the computer and Internet  security stream. I've been hacking things since I was 12 at least. I have two CVEs from  ages 16 and 19. That was just last year. This is my second year at DEF CON, and I'm really  excited and happy to be here. I'm just a little bit scared.  All right. So, we're going to be talking about physical access systems. So, just to give  you a quick background of all the components, you have a card that has the credential on  it, the reader that's going to read that credential off the card, send that information  back to a back-end access controller that will validate that credential, make sure it's  valid for the door it's trying to open. If it is, it'll send a signal to the lock, opens  the door, opens Sesame, you're golden. We're going to be focusing mostly, well, entirely  on the card-to-reader interactions. And in that space, there's quite a few technologies  that have been a part of this. And we'll go through some of them just for history's sake,  but our technology, our attack is going to be on some of the newest technologies, MyFairDestFire  and SeeUs. So, the purpose of physical access, what it's trying to do is it's trying to validate  that there's a physical presence of a credential at a specific time. So, that's what the reader  is trying to do. And so, because of that, there's some ways that we have come up with,  people have come up to attack it. The first one is the most basic card-cloning attack.  If you can see a card, capture the data off of it, write that to a new card, present that  to a reader, it has no idea that it's a different card. So, you have a duplicate and you can  authenticate as the original card. A kind of offshoot of that one is a downgrade attack.  So, if you have a technology that can't be cloned, but you can read it with a standard  reader, you can take the data that it's trying to send to the backend, encode that on a lower  frequency or lower security card and if the reader will accept both, then you've duplicated  the card just as effectively. The other category that I don't see very much in the physical  security space, but we just put it in for posterity, is the replay attack. So, if you  can capture a sequence of messages between a card and a reader and then replay that,  you may be able to trick a reader into thinking that there is a credential there at that time.  And then the final one, the one that we're going to be talking most about in doing the  demos of today, is the relay attack. And you might be familiar with this in the space  of car thefts, where people are putting readers up next to your door and trying to relay the  signal from your key fobs to your car. The same kind of thing that we're doing with RFID  cards. We're going to try to relay an RFID card over a very long distance and just show  you how that can be done. So, to give you some context about how we got started down  this path of research, it's good to know what the history of access control technologies  are and what the flaws were that kind of led them to where they are today. So, one of the  original technologies, the HID prox, a very simplistic technology, once the card got energized,  it broadcasts its ID. Anybody around can listen to it. Super insecure. There's no encryption  on it. You can buy a reader from Amazon for very cheap. Fun fact, my very first DEF CON  was DEF CON 21. I went to go see the Bishop Fox talk on the Tastic RFID thief, where he  took a garage door reader, it was a high-powered garage door reader, and basically tagged on  to the data lines so he could record the card data. But that extended his read range from  a couple of inches to a couple of feet, and he would walk around with that in a briefcase  and collect cards. It's a pretty fun talk. I still have the piece that I got from it,  and it kind of inspired some of the stuff that moved me forward into this talk. So,  HID realized that that wasn't a good idea, so they came up with another version called  the HID iClass, and it was designed to protect card cloning replays. The way it did that  was it had a key between the card and the reader that was a shared key that only they  knew. HID created one shared key between the card and reader for most of the systems that  they released. If you wanted to have a special key, you had to ask HID to create a new one  for you, and they called that the elite key system, so only your readers and your cards  would use that shared key. And it was done through a proprietary cipher that they created,  which was then reverse-engineered by some researchers, and they came up with a key recovery  attack where you can recover the keys of any, not just the standard, but even the elite  keyed readers. So now it's trivially simple to create a copy of an iClass card using things  like the Proxmark. Another kind of entry in the mid-range RFID is the Mifare Classic.  So we don't see this very often used in access control, but it's kind of the precursor to  the Desfire EV1 that sometimes does get into access control, so we thought we'd throw it  in as well. It uses a different mechanism. It has keys for each sector, and you can have  two keys that you can define as a read or a write key, but again, they used a proprietary  algorithm for that crypto, and again, it was reverse-engineered by a team of researchers.  So very easy to copy and clone Mifare Classic cards. I think this is about the point where  both HID and NXP, who make the Mifare cards, kind of realized that maybe making proprietary  crypto was not a good idea, and you can see that in a lot of their marketing about the  new technology. So the new one for HID is CEOS, and NXP came out with the Mifare Desfire,  and there's a couple of variants of that, EV1, 2, and 3, and so they all use industry  standard ciphers, and the worthwhile thing to note is that EV1 came out in 2006, so 17  years since EV1 came out in CEOS after that in 2012, there's been no public techniques  disclosed to clone a CEOS card. The only attack that is currently known before what we're  going to show today, I guess, is the downgrade attack. So if you have a CEOS reader that  has a standard key set and your card is in the standard key set, you could read the data  off the back end, program that onto a low frequency or a lower security card, and create  a duplicate that way. But that can be easily defeated by using elite-keyed systems, because  then you would have to have a reader that has that same elite key, so if you're targeting  a facility, you'd have to go and rip that reader off the wall, and I'm pretty sure they're  going to notice that. Or the other thing they can do is they can configure their readers  to only accept the CEOS or Desfire cards, so if you clone it to a low frequency or a  lower security card, it's useless, because the reader won't accept it. Now, you might  come into situations where they have different configurations around the building. In a loading  bay, they might use a dual frequency reader, but most often, the secured, protected areas  of a high security building are going to be protected by elite-keyed CEOS or high  frequency only cards. So, and that was actually the scenario that we faced when we were doing  a red team engagement, so that's what led to the motivation. If we can't break the crypto,  we go for a relay attack instead, and I'm going to pass it to Sam to talk about how  we did that.  Thank you. So, first, I'm just going to talk a bit about the relay attack scenario, so  what this would look like from an attacker deploying it. So, basically, you're going  to send one of your guys to stand beside a legitimate employee of the place you're trying  to access on public transit or some other environment like that, and then they can hold  a Proxmark fairly close to the guy's pass, and then you send one of your other guys right  up to the door and just badge in, and you need some way of communicating between the  two Proxmarks. We use the internet as a backbone, which is super convenient, because it's available  everywhere with cell networks and stuff, but it theoretically could be anything there.  So here's the architecture of our original attack here. The first version used laptops  instead of mobile devices. We since migrated to that, but as you can see, we have the real  card and then two Proxmarks acting as a fake reader and a fake card, and then if you follow  that green line there, messages go from the real reader all the way to the real card,  and then responses go all the way back. You repeat that about 10 or 12 times or whatever,  and then the door opens. And even this original attack did use over the internet. We had a  web socket connection between the two laptops, and in this original attack, we also used  Bluetooth between the laptop and the phone, or sorry, between the laptop and the Proxmark  just to get them a bit further apart and not have to run wires. So because all of the messages  are generated by a real card and a real reader, the contents are guaranteed to be correct.  If they weren't, the system wouldn't work in the first place, and legitimate cards would  not open the doors. So the only way that readers could detect our attacks is by detecting timing  variations, and that's because the round-trip time of request-response over about an inch  between the legitimate scenario versus auto to Vegas is significantly shorter. So we were  investigating, can we make the readers support longer than normal timings? And it turns out  that we can. There's a few mechanisms. So all of the high-frequency cards that we've  discussed so far, so the 13.56 megahertz ones are based on ISO 14443 type A, or just 14A  since that's a lot of letter soup, and most access controls would be based on the standards.  There's a few that aren't, but most of them are, and this is analogous to how HTTP is  built on top of TCP. This provides a messaging layer that the application-specific data would  travel over, but before any application-layer data, so the CS protocol or the desk protocol,  before any of that happens, the card and the reader must exchange parameters in what we  call the 14A handshake, and this is both documented very nicely, it's an ISO standard, but it's  also not encrypted or authenticated at all. There's a 16-bit CRC on some parts, but the  details of that are public, so we can't mess with that. So let's have a quick look.  So this diagram here shows a real handshake that we captured between a real CS card and  a real reader. You don't have to understand most of it, the spec is about 100 pages, but  there are a few parts I'd like to highlight here. So the first message I'd like to highlight  is this UID CLN message. Now, the standard actually has a mechanism for the card to give  a UID to the reader. CS doesn't use this, because it's completely unauthenticated, as  said earlier, but other mechanisms do, but CS actually just provides a random value each  time, so you can't even use this with readers who don't support the CS protocol just by  falling back to that number, and then the other thing I'd like to highlight is that  ATS message there, and specifically that blue byte, which is interface byte TB1. ATS here  is answer select, and the important bit of TB1 there is the frame waiting time integer,  which is coded in the high nibble, and that's the frame waiting time, and I'll explain what  that is in just a second, in accordance with that little equation there, and the FWT tells  the reader how long to wait between frames, so after the reader sends a request, it will  wait that amount of time before expecting a response from the card, and if it doesn't  receive one at that point, it will usually restart the entire authentication attempt  from the beginning, however, this is unauthenticated, it's sent by the card, which we are pretending  to be, and we can mess with it, and if you notice at just the end of that equation there,  there's that exponential term, we can make that go pretty high.  So after the 14A handshake is complete, it goes into the CS protocol, which is a bunch  of random bytes, and I have no idea what they mean, but who cares, because these are  generated by a real card and a real reader, we know they're right, we just need to get  them from point A to point B. Yes, a lot of the messages in the 14A handshake  are sent before that ATS message, so the modified frame waiting time won't apply yet, and therefore  we can't relay them, the latency over any internet connection, even basic Ethernet will  be far too long, it's messed up by print statements in fact, so that initial 14A handshake does  have to be handled on the prox marks themselves, but thankfully it can really just be hard  coded for the most part, it doesn't really vary, but we'll get into a few more details  on that later. And as for how long we can get the reader  to wait between frames, if we set the FWI to its highest value of 14, we can make it  wait 4,949 milliseconds, which is almost five seconds, I'm not sure why that's supported  by the standard, because I don't see a real use case, but it's very convenient for us.  There is another technique in the 14A standard that we can use to bypass the round trip time  check, which is waiting time extensions, and that's a mechanism that applies to just the  next message, not all subsequent messages, but it can also be repeated, which is nice,  so theoretically if you keep the fake card by the reader for 20 minutes and it just keeps  sending these, you could have 20 minutes of time, but in practice, at least with the readers  that we tested, we found it was less reliable, so we're mostly relying on modifying the FWT.  I think a big problem with the WTX is it does need to be sent for each message, so if it's  missed once, the entire authentication attempt fails.  So our original design was implemented as an extension to the already existing and open  source HF Replay Proxmark standalone mode, which was originally written by Salvador Mendoza,  that was to relay credit cards actually, which was pretty cool, and we made some changes  to allow vm.cs protocol, or really any protocol, instead of just credit cards, and also adding  the long-range internet component, instead of just over Bluetooth like it was originally,  and this original design was strongly coupled with the BlueShark Bluetooth add-on, messages  were conveyed from Proxmark to laptop and then sent over IP, and we did have a lot of  success with this design, the big highlight being unlocking a door in Ottawa with a card  in Florida, because my colleague over here has a vacation home in Florida, so we sent  him down with a card and just tried that out, and it worked after a few tries.  There were, however, some fairly major reliability issues in this original design.  So the BlueShark add-on does come with an integrated rechargeable battery, and we did  like that design at first, because it's a lot more convenient for, like, real deployments,  like actually standing beside someone on the bus and trying to relay their card, than running  a cable up their sleeve, you get to put it a bit further away, you don't have that whole  cable to deal with, but the ability of the Proxmark that's pretending to be a reader  to read the card, which is its job, is very dependent on the battery level.  If it's too high, we get bad reads.  If it's too low, we also get bad reads.  We're not entirely sure why that happens.  We think it's related to, like, the voltage level being output by the battery, but we're  not 100% sure on that.  It did prove very frustrating, like, while we were developing this, we developed little  rules of thumb, like, when it starts failing, plug it in for 12 minutes and try again, and  that kind of worked, but it wasn't very nice.  The other problem was latency.  So we can make the reader accept ridiculous amounts of latency, but on the card side,  real cards are designed under the assumption that the reader will respond within at most  a few milliseconds and typically much faster, and we blow that assumption out of the water  by several orders of magnitude when we're doing this over longer ranges.  So we find that the card sometimes, like, forgets that it's supposed to be in the middle  of an authentication attempt, and this happens increasingly often as the latency increases.  This isn't, like, necessarily a deal breaker by itself, because it just means you need  to retry from the beginning, so if your guy is still standing beside the guy in public  transit, you're good to go, but maybe it's a little suspicious if you're standing beside  a reader for two minutes waiting for the door to open.  Not the best.  And different cards could be more resilient to this.  Most of our observations here were with CEOS cards in particular.  We actually only tested with Deskfire for the first time earlier today before we went  to sleep.  It was hard to source a card.  So between that and the battery issues, the initial design was not reliable.  It was usable, not really reliable, but usable within the same city, and even then, I'd say  this was a practical attack that higher security, higher value facilities would be more concerned  about, but it was much harder to make it work over longer distances, and even in the  same city, it wasn't perfectly reliable.  So our revised design, we incorporated quite a few changes.  So first off, we swapped laptops with phones.  Laptop in your backpack is fine, but phone in your pocket is even better, and then more  importantly, we swapped that little Bluetooth link there with a serial link, and we're also  powering the Proxmark from the phone over that serial link.  So we knocked out the battery, and we knocked out Bluetooth.  Bluetooth was nice, but Bluetooth classic is a horrible protocol, and 15 milliseconds  of latency on each side, 100 milliseconds total, when Florida to Ottawa is only a 99-millisecond  ping.  That's almost doubling it, and we didn't really want to eat that, and getting rid of that  really did increase our reliability.  Additionally, just operated over a cell network where phones will not have public IPs, instead  of them connecting directly to each other, we have a little relay server just hosted  in DigitalOcean in between them.  So the software in our revised design is called HFCardHopper, it's a new module for Iceman's  Proxmark 3 firmware, we're releasing it later this week whenever I get around to doing a  pull request.  It's inspired by Salvador Mendoza's original design, but doesn't share any code, and it  has the code to trick readers into using a longer frame rating time.  It can relay any ISO 14443A protocol, and it actually has support for relaying that  initial UID and DATS, that doesn't matter so much for CEOS, because the UID is random  each time, but for Deathfire, that UID actually contributes material to later cryptographic  operations, so to get it to match up on both sides, you do need to get that right.  Now, because that's sent over DATS, we can't actually relay that in realtime, because the  modified frame rating time won't apply, but it doesn't actually change, like, well, for  when it matters, it doesn't change, so Deathfire codes always give the same UID, so if you  just read it once, then transmit it, then the Proxmark can set itself up to emulate  that specific card, and that doesn't have to happen in realtime, which is nice, and  it works with BlueShark and our custom hardware, which handles that CO link, which my colleague  Trevor will talk to you about.  Yeah, so as Sam mentioned, we wanted to swap out the Bluetooth module, mainly because of  latency issues, so we came up with another module that is USB to UART bridge, basically.  If you're familiar with things like the Shikra, it uses the FT232 chip that's in the Shikra,  we just modified the design to have a USB-C, which is much more convenient for connecting  to modern phones, and then a ribbon cable for connecting to the Proxmark.  We chose to use a ribbon cable to connect to that interface on the Proxmark for a couple  of reasons.  A, we think it's a little bit faster, we're directly connecting to the Proxmark over USART,  whereas if you're connecting to the USB on the side of the Proxmark, that's actually  an emulated modem, so that would add a little bit of latency, but also this makes it completely  interchangeable with the BlueShark add-on, so if you wanted to use the BlueShark for  wire-free, our emulator, the standalone mode will still work with the BlueShark and with  this interchangeably.  We did have one little hiccup when creating these and ordering these for DEF CON, it turns  out that just casually mentioning that you need a 14-pin, 0.5-millimeter spaced ribbon  cable adapter is not enough to make sure it actually gets ordered properly, so, you know,  lessons learned.  We managed to get it reordered, rebuilt, props to one of my colleagues who actually disassembled  half a dozen of these, and if you see one of these, if you come up, I'll show you, there's  a lot of tiny little components in here.  He took every single component off and resoldered it onto a new board with the right pin header,  and that's the board that's being used in Ottawa right now for the other side of this  demo, so appreciate that.  That was a lot of hard work, I know.  And then the other thing we added is a custom Android app, so to make it easy to interface  with the Proxmark, we created an Android app that will bridge the communication between  the FTDI and, therefore, the Proxmark and the Relay server, and it supports card or  reader modes.  You can alternate it, and it supports CLS and DESFire cards, and you can adjust the  frame rating values for your specific target, and it also will handle hardware resets, because  we came across a lot of those, so we needed to build that in to be able to quickly reset  and start over again, so it's quite easy to start over with that, but I will say it is  my first Android app, I've never done this before, and we kind of just went function  over style.  I know it's pretty ugly, but it works.  All right, so let's go over some of the results before we get into the demo.  So we've tested this on a variety of different HID readers, so the first couple are older  generation HID multiclass readers, the RP40 and the RPK40, a couple of different models,  but these are ones that will accept both low frequency and high frequency cards, so there  is some requirement for them to adjust the frame rating time, because older cards are  a bit slower, so it makes sense that adjusting them was a successful attack, but the one  that was a little more surprising was the Signo readers from HID, which are their latest  and greatest readers, and there's three variants of them, 00, 01, 02, and the difference in  those is the protocols that it supports, so 01 is kind of like your multiclass, it will  support the low frequency and high frequency, sorry, that's the 00, the 01, I think, is  the only CEOS protocol, CEOS and Dezfire, and then 02 is CEOS, Dezfire, and smartphones.  So that one's the one that to me is surprising that the frame rating time attack works on,  because especially for the 01 and 02, they're only talking to high frequency cards that  are, you know, fast, quick responding cards, there's really no need for them to have the,  to accept an increased waiting time.  In terms of the card technologies, most of our research was focused on CEOS, because  as I said, this was motivated by a specific engagement we were trying to get into a building,  but we have since, as of last night at 1 a.m. in the morning, acquired an EV1 card and compatible  reader and we're able to test and it does work for EV1 cards as well.  The other ones that we haven't tested with and we want to are the EV2 and EV3.  The problem with that is, so EV cards are not super common in HID access control systems,  and so getting an EV1 card or an EV2 card that is programmed with an HID secure identity  object, which is the object that they write in the card to, for the reader to unpack and  pull the identification out of, so to get a code, a card coded for that is quite challenging  and quite expensive, so we haven't come across those cards yet.  But the interesting thing about those is that NXP does have a patent for being able to do  the proximity check for communication devices, so based on that, these two technologies should  be immune to our relay attack because they should be able to detect the proximity of  the card, but it's something we would like to verify and try for ourselves.  In terms of distances, we started out in our lab just across the room 12 feet, one of us  took the readers home, went back from our house to the office, tried that, and then  as Sam mentioned, when I went down to Florida, I took the card with me, we relayed it from  Florida back to Ottawa, which is about 1,400 miles of distance that we're going across,  and then earlier today in the green room, we finally got a successful test of doing  Vegas to Ottawa, and I say finally got a successful, we just didn't have an opportunity because  production issues on the card hoppers, it actually worked quite smoothly, quite well,  so that's about 2,400 miles now we've gone.  Can we do it on stage, is that possible?  So I better text my colleague on the other side who's waiting for us to say we're ready,  so I'll tell them to join now.  We also would like to test this further, so if there are people here that are interested  in collaborating with us, if you live farther away, Brazil or other places that we can try  this out and see how far we can push this distance, come chat with us afterwards.  All right, so we are good to go, they're ready on their side, let's jump on.  Hello, I don't think the sound is working.  Welcome Noon and Liz to DEF CON, everyone say hello.  All right, so Liz is just going to demonstrate right now that she can't get into the door,  it's locked, right, and just presenting the reader that she has to the door is not going  to work because we're not relaying a card at this point, so if she puts it up against  the door, if you put the thing up against the reader, yeah, exactly, it doesn't work  because we need to relay the card.  All right, you ready to go, Sam?  Liz you ready to go, give me a thumbs up when you're ready.  Thumbs up, let's see.  I think we need to do a reset on her side, one sec, sorry.  This is what happens when we do it live, right?  She's working with the pre-production version, the one that my colleague put together by  hand, so it's not the most, you know, production ready system, so we'll give her another second  here.  All right, she's good to go, we're good to go, all right, go for it, Sam, put it closer  to the reader, yeah, all right, we're going to try it one more time, if not we'll switch,  just pull back Liz and cancel, we'll try again, give me a thumbs up when you're ready  to go.  If this doesn't work, we'll switch to the video of us doing it previously in the green  room just to prove, okay, I think she's good, and it's not working, all right, well, I guess  that's where we're going to jump to video, demo gods prove too much for us.  Thanks anyway, Liz, Noon, thank you, all right, so we kind of planned for this, that's fine,  so this is what it should have looked like, so when she puts it up to the reader, it does  take some time, because we're relaying these messages one at a time over the internet,  so it's not as quick as normally when you push it up against the reader, but after a  certain amount of time, it does work, and she can open the door.  So on the phone side, this is what you would have seen if you were looking at the phone,  so we connect the card hopper, card hopper is the term we're giving this board, we connect  it to the phone, we put the phone into reader mode, we don't adjust the frame waiting time,  because it's fine, and then we start seeing all the messages flying back and forth, you  can see there's quite a few of them going back and forth, we don't really care what  they are, they're right, they're fine, and that's the, at that point, we're done, we've  opened the door.  So yeah, I said we don't care about the waiting time, we default it to 14, which is the max,  so we're just leaving it at the max, and it's working fine.  On our side here, this is what you would see, so this was us in the green room.  So I put the card up against the reader, and wait, and it goes through that back and forth,  back and forth, back and forth, and then boom, we're done.  So it does take more time, it is a little bit more conspicuous, it's not necessarily  the stealthiest of attack, but hey, being able to relay a card from here, 2400 miles  away I think is pretty good.  So the other slide, a couple of other slides we wanted to show, the prevalence of the different  technologies.  So unfortunately, there's a weird trend in the access control industry that they don't  necessarily move to the newest technologies right away.  We're still using a lot of the old technologies, so the 125K HID proc stuff I mentioned still  has about 32% of the market.  Pretty small market percentage for the CEOS, and even smaller for some of the MyFair cards  individually.  But it's interesting to note that these technologies have been around for a while, like CEOS came  out in 2012, EV1 2006, so it's unfortunate that the industry has not adopted these as  quickly as they probably should have.  So the other point that we wanted to make was that most of the ones that are currently  in use, aside from the EV2, EV3, are vulnerable to some sort of attack at this point.  So most of the access control industry is still vulnerable.  So I also want to talk a little bit about HID's response.  So we did a responsible disclosure of this through BugCrowd.  We disclosed it to BugCrowd on December 9th of 2022.  It was triaged by HID on January 17th, and then we got their final response on March  10th.  I'm sorry, I'm just not showing the presentation mode, I should have switched back.  That's why.  All right.  So one of the recommendations we made to HID was that they should limit that frame waiting  time integer, not accept values over what are strictly necessary.  And they didn't like that idea because it would put them out of compliance with the  ISO spec, and it would impact their customers' needs for backward compatibility.  I don't know any customer that needs a five-second waiting time for backward compatibility, but  that's what they felt like.  The other comment that got to me a little bit was that the majority of their end users  do not see relay attacks as a viable threat.  That was the motivation for coming here today, for doing the additional work of creating  the pieces.  We wanted to show that this is a viable, feasible threat, something that could be done with  simple technology from the Proxmark, a small little add-on, and the relay server.  The one comment that they did make, which has, I think, some good validity, is that  their end users that are concerned will typically add a second factor, PIN or biometric, and  some will use their mobile credentials.  But the one problem that we see with this is, okay, now everybody has to enter a six-digit  PIN.  Can you imagine the lineups going in and out of that building?  Six-digit PINs or biometrics are good, but they're not always the most usable or user-friendly  especially when you're trying to manage large amounts of people going in and coming out.  All right, so that's the end of our presentation.  We have some extra of the little boards, the Cardhopper boards that we printed, the correct  ones now.  We also run the embedded CTF, so if you come play in the embedded Village CTF, the top  three teams will get one of those boards, so come and play.  If you're interested in collaborating, if you want to try testing this at further distances,  we're happy to share with you a card and a board, and we can see how far we can push  this.  Come chat with us at the site afterwards, and thank you very much.  Any questions?  Thank you.  They turn it back on.  OK, you asked whether there's a subset of protocols  that are supported by this.  So basically, any ISO 14443A, any technology  that uses that, which is most high-frequency cards,  they would be vulnerable to this kind of relay attack  because of that.  So the most common that we come across in access control  are CEOS and EV1, 2, and 3.  But I'm sure there are other ones  we're just not super familiar with.  Thank you.


url: https://www.youtube.com/watch?v=8cANuTuAkds
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
title:
  DEF CON 31 War Stories - UNConventional Cybercrime -  Bad Treaty Becoming Law - Rodriguez, Budington

content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=8cANuTuAkds",
    "title": "DEF CON 31 War Stories - UNConventional Cybercrime -  Bad Treaty Becoming Law - Rodriguez, Budington",
    "description": "Heads up DEF CON! The future of hacking, cybersecurity, and human rights are at risk as the United Nations negotiates a draft UN cybercrime treaty that has the potential to substantively reshape anti-hacking law around the world. The proposed Treaty could change the game for security researchers and coders like you. With Russia and China playing an initial role in pushing for this treaty, the future for security researchers\u2019s rights could be at risk.\n\nJoin us as we deep dive into the murky waters of these negotiations, exploring its risks for security and human rights, including the universal criminalization of network and device intrusion without any protections for legitimate security research. The lack of legal shield for security researchers could hinder bug bounties, responsible vulnerability disclosure, and pentesting. We'll discuss the geopolitical complexities, and the vital role you can play.\n\nEFF has been on the front lines in Vienna, attending the negotiations and representing the interests of our members since the start, and we need your help. Your insights and experiences are crucial. Together we will review the text, identify new challenges that you may face so we can better understand the community concerns. Let\u2019s champion together a future where security research and human rights can thrive!",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 1519,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230914"
  }

  This text was transcribed using whisper model: large-v2

   Good. Okay. Today we are going to talk a little bit about the work we are doing at a global  level, fighting a proposed UN cybercrime treaty. But before I start to discuss what's on the  text of the treaty, I want to give a little of how we end up with this treaty and these  global negotiations. So there is already a global cybercrime treaty. It's not global, it's  international. It's the Budapest Convention and has been the main existing treaty for  international cooperation, like one country helping another investigate a crime in  cross-border spying powers. It was finalized in 2001 and recently has been extended next year.  Next. Next. Yeah. And it has, we have been criticizing that treaty for many, many, many  problems. And Budapest has become the, the fact of standard for many countries. So  Budapest has like 64 countries, next, and many of the countries have already adopted many of  the computer crimes that are in Budapest. However, um, and many countries have also used it  as a model law, even if they have not ratified. However, some countries like Russia has  objected to the Budapest Convention because sitting concerns that it infringed on our  sovereignty by allowing other nations to investigate a crime in their own country. That's  one of the main reasons why Russia proposed a new cybercrime convention at the UN in  2017. At that moment, we thought this is not going to go forward. But in 2019, the UN  General Assembly adopted a resolution that create this ad hoc committee. Next. Um, okay, I  do it. This ad hoc committee, uh, tasked with the job of elaborating this proposed UN  cybercrime convention. And this proposal was put forward by Russia, Belarus, Cambodia,  China, Iran, Myanmar, Nicaragua, Syria, Venezuela. Many countries opposed it, including the  United States and the EU, and with concerns that this treaty could infringe on people's  freedom. Let's fast forward to, to 2002, and the UN just started the actual negotiations of  this draft treaty, with member states submitting some proposed steps. Russia having  illegally invade Ukraine in that moment was considered less than fully credible on  respecting sovereignty, which was his claim why the treaty, you know, didn't work in the  first place. But nevertheless, Russia got the ball rolling, and many of the proposals made it  to the first negotiating text. But geopolitics is always messy. And in 2000, as the  negotiation opposed it, many of the countries who were originally opposed to the treaty  decided to engage in the negotiations, and pursuing their own agendas. While forming alliance  in essential global negotiations is like necessary to get consensus and move, uh, move, uh,  proposals forward, it could also be complicated, because it could end up compromising the  standards of human rights protections. And regrettably, instead of progressing towards a  pro-human rights treaty, the current version of the draft, and it's called Zero Draft, which  was released two weeks ago, it's um, this, the first negotiated draft that is on the table, is  moving away from it. The Zero Draft has five chapters. One on criminalization, that we talk  about computer access, and all the color, color's crimes, and also a chapter on domestic  surveillance, cross-border surveillance, technical assistance, and proactive measures. The draft  convention has two articles on human rights. One article five, that will apply to the whole  treaty, uh, general one, and one on safeguards, that will apply only to the domestic powers.  Um, this article 24 is very weak, not even strong enough, but even those articles, uh,  some countries want to delete them from the treaty. Um, interesting enough, when it comes to  international cooperation, the previous draft made clear that human rights should apply also to  the cross-border spying powers, the international cooperation chapter. However, that was  removed. Um, during the discussions leading to this Zero Draft, countries such as India, Russia,  China, Iran, Syria, Egypt, and Tonga, have even proposed to delete reference to the  international human rights obligation, this article five, which is concerning, and even  objective on the language of the limitations of domestic spying powers, making it even weaker  than Budapest. So, why we care about treaties? Treaties are binding, uh, for the countries who  decide to sign it, who are obliged to comply with it, with them. Some treaty provisions  compel states to adopt certain laws to implement such obligations. They use child, uh, the  state shall implement, shall adopt domestic legislation. And some others will say a state may  adopt domestic legislation. Sometimes a state can make reservations and say, oh, I can  exclude from that provision only if a treaty allow it. It's not always the case. And this is  problematic because, uh, when you come and have a law discussed in Congress, most of the core  features of the treaty has already been negotiated. So there are little things you can do at  the domestic level. Of course, you will try to find flexibility, these flexibilities that  could, you could use to get better safeguards in place, or better protections for human  rights, or whatever you want to include in the treaty. But this is a sour, uh, it's, it's, it's  not always useful to have flexibility because sometimes it could be problematic for human  rights. For instance, the treaty doesn't compel states to adopt mass surveillance powers, but  also doesn't foreclose it. Meaning that if a state, like the USA state, will use the  particularity standard or the more standards to limit, um, surveillance powers, others could  decide not to do that. So that, that's why it's problematic to have too much flexibility. But  sometimes it could be good because you can have people trying to advocate for better  protections, especially when it comes to criminalization. Um, so right now, uh, we are, the  assembly in 2001, that's a little, uh, the general assembly finally provide a draft  convention to the treaty. There's six sections to negotiate. It was from March 22 until 2023.  And it's supposed that the treaty will be finalized in January 2024, but we don't know yet.  We will see. The coming negotiations is going to be in two weeks, August 21st, and we hope the  treaty keeps negotiating. I, I think there are too many red lines in the treaty to be able to  get a consensus, but we don't know. And so far, according to the timeline, it's going to be  finalized in January. So, why, uh, what we are doing here. So, let's discuss the chapter of  criminalization. A matter of time, I won't be able to deal with everything. We are not going to.  So, but, um, the treaty is very broad, and so we don't have the time with everything. But, um, one  of the main concerns is the crimes that are in the criminalization section. Usually these are  the core cybercrimes, and we call core cybercrimes in the U.N., they call core cybercrimes to  those who are computer access without authorization, illegal interference, misuse of  devices, interference of data, interference of systems, uh, et cetera, illegal  interception, et cetera. But, uh, before there were more than 30 crimes, so in that sense we won.  Many countries like Russia and China, but also many other, not authoritarian, but in the  middle were proposing fake news crimes and many other crimes that can criminalize a speech. Um, so  that's out of the treaty. However, there always is a loophole, and this loophole is called  Article 17, in which it compels states to adopt, to make a cybercrime, to make a  cybercrime, any other applicable cybercrime treaty that exists. Imagine, there is a treaty of  terrorism of Lyme, smuggling, narcotics, now they all have to turn it into cybercrime. And  that's all. Making something of Lyme and turning it into cybercrime is a problem because  many of the provisions of Lyme, they don't have problems like criminal liability by  intermediaries. They have not been fought, uh, under those, how these crimes will be  committed under which conditions. And so making this automatic translation could create a  lot of problems. So we are asking to delete this loophole. Um, but, um, what is more  important is that, uh, the crime have these articles of computer access without  authorization that you already know maybe from the CFAA. However, what is new here is  first, the older convention, uh, the Budapest Convention was ratified by 60 countries. So 60  countries have those crimes in their books. I don't know, many others may have adopted, but  it's not the 194 countries around the world. Meaning, by adopting this treaty, and if we  get consensus, all countries around the world will have these crimes. And it's not only that  it's a problem. It's that it also has an article on jurisdiction. When a state can claim  jurisdiction on the investigation of crime. And the real issue of this treaty is international  cooperation. Once all countries have in their books this crime, they can help each other  investigate a crime, and they can easily claim jurisdiction for the investigation and  extradition of a crime and extradition of the person accused. So, yeah, so Article 22 have,  you can claim jurisdiction if the offense happen which is territory. A state can claim  jurisdiction if the offense involve a national event, um, if you are not in the territory,  whether they are victims or perpetrators. Also, if the offense is planned outside, but  committed in their territory, or if the state is, uh, against the state itself. Um, let's make  a case to understand this. And a simple one first. If a security researcher from country A  without authorization access a database in country B, and country B has a jurisdiction  because the offenses happen within its territory. But if the researcher is a national, also  this country B, or target a national of country B, country B can also claim jurisdiction. And,  um, and even while operating from the United States, let's say, country A, country B can  still claim jurisdiction in, in those cases. And if there is multiple countries  investigating the crime, they have to coordinate. But they don't say how. And this is very  problematic at a global level when you have different countries with different standards of  human rights protections. So let's see a little more complex scenario. A security researcher  from country A, let's say a democratic nations, identifies a vulnerability and without  authorization, without rights, access a database in country B. Let's say country B is an  authoritarian regime. The database, which is unknown to the researcher at that time,  contains sensitive information about dissidents from country C, which also is an  authoritarian regime. So we have country A democratic, country B and C authoritarian. And  information about dissidents from country C. The researcher's intentions are purely  academic. But implications are political and sensitive. So what would happen here,  could country B would likely want to claim jurisdiction over the matter since the  unauthorized access occurred in their territory. Given the nature of the laws in that country,  they might paint the researcher as a spy or a foreign agent and demand extradition. Country  C would also be deeply concerned as their national data was compromised. Even though the  researcher has no malicious intent, the sensitive information possibly, the sensitive  information nature means that country C would likely also claim jurisdiction over the  matter. Possibly painting it as an act against the state, which is also another clause in the  article 22. If the researcher travels to country C for any reason, or if country C can somehow  apprehend him, country C would want to establish its own jurisdiction over the researcher.  Over the researcher, especially if country A, imagine the United States, don't want to  punish that person. Since both country B and C, that both authoritarian regimes have a  stakes issue, there will be a diplomatic tussle. And when there is diplomatic issues, it gets very  complicated and murky. The two authoritarian regimes might coordinate or even blame country A  for supposed espionage or interference. Country A, being a democratic country, would find  itself in a very difficult position. And depending on the international relationship, treaties,  geopolitical strategies of that country, country A might be forced to either protect or distance  themselves or even hand over the researcher to the country. So we are calling for article 22  also to be deleted. Because once you claim jurisdiction, other laws could apply to them. And  this is very mathematical also for the surveillance powers, because some countries' laws,  for instance, when claim jurisdiction may have laws that are very draconian and have very  little standards, it can create obligations on providers to localize data among other issues.  That will make it easier for them to access data. So I think I will pass to Bill about, but  just to make very clear, while these articles are already in the GFAA, we think that most  importantly, we need to have limitations here. And we need to make sure that computer access  without authorization means breaching a security measure that is done with dishonest  intentions, causing harm. And there should be a public interest protection for the public  interest. This article is not only applicable to security researchers. Many of the work of  journalists sometimes involve finding information that is very obscure on the Internet. But  it is public available. And if it's just using a simple tool to get access to information  that is public available, that could make them a crime. And then we have all these other  repercussions. The treaty itself is a treaty about international cooperation, meaning now  country, whatever country, can help the other country to investigate that crime. We are  fighting for dual criminality to make sure that the crime that is being investigated is a  crime in both countries, but that's not mandatory. Right now it's just optional. And even  two countries who are authoritarian regimes may allow each other to help each other  investigate a content related crime, a crime that is inherently illegal in international law.  Laissez Majesté, for instance, insulting the king. So they will use the whole surveillance  powers to investigate a crime that is that. For us, that's providing a legal, I think that  the treaty, what it's doing is providing a legal basis for authoritarian regimes to rank among, to  legitimize the illegal prices of international cooperation on crimes that are not worth it, or  should not be subject of criminal investigation. So I pass.  Thanks very much, Katica. So, as Katica mentioned, Articles 5, which kind of applies to the  entire treaty, and Articles 24, which applies to the new investigative powers with regards to  human rights, the human rights limits on the new powers that are delegated to states that are  signatories to the treaty. What we want to push are stringent limitations to the new powers on  surveillance. We would love to see the UN Cybercrime Treaty in general be just discarded, but  at the very least there should be stringent safeguards on human rights abuses that are  possible. One thing that we want is to set time limits on investigative powers and  surveillance. So if there is an investigation going on, then set strict time limits for when that  cooperation will happen. Effective remedy, which is when someone is targeted for  investigation, and they are targeted wrongly, then they should have the ability to then in the  future seek remedy, seek some kind of justice for what happened to them. We want to require  prior judicial review when a surveillance power is brought to the table. There should be, in the  country which is employing the surveillance technology, a judicial oversight that happens  prior to it actually being implemented. So an infactual basis for any crime that is being  alleged has to be a paper trail for why you think this is a crime that is being committed and  that there could be vetting on both sides and not just arbitrary statement that this is  happening by say an authoritarian regime forcing investigation on someone who is in the  jurisdiction of a democratic society. Finally, we want the investigative committee to  tell the public how often these new powers were used. Somewhat like a transparency report for  the amount that these new powers were used so that we know if there is massive abuse  happening, say mass surveillance. So we want these strong protections to be incorporated  within article 24 on the new investigative powers. So we want a new bolstered article  5 which applies generally to the convention and article 24 which applies to these new  surveillance powers. One of the things that's problematic throughout the treaty, the  zero draft, is the term competent authorities which is not defined. So in these  conventions you'll have a long text and the terms and definitions will be in the first few  articles. Article 2 in this case defines a whole slew of terms but not competent  authorities which appears throughout the treaty. And competent authorities could be  interpreted as prosecutors or law enforcement by countries which adopt this. So we want  that to be better defined and not to apply to say overzealous prosecutorial authorities.  And what should be most relevant for the DEF CON community is perhaps article 28. So  article 28 empowers the search and seizure of stored data allowing competent authorities to  compel those with device knowledge to disclose information about how to access data on these  devices. Say security researchers who know about a vulnerability in a device or network and  they are given, investigative authorities are given new powers to compel them to take part in  an investigative. This is open, the wording is open to interpretation but it can be  interpreted as forced disclosure of security vulnerabilities to government authorities. So  this is something that we at EFF feel very strongly about and also has to do with another  piece of pending international legislation which is the EU Cyber Resilience Act. And that's  another piece of legislation which may compel companies to report vulnerabilities to EU  regulatory authorities when there is a vulnerability that they know of. Basically it's  trying to rein in the irresponsible companies from not doing their due diligence with regards  to end devices and patching vulnerabilities. But the good actors in the space of cyber  security are reasonably terrified of this because vulnerabilities are very justifiably so  regarded as well kept secrets in the industry and they don't want to alert regulatory  authorities to continue the spread of information about a vulnerability before, for  instance, it's able to be fixed and pushed. So these are kind of, it's a new push by  governments to get information on vulnerabilities both in the UN Cybercrime Treaty and the  EU Cyber Resilience Act. So what is next? Next is the 6th session of the Cybercrime  Convention which will happen and will be attending in August and September and that is when an  intensive round of negotiations will happen around the text. We're trying to get these  protections built into the text of the convention and that will be incorporated into a final  draft if we can hopefully have some input on the process. Although they're not obliged to  listen to us in any way, shape or form. But then in January, February of 2024 is when it will  go into effect and there can be new signatories. But that deadline, January, February 2024  may be pushed back if there's not agreement in member states. So we're trying, we're trying  to stand up for users' rights and the rights of security researchers not to be criminalized  in the international forum and we hope that you will all follow this closely.  Thank you.


url: https://www.youtube.com/watch?v=NGhamH4_CZY
title: DEF CON 31 - Turning my virtual wallet into a skimming device - Borgogno, Barrionuevo
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=NGhamH4_CZY",
    "title": "DEF CON 31 - Turning my virtual wallet into a skimming device  -  Borgogno,  Barrionuevo",
    "description": "In third-world economies, cheaper often means more accessible. In recent years, there has been a growing interest in modern mobile wallet solutions that allow you to save money, make transactions, payments, and transfer funds to friends or clients with the help of MPOS devices. These small, durable, and simple devices can be used to read credit card information. However, these solutions have vulnerabilities that can be exploited. In this talk, we will provide real-life examples of money theft, credit card information skimming, Bluetooth communication tampering, and hardware hacking associated with these solutions.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 2537,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230915"
  }

  This text was transcribed using whisper model: large-v2

   Hi everyone. This is turning my phone into a scheming device and post solutions. We'd like to  introduce ourselves briefly. I'm Ileana Barrionuevo. I'm a security engineer and security  researcher at UTN. I am from Cordoba, Argentina. And this is Dan Borgogno.  Hi, uh, I'm a security engineer, uh, uh, security, security researcher. There are two tags if  you want to, to follow us. Uh, I work at Latus Seguros. We are trying to protect data and people  through a new type of risk, uh, risk management. Democratizing cyber insurance, saving  companies from bankruptcy after cyber attacks through advanced, uh, risk analysis. Uh,  this is the agenda. Well, we'll talk about why we chose these devices, these solutions. We  talked security concerns that we found and how we hack them by taking different paths such  as network traffic analysis, application analysis, Bluetooth, hardware, and so on. Go ahead.  So, what are, uh, digital wallets and what, what's the impulse and how everything is  connected? Well, digital wallets are a way for you to have your money stored in your, in your  phone. Basically you can receive money, you can transfer money, or you can do operations with  your money. Uh, the problem comes when you have a business, you want to receive payments from  anyone. For example, you're sending things and you are trying to, to get payments from a guy  that doesn't have the same wallet or may have a credit debit card. So these devices basically  what they do is they allow you to interact with the credit card information and to receive the  data that you need to make a payment. And they're connected through Bluetooth. These  solutions are widely available in Argentina so that's why we try to, to analyze them. And as  you can see, they are pretty common. There are a lot of, of devices that are out there. Uh, we  have very different, uh, digital wallets and all these devices have, uh, different providers.  You can see on the bottom that there is a lot of providers, VBoss, MagicBoss, Stripe,  Display, uh, amongst others. So, um, you need to keep in mind that you have the, the, the, the  manufacturer and the digital wallet implementator. And the one thing that you need to keep in  mind as well is that the attacker right now might be the digital wallet owner. So you have  this device, you have this business, you are trying to receive payments. When you are  receiving a payment you need to protect the client data from the guy that's paying and using  his credit card to, to give you money. So right now the attack surface, uh, it's a little  bit bigger and we would choose these devices to, to assess them. Is that in the first case  is that they are sending very critical information over Bluetooth, which is critical  information. So, uh, we might, you, you might know that Bluetooth, uh, 4.0 is very  vulnerable. You can do a shyhack attacks and you can do a lot of stuff with Bluetooth. So our  first question was, uh, how secure is this? It's really secure. You can really see the  critical information from the air or not. This is that difficult. On the other hand, uh, we  saw that, um, differently from the, the components or the, the inputs that have a specific  system embedded in it. When you're trying to use your mobile application with those devices,  you can control the, the data flow. You can control the payment process. And this is  really, uh, it's a big problem because right now you can try amongst other things to make a  reply attack. You can try a different payment. You can show the client, uh, one amount of  money and then charge it for a bigger amount or something like that. So we try to figure  out how vulnerable is that the, the, the critical owner, the, the digital owner can manipulate  the, the payment flow. And the third, third thing is that we have a really wide attack  surface. You can hack data entry. You can hack the hardware. You can hack the firmware. You  can hack the Bluetooth. You can do a shyhack over Bluetooth. You can have manipulation of  the application. You can reverse an SDK that, uh, uh, third parties provide to you to  integrate with your digital wallet. You can manipulate network traffic. There's a lot of  things you need to implement security measures on each one of those steps. So the attack  surface is really big. So as you can see this is a simple graphic, uh, all those are attack  points, right? So you can try to get the critical information for example in each one of  those points. So the other thing that you need to understand is what are the features that  these, those devices provide. Um, these devices, uh, allow you to read EMB which is the, the  chip from the credit card. You can read the MAC stripe information which is the black stripe  in the back of your credit card, your credit card. You can read NFC and receive NFC, NFC  payments. And those devices allow, uh, firmware update over the air. They receive over the air,  uh, key updates because I will explain later how the key system management works. And they  have Bluetooth, uh, low energy and EDR which is the 3.0. And they support pretty much  every, uh, payment standard. And you need to keep in mind that to understand, uh, what we've  done is that these devices encrypt critical information to be sent to the backend and the way  this is done is by a key management system, um, a protocol which is called the UKPT.  Basically what this device, uh, have is a specific key. You have a, uh, um, uh, wallet  provided. You have a master key and for each one of the devices that are going to the market  you will generate a specific key which is called the EPEC. And this key will be embedded in  the firmware and then for each transaction that we'll try to do, you'll try to generate a  new key, a session key, to encrypt this information and when this information gets to the  backend, Cypher with, uh, triple S, the backend system will try to generate the same key  based on the device itself and the transaction that is occurring. So there is no interchange  of a key but this is a Cypher, uh, Cypher channel between the device and the backend. So  after that the best, the transaction when, uh, it's, it's, it's get done. And the other thing  that you didn't understand is that critical information provides a lot of stuff. Amongst  them you can read, uh, Maxstripe. You can, uh, the Maxstripe is, uh, a stan- uh, it's a fixed  data. You can clone it. It's not something that you can change. Um, you have AMB data, NFC  data which is, uh, a specific protocol that allows you to make payments but they have, uh,  another additional Cypher link over it. Uh, I won't get into details but you need to know  that there's a different protocols and stuff that you can get from a critical. So moving on  to network traffic. Well, we started analyzing one of the cases, one of the application  vendors that interacts with this device and well, we intercepted the traffic. We actually  realized that we can read and modify any data traveling on the request and the responses. We  use Frida, Objection, Meet and Proxy, Burp Suite and well, any proxy. And we can control the  whole payment flow and we capture, we can capture the encrypted information that comes from  this device and we can try different use cases such as reusing data, reconstructing  information. Well, we have to break the SSL pinning so we use Frida scripts and running  with Objection and a proxy. And here we have the first abuse case which is data  reconstruction. We have seen that this particular application was managing information. We  have obtained information from the backend that wasn't used at the front end so we have seen  that. That is the encrypted information, the credit card number and the CVV and  expiration et cetera. But the backend returns the same information and non-encrypted. So  there you see the first A numbers of the credit card number and the GNI and the last four  numbers and expiration date. So, well, that data wasn't being used at front end so we  should try to reconstruct the complete credit card number. So how many attempts should I  do? Nearly 9,000, right? But to get these four numbers that we are missing, we should do  only 999 attempts because the credit card number follows a specific structure that can be  validated with that script for example, right? So we should do brute force and then we get  these four missing numbers and then we have the whole picture to make payments, malicious  payments. So even though the credit card data was traveling ciphered when the response for  each one of the payments came through, you can get this data to reconstruct any credit  card information. Um, well, this is a next obvious case which consists of reusing data. To  you KPT states that the key, the transaction key should be used once and then should be  discarded. So, what if we resend a request that has the encrypted information with this  key traveling in the request? What if we resend the request after a valid payment? It should  fail following the standard but here we have the process, we initiate the transaction, the  customer makes a payment on the device, we capture by analyzing the traffic, we capture the  request, the transaction goes well, it's accepted but then when the customer leaves the store,  we start it, we trigger another payment with our cards but then we replace the request with  the credit card information that is encrypted but we have saved it previously. And then we  make another payment. So you should keep in mind that there is a grey area between the  responsibilities of the device provider and the cre- uh, and the digital wallet owner. So  these things comes to get in the grey area that no one wants to take responsibility about,  the things that you should do and you should not do, do with the, the grey data.  And here we are positioned as merchants. We are the attacker merchants. So here's a demo of  the reply attack. So we have 2 phones with 2 different applications and we're trying to make a  payment from, on the first digital wallet, capture the data and then we open a second, uh,  digital wallet with a second device and we'll try to dummy, uh, credit card payment and then  we'll replace this credit card data, dummy data with the previous one and we'll, you will  see that we have a successful transaction. So right now, uh, everything's connected to  Meet and Proxy. Um, I already done a transaction. So the, the payment went through. So,  sorry, this is a first payment. Uh, already connected. I'm getting the traffic from Meet and  Proxy. I just received the encrypted credit card information from the first payment. And  again, don't bother about, uh, getting this data. Uh, it's all fixed so you won't be able to  use this data. But once the, right here I'm, I'm, uh, using a simple identification number  that you need in Argentina to make a payment. And you'll see that the transaction, it's  approved. So the client left the store, goes to their home, pretty happy. He paid 55 pesos.  And I'll turn off the Wi-Fi and leave everything on the side. And I use a different, um,  account in another phone. I'm getting the information, the green information that shouldn't be  used to, to re-send, uh, for another payment. And saving this data, just in a text file. Uh,  that's cipher data. You can see the key SN which is a transaction key, which allows you to  generate on the back end the new key to service data. And right now I'm turning the phone, uh,  Wi-Fi to make another payment. That's a dummy card. This, uh, it's already expired. And I use  it to make another, uh, initial payment. So right now I'm intercepting the traffic. And I  will replace this data. So turn on the device. Make another payment for a bigger amount.  That's about a dollar. And right now you'll see that I'll trigger the, the device. But I  will capture the information on traffic, on network traffic. I will replace the, the  information with the previous one. And I resume the, the traffic. And you'll see that right  now I need to, again, import all the data. This is not valid, so I just can input whatever I  want. And you'll see that the transaction went through. So. There, there are more things.  Wait, wait, wait. So you can see that right here I, we have, uh, the, sorry I was trying to  show you. Oh man. It was the second transaction and the wallet from the customer with a, with a  valid payment. Yeah, you can see right here we have the two payments from the same client.  And the second payment was never, never actually executed. It was, and it was charged. So,  going back to the presentation. Okay, well, let's move on to application analysis. We have  seen network traffic and now we are going to hook the methods from the SDK. It's the, the  SDK, sorry. And we have the SDK and the device interacting with the application. So, we try to  manipulate the objects, the instances related to the encrypted card information coming from  this. So, we are abusing TUKPT implemented here. And remember that we have this case in  which we cannot reuse the key because this was fixed. This was reported and fixed. We  shouldn't use again the same request. But encrypted card information shouldn't be used  again. So, we are the ones interacting with the SDK and the device. So, we can manipulate  and get as many keys and as many encrypted card information as we want. This was  theoretical. We thought about it last year. We tested this year and it worked. So, how it  works. We initiate a transaction. The customer is going to pay, taps the card on this device.  We capture that card, encrypted card information, right? And we try to make the payment  fail. So, in the second attempt from the customer, we are sending to you the previous card  information. And in this second tap, this second attempt from the client, we are capturing  also that information and we are saving it on memory. And then when the customer leaves, we  are going to pay again with this second tap that we captured. And the transaction will be  accepted. This is a little script that we developed to run with objection. We hooked the  method, the serializer that triggers the request that completes the operation, the payment.  And we enumerate all the instances related to the objects, the credit card information that  comes from here. And, well, we can save on an array or send to a server. And in the first  attempt, we are sending data in order to make the payment fail. And, well, that method returns  this first instance. And then we are sending the previous card information that we are  saving in each tap. And, well, we are sending information to a server if we want. And, well,  in order to understand this process, we have two requests. The first one that initiates the  payment. And the second one that completes that operation with an operation ID that is got  from the first request. Now in the demo, we are showing you the requests and responses. But I  wanted to make it clear that we are not manipulating the traffic. We are only manipulating the  instances at run time. We are manipulating and hooking the methods of the SDK. So let's start  the demo. Well, we are starting the application. The customer is going to receive the  payment. The customer is going to pay. We are pairing the device. This is the first tap. We are  capturing the information. But we are sending data in order to make the payment fail. Well, we  are completing the DNI for legal reasons. And then we are triggering the first request, starting  the payment with valid data. But the second one is GME data. Because we want to make the  payment fail. Right? So then there's an error. And we say the customer, hey, let's try it  again. We have captured this valid information from the credit card. And in this second tap, we  are capturing also the credit card information. But we are sending the previous one from the  first tap that we have captured. So completing again. Legal data. And then we are sending  well, starting the payment again. Because this is a valid transaction. We get an operation ID  which is needed to complete the transaction later with this second request. And then we are  sending the previous card information that we have saved. And this wasn't used. Well, we have  triggered now the malicious payment. The customer leaves the store. Really, really happy. Then we  trigger another payment. As an attacker. As a merchant attacker. And we are sending the  payment. We start the operation. We get the operation ID from the first request. And then we are  sending this previous card information from the customer. Which is encrypted. I don't need to  know what the credit card number is. So we completed a payment. So here we have a valid  transaction. And the customer will see a second payment. But just to clarify, we tried to  manipulate the price. But this was validated at backend. So the price was the first one that the  customer paid previously. So that was the demo. And the second one.  And well, just to, in order that you understand how the script is. This is a script running  with Objection. We are capturing the first tap. But we tamper the method. The situation.  And we send the data. Yeah. We are saving card information. We are linking it to a server.  And this is the second tap when the customer tries again. But we are sending the previous one.  Right? The first one. Well, this is the attacker tap. And we are sending the first one.  The second tap from the customer. It's a little, a little strange but we are sending previous  data. And the payment goes well. So, let's move on to Bluetooth. So, Bluetooth analysis. Uh, we  don't open all the devices. There are mainly 4. And all of them share pretty much the same  uh, Bluetooth chip. Which is the iChip YC1021. This, if you go to the data sheet, you'll see  that this device supports Bluetooth 3.0 and 5.0. And you might know that Bluetooth low  energy is quite vulnerable. You can do shy hacker attacks. You can do a lot of stuff. Uh, so,  we uh, we unloaded um, a test application that some of these providers uh, allowed you to  use. To interact with the device and to see if the device is working properly or not. Um, so  we hacked this application to make it work with Bluetooth uh, low energy. And we used  BiddleJack which is a tool that we love a lot. Using 3 micro bits connected to a USB hub. We  were able to sniff all the, the advertisement packets. And we tried to, we, we were able to  sniff uh, critical information from a payment. And you can see in the left there is the, the  application itself. Testing application. It will show you the same, the same information,  the same information that we sent to the backend. And will be deciphered at the end. And you can  see in the right, the wire shack analysis. And you can see the same information is being shown  on both sides. So we are, we, we are, uh, we are sniffing the same information that we've  been sent to uh, the backend. So the, the Bluetooth is not adding any uh, adding any  ciphering over the traffic. But, we will try to, to do the same attack against all the  digital wallets. We weren't able to it, to do it. Because, mostly because all of them use a  Bluetooth EDR which is the 3.0. And it's based on the pairing mesca- mechanism. So uh, to  see what is the, the data that is sending over Bluetooth EDR we were able to get the HCI  debug log from Android. And uh, doing, we run a lot of analysis over this traffic. And we  found out that the same data is traveling over the, the HCI. But, since a Bluetooth EDR is  adding another uh, layer of, of ciphering, you cannot get this information from just sniffing  Bluetooth uh, 3.0. And if you will, were able to do it, you'll need a really expensive tool  which we don't have. But doing just a little bit of research over these devices, uh, you'll  see that the first time you try to pair this device to your phone, you'll be uh, shown with a  numeric comparison. Numeric comparison is basically uh, a pairing method where you show  the same six digit number on the device and on the um, on the phone. And you need to  click accept on those devices. I don't know if you see what's the problem. You have, you  don't have any screen in those devices. You have no way to see or to know what are you  pairing to. So we tried to do a money to me attack. Uh, basically what we created is just a  very simple script where you, where you use a single Bluetooth adapter and basically doing a  Bluetooth analysis over the traffic. We found out that all the traffic information was sent  over Bluetooth with an SPP protocol which is basically serial over Bluetooth. It's just  transmit and send data. That's it. You need just one channel. So we emulated a channel and  we created a simple script which is trying to listen uh, based on a reg ex just to see if  there is a device that is turned on. Other thing that you need to keep in mind is that for  each transaction you need to turn on the device because it turns uh, off itself after three,  maybe five minutes. So for each transaction you need to turn it on and it accepts connection  from pretty much anyone because again, you don't have any way to pair it correctly with any  other, with any device. So uh, our script what it does is trying to start listening in the  air, it just connects as fast as it can to the device and then it starts emulating the same  device and provides the same SPP protocol. So that's the setup. It's pretty simple. You have  on one side the device turned on, uh Raspberry Pi with Python and then the device, the  mobile application will try to connect automatically to the device that we are emulating. So  this is demo. Um, this is one digital wallet. You can see right here that that's the, the  remote desktop for the, the Raspberry Pi. We try, we start the, the money in the attack. You  can see that it's already uh, saw the device, it's connected to itself and right now it's  emulating the same device. So I, I just uh, entered to the mobile application, uh, and  the digital wallet. I go to try to make a payment and right now those devices are paired but  you'll see that everything works pretty good. Right now you can see all the quick, the  drafting information between the application, the Raspberry Pi and the, the impulse  device. For now I'll try to make a payment and you can see all the, the information right  from here on the money in the attack. So, the payment mechanism doesn't allow you to know  what are you actually paying to. The device doesn't know who it's paying to and the mobile  application doesn't know. So what can we do with this? Um, with the money in the attack we  can do basically uh, create uh, max type, we can try to do a max type stealing. Uh, since  the device is connected from, from A1 you can try to do an over the air update or, or uh,  a back update which is the key that is itself. Or you can try to do a dual copy bypass which  is pretty much the same as Celiana shown but on Bluetooth level. You try to force a, a bad  payment, you try it again, you saw, save the data from the two, the, the two manipulations  and you send just one and the other it's already valid to make a second payment. But  I want to show you uh, a little big uh, a little thing of um, this is the second try that we've  done with money in the attack. This is another digital wallet and we tried just a, a small  payment and I know you, you might be able to see something quite interesting. Um, again, the  the car owner and the, the guys that run the store doesn't know that this is a guy in the  middle. So, right here you can see that everything is working properly. I used an NFC  payment and everything is working correctly. Uh, but it's just a little different, I tried the  max type. And again, this data from the max type, this card is already expired on the  wallet, but this information should be ciphered. There's no way this information is  traveling in plain text. Right? So, first another payment. And you can see right there,  this is the plain text uh, max type information from the air. So, basically you can go to any  site. You can go to any store in Argentina that you're using this uh, solution. Sit there and  start receiving critical information. You can go with this data and emulate a card with max  proof. That's pretty much it. So, uh, moving forward. Um, hardware analysis. Uh, we are not  hardware hackers, disclaimer. We're trying to be, uh, but these are the 4 devices that are  right now available in Argentina. We took them apart and we saw that they share the same  principles amongst all of them. You have the smaller ones which don't, doesn't support NFC  and the bigger one that supports NFC, basically. So, uh, what are the valuable points? I mean,  what can I get as a low level hardware hacker from this? Well, the first thing that I think is  really interesting to have is the critical information that is traveling on the devices. Um,  DMC or EMB tokens are also very data to make a payment. So, if I get this information, I could  go make payments. Uh, the freeware might be really interesting to find bugs and hack other  devices. Uh, the IP key which allow, will allow me to, uh, decipher my own data and they  may make, uh, another payment. Or maybe the UART logs will allow me to, to see a few logs.  That might be, uh, leaking important information. But you can see right here, this is, uh,  really basic. Uh, this is the connectors and things that you might find in, in these devices.  You have a Bluetooth connector, an EMB connector, we connect to a chip, a controller, um,  mag stripe which is pretty much a tape head connected to a level fire. And in the back, well,  you can see the level fire and the EMB front end. And of course the Bluetooth, um, I don't know  if I said it already. Uh, but in the bigger devices you might find, again, Bluetooth, a  microcontroller, uh, we found out that there's a flash memory. Uh, we suspect this, this is  where the firmware is stored. Uh, we have as well a tape head, a battery controller and an EFC  front end, of course, to interact with NFC. So this is something, this is a very basic  diagram on what are the, the main components that all these devices will have. So we went to  for the long-hauling fruit and after running a few analysis stuff later we found out the  device was still working, all open. So do you have any anti-tampering measures? And that's a  must. When you have a, a credit card or, or credit card reader or whatever payment system, you  need to have anti-tampering measures to avoid anyone to just hook in the data bus and start  stealing information. Why? Because you have clear text traffic between each one of the  cont- your, your components. You have the controller which provide, which provide you with a  little bit of, uh, cryptography but in the meanwhile, I mean, between the data is traveling  from the, the peripheral and the controller you have clear text traffic. So we went for the  long-hauling fruit and we tried to, to get the max-stripe information from a simple swipe,  which is pretty much like a common schemer. That's pretty much what it is. So, um, that's  the, um, that's the amplifier. It's connected to the tape head and we connected an oscilloscope  to the tape head and you can see in the right, in the left that you have a waveform which is  encoding for the credit card information from the, from the max-stripe and you can see that  the, the, the shape is very specific. So this is what we saw on the oscilloscope. Pretty much  the same shape. This data is on clear ta- text traffic. So, we got the data, we tried to  create a schemer. A schemer will try to get this data and transmit it over the air, whatever  we can. Disclaimer, this is overkill, of course. Don't, don't get angry. Uh, there's another  way to do this, I'll, I'll show you but, heh, we used, uh, BluePill which is an Arduino with a  specific chipset that allowed me to have really high rates of analog reads over the, the, the  data that is being sent between the tape head and the controller. And we were seeing all this  data on raw data over the Bluetooth which is again, overkill. And we were seeing this data  with, um, a Raspberry Pi connected to a Bombercat which is a device that amongst other  things allow you to emulate credit card information. So we created a little script for both  these things. Uh, Raspberry Pi will decode the data, will create, will create the, the  specific, uh, MaxPod data that need to be sent to the Bombercat over serial and the Bombercat  will emulate this data. So, uh, here's the demo. So, here's the test application. Here's the  open device. It's working right now as, as it is. Here's the, um, the hardware input  implant and that's the receiver. And that's another, uh, card, uh, credit card receiver.  Basically to see that the same information that we have sent are the same one that we are  emulating. So right now I'll try to make a swipe. And you'll see that all this information  right now has been sent over Bluetooth. This is all the, the data points and right now you  can see that right at the bottom that's the track 2 of the decoded data. And this data is  being sent to the Bombercat that is in the bottom. You cannot see it right now. And right now  I'm emulating the data and you can see that pretty much it's the, the same. Uh, not pretty  much. It's the same data, this track 2 that we were able to send over here. Again, this  overkill, uh, this way, easier way to do this. But this is what, uh, worked for us. And this,  uh, just to show you, uh, that the device is still working by itself. Right now you can see  that the, the hardware input, again because we are not hardware hackers, is creating a lot of  noises. Um, so when I try to make a payment, uh, of course it, it will fail but if I  disconnected the hardware input, you'll see that everything will work. Um, I just  disconnected the, the device and you can see that you're receiving the same encrypt data.  What this device is supposed to do when it's open, it should wipe out all the keys and you  shouldn't be able to cipher any data. So this is a big deal because, uh, you know if you're  paying, uh, even though the, the network traffic or the Bluetooth traffic might not be  tampered, you know if there is anything embedded in the device. Uh, so this is what the  schema implant looks like. It's quite big. Uh, it's huge. Uh, the receiver you can see on the  left and you can see the transmitter on the right. It's pretty big. But we found out that  there's another way to do it. We used a very simple 433, uh, RF transmitter. Connected  directly to the, the, the, the energy input of the, the same device. And we were able to, uh,  make a few swipes and transmit the same data over to our receiver. And you can see that's  quite small. The thing that we weren't able to decode this data correctly because there's a  lot of noises and these devices are not, uh, uh, not that good at transmitting, uh, uh,  really, uh, nice information over here. So the last thing that, uh, the last analysis, uh,  working on one of those, uh, digital wallet companies, we saw that using, you should, you  should keep in mind that it's a trust chain between the device and the backend. Because since  the same keys being generated on both ends, uh, all the data is trusted between each one of  the points. So, um, in most of digital wallets you have this, uh, fraud prevention systems  where you are trying to make a same payment over and over. And if it fails three, maybe four  times, your credit card might be blocked. So we were seeing that, that we, we, we heard, we  heard about a lot of clients complain about payments that they never had done. And we were  seeing that there was a lot of tryout payments for a bigger amount of money, um, and all  failed. And pretty much every payment was the same, the data from the payment, the credit card  was the same, but they were changing the CBV number which is a secure number embedded  inside the, the MaxStack information. So we tried to replicate this problem to see what the  fuck is, what is going on. And we found out that, uh, we, we created a MaxPoof, we didn't  have the, the bumper cut, uh, back then. And we tried the same, to do the same execution.  Just trying to change the CBV number. And we find out that the application behaved really  differently even though the credit card was blocked. The, the, the application behaved  differently if the CBV was correct, uh, or if it's, it is not. So if the CBV was not correct,  uh, the application showed you something and if it was correct, it showed you a different  thing. So, uh, the attacker, once he gets to the right CBV number, he waited for the  client to unlock his card and then he will go up there and make another payment. So this is a  problem mostly related to, uh, the trust chain between the devices and the gray area  between the responsibilities of the, the, the device provider and the credit, and the  digital wallet, um, the vendor. So conclusion.  Well, final thoughts. Companies should use encrypted end-to-end solutions that  implement anti-tampering measures. And it's important to read the manual to know how to  implement also the, the TUKPT standards in this, in this case. And reuse data should be  denied for no reasons. And it could be good if an expiration or a TTL could be added to, to  this encrypted card information in order that no one can reuse it later. So you, you have  seen that we can save the information on using another opportunity. And another way to  associate, um, with a signature or, uh, I don't know, something that associate the accounts  with the device and a device ID or the impulse information. And additional things that you can add.  Okay, um, one thing, uh, we, we think that one of the most critical things, uh, is that you can  manipulate data. So as Ileana said, we thought, we think that you should, uh, digital sign  everything that you're saying to the backend to make sure that the client is not manipulating  the data. That's really difficult to do. Sometimes you might find in Android that you can do  pretty much whatever you want with your application. Um, on the other hand, uh, you should  have any auto-bounce pairing method. Because again, these devices, if they, they intend to be  chipped and you don't want to add screen, you need to provide another way, uh, to avoid  man in the middle attacks. So auto-bounce pairing might work with those devices because you  can pair them, uh, with NFC for example. So that might work and there is no, no way for me as  an attacker to make a, a man in the middle attack as, uh, as itself. Um, or you can add a  device, uh, screen to the devices to just to, to be sure that you're pairing to the right  device. We think that this problem is quite, uh, quite dumb. I mean, it's really easy to, to  fix it, but, uh, it might be related to the, the implementation and, and the design of the  solution by itself. So these are the repositories, uh, the man in the middle is called  Prettyado. Um, the post, the, the hardware implant, again, uh, we are not hardware hackers, so  sorry if you see things that you might not like. And the current injection, current injection is  the repository for the freedom and objection scripts. And we would like to thank a few  friends of ours, Adrien Perroneo, Marino Marino, CodeHackerspace, and Joaquin Marella for  helping us and giving us recommendation and tips to how to do certain things. So thank you,  we're open to questions.  >>[applause and cheers from audience and audience members in the audience.


url: https://www.youtube.com/watch?v=4AY5uS3yFjE
title: DEF CON 31 - Track the Planet! Mapping IDs, Monitoring Presence in the Azure Ecosystem - nyxgeek
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=4AY5uS3yFjE",
    "title": "DEF CON 31 - Track the Planet! Mapping IDs, Monitoring Presence in the Azure Ecosystem  - nyxgeek",
    "description": "Microsoft Azure is ripe with user information disclosures. We are going to look at weaponizing these disclosures by performing data collection at a large scale against OneDrive, Teams, and Graph.\n\nOneDrive and Teams present silent enumeration methods, requiring no logon attempts and creating no logs. This enables enumeration at a massive scale against the biggest corporations, educational instututes, and government entities in the world. Over the last 1.5 years I have enumerated over 20m users. We will explore the techniques used and the data that was collected, including Azure adoption rates and analysis of username formats.\n\nMicrosoft Teams suffers from information dislcosure due to default settings allowing users to see the online presence of others. An undocumented, unauthenticated Microsoft Teams Presence lookup trick will be shared, which enables easy unauthenticated enumeration of the online Teams Presence of users at many organizations. To demonstrate this we will monitor approximately 100,000 Microsoft employees' online presence and any out-of-office messages that are stored.\n\nFinally, Azure supports Guest users, allowing two companies to collaborate on a project. I will unveil a method of identifying Azure Guest users at other tenants. In this way, hidden corporate relationships can be revealed.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 1916,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230915"
  }

  This text was transcribed using whisper model: large-v2

   All right. Hello. Welcome to track the planet. Today we're going to be talking a little bit  about user enumeration in Azure. And I hope to demonstrate to you today a little bit about  why user enumeration is a vulnerability and why it should be taken seriously.  So with that, a little bit about me. I'm Nick Skeak. I'm over at TrustedSec, but this research  is my own. This talk is about user enumeration. And there are no zero days being announced  here. There's nothing really like no hotness really except for some really just taking  advantage of things that are already existing. Microsoft knows about all of this. There's  nothing new being announced that's going to be a surprise to them. Well, maybe.  So first let's really just talk about user enumeration and why it matters. So what is  it? User enumeration is the ability to determine if a user is valid on a system. There's various  ways of doing it, especially in Azure. But some examples here you can see verbose responses  just saying if the user name is invalid or not. There's time based ones. Or you might  do one that's web based. Maybe it's a 404 if it doesn't exist and a 302 or a 401 if  it does exist. So there's various ways of doing this. And it is a security flaw. We  use it all the time in pen testing. It enables all of these different attacks, primarily  password sprays, phishing, and then the occasional targeted RCE that can affect users if you  have their email address. It's an unnecessary feature. It doesn't need to be here. It's  purely cosmetic. And then it also allows the identification of targets. Right? So we often  use first dot last name. We use our identities in our email addresses. So when that's possible,  it's possible then to not just identify a user name, like a numeric user name, but when  it's John Smith, you know that person's identity. You can find them. So this is a dangerous  thing because it allows all of these different attacks to happen. Especially with password  sprays. I just want to mention on this real quick. It is enormous. If you are on a pen  test and you can't do user enumeration, you're going to have a bad time. If you're looking  at like for instance J Smith format, if you're using census data from 2010, that's 4.2 million  lines. If you can reduce that to 2,000 lines or less, if you can find just the valid users,  now all of a sudden you're not wasting a day doing password sprays. You can rotate every  hour or as often as you can without setting their lockout off. So it's huge for that.  It wouldn't really be possible if it wasn't for user enumeration. It would be not worth  the time. And often if you've ever dumped a domain controller, I'm sure that you know  that there's always one or two bad passwords in there. I can count on one hand the number  of times that I've dumped a DC and not found anything that I was like, oh, yeah, that's  yeah. So instead of thinking about it like you're trying to guess the password when you're  doing password sprays, assume that there's going to be one out of those hundred top passwords  in there. Instead focus on finding the users. Because if you can get complete enumeration,  you can almost always find a weak password. So think about it that way instead of thinking  about it as trying to find the password. You're trying to find the user with that weak password  that we assume exists somewhere. So it really matters in Azure because everybody uses Azure.  Not everybody, but nearly. So in the Fortune 500, for instance, 99% have Azure tenants,  whether they use them or not. They might have just registered it. But out of those, 96%  had SharePoint enabled and I've identified valid user names via OneDrive in 89% of the  Fortune 500. So they are being used. It is widespread. If you look at state government  adoption, every state government uses Azure. This is so widespread. Everyone is affected  by things that come up in Azure, especially with the user enumeration. There are federal  government agencies that use Azure. Everything has the same vulnerability built in there  with OneDrive and other user enumeration methods. So who might not want to be enumerated, right?  Who might want to stay kind of hidden from view? There are a number of areas where you  think maybe we shouldn't allow them to make lists of potential cyber targets, right? People  that might be targeted with phishing, password sprays, et cetera. And it's not new to think  about user enumeration as a vulnerability. This has been recognized by many large organizations.  It shouldn't be the case that Microsoft makes the argument that user enumeration isn't a  vulnerability. And you can see that they don't take it seriously because if you look  from back even to 2014, that's a decade ago almost, that's when I believe the first exchange  time-based user enumeration was identified. There were multiple loans after that, you  can see. And it's just persistent throughout all their products because they don't consider  it a vulnerability. You can see this actually if you were to go to look at their bounty  page out of scope submissions and vulnerabilities, these are not in scope for submission. So  it's not surprising. I submitted the SharePoint OneDrive enumeration vulnerability to them.  And you can actually see they actually gave us a really nice verbose response. So the  parts that I want to point out are basically we would not consider it on its own a security  vulnerability and that it's similar to knowing a website IP address. And that's something  that's public, right? That's not something that's considered private information at all.  So that is their stance on it. It's not a bug, it's a feature. It's built in. So with  that, we arrive at stage one, user enumeration. So knowing that OneDrive can enumerate users  and it can do so silently via HTTP, it's just a head request and you can tell if the user  is valid or not, it's basically web scraping. There's no authentication attempt, unlike  graph and other methods where you have to actually try to make a login, which is sketchy  if you're going to try doing something on a large scale. But OneDrive doesn't have any  of those problems. You can use this and nobody can see it, except for Microsoft.  So there's a few different Azure enumeration methods. These are the popular ones that I'm  aware of. The graph one has a logon attempt made. It shows up in any logs. That's the  normal one that people will use to attack oftentimes.  Oops, sorry. My bad. So the next one down, seamless SSO, that's a quiet one, but you  get false positives with it. There's the team's presence, but you need to have the external  access enabled. We'll be talking about that later. And so we have OneDrive. OneDrive has  no rate limits, no false positives. It's simple. It's easy to script out because it's so easy.  You can, in fact, use Durbuster if you really wanted to, to do the same type of enumeration.  Now in order to enumerate a OneDrive user, there are a few things that you need to know.  You need to know the domain name and you need to know the tenant name. But you don't always  know what the tenant name is. Oftentimes it will match the domain name minus the TLD,  but that's not always the case. And in fact, a good portion of the time it's not the case.  And so that's an important requirement to doing the OneDrive enumeration, and thankfully  Dr. Azure AD, who is amazing, identified a way to do this. He published it in AAD Internals  and then Trevor Spray added it into their tool, which is also amazing and you should  check it out. And it identifies the tenant names using a Microsoft lookup service. So  I implemented these into my own tool, OneDrive Enum, and I started enumerating users and  I then added networking capabilities and just had basically a SQL backend and a bunch of  VPSs. For this I used Clue, which is not a codified likeness, but it's a cloud lookup  utility. And so that would just talk back to my Tron server and sync up word lists,  et cetera, and then you could run your enumeration on there. And I had, the original Clue crew  was only a small squad, but after about six months or so of doing this, I decided to go  a little bit harder and we upped it up a little bit. At one time I did reach 56, but  it was a little, that's too much. 40 was my running, and over the course of a year and  a half I was able to enumerate 24 million users. So these are users at the largest organizations  in the world. Not just limited to Fortune 500 and 1000, but I did specifically look  at those. So for reference, 20 million users, it's kind of hard to imagine, but it's about  the state of Florida or Australia or New York state. So it's a lot of users. So let's take  a look at some of the results of the user enumeration that I did. The total user names  that were found were 24 million. The unique were about 10 million. It took about 556 days  and I averaged around 40K or so a day. And this was with a small scale operation. If  somebody really wanted to do it, they could scale it up a lot. So this is, the total operating  budget for this, by the way, was about $5,000. So it's more than I wanted to spend, but it's  something that proves that it would be so cheap for anybody in the world to do this.  Now looking at user name formats, when you're trying to identify, oops. Okay. So I'm going  to try. So I don't know about this. Microsoft doesn't want this to happen. Okay. Well, let's  see what we can do here. So to identify user name formats, I used a survey script. And  in doing so, I would run a set of different user names against that. And then you can  get back the number of the matching formats. So for instance, here you can see J. Smith  was the top format. Let me just see if I can jiggle some stuff here. I might be able to  get it going. Oh. Well, so going through the different user name formats, I actually sprayed  this against all of the Fortune 1000 companies. And we can see overall what were the most  prevalent user name formats. We have John Smith as the top, followed by J. Smith, et  cetera. It's just kind of interesting to see. The one thing you have to realize, though,  is that this is probably not really perfect. You know, obviously there's more variation  in John Smith user name formats than there are in J. Smith. So it's going to be a little  bit skewed. John Smith is probably underrepresented in this survey here. One of the interesting  things that I identified when I was doing this is that I had originally assumed that  people would have one user name format, that it would only be the single one. But that's  not the case, right? Because you run out of user name space eventually. If you're starting  with J. Smith, you have to do something when you get that 2,000th user or so. And you can  do it a few ways. You can either go up in digits. You can add a format. You can switch  over from J. Smith to JJ Smith, for instance, something like that. Or you truncate it. And  those are the main areas that I saw organizations would move as they were doing this.  So I went through and I kind of did a catalog of that as well, looking at what combinations  were used. So you can see here that it's actually sorted also commonly limited by popularity  on each level. So the third and fourth lines down, they're basically the same thing but  flipped, right? So it's just kind of interesting to see the variations and how they fall out.  So looking at Fortune 1,000 companies, I just pulled these out specifically just so we'd  be targeting large organizations and not picking on anybody really small. But just to show  kind of what type of user enumeration is possible. And you'll notice here that a lot of these  actually are over 100%. And the reason for that is with OneDrive, you actually the user  URL exists until you delete the user and then you empty your recycle bin. So if you have  a long retention policy, that's going to keep them in there a long time. And or if you have  a high turnover, that would also super inflate your findings there. But at any rate, even  for an attacker, that reduces it drastically. So it's still worthwhile.  So in Azure, there are tenants and then there are domain or email addresses associated with  those tenants. There are some multi-tenant domain or organizations like Microsoft where  you can see they have their main Microsoft, but then they also have APC in Europe, etc.  And this is just the breakdown of the users I found there. I got about 126k in Microsoft's  main tenant on Microsoft.com. You can see LinkedIn is in there. I had forgotten that  they had acquired that. And then you can see actually there is a Microsoft APC or Microsoft  Europe. Yeah, both of Microsoft.com domains there. So you can see how they're actually  split up. So if you're an attacker, you could actually target one of those specific geographic  locations based on that tenant name.  So got phase one done. Does anybody remember what phase two is? We're going to do some  presence enumeration here. Stage two. So to do this, we're going to monitor teams. Before  we talk about that, I'm just going to give you a real brief timeline here about teams  and prior to that Skype for Business and prior to that Link and before that Office  Communicator, I guess. But they're all really the same thing. They're just incarnations  of it again and they label it new, but they all have the same problems. So here, it started  out with being called Open Federation and that lets anybody from anywhere message people  at your organization. That's back when it was Link. I just want to point out here, in  2016, Carl Fossum spoke about PowerSkype and attacking Federated Skype for Business at  DerbyCon. That was the first talk that I'm aware of where anybody discussed using presence  enumeration and he had a great tool for it there. They eventually did shut down the PowerShell  APIs that were on the back end, but it had a good run. So this problem with presence  enumeration is not new. I actually had a little side project here. I was going to release  it, you know how things happen. You don't end up getting around to releasing it. But  I was trying to prove that this is a problem back then. So I took a bunch of the CEOs from  the biggest corporations in the world and I would, you know, monitor their online presence  so you could look at a website and see if they're online or not. You could message them  directly because they have external access enabled. So that was just kind of a thing  to prove out that this is an issue back then. So this is not a new thing at all. Right now,  it's called external access and that's in Teams and it's the default setting to have  it enabled to let anybody speak with you. You can see it right there and you might recognize  it from an outlook. If you ever see a green dot show up next to somebody's email and you  have the Teams plug-in installed, that's what that is. So again, it's not a bug. It's  a feature. So one day while I was playing with Graph Explorer, I noticed that there's  a feature in there for presence lookups. So you can look up somebody's presence and you're  using unauthenticated, you're on the outside and somehow it was doing the presence lookup  and I was like, wait, that's kind of weird because you need to be licensed and you need  to be logged in to do that. So I started playing with it in Burp and it turns out there's a  weird bearer token set and if you're familiar with bearer tokens, that is not a normal bearer  token. So I went digging around and lo and behold in the source code, they have a bypass  to make anonymous presence lookups. It's on GitHub even. And so here you can actually  see they're proxying the graph request through graph.office.net. So with this, if you have  the UUID, which is that last item there on the right, that long string of characters,  if you have that for a user, you can check their presence via this lookup. So, enter  team filtration. So this was released last year actually at DEF CON 30. And you can use  it to enumerate teams. Microsoft messed a little bit with the external access enumeration  but you can still do it if they have external access enabled. Prior to that, you could tell  even if they didn't have external access enabled, you could still enumerate them. At any rate,  what we're looking for are the GUIDs that they can look up for teams. So we can now  pull down a list of users' GUIDs and using that previous trick, we can start looking  up their presence without having to worry about any authentication or not using an actual  account or anything. So you can do this purely anonymously. Now beware, there are limits  on this, right? There are rate limits on this. And so keep that in mind. There will  be a tool drop later. If you're looking for it right now, I'm sorry, it's not there. It  will be later today. So keep your eye out for it. My Twitter handle will be out later,  so check that. Now, so what should we do with something like this, right? This is pretty  cool but what should we do? We should track a company. And who better than Microsoft,  right? This is their feature. They've enabled it by default on everybody's. They have to  know how it works. And if they don't, who can be expected to know how it works? So I  don't really feel bad about doing this because it's their feature that I'm demonstrating.  So I started doing some monitoring around April 28th. And I started graphing it out  and it's kind of neat, right? You can see their daily activity throughout the day, how  many people are online. And it was great. I submitted to DEF CON. I was like, yes, this  is going to be good. And then a week later this happened. I was so bummed out. I was  like, okay, this is going to be way more complicated now. I'm going to have to spin up an Azure  tenant, blah, blah, blah. But I waited and a month later it came back. So I don't know  what happened, but things are working again. And you can now do this. I'm going to be,  I'm actually not monitoring that anymore, so you guys are free to use this and not worry  about the rate limits. Yeah, so here's something interesting that popped up one day. Any guesses  on what this is? It's an all-hands meeting there for just a little bit. And you can actually  see two of them, right? There's one for probably in the Americas and probably one for overseas.  There's actually, you can see a Microsoft Build event there where they announced that  and then the two days that they're actually out there and busy on those days. I just want  to put this up here for a second while I take a drink of water. So you can also draw heat  maps. You can find out what day people are active, how many available users are active  on any given day. And you can actually see, I think the 4th of July this week being on  a weekday, I think that messed with people taking off. People were still checking their  phones, you can see on the holiday. They were more off on the weekend before. But yeah,  it's kind of neat. And on Fridays, of course, look on Fridays. Summertime. So I took all  their out-of-office messages too. These are also all available through the presence lookup.  So Team Filtration will do this. Yeah, so I've got all their out-of-office messages  and just kind of, it's not very useful, but it's kind of neat. But, so back to identities  and emails being linked, right? So you can go on LinkedIn, right, and find members of  the Microsoft security team. You can then enumerate their email addresses and pull them  up to make sure they're the right one. Because teams will tell you their display name. So  you can verify that that's actually who you're looking for and not just somebody else named  Jay Smith. So if an attacker were to do this, there are a few things that they might be  interested in, right? Are they online right now? Who's on vacation? Who's out of office?  Who should I call to talk to that person that's out of office? And then the other thing is  it doesn't even have to be an adversary. This could be some marketing person that wants  to reach somebody when they're at their desk. Just find out what their schedule is and now  I know that they're going to be there right now and I can email them. So the other thing  is that even if the usernames were completely anonymous, right, you can still tell a lot  about somebody based on their schedule. Like when are their normal hours? Are they a night  owl or are they up in the morning? What holidays are they taking off? Are they taking religious  holidays or are they taking holidays particularly to one nation? Even if you used numeric usernames,  you could still identify a lot about people by putting a game of 20 questions there, you  know, figuring out this or that, this or that. And you can really narrow down who that could  possibly be. So that was the end of that one. Stage three is the really interesting part  guest enumeration. So just real quick, know that it is possible to enumerate guest users  in Azure so you should consider any guests that you have to be public information. Real  quick how it works, right? You invite somebody to your tenant in Azure. Beware. So anything,  I'm going to show you some stuff here. These do not imply business relationships. Anybody  can invite a guest user by default, even other guests. So if, you know, if you invited  me to your tenant, I can then turn around and invite a random third party to your tenant  because that's the default setting there. And I don't know how many people actually  go through and change that. But I'm just telling you, that's what it is by default. So there's  a lot of like ambiguity here about relationships if you're trying to infer them by looking  at guests, guest users at an organization. But on the other hand, if you see that there's  like maybe 30 or 100 guest users at an org, that might not be just a coincidence. So it's  actually, this is all out in plain sight too. So if you go log into the Azure portal and  you go to a guest account and you pull it up, this is the user principal name you'll  see. And it's not too hard to decipher what we need to change, you know, from the email  address to get to that user name. And because user enumeration isn't a vulnerability, it's  a feature. So I have to say, Dr. Azure AD is the first one to discover guest enumeration.  I ran across this and he actually found it four years ago. So this is not new at all.  Not new in the least. He didn't make a big deal about it and it was kind of published  midway down. And I also think the other reason this hasn't received much attention yet is  that this will not come up on a pen test. This is not in scope on a pen test, right?  I can't try pivoting to another tenant there, so why would I even care if I can enumerate  users there? But it's been possible this whole time. And so I'm rather certain that people  are using this already. Why wouldn't they? You know, it's been out there. There are various  ways of doing this, so why wouldn't people be doing this already? So keep that in mind  while I show you these next ones. So real quick though, I'll show you how it works,  right? This is how simple it is. How simple. You can do it from a browser yourself if you  know what the email address is. So on the left, that's an invalid one. Fake user underscore  domain dot com exd Microsoft dot on Microsoft dot com. So that's Microsoft's tenant there.  Microsoft dot on Microsoft dot com. You can see on the left side, I'm showing you some  valid user. You get redirected to a sign-in page if it's a valid user. So you can tell  immediately. You don't even need to authenticate. You're simply entering that user name there  in that sign-in page. So another tool drop that will be out. There's another method of  doing this too that I identified, which is via graph enumeration. So the same enumeration  method that we use for, you know, other enumerations that are interactive. Same thing works there.  There are a few differences though. Graph-based user enumeration is an authentication attempt  against graph, but you can't log in this way. So even if you have the valid password, it  won't let you in. It won't tell you if it's a valid password or not. Nothing about it.  It's not possible to log in via this avenue with that guest account. So it's not really  a log in attempt, but if you decide to use this method, just keep that in mind. In the  tool, the password is set to a really long GUID so that it won't be any chance that somebody  actually has that password, but you can't leave the field blank. So it has to be there.  Just be aware it will show up in logs and defunders. If you see this in your logs where  you see a failed guest EXE log on your account, don't be alarmed. You can't get in that way,  but do know that somebody's found out about that account.  Now what can we do with this, right? If only we had a giant list of usernames from somewhere.  Then we could do something interesting. We could try identifying some partnerships between  companies. So I started by looking at, you know, going to Google, say, okay, so-and-so  partners with blank. Who comes up? Let's look at that. So took a few consultant companies  and I got some hits back. Okay, this works. For real. I can prove it out that it's actually  actionable attack in the real world. This is not just, you know, an idea. So this is  what 30,000 guest connections between companies looks like. So these are a lot of big companies  in America. Now this one is in color code. I left Microsoft in there because, again,  this is their feature, but I'm going to show you here in just a slide or two here, but  we identified guest accounts among all these giant organizations, ones that maybe they  don't want people knowing who potentially, you know, right, because we don't know for  sure if there's actually a business relationship there, but potentially could be because of  this guest relationship. Now one more sip of water. Where was I? So let's look at Microsoft's  guest relationships. I've taken out all the names. I'm sorry. Not going to be that fun,  but you can see the diversity of relationships there. Now any of the blue ones are where  Microsoft has guest access to. Any of the red ones are where that entity has guest access  to Microsoft. Now by default, you know, they might just have guest access and no actual  group membership, et cetera, no special privileges, but they are there. Any of the green that  are interconnected are in between partners of Microsoft that also have a connection to  Microsoft. So you can see between various entities there, and then the larger it is,  the bigger or the greater number of connections there are to that node. So that's what you're  seeing here. Now, again, this is Microsoft's stance. This is pure user enumeration. Nothing  about this is an attack. This is user enumeration, pure. So I want to focus on Microsoft, but  to show like the width of this and how it affects everybody, I'm just going to show  you a few other large companies here. So for instance, here's Metas. You can see. We've  got Tesla. Might be interesting. Again, I apologize that it's not more juicy, but here's  a company named Palantir. I don't know if anybody's heard of that one. Remember the  blue says that they have guest access to that tenant. So looking at the most widespread  companies, I'm just showing you a few of the top ones here that I found the most connections  to organizations, and these are distinct hosts that they have connections to. You can see  a bunch of consultancy companies there. Not too unusual. But so speaking again about users  and identities, right, and enumeration, with this type of information, we know the email  address that's there, right? So we have their identity oftentimes. So you can actually do  some deeper digging and give it some more context with what years these guest relationships  are active because almost nobody cleans up guests. They almost always just leave them  out there and maybe they disable them or whatnot, but they almost always leave them there. So  you can at least see when they are. The oldest one I identified personally that I verified  was like 2018. So that's a little ways ago. So how does this matter, right, for attackers,  right? If you're looking at these guest relationships, now all of a sudden if you're trying to hit  a hardened target, you might want to say, hey, let's see what we can do around these  peripherals. Can we compromise another tenant and see if we have any access? It might be  a fruitless effort, but it might be something. So I mean, this is providing a roadmap to  allow attackers to identify their next steps. And this is pure user enumeration, right?  Not a vulnerability. So one of the last things I want to say is that this is a U.S. adversary's  dream, right? You have nations that love to do data collection. Do you think that they're  not doing something with this yet? Do you think that they're just letting this sit out  there because it's not ethical to collect this? I mean, look at these different industries.  All of America is tied up in this, right? State governments, federal corporations. And  if they don't take this seriously, they're not going to fix this. They're going to let  this sit. And this isn't just like a short-term investment. This is a long-term investment.  Names are durable, right? How many times do most people change their name in their life?  A couple times, maybe a few. But most people don't change their names very often. So once  you make these lists, they're valid for a long time, right? They might switch organizations,  but that person's name, you still have that. You can make permutations out of that and  try those other places. So I mean, this isn't something that I think we should let. Is this  something that we want? You know, is this how we want to have our stuff run? I think  that we should maybe recommend, politely, that they take this a little more seriously.  I mean, so we've demonstrated that it's possible to get 24 million users out of Azure. We've  demonstrated 100,000 users every 30 minutes, so twice a day. That's a huge number of requests.  We're able to do that. We can monitor an entire company as big as Microsoft. We can select  out users from there and monitor them exclusively if we wanted to on an even finer, you know,  rotation. And we've shown that we can do guest enumeration, right, between different companies.  This is all user enumeration. This isn't an exploit, at least not by Microsoft's stance.  This is all just user enumeration. So I just want you to remember, though, in closing,  that I am just the messenger here. I'm just showing you what the logical conclusion of  this is, right? I'm not anybody special. I'm just some dude that, this is basically  sysadmin 101, right? I made a SQL server. I still have servers and I had to report back.  I made a Python script. It's not hard stuff. And it only cost me about 5K, right? If you're  a nation state or somebody who really wants to invest in this, you can do something much  bigger than I did. This is just like a hobby that I did in spare time to try to get Microsoft  to fix this. And that is why I did this. I want Microsoft to fix this. I don't know how  else to go about it. We've talked to Microsoft and they don't take it seriously as an issue.  So at this point, I just wanted to share this with you so at least we can all be on the  same footing and know what's possible out there. So with that, some shoutouts. Dr. Azure  AD, TechRomancer, Carl Fawson, he's awesome, RootSecDev, Flagwick, and then everybody at  TrustedSec, of course. These are some links to the different tools. The last two will  be out later today, so just keep an eye on that. Follow me on Twitter. And thank you  so much.  Thank you.


url: https://www.youtube.com/watch?v=xweVuSEC8ZI
title: DEF CON 31 - There Are No Mushroom Clouds in Cyberwar - Mieke Eoyang
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=xweVuSEC8ZI",
    "title": "DEF CON 31 - There Are No Mushroom Clouds in Cyberwar -  Mieke Eoyang",
    "description": "This presentation will discuss the history of cyberwarfare, highlighting the misconceptions between nuclear deterrence and the nature of cyber conflict. It will shed light on this association in popular culture, including in movies like \"WarGames,\" which influenced then President Ronald Reagan and fed his concerns about potential hacking into U.S. weapons systems. These concerns and other influences helped to shape early perceptions about the cyber domain, which immediately became intertwined with notions of strategic weapons and catastrophic effects. In subsequent decades, continued theorizing about cyberwarfare envisioned strategic cyber attacks that could cause decisive effects, stoking fears of a \"Cyber Pearl Harbor.\" However, the reality is that cyber operations are ephemeral and cyber effects are hard to attribute and are rarely decisive. The turning point in U.S. cyber strategy occurred in lead up to the 2018 midterm election, with the adoption of a new approach focused on defending forward, which involved actively disrupting malicious cyber activity before it affected the U.S. Homeland. This strategy was further informed by Russia\u2019s 2022 invasion of Ukraine, which demonstrated how cyber capabilities may be used in large-scale conventional conflict. Looking ahead, in terms of protecting Americans and strengthening our global Allies and partners, we know that private industry and individual volunteers will play a critical role, including many of the participants at DEF CON. This recognition acknowledges that cyberwarfare is pervasive and requires collective engagement.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 1077,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230917"
  }

  This text was transcribed using whisper model: large-v2

   Thank you.  So one December day, in the middle of a global pandemic, the world learned about a fairly  sophisticated intrusion into an enterprise management software system known as SolarWinds.  And when we discover that, the media environment and the cybersecurity community, national  security community, went into overdrive talking about this intrusion.  One senator called this equivalent to an armed attack.  One commenter, summarizing all of this, said that this incident hit every single one of  our nightmare scenarios.  That commenter was me.  Commenting from my lockdown living room in the middle of the pandemic.  I'm Mika Ouyang.  I used to be a think tanker where I did a lot of work writing about cybercrime and cybersecurity.  And after this, with all of this hype, a few weeks later, I came into government as  the deputy assistant secretary of defense for cyber policy.  I am the senior civilian policy official in the Department of Defense.  You might have heard of us.  And I had to deal with this incident, how the government was going to respond to it,  and then subsequent attacks like the intrusion in Microsoft systems and Colonial Pipeline.  And one of the things that I had to wrestle with was the consequences of that rhetoric  that we had talked about in the national security community to describe cyber incidents.  And one of the challenges that I discovered is that a lot of the mental models that we  use to describe cyber incidents don't actually map to our lived experience in the cyber domain.  And so, you know, really sort of wondering, like, why are we so off?  Why are the ways in which we talk about these things so different from the reality that  we experience?  And frankly, that rhetorical difference inhibits a useful policy conversation about how we  respond, how serious and big these things are.  And one of the things I realized is that national security people tend to talk about  these things in the frames that they understand.  And so, you know, I did that too.  I had been a professional staff member on the House Intelligence Committee.  I had responded to the buckshot Yankee, Operation Buckshot Yankee, which some of you may remember  from 2008.  I thought I understood cyber and the ways in which we as a national security community  talked about it.  But as I said, the ways in which we've talked about it have not actually been that helpful.  And there's a huge difference between cyber war and then cyber in war.  So I want to talk to you guys today a little bit about where those mental models came from,  how that differs from our experience and how we see that, and then what that means for  us going forward.  So let me start at the beginning.  Some of you may be familiar with this screen grab.  For those of you who are not, ask your parents about the movie War Games.  War Games was a movie where a young intrepid hacker, for those of you who were too young  to remember this, breaks into the Department of Defense's nuclear command and control systems  and demonstrates that the world could be destroyed through mutually assured destruction.  This movie is really sort of the start of not only cyber security but a number of other  things for the Department of Defense, including when President Reagan sought a recognition  that we had to engage in arms control negotiations with the then Soviet Union, but also his recognition  that hey, some of our sensitive DOD systems might be vulnerable to hacking.  And so when the Department of Defense stood up its first cyber command, we stood it up  as subordinate to U.S. Strategic Command.  And that subordination meant that the ways in which Strategic Command thought about the  management of nuclear weapons, which was their main mission, infected a lot of the ways in  which we thought about the cyber domain.  So concepts like mutually assured destruction, some of these concepts about mutual hold at  risk, the idea that you could do something to the adversary the same way that he would  do it to you, really guided a lot of the thinking around how the Department approached  cyber.  And I know that term is like fraud.  But it really shaped a lot of the ways in which we thought about it.  And so as time went on, we still tended to view the cyber impacts at the high end of  the national security threats that we experienced.  You heard language and DOD officials talking about a cyber 9-11 or a cyber Pearl Harbor,  thinking that it was going to be this kind of big attack that would change society and  leave everybody in darkness.  And so we thought about it in those terms.  But we thought it was going to be like the end of Mr. Robot season one, like everything  goes dark and there's chaos.  And then also for the Department of Defense, as we thought about that activity, we thought  about it in terms of war.  Which meant that we were thinking about it just in terms of like what crossed the threshold  for the Department of Defense as an armed attack?  What would be the trigger in cyber that would bring the rest of our capabilities to bear?  And in doing that, we didn't really think as carefully about a whole range of activity  that was happening every day in the Internet domain, espionage, criminal activity, hacktivism.  There were all kinds of things happening that were not rising to the level of the Department  of Defense and everyone was like, when is the Department of Defense getting in the game?  But our experience in sort of cyber war and the people who like very, you know, were working  on thinking these things through, sort of a hypothetical, the hypothetical didn't match  the reality of what we were experiencing, what we have subsequently learned.  So if you think about 2017 and the cyber attacks against Ukraine by Russia that were significant  disruptions to their electric grid, there were significant disruptions to their critical  infrastructure and people said, this is cyber war, this is the kind of attack that we are  expecting in the cyber domain.  What we learned in 2022 is that cyber attacks are actually not the same, like cyber war  is not the same as cyber in war.  And the cyber attacks against Ukraine's critical infrastructure were not nearly as devastating  or impactful as the kinetic attacks that Russia launched against Ukraine in their attempt  to take the entire country.  Kinetic war and cyber's use in kinetic war is very different than the ways in which we  were talking about cyber war.  And I don't know if you remember at the beginning of the conflict, everyone's like, where's  the cyber war that we were promised?  Is cyber the dog that didn't bark?  And part of the challenge of that is like the national security rhetoric around this  meant that we had been conditioned to expect that when that dog barked, it would blow out  our eardrums.  But actually when the dog barked, it barked at the volume of a normal dog.  Cyber did the things that cyber could do.  It just didn't cause the Ukrainians to like roll over and say, okay, fine, take our country.  It was not going to do that.  There are many other things that affect people's calculus in the context of an armed conflict.  And indeed we saw, right, the cyber attacks that the Russians launched against Ukraine  at the outside of the conflict, even some of the most sophisticated, like the disruption  against the Viasat satellite communications network that had spillover effects into NATO  countries was not sufficient to overcome Ukraine's will to defend its own territory and the resilient  mindset that they displayed and their ability to look to commercial solutions to continue  fighting their fight.  So what that tells us is that it's not about cyber deterrence.  It's not about this cyber for cyber, we, you know, cyber pew pew, your networks, you cyber  pew pew ours.  It's now for us about integrated deterrence.  We think about these things in the context of how can cyber as one of the tools of national  power support all of the other things that we do in the cyber domain?  So how do we ensure that we can use cyber to defend our cyber terrain in air, land,  maritime, space, and then what are the options that we have to use cyber in those other places?  And it may be that we respond to cyber things with other tools, with sanctions, with law  enforcement actions, with diplomatic demarches and very, very angry letters, but it may be  that we also respond with kinetic attacks depending on the range of things that we have  and what is needed at the time.  So as we think about some of the challenges and what we've experienced, we've learned  some things based on our experience of how cyber is different.  And one of those things is about moving at the speed of cyber.  We have always assumed that cyber domain moves quickly because technology moves quickly,  the attacks come quickly.  And so we often have people asking us, like, you know, can you just give me a cyber option?  Like tank, whistle me up an exit.  And the thing is, like, you can't just, like, as you all know, tap your fingers on a keyboard  and then have something happen on the other side of the world.  It takes time and preparation.  It takes understanding.  It takes engineering.  It takes coding to be able to accomplish things.  And so it's not what I think a lot of people expect about how quickly we can move in the  cyber domain.  And in fact, I really appreciate the academic work of a guy, Lennart Mashmire, who did an  analysis of Russian cyber attacks against Ukraine in the run-up to this conflict, and  he talked about the cyber trilemma and these concept of speed, intensity, and control and  how these factors play off against each other, and you can't optimize for all three, right?  It's like good, fast, cheap, pick two.  It's speed, intensity, control, pick two.  And so when you see an incident like NotPetya, you see something that was developed relatively  quickly, had a pretty large intensity level, but spun out of control.  And so for us in the Department of Defense, we're going to optimize for control.  There are elements of control about making sure that you don't get caught, about doing  exactly what you intend to do and no more, to not spill over.  That's one of the things that we optimize for.  You know, we spend a lot of time investing in precision, precision weapons and all those  other things.  It's a lot different in the cyber domain.  And so not only are we optimizing for control, there are rules that we, the Department of  Defense, have to follow.  There is no cyber asterisk on the rules under the laws of armed conflict.  There are certain things that we would not do via any means, poison civilians, things  like that, intentionally trying to inflict harm on civilians.  If we're not going to do them via kinetic means, we're not going to do them via cyber  means.  Unfortunately, I don't know how well understood that is globally around the world.  Frankly, there are some countries that maybe aren't even living up to those obligations  in the physical space.  But for us, there are rules that we are going to have to live by as we think about armed  conflict.  And so we are reflecting all this in our 2023 cyber strategy, which we hope to roll out  publicly soon.  We've released a classified version to Congress, so they're going through it.  We hope to be able to talk to you more about it shortly.  But another one of the things that's changed for us that we reflect here is how we think  about cyber offense and defense.  Historically, the Department had thought about cyber defense and really prioritized it as  how do we defend the networks that we own and operate?  And we would think about how do you defend all the things all the time?  But the challenge is, of course, the number of attacks we experience are so numerous,  so pervasive by so many different actors, you can only hold the door for so long before  the attackers make it through.  And so you have to adopt a more resilient approach.  And because we can't be everywhere all the time, we have to think about new ways to defend  the nation.  We are not going to seek to be on all of the private sector networks all the time.  Frankly, we can't afford the personnel costs of that.  But also, who wants an E4 showing up at your network being like, hi, I'm here from the  Department of Defense.  I'm here to help.  So we have to think about different ways of doing that.  And so one of the things that we can do is take the insights that we have as the Department  of Defense about the adversary's TTPs and share them out with the world through partners.  And so we work with other countries around the world, with our civilian agency partners,  the FBI, DHS, and others, to identify this type of TTPs and then push them out to the  private sector so that they can defend their own networks.  And that's actually a really big change for us.  When I started in this business, people kept asking us for actionable intelligence, and  we're like, no, it's too secret.  We can't tell you.  We have now figured out how to be able to share that information.  And you saw that in something else that occurred at the beginning of the conflict.  Credit to Jen Easterly, who is wandering around here somewhere.  The Shields Up activities that we engaged in to encourage critical infrastructure to  raise their level of defense and the information that the Department of Defense shared out  through that so that the private sector could defend themselves.  And then the technical assistance that we are able to provide through the NSA's Cyber  Security Collaboration Center.  We think that this model represents a better way for us as the Department of Defense to  engage in the defend the homeland mission that doesn't ask us to get on everybody else's  networks.  But I think one of the challenges is that we need help.  And so we have to think about, like, for us, who does cyber?  And I know a lot of you do cyber, but, like, when it comes to offensive cyber, we're one  of the only organizations that has the legal authority to be able to go out and disrupt  adversary malicious cyber activities without our colleagues at the FBI, like, knocking  on people's doors.  And the challenge for us is that, like, it's a really big threat space.  We have a lot that we have to take on.  Russia is not our only cyber-capable adversary.  Frankly, the PRC is also highly capable and capable and has demonstrated, for those of  you who saw the Microsoft Volt Typhoon announcement, seeking to disrupt critical infrastructure  on which we, the Department of Defense, would rely for our mobilization, putting at risk  the lives of our service members and the lives of people in Guam, the lives of people in  the Indo-Pacific region that we might be protecting.  But it's a really big challenge for us, and we need help.  We need the help of people who have the skill sets of the people in this room to be able  to help us identify the adversary malicious activity, to help us develop the kinds of  things that we can use to prevent that malicious activity from causing harm to Americans.  And we need your help to be able to disrupt that activity before it causes harm to people  in the United States.  And we hope that you'd be willing to come help us with that.  It's a big mission space.  We are thinking about it differently.  We are thinking about it in the context of our rules, and we're thinking about it in  the ways in which the cyber domain actually works.  So with that, ladies and gentlemen, thank you.


url: https://www.youtube.com/watch?v=u8V4ofWpHZk
title: DEF CON 31 - Ringhopper - How We Almost Zero day’d the World - Benny Zeltser, Jonathan Lusky
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=u8V4ofWpHZk",
    "title": "DEF CON 31 - Ringhopper - How We Almost Zero day\u2019d the World - Benny Zeltser, Jonathan Lusky",
    "description": "Last year we almost zero-day\u2019d the world with the publication of RingHopper. Now we can finally share some juicy details and invite you for an illuminating journey as we delve into the realm of RingHopper, a method to hop from user-land to SMM.\n\nWe will survey the discovery and disclosure of a family of industry-wide vulnerabilities in various UEFI implementations, affecting more than eight major vendors, making billions of devices vulnerable to our attack. Then, we will deep-dive into the innards of SMM exploitation and discuss methods to use and abuse various functionalities and properties of edk2 to gain code execution. We will unveil both our futile and fruitful quests of crafting our way to SMM, and detail both the paths that lead to dead-ends, and the route to success.\n\nWe will give a detailed overview of different ways to elevate this kind of attack to user-land both on Windows and Linux by chaining multiple vulnerabilities together.\n\nFinally, we will show RingHopper hopping from user-space to\u2026 SMM.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 2389,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230917"
  }

  This text was transcribed using whisper model: large-v2

   Good morning, DEF CON. How's everyone doing? Right. So hope you got a good night's sleep  because today we'll embark on a journey. A journey into the realm of Ring Hopper. But  first we'll tell you the story of how we almost zero-dayed the world. So usually a timeline  is presented towards the end of the talk, but we'll make an exception. It all started  on June 1st, 2021, when we initially reported the findings we'll be talking about today.  On January 19th, 2022, CERT-CC started working on the coordinated disclosure. We'll soon  see why this disclosure had to be coordinated. By the way, I'd like to use this stage to  send a big shout-out to VGI and the folks for mastering the challenging disclosure.  Right about now, a year ago, we should have presented our findings in the Black Hat and  DEF CON conferences, but unfortunately we were notified that the issues will not be  fixed in time. So we had to withdraw our talks. But we did it rather close to the conferences  themselves, so our abstract was still printed in the booklet, in DEF CON's booklet, which  might have caused some confusion. By the way, from the bottom of our hearts, we appreciate  the concern. Fast forward to November 8th, 2022, when the  last embargo set by CERT-CC has expired. And a note was published, which cleared pretty  much everything up. And now that we're out of the all-day danger zone, where we couldn't  talk about our findings, let's dive in. So at the beginning, there were four privilege  rings. The most notable are the user mode, user land, user space, ring three, it goes  by many names, and the kernel. The lower the number of the ring, the more privileges it  has, and it works in a manner that is opaque to all the rings above it. For instance, the  user mode has no notion whatsoever of what's going on the kernel. Over the years, new additional  rings were introduced, for instance, the VMM, ring minus one is usually where your hypervisor  runs, and SMM, ring minus two. So let's talk about SMM. It started, it stands for system  management mode, and it started as a small and humble processor operating mode that mostly  provided low-level system functionalities such as power management, system hardware  control, and OEMs ran their proprietary device-specific code there. Over the years, SMM got  bigger and bigger and turned into a huge monstrosity that performed all kinds of operations.  For instance, it exposed and exposes an interface to the SM BIOS, does PS2 mouse keyboard  emulation, handles USB events and boot and run time, and the list is long. Together with  SMM grew the attack surface, and it has become so much more interesting for the attacker.  But this is fine, because numerous registers and MSRs, along with some pretty awesome  mitigations, were created with the sole purpose to keep SMM safe.  So in order to switch to SMM, the kernel has to trigger a special kind of interrupt called  system management interrupt, or SMI for short. Once an SMI is triggered, the processor switches  to running SMM, and the kernel is no longer active, and just like with any other interrupt,  there is an interrupt handler that corresponds to the interrupt number that was triggered,  and in our case, it's aptly named the SMI handler. Once the SMI handler is done running,  the processor switches back to running the kernel, and the SMM is no longer active.  The SMM resides in a special well-guarded portion of the RAM called SM RAM, system management  RAM, while all the other entities have no access to the SM RAM whatsoever. For instance,  if the kernel tries to read from the SM RAM, it will get a bunch of FFs.  Overall, it looks like a worthy target, right? So in our research, we started with an agent  running in user mode, escalated to the kernel, and from there, we hopped to the SMM.  And we did all that on this Intel NUC. But as we'll see later on, our research goes way beyond  this recently discontinued little fella.  So this is a good time to dive into our findings, but before we do so, we need to understand  what is a time-of-check time-of-use vulnerability in SMM context. So let's say we have an SMI  handler that provides the awesome service of overriding a buffer with the value of coffee.  Since we are SMM, we do not trust the operating system, so the first thing we have to do is  to validate the input and basically make sure that the output buffer points to a valid location.  This will be the time-of-check. Then, once it was validated, we can use it and override  its content with the value of coffee. This will be the time-of-use.  If an attacker can modify this output buffer, the pointer, to lead to another location  in between the time-of-check and the time-of-use, it will basically gain a right primitive  of the value coffee. So let's see how it works in SMM context.  So in the normal scenario, we have an input buffer which would lead to an OS-owned memory  and the SMI handler will simply override the content of it with the value of coffee.  However, an attacker may try to modify this output buffer to lead to the SMRAM in between  the time-of-check and time-of-use, and by doing so, gain a right primitive of the value  coffee to the SMRAM. By the way, this is exactly what a validation function does.  It makes sure that the output buffer is not located inside the SMRAM.  So let's discuss how we exploit such an issue.  In a classic time-of-check, time-of-use exploitation, it will work as follows.  Let's say we have a system with four different cores, and let's assume that the first core  does the critical SMI handling. It does the validation and usage steps.  So between the other cores, we will try to corrupt the data. Sometimes we may do this  before the validation, and if so, it will simply not pass the validation phase.  Sometimes after the usage, and in such scenario, nothing would happen.  But eventually, with some luck, we may corrupt the data exactly in between the validation  and usage, and exploit this issue.  However, when an SMI is triggered, all the other cores are going idle, and we cannot  use them to corrupt the data. So how did we do that?  The answer was DMA. DMA stands for direct memory access, and this is the way for your  peripheral devices to talk with the CPU, the operating system.  And in precise, those devices could be your Ethernet adapter, or your graphics card, and etc.  So to test this hypothesis, we took something that is called PCILH.  It's a cool tool by Ulf Rysk. This is the small red FPGA device that you see here, which  is connected through the M2 bus, and basically it allows you to initiate arbitrary read and  write DMA transactions to the RAM.  And using it, we were actually able to exploit this time check time fuse issue, which was  amazing, but as some of you may say, it's not good enough.  It requires physical access, right?  And it could be considered only as an evil maid attack, or supply chain attack at best.  And we thought so as well, and we wanted to make things even more powerful.  We wanted to operate them remotely.  So to do that, we utilized something that exists on any platform.  We utilized a storage device, and we did it using a cool technique by Rafal that was presented  a couple of years ago, which allows you to generate DMA transactions using a storage device.  So let's see how it works now.  Remember the previous diagram?  Now we add another component into the equation.  We add your storage device, and on top of it, we place a malicious file which contains  our payload, or basically the modified address.  So once again, we will start by generating a DMA request.  Due to the asynchronous nature of the storage device, it will take it some time to process  the request.  Then we will also hook this request such that it will be redirected back to the input buffer,  and we will trigger an SMI.  Once we trigger an SMI, all the cores are going idle.  Remember?  Then eventually, the SMI handler will enter the critical validation and usage steps, and  with some luck, the data or the file will be returned exactly in between the validation  and usage, and will allow us to exploit this time-of-check, time-of-fuse issue.  Okay, so we talked a lot, and it's probably a good time for a recap.  So we discussed what is SMM and how we can communicate with it.  We also discussed how we can turn those time-of-check, time-of-fuse issues into write primitives to  the SMRAM, and we also discussed how to manipulate DMA transactions to exploit exactly those  time-of-check, time-of-fuse issues.  And we also discussed how to execute code inside SMM.  Oh, well, not exactly.  So, yeah, we don't currently have the ability to execute code in SMM, but we have something  pretty powerful.  We have a write primitive to the SMRAM.  So let's put that to some good use.  One of the modules we analyzed was the SMBIOS DMA edit Dixie driver, and our analysis was  not in vain.  It bore fruits in the image of potential write primitives.  It's worth noting that this list is not exhaustive, and it's far from being the only vulnerable  module.  However, with a bunch of write primitives in a classic scenario, you would probably  try to find an executable memory region, right?  And we thought that it would apply to SMM as well.  But as we discovered, SMM has a paging mechanism of its own, where all pages containing code  are read-only, and all pages containing data are non-executable.  Then you would probably try to forge some arbitrary payload out of your write primitives.  And even though we have quite a few of them, their variety and number does not let us craft  anything decent.  And lastly, you would strive to get unrestricted memory access.  And here, once again, the paging mechanism in the SMM hinders our exploitation.  So for starters, most of the non-SMRAM RAM is simply not mapped to the page table.  And if that's not annoying enough, and it's annoying, the page table resides in read-only  pages, meaning no new pages can be allocated, and all attributes are permanent.  Meaning that if we do manage to execute code in SMM, it would be pretty hard.  Not impossible, but pretty hard to do something, for instance, to the OS.  So as you all probably agree, I hope by now, the classic approach might not be very applicable here.  So let's try to think out of the box and leverage some mechanisms that are unique and internal to SMM.  So at this point, Jonathan and I turned to reading some works from the past.  And one of the works we found was by Raphael Washtuk and Corey Kallenberg from 2015, where they write,  by forcing S3 suspend-resume cycle, an attacker can run an arbitrary code and take control over SMM.  Sounds promising, right? But what's S3 suspend-resume, and what is S3?  So, well, S3 is a sleep state where the CPU is idle, but the memory keeps on working.  And simply put, when you put your machine to sleep, it usually enters S3.  Let's continue with some more background.  So a normal boot process is rather time-consuming.  But when we come back from S3, some of this process can be skipped because, well, the machine has already booted once.  However, some configuration still needs to be restored.  And here the S3 boot script comes to our aid.  During the normal boot, the configuration of the platform is encoded into the S3 boot script.  And then when the machine wakes up, the code boot engine simply executes the script and restores the configuration.  And this boot script consists of rather primitive opcodes like reading, writing to IO, to memory, to PCI, etc.  And here's the interesting bit.  Previously, it was stored in a location that was accessible to the OS,  which is exactly the fact that the paper we saw earlier abuses.  They modified the boot script from the kernel, put the machine to sleep, woke it up.  At this point, their malicious S3 boot script was executed, and eventually they ran code in SMM.  So as you could probably guess, this paper was from 2015, so it's already mitigated.  And nowadays, the S3 boot script resides in a container aptly named Logbox.  And the Logbox is a data structure that provides integrity of the data.  It is located in the SMRAM, has a pretty standard implementation,  and there is a rather convenient API for reading, writing, and updating it from ring zero.  So let's have a look at the update procedure.  So here we see the function that updates the Logbox,  and it either returns access denied error or some internal status.  The only way we do not get access denied, and, well, we don't want to get access denied,  is if the mLogged global variable is not set,  which is kind of a nice way of preventing the kernel from updating the Logbox.  And this global variable unconveniently resides in the SMRAM,  but, hey, we have a right primitive there, right?  So let's utilize all the information we got and try to execute unauthorized code in XMM.  So the plan is as follows.  We use our right primitive to zero out the mLogged global variable.  Then we invoke the update procedure of the Logbox,  and by that modify the S3 boot script with our malicious version of it.  We put the machine to sleep, wake it up,  and at this point the S3 boot script will be executed  and will be eventually running code in SMM.  So it's a great idea, but it doesn't really work  because right after the machine wakes up and just before the S3 boot script is executed,  the code will close and lock SMRAM and only then jump to the boot script,  meaning that even though we managed to execute code,  rather privileged code, at rather early stages of S3 resume,  the SMRAM is locked and most of the RAM is simply not mapped to the page table.  Yeah, we should have read that documentation.  All right, so our quest continues, and let's take another attempt.  And let's take another attempt where we emerge victorious.  But as usual, some background.  So each core has its own region of the SMRAM  pointed to by the SMBase MSR model-specific register.  Each core has an MSR of its own.  Each of these regions contains a lot of interesting things,  but we'll be focusing on two.  The SMI handler entry point,  which is the first code that will be executed upon entering SMM,  and the save state, which contains, among other things,  the value of the SMBase MSR.  And as a matter of fact, the proper way to modify the SMBase MSR  is by changing its value in the save state.  And this whole operation is pretty special.  How special is it, you might wonder.  It's so special that it has a name, SMBase Relocation.  From a developer's point of view,  SMBase Relocation is pretty straightforward.  They modify the SMBase value in the save state,  and some magic behind the scene relocates the whole region  to the new address,  which leads to the following attack idea.  So let's allocate some user-controlled memory  that is accessible to both kernel and SMM.  There we'll craft our own SMI handler entry point,  the first code that will be executed upon entering SMM.  And now we'll simply use our write primitive  to modify the SMBase value in the save state.  This will trigger an SMBase relocation,  and eventually we'll execute code in SMM, right?  It's a great idea, but it doesn't work.  It doesn't work at least out of the box,  and it doesn't work thanks to this MSR,  and in particular, the SMM code check enable bit.  So when this bit is set and the machine is running in SMM,  if someone tries to execute code outside of SMRAM,  it will simply trigger an exception.  You can think of it as some sort of a SMAP mechanism.  But that's not all.  There is a lock bit here that if set,  this MSR cannot be modified or changed in any way  until the next reboot.  And, well, rebooting the machine  or cutting power to the CPU kind of defeats the purpose.  So at this point, Jonathan and I sat and thought,  what could be the closest thing to rebooting the machine  without rebooting the machine?  And then it hit us.  We'll just put the machine to sleep,  prior to S3 sleep.  Recall that the S3 sleep state is a processor state  where the CPU is idle, but the memory keeps on working.  And as the CPU loses power,  all of the entries stored on the CPU  are cleared when going into S3.  So if you care about all these entries,  for instance, the MSR we just saw,  all the data should be copied to the memory  prior to entering S3.  And after the machine wakes up,  it should be restored to the CPU.  So let's have a look at our beloved  MSM code check enable bit.  In normal execution, it is set.  When going into S3, it is still set.  When the machine wakes up and we come back from S3  as the CPU lost its power, it is cleared.  And at the very early stage of the boot process,  there is some initialization code  that initializes this bit.  So let's have a look at the initialization code.  So clearly, we see the write MSR over here  with a certain value.  You'd have to believe us that it comes from the memory.  And here's the interesting bit.  This write MSR happens only if the condition  in the if statement holds,  meaning the MSMM feature control supported global variable  should not be zero.  And remember, we have a write primitive to the SMRAM  to the place where this global variable is stored.  This leads to the full recipe of unauthorized code execution  in SMM from kernel.  So first, we use our write primitive  to annul the MSMM feature control supported global variable.  Then we put the machine to sleep, wake it up.  At this point, the function you saw earlier is executed.  The condition in the if statement does not hold.  And the SMAP-like mechanism is not enabled.  Hooray.  Now we create our own SMI handler entry point,  the first code that will be executed upon entering SMM.  And we use a write primitive once again  to modify the value of the SMBase MSR in the safe state.  And thus, we trigger an SMBase relocation.  And we trigger an SMI.  And drumrolls, please.  We have code execution in SMM.  All right.  Great success.  So frankly and humbly speaking, this method is pretty awesome.  But it gets even better.  So the SMI handler entry point starts running in real mode,  meaning that the page tables, enforcements  have not kicked in yet because, well, there is no paging.  And as we crafted our own SMI handler entry point,  we have full and unrestricted memory access  to all of the RAM.  So for instance, we do not mind the non-executable  or read-only pages,  or the fact that the paging mechanism is static,  or the fact that the page table resides in read-only pages,  or the non-executable stack, or any of these mitigations.  This is pretty awesome.  However, newer mitigations do hinder our exploitation.  In particular, the S3 and SMBase log bits.  When these bits are set,  the CR3 register and the SMBase MSR  cannot be modified until next reboot.  So while those mitigations are not fully adopted yet  in all platforms,  we wanted to deal with them as well.  And to do that, we had no lead at this moment.  So we decided to dig up once again  through the pages of history.  And we stumbled upon this cache poisoning attack  that was presented in 2009 by Rafael and Joanna.  And using the cache poisoning technique,  you basically are able to arbitrarily read and write  to and from the SMRAM.  So let's see how this mechanism works.  So when we try to write to the SMRAM from the kernel,  we will stumble upon a barrier,  which basically makes sense, right?  We are not allowed to write to the SMRAM,  so the memory transactions will be discarded.  However, this was a little bit misleading.  In practice, when we try to write to the SMRAM,  we'll go through the cache first,  and the data will be stored there first,  and only then it will be written back to the SMRAM.  So what if before the data is written back to the SMRAM,  we will trigger an SMI,  and the CPU will enter SMM state,  the barrier will be removed,  and with some luck, only then the writeback will occur,  and we'll modify the content of the SMRAM.  So this would work.  But obviously, this is already mitigated,  and this is due to a special MSR that is called SMRR,  the System Management Range Register,  and it does a simple thing.  It basically disables the caching of the SMRAM.  But we already know how to disable MSRs, right?  So let's see the code that restores it from the sleep state.  And this probably looks familiar,  and this is why.  So this is the line of code that actually restores the MSR,  and once again, it is dependent upon a global.  So what if we annul this global,  set it to zero using one of our write primitives,  we'll put the machine into sleep,  we'll wake it up,  and when we wake up, we will be able to write to the SMRAM  directly by resurrecting from the dead the cache-poisoning attack.  So once again, success,  and we can deal with even those newer mitigations.  So this is a great time for a demo,  and let's hope it will work.  Okay. Perfect.  So before we begin, please notice the Intel NUC logo.  This logo...  This logo is stored on the SPI Flash,  along with the UEFI firmware.  So if you are able to execute code inside SMM,  we will be able to modify this logo.  The reason for that is because only SMM is accessible to the SPI Flash.  It is the only one that is able to write to it.  So now it's time to elevate our privileges.  We'll begin by crafting a new write primitive  of the value of zero.  Remember, we had a rather complex write primitive,  and none of them was an actual zero.  So by chaining a couple of them  and modifying a couple of globals inside the SMRAM,  we were able to craft the value of zero,  and this will help us in the next step of our attack.  So now we will try to annul the MSMM feature control supported global,  which is responsible for the MSR restoration.  And if you are actually able to disable it,  when we return from sleep state, the MSR will be annulled.  So now that we have annulled this global,  we will read the MSR before we go to sleep state.  We will see that the value of the MSR is five,  which stands for two enabled bits,  both the enable bit and the lock bit,  and we'll put the machine into sleep.  So at this moment, we count on the user to return from the sleep.  I guess no one was ever concerned  that he's being SMM mega breached  when his machine suddenly went to sleep.  And now that he is back,  we will read the MSR once again, and it is zero.  So now we are able to execute code outside the SMRAM.  But how we will do it?  Using the SMBase relocation attack.  So at this point, we'll execute the SMBase relocation attack  and execute our own shellcode outside the SMRAM.  So what the shellcode actually does,  it simply replaces one of the SMI handlers,  and now we are only left with triggering it.  So now that we have triggered it,  we will reboot the machine  and see the result of what our SMI handler actually did.  And voila!  We managed to change the logo!  So to better understand the implications of the issues we have found,  we need to understand the UEFI ecosystem first.  So everything begins with the TianoCore project,  or what some of you may refer to as the ADK2,  or practically the source code for any of your modern UEFI frameworks.  Then comes the IBVs, the independent BIOS vendors.  They take this source code, ADK2,  and practically add a major portion of functionality.  They add all the different SMI handlers along the way.  Then they deliver it to the OEMs,  to the original equipment manufacturers,  such as Acer, Asus, Dell, Gigabyte, HP,  Intel in the case of the Intel NUCs,  Lenovo, and MSI.  Then those OEMs deliver it to you guys, the end customers.  So in the attempt to understand how many devices are vulnerable to Ringhopper,  we found out that only in 2020,  there were manufactured more than 200 million devices  that are vulnerable to our attack,  which is absolutely crazy,  and probably results in a couple of billion devices that are vulnerable.  And obviously it means tons of CVs.  So if things were not bad enough,  we want to make things even worse.  Up until now, we attack the machine from kernel  to SMM, a.k.a. Ring-2.  But we want to make our attack work from Ring-3 as well,  from user space.  And to do that, we require three different things.  We need to be able to generate DMA transactions,  we need to be able to trigger SMIs,  and we need to be able to write to specific physical memory.  So let's begin by generating DMA transactions.  So remember the previous diagram  where we hooked inside a kernel the DMA response  and we made some very complicated DMA requests?  So we figured out it is way, way simpler.  In order to generate DMA requests,  you only have to read a file.  The data will be returned to us with DMA directly.  And to make sure that it is being redirected  to the input buffer, we do not need a hook.  We simply read it into the input buffer.  So this was it,  and how we generated DMA transactions from user space.  It was rather simple,  but triggering SMIs is way complicated.  And this is because we need to execute a special opcode,  out B2, that can be executed only from kernel.  And at this point, we got very frustrated.  And like every frustrated millennial,  we went on social media.  And in specific, the ones that,  if you triple its name by three,  you'll probably get the wrong results.  So anyway,  we stumbled upon one of Alex Matrosoff's tweets,  which says that practically any BIOS update tools  that you'll find out there  probably has some low-level functionality  that can be reused for offensive purposes.  And indeed there was.  So AMI provides two drivers,  a Linux driver and a signed Windows driver,  and both of them expose an API  for triggering any arbitrary SMIs that we desire.  Basically a yoke tool.  So now that we have done with triggering SMIs,  we are only left with writing to specific physical memory.  And I remind you,  we wanted to make it work both from Windows and Linux.  So let's start with Windows.  So the communication with SMM  is a little bit more complicated.  It has a special struct that is called a mailbox,  which has a description of all the things  related with the communication with SMM.  And among others, it contains a physical address  of a row buffer,  which would actually contain the input.  So in order to access it from SMM,  we require a physical address,  which is basically the virtual address within SMM context.  And to access it from user space,  we require a virtual address  that maps exactly this physical memory region.  So let's look at the buffer mapping yoke tool  inside one of the Windows drivers.  So it begins by triggering SMID 9,  which basically populates the mailbox  and along the way the row pointer to the buffer.  And then in order to access this mailbox,  it needs to map this physical address.  So the next thing that it does,  it basically maps this physical address  into an accessible virtual address.  Then at offset 8,  it accesses the pointer to this physical buffer,  the row buffer,  and once again map it  into a user-accessible virtual address.  And then returns everything into a user-accessible memory  so the user will be able to access those virtual addresses.  So some of you may notice there is a race condition here.  In between the time that the SMI is being triggered  and the mailbox is being populated  with the pointer to this row buffer  and the times it is being mapped to user virtual address.  So what if we change this physical address  in between the time that the mailbox is being populated  and the times that this physical address is being mapped?  Basically we'll be able to map  any arbitrary physical address that we desire.  So let's see how it works.  We will trigger the buffer mapping yoke tool twice.  On the first attempt we will get an access  to the mailbox virtual address  so we will be able to modify the mailbox at offset 8  with our own desired physical address.  And then we will modify the mailbox  to exploit this race condition  and basically change this address  with our own arbitrary physical address  and we will get the corresponding virtual address.  So this looks great,  but reality makes things even harder.  In order to avoid the remapping  of the same physical addresses over and over again,  those globals are being checked,  which basically makes sense, right?  We do not want to map the same address over and over again.  So at this point we decided to look at the cleanup yoke tool.  And we noticed that the cleanup yoke tool,  all it does is to annul those globals.  And I will repeat it, it only annuls the globals.  There is no unmapping of this virtual address once or ever.  So it is still accessible to user space.  So we will use this fact  and we will make the following exploitation.  So we will trigger the buffer mapping yoke tool  to get the mailbox virtual address.  We will trigger the cleanup yoke tool to annul the globals.  We will exploit the file,  and then we will exploit the following race condition.  From two cores, we will do as follows.  On the first core, we will trigger  the buffing mapping yoke tool once again  to populate the mailbox  and to map the physical address inside it.  From within the other cores,  we will use our previous virtual address of the mailbox  to modify it at offset 8  with our own desired physical address.  Then we'll check if the newly mapped physical address  is the ones that we wanted.  If not, we will simply repeat the entire process.  We'll trigger the cleanup yoke tool,  repeat the entire process once again until we succeed.  So you folks are pretty tired by now, I guess.  We've presented a lot of info,  but let's...  but do you have a moment to talk about Linux?  AMI does some pretty...  lets us do some pretty amazing things from user space.  Here we open the Linux module,  the kernel module, sorry,  and trigger the mmap syscall  with the...  with the kernel module's file descriptor  to map any physical address.  Which is pretty awesome.  At this point, we'll have to somehow be able  to generate DMA transactions for our exploit to work.  So just as we did on Windows,  we'll simply open a file,  read it to the previously mapped memory,  and hope for the best.  From the Linux module's side,  they initialize the mmap attribute  of the file operations struct  with their own function,  which does...  which actually does the virtual to physical  to virtual mapping using the remap BFN range,  which is pretty straightforward.  It gets a physical address  and returns a user-accessible virtual address.  But there are some bad news.  When we execute this code,  we get an e-fault.  And the reason for that is  in the way remap BFN range works.  When running this function,  page ranges are managed without struct page,  just pure BFN.  Simply put, this will not work.  No DMA transactions will be generated here.  However, we have the ability  to map any physical address.  Any physical address.  So let's take the code from before,  and instead of mapping some arbitrary physical address,  let's map, for instance, the address of the Linux kernel  or a kernel module.  At this point that we have the user-accessible mapping,  we will be able to patch ring zero code  and gain code execution in kernel.  And which is pretty awesome,  but it sounds kind of familiar, right?  Do we remember how we generated DMA transactions from kernel?  So now that we have all three bullets  working from ring three,  we have a full exploitation chain  from user land to SMM,  which concludes our journey.  We first got the ability to write to the SMRAM.  Then we tried to leverage it into code execution in SMM  using the S3 boot script,  and we failed spectacularly.  And we successfully ran unauthorized code in SMM  using and abusing the SMBase relocation technique.  And lastly, we elevated the attack to work from user land,  and thus we managed to hop from user space to SMM.  We were Jonathan and Benny.  Thank you so much for taking part in this journey.  Thank you for having me.


url: https://www.youtube.com/watch?v=NVnzm-L4a5c
title: DEF CON 31 - How Vulns in Global Transportation Payment Systems Cost You - Omer Attias
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=NVnzm-L4a5c",
    "title": "DEF CON 31 - How Vulns in Global Transportation Payment Systems Cost You - Omer Attias",
    "description": "Public transportation payment systems have undergone significant changes over the years. Recently, mobile payment solutions have become increasingly popular, allowing passengers to pay for their fare using their smartphones or other mobile devices.\n\nThe evolution of public transportation payment systems has been driven by the need for faster, more convenient, and more secure payment methods, and this trend is likely to continue in the years to come, But how secure are mobile payment solutions for public transportation?\n\nIn this presentation, we will examine the security risks associated with transportation applications, using Moovit as a case study. Moovit is a widely used transportation app operating in over 100 countries and 5000+ cities. Through our investigation of the app's API, including SSL-encrypted data, we discovered specific vulnerabilities, which we will discuss. We will also demonstrate a custom user interface that can obtain a \"free ticket\" and cause someone else to pay. Furthermore, we will explain how an attacker could gain unauthorized access to and exfiltrate Personal Identifiable Information (PII) of registered users. Our findings offer practical recommendations to improve the security of transportation apps.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 2028,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230917"
  }

  This text was transcribed using whisper model: large-v2

   Thank you. So, hey everyone. So, do you want to have some fun? Alright. So, uh, okay. Hello  everyone. Welcome to my talk, The Price of Convenience. How security vulnerabilities in  global transportation payment system can cost you. My name is Omer Attias and I'm 23 years  old. I've been working at SafeBridge as a security researcher for the last two years and  previously I started my career at the age of 17 while working at Rafael Advanced Defense  Systems. I'm especially interested in low level and vulnerability research and I'm also a  technology and science enthusiast. Okay, so in this session we walk through the smart  payment solution of public transportation and we specifically look at the solution in  train services. And learn how we can trick the train station gates in order to avoid  ping. Then we will focus on Movit, a mass operator that provide a mobile solution for  public transport. We will delve into the APIs of this application and we'll find some  vulnerabilities that led me to the perfect crime. So, let's kick it off. So, I guess all of  you have ever used public transportation. So, give me hands, I want hands. Please raise your  hand if you have ever used mobile, mobile app solution in order to pay. Okay, I can see a  few hands. Cool, so I encourage all the people that raised their hands to stay tuned to this  session. And all the people that didn't raise their hand, also stay tuned cause it will be  fun and profit. Okay, so recently mobile payment solution have become increasingly  popular allowing passengers to pay for their rides using their smart phones. This trend is  likely to continue so let's discuss some terms used in this field. So, let's explain what is  mass actually. So, mass is actually SAS but in the mobility field. It's actually application  that provide plan and pay for transportation. The mass operator is actually the company that  develops the application that provide those features. We can see the logos below like  Uber and Movit and later on on this talk we will focus more on Movit. But a disclosure before  we delve into the session, all the findings and explanation are based on the transportation in  Israel but are not limited to other countries like the US. And also I focused on the train  services but the techniques apply to other transport services as well. And one more  thing to note is that all my research done in an ethical way. So now it's time to understand  the mobile solution in public transport. So how actually mobile solution work as far as the  train services is concerned. I want to introduce Mike. Mike wants to take a train ride and use  his new mobile solution. His mass operator application that he just downloaded. So Mike  got close enough to the station and open up the favorite mass operator. With his mass operator  Mike can order an entrance ticket and this ticket is actually a QR code that the gates can  validate. And if the ticket is valid the gate will open the doors. Now Mike can enjoy his ride  and when Mike reached his destination Mike again open up the application and order an exit  ticket and complete the train ride. But one more thing to note is that the fare is calculated  when we end the ride. Because only at the destination the mass operator know how much to  charge us. And all the billings are accumulated and will be charged on monthly basis.  So the mobile solution provides the payment interface between the train services and the user  in the form of the QR code. And I thought to myself what the ticket contain? Maybe the ticket  is encrypted, maybe not. But I decided to give it a shot and investigate the ticket format.  Cool. So now we understand how to use the provided mobile solution in order to get around.  Let's deep dive into the format of the ticket. So here's an example of train ticket. You can see  a long number below the QR code which is the row ticket number. It seems that the QR code is  not encrypted and I wondered if it's possible to change this value and trick the gates into  accepting a fake ticket and ultimately this is a way to avoid paying, right?  But what is this format of random looking digits? To make sense of it I need to gather more  ticket samples and analyze their patterns. So I collected a few train tickets and noticed a  interesting pattern in the form of the ending 201 in each of the tickets. This suggests  a format that can be figured out by more analysis but it's still difficult for me to identify  a specific format that I can fully understand. So when I searched on Google I found  an API that gave me a JSON file with lots of information. In that file one of the details  mentioned was the operator. This JSON member represents the ID of the mass operator.  So it turns out that the repeated number 201 at the end of each ticket that I collected  represented the ID for Movit Pango which is the one that I used. And I also found  other operator mentions in the JSON including one called IDF and it's interesting to know that  IDF operator allows soldiers in Israel to ride for free. But I'm still not familiar with  the remaining part of the ticket and I don't have any leads to help me understand it.  Well, now what? At that point in time I understood that breaking down the whole format of the  ticket is too difficult. And I decided to take my current knowledge at that point in time  and conduct an experiment on the train station physical gates. So what would happen  if I will order a ticket and just in time modify the ending operator ID to be a different  operator ID? In this example I will change Movit Pango operator to be the IDF one.  And my expectation was that the gates would see this ticket as a valid ticket as I  just modified the operator ID to another known operator ID. But long story short the  experiment failed. So in summary I had some knowledge about the ticket format but it was  not enough to do anything interesting. And I realized that this approach may not be  effective because the gates still validate the ticket even if I make small changes to it.  So I decided to take the focus from the ticket to focus on the gates. And the focus  change from the ticket to the gates led me to find a logical vulnerability that allowed  me to take a ride without being charged. Let's see. So a quick reminder there are two  tickets during a train ride. The enter ticket which we order before entering the station  and the exit ticket before exiting the station. Diffing the entrance and the exit tickets  revealed that these two tickets are actually the same ticket. Okay. So if the entrance  and the exit tickets are the same, why not to use a canceled ticket in order to take a  train ride? Let me explain exactly how. So Mike gets close enough to the station and  then order an entrance ticket. But this time Mike immediately cancel his ticket. And  the question is will the gates will validate this ticket? So it turns out that the gates  accepted the canceled ticket. Perfect. Now we know that there is no real time  communication between the gates and the mass operator. Now Mike can enjoy his ride and  now is the moment of truth. Mike reaches the destination. Will the canceled ticket  open the doors gate? So yes. Mike completed a full ride with a canceled ticket. This  means that Mike will not pay on the ride, right? So nope. Mike will pay. A week  after his ride the mass operator found that there is a ride that not being charged.  How they knew that? After all Mike canceled his ticket. So what likely happened is  that when Mike entered the station a record was saved in the train logs. And similarly  a record will be saved for the exit. These two logs together represent a complete  ride even though the ticket was canceled the mass operator can still calculate the fare  for the full ride. So I had to trick somehow the gates. And the idea that came to my  mind is to make a hole in the logs. And I will explain how. The process is similar to  the previous process but this time when Mike reaches the destination with the canceled  ticket, Mike order again entrance ticket and then immediately cancel it. The second  ticket will open the gate and in this process there is no full ride that the mass operators  see that Mike did. So this is actually worked. And to summarize all, we gained no  ledge of how mobile solution works and I showed a way to trick the train station gates  in order to avoid paying. So far so good. But that's not all. I decided to take a specific  mass operator and find security issues there. The goal is to make a free ride and maybe  even more. So in the second half of this session I will shift my focus to Movit and present  three vulnerabilities that I have discovered. And additionally there will be a bonus  demonstration toward the end. But first let me introduce Movit. So Movit is a worldwide  mass operator that has been acquired by Intel at 900 million dollars. Movit has more than  1.4 billion users around the world and they operate in more than 100 countries and 5,000  cities. Movit has integration with these big transit providers. It means that we could  control an account with one of these providers linked to the account. And the application  is primarily used for navigation and finding routes but also used for paying for rides. By  clicking the join now button and completing the registration process, users can use their  Movit application to pay for rides including the train as we discussed earlier. So let's  see what this looks like. So the account registration process begins with downloading the  app and joining the payment service. As part of the payment service registration, users are  prompted to provide their phone number. And to validate that the provided phone number  belongs to the users and the phone number is owned by the user, Movit servers generate a  random OTP and send it to the provided phone number. If the user responds with the correct  OTP, Movit will register a new account. And this account is affiliated with the provided  phone number. The account holds other details of the user such as their credit card and  their personal information. Also, Movit offers a feature that enables users to switch  their account between devices. The process of switching devices is quite seamless as it  follows the same steps as registering a new account. So for example, if the user takes  his SIM card and places it in another device, the new device holds the phone number of the  old device that already has an account registered. But there is no account connected to the  new device, right? So with the new device trying to join the service, Movit server will  see that there is an existing account in their affiliations. By authorizing the  generated OTP, will cause the account previously connected to the old device to  disconnect and transfer to the newly registered device. So I wondered if I would be  able to find some basic insecurities in the API. And I decided to look at the API  request between the server and the mobile application. But all the traffic between the  server and the application is encrypted using SSL, making it impossible to intercept.  But I managed to bypass the SSL certificate using a free script. This allowed me to  serve my own certificate and ultimately intercept all API requests between the server  and the device. And my goal was to understand the API communication between the device  and the server. So let's see. When the application is first opened, a create user API  request is sent to the server. The name of the API may sound straightforward, but I  realize it's actually badly named. Let me explain why. When the API request is sent,  the server responds with a log identifier called user key. And through my research,  I found that this identifier is actually assigned to the device and not to the user.  And later on, we will discuss this user key identifier more in detail. For now, just  remember it's associated with the device and not with the user. So I explained earlier  the account registration process and that the servers hold additional details on the user  like his credit card. And I want to add one more detail, the user key. The server also  identify account by his user key. But it's important to know that not all the user keys  have affiliated accounts, but all the accounts have affiliated user keys.  Okay. So let's assume there is a device with user key number one. And for example, this  account is linked with phone number one. Our goal is to hijack this account using the account  switching feature. First, the attacker make a create user API request to obtain user key  legitimately. For example, in this, we get user key number two. After obtaining the user  key, the attacker attempts to join the payment service by pretending to be the other device  and specifically the phone device with user key number one. But to complete the registration,  the attacker needs to provide the OTP generated by move it right. And since the attacker doesn't  have access to the phone device, they cannot get the OTP. The OTP is actually four digits  long. And this is immediately raised the idea of brute forcing this OTP. And I know that  there is a small chance that it will be work. But I decided to give it a shot. And for my  surprise, the brute force attack against the OTP actually worked. And I could literally go  over all the OTP options from zero to 9,099. And in the worst case, the brute force took me  only five minutes. So let's see. So we can see the device, the emulator that I have  connected with my account. And now I'm executing the brute force script providing my phone  number. And now the script are trying to guess all the OTP options, as you can see. And we  got the OTP 2014, which immediately disconnected me from the device. We can see. And I order  a train ticket on behalf of my account. And now we will see that someone purchased the  ticket. And this was not me. Cool. So after the brute force attack, the attacker takes  control of the account. This allows the attacker to completely impersonate the account and  use its credit card to order tickets. And furthermore, the attacker gains access to  account's personal information. Also, the server will change its affiliation and link the  attacker user key to the account represented by the victim phone number. So this attack  has its pros and its cons. And on the positive side, it targets a specific phone number,  which can be useful. But it also has limitation. It cannot be widely spread, takes time due  to the brute force, and causes the account to be disconnected. The brute force attack  is a possible approach, but its effectiveness is limited due to the requirement of having  the phone number linked to the account. So I decided to transform the problem of getting  phone number linked to an account to understand the user key format with the goal of enumerating  existing accounts. So in the next few slides, I will delve into the user key format, and  I will showcase the second vulnerability that I found. So as I mentioned earlier, when the  application is opened, for the first time, a create user API is sent to the Movit servers.  The server responds with a user key, and we can see the above value is an example for user  key. It looks like a type of UID or something. And if I make the API request multiple times,  I can gather a lot of user key samples, and by analyzing these samples, I will be able to  understand the format better. So I created around 25,000 user keys. And the keys seem  pretty similar, as they all started with E4. And in a brief look, there is a value within  the user key which repeated in each of the keys. Maybe this is a known value. So I searched  this on Google. And I found this Oracle DB function that generates unique identifier with  similar value. In fact, this identifier is not really randomized well. The function that  generates these keys doesn't generate a real pseudorandom identifier, and I will explain  why. And how I managed to identify other devices. So the documentation on this function  shows that this identifier consists of auth identifier, process or thread identifier, and  a non-repeating value. And probably the auth identifier is constant value that appears in  each of the keys. So let's try to confirm this on each of the user keys that I have  collected. So in a second look, we can see that the user keys are not randomized well,  but there are two parts of the user key that seems pretty random. But I noticed that the  last four bytes of the user key repeat in some user keys. Additionally, when this repetition  happens, there are also four middle bytes that remain the same. And moreover, these two  numbers are the only ones that seems well randomized. So when this repetition happened,  the user keys became almost identical, suggesting a relationship between the last four bytes  and the middle four bytes. But brute forcing these two numbers is very difficult due to  the large number of combination, right? So brute force is not a possible approach in  here. What we can do? So I sorted all the keys and got so many keys with these matching  values. These keys are almost identical except of the red square, which turned to be sequential.  But I noticed something interesting. Some of the keys follow a sequence, but there are  a few missings. For example, between A0 and A7, there are six missing keys. And after  looking into it, I realized that those missing keys have already been taken by other users.  So bingo. If we will look for those gaps, we could fill those gaps with user keys of  other devices, right? So we will fill the gaps between A0 to A7, and we know all these  missing keys actually belong to other devices. But what we can do with devices' user keys?  So I was looking for an API request to get some more details by providing user keys.  And luckily, I found the perfect API for this. To retrieve the user's information, I can  use the user profile API by passing the user key as an argument. And when I make the request,  the server will respond with the details related to the user keys. And guess what? If there  is an account associated with the user key, the response will include the account phone  number. And if we have a phone number, we can do brute force, right? So I filmed a  demonstration of catching user keys of newly registered devices and their phone numbers.  And I attempted to test if downloading and registering the payment service would be detected.  So let's see. We can see that this is immediately catching a new, really catching a new  customer of movies and their phone numbers. And we will wait to see if I can catch myself.  All these actually are real users.  So as we can see, we caught myself, and this is my phone number, and I actually can attack  myself. So I leave the script to run for two hours, and a few moments later, the script caught  so many accounts, even worldwide accounts. And for each account, I can link a phone number  belongs to the user. And from now on, we can practically obtain all the newly registered  customers of movie. So we have a lot of phone numbers of accounts that can be attacked with  the brute force. And now we have made the brute force attack more powerful. We don't need  the phone number anymore. Instead, we can go through all the newly registered customers and  attack them. But it still disconnects the account from the device. And I wanted to improve  that also. So we have a list of user keys and their phone numbers. We want to be able to  impersonate the user without disconnecting them from the device. To do this, we need to  understand how the API request looks from the user's account perspective. So let's see.  In the next slide, we will learn how ticket purchasing works in relation to API requests.  We discussed the brute force attack, which involves hijacking account by trying out all  possible OTP options. Now I would like to explore the internals of the API involved.  So just a reminder about the create user API. When the application is first opened, a user  key is generated for the device and requested through this API request. But that's not all.  After this API request, there is something important to know. We have learned that Movit  stores account information like personal details and credit card data along with the user key.  But there is one more essential requirement we missed, the access token. Without it,  communicating with the servers is impossible. The access token is generated immediately  after the device receives its user key. By sending register API request, the server will  respond with a temporary token. And with this token, we can request a verification from a  third party providing the token along with the user key. And in exchange, Google will  respond with the access token. So after setting up the access token, the  application has user key and access token, allowing us to request more APIs. For instance,  without the access token, we cannot register for the payment service, which also means that  we won't be able to use the API for purchasing new tickets. So now we understand that these  two requirements are essential to the API communication. Let's go back to the problem.  The issue is that we have the user key of an existing account, but we don't have their access  token. This means that we cannot make API requests on behalf of the account, like ordering a  train ticket. So in this situation, if we use the brute force attack that I explained earlier,  the account will be disconnected from the device and associated to other device. But we want  to fully impersonate the account without disconnecting it. So let's see what we can do. The  access token is actually a JWT, as we can see. Can we forge this token by modifying the payload  So this approach is not possible due to the way JWT works. So we cannot forge JWT. Do we  have another way to get the token? So through this research, I've learned that sometimes the  simple things will work. So I went back to the creation of the JWT token, and we'll see that  we already have a user key of a different account. Maybe we can request another token for this  user key, even though there is an already active token. To do that, we need to send register and  then verify custom token request. So let's see what we got. So that's actually worked. There  is no validation on the access token creation request. We could request as much as tokens as  we want, even though there is an active token. Now we can fully impersonate accounts without  disconnecting them. It's crazy. We actually have the ability to perform all the operation on  behalf of different accounts, including ordering tickets. Additionally, we can access all of  their personal information. Now we have made a perfect attack without disconnecting the  account. This attack is quick and doesn't require a phone number. With the information collected  through our script, we have the ability to access each of these accounts, and by doing so, we  can retrieve their personal information. So let's see what we did. So I conducted a  proof of concept in which I took each of the user keys and used them to create a database  containing various personal information, such their ID, email address, and so on. Using  this database, I developed a user interface for demonstration purposes, which I then tested  on the train station. But before the demo, here's a fun fact. One of the COD accounts  belongs to one of the developers that moved it, the actual backend developer. It's nice to  see that he believes in the product. So let's see the demo. This is me in the train station,  and you can see on the left side the user interface that I have developed. And now I'm  selecting the source station and the account that I want to pay on my ride. And in exchange,  I'm getting a ticket, which someone else paid me, and I'm easily passing the gates.  Thank you. Okay. So the takeaways. Even big companies can fall victim to simple attacks,  showing the need for increased awareness and attention to basic security measures, and  also, I want to understand the research perspective, turning challenges into opportunities  and using limitations for positive results. We connected with MoveIt and responsibly  disclosed all the vulnerabilities, and all of them have been fixed and no customer action is  required. Also, all the scripts that I used throughout this research pushed to this GitHub  repository, and you are more than welcome to take a look. And I want to thank Shmuel  Cohen for helping me a lot throughout this research. Thank you. And I want to thank you  for joining. Thank you.


url: https://www.youtube.com/watch?v=DFnxrsEvs7M
title: DEF CON 31 -DARPA AI Cyber Challenge Announcement - Perri Adams, Panel
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=DFnxrsEvs7M",
    "title": "DEF CON 31 -DARPA AI Cyber Challenge Announcement -  Perri Adams, Panel",
    "description": "DARPA\u2019s AI Cyber Challenge program manager, Perri Adams, is joined by collaborators from Anthropic, Google, Google DeepMind, OpenAI and the Open Source Security Foundation to share insights about the upcoming competition and discuss the software security challenges facing the commercial sector and open-source community.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 1286,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230908"
  }

  This text was transcribed using whisper model: large-v2

   Hey everyone. Uh thank you so much for that. So I am Perry Adams. I am from DARPA and uh I  have with me here today uh Michael Salito who is the head of geopolitics and security policy  at Anthropic. I have Heather Atkins or Atkins I apologize, the VP of security engineering at  Google. Uh Vijay Burina, the CISO and uh head of security research at Google DeepMind. Dave  Weston who is the VP of enterprise and operating system security at Microsoft. Matt Knight who  is the head of security at OpenAI. And Omkar uh Ara I'm so sorry Omkar we should have  practiced this beforehand. Omkar Arasara you can. Yes please give him uh uh a round of  applause for um uh putting up with me. Uh he is uh the general manager of uh the open source  security foundation, a project of the Linux foundation. So now we got through that. I  wonder if I have the largest panel at DEF CON this year. I think it took us uh a minute and a  half just to get through names. Um so before we uh let them talk uh I I'll give a little  background on what we're here to talk about today. So I'm Perry Adams. I'm at uh DARPA where  I uh run a number of research efforts that uh try to push the bounds of what's possible in  computer security defense. And while I'm not doing that, when I'm not doing that I  organize a DEF CON CTF and the finals are currently ongoing so to put a plug for that you  should absolutely visit the uh CTF floor. Uh but one thing that I'm doing right now that I  just announced at Black Hat is called the AI Cyber Challenge. And so if you don't know  anything about it I encourage you to visit AICyberchallenge.com which has quite a bit of  detail of what this challenge will be. And so I'm here at Black Hat and uh DEF CON to  announce it for the first time. This is a White House backed initiative that puts uh up to  nearly 20 million dollars on the line to bring together the best and the brightest in AI and  cyber security to create AI driven systems that can uh secure the software that all  Americans rely on. So this is a competition to develop automatic systems that can find and  fix vulnerabilities in code. And so a little bit about the the structure of this. We are  going to uh put on a qualification event in May of this year and 20 teams will advance to  the semi-finals at DEF CON in 2024. The top 5 teams there will win 2 million dollars each  and will advance to the finals which will occur at DEF CON in 2025. DARPA is also funding  up to 7 small businesses up to 1 million dollars each to participate. And so the uh  application process for those awards will open on August 17th and uh the application  process for the open uh registration, the open track uh will uh will start in November. And  so this is a competition that is open to anyone and I encourage you all to visit  AICyberchallenge.com to learn more about this effort. Uh because the reason I want to  announce it to this audience is that Black Hat and DEF CON bring together some of the  greatest minds in this space and I would love to see participation from you all in  something like this. Now I'm also incredibly gratified to have some really fantastic  collaborators on this effort. So Anthropic, Google, DeepMind, Microsoft and Open AI have  come together to collaborate with DARPA on this effort to make their cutting edge  technology available to participants to build on top of for this effort. Similarly we're  collaborating with the Open Source Security Foundation to help participants develop  systems that can solve real world challenges especially those for instance seen in the  open source community such as supply chain, security and the security of our critical  infrastructure systems on which uh which are built on top of so much open source code. And  so today we're really here to uh not hear me talk because I've been talking about this  quite a lot lately but to uh hear my panelists talk about what they're looking forward to  in this uh in this competition, how they see it fit into the broader context of the work  that they do every day. And so I'm going to start all the way at the end of the table with  Omkar and so Omkar help us set the help us set the stage. What challenges does the  open source uh community face in software security? And what do you see is wrong with  the status quo? Is the microphone on? I can talk really loud. I think it is. Alright thank  you. Uh thank you Perry. And let me first say as a guy who first went to DEF CON at Alexis  Park just seeing the amount of security professionals that are here I think this was  probably bigger than all of the attendees at Alexis Park the last time I was at DEF CON so  it's an honor to be here. Um as most of you in the room know open source is everywhere.  Open source is in safety critical systems from planes to trains to mobile phones, routers,  switches, computers. And we believe that it is our duty as custodians of security within  the Linux Foundation home of things like the kernel you may have heard of it um as well as  other projects like CNCF and of course the open SSF we believe that it's our public duty to  ensure that our open source supply chain is secure by construction. That is not an easy  thing to do. This is not enterprise software. We can't just jam a secure SDLC in and be done  with it. So we're working with our community as best we can and we're really looking forward  to efforts like this one where we're able to use cutting edge technologies in order to  address vast classes of problem across open source in a way that is complimentary to our  communities. Simply opening thousands of PRs that don't follow the coding style of the project  that you're trying to fix or aren't conformant with the culture of that project is not the way  you fix security. And we look forward to working with DARPA as well as our partners on this  challenge. We're looking forward to some very innovative solutions to these systemic  challenges that we've faced in open source that underpins some of our most safety critical  systems. Thank you. And so my next question goes to my three friends from Google and  Microsoft. So Heather, Vijay, and Dave. You all between Google and Microsoft maintain some  of the largest code bases in the world. How do you deal with those challenges, some of the  challenges that Omkar talked about at that scale? And how do you foresee the use of AI as  applied to that problem? So do you want to start with Dave? Sure. Yeah. So I think the  challenge of finding vulnerabilities is really a challenge of scale. At Microsoft we use  many different techniques. So for example, fuzzing and dynamic analysis techniques are a  great way to at scale find vulnerabilities. Especially in large code bases. We use  compiler changes, platform mitigations, safer languages. I'm sure there's some Rust fans out  there. Shout out to my Rust fans. But obviously we have a large code base that is often  impacted by memory safety issues. So I'm really excited about the scope and the opportunity  of this competition. I'm optimistic but I also having worked in this space a bit, I know  there's some real challenges here. So I think there's going to have to be some breakthroughs  here to really deliver. And I'm excited and I think we can do this. One of the areas that I  think is really exciting is augmenting static analysis. I mentioned that fuzzing is a  fundamental technique but it has some limitations. Building tests and drivers, getting code  coverage, a lot of the sort of block and tackling is not particularly beautiful and it's  difficult to do. So getting that coverage is sometimes hard. Static analysis on the other  hand, particularly on native languages, can be challenging as well. Just reasoning at that  scale. And so being able to do things like automatically generate annotations that can  then feed into existing static analysis systems and augmenting those systems with some AI  approaches are I think something that I think will show up in this competition if I had to  guess. And it's something that we're working on internally and it's been pretty fruitful in  the early stages. So I'm actually just really excited as a security geek to see where folks  go. And I think there will be huge benefit to Microsoft and many of the other folks here if we  can really tackle this challenge. So it's great to see. And before I hand it back to Google,  just to build on what Dave said is I think how he describes the use of AI, not simply  taking large language models and throwing them at code and saying it's going to LLM  vulnerability, but thinking about the ways in which not just generative AI but other machine  learning based approaches can augment traditional program analysis tools like static and  dynamic analysis can take the hard computational problems in that space and the complexity  issues and reduce the search space, guide it and provide augmentation in the spaces that  traditional computer science approaches haven't been able to tackle. That's something I'm  really excited to see in this challenge. So jumping off of that, I'll hand it to Google.  I think it's important to think a little bit about what the outcome we're trying to achieve  is. Imagine a world where most of the new code on the planet is mostly free of bugs. And all  the code that you maintain when you make new changes is also mostly free of bugs. And  when you find vulnerabilities, they're patched and fixed very quickly. That's the outcome  here. And we've been trying to do that as an industry for a long time. Dave mentioned a bunch  of things we've been doing from static analysis, manual audit, fuzzing, DARPA ran a  cyber challenge, what was it, 2015, 2016, and the winning teams there found  vulnerabilities mostly through fuzzing. I think we are now in a new generation of software  development where we are about to get a real leg up on this problem. And fixing the whole  software development life cycle to give developers a high amount of assurance. And so I'm  really excited about the partnership with DARPA because I think we're going to really challenge  in a very open collaborative community kind of way what those solutions might be, whether  you're an open source developer or a commercial developer. And I think we're probably going to  invent some new things. I look forward to kind of all the innovations we see there. Vijay,  do you want to jump in?  Yeah. Great. I think one thing that's quite exciting about the software security space is  that there's a large group of AI researchers that are also deeply interested in this  space. The problem is quite tractable both on the static analysis side and on the dynamic  analysis side. Google has one of the largest fuzzing clusters in the world across our code  base, and we care about that space quite a bit. You've seen some tools that we've released  over the past few years, especially in this space. And there's, from a research standpoint,  some very specific problem spaces that a lot of folks across Google have started to focus  on. For example, using reinforcement learning to do deeper and better code coverage  across our code base, across our integration and build pipelines, and optimizing for that  specific outcome, as Heather mentioned. So that's pretty exciting. We've seen some pretty  impressive results in that space as well. And then, again, to kind of build on top of  some of the things we're doing around fuzzing, using the latest and greatest state-of-the-art  models that we have to do things like fuzz target identification and general work that we  have around our ability to identify and make sense of the things that our clusters find in a  scalable way.  Thank you. And so I talked a little bit about taking different AI approaches and combining  them with program analysis techniques, but we have also seen just really interesting  potential, significant potential in a range of areas from the large language models that have  been put out recently. And so to both Michael and Matt, Anthropic and Open AI, how do you  think LLM specifically can assist with finding and fixing vulnerabilities in software?  Yeah, thanks, Perry. I couldn't be more excited to be supporting the AI Cyber Challenge and  hopefully many of you as participants. It's a great vision which very much aligns with our  own at Open AI. We believe that large language models are going to be transformational for  cyber defense. And we're extremely excited to have the next generation of security tooling  built on our models. We've been working with the community on defensive security research  programs through our cyber grant program. We've had some just really amazing submissions from  the community. We're giving away a million dollars to start, plus GPT-4 access and API credits  to get people started. And we're excited to give the same treatment to AI Cyber Challenge  participants, too. You'll get access to our models, you'll be able to use credits and so on to  do your work. So I would just invite you to think about ways in which you are limited as  security engineers. These are areas where language models can augment your own work and help  fill in areas where maybe you don't have time, parts of your workflow that are sort of  drudgery or maybe where you have scale limitations. These are areas where language models are  going to be able to fill in. And I just want to add a personal note here. I competed in  DARPA's Spectrum Collaboration Challenge a couple years ago in a personal context. It was  some of the most fun that I've had writing software. It's a great way to get access to some  really cool technology, work on some really challenging problems and also be eligible to earn  some money, too. So I hope you'll consider competing. I look forward to supporting you. And  thanks to Perry and DARPA for making this happen.  Yeah, thanks. So large language models like CLAWD can complement the wide range of tools  already used by cybersecurity experts. In some cases they can automate tasks that require  human judgment so that vulnerabilities can be found and fixed in an automated and more  cost-effective fashion. But I think the most important thing to think about is how quickly  the technology is improving. You know, two years ago nobody was using LLMs to help with  writing code. Last year a study came out that found that GitHub copilot users were 50% more  productive than people that didn't use it. And today LLMs are useful assistance for researchers  to find and fix bugs. They can generate, interpret, explain, suggest alternatives to code. But  by next year's DEF CON and certainly within two years when the finals are held, the base  models are just going to be dramatically more powerful than they are today in the same way  that we've seen even in the last year things change quite dramatically. So we're really  excited to support the Cyber Challenge and see what everybody is able to build on our  model. This could be a really great opportunity to do something that makes a huge contribution  to the open source community and to the security of open source that underpins so much of our  economy and society.  Thank you. And I have to say this is one of the parts of this challenge, just to put a  fine point out that I am so excited for, is that participants will have access to resources  from our collaborators to build on top of. So we'll have access to very, very cutting  edge technology from across multiple companies and be able to show really what's possible  when that's applied to a very important challenge like cyber security. And I also want  to stress the prize money that DARPA is putting on the table. The top prize for the final  winner in 2025 will be $4 million. The second place will be $3 million and the third place  will be $1.5 million. And that's in addition to the $2 million each those top five finalists  will get. And that's because DARPA sees this as an incredibly important initiative to push  software security forward. So in our last three minutes, does everyone want to go down  and give a 20 second snippet of advice for perspective AICC participants?  Sure, I'll start. So language models are super sensitive to the prompt that you put in.  And so if the first prompt doesn't work and the second and the hundredths don't work,  just keep trying. You know, it's as simple, it could be as simple as finding a statement  like think step by step and you might just unlock a huge set of new capabilities that  you didn't know existed in the model.  Yeah, I think also in addition to thinking about how the LLM is working, think a little bit  about how you as a developer code and where it would be most helpful. We call that kind  of the user journey of software development. You know, do you want it kind of there as  you're coding? Do you want it when you check in your code? Do you want it running after?  And just think about all the opportunities that you might be able to target.  I think everybody here will agree, but two years is an eternity in AI. So there's going  to be quite a bit of improvement in capabilities. So keep that in mind when you're thinking  about your final solution throughout the competition. I think that's going to be important.  You probably shouldn't be over indexing on current capabilities because there could be  some substantial step changes in those capabilities too.  Yeah, this is obviously going to be a significant challenge. I've looked at a little bit  the rule set and the things that have to happen here. And so I think creativity is going to be a huge part  of thinking about how to nest together different solutions to get to this outcome and ultimately  get a high precision outcome. I think traditionally the problem with static analysis is not that  it can't find bugs, but can it find bugs without the noise? And so I think thinking even  beyond just the specific challenges that are there, but how this is going to be deployed at scale  will be key to getting the results.  I would encourage you to think about places and opportunities where current tools are  constrained or where you are constrained in your own bandwidth. That is where the action's at.  Solve for that and you'll have interesting results.  And remember that the versions of these models that we have today are the worst versions  that we'll ever have at any point going forward. These things are going to get better.  Do not bet on today's foundation model capabilities because the next ones  may supplant it. So get ready for that.  I have the luck of going last  and saying something profound after all those wonderful suggestions.  As I mentioned earlier, open source underpins the most  critical infrastructure that we use today. The work that you're going to  embark on using some of these leading edge tools will have profound impact.  This isn't a term paper. This isn't a release.  This isn't a new product. This is everything. This is all the marbles.  So we really look forward to seeing the contributions that  y'all as participants in the challenge will be contributing.  And most of all, we look forward to leveling up open source supply chain security.  Thank you all. I would second all of that advice.  And I'll add one last thing on Dave's, which is that we will also be looking at  false positives that come out because to create good tooling  you really need to be thinking about usability and the amount of noise.  But to end with the obligatory plug,  please visit AICyberChallenge.com where there is  all the information you need to understand how to participate. And more information  will be coming out this fall. Thank you all so much.  Applause  Applause


url: https://www.youtube.com/watch?v=9Tqp-qJ0__Q
title: DEF CON 31 - The Hackers, The Lawyers, And The Defense Fund - Geiger, Opsahl, McCain, Croc
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=9Tqp-qJ0__Q",
    "title": "DEF CON 31 - The Hackers, The Lawyers, And The Defense Fund - Geiger, Opsahl, McCain, Croc",
    "description": "The hacker community has long conducted important security research that skates the edge of legality. This has led to charges and lawsuits, bogus and serious alike, against hackers. In this panel, we\u2019ll hear from a hacker that faced legal challenges, we\u2019ll describe what legal counseling for hackers looks like in practice, and we\u2019ll discuss a new resource for the hacker community: the Security Research Legal Defense Fund.\n\nLegal issues can arise for good faith hackers because computer or software owners want to prevent security research or vulnerability disclosure. Security researchers have rights and defenses against legal claims, but don\u2019t always have access to representation or resources to defend themselves. EFF provides free legal counseling, ideally in advance of security researchers conducting their work so they can steer clear of problematic activity or at least mitigate the risk of legal threats. In litigation, EFF tries to find cases that will advance legal rights for the entire community, but many individuals will need representation even when their particular cases will not have a broader impact. In those cases, EFF endeavors to refer people to cooperating counsel, which can be difficult if funds are not available.\n\nWhat is it like, as a hacker, to face legal threats? What are the common ways hackers encounter legal threats? When that happens, what should hackers do? What is it really like to provide legal representation to hackers? Are there areas of the world with greater or lesser access to legal rights and representation? What resources can hackers leverage to protect themselves, their rights, and others in the community? Join us and find out!",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 2616,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230915"
  }

  This text was transcribed using whisper model: large-v2

   So, this panel is the hackers, the lawyers, and the defense fund.  I am Harley Geiger, and I am your moderator for this panel.  There is unlikely to be a hacker at this conference that has not contemplated at some point the  potential legal trouble that they may face as a result of good faith security testing.  And many people have experienced this directly themselves, and many more will experience  it at some point in their hacking careers.  So, one of the things that makes the security community so effective is that it is always  pushing the boundaries of permissible behavior.  And by pushing that boundary, it helps define that boundary, it also creates space to innovate  and to simulate criminal attacks so that we can better prepare ourselves to defend and  preempt those very attacks.  This is how we fix vulnerabilities before malicious actors get a hold of them.  In many ways, the laws recognize this now, and are working to accommodate this kind of  security research activity.  But we're seeing more coordinated vulnerability disclosure in laws in the United States, at  the state level, abroad.  However, we are also seeing that the hacker continues to face legal threats from various  sources like the governor of Missouri threatening a newspaper.  And some of these are bogus, or empty, but some are also quite serious.  So what is it like for a hacker that faces legal threats?  And what sort of resources are available for security researchers that run into legal complications?  So for this panel, we're going to hear first from a hacker that has lived this and faced  legal threats, that is Miles McCain.  Second, we'll hear from Charlie Schneider from Google about how the ecosystem benefits  from the work of security researchers, and that the chilling effect that legal threats  can have.  Third, we'll hear from Kurt Opsahl.  He is the Associate General Counsel at Filecoin Foundation, and has provided legal representation  to many security researchers.  Then we'll hear from Hannah Zhao from the Electronic Frontier Foundation about the ways  that EFF provides legal services to hackers through the Coder's Rights Project and impact  litigation.  And then lastly, we'll hear again from me about the Security Research Legal Defense  Fund.  This defense fund was recently launched, and aims to provide funding for the defense of  good faith security research.  So one last thing before we kick that off, which is that nothing you hear on this stage  should be construed as legal advice.  You do need a lawyer, lawyers are really great, but they're not sitting up here at this moment.  So Miles, if you wouldn't mind, please introduce yourself and tell us your story.  Awesome.  Thanks everybody.  Hey everyone, I'm Miles.  I am a college student, open source software developer, and enthusiast security researcher.  Right now I'm just going to briefly share my experience receiving a legal threat for  good faith security research, and then I'm going to zoom out and talk about some key  takeaways that I had from this experience.  Before I do that, I want to give a shout out to Adi right there, and the whole Stanford  Applied Cyber Security crew.  If you want to stand up and just wave as I say this.  Adi was one of my co-conspirators on the Vuln disclosure that I'm about to talk about, and  we would not have been able to stand up for ourselves in the way that we did had it not  been for the amazing support of the Stanford Applied Cyber Community.  So thanks for being here.  All right, so this is a fun story.  Last October, a Stanford student startup called Fizz was getting super popular on campus.  This was an anonymous social media app that claimed to be 100% secure.  What could go wrong with something like that?  Well, me and a few security-minded friends, Adi being one of them, we were drawn like  moths to a flame when we heard that.  And so one Friday night, we decided to evaluate whether Fizz really was 100% secure like  they claimed.  Well, dear audience, as you might be able to tell from me sitting here, they were not.  Within a couple hours, we were able to gain full read-write access to their database where  they were storing all posts and users and everything you could imagine entirely de-anonymized.  100% secure.  All right, so at this point, we did what any good security researcher is supposed to do,  which many of you have probably done, which is that we responsibly disclosed what we found.  We wrote a detailed vulnerability disclosure report, we suggested remediations, and we  also proactively agreed to not talk about our findings until an embargo date, which  was fair amount in the future.  We wanted to give them time to fix the issues.  And we sent them the report via email.  At first, they were super grateful.  They said, hey, fixing these issues is our absolute top priority.  And every couple weeks, I guess every week or so, they would send us an update.  And then one day, they sent us a threat.  This was a crazy threat.  I remember it really vividly.  I was just finishing up a run, and I looked at my phone, and my heart rate went way up.  That is not what's supposed to happen after you finish a run.  In the threat, they said that we had violated state and federal law, we had conspiracy to  commit a felony.  They also brought up the Stanford Disciplinary Code, which I thought was pretty odd.  And then at the very end of their threat, they left a demand.  Don't ever talk about this publicly.  And if you agree to never talk about this, then we will not pursue legal action.  Well, as you can probably tell by me sitting here, we did not agree to that demand.  And I'll talk about why.  But clearly, they wanted to scare us into silence.  So what do you do when you get a letter like this?  Well, I totally freaked out.  I was angry and scared.  I'm usually a try to be a pretty level-headed person, but this was something different.  The very first thing that our friend Cooper, who was another of our co-conspirators, said  in our disclosure group chat when we got the threat was, stay calm, don't do anything fucking  stupid, we're going to need a lawyer.  And if you can't tell from this advice, this was not Cooper's first time receiving legal  threats.  So we started asking for help in our network.  And within a few days, we were connected to Kurt, who's sitting right here, and Andrew  Crocker at the Electronic Frontier Foundation.  And after talking with them a little bit, Kurt and Andrew generously agreed to represent  us in our response to the letter pro bono.  So we walked them through our disclosure and our documentation, and with their advice,  we made the decision to not cave to the threats.  Also, hey, I see a big crowd of AC people who just walked in.  Love y'all.  And so Kurt and Andrew drafted a response to Fizz, and they totally shut the threat  down.  And as an aside, the Stanford Daily published both the threat and our response.  This is public.  I really recommend you read it if you haven't.  Anyway, after we responded, the Fizz team asked to meet, and we were able to resolve  the situation amicably.  We pushed Fizz to proactively disclose the vulnerability to their users publicly, which  they did eventually do.  So taking a step back, getting a legal threat for our good faith security research was incredibly  stressful.  And the fact that it came from our classmates just added insult to injury.  And I have three sort of key takeaways from this experience that I want to share.  First, keep your research above board and really well documented.  Ahead of time, think about what you're trying to accomplish, write it down, and make sure  that you don't cross any ethical lines.  A big reason why we were able to resolve the situation amicably was because we played by  the rules.  We didn't save or leak the data that we had access to.  We didn't mess with anyone's account.  We didn't cause any damage.  And we kept really detailed documentation of absolutely everything we did.  And that clean documentation helped us as we were writing our disclosure, and I imagine  it also probably helped Andrew and Kurt as they were drafting the response.  Second thing, stay calm.  I cannot tell you how much I wanted to curse the Fizz team out over email.  Oh, my God.  But no, we had to keep it professional, even as they were resorting to legal scare tactics.  Your goal when you get a legal threat is to get out of it, to resolve the situation amicably,  to not go to jail.  That is it.  And the temporary satisfaction of saying fuck you while absolutely real is just not worth  giving up the possibility of resolving the situation amicably.  And the third and final takeaway is get a lawyer.  And I'm not just saying that because I'm on a panel with a bunch of lawyers.  We could have tried to navigate this process on our own.  But that would have been an absolutely profound mistake.  They would have escalated.  After all, they were banking on us being naive and falling for their scare tactics.  But thankfully, Kurt and Andrew stepped in and really saved the day.  Now, I recognize that not everyone has the ability to get the Electronic Frontier Foundation  to represent them pro bono.  And they don't have the ability to represent everyone who faces a legal threat.  But there are an increasing number of resources available for good faith security researchers  who do receive legal threats.  We're going to be talking about those on this panel.  And you should absolutely try to make use of them.  Do not try to fly solo.  Now I will hand it off to Charlie, who is the head of security policy at Google and  who has spent a long time on the other side of the vulnerability disclosure process.  Thank you, Myles.  So yeah, so as Myles said, I kind of am here to represent the other side of the equation,  the bug collectors.  And throughout my career, I've had the privilege of collecting bugs from skilled researchers  all over the world.  And my career has been spent exclusively in very, very large organizations who, in theory,  hold a lot of power and leverage over hackers.  And so at the Department of Defense, I helped found and manage the first bug bounty pilot  called Hack the Pentagon, and I wrote their first vulnerability disclosure policy.  Later I worked at a financial institution where I led researcher engagement in their  bounty programs.  And now at Google, I get to work with our bug collector teams all over the company.  And in all of these experiences and throughout, I've seen kind of firsthand the power and  leverage that organizations like mine can hold over researchers.  Even before we could found and start the Hack the Pentagon bug bounty pilot, I first had  to kind of search through the massive defense department bureaucracy to identify who within  the department had been machine gunning out cease and desist letters to anyone they could  find who had been scanning any part of our Slash 8 IP ranges.  So talk about sending a mixed message as you're trying to get a bug bounty program started.  And during the first bug bounty, one of our very top contributors to the program who I  believe has continued being one of the top contributors to all the various kind of DOD  vulnerability disclosure programs was an individual who ran afoul of US computer hacking laws.  And he served his time and he got out and was in the first wave of people to raise their  hands to contribute to government security in kind of the first bug bounty.  And I think that took a lot of courage to have gone through what that person did and  faced those risks and still come back to help us.  And at Google, we see there as well kind of the power that companies have to chill security  research.  Sometimes we receive reports from researchers for bugs in other companies' products because  those researchers are afraid of what those companies might do, their reputation on disclosure  issues and so they come to us instead.  And I think that's really unfortunate and that's ultimately those companies' loss and  I think it's all of our loss if hackers can't contribute.  From a bug collector's perspective, we want hackers to be able to engage on an equal footing  with us without fear of legal reprisal.  With more kind of legal certainty in the equation, we can have more open and deeper collaboration  and conversations and ultimately from a company's perspective, we're going to get more and  better bugs and each new report gives us an opportunity to close off an avenue of attack  and protect users.  But when vague laws and companies behaving badly allow kind of the creation of this chilling  effect on security research, I think ultimately the only ones who truly win are attackers  and it's users who lose.  So that's why I'm super excited to be here and why I'm glad that the Legal Defense Fund  exists now and I think all companies and all kind of bug collectors should be glad it exists.  So I'll turn it now to Kurt.  Hey everybody.  Is this on?  Doesn't appear to be.  Hey everybody.  Ah, that is on.  Hey, my name is Kurt Opsahl.  I'm the Associate General Counsel for Cybersecurity and Civil Liberties Policy with the Filecoin  Foundation and I also volunteer my time with EFF as a special counsel and for many, many  years I was working with EFF on the Coder's Rights Project.  I've been in this community trying to help other legal situations since the Alexa Park  days back in DEF CON 13 was my first one.  We had an exciting time with security researcher Mike Lynn at Cisco and some disputes over  a program that had to be physically removed from the program book due to some threats.  And I've really enjoyed working with like countless people in the security research  community and how to help them out, avoid situations or deal with situations that occur.  So I want to talk to you a little bit about some of that experience.  So just to set the stage a bit, sort of broadly speaking, there are two types or categories  of legal issues that come up for security researchers.  The first are issues around doing the research itself.  Legal issues that may arise because of, you know, are you, you know, hacking onto someone's  system?  Will that be considered an intrusion?  Is there a anti-circumvention issue arising out of the Digital Millennium Copyright Act?  An end user license agreement or terms of service will have a potential contractual  provision that might go on.  If you're doing wireless research, it may involve getting contents of communication,  which brings up what the law likes to call wiretapping.  And so there's, you know, a host of issues that can come up in the course of it and how  you navigate those in order to minimize risk.  And the second large category is the disclosure.  And this comes out where, you know, if there is a vendor or a commercial entity, especially  who you are exposing a vulnerability, they may become sad and upset.  Now, these days, it's actually fairly well established for technology companies that,  you know, people who've been around this space for a long time receiving bug reports.  They may have a bug bounty program that's been going on successfully for a long time.  And this has been a really great, you know, advantage to the community to have bug bounty  programs that you can look at, see what the rules are, work with it, have points of contact.  But it's not always the case.  More old school industries, sometimes I call it first contact situations, the first time  that they have been reached out to by the security community to say, you know, your  security is broken.  People can, you know, see all this info.  And sometimes they panic, or they want to make sure this shuts down, or they think of  it from a sort of a comms point of view, a communications point of view of trying to  not have that communication.  So, the good news is for disclosing vulnerabilities, if you disclose truthful information about  a vulnerability, that is strongly protected by the First Amendment.  You know, it is hard for someone to build a case around saying you should not say something  which is truthful, even if that is something that is embarrassing or awkward.  But some of the tension arises is that these two issues can be interrelated.  One of the issues is that if perhaps there was something that was towards the edge of  legal lines or can be construed that way in the course of doing the research, publicly  disclosing it, well, one, if done uncarefully, might involve admitting to things on stage  that can and will be used against you.  But also, even if you did play by the rules, you did it well, there's a threat of litigation  over it, and the possibility that you'll be sort of facing a very awkward situation  getting these threats that may worry you, not about the legality of the disclosure,  but that they may go after you for the underlying research.  So, what should hackers do in these kinds of circumstances?  Well, a lot of it, first of all, have a lawyer with you at all times.  But that is somewhat inconvenient and hard to do.  So, it's a question of like, when should you reach out?  And also, what can you do to help mitigate some of these things as early as possible?  And so, when I talk to security researchers, some of the advice is very dependent on what  stage things are at.  If it's early on, you can minimize the risk in doing the research itself.  So, for example, if it's a hardware bug you're trying to find, if you own the hardware, then  that resolves whether you are intruding on somebody else's hardware.  You'd be amazed at the number of machines that you can buy on eBay that, like, if you  wanted to test, say, you know, voting machines in the early days, it was very hard to get  cooperation from the voting vendors, but you could buy used voting machines on eBay.  Someone was doing a test of some TSA scanning machines.  It turns out those are available on eBay as well.  So, you can do a lot of that stuff.  Wireless communications, well, you can minimize risk around wiretapping by just having your  own communication, that is to say, where you've consented, or you and your buddy, but not  doing it more broadly to strangers.  So, there's a lot of things that can be done early on, though sometimes our first contact  with a researcher is after some of that research is done, and it's about trying to navigate  the path forward.  But I would say one of the things you can and should reach out, if you have some questions  about that, reach out to the Coders' Rights Project at EFF, and Hannah will talk a little  bit more about that to avoid some of these problems.  But at the disclosure stage, I would say probably the key thing to start out with, if you're  about to disclose, is make sure that you get someone who understands security, or is an  engineer trying to establish sort of a geek-to-geek protocol, communications, not going through  marketing or legal, but with an engineer.  And sometimes people in this community know somebody there, or you can check the disclose.io,  has a list of points of contact.  But if you can have an engineer, they probably will understand it.  Even if it's an engineer working in an old school firm, it might be an internal advocate  for like, yeah, this is embarrassing, but this happens and we got to deal with it.  But sometimes the only path forward is going through a more public like comms channel,  or things get escalated, and that is a sign.  A sign things might be going weird, that is an excellent time to reach out for a lawyer  if there are signs.  If a lawyer is getting back to you, even if it's not a threat, if they're asking some  weird questions, maybe you want to talk to your own lawyer for a response.  As Miles was saying, document some things, especially if they are documenting things  that show that you did the right thing, you behaved properly, that you didn't mess with  customer information.  And also if they say nice things about how much they appreciated early on, save a copy  of those emails later, because in case things get weird later, it's good to have.  And most of the time, these things can be resolved, and everyone goes away ultimately  happy and there's some awkward moments along the way, but more often than not, it can be  resolved.  And even when there is this kind of, I say Barbara Streisand is your friend, the Streisand  effect, as many of you I'm sure know, is when the news about the dispute gets more  coverage to the issue than the issue they're trying to cover up would have gotten anyway.  And I think that helped to have the Stanford Daily publish the cease and desist and response  letters.  And also on my mind today is that many years ago, I think it was 2008, there was a presentation  here at DEF CON about a subway hack, the Charlie card and the MBTA, and the MBTA did  get very upset.  In fact, so upset they went to court, tried to get the talk shut down, they got a temporary  restraining order, and that led to the talk being replaced to a press conference about  how they had squelched speech about their security, which ultimately probably had more  people in attendance than your average talk and got it into big news.  So that's a strong incentive if someone is behaving rationally on the other side, that  them going ballistic on you will actually hurt them far more than trying to resolve  it amicably.  But of course, not everybody is rational.  And oftentimes we say that you can guess what a rational person might do, but your opponents  in litigation are not always rational.  And so that's when things step up to litigation, and one of the challenges is that while you  can get some great pro bono services, and I think definitely reach out to EFF, EFF can't  represent everybody in litigation.  Litigation is a much more time consuming and legal intensive process.  It can be fun as a lawyer doing this, but it is not fun to be the person in the litigation.  Even if you're going to win, it still sucks to be along the way, but it's good to have  counsel on that.  And so one of the things I like about the Security Legal Defense Fund is in those circumstances  where some money will help get an attorney that is where pro bono resources have been  used as best they can, but are not enough to have that fund available.  And hopefully it's one of those things that hopefully never gets used, but having it available  can help reduce the chilling effect that comes from these feasts and desist, these  often nasty grams.  Miles was just describing, it's just full of bluster and threats, and some of that bluster  is just trying to scare you.  Some of the ridiculously short deadlines, things like that, trying to induce panic.  And part of that is the bullying that's going to go after someone who is not represented,  sees the scare thing, and just stops speaking about it even though they have every right  to.  And so having some of that reassurance available can help out and make sure the talks continue  to happen.  And so the good news on the MBTA is I was just seeing yesterday that some other researchers  also found some problems with the Charlie card on the MBTA.  And this time they were very nice to the researchers.  They listened to what the vulnerability was.  They talked it through politely.  And so things can change and get better.  And it went from a bad first contact situation to now the way we'd like to see vendors,  researchers working together to solve this common problem we have of security.  And one last thing before I pass this on, we talk a lot about, I'm a US lawyer, I've  talked a lot about the situation in the United States, but security research is a global  phenomenon and is done all over the world.  And one of the things that is cool about the United States is there's a long tradition  of pro bono legal representation.  And a lot of lawyers, even ones who work at big law firms and such, see it as part of  their job to give back some of their time to the community through pro bono work.  But this is not a universal tradition.  And in many places around the world, your choice is, pro bono counsel is not readily  available or not available at all.  And so that is another reason it's good to have some funding available to try and help  people who are in a bad spot somewhere outside of the US.  So with that, let me turn it over to Hannah.  Hi, everyone.  Hi, everyone.  My name is Hannah Zhou.  I'm a staff—excuse me.  I'm a staff attorney at the Electronic Frontier Foundation, and I'm part of EFF's Coders'  Rights Project.  So I'm going to talk a little bit about Coders' Rights Project, the kind of help that we offer  to security researchers, and the kind of counseling that we can provide for you all.  So first, EFF, I'm sure a lot of you are familiar with, but it was actually founded over 30  years ago in order to defend developers and programmers legally.  So Coders' Rights Project currently continues that tradition of representing and counseling  tinkerers and hackers and people who want to innovate while protecting their rights  and promoting innovation.  So if you are someone who is doing security research, what happens when you need help?  How should you reach out to us?  Well, there are several ways that we get our clients at the Coders' Rights Project.  The first way is through intake, which is our email, info—I-N-F-O—at EFF.org.  You can email your questions there and say that you're seeking legal counsel about your  issue.  Those emails that we exchange thereafter will be privileged, and so you can disclose a  lot more information so that we can help you.  Another way that we get folks is through an informal referral network.  So this means that people might say, sort of like what happened with Miles, you know,  people are asking around, maybe they're in some sort of trouble or they receive a cease  and desist letter or something like that, and other people will say, well, I know someone  at EFF, or you should reach out to EFF, and those folks reach out to us.  And then the last way that happens all the time is here at conferences like DEF CON and  other security conferences, where people will come up to us after our talks or come  up to the booth and say, hey, we have these issues, and we can give our contact information.  So, again, please do not talk about the possible felony that you committed in a room full of  people, but we will have a private conversation instead about it so that we can ensure that  your privilege is protected.  We do get a lot of requests through intake.  We are able to provide counseling for the vast majority of folks who reach out to the  Coders' Rights Project.  And what that means is that we will sit down with you, we will get information from you  to make sure we have no conflicts of interest.  Then we will get, you know, details on what you did, how you did it, and what exactly  your worries are and what your goals are.  And we will tell you about the legal risks, the possible, you know, laws that could be  invoked by adverse parties, and the different things that, you know, could happen and what,  you know, whether they're more likely to happen, less likely to happen.  It's hard to do talking absolutes in the law, but we can definitely give you an idea  of what your choices down the road can bring.  So, when should you reach out?  Well, the earlier, the better, because the earlier you know, if you have even an inkling  that maybe there might be some legal problems down the road, you shouldn't wait until you  get that cease and desist letter.  Reaching out early is really helpful because we can lay out the path before you, and you  can make informed decisions based on your risk tolerance and your priorities about what  actions you want to take and what actions you don't want to take, because now you know  what kind of risks those decisions can bring in the future.  So, earlier is always better.  As was mentioned before, EFF doesn't always represent our coders' rights clients in litigation,  and the reason for that is because EFF is an impact litigation firm, and that means  we are always either trying to make good law with cases or trying to prevent bad laws from  happening with cases, and so that means that when we are thinking about what case to take,  we think about things like the facts of the case, whether they are good, whether they  might be in a good jurisdiction, who are the judges that are likely to listen to this case,  and whether those judges are friendly to the arguments that we're making.  So, those type of considerations come into play, and the reason we can't take on everyone  is because we have limited resources, and there's a saying in Chinese that says you  need to use the good steel on the blade of the sword, so you don't want to use it for  the hilt, you don't want to use it for the sheath, you want to use it on the blade itself,  because we have limited resources, we really want to make sure that we're creating the most  impact when we spend those resources. Now, individual representation, on the other hand,  means you want to fight the best for your individual client. So, I used to be a public  defender before I joined EFF, and no matter who my client was, I had to defend them. I made the  best legal arguments I could for their case. I don't think about things like, are those  arguments good for the community? Whereas, with impact litigation, you think about, are the  arguments we're going to argue going to be good for the security research community as a whole?  So, that's another reason why we don't take on every one of our counseling clients as our  litigation clients. But that's not to say it never happens. Just a couple years ago,  Cara Cagliano, another member of the coders' rights team, as well as I, we represented  another college student, actually, who was also a security researcher. He looked into the code  of the proctoring software that his university used, and he realized there were references in  that code to functions that Proctorio, the proctoring software company, claimed that they  don't have in their software, and that they never do. So, he posted the snippets of those code  online, and criticized the company. Proctorio took a bunch of different actions to take down  the criticism, as well as the code, and he came to us, and we began to counsel him on how to help  him respond to the takedown notices, so that his code gets, and his criticism gets posted  back up on Pastebin and GitHub. And later, as we were in the process of counseling him,  we actually decided to take him on as a client in litigation, and we filed a suit against Proctorio  for what it was doing. And the reason that we did that was because that this case had a lot of  specific facts about it that was good. First, we think that it's very important to protect  security researchers when they expose hypocrisy and inconsistencies in a company's claims versus  what its software seemingly is actually doing, and we think that it is good for the security  research community as a whole. On top of that, it also concerned various other issues that EFF is  involved with, including student privacy and copyright. So, like I said, it's not impossible  for us to take on our counseling clients as direct litigation clients, but it doesn't happen  all the time. And with that, I will hand it off to Harley.  All right. So, I'm going to talk about the Security Research Legal Defense Funds and sort of round us out.  We may or may not have time for questions because of the sound issue earlier, so we're running a  little bit behind, but we'll get to it if we can. I am Harley Geiger, and I am a counsel at Venable  LLP. I work on cybersecurity and privacy law and have been doing so for about 15 years, and I'm  also the coordinator of the world's first security research legal defense fund. I'm going to talk  about that as a resource that security researchers facing legal threats are able to use. So, the  defense fund is an independent, non-profit organization. The defense fund is intended to help  individuals who face security threats due to good faith security research—sorry, I said security  threats—legal threats due to good faith security research or vulnerability disclosure. The defense  fund is not going to provide direct legal representation, so it's not going to act as your  attorney. You know, you have to find your own attorney. However, the defense fund will provide  funds for legal representation if you meet certain criteria. So, some of the criteria for being  eligible are mostly—these are mostly centered around making sure that the defense fund is  independent and acts in the public interest. So, one, the defense fund has an independent board.  The board approves who can qualify for funds. The board is presently Amy Stepanovich from the  Future of Privacy Forum, James Dempsey from UC Berkeley, and Kurt Opsahl from the Falcoin  Foundation. Security researchers—second criteria—security researchers have to show some  financial need. They don't necessarily need to be completely indigent, but in order to get community  funds, to be fair, there has to be some sort of financial need. And then, as I mentioned a little  bit earlier, the defense fund aims to help individuals for threats related to good-faith  security research and vuln disclosure. So, in that definition, loosely, is testing or investigating  security flaws for the purpose of enhancing the security of the devices, the users, or the systems.  The defense fund has to act in the public interest, and so it's not going to defend—even if you're  normally a good-faith security researcher, if you commit an act of extortion, you know, or if you  have deliberately harmed the system or exfiltrated PII, things like that, then you may not qualify.  Malicious attacks cannot qualify. So, as an example, an independent hacker finds a  vulnerability in a smart product. They reach out to the product manufacturer to disclose the  vulnerability. The manufacturer threatens a lawsuit against the hacker unless they sign an NDA  about the vulnerability, and the hacker has an attorney, but can't really afford to resist the  lawsuit. Uh, so the hacker can reach out to the security research legal defense fund and ask for  help. The defense fund will hear the background of the, uh, of the threats, and the board will vote  on whether or not to help the hacker push back on the threat of lawsuit. Uh, if the board votes yes,  uh, then it will help pay security and court fees for the hacker. So, our vision is that the  security research legal defense funds will help deter unfounded, uh, or over-aggressive legal  threats against hackers that are acting in good faith. Uh, we also expect that this will help cut  into the chilling effect that security researchers face, uh, if they know that this resource is out  there to potentially help them if they're acting in good faith. And then lastly, uh, we view the  defense fund as encouraging, uh, hackers to model good behavior. Uh, because you will not qualify  for the funds unless you are acting, uh, in good faith and doing good faith security research. Uh,  so a note on the status and how the community can help, and then we'll see if we can take  questions if we're allowed. Um, so the security research legal defense fund has launched. Uh, it  is operational. Uh, you can visit the website now at securityresearchlegaldefensefund.org, or if  that's too much, uh, s-r-l-d-f dot org. Uh, we have applied for 501c3 charitable status with the  IRS, and of course the legal defense fund, uh, is a fund. And so the funding model for the defense  fund, uh, is driven by community donations, and so the community is in a position to help itself.  Uh, those donations are tax deductible, and I believe, uh, Google has an announcement to make  on, on the donations to the fund. Sure, yeah, and so I actually have, uh, kind of two PSAs and, uh,  and one announcement. So first is a public service announcement for, uh, fellow corporate  overlords in the audience, uh, different companies, uh, consider finding a way to,  to donate to the program. Uh, second PSA is for researchers that, uh, if you are inclined to  donate bug bounty winnings for, for any reason, either, you know, for its own sake or because  maybe by the terms of your employment contract, you're not allowed to accept winnings, consider  donating to the funds. And I'm happy to announce that, uh, any researchers in our Google Bug  Hunters program that opts to donate to the fund, uh, Google will, uh, quadruple, uh, that donation.  That's amazing. So beyond donations, uh, the community can also help just by letting other  people know that this resource is out there. Uh, we need awareness in order for this to best serve  the community. Um, so that's it. I hope that you enjoyed this panel and I hope that you find it  inspiring that the security community has these champions, uh, like Kurt, like, like Hannah, like,  like Marsha Hoffman, you know, and others who have been defending security researchers for so many  years, uh, and hope that you, you find it inspiring that you have these assets like the Coder's  Rights Project or the Security Research Legal Defense Fund and key supporters like Google, um,  who are, are out there trying to ensure that good faith security research helps the community. I  think we should take pride in knowing the progress that the community has made. Uh, together we're  strong and we will continue to secure the world. Uh, if we can take one or two questions before  dissipating, is that, I'm not sure if that's, can I get a thumbs up or a thumbs down? I think I have  a thumbs up. All right. Two thumbs up. Uh, let's take questions. I will say though, please don't  discuss a personal legal situation in your question. Um, privilege does not extend to the  DEF CON floor. We have a question. It appears we do not have a microphone for this fine gentleman,  so you're going to have to scream.  While my information security team is figuring out how their apps work,  um, in this case, um, because we didn't want the illegal proceeds to trace back to me,  I donated it to charity. Um, my violent alternate ego went to jail in Europe.  Um, um, and it was a very nice event. Thank you. Um, but because we're taking donations,  can we take it in Bitcoin? Uh, first of all, you sound like you have a really cool job.  Second, uh, you know, whether we take it in Bitcoin, I don't see why not, but that's going  to have to be something that will be discussed at the, at the board level. I think right now  the, uh, I don't think that we have the mechanism for that. Um, but I think that cryptocurrency,  I mean, EFF also takes donations. We do take cryptocurrency donations. So yes, I think,  I think, uh, eventually now whether we want to take it from a shadowy quasi person who has been  collaborating with, uh, with, with people who are possibly under sanction, that's, that's a  different matter, but thank you. All right. I think we need to go to make room for the,  for the next panel. Thank you all so much. We really appreciate you being here.


url: https://www.youtube.com/watch?v=j8ZiIOd53JU
title: DEF CON 31 - The GitHub Actions Worm - Asi Greenholts
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=j8ZiIOd53JU",
    "title": "DEF CON 31 - The GitHub Actions Worm  - Asi Greenholts",
    "description": "GitHub is the most popular platform to host Open Source projects therefore, the popularity of their CI/CD platform - GitHub Actions is rising, which makes it an attractive target for attackers.\n\nIn this talk I\u2019ll show you how an attacker can take advantage of the Custom GitHub Actions ecosystem by infecting one Action to spread malicious code to other Actions and projects by showing you a demo of POC worm.\n\nWe will start by exploring the ways in which Actions are loosely and implicitly dependent on other Actions. This will allow us to create a dependency tree of Actions that starts from a project that we want to attack and hopefully ends in a vulnerable Action that we can take control of.\n\nWe will then dive down to how GitHub Actions is working under the hood and I\u2019ll show you how an attacker that is in control of an Action can utilize the mechanism of the GitHub Actions Runner to infect other Actions that are dependent on their Action and eventually infect the targeted project.\n\nFinally, after we\u2019ve gained all of the theoretical knowledge I\u2019ll show you a demo with POC malware that is spreading through Actions and we will talk on how to defend against this kind of attack.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 2422,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230917"
  }

  This text was transcribed using whisper model: large-v2

   OK, let's start. Hi, everybody. Today we're going to talk about, OK, maybe I won't use  it. OK. Today we're going to talk about some GitHub Action worms. So this talk is going  to be very technical. Can you hear me good in the back? Yeah? Woo! Let's go. I try to  not lose you. If you get lost, you'll have something that will show you the progress  bar on the bottom of the slides. And this is basically a result of research I did. It  took about three months. My basic goal was to find a new way to attack CCD pipelines.  And this is what I came up with. This is a new way which will understand slowly the real  impact and the scale of it. So a bit about myself. My name is Asif Reynolds. I'm a security  researcher currently at Palo Alto Networks. I have around eight years of experience in  cybersecurity. I've done incident response, SOC, security architecture, and, of course,  application security. For the last two years, I've been working for CIDR security, which  was acquired not too long ago by Palo Alto Networks. And I research CICD security and  all the things that revolve around it. So let's talk about some notable projects I've  been a part of. So the first one is the Top 10 CICD Risks. This is a project we released  about a year ago, and it was embraced by OWASP. You can find it on GitHub, also on OWASP's  website. The second one is the CICD Go. This is a deliberately vulnerable CICD environment,  basically a CTF, in which you can hack a real CICD environment that's being installed on  your local computer. You can find it on GitHub, download it, play with it, and learn how to  hack CICD pipelines. Now, before we begin, let's do a quick overview of what GitHub Actions  is. So how many of you are using GitHub Actions, by a raise of hand? Okay, that's a lot.  Nice. So I'll do this quick, and we'll just get everybody to the same page. So GitHub  Actions is a continuous integration and continuous delivery platform, CICD, that allows you  to automate your build, test, and deployment pipelines. You can see on the left side, there  are events that can trigger pipelines, such as push, pull request events, and so on. And  pipelines in GitHub Actions are called workflows. Workflows can contain multiple number of  jobs, as you see. Each job is running on a different runner, and on each job can contain  multiple number of steps. Each step can contain a bash command or an action. What is an  action? An action is basically a code package that allows you to use someone else's, let's  say, library to execute some stuff in your pipeline. For example, you want to do something  that probably everyone does, like checking out the code from the repository to the runner  itself. You don't want to develop it yourself. Someone else probably already developed it.  So you can use an action that checks out your code from the repository to the runner  itself. Now, let's see an example of a workflow, a simple one. So let's start with the first  part. So we have the on keyword, which is the triggers of the workflow. Here it's triggered  by a workflow dispatch, which is a manual trigger, push to the main branch, and pull  requests. Pretty easy. Next, we have the jobs. We have only one job here. It's called  check links, and it's running on an Ubuntu virtual machine. Next, we have the steps. So  here we have the first step that checks out the code, and it uses an action. The name of  the action is actions slash checkout at v3. Now, what v3 means, it's the version of the  action, and the actions slash checkout is the organization slash repository. So actions  are contained in a GitHub repository, and this is how you reference them and how you  call them. This specific action was written by GitHub themselves. The actions organization  is an organization that's maintained by GitHub. Next, we have the setup node step, which uses  a setup node action, which also receives two inputs, as you can see here. Actions can  also return outputs, which is nice. Simple stuff. And next, we have a bash command that's  using to do NPMCI, install the dependencies of the package here. And after that, we see a  third-party package. This is a package that was written by someone on the internet and  published as a public repository, and we're using it here. You can see at the end, there's  a different reference type. This reference is a hash commit of the repository. We'll  go later exactly into what it means and how we can use it, but this is the basic idea  of workflows. And here you have a screenshot of the GitHub marketplace and specifically  the actions. When I took this picture not too long ago, there was around 19,000 actions  on the marketplace. The vast majority of them is actions written by the community. Some  of them are written by GitHub, some of them are written by vendors, but the majority is  written by kind people on the internet. So let's talk about the worm itself now, finally.  So in order to understand how to build the GitHub Actions worm, we need to understand a few  parts of the puzzle, which we will build during this presentation. And the different parts  are initial attack vector, action dependencies, action to infect actions, and finding attack  graphs at scale. Now, if this doesn't mean anything to you right now, you'll understand it  in a few minutes, but we'll go through each one of them, basically completing the puzzle,  and when the puzzle will be finished, we'll be able to show a demo of the worm itself  attacking repositories. So let's start with initial attack vectors. So most of the CICD  attacks that happened up until now were done kind of in a similar fashion. Basically, attackers  compromised a repository or a package or some kind of a project, and they infected it  with code that is used to directly infect the direct dependence of the package. Let's show  some examples. So one of them will be to exfiltrate environment variables when the package  is being run, to steal maybe secrets from the pipeline execution or from production  environments. Second thing may be to run a reverse shell. When this package is being run  in production, it will start a reverse shell, allowing attackers access to production  environments, but when they compromise a package, they basically only affect the direct  dependence. And let's see a few examples of how to compromise GitHub repositories  specifically with some known attack vectors. So we're going to talk about three attack  vectors. I've implemented scanning automatically for those attacks to look for vulnerable  repositories that are vulnerable to those attacks in my research. So this is the reason they're  only relevant. They're the only ones relevant for this presentation, but of course there are  more. So let's go through them. The first one is reprojecting. What is reprojecting? On the  left, we have a repository that's using the action in the middle. The action is part of an  organization, and let's say one day the maintainer wakes up and decides to move the action to a  new organization. Nice animations. So what happens next? The repository makes a request to the  action, and GitHub automatically redirects it to the new repository. That's great, right? But  what happens when the maintainer decides to delete the old organization? Well, when it doesn't  exist anymore, an attacker can come and basically register the same organization name and  same old repository name. When another request is being made by the repository, it will cancel  the redirection, which will actually compromise the repository that is using the now  malicious action instead of the original one which was moved or maybe deleted. Now, GitHub  knows of this issue, and they've made a mitigation. They retired the namespaces of projects  that had more than 100 clones in the week leading up to the account's deletion or renaming,  but still, it's not foolproof. It's not still tight. There are still cases which repositories  are re-projectable. We won't talk about why, but I'll show you some real examples of  repositories that are re-project, but it's still possible. So just know this for now, and you  can look it up later. The next one is NPM email hijacking. So here we want to basically  hijack an NPM package. How can we do it? So we pass the package log JSON over a repository,  getting all the packages that the target repository that we want to compromise is using. For  each package, we'll send a request to the NPM registry to get the manifest of the package.  Inside the manifest, we find a few interesting things, the maintainers and their emails. For  each email, we can send a request to check if the domain of the email is available for  purchasing. Basically, the maintainer created an email for themselves, and they forgot to  renew the domain, or the domain got expired or deleted or something like that. And if it's  possible to buy the domain, we buy the domain. We can then set up a mail server, redirect  the emails to our inbox, and reset the maintainer's password. Now, this is only possible on  accounts that don't have two-factor authentication, but still, a lot of accounts don't have  two-factor authentication, and of course, I'll also show you a real example later. Now, NPM  also knows of this issue, and this is a snapshot from their documentation, and they're  saying that they periodically check if packages have expired domains, and if so, they  disable the account from doing password resets. The issue is that today, there are on NPM  around 2.5 million packages, probably huge numbers of different domains, and it's pretty  hard to scan them daily or even weekly. I don't know how long they're doing it for, but  let's say you're an attacker, and you want to target specific packages, and you scan them  even hourly, if you have a few packages, and you check if the domain is expired or  something like that, and you can buy them before NPM makes their checks, you can still  take over the package and do this attack, of course, if they don't have two-factor  authentication. And the last one is command injection. So here we have a code snippet  from GitHub Action. You can see here a simple configuration of the Git client, and then  pushing some code to the repository. Now, in the line with the red box, you can see that  it's using something that's called context. So as I told you, GitHub Actions, GitHub  workflows, when they're triggered, they're triggered by an event. The workflow itself  receives the event in the type of a context, and it can access some fields on the events  and get data about what triggered the event itself. So for example, one of the events  that are available is the author email of the head commit. Now, who controls the author  email of the head commit? Whoever did the commit, and not the maintainers of the repository.  So they can write anything they want there. One of the funny things they can write in  the author email of the Git commit is this string. What is this nice string? This is  basically command injection. We write an email. We do like a small back tick before and  after the code command. We download a malicious bash script and execute it inside the pipeline.  So you simply do that on your computer, push the code with this nice email, and it will  cause this code snippet here to execute your code, download the bash script, and execute  malicious stuff, which is nice. Now, of course, there are more attacks. As I've told you,  some of them are dependency confusion, public PPE, and just creating a malicious pull request,  hoping the maintainers will merge it. Now, you think maybe this is crazy, but actually  someone did it to the Linux project about a year or two ago. They didn't like it so much,  but they actually successfully committed malicious code with a vulnerability to the  Linux project. And, of course, there are more. I won't get into what each of those attacks  are. You can look it up on Google, but just know there are more possible ways. Now, how can  we further our attack? We just understood how to compromise a single repository. Of course,  here we're going to talk about worms. We want to compromise infinite repositories. How can  we do that? So next thing we'll talk about is action dependencies. Now, there are a few  types of actions, three types to be exact. The first one is a Docker action. You can  see here it's using a Docker file. You can also use a Docker image to define what the  action does. Now, what you're seeing here is the action YAML file. This is a file that  sits at the root of the repository that defines what the action actually does. So this is  like the main function of the action. So this is simple. Next, we have a JavaScript  action. You can write plain JavaScript, and this is also relevant for the NPM email hijacking  attack because if an action uses JavaScript, it has a dependency that we can hijack. We  can hijack the action. And the third one, which is important for the dependency part,  is a composite action. Now, composite actions can use other actions as part of their logic,  and they can also execute bash. So this is the first type of dependencies between action.  A composite action can actually depend on other action and just execute it when it's  been executed. Now, what is the second way actions are depending on each other? Actions  are stored on GitHub. They obviously need their own CACD. And most of the times, what  CACD platforms do they use? GitHub Actions, of course. So here's an example of a GitHub  workflow of an action. You can see that it uses other actions. Well, this is a dependency  not in a similar fashion that we know like code libraries. This is kind of an implicit  dependency. Now, the action that this workflow belongs to is depending on the actions that  are being run inside its workflow, but it's not part of the code itself. Now, as you saw  in the snippet that I've showed you of the command injection, maybe it has some permissions.  Maybe we can, by compromising an action in the workflow, push malicious code to the repository.  Maybe we'll see it. Maybe not. Maybe nothing will work. So this is the other way actions  are dependent on each other, using other actions in their CACD. Now, what we can do is basically  take those two files, pass them, and build a huge tree on Neo4j of action dependencies.  And this is exactly what I did, and this is how I do art. I don't know how to paint, so  this is my art. I create flowers of dependencies using GitHub Actions. I promise you this is  a random query of the database. I didn't make it by myself. So what we're seeing here are  action dependencies. We can see a repository with a purple node. Now, we pass the files  and we can see all the action usages. Each orange node of an action usage is an action  which comes from a repository. So we have a purple node that's connected to an action  usage node, which is connected to the repository of the action being used, and so on. It goes  recursively, and you can see in this beautiful flower that we have all the actions on the  outer side of the flower that are dependent on the one in the middle, which is nice.  Let's see the same graph in a different way. This is the same graph. Now, here we want  to target the repository on the left. How can we do that? Let's say we have some weak  link in the chain. Some action is using another action, which uses another action, and the  other action was created by someone random on the Internet. They probably made it. They  didn't make so much effort to secure it, so on. So we can maybe compromise it. And by  compromising that action, potentially we may be able to climb up the tree, infect all the  actions that are dependent on it, and reach our target. Now, how can we do the initial  infection of the weakest link? This is by the, you can see the line that is missing  there, but we can do it using one of the initial attack vectors that we talked about earlier.  So we have a few parts of the puzzle. We know that we have the initial attack vector, and  now we need some kind of a way to infect actions and to jump from one action to another action.  So let's see actually how to do it. So action to infect actions. We'll start with talking  about secrets in GitHub Actions. So here we have an example workflow that I'll use to  explain how secrets work. So we have the first job on the top that's using the first secret,  as you can see, and the second job that uses the second secret on its second step. Now,  you can see some interesting bash code here in the red box. What this bash code does is  basically dump the memory of the runner and grab for secrets in its memory. Now, secrets  are stored in clear text in the memory of the runner. I know this thanks to research by a guy  that's mentioned here below, Karim Rahal. And what he described in his research is that the  job receives all the secrets that are being used inside the job even before it starts. So it  doesn't matter where we dump the secrets inside the job. We'll get all the secrets that are  available. So here we see an example that we're dumping the secrets even before it's being  used. And let's see how the secret dump will look like. So this is the decoded base 64 of the  dump. We see the second secret and its value. I'm a secret. And we also see a GitHub token.  We'll get in a second into what GitHub token is. But so far we know that all secrets are  accessible to all steps in a job. We didn't see the first secret because it's on a different  job which runs on a different runner. We only saw the second secret. Another point worth  mentioning is that on self-hosted runners, if they're not configured correctly and they're  not destroyed after each execution of a workflow, we may be able to get secrets of past jobs  that were run on the same runner which is much cooler. And the GitHub token is accessible  although it wasn't even referenced in the workflow at all. So these are the two important  things we know. And what is the GitHub token? So in the start of each workflow, GitHub  generates a token for the workflow so the workflow can use it to authenticate to GitHub's  API and perform actions like pushing code to the repository, publishing comments on pull  requests, querying some data about the repository, basically identifying as the workflow  itself. Now to understand the next part, we'll get into how actions are being called. Everything  will just get to complete the picture in a few seconds. So there are three main ways to  reference actions. There are more ways but those are the ones that are relevant for this  presentation. We can reference an action using a hash commit. We can reference it using a  branch or a tag. So the GitHub actions runner will know which action it needs to fetch. Now  if we want to infect actions, we need to modify one of those references. Now modifying an  existing commit hash might be a bit difficult but we can create a new commit to an existing  branch and something else we can do is we can delete an existing tag, creating a new malicious  commit and creating the same tag name with a new malicious commit. Now let's see how it's  actually being done. Just a diagram. So here we have an action repository on the left which  uses GitHub actions as its CICD and it uses the compromised action on the right using the  main branch reference. Now we want to infect the main branch of the left action. How can we  do that? So when the job begins, of course as we said, the runner generates a GitHub token for  the job and also because we can dump secrets as I showed earlier, we may be able to use some  personal access tokens that are being used during the workflow. Maybe they also have some  nice permissions that we can exploit. So when the compromised action is being run, it can  use this token to push code back to the main branch. Now this is only possible if the main  branch doesn't have branch protection rules. But what can we do if it does have branch  protection rules? We can do the same thing. Let's see here like a different scenario. We want  to infect the temporary branch. So same thing, the token is being generated. We push code to  the unprotected branch because the main one has branch protection rules and then we push a  new tag to the repository and by that overriding an existing tag which will now cause any  new request for using the action to use the new malicious tag. We'll see an actual example of  this in a few minutes. And to do that, of course, all those pushes and stuff like that and  deleting tags, we need permissions. So how does the GitHub token permissions work? So up  until not too long ago, all the repositories had default write permissions for the tokens.  GitHub changed it about half a year ago. But this still means that most of the repositories on  GitHub nowadays have write permission to the token by default which is great for hackers, not  so great for the maintainers of the repositories. And what maintainers can do if they still need  the write permissions, they can override the permissions of the tokens specifically for  specific workflows like this snippet here which says that the content permission which is used  for pushing code to the repository will be set to read even though the repository is defined  to have write access for the token. Now, in my research, I wanted to find which repositories  are actually vulnerable to this kind of attack and which repositories will allow the worm to  spread between them. So I needed to calculate what is the actual permissions of the GitHub  token. Now, if I see this, I know the exact permissions. But if it doesn't exist, I need to  find out the default permissions of the repository. How can I see that? We can look at the  logs. It says there, right in clear text, the GitHub token permissions are right and we can just  pass the logs. It sounds simple, but to actually implement it and get all the logs from the  repositories and get the ones that are relevant is a bit more complicated than I expected at  first, but it worked eventually. So let's do a quick recap of what we got until now. So the  first step to execute the worm is to compromise a repository using one of the three initial  attack vectors I showed earlier. The next step is to infect actions by using the GitHub token  or a personal access token inside the repository to push code to the main branch, one or  another branch that is being used, or override an existing tag. By that, we'll climb up the  tree of action dependencies and we'll reach the target repository in which we'll be able to  execute code, steal secrets, maybe modify its code, and a lot of fun like this. Now, let's  start with automation. How can we find vulnerable repositories like this one at scale? So  what I did was this process. So the first thing I did was to collect targets. I collected two  types of targets. The first one is the top 10K repositories in GitHub by stars, and the second  one was 32K repositories of companies with bug bounty programs. I collected this data using a  database that's here in the picture. It contains a lot of bug bounty programs. And what I did  next is to filter out all the repositories that are not using GitHub actions because it's not  relevant. Then I cloned each repository to my computer, checked for the three initial attack  vectors. If I found one that's possible, I added a red node inside the Neo4j graph. And then I  collected metadata about the actions. So I collected, I parsed the action YAML files and the  workflow YAML files that we've seen earlier to find which actions this repository is  depending on. And I collected this metadata about each action. You can see if the content  right permissions is true or false according to the calculation of the different permissions  and override of the permissions inside the workflow file. We can see here the name of the  action, which line it was used in, what secrets are accessible to it inside of the job. Here it's  empty, but of course there are a lot of secrets that are accessible to a lot of actions. And next  thing I did was to go through this step for each action. So for each action dependency I find, I  clone its repository, search for its dependencies, check for initial attack vectors, and for each  dependency this process goes on and on and on. And by using this process we can create this  beautiful graph. Now this is a real case of a project that's vulnerable to this attack. Now let's  explain what we're seeing here. So at the bottom we see two red arrows that are pointing to two  initial attack vectors. Now those two repositories that it points to are actually the same  repository which was moved from one name to another. So it has two references, but it's  actually the same repository. Now what this repository is, is a dependency of some other  actions that are using it. And those other actions are a dependency of the target repositories  that have started scanning. So in this picture we can see that by attacking one repository and  compromising it, we can compromise 18 intermediate actions and by compromising them we can  compromise 72 of the target repositories I initially started scanning. Which is super crazy,  but still this is not the whole picture and impact and scale of this attack. Sadly I cannot  disclose the exact names of those repositories. I can tell you that the target repositories that  you see here are target repositories of huge companies, names that all of you know, and I'll show  you some real examples which I can disclose to describe the real impact and scale of this  attack. So here's a real example that I can show all the participants in this attack graph. So  what we're seeing here on the bottom left side, you can see the Hankfire repository which is a  popular open source, about 8K stars on GitHub. And it uses two actions which you can see in the  orange nodes. Those two actions come from two repositories, the Veracode repository at the top  and the Payploto repository at the bottom. Now the Payploto repository has a red node connected  to it which says re-projecting, meaning this repository is re-projectable. Now next thing I did  was to register the organization. I am the owner of the Payploto organization and as you can see  here in my screenshot, I can register the ActionZip repository. Now I didn't do that in order to  not break anyone's pipeline or execute malicious code on innocent people, but it's possible. I  still own this organization. And I of course reported this issue to the other repositories  that are depending on it and they fixed it. But let's see how their workflows look like. So this  is the Veracode repository, the Veracode workflow. You can see it's using the Payploto, the  action that I'm able to re-project. And you can see here the Hankfire repository which uses the  Payploto and the Veracode repository. And also in the middle you can see some secrets that it  uses that of course this worm can potentially access. So this means that in order to attack  these Hankfire repositories, we have two paths. We can directly attack it using the ActionZip  re-projectable repository. We can also re-project the ActionZip repository, infect the Veracode  repository, and through that infect the Hankfire repository. Now this looks simple, right? This  is the same diagram. We see the same repositories. So okay, we re-project this one repository. We  get to two other repositories. Sounds boring, right? But you can see because there's a lot of  empty space on the slide that there's actually much more to that. So let's say we do this attack.  We re-project the ActionZip repository and we by that infect the Veracode and target repository.  But this is not the whole story. The Veracode repository is an action by itself which has 1.6k  dependents which we can also infect them. And these dependents probably have more dependents  and so on. So that's it. And the ActionZip repository also have about 600 dependents which  probably have maybe their own dependents. So we can see this looks like okay, that's a lot of  repositories. Instead of attacking like three, I can now attack like 2,000 repositories. It's  nice, but still there's a lot of empty space on the slide. The Hankfire repository actually  creates a NuGet package which has 9.4k daily downloads which is nice. So we can also  compromise all the 9.4k daily downloads of the NuGet package. But this is still not the full  picture. Now this is only public information. Those are only public repositories that we've  seen. What about all the private repositories? There are probably a lot more private  repositories that are dependent on this action. And by infecting them we can also propagate  inside private organizations. Now let's say even if we don't have write permissions for the  GitHub token, actually running the worm inside those private repositories, they give us read  permission which you can use to exfiltrate source code of a lot of companies potentially or  organizations. So you can say now okay, so this is really cool, real crazy. Huge impact of  the attack, right? But that's not it. That's just one scenario, one attack path. I found a lot of  those. And this is actually the real impact of the attack. Nice, yeah. Let's see some energies.  Now we finally have all the different puzzle pieces combined and the next thing we can do is  some PowerPoint magic. And let me introduce you to the dendro worm. The word dendro comes out  of the world dendrology which is the science and study of woody plants. This is how I  called my pet worm. And let's see how the demo actually looks like. So in the demo we'll see  this environment. In this environment we have the target repository on the left which uses a  GitHub actions CACD workflow that uses the random action using a V1 tag annotation. The  random action also uses GitHub actions and it uses the main branch annotation of the  rev date action in its workflow. The rev date action is a composite action which uses  directly the rev action. Now as an attacker what we'll do is we'll start with right access to  the repository on the right. We'll infect it with malicious code of the worm and then it will  automatically of course infect the composite action because it uses it as part of its logic.  And then we'll see what happens when a maintainer of the random action creates a push to the  main branch of its repository which will trigger the workflow. When the workflow is being  triggered by running the compromised action the worm will infect the repository by overriding  an existing tag which this tag is being used by the target repository. So when the target  repository workflow is being run it will actually execute the model itself and then we'll be  able to steal secrets. Now let's see the demo itself. Let's do duplicate. Okay nice. Okay you  can see here in the bottom there's the same graph that I've shown you. It's a dynamic so it  will evolve during the demo. On the right side you can see the terminal of the server and on  the left side the repositories. Now we'll start with the first repository. Here it's an  action file and we're infecting it with malicious code, some zoom magic. And we see that we're  downloading a malware from the server and installing it as a Python package and executing  it. Now I did it using Python just as a POC but this of course can be done much more stealthy.  And now we commit the changes to the repository and we go to the second repository. Now the  second repository we can see it uses the first repository as part of its composite action  YAML file which means this repository is automatically compromised because next time it will  run it will run the malicious action we've just infected. Next thing we see is the third  action. Here you can see it just generates a random number which does nothing and it has a  CICD workflow. Now this workflow uses the second action as part of its logic. You can see  here. So it's using the main branch which is infected because of the composite action. And  another thing we can see this repository has a V1 tag that was created yesterday which  will override soon. Now here we can see the maintainer pushes new code to the main branch  which you'll see here it's protected using branch protection rules. This is why the override  is needed. And this push triggers the workflow we've just seen. And you'll be able to see in a  few seconds on the right the worm being executed. Here you can see it's being downloaded,  executed on the left. And in a few seconds we'll see the actual infection. And you can see  that it didn't successfully infect it using a push but it successfully infected it using  override of the tag itself and also it printed out all the secrets that are available which is  only the GitHub action token. And we can see now the tag that was overwritten just now. Here's  the new malicious code. Same code like the infection we did at the start. And now we see in  the target repository which also has HCI which uses the action that just got infected using  the V1 tag that was just got also infected. And it's also using the very secret secret, very  cool name. And what we see here next is the maintainer of the repository pushing code to the  main branch like everything as usual, business as usual. And it will trigger the workflow that  we've just seen. And same thing happens. We'll see the malware being downloaded. And executed  and installed. And you can see here that it successfully exfiltrated the secrets from inside.  You can see it failed to infect the repository because it's not an actual repository but it did  actually infect the secret. Still a secret. Thank you. Okay. Let's continue. Okay. So we've  just seen the demo of the actual malware. And we have a bit of time so I'll show you more  interesting stuff I found out during this research. So it turns out there are a lot of  repositories that are directly vulnerable to the three initial attack vectors. I'll show you at  the beginning. I found 175 repositories directly vulnerable to those three attacks using 192  different ways. So some of the repositories had multiple command injections available on them.  Multiple NPM email hijacking of packages they're using. And those projects are actually  projects of really known organizations. You can see the coolest one is I found a command  injection in Angular which is crazy. Probably everyone here is using Angular in some sort of a  way. Maybe as a user. Maybe as a developer. Also I found some command injection in a popular  open source you can see here. The Astro open source. And in the last bullet you can see I  hijacked one email domain of a company that's called Plotly. And of course I reported it to  them. But by possibly hijacking that one domain I could compromise 67 repositories that were  maintained by this one user that belonged to this company. Now this user actually had like 90  repositories but only 60 of them belonged to the company. So technically I was able to  compromise 90 repositories by actually buying a single domain of a single user that forgot to  renew its email domain. And now that we're nearing the end let's talk about how actually you can  protect yourself from this attack. So the first and most important thing you can do it's  ordered by most effective stuff to the less effective stuff. So you can set the GitHub token  and any personal access token being used inside the workflow to minimal permissions. Basically  the content permission is the permission that's used to push code. So if you don't need to push  code to the repository set it to read. You can also configure branch protection rules to  prevent pushes to used branches. And use protected tags which is a less known feature of  GitHub. Also you can limit outbound connections from runners to prevent downloading of malware  like in this example. Now of course the worm itself can contain its own code inside its own  code without accessing the internet and still infect stuff but it makes life of attackers much  harder. You can also pin actions by using a hash which also makes it a bit difficult for  attackers to perform this attack. It's still not sealed tight and you can also use this project  that was released by GitHub not too long ago which helps you to reduce permissions for your  workflows. That was the GitHub Actions Worm and thank you everybody for coming.  Thank you.  I think if we have some time for questions. Do we have a mic? Yes.  So we asked how can I pass branch protection rules to override a tag. So branch protection  rules don't affect tags. So even if you have, you need to use the protected tags. It's a  different feature. More questions? Yes.  Can you say again a bit louder? I can barely hear you.  What is the response of the companies that reported this issue?  So the companies I've showed that have reported this issue to, they fixed their workflows, they  removed the vulnerable actions which makes them, which basically mitigates this issue.  Most of the companies that had more complicated graphs, like you had to compromise a  dependency, they didn't consider it as an issue because it's dependencies and like in bug  bounties or generally in vulnerability disclosure programs, they consider it out of  scope or not relevant but yeah, it's still possible to attack them this way.  More questions? Yes.  Okay, so if I come around any malicious action being used in the wild, I actually didn't see  anything. I didn't look for them so that's maybe the reason. But there are malicious actions  probably around there. Not doing this stuff probably but maybe other stuff, yeah.  More questions? More questions?  Okay, thank you.  Thank you.


url: https://www.youtube.com/watch?v=iGINoIYQwak
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
title:
  DEF CON 31 - Tetra Tour de Force Jailbreaking Digital Radios & Base Stations for Fun - Midnight Blue

content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=iGINoIYQwak",
    "title": "DEF CON 31 - Tetra Tour de Force Jailbreaking Digital Radios & Base Stations for Fun - Midnight Blue",
    "description": "In this talk we will discuss the radio jailbreaking journey that enabled us to perform the first public disclosure and analysis of the proprietary cryptography used in TETRA (Terrestrial Trunked Radio): a standard used globally by government agencies, police, prisons, and military operators as well as critical infrastructure such as SCADA telecontrol of oil rigs, pipelines, transportation and electric and water utilities.\n\nFor decades, the underlying algorithms have remained secret under restrictive NDAs prohibiting public scrutiny of this critical technology. In this talk, we will make public the TETRA cipher suites (TEA and TAA1 to be precise), one of the last bastions of widely deployed secret crypto, and discuss in-depth how we managed to obtain them.\n\nWe will discuss several different flaws we uncovered allowing passive or active adversaries to intercept and manipulate TETRA traffic, including details of a backdoored stream cipher.\n\nThis journey involved reverse-engineering and exploiting multiple 0-day vulnerabilities in the popular Motorola MTM5x00 radio and its TI OMAP-L138 TEE and covers everything from side-channel attacks on DSPs to writing your own decompilers. We will also discuss how we gained code execution on and instrumented a Motorola MBTS TETRA base station for research purposes.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 4213,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230915"
  }

  This text was transcribed using whisper model: large-v2

   All right, hello and welcome everybody to our talk, Tetra Tour de Force, jailbreaking  digital radios and base stations for fun and secrets. I'm very excited to stand here today  and share this research with you after working on it for more than two years. My name is  Jules Wetzels and these are my colleagues, Carla Meyer and Wouter Bokslag, and together  we form Midnight Blue, a specialist security consultancy firm that specializes mainly in  embedded systems as well as critical infrastructure. So a little bit about Tetra, what is Tetra?  It's a globally used radio technology that competes with the likes of P25, which you  might know from being used by the United States police, DMR and the confusingly named Tetrapole.  It was standardized in 1995 by ETSI, that's the European Telecommunication Standards Institute,  and they are known for also doing work on GSM, 3G, 4G and so on. It's used for voice  and data communications as well as machine to machine communications and it relies on  secret proprietary cryptography. That's why we're standing here today.  So it's the vast majority of global police forces outside of the United States and France  use Tetra for their voice communications and this is countries like the Netherlands and  Germany and the United Kingdom, but also Scandinavian countries, Eastern Europe, large parts of  Asia and South America use this. In addition, it's used in military and intelligence  services contexts. Now, the countries that you see highlighted on the map here are the  ones where we could confirm military or intelligence users through open source intelligence, but  this is likely the tip of the iceberg, so there might be many more countries out there  that use it in this capacity. And on top of that, it's used by critical  infrastructure. So if you see private security forces at airports, harbors and train stations,  there's a good chance that their handheld radios are Tetra based. And on top of that,  it's also used as a radio link for wide area networks carrying SCADA communications in  order to do telecontrol and telemetry of high voltage substations, oil and gas pipelines  as well as railway signaling, so serious stuff. Now, a common misconception is that Tetra  is an open standard, but that's not true. Some parts of the standard are public, but  the cryptography within it is secret, and it's only available to you if you sign an  NDA, and I mean, in that case, you can't talk about it, and you're only allowed to sign  an NDA if you are what they call a bona fide party. And these bona fide parties are usually  manufacturers and these manufacturers have to ensure that the algorithms are protected,  either by implementing them in hardware or implementing them in software with extraction  countermeasures. Now, the first problem already is that there are lots of these bona fide  vendors and they are geographically dispersed, so every major country in the world essentially  has a domestic Tetra manufacturer. That's the United States, the United Kingdom, China,  Russia. So you can feel that top tier adversaries likely already have these specifications of  these algorithms, either through their in-country manufacturers or through just, you know, getting  them from a share point somewhere at a manufacturer. We, however, had to jump through a lot more  hoops in this case. So Tetra security has two main pillars, the first of which is the  TAA1 suite, which is the authentication, key management, and distribution suite. It's  also used for identity encryption. The second suite is the Tetra encryption algorithm suite,  which is used for voice and data encryption through the air interface encryption functionality.  And this has four different flavors. The first of which is TAA1, which is readily exportable.  Then you have TAA2, which is restricted in its use to European public safety organizations.  Then you have TAA3, which is used for extra European public safety, for those countries  that have friendly relationships with the European Union. And then you have TAA4, which  is the same use case as TAA1, but it's hardly used in practice.  Optionally, there are Tetra end-to-end solutions available, but these are only used by some  countries and only in special cases, in most of the cases. So think about special intervention  units, counterintelligence observation units. It's not a part of the Tetra standard. There  are some guidelines around it, but it's a vendor-specific proprietary solution that  you build on top of the air interface encryption. It's expensive and, again, very opaque as  well. It hasn't been looked into yet. So with this in mind, we undertook Project  ReTetra, which was the project to reverse engineer these algorithms. And you can find  all the details about this on this particular URL.  We undertook this with Kirchhoff's principle in mind. Now, I probably don't have to explain  to you guys what Kirchhoff's principle is, but I'm still going to anyway. It says that  a crypto system should be secure even if everything about the system except for the key is public  knowledge. So no security through obscurity, right?  Violators of this principle have historically not done well. If you look at the history  of standards like GSM, GMR, GPRS, all Etsy standards, by the way, their secret cryptographic  algorithms either turned out to be broken or backdoored. And we had the suspicion that  this might be the case for Tetra as well. But in more than 20 years, nobody had looked  at this publicly. Now, Etsy thinks very differently about this.  In an interview with the journalist Kim Zetter, Brian Murgatroyd, who's the chairman of the  Etsy technical committee on Tetra, said, well, obscurity is also a way of maintaining security.  Well, let's see if that's actually the case. So the project was undertaken with funding  from Enelnet, which is a Dutch nonprofit organization that hands out money for open source initiatives.  And they kindly supplied us with some money to undertake this research, and now we can  talk about Tetra for the first time in public. So let's break open a radio.  Well, before we could break open a radio and see what's going on inside, we did a little  bit of analysis first, because you want to select the right kind of target, because if  you select a radio that is harder to reverse engineer, you might end up spending a lot  of time on dead ends. So we did some analysis of the internal architectures  of different kind of radios from different vendors by looking through the different data  sheets. And here you can see that, well, there's a variety of architectures, some of which  are quite esoteric, but also they implement different kind of security features. Like  certain radios will implement hardware-based ASICs that likely include the algorithms,  and we don't want to spend a lot of time with assets and scanning electron microscopes.  So we went for the one that has a trusted execution environment in software. And that  turned out to be the Motorola MTM5400. This is a very common model. It's easily obtained  secondhand online on eBay. And it has a baseband system on chip that is by a manufacturer that  is not Motorola, but by Texas Instruments. And this likely hints at the fact that there's  no hardware implementation of these algorithms inside. Also, this SoC has software security  features and that are very suited for likely protecting this Tetra crypto from extraction.  The architecture of the radio looks like something you see on the right of the slide. So if you  have the radio, you have a control head, which is where the microphone, the keyboard, and  the field configuration is. Then on the back of the radio, you have a rear connector, which  you use for depot programming, for configuring the radio, doing firmware updates and so on.  And then inside you have the baseband chip. And the baseband chip, in this case the Freon  baseband, is based on the OMAP L138 architecture by Texas Instruments, which has a ARM core  for the high-level stuff and a digital signals processor for, well, processing the signals.  And then inside the DSP, you have a trusted execution environment that likely includes  our magic sauce. So this OMAP L138, like I mentioned, it has an ARM core, but it also  has a DSP core that is based on a flavor of the TMS320 DSP architecture. There's very  limited reversing tooling available for this particular flavor, so we had to build a lot  of our own. And the DSP features an orthogonal security model. So you have a separation between  the regular user and supervisor mode, but you also have a separation between secure  and non-secure mode. And if you look at the supervisor secure mode, that is likely where  a lot of the interesting stuff is located. First thing we did is we bought a development  kit for this architecture. It was relatively low cost. Unfortunately, this didn't come  with a secure version of the chip, so we couldn't analyze it on a development board.  However, it's useful for reversing, debugging, testing your shellcode, and so on. Now, we  wanted to confirm our assumptions, so we opened up the radio, and we saw that all the main  board was covered with shields. So in order to see what kind of chip is exactly used,  we took a rotary saw, we sawed off these shields, and we found out that, yes, it is indeed this  particular chip with the secure flavor. Then we took a look at the firmware. The firmware  comes as an RPK package, and the RPK package, well, it's essentially a zip archive, and  inside the zip archive, there's an encrypted Z-19 file. So, you know, these firmwares are  not personalized. They don't differ from radio to radio. They're general. And the engineering  software needs to have a way to load this firmware onto these radios, so likely it knows  the passwords to these encrypted files. It's written in .NET, so it's very easy reverse  engineering. With a little bit of effort, you get the two passwords, which are static.  So then you're able to extract the zip archive. You get the Z-19 file. You decrypt it with  one password, and you get the S-19 files. You decrypt those with the second password,  and then you have what you're actually looking for, which is the file system of the application  processor and the DSP firmware. So is this trusted execution environment actually used  for the Tetra algorithms? Well, there's no proper DSP reversing tooling yet, so how do  we find this out? Well, by doing the entropic analysis of the DSP firmware. So you can see  on the left of the slide that in a particular area within the DSP firmware, there's a very  high entropy area, which likely indicates encrypted data, and then you can see the cross  references in the code to this particular area correspond with API call invocations  of this particular secure kernel API. So delving into a little bit more detail will  be my colleague, Carlo Meyer, who will take you on the rest of the journey.  All right. So now that we have a pretty good idea of where to go, let's break it to you.  So the first thing we have to do is get code execution obviously on the application processor,  and we identified three possible angles, the first one being the modem AT command interface,  the second being modifying the NAND flash, and the third one being targeting some peripheral  interface, for example, like the GPS module or the what have you. After that, we'd have  to move from the ARM core towards the DSP through either direct memory access or through  some DSP link library, which is the library used to pass messages back and forth from  the ARM core to the DSP and vice versa. And finally, once we obtain code execution on  the DSP, we'd have to find either a vulnerability or a side channel flaw in the trusted execution  environment. So this is basically the same thing, but then presented in a nicer way.  Okay. So the MTM radio has a rear connector that exposes the AT modem command interface.  With this interface, you can read, write parameters, for example. Analyzing the firmware gave us  a list of commands, and we immediately started looking for those with string parsing or variable  length handling. The commands used to set a talk group list entry and supplement the  enumerate them, we found a classic format string vulnerability, which allows us to write  arbitrary data to any pointer that's listed on the stack. So on the slide on the right,  you see our user input that contains percent P, and on the bottom, you see it interpreted  as a format string. So this is a classic vulnerability. So this means that we can write anything that  we'd like to anything that's listed onto the stack. So if we can influence what's on the  stack, we have a write anything anywhere primitive. Unfortunately, we don't. So how do we go about  that? So luckily, there's frame pointers in this firmware. Frame pointers have the nice  property that each frame pointer points to the next frame pointer. So in this particular  example, let's say that argument 55, that one contains a memory address, and it points  to argument 59, which in turn points to argument 71. Now, suppose that you write, let's say  0x80 to argument 55, that will update argument 59, and in this particular example, it will  now not point to argument 79, but it will point to byte 0 of argument, not point to  argument 71, but in this particular example, it will point to byte 0 of argument 79. All  right. So now if we write anything to argument 59, it will update byte 0 of argument 79.  Then we go back, and we update, then we write something to argument 55 again, for example,  0x81, and therefore argument 59 now points to byte 1 of argument 79, and this way, we  go by continuing this route, we end up being argument number 79 being completely malleable  by us. We completely control its value, and this way, we have a pointer on the stack that  we completely control, and therefore we have a write anything anywhere primitive. Good.  So it turns out that the heap actually has read, write, and execute permissions, so the  next steps would be just to write our shellcode onto the heap, overwrite some pointer that  points to executable code, and then trigger execution of that pointer, and boom. So that  got us a shell on the application processor. All right. So the next step is to move on  to the DSP, so to recap, this means exploiting vulnerability in this communication library  called DSP link, or exploit some misconfiguration in the MPUs configuration. Right. So this  thing contains two cores that need to communicate somehow, and they do this by having shared  internal RAM and some external DDR2 memory, and this could present an interesting avenue  for lateral movement via direct memory access. So now the SOC has in question has memory  protection features, which allow for the segmentation of memory areas between cores and within cores.  So the plan would be to dump the MPU configuration, and then find a range that's used by both  the DSP and the application processor, and then identify and exploit an interface that  uses this shared memory range, such as DSP link, that's used in order to pass messages  back and forth. So when we dumped the configuration, we saw that there is essentially no segmentation  applied whatsoever, so basically this MPU poses zero problems for us. Like getting code  execution on the DSP is as straightforward as just modifying parts of the DSP firmware  in RAM. So the next thing we did is we implemented a framework for running code on the DSP. We  wrote multiple application processor kernel modules, which hijacks DSP control by allocating  shared memory, copying our payload over into the shared memory, and then redirect DSP execution  to our code, meanwhile ensuring that the watchdog, which is a hardware peripheral, was periodically  kicked in order to prevent the board from resetting. So all of this was kind of complicated  by the fact that the DSP architecture is pretty hellish. It has delayed branches, variable  degrees of concurrencies, lots of conditionals, and very limited IDA support. So we had to  implement our own disassembler, and on top of that we also added support for the architecture  to the Red Deck decompiler, and both will be upstreamed in the course of the next few  weeks. As you can see, the decompiler output reads a lot nicer than the disassembler.  All right, and with that, we had reliable DSP code execution.  So on to the final step, attacking the TEE. So at first we got our hands on a chip whisperer  to do some power side channel analysis. However, it quickly turned out that it wasn't the easiest  route at all. We had to find clock lines on the PCB, we then find the DSP power line,  decrease the DSP core clock speed, correlate measurements to the key, etc., etc., which  turned out to be a nightmare. We were quite sure that we were going to break the board  this way. So we took a step back and we looked at maybe we have other options here.  So it turns out the TEE is implemented in ROM by a subsystem called the secure kernel.  This code runs in DSP secure mode, and all non-secure code can do is perform a secure  kernel API call, which is very similar to a sys call on a regular PC. So there's this  thing called SK load, which is an API call which allows for runtime loading of encrypted  modules. For example, our Tetra module, which contains the Tetra algorithms, and it then  decrypts this module with AES and validates them using RSA and then loads them into the  trusted execution environment where they're invisible in non-secure mode. Then if you're  back into non-secure mode, you can invoke one of these algorithms through SK algo invoke,  which allows non-secure code to invoke these algorithms and get the result from one of  these functions that was previously loaded. These modules are encrypted with a customer  encryption key, so that's the factory set key. In this case, that key belongs to Motorola.  So now for our tech, we got some inspiration. Modern computers use caches to speed up memory  accesses, and this introduces some timing differences during lookups. And this in turn  may leak some information on secrets involved. So in 2005 already, Daniel Bernstein wrote  an interesting paper on performing such attacks on AES, where you build a profile of timing  differences and then you observe the target's system characteristics. You correlate these  with the observation and then you derive which key fits best. Right. So for the DSP, we are  targeting, it has several caches. You have a level one data cache, you have a level one  code cache, and you have a level two cache. The level one data cache has a 64-byte line  where memory reads are fast and data that is already, for data that's already cached,  and otherwise it's slow. So we can evict addresses from cache in this 64-byte granularity, and  it turns out that doing so from non-secure mode also affects secure portions from the  address space that you cannot usually read from non-secure mode. Furthermore, there's  a feature called a cache freeze, which basically means the cache is turned into read-only state,  which means that whenever you get a cache hit, you get a performance increase. Whenever  you get a cache miss, you have to fetch it from main memory, but the cache isn't updated.  So now that we have some control over the cache, which AES decryption step should we  target? Well, it turns out that inverse sub-bytes, we're decrypting AES, so inverse sub-bytes  uses an S-box, and that means a memory lookup, so we should probably target that. The thing  is, this S-box is located in some page in ROM, but it's not readable from non-secure  mode, so we don't really know where the S-box is. So the first thing we have to figure out  is figure out where the S-box is. So what we did is, we start by evicting the first  cache line, so the first 64 bytes of this ROM, invoke skload, and then measure the time  it took to run that code in terms of clock cycles, and then we do so for the second cache  line, and then the next, and so forth, and eventually we plot this. So we get something  like this. It seems quite obvious, the S-box is right over there. Okay, so let's dig a  bit deeper. We're going to prepare the cache as follows. We run skload so that the full  S-box will be in cache, and then we evict the first 32 entries, so this is what we refer  to as the first octant, because it's one-eighth of the S-box, and then we enable this cache  freeze feature. And now, whenever a timing penalty occurs, we know that this happens  due to the first octant of the S-box being hit. So we'll assume this setup for the remainder  of the presentation. So having evicted the first octant of the S-box from cache, we set  ct0, so that's the first ciphertext byte that we provide to skload. We set it to zero, and  we randomize the remainder of the ciphertext, and we measure average running times of skload,  and then we repeat that for other values of ct0 as well, and then we plot the results.  So again, we set the first ciphertext byte to zero, we randomize the remainder, and we  get the average running time of skload. So that thing now, our controlled value, gets  put through the S-box. So when we plot that, we get something like this, which is quite  interesting. So we know by construction that the penalty is observed when our ciphertext  byte XOR a round key byte is less than 32, and in the above example, we find that this  leaks some information about the round key byte. So in this particular case, the round  key byte is located somewhere between 32 and 64. So that's great. We effectively leaked  three bits of this round key byte, so we repeat the same thing for the remaining 15 round  key bytes. We obtain a total of 48 bits of round key. However, this approach is inherently  limited, because after all, the other five bits of the round key do not influence which  S-box octant is hit, and therefore we cannot leak those. There's still 80 bits left to  brute force, so that's not really a viable approach either, so we have to dive in even  deeper. So suppose that we, instead of attacking the first S-box lookup, let's look at the  second S-box lookup. So round one S-box lookup has introduced some diffusion within the state  byte, so this now means that the least significant bits of this byte actually do influence which  octant is hit during the S-box lookup. So we now have to account for shifting of the  state bytes, the influence of the next round key, and the diffusion of mixed column step,  which was a step that's taken in between, and then we can extend our attack. And I won't  go into further details, because this probably goes, if I would explain to myself, it would  go way beyond my head, so I'll just demonstrate it.  All right, so this is right after we got a shell on the radio, on the Encore, so this  is loading a kernel module that kicks the watchdog, and now we hijack code execution  on the DSP, and next thing we do is run the side channel attack. So this is the full thing,  I'm showing you this because we optimized it such that it's stupidly fast, so this only  takes a minute, and then it gives you the key.  So all the bytes in between that you see, those are round key bytes.  And there we go, that's the key.  Now, clearly this isn't the actual Motorola key, it's just a mockup.  Right, of course it wouldn't be fair if there weren't even more hurdles for us to jump over,  so it turned out there was an additional encryption layer for which we had to adapt  the attack to, then there was an additional obfuscation layer which stumped us for a bit,  but once we observed similarities between the loaded modules, it turns out that the  obfuscation was just a rolling XOR that incrementally calculated a checksum, and with that we could  now extract the customer encryption key in less than a minute, we reverse engineered  the remainder of the module format, decrypted our target module, reverse engineered it,  and finally got the secret algorithms.  So a little recap for the journey so far, we found a format string vulnerability in  the AT interface on the rear connector of the radio, to get us code execution on the  baseband application processor, we then jumped to the DSP via shared memory, explored the  cache timing side channel on the TEE of the DSP to extract our secret algos, and now we  have them.  So that brings us to the point that we can actually start doing what we wanted to do,  and that is analyze the cryptographic primitives underpinning the security of Tetra.  We can now finally start doing what we came here for, and that is analyze the security  of Tetra. All the primitives are by the way public now, so you can get them off GitHub  if you want to take a look at it for yourselves. I will start by explaining some things and  explain some vulnerabilities that we found. So what you see here is how this authentication  is shown in the standards, you see some boxes, TA11, TA22, and those are like black boxes,  they don't tell you how it works. We are now able to actually inspect how these things  are implemented, and we saw that all the primitives that are marked TA-something are  based on a proprietary cipher named Hurdle, it's a 16-round FISO cipher which uses 64-bit  blocks and a 128-bit key, and the primitives called TB are based on very simple XOR and  addition operations. Also, interestingly, we found that some of these blocks are identical  or highly related, and that will help us later.  So this is an overview of a part of Hurdle. Hurdle has an F function that combines half  of the states, so 32 bits, with 96 bits of round key information, and it has this really  extensive cascading structure, so it's quite interesting to look at, and I'm looking really  forward to some professional cryptanalytical insights.  We could not break it. We could, however, find the function that originally generated  the S-box, it's based on the Nyberg S-box, just like AES, but we didn't get any further  with this, so we hope some of you guys maybe want to look into this.  We will discuss, however, an attack we found on this authentication scheme. What you see  here is how the mobile station and the infrastructure perform mutual authentication, so they generate  some random numbers, and through a cryptographic dance, they prove knowledge of a shared secret  key, and if this authentication succeeds, it will also yield a session key, the DCK,  and below, on the bottom of this slide, you see how this DCK is constructed in terms of  these primitives. Now that we have obtained these primitives,  we can do some simplification. We found that TA21 is actually identical to TA11, except  that the RS, the random seed supplied by the infrastructure, has a reversed byte order.  Additionally, TA22 is actually identical to TA12, and the TB4 function is nothing more  than an XOR, so the session key is generated by XORing together two half-session keys that  were generated previously. Now, this is interesting because this allows  for an attack. Let's assume that we impersonate the infrastructure and we target a mobile  station. Additionally, let's assume that we can predict the random number that is being  generated by the mobile station. This may seem like a bit of a stretch, but in embedded  systems, random number generation is really hard and quite often not fully unpredictable,  so this may be more feasible than you might initially think.  We can provide the mobile station with an RS, a random seed, that is a palindrome, so  it's identical in the reversed byte order as in the forward byte order. And if we do  all that, then we can simplify the DCK derivation formula to something that has the same on  the left and on the right side of the XOR operation. And by nature of the XOR function,  we end up with a zero key. So what we have achieved in this case is an authenticated  channel with a mobile station with a known session key of all zeros, without even having  knowledge of the original shared secret key. So, next, let's talk about identity encryption.  Identity encryption in Tetra is implemented in a primitive called TA61, and this is used  to encrypt 24-bit Tetra addresses, which you can compare to a phone number if you want.  And these encrypted addresses are used for a while until a certain network key is changed.  This won't happen very often, maybe every few weeks or so, so Tetra doesn't offer strong  anonymity but pseudonymity nonetheless. At this point, unfortunately, we cannot disclose  the implementation of TA61 due to some serious concerns from Tetra stakeholders. We will  publish them in December, but at this point, at least we can share with you the outline  of an attack so that we can have an informed discussion on the security of this primitive.  The attack looks as follows. The CCK network key is first being used in a hurdle encryption  in order to generate a 64-bit intermediate secret, which is shown here as C. And only  then this intermediate secret is used in order to encrypt this 24-bit identity. And this  happens in a weird, two-round, lightweight crypto scheme. And this is vulnerable to a  meet-in-the-middle attack. As an attacker, we can try to gather a few pairs of unencrypted  identities together with their encrypted equivalents and start computing forward from the unencrypted  one and backward from the encrypted one and see at the meeting point which guess for the  intermediate secret C would make sense. And this attack has a complexity of 2 to the 48th,  which on a regular laptop runs in about a minute. And after you have computed this value  of C, you can instantly de-anonymize anything that comes past on the air interface. Also  it gives you an option to attack a hurdle encryption because you have C, which is the  output of a hurdle encryption. And if you can somehow break that encryption and derive  what the original CCK was, there is a very, very serious problem for Tetra. So that's  also something to investigate in the future. Now de-anonymization can be quite serious  depending on the use case of a Tetra network. Tetra identities are typically distributed  in ranges. So regular police forces will get one range while intervention teams get another  range and firefighters will get yet another range. So as an attacker, if you invest some  effort into identifying which ranges belong to which kind of services, you can have a  very interesting intelligence position. This can be used, for instance, in a counterintelligence  context when you may be able to notice when covert surveillance units are near you all  the time. Or it can serve as an early warning for organized crime when intervention teams  seem to pile up somewhere in the vicinity. The attack is fully passive and can be executed  with very cheap hardware. So it's very realistic that this can be done.  So let's talk about the actual encryption algorithms. In Tetra, traffic is encrypted  with one of four key stream generators, as Jos pointed out previously. And we found that  all of them share a very similar structure. And depicted here is TA2. On the top you see  the key register, an 80-bit register that provides information to the state register  below and eventually the state register will output key stream which is then used for encryption  of Tetra traffic. To us, TA2 looks robust, but we are not cryptographers and more public  scrutiny is needed before we can finally decide that this is all good and safe to use.  But this is where it gets real interesting, because we found a backdoor in the TA1 cipher.  TA1 is intended for private use cases, commercial use cases like private security, but it's  also been distributed to, like, say, less friendly police and military forces that Europe  did not have very good footing with at the time these networks were originally conceived.  TA1 is advertised as having an 80-bit key, but the first thing it does is apply a secret  reduction step that compresses this 80-bit key into a 32-bit register. And from then  on it will only use this 32-bit register for the generation of key stream. So obviously  this is trivial to attack nowadays. You will be able to crack such a key in a minute and  get a key that works for decryption of all traffic on that frequency. Additionally, you  could decide to actually start injecting traffic, which is especially worrisome when  Tetra is used in a data-carrying capacity such as SCADA1 telecontrol kind of traffic.  So, small demonstration.  Hi, we're Midnight Blue, a specialist security consultancy firm. In this video, we're going  to demonstrate a proof-of-concept attack from the Tetra Burst vulnerabilities recently  uncovered by our team. Terrestrial Trunked Radio, or Tetra, is a radio communication  standard used globally by law enforcement, emergency services, military operators, private  security, and harbor and airport personnel. In addition, Tetra is used in a wide area  network carrying capacity for SCADA telecontrol of oil and gas pipelines, electrical substations,  water management, and even railway signaling. Tetra offers confidential communication guaranteed  through its so-called Air Interface Encryption feature. This feature encrypts Tetra traffic  by means of one of four proprietary stream ciphers, TEA1, TEA2, TEA3, and TEA4. Of these  ciphers, TEA1 can be exported globally with appropriate export approval and can be used  by both commercial and government parties. As such, TEA1 is used to protect select law  enforcement, military and private security radio communications, as well as SCADA radio  links of global critical infrastructure. Tetra is used in many different sectors, ranging  from electrical and water utilities to oil and gas, transport, and mining. Since the  Tetra encryption algorithms have been kept secret for over 20 years, their security has  never been properly publicly evaluated until now. Midnight Blue researchers have reverse-engineered  the algorithms and uncovered several vulnerabilities in Tetra, including a backdoor in the TEA1  algorithm which reduces its advertised key strength of 80 bits to a mere 32 bits. This  backdoor, which has festered in global critical infrastructure for decades, enables the interception  and manipulation of TEA1-protected Tetra communications from anywhere within cell tower coverage,  which may be up to tens of kilometers. Due to the simplicity of the backdoor, even attackers  with limited resources, such as a $10 radio dongle, can crack TEA1 keys in a matter of  minutes. In this demonstration, carried out on a real network, the attacker captures traffic  and identifies messages on which to mount the attack. Now, the attacker computes the  key used on this frequency. This will take about a minute. Once the key has been cracked,  voice communications can be intercepted while the attack remains fully undetected, or data  can be actively injected. In the case of SCADA telecontrol communications being carried over  Tetra-wide area networks, attackers could use this vulnerability to obtain direct access  deep within the operational technology networks of critical infrastructure, allowing them  to intercept and manipulate network traffic-controlling equipment like switchgear, circuit breakers,  and valves at electrical substations or oil and gas pipelines. Due to the highly sensitive  nature of the uncovered issues, Midnight Blue has spent more than 1.5 years in a carefully  coordinated disclosure process with multiple government and industry stakeholders, guided  by the Dutch government's National Cyber Security Centre. During this process, detailed...  Thank you. Awesome, thank you. So, with a small recap and demonstration video, I think  we made a point, right? Well, Etsy has some interesting things to say about this. First,  they claim that we are using a very high-powered graphics card in order to be able to attack  this. Well, in my opinion, a 2016 consumer-grade graphics card is not that high-end, but, hey,  opinions may differ. Also, they state that 25 years ago, when Tetra was standardized,  32 bits of key entropy was probably sufficient to withstand attack. And they state that you  need some pretty reasonable equipment in order to be able to attack TEA-1. Now, I don't think  I have to explain to you guys, thank you, that this just doesn't make sense. But, yeah,  you know, why would we make any assumptions on this? Why would we use reasonable equipment  in order to attack such a cipher? Let's see what this bad boy can do.  Hi, we're Midnight Blue. About two weeks ago, we announced the Tetra Burst vulnerabilities,  consisting of five vulnerabilities in the Tetra Radio Standard, two of which are deemed  critical. Since then, Etsy, the standardization body responsible for Tetra, has made public  statements in which they downplay the seriousness of the vulnerabilities. In these statements,  they resorted to a semantic discussion, not calling a spade a spade, or, more specifically,  not calling a backdoor a backdoor. Furthermore, they made a number of evidently false statements,  such as claiming packet injection and TEA-1 encrypted networks would be impossible, and  that 32 bits of cryptographic strength would have been sufficient in the late 90s.  To any information security expert, it's pretty clear that this is not the case. But to help  remove those few remaining doubts, we decided to take on the challenge of cracking TEA-1  on this beautiful machine produced in 1998, running good old Windows 95.  Frankly, the hardware is so old that it wasn't easy to get our hands on. When we run the  cracking tool, we see it reports that it needs about 13 hours to go through the entire search  space. After 12 and a half hours, the key is found, demonstrating the feasibility of  cracking TEA-1 on 90s consumer hardware. Alright Etsy, now that we've cleared up this  issue, please let us know if you'd like us to demonstrate packet injection as well.  Right, now, I think we've got that out of the way. So, we discussed TEA-1, it's backdoored,  it's trivially breakable. But the other encryption algorithms should be fine, right? There's  still TEA-2 and TEA-3, which are used generally by law enforcement and emergency services.  Well, not really. Because we also found a protocol level vulnerability in Tetra. And  in order to understand that, we need to dive into the standard a little bit more.  So in Tetra, signalling is encrypted and only the very first part, the MAC header,  is unencrypted. The MAC header contains some high level stuff like the length of the package  and the addressee of the message. And everything after that is encrypted with the keystream  generator. It's important to note that the Tetra messages have no authenticity or integrity  guarantees whatsoever. So there is a CRC on the MAC level, and you may optionally add  a CRC 32 in the data that's encrypted here. But that's not a cryptographic MAC in any  sense. So an attacker will be able to forge messages, and whenever such a message is decrypted,  the radio will just interpret it and parse it at face value.  So the application of the keystream works as follows. The keystream generator function  gets two inputs. It gets a key, and it gets an IV. And this IV is intended to make sure  that for each message, a different keystream is being generated. And in Tetra, the IV mostly  consists of the network time. So the network time is a set of frame counters. There's  slot, frame, multi-frame, all kinds of frame counters. And these things must be known to  the radio whenever he wants to perform an encryption or a decryption. So how does he  know that? Well, because it's broadcast by the infrastructure in sync and sysinfo frames.  And once more, these messages in Tetra have no further integrity guarantees whatsoever.  So the attack starts to be clear to some of you maybe. An attacker can decide to overpower  the infrastructure and target a mobile station and alter its perception of the network time.  And if you start playing with the sync and sysinfo frames with a targeted mobile station,  it will happily use those counters and start using keystream that was relevant at the time  you specified to it. And this works regardless of which keystream generator is used. So also  on TEA2 and TEA3. The attack outline would be as follows. Imagine we capture an interesting  message at some point in time. It's encrypted, but we decide that we would like to have the  plain text contents. Then at a later point in time, we identify a mobile station that  we want to attack. And it can be the same mobile station. It can also be another mobile  station as long as it has the same key material. We then overpower the legitimate infrastructure  signal, for instance, by use of directional antennas or just by being closer to it than  the regular cell tower is. And from that perspective, we can start messing with the perception of  time of this mobile station. So we can set the mobile station time all the way back to  time T when we originally captured our encrypted message. Now we will somehow need to be able  to extract the keystream from the mobile station that we need to decrypt our message. We'll  get into that later. But if we can do that, then we have one we will be able to decrypt.  Now for the recovery of keystream, let's start out with an assumption that we already have  some keystream at our disposal. So we will construct a message that is of length n plus  1, so one bit longer than the keystream we have, such that it has an FCS, a frame check  sequence, which is a checksum that is embedded in the encrypted part. And it needs an acknowledgement  from the mobile station upon receipt. We can encrypt this message with the keystream we  already have, and the last bit, which we don't have, we will just guess that the keystream  bit there is zero. We send it to the mobile station, and the mobile station will decrypt  the message, check the checksum, and if everything is good, send an acknowledgement. If that  happens, we know the keystream guess was correct, and we have now recovered one additional bit  of keystream. If we do not get an acknowledgement, we know our guess was wrong, and we have still  recovered a bit of keystream. You can repeat this, and each time you will recover an additional  bit of keystream up to the length you desire. Now, this assumption of having initial keystream  is nice, but we need more. We need to have something that actually works in order to  generate this initial keystream. And we are going to do that by sending 16 messages to  the mobile station, and the first four bits will all be tried, and we add the last zero.  It doesn't matter what is there, but we will try 0, 0, 0, 0 up to 1, 1, 1, 1, 0. And given  how Tetra works, these four bits encode the message type on the LLC level. And what's  interesting is that for these 16 messages, there will be exactly one message that will  get an acknowledgement from the mobile station. And this is the BL data without FCS message  type. And all the other messages are either supposed to be way longer, and thus discarded  as being invalid, or will not require an acknowledgement to be sent in the first place. So we try these  16 messages, we will get one acknowledgement, and that means that we will know how the mobile  station decrypted this. So we will know four bits of keystream. That's pretty cool, but  still we need a bit more, because the shortest message we can use for the first attack we  presented here is 37 bits long. So what we do is we recover these four bits for 10 consecutive  slots. And we then craft our 37 bits message with the checksum inside of it, and we use  MAC fragmentation, a fragmentation feature Tetra offers, in order to distribute our message  over all of these small slots where we have only four bits of keystream available. The  radio will then make sure that these things are stitched back together, will decrypt them,  will validate whether the checksum makes sense. If it makes sense, you get an acknowledgement,  the story we discussed. So in this way, you can easily choose for which slot you would  like to have an additional bit of keystream, make a guess on that keystream bit, and recover  an additional bit. So when we presented this to Etsy, they said that's an interesting and  valid theoretical attack, but it's quite serious because it affects all keystream generators.  So we asked them, okay, understandable, but please provide us with a base station so we  can instrument it and validate whether this attack is actually practical. And they said,  lol no, maybe the wording was a little different. We tried more stakeholders, and they all responded  like this. So we had to go about this in another way. So what options do we have? We could  implement the Tetra infrastructure stack on a software-defined radio, and in that way  try to target our radio, but that sounds like an awful lot of work. It's very complex, painstaking,  not what we're here for, right? So what we did is get our own base station. Meet the  Motorola MBTS. It's old, it's heavy, I believe it's 75 kilos or something. It was a clear  text base station, so it doesn't support encryption, and it's cool as fuck. And we decided to transform  this thing into an attack platform. So short overview of the MBTS. It has two main components.  It has a side controller, which does all the high-level stuff, and it also holds the firmwares  for both itself and for the base radio modules. And these base radio modules, you can have  one or multiple of them. They are actually connected to the antenna. They perform modulation  and demodulation, but they also perform the encryption. Both of these components are running  on PSOS Plus real-time operating system, and based on PowerPC CPUs. Also, the MBTS has  management consoles over a serial port, so you can connect to the serial port, enter  some passwords, and then you're allowed to enter commands for diagnostics and for debugging  purposes. Interestingly, both of these things use unsigned firmwares.  So let's go do some base station hacking. We modified the firmwares in order to allow  for the implementation of a proof of concept, and the first thing we did was implement a  tinker command, which can be invoked from the command line. And our tinker command  allows raw memory access, so you can just enter a command, read memory, or with another  command write to memory. You can also execute memory by just jumping to a random memory  address as specified. And we also added malloc and free primitives so that you can allocate  blocks of memory for use for other stuff. Also, we added TEA support. We used our own  reference implementation for that, and what was very helpful was that this firmware already  supported almost the entire suite of cryptography that's required for Tetra, but it just had  an empty stop function for the keystream generator. So we replaced that, we did some more small  changes, and we had a functional encrypting base station on our hands.  We wrote a framework that allows for the loading of modules into the memory of the base station  and for the placement of hooks on functions where we were either interested in debugging  or changing the behavior. So, making implants for this base station was kind of straightforward  actually. Right, so we then decided to continue and start working on our proof of concept,  for which we dedicated the .ksreuse command, which allows the base station to suddenly  change the network time as required in order to be able to mount the attack. And also it  implements the recovery mechanisms that I've just explained to you guys.  Once we started messing with the network time, we saw that our radio rebooted, our mobile  radio rebooted, and we found that it was due to some synchronization issues in Tetra. Certain  messages are expected at certain times, and if you mess with the timing, then it will  start misinterpreting stuff. This can be resolved. We resolved it by making sure our time changes  aligned to four multi-frames. It can be done neater, it will get you a performance improvement,  but that's way beyond what a proof of concept should be. So, with some more tinkering, our  MTM radio gladly accepts any jump in network time, and we can start attacking.  One last thing on the base station, we found several vulnerabilities. For instance, the  unauthenticated firmwares, which is quite an issue for mission-critical communications.  An attacker could implant such a thing and gain permanent access to a base station, or  he can just exfiltrate keys and be on his way. Also, the firmwares of both the side  controller and the base radio have hard-coded, undocumented backdoor passwords. These passwords  give you an authentication level on the command line that's even higher than the system's  owner would normally have. Lastly, if you can crash the side controller by some kind  of unhandled exception, it will drop to a debug shell that allows you direct code execution  and memory access, once again allowing for key exfiltration.  We have looked at multiple radios, multiple base stations, and mobile stations at this  point, and there seems to be some kind of industry-wide issue here. The software stacks  that are being used are really not up to standards, and we start wondering whether  anyone is actually pen-testing these things in any condition. In any case, here is a demonstration  video for the keystream recovery attack.  Hi, we are Midnight Blue. We have uncovered several serious vulnerabilities in the Tetra  radio standard, dubbed Tetra Burst. We will first demonstrate a decryption oracle attack  to recover a text message, but the attack can also be applied to voice communication  and data. The demonstration takes place on our lab setup. The radio receives an encrypted  message which is also captured by the attacker. We see the message says secret.  The attacker now needs to target the radio and impersonate the infrastructure and carry  out the attack to decrypt the previously captured message. We have sped up this process.  The attacker has now recovered all he needs to decrypt the message. This attack applies  to all Tetra configurations, but can be resolved with a firmware update. Further details will  be disclosed on August 9th.  So this is pretty concrete, right? So what would Etsy say about this? We presented our  proof of concept status and now in their public response on the vulnerabilities we  uncovered, all they have to say on this keystream recovery issue is that our research uncovered  some general areas for improvement in the Tetra protocol.  Lastly, I would like to draw your attention to TA3. We have analyzed it and we have not  found it vulnerable, but there is something very weird going on. Now in the other TS there  is also an S-box, but these S-boxes look normal like an S-box should look. In TA3 the S-box  is not a permutation, so there is one entry that is there twice. This is highly irregular  and certainly not a positive thing for the security of this algorithm.  It might be a mistake, right? Just some random bit-flip that occurred somewhere. Well at  least it has to be a mistake when the standard was drafted because if not our radio would  not be compatible with other radios in the field. And what makes it extra suspicious  is the fact that there is another small structural change to the feedback mechanism of the key  register that hides the issue. Usually you get state merges and in this case you don't.  So there is another small difference from TA1 and TA2 that is here that kind of masks  that there is something weird going on. So at this point the impact is unclear, but we  are really asking anyone who knows his way around these kind of things to take a good  look at it and publish their findings.  So let's discuss the Coordinated Vulnerability Disclosure process. We started working on  this project in January 2021 and it took us four months to get the secret cryptography  out of the radio. The rest of the year we spent on analysis of the ciphers, on analysis  of the protocol and on building some proof of concepts. At the end of 2021, in December,  we contacted the Dutch NCSC which then started enumerating stakeholders and in January 2022  we got our first meetings with the Dutch police, with ETSI, the standardisation body and with  the intelligence community. In February we distributed a preliminary advisory that was  to be distributed among stakeholders. The remainder of the year we were in touch with  various stakeholders like manufacturers, network operators, users in order to do our best  into helping them understand the vulnerabilities and understand mitigations that they could  take.  Now let's talk mitigations. The keystream recovery attack can be resolved in firmware  because the radio can be told not to trust these weird changes in network time. It's  important, however, that these patches are properly validated because it's a tricky thing  to tackle and it's easy to get it wrong. Alternatively, end-to-end encryption can be used to have a  secondary layer of encryption on top of the air interface encryption and if you're using  a tetra radio in a data-carrying capacity, you can also consider TLS or IPSec to add  additional encryption. The TA1 backdoor obviously cannot be resolved with a firmware patch because  it's an essential part of the standard. So we would recommend TA1 users to migrate to  TA2 or alternatively, if that's not possible, use end-to-end encryption or TA3.  The de-anonymization attack also cannot be resolved with a firmware update. These users  will have to migrate to TAA2 which is a new version of the standard that Etsy has drafted  and has been published last year. This implements a new encryption mechanism for identities  that should be better. Lastly, we have the DCK pinning attack, the session key pinning  attack. This can also be resolved with a firmware update.  Thanks for that. So in the aftermath of disclosing these issues, there were some interesting  discussions with Etsy which we'd like to highlight. So in Kim Zetter's interview with the Etsy  Tetra chairman, he says a couple of interesting things. First of all, he says, well, TA1,  is it such a big deal, this backdoor? Because, you know, anyone in Europe who would need  high security would be using TA2. Well, I mean, this is not true. We look through various  standards and procurement documents and they show that TA1 equipment was procured by various  countries for police and military use in the last five years. And these are countries like  Poland, Bulgaria, Croatia, Montenegro, Moldova, all of which are either EU countries or candidate  EU countries. And some of these have been allowed to use TA2 according to Etsy's own  standards as far back as 2003 or 2008. Regardless, in the last five years they were supplied  with this backdoor algorithm within Europe. So what happened here, we don't know, but  it's not just limited to the outside of Europe. Secondly, when it comes to the use of TA1  in critical infrastructure, the chairman says, well, if you're using TA1, well, we  know that certainly a government actor could have a go at them in a short order because  that's what the researchers have proved. But he says, you know, you might be able to migrate  away or, you know, are high value targets actually using this? Well, the problem in  critical infrastructure is that you don't have a lot of choice. You can get TA1, 2,  or TA3. You're limited to TA1 due to the export controls. In many cases, there are no tetra  end-to-end solutions for the RTUs, the remote terminal units that you use in critical infrastructure.  And some of the compensated controls that you might want to take, such as TLS or IPSAC  on top of tetra, might not be supported by these RTUs either. And even if you could migrate  away to TA2 or TA3, sometimes this is just not possible in field. As you can see on the  snippet from the manual from one of the popular tetra RTUs, you pick an algorithm and then  you stick with it. You can't update it in the field. So now you're stuck with this  32 bits of security. But maybe all of the stuff we've covered, you know, maybe it doesn't  matter. Maybe it's a big nothing burger because nobody actually targets tetra networks. And  actually in Etsy's official statement, they say, Etsy and TCCA are not at this time aware  of any exploitations on operational networks. Well, that's interesting because two out of  five attacks are passive, so how are you going to notice that? And it's also not true because  we looked through the Snowden documents and we found that a joint NSA and Australian Signals  Directorate project was undertaken in 2007 against the United Nations Climate Change  Conference in Bali, where they targeted the networks of the Indonesian police and they  collected tetra communications describing demonstration routes, as well as the Bali  chief of police's private mobile phone number. Now, they don't go into the technical details,  so this is not proof of our vulnerabilities being exploited, might be, might not be,  but it does show that tetra networks are being actively targeted. We also found a second  reference in the Snowden documents where GCHQ mentions that in 2009 they undertook what  they call an effects operation called Operation Kido against Argentina around a conflict regarding  oil exploration rights tensions regarding the Falklands or Malvinas Isles. And here they  mentioned they were collecting high priority military and leadership communications and  that involved a number of tetra collects. So this shows again, you know, tetra networks  are being targeted. So, what's next? Well, Etsy announced an update to the standard.  They're going to replace the TAA1 authentication suite with TAA2. They're going to update the  TAA1 to 3 algorithms with 5 to 7. They have some mitigations around the key stream recovery  attack and they're going to keep the new algorithms all secret again. So, in the interview with  the chairman, the journalist asked, you know, if you're saying the only reason these algorithms  are secret is because the government has advised it, can Etsy actually decide to make them  public on their own? And then they say, yes, we can make that decision, and then the journalist  asks, so why don't you? And the only answer is, well, I don't know. So, should we trust  TAA6 and 7, especially because these will be the new export controlled ones? What do  you think? No. Well, let's just ask Etsy themselves first. So, the journalist says, should we  trust Etsy algorithms going forward? And then the chairman says, well, we have no reason  to produce dodgy algorithms, if you like, you know, except for the ones that they did.  And then he goes further and he says, well, these algorithms were just handed to us and  they were designed with some assistance from some government authorities. Let me put it  that way. And a little bit later he says, well, at the end of the day, it's down to  customer organizations to ensure that things are secure enough for them. I agree it's difficult  with a private algorithm, but the reason we have three different algorithms available  must be clear to someone that they're not all as secure as each other. So, you're going  to get three new different algorithms that are going to be private, so make up your own  mind about those ones. In conclusion, this has been the first public in-depth Tetra security  analysis in more than 20 years. It affects more than 100 countries, many different sectors  that are critical. We reverse engineered the secret cryptography algorithms, published  them on GitHub, so you can go take a look. Multiple vulnerabilities were uncovered, both  in the standard as well as equipment, including a backdoor in TEA-1. This has implications  for voice and data communications as well as SCADA telecontrol communications. Patches  are available for some of the issues, while mitigations will be required for others. And  I'd like to finish this talk off with a call to action, because there's much more work  to be done on Tetra. First of all, people need to take a closer look at the TEA algorithms,  especially that very fishy S-box in TEA-3. See if you can get a handle on that one. Also  take a closer look at Hurdle, the block cipher that forms the core of the authentication  suite, because an attack on Hurdle could be catastrophic for Tetra security due to our  attack on TEA-61, which gives you a little bit of a foothold to play around with that  cipher. Secondly, if you're more of a developer, we recommend to implement and extend the open  Tetra stacks that are there. The people at Osmo.com have done some great work, and you  can go talk to the Osmo.com people as well as the NLNet Foundation, who will happily  help you around, extend these open implementations. And finally, stop doing secret cryptography,  please. It's a bad idea. It always ends in tears, and it's just not polite. Stop doing  that stuff. Finally, if you want to read more, white papers will be forthcoming on tetraburst.com.  An overview of all the vulnerabilities in the radios and the base stations are on midnightblue.nl  slash retetra. The algorithms are on GitHub. If you want to ask questions to us that you  don't want to ask in public, you can always send us an email on one of the addresses below.  If you do have questions that you want to ask in public, I'd like to open the floor  for that right now. And that's that.


url: https://www.youtube.com/watch?v=Y4A7KMQEmfo
title: DEF CON 31 - Terminally Owned - 60 Years of Escaping - David Leadbeater
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=Y4A7KMQEmfo",
    "title": "DEF CON 31 - Terminally Owned - 60 Years of Escaping - David Leadbeater",
    "description": "It is 60 years since the first publication of the ASCII standard, something we now very much take for granted. ASCII introduced the Escape character; something we still use but maybe don't think about very much. The terminal is a tool all of us use. It's a way to interact with nearly every modern operating system. Underneath it uses escape codes defined in standards, some of which date back to the 1970s.\n\nLike anything which deals with untrusted user input, it has an attack surface. 20 years ago HD Moore wrote a paper on terminal vulnerabilities, finding multiple CVEs in the process. I decided it was time to revisit this class of vulnerability.\n\nIn this talk I'll look at the history of terminals and then detail the issues I found in half a dozen different terminals. Even Microsoft who historically haven't had strong terminal support didn't escape a CVE. In order to exploit these vulnerabilities they often need to be combined with a vulnerability in something else. I'll cover how to exploit these vulnerabilities in multiple ways.\n\nOverall this research found multiple remote code execution vulnerabilities across nearly all platforms and new unique ways to deliver the exploits.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 2853,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230917"
  }

  This text was transcribed using whisper model: large-v2

   Thank you. So, hello, DEF CON. I'm David. I'm here to talk about terminals. I actually  came through four terminals on the way here from the other side of the world. My flight  got rerouted, so that was four airport terminals. But that's not what I'm here to talk about.  I'm from G Research. I work for our open source team. We're not a security research company.  We're a quantitative research company, and we predict things. So, we use a lot of machine  learning, AI, but we also use a lot of infrastructure underneath that. So, our open source team  aims to improve the infrastructure we use. We contribute some projects on top of that  infrastructure. We use things like Kubernetes. But we also use terminals, and that's what  I'm here to talk about today. So, what is a terminal? Well, first of all, we need to  go back in time. So, we're going to go back to the 1960s, and what are terminals built  on? ASCII, American Standard Code for Information Interchange. We've all heard of it. Do we  know it that well? Probably, maybe. There's some strange things in it that are legacy.  We take it for granted. This very slide has ASCII on it. To give it its full name, American  Standards Association X3.4-1963. That looks like this. So, this is the ASCII standard  code. Now, if you look closely at this, it's got seven bits. It's got this large unassigned  range. It's got an escape. That's what a lot of this talk is about. There's also something  called WIU, which is who are you? And that's a way of asking the terminal on the other  end what it is. And a lot of this talk will talk about that. So, from the early days of  the ASCII standard, replies were something that were a key part of it. So, in this case,  you sent a single character, WIU, and in response, the other end would probably respond with  RU. It turns out this is all a bit vague because later on, ASCII changed, and in 1967,  they added, well, lower case, which was quite key. They also moved escape. So, now, if you  look closely at this table, all the control sequences are on the left two columns except  delete, which is actually an interesting legacy and one of those facts that I really like.  So, delete is where it is because on a punch card, if you punch out all the holes, you  delete a character. So, sort of legacy things that we still have in ASCII are designed like  that for a reason. It's one of those legacy things that doesn't hurt but is kind of amusing.  So, there's a few other details about ASCII. It only defines seven bits, as I said, although  interestingly, two years after this, in 1969, Vint Cerf wrote RFC 20, and that basically  said that the internet should use ASCII, but it also said that it should use eight-bit  characters, which is, you know, what we expect these days, but that RFC actually defines  that the eighth bit should just always be zero. So, they hadn't yet actually defined  what the eighth bit was, but they were leaving room for expansion. So, there's a lot of  sort of history here, and if you're interested in character encodings, there's some references  for this talk. There's books on it. IBM were very involved in it, and some other things.  So, 60 years ago, there were some proposals on ESCAPE. So, before ASCII was even officially  published as a standard, Bob Bemer, who was an employee of IBM, wrote an article in Communications  of the ACM called A Proposal for Character Code Compatibility, which is a bit of a wordy  thing, but basically it was saying we've got this single character set, but what are we  going to do if we need to put international characters in and so on, and that was where  ESCAPE was defined as a mechanism that allowed basically to say something different is coming  after this point. And, you know, everyone here who's done freaking or anything knows  how great in-band signaling is. So, basically this is in-band signaling, and so the second  reference is from 1963, and that was written by someone at AT&T, you know, so they really  loved in-band signaling, and so this was a proposed discipline for the use of ESCAPE,  and this was kind of the first time that what ESCAPE might mean was defined, and it's  very interesting to sort of go back at the history of this, and one of the key things  it actually defines is not what ESCAPE does, but how it is parsed essentially, and so it  says that particular letters or symbols after ESCAPE will either continue the ESCAPE sequence  or end it, and that later becomes relevant. So, what was ASCII actually used in? So, in  1963, the teletype model 33 was released, and this was one of the first devices to use  ASCII. It's kind of lost to history exactly what was using it, but, you know, this was  a thing you could type into, and it was used in the development of UNIX, so sitting down  here, this is 1972, Ken Thompson is sitting down, and Dennis Ritchie is standing up. Ken  is sitting at a teletypewriter, or a TTY, so this UNIX machine has two TTYs. We still  call them TTYs, but they're not that device any more. They're something quite different,  but this is where terminals started. So, in 1976, Leah Siegler released the ADM3A. Now,  this wasn't the first glass terminal. That was released by Datapoint in the early 70s,  but this was one of the first affordable terminals, at least at the time, in kit form.  It cost under a thousand US dollars. And the University of California at Berkeley standardised  on these for various uses, and Bill Joy had one of these. If we look closely at the keyboard,  on the very left-hand side are the configuration options, so you open a panel and change dip  switches to adjust the speed and other things like that. But if you look very closely at  the H, J, K and L keys, you see they've got arrows, and if you're a Vim user, you might  be familiar with what those do. So, this terminal was used by Bill Joy in the development of  the X editor, which had a mode called VI, and as we all know, the rest is history. So,  this was the first device that was used to develop the visual editor that we now know  on Unix. And there's another Unix reference here. If you look at the top right-hand side,  the home button has a tilde on it, and that's what the home directory is these days. Exactly  whether this is the exact reason that that is the case, people think so, but it's kind  of lost in time. But, yes, there's definitely a lot of Unix history here. But why is this  also interesting? Well, this was also one of the first terminals that let you position  the cursor anywhere on the screen. This is from the manual, which someone has kindly  preserved, and it basically says that the escape key can be used in conjunction with  character keys to position the cursor anywhere on the screen. So, rather than just moving  the cursor up and down, you can say, I want it, you know, five rows down, two across,  whatever it is, which lets you essentially implement any kind of editor or a visual application  at least as far as you can go visually in a terminal. And this was one of the first  devices to support this kind of thing. Some of the earlier terminals only supported moving  up and down, so it was more inefficient, especially over at the time people were using 300 board  modems to talk to things. So, if you imagine you have to send multiple characters to move  the cursor around, you can literally see the cursor move. So, the interesting thing in  this document is actually somewhere in the middle. It says this operation may also be  initiated by the host computer. So, the user can type this as an escape sequence, or the  computer can basically say, position this where I want on the screen. And basically  that makes VI possible. So, in 1978, the VT100 was released, and this was really continuing  the introduction of more and more features into terminals. But the interesting thing  about the VT100 is it was one of the first terminals to implement this standard, which  is known as X3.64-1979. But many people know this simply as ANSI. So, we'll get to what  that means. But to give it its full name, additional controls for use with American  National Standard Code for Information Interchange. So, basically this was, as I said earlier,  there was a working group on escape. That working group turned into this standard. There  were some other details along the way, but this was the final product. The standard was  actually released in 1979. So, the VT100 was built in development of that standard, and  OpTec actually released it before the standard was released. So, very close together development.  I haven't looked that closely at the history there, but it's quite interesting. But what  does a VT100 give us? So, it gives us escape sequences like this. So, I'm using C star  strings here. So, slash E is the escape character, and then the other things you see are just  the symbols you expect them to be. So, like I said, a particular sequence is defined.  So, here the left bracket opens a particular kind of escape sequence. Then you can have  numbers, semicolons, and then usually a letter ends the sequence. So, here the top one sets  the top and bottom margins, which is a deck specific one based on the name. The bottom  two are positioning the cursor, and those are ANSI standard ones. They don't have a  deck prefix to the name. So, we can actually just demo this. So, like on a VT100 emulator,  we can just in a command line, we can run print F, and this will do something. Sorry,  this bit is not. So, I'm actually using OpenBSD to demo this. So, here I am just logging in  as you do, but a console is a VT100 emulator, and here I can just type print F, and I've  now limited myself to the top ten lines of the screen. So, if I type clear, you can now  see I'm still hitting enter, but I don't go further down the screen, but I can use an  escape sequence to move further down the screen. So, I've now moved myself outside that restricted  region using the deck escape sequence. Now I can move 2,000 lines up. So, OpenBSD just  rebooted when I moved 2,000 lines down then. So, what just happened? So, have you tried  forcing an unexpected reboot? So, that was a present day OpenBSD bug. It resulted in  this reliability fix in early 2023, and I found that basically the VT100 emulation,  which was originally written for NetBSD in 1998, I don't think anyone had ever really  audited it. So, basically, yeah, you asked it to move around the screen, and there was  some kind of, it was basically just a bounds checking error, as it says there. I later  found another bug, so there was a further reliability fix while I was writing this talk.  I was like, that's strange. So, it turns out also if you look at those escape sequences,  I said you can have numbers and semicolons and things. It turns out if you just send  four gigabytes of semicolons, you overflowed something. Both of these will either cause  a kernel panic or a reboot, depending on exactly how they're arranged. I don't believe  they're exploitable further. I'm sure someone might prove me wrong, but I would expect that  address randomization and other recent additions to kernels limit a lot of this, and also  on a 64-bit system, you're probably far enough away and you can't actually set more than  32-bit parameters. So, maybe a 32-bit system without any address randomization might be  exploitable. So, you know, if you went back to when this code was written in 1998 and  found this bug, it would probably be far more interesting than it is right now, but no one  found it then, fortunately or unfortunately. I mean, it's interesting that this bug has  existed in OpenBSD and NetBSD for, you know, 25 years, but there you go. So, let's go to  the 1980s now. PCs. So, DOS 2.0 introduced a driver called ANSI.SYS. And actually, this  is a screenshot from PCJS.org, which is an awesome web-based PC emulator, and it actually  is quite a faithful emulation of PCs. It's not just like trying to make sure that XXX  works. It really does have the IBM BIOS and some other things. So, you can go there, type  in those commands, and if you see at the bottom where I've typed CLS and piped it to more,  that's actually something that is built into DOS. If you type CLS and it's not directly  connected to the screen, then it will output the escape sequence. In this case, I've not  actually rebooted after I've said to load ANSI.SYS. So, this is the default DOS behavior.  You just see the escape character on the screen. If you do this on the PCJS emulator, you reboot,  and it will actually run that code. So, that's how that works. Unfortunately, I have minor  technical issues. I mean, this particular demo is not going to work. So, I was going  to demo what happens with ANSI.SYS on a more recent DOS. So, basically, bulletin boards  and things use ANSI.SYS, and it was kind of awesome, you know, combined with this particular  IBM code page. This is IBM code page 437. So, I mentioned what ASCII is, but if we look  at the second half of this, there's some custom characters, and then these are the IBM PC  specific characters, and these combined with the escape sequences that the ANSI.SYS driver  gives you allows you to do art like this. This was taken from a Dreams of Insanity bulletin  board, the intro to it, and you can find this online on textfiles.com or other places. So,  how you can actually view this on a modern computer is you can actually use icon to convert  from IBM code page 437, and then you can pipe it to PV, which is a command line tool  that can do various pipe-like things on Unix, and in this case, I'm asking it to slow down  enough that it behaves like a 28K modem, and if you run that, unfortunately, the demo is  not working for reasons, but basically, you'll see the output just below it, and what that  actually looks like when you look at it in a raw form is something like this. So, you  can see the text is actually sort of here and here, but there's all these control characters  here. So, it's kind of hard if you actually just open this in an editor to see what it's  doing, and that, of course, brings us to a potential attack. So, there's something called  ANSI bombs. Now, the ANSI.SYS driver had a special ability to redefine keys. So, if you  could write something to someone's screen, you could redefine keys. Now, what I'm showing  there is actually still detected by some antiviruses. That is a real virus, and it basically  says for particular keys, redefine them. So, if you type this to the screen like it tells  you to, you do type help.txt, which is for those who have forgotten how DOS works, that's  the same as cat to the screen, basically. So, raw cat is a bad idea. Raw type is a bad  idea on DOS a long time ago. So, anyway, you do that, and then you hit enter, and what  that actually expands to is a Dell tree. So, if we just go back, each one of these, the  first sort of part of the sequence is which character to redefine. Sorry about that. So,  that's which character to redefine. And it's if we go right back to the ANSI table, which  I won't do right now, but you'll see that my favorite one here is so 27 is escape. We'll  talk about that a bit later. Eight is a good one. That's backspace. So, you think you've  made a mistake, and then you press backspace, and this silly basically this is a prank.  Bombs are always a prank. But anyway, it redefines certain keys if you cat this to your  screen, and maybe you don't immediately realize this. There were many different variants of  this. Like some were sort of weird, and you maybe didn't even touch that key. So, you  didn't know it happened, and then later on, you randomly press it. So, this wasn't really  considered a real security thing back in the day, but it's kind of amusing because it's a  predecessor to some of the things I'm going to get to. So, yeah, probably bad deleting your  C drive. And this works. As you can see here, this was on DOS 622. I demoed this, but it  worked all the way back to DOS 2 if you loaded the ANSI sys driver, which not everyone did,  and there were also secure versions of the ANSI sys driver, but obviously this was the  90s and the 80s, so CVEs weren't really a thing and stuff like that. So, you know, some  of these attacks that I'm talking about are older than you may realize. So, let's go to the  90s. So, this was from Frack in 1994, and it's a utility called Flash.C. And so it says  here it's intended to quickly mess up a user's terminal by issuing a talk request and sending  special characters and it says it's really nasty. So, let's have a look at what that actually  is. So, it sends these evil strings. So, I won't go into exactly what they all do, but one  of the ones that I mentioned earlier was the limiting to the top ten lines of the screen.  Well, this is limiting you to the top three lines of the screen. So, already that's quite  annoying because you've got a really large terminal and you can only see three lines. It  also inverts the background color. One of them is a deck specific sequence that sends a test  pattern to the screen, which basically means it fills the screen with ease. So, yeah. But  just a quick aside, because if you looked at this, you see that says slash 033. So, that's  octal. So, 033 is actually 27 in character numbers in decimal. So, there are many ways to  represent escape. I've already in this presentation shown three at the top. But you can also use  JSON and stocks talk mentioned that you probably should escape certain outputs of the screen  using that. So, yeah. You can do that in JSON. If you're writing stuff in Go, then it doesn't  do C style strings. So, slash X1B and in some cases just slash 27. And we'll get to some  other variants on this in a moment. But, yeah. So, if you see this in various different forms,  just be aware that, like, there are many ways to represent escape. So, hello, DEF CON. This  is a BT520. My dog also says hi. So, November 1995, this was released. Now, Windows 95 was  actually released before this. So, this was newish tech for the time. It did some fancy  things. But in the terminal world, it was new. In the real computer world, most people were  actually using X terms. And if we go back to this flash.C, it says in the middle that it's  actually expecting to target an X term. But let's just be time appropriate here. So, what  happens if we simulate receiving flash.C terminal DOS attack? Oops. Okay. So, this is  I'm just going to have to switch inputs. This is going to be a bit crazy. I thought I had  this video copy. Okay. That works. Yeah. So, sorry. This flickers both because the video  recording of this is kind of bad, but also there's an issue with the projector. But what  happens is the screen goes blank anyway. So, this is kind of annoying. So, if you send this  to a real terminal, a reboot of it takes several seconds. So, you literally send escape and C  and the real terminal breaks. If we remove the escape and C and we send that, then we see  roughly what we would have seen in X term or another terminal. So, it starts flashing a lot  and inverts the background. And now when we start typing, we also see our characters are not  the normal characters. So, there's a deck special alphabet that is designed for box drawing  and things. A bit like we saw the PC had its own. So, yeah. We then reset and we can see  what happened. But notice reset didn't reset the fact that the screen was inverted. So, this  really messed up your terminal. Send these things to the terminal and it's kind of broken. So,  yeah. So, let's go to 2003. So, H.D. Moore did some research and published this article  in BugTrack and Full Disclosure at the time. Terminal emulated security issues. And now this  is some of the first proper research. CVEs were still relatively new at the time. That's in  quotes because it was rather than CVEs, it was actually CANs. It's just going to go blank for a  second. So, these were CANs. And they later became CVEs. So, this is kind of interesting.  Is that going to come back? Let me just type XRNR commands for a moment. There we go. So,  this was among the first published CVEs. And so, one of the ones in here is about window title  reporting. So, I've mentioned this in some previous talks. So, sorry if you've seen that  before. But I think it's important to repeat some of this. So, what does this look like? So,  if we print something to the screen, like I showed before, you can print escape sequences to  change positions on the screen and move things around. This is a special escape sequence to  set the title. So, your shell prompt will often include the command to set the title, for  example. So, what if we set it to calc EXE? Well, that's not bad. But some terminals have a  special sequence to ask for a reply of what the title is. So, you ask for what the title is, it  replies with what the title is. And so, then this looks something a bit like this.  Which one are we doing? This one. So, yeah. So, we do something like this and calc EXE opens  back here. So, it's literally that simple. But, yeah. So, this is interesting. This wasn't an  old vulnerability. I just ran that against Con AMU, which is a Windows terminal. So, that  vulnerability from X term also exists on Con AMU and Swift term and WES term. The Con AMU  one is the most concerning, though. Because actually what I did back here, if you look  closely, I put a slash X zero D, which is also known as carry for return. So, in this case, I  didn't have to press enter. The terminal pressed enter for me. And that makes these attacks  much more scary. It's either before you had to social engineer the user into pressing enter  somehow. But it turns out actually you don't always have to do that. So, there are other  ways to deliver this. I use print F. Obviously a user running print F is a bit like someone in  a JavaScript console. Ask them to open the JavaScript console and attack themselves. But you  can run curl on things. And curl is just like catting something to the screen. So, here I have  an evil example.com. When you query it and get it with curl, it says I am good. You pipe it to  the shell and it says I am evil. And down at the bottom I've piped it to cat minus V so you can  see what's happening. And actually there's a comment and then a lot of backspace  characters. So, basically what you see is I am good when you cat it. But what the shell sees is  I am evil followed by a comment. So, you can basically make the user run one, see that they're  going to run one thing and then run something different. This is actually kind of interesting  because some recent attacks in the past year were called Trojan source where people used  Unicode to achieve similar effects in text editors. So, these kind of things have been  possible in basically anywhere you have text. Sometimes text is not just pure ASCII. There are  other things in it. Escape characters, Unicode, right to left overrides, other things. So,  these things can apply in various ways. So, cat minus V is considered good. In the 80s,  the original Unix people from Bell Labs wrote an article called cat minus V considered  harmful because they thought that cat shouldn't actually have any command line options and it  should be its own thing which is kind of amusing. But cat minus V is a good idea. Anything  that can potentially write raw text to your terminal is harmful. So, you can pipe it to cat  minus V and see what's happening. Alternatively, the program itself, if it expects to print to  a terminal, should just do the escaping itself. So, if you use curl, what else can we do?  Well, it's always DNS, isn't it? So, this is a bit crazy. But it turns out you can put lots of  things in DNS. So, the easy place to do this is text records. I can put stuff in text  records. But it turns out I can also, in many cases, put funny characters just in the host  name itself. The interesting thing about that is depending what libc you're running, it may  or may not resolve. So, what I'm sort of proposing is a slightly crazy delivery method here  is someone finds out that they can't access this host, but someone else says they can, so  they start debugging it. And it turns out that on Alpine, you can ping the relevant host  because it does follow the C name chain to the crazy thing. But glibc doesn't. And actually,  I due to unrelated vulnerability, I actually made OpenBSD change their behavior. So,  OpenBSD older versions for about 7.3, this does work. Newer versions, it doesn't. You can  also use this to tell the difference between macOS and Windows potentially. So, I reckon there's  some fun things there. Anyway, that's kind of an aside. So, what can we do with this?  So, Windows Terminal, it turns out, supports some kind of music thing. So, yeah. Let's see if  we can make this work. That's not going to work because I don't have any sound.  Yeah. Okay. So, yeah. Because I've changed a device here, that sound output is not going to work.  But anyway, so you run that in Windows, and it turns out it starts playing music here.  Which is kind of fun. But what did I just actually show you? Well, I showed you that if you  run NS lookup, then it actually just writes raw things to the screen. So, it turns out if you  actually have another bug, say, for example, you have a bug in a tool called commander, which  actually is based on con EMU that I just spoke about. So, here we are. We just do an NS lookup  on con EMU dot lab. So, yeah. The interesting thing about this is I previously disclosed this  as a bug. But actually, this still works on the fixed version. I had a bit of a discussion  with the author of con EMU about this. But if you look very closely, I'm using control O  here rather than pressing enter. So, it turns out what the author did to fix this originally  was look for carriage return and line feed. But it turns out if you're using a read line  compatible shell, and this is commander, which adds a bunch of Unix tools to Windows, then  basically it's, yeah. It runs when you press control O, it actually is bound to something  like history add and accept, which is the same as pressing enter as far as anything is  concerned. So, yeah. That's a thing. So, sorry. I'm going to have to speed up slightly because  we've got a few more of those to come. So, we're not done with DNS. It turns out there are  other tricks you can play with DNS. So, Apple terminal is actually relatively secure. I  looked at it for a while and didn't find anything. But it does have a way of setting what  your working directory is. So, the way this works is the same way that I said that a title  integrates with your shell prompt, you also integrate with your shell prompt and send the  terminal a hidden escape sequence that tells it what working directory you're currently in.  Which is, you know, that makes sense. It's useful to tell the terminal what working  directory you're in. Because it turns out up here you have a thing that tells you that you're  in either the temp or your home directory and it gives you a pretty icon of your home if  you're in your home directory. Anyway, if you actually read what's happening on the slide  here. So, I can print users DGL first of all. That works fine. I can also, it turns out, put a  host name in the file URL. And over here it does a DNS lookup on that file URL. So, it's not  like the end of the world. But it's an information leakage thing in that if I for some reason  connected to a server that maybe doesn't have access to the outside world, but the computer  that I'm connecting from does, some malicious thing on that server could write something to my  terminal and then it could actually through DNS tunnel it back to wherever. So, you can use DNS  as an exfiltration method via the terminal that some user is connected via. So, I reported this  to Apple in, as you can see here, October 2022. And they unfortunately haven't fixed it yet. So,  they're quite past the disclosure deadline for this one. It still works as far as I'm aware. I  haven't tested the very latest version. But it turns out there's also another bug which is kind  of fun. If you actually get to about 1,024 characters somewhere around there, when you open a  new tab, what it tries to do is change into that directory. And this sort of CD command you see  on screen here is what it wrote. So, it does that sort of for you. It turns out if it's longer  than the allowed directory name length on Mac OS, then it just hangs the entire terminal. So,  it's kind of a bit like a sleeping time bomb in that if you run that, then the terminal next time  someone opens a new tab will just hang and they won't actually know why. The one saving grace  there is if this actually is integrated for your prompt, the next time the prompt is displayed,  it will clear that and then it won't work. So, it's not the end of the world. So, back in HD  Moore's paper in 2003, there was a fictitious case study. And it spoke about Apache locks.  What's more relevant today? So, developers run things like Python free HTTP command lines. And  if you saw Stock's talk, I'm afraid this is basically the same demo. But which one are we on?  There we go. So, we've got an attacker down here and a victim at the top. We can't put escape  characters in via just using curl. But if we write raw to the screen, sorry, the screen. If we write  using Netcat, we can write things. And it turned out Python didn't escape the log file. So, we can  change the color of the logs. Fine. That's kind of fun. So, it turns out if we've got a terminal  vulnerability, we can do things with that as well. This is item 2. The vulnerability was that it  would reply with a user controllable string. So, what it's supposed to be used for is querying the  color. So, here it's telling us that the color is 31M red. I just changed the color back to the  default color and it says it's zero. But it turns out, yeah, if we put something else there, then  it replies up here with something else. And it turns out that can be anything else. So, the real  insight is that we can put control C there. So, by putting control C there, it will basically kill  Python. And at that point, we can run anything we want in the terminal. So, we put control C.  Because of how this works in item 2, we kind of have to split each control character into its own  escape sequence. But it turns out Python just doesn't care what the HTTP request looks like. So,  we can just really put any characters we feel like in the request thing and eventually the  calculator pops up. So, that was a bug in item 2 that was fixed. And as I mentioned, the request  selection or setting, which is a specific escape sequence used for querying the color and thing,  there was an implementation bug in that. And, yeah, it unexpectedly echoed a string back.  Control C is also part of a string. So, we can press control C. And I call this a full echo back.  So, how about another one? So, this is Git for Windows or also known as Git Bash. So, here we're  cloning a Git repository. We go into this Git repository. It's called bad Git. Interesting. We  run Git log. So, what does Git log normally do? Well, Git log opens calculator today.  So, if we pipe that to cat minus V, we'll see up here it says just below is an escape  sequence. And that's actually in the commit log of this Git repository. And it's also a  cross platform exploit, as you might notice. Because this is actually the same bug as the item  2 one. It's deck RQSS. And it turned out Mintity on Windows was vulnerable to this. So, yeah.  Sorry. Slides loading slowly here. But we'll get there. So, yeah. So, Git uses LESS as a  pager. And LESS had a bug in its OSC 8 hyperlink handling. So, there's a way of embedding hyperlinks  in terminals now. LESS supports this so that things like man pages can make their links in  them clickable. It turns out that if you've got a bug in LESS and a bug in a terminal, then it  means that anything you write to basically anywhere in Git, you can then write that escape  characters to the screen. So, the actual issue is that here where I've got if you remember earlier  I said that escape C is like a terminal reset thing. It turns out that LESS wasn't looking for  particular escape characters ending something. So, here this ended it as far as Mintity was  concerned. But it didn't end the escape sequence inside the OSC 8 as far as LESS was concerned.  And the funny thing about this is this bug was disclosed earlier this year. In the  posting of it, I sort of said it was a denial of service attack. And then later on I worked out  actually this can also be used for a bit more when I found a terminal exploit. I don't know if  anyone else noticed that. But anyway. So, we're getting a bit low on time. So, I'm going to run a  little bit faster here. So, basically this deck RQS thing I showed was actually an extern bug.  And it's funny because it was documented incorrectly in the extern manual of control sequences and  then various other terminals have recreated similar bugs. So, let's just go to a slightly  different thing. So, we've got a shared system. Administrator gets an alert about excessive  memory usage. Starts debugging. What command do you run? Top someone said. Good. So, what if  there was a bug in top? Which video is it? That one. So, here I've got top oops, that went too  quickly. I've got a script running on the sorry. We'll try that again. I forgot how short this  video was. So, here we're running top minus capital O, sorry, minus O capital res. And on the  left hand side we've got a little script running. And what just happened? Well, you got owned. So,  it turns out this is an extern bug in its optional graphics support. So,  basically we can do something like this. So, we can get escape sequences into top. Regis is a  particular graphics thing that digital invented in the 80s and some of their terminals supported  this. So, if you tell extern to run in compatibility mode of one of those terminals and then you print  some special sequence, it replies with something like A1 equals XXX. And the exploit essentially  is you can build up a you don't get very many characters but you can build up an environment  variable if you run about ten different processes. So, it's a bit obscure. The extern Regis support  isn't default. Some distributions enable it. But top 3.X doesn't do escaping. 4.X does. Very few  distros have it. I failed to convince the top authors this is a security problem. As far as  they're concerned, there are other ways to spoof things in top. So, it's actually the terminal's  problem. And this can also be used as a Docker escape. So, if you're running as the administrator  outside Docker and you run top, you still see processes inside Docker. So, potentially there  are other avenues to this. But we can also attack Kubernetes here. So, let's have a look at  Windows Terminal. So, this is Windows Terminal. Here I'm just running busy box and deliberately  running this as a nobody user. So, this is, you know, not no special privileges here. But there  is this interesting file called termination log. And so, if we write an exploit to termination log  and then actually we just exit. For whatever reason, this container has just died. So, the  administrator starts debugging what's happening here. So, how do you debug Kubernetes? You run  kubectl. So, there's this pod running. It just said it's restarted. So, maybe the administrator  got an alert it restarted or something. So, the first thing you run is kubectl describe that pod.  And then nothing really happens. There's no message which is a bit strange. But, yeah, the  victim over here doesn't really know what's happening. They start debugging a bit more. So,  they decide they're going to duplicate this tab so they can have more context. So, this was  I'm going to skip that one. So, that was a Windows terminal bug. But what can we do with  documented escape characters? Well, it turns out there's certain replies that do interesting  things. So, if, for example, we ask what color something is, colors in some terminals are  separated with slashes. And where can we find lack of escaping? So, we can put files on disk  and see if things do that. It turns out NMCLI on Linux, if we happen to connect to a wireless  network with an escape character in it, I've got a network at home called red. It was actually the  color red. Bluetooth CTL on Linux mostly doesn't escape things. Some of these are hard to exploit.  You don't get many characters. But like I showed at the top, you can create lots and lots of  devices or networks or something. And, you know, comment forms on website. See Stock's talk more  on that. But let's have a quick demo. I'm running out of time. So, I'm going a little bit faster  than expected here. But here I've got a script that sets up a particular thing in slash TMP.  So, now I'm just typing CD slash TMP. And I hit tab like you often do, right? To see what exists  in that directory. So, when I hit tab, what happens? My cursor disappears. That's strange.  So, I'm not sure what happens. I press control C. And then I hit enter and everything goes red  and it all gets a bit broken. So, what just happened there? So,  the slides for this will be up later. I'm going to skip this quickly. But basically,  you hide the cursor. You ask what color it is. And because you're in a control directory slash TMP,  you created a file that the shell printed out on screen. And basically, magically,  the user basically has to hit enter. There's an escape sequence for X term that makes it so  control C just writes some escape characters to the screen. So, there's literally nothing you can  do except close the terminal or press enter. So, you social engineer the user into they probably  press enter because they think their terminal's broken. So, how do you protect yourself from all  this? So, terminals are just like a browser. They deal with untrusted inputs. Ensure correct  output escaping. Secure settings. That's a fun one. Just go and turn this on right now unless  you actually use the shell integration features. There might be bugs there. Who knows? Also,  ST is a cool terminal. You should use it. It's really basic. If you don't want the features  your terminal gives you, you limit your exposure by using basic things. There's probably some  end days here. So, I'm crazy. And if you've got a phone or something, try that particular IP  address. It's on the DEF CON network. It will test your terminal. And I want to make this  repository public. Yeah, yeah, yeah. How many buttons do you have to press to do that? Oh,  really? Okay. Anyway. So, I just published that.  So, in writing that tool, I found another bug. Yeah. That's all the bugs I found. Thank you very  much.


