# MediaChunks

chunk_id: 208_chunk_1
chunk_text:
for malicious traffic.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2486, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 8.48s | This text was transcribed using whisper model: large-v2 So my name is Aapo. I do a lot of things with IoT, but especially for my work 8.48s - 15.32s | security research, consulting, and mainly look at IoT and other kinds of devices. 15.32s - 20.96s | I work a lot on cryptography and network protocols. Outside of that, 20.96s - 25.88s | bug bounty. So if you run a hardware bug bounty program, you know where to find 25.88s - 36.02s | me, and I'm also a coach for a Finnish CTF team. But yeah, so here is some IoT 36.02s - 44.90s | and my trusty EPC, and I want to kind of see how it works. I might want to hack it 44.90s - 53.22s | or I might want to check out something about it. This particular device connects 53.22s - 58.98s | to the Internet with an Ethernet port or Wi-Fi. So that should be quite 58.98s - 64.02s | straightforward. If we want to know where it's connecting to, and that's a 64.02s - 71.98s | big part of IoT, we can simply plug in an Ethernet cable to the device and the 71.98s - 78.08s | other end to our laptop, and then on our laptop in the Ethernet interface, we will 78.08s - 85.62s | see any traffic it's trying to send. We can do the same with Wi-Fi. So if we have 85.62s - 91.38s | our access point, the device connected to it, and then again we will see the 91.38s - 99.97s | traffic on the Ethernet interface. But there are some kind of devices, and 99.97s - 105.81s | especially industrial IoT, that have a very specialized job and they have been 105.81s - 111.53s | made to be very cheap. So they have only one way to connect to the Internet, and 111.53s - 117.61s | nowadays a big part of it is some kind of something else than Ethernet or 117.61s - 125.05s | Wi-Fi. So today we will be talking about these kind of devices. So some kind of 125.05s - 131.61s | 4G connection on this one, and how that works. There's a modem, you plug in a SIM 131.61s - 137.01s | card and it


chunk_id: 208_chunk_2
chunk_text:
big part of IoT, we can simply plug in an Ethernet cable to the device and the 71.98s - 78.08s | other end to our laptop, and then on our laptop in the Ethernet interface, we will 78.08s - 85.62s | see any traffic it's trying to send. We can do the same with Wi-Fi. So if we have 85.62s - 91.38s | our access point, the device connected to it, and then again we will see the 91.38s - 99.97s | traffic on the Ethernet interface. But there are some kind of devices, and 99.97s - 105.81s | especially industrial IoT, that have a very specialized job and they have been 105.81s - 111.53s | made to be very cheap. So they have only one way to connect to the Internet, and 111.53s - 117.61s | nowadays a big part of it is some kind of something else than Ethernet or 117.61s - 125.05s | Wi-Fi. So today we will be talking about these kind of devices. So some kind of 125.05s - 131.61s | 4G connection on this one, and how that works. There's a modem, you plug in a SIM 131.61s - 137.01s | card and it connects to 4G, and it's connected to the Internet. But the 137.01s - 145.37s | problem is, how do we actually see the data? So this is kind of the topic of 145.45s - 151.86s | today. There are also different kind of devices, they might have multiple ways of 151.86s - 157.34s | connecting to the Internet. So here we have a phone currently connected to my 157.34s - 161.18s | Wi-Fi access point, and I can see everything it's sending to the Internet. 161.18s - 168.14s | Or can I? So if you might not be able to see it, but there's a little 5G icon 168.14s - 173.62s | there, so it's actually connected to 5G as well. So a question is, is there 173.62s - 181.30s | traffic over 5G as well? So it might be something built-in, there might be 181.30s - 191.46s | something malicious. So let's talk about that. So why would you want to look into 191.46s - 197.34s | mobile network traffic? If you're just a tinkerer, if you're at DEF CON here, or 197.34s - 202.38s | watching this video, then you might be curious. You might care about your


chunk_id: 208_chunk_3
chunk_text:
connects to 4G, and it's connected to the Internet. But the 137.01s - 145.37s | problem is, how do we actually see the data? So this is kind of the topic of 145.45s - 151.86s | today. There are also different kind of devices, they might have multiple ways of 151.86s - 157.34s | connecting to the Internet. So here we have a phone currently connected to my 157.34s - 161.18s | Wi-Fi access point, and I can see everything it's sending to the Internet. 161.18s - 168.14s | Or can I? So if you might not be able to see it, but there's a little 5G icon 168.14s - 173.62s | there, so it's actually connected to 5G as well. So a question is, is there 173.62s - 181.30s | traffic over 5G as well? So it might be something built-in, there might be 181.30s - 191.46s | something malicious. So let's talk about that. So why would you want to look into 191.46s - 197.34s | mobile network traffic? If you're just a tinkerer, if you're at DEF CON here, or 197.34s - 202.38s | watching this video, then you might be curious. You might care about your 202.38s - 209.30s | privacy. You might think, where do my devices talk to? Is there some kind of 209.30s - 215.18s | unencrypted private information flying through the air? And if you are in 215.18s - 220.54s | traveling in some countries, you might want to kind of know what exactly your 220.54s - 227.94s | devices are sending. From offensive security point of view, we might think 227.94s - 232.02s | that can we tamper with the traffic and find vulnerabilities? If you do 232.02s - 238.06s | penetration testing, and you have these kind of devices, you need to hack them, 238.06s - 245.06s | you need to kind of do some kind of security audit or something like that, 245.06s - 250.14s | you might want to look at the traffic. Can you actually say we've kind of 250.14s - 258.49s | penetration tested this, if you haven't looked at the mobile traffic? From 258.49s - 263.29s | defensive point of view, you might want to detect malicious traffic, or just 263.29s - 269.53s | filter some unwanted things. You can do this in most cases on the device, so if 269.53s - 274.37s | you


chunk_id: 208_chunk_4
chunk_text:
202.38s - 209.30s | privacy. You might think, where do my devices talk to? Is there some kind of 209.30s - 215.18s | unencrypted private information flying through the air? And if you are in 215.18s - 220.54s | traveling in some countries, you might want to kind of know what exactly your 220.54s - 227.94s | devices are sending. From offensive security point of view, we might think 227.94s - 232.02s | that can we tamper with the traffic and find vulnerabilities? If you do 232.02s - 238.06s | penetration testing, and you have these kind of devices, you need to hack them, 238.06s - 245.06s | you need to kind of do some kind of security audit or something like that, 245.06s - 250.14s | you might want to look at the traffic. Can you actually say we've kind of 250.14s - 258.49s | penetration tested this, if you haven't looked at the mobile traffic? From 258.49s - 263.29s | defensive point of view, you might want to detect malicious traffic, or just 263.29s - 269.53s | filter some unwanted things. You can do this in most cases on the device, so if 269.53s - 274.37s | you have a phone, you can install something and it will kind of filter 274.37s - 278.85s | things, or endpoint detection, or whatever. But if you have some advanced 278.85s - 284.53s | malware on your phone, it might not respect the on-device protections. So if 284.53s - 291.61s | it's running on very low inside the operating system, it can easily just not 291.61s - 299.30s | allow the endpoint protection to run. So we might not want to do the testing on 299.30s - 310.97s | the device, we want to do it outside. So what are these mobile networks? Sometimes 310.97s - 316.53s | called like cellular networks, and these come in different flavors. There is 2G, 316.53s - 325.53s | 3G, 4G, 5G, etc. Some older ones, but I think these are the currently used, 325.53s - 333.37s | and in 4G and in 5G, there are these slightly different, like NB-IoT is a 333.37s - 342.53s | special version of LTE, but the main thing is that you have different 342.53s - 352.54s | frequency bands and special radios that can talk with these protocols. Usually 352.54s - 358.38s | the mobile networks are operated


chunk_id: 208_chunk_5
chunk_text:
have a phone, you can install something and it will kind of filter 274.37s - 278.85s | things, or endpoint detection, or whatever. But if you have some advanced 278.85s - 284.53s | malware on your phone, it might not respect the on-device protections. So if 284.53s - 291.61s | it's running on very low inside the operating system, it can easily just not 291.61s - 299.30s | allow the endpoint protection to run. So we might not want to do the testing on 299.30s - 310.97s | the device, we want to do it outside. So what are these mobile networks? Sometimes 310.97s - 316.53s | called like cellular networks, and these come in different flavors. There is 2G, 316.53s - 325.53s | 3G, 4G, 5G, etc. Some older ones, but I think these are the currently used, 325.53s - 333.37s | and in 4G and in 5G, there are these slightly different, like NB-IoT is a 333.37s - 342.53s | special version of LTE, but the main thing is that you have different 342.53s - 352.54s | frequency bands and special radios that can talk with these protocols. Usually 352.54s - 358.38s | the mobile networks are operated by Internet Service Providers, so ISPs, and 358.38s - 364.30s | they have massive amounts of base stations all over the world, so if you 364.30s - 371.02s | have a civilization, you most likely have a mobile network there. And how 371.02s - 376.62s | you use these mobile networks is you just buy a subscription from an ISP, they 376.62s - 381.86s | will give you a SIM card or send it to you, and then you plug the SIM card into 381.86s - 388.10s | your device, the SIM card authenticates you to the network, and then you connect. 388.10s - 396.02s | You can kind of send text messages or phone calls, but nobody really does that 396.02s - 401.74s | anymore, so it's mainly used to route IP traffic from your device to the 401.74s - 408.65s | Internet or wherever you want to go. Usually this mobile network stuff, this 408.65s - 414.13s | is very specialized, and it comes in this separate hardware module called a modem, 414.13s - 422.69s | and that's a separate device on your device. These modems are very complex, 422.69s - 427.81s | usually run their own operating


chunk_id: 208_chunk_6
chunk_text:
by Internet Service Providers, so ISPs, and 358.38s - 364.30s | they have massive amounts of base stations all over the world, so if you 364.30s - 371.02s | have a civilization, you most likely have a mobile network there. And how 371.02s - 376.62s | you use these mobile networks is you just buy a subscription from an ISP, they 376.62s - 381.86s | will give you a SIM card or send it to you, and then you plug the SIM card into 381.86s - 388.10s | your device, the SIM card authenticates you to the network, and then you connect. 388.10s - 396.02s | You can kind of send text messages or phone calls, but nobody really does that 396.02s - 401.74s | anymore, so it's mainly used to route IP traffic from your device to the 401.74s - 408.65s | Internet or wherever you want to go. Usually this mobile network stuff, this 408.65s - 414.13s | is very specialized, and it comes in this separate hardware module called a modem, 414.13s - 422.69s | and that's a separate device on your device. These modems are very complex, 422.69s - 427.81s | usually run their own operating systems, and are basically a small computer that 427.81s - 438.51s | you just connect to your board, and then it handles a lot of things. Here you can 438.51s - 445.43s | see a picture of this, so on the left we have a mobile device, it has a CPU and 445.43s - 452.35s | the modem, and the CPU runs some kind of operating system, Linux or Windows or 452.35s - 458.07s | whatever, and then talks with the modem and offloads the actual mobile network 458.07s - 463.83s | thing to it, and then you just give it data, and the data somehow finds its way 463.83s - 473.47s | into the Internet. On 4G we have these cell towers, so these are the base 473.47s - 478.59s | stations that are all over the world, and they, your device usually connects to 478.59s - 484.51s | the nearest one or the one with the least amount of traffic, so they handle 484.51s - 491.99s | it themselves. The cell tower is connected to the ISP infrastructure, so 491.99s - 497.27s | there's different kind of things, we're not going to go that in depth, because 498.07s


chunk_id: 208_chunk_7
chunk_text:
systems, and are basically a small computer that 427.81s - 438.51s | you just connect to your board, and then it handles a lot of things. Here you can 438.51s - 445.43s | see a picture of this, so on the left we have a mobile device, it has a CPU and 445.43s - 452.35s | the modem, and the CPU runs some kind of operating system, Linux or Windows or 452.35s - 458.07s | whatever, and then talks with the modem and offloads the actual mobile network 458.07s - 463.83s | thing to it, and then you just give it data, and the data somehow finds its way 463.83s - 473.47s | into the Internet. On 4G we have these cell towers, so these are the base 473.47s - 478.59s | stations that are all over the world, and they, your device usually connects to 478.59s - 484.51s | the nearest one or the one with the least amount of traffic, so they handle 484.51s - 491.99s | it themselves. The cell tower is connected to the ISP infrastructure, so 491.99s - 497.27s | there's different kind of things, we're not going to go that in depth, because 498.07s - 503.99s | this talk not only covers 4G, but all kinds of mobile networks. But usually 503.99s - 510.39s | they have similar way of operating, so first the radio connects to a serving 510.39s - 515.99s | gateway, and some kind of authentication mechanism, so the SIM card from the 515.99s - 523.31s | modem talks with the off, and then your mobile device is then, the traffic is 523.31s - 533.13s | routed with these packet gateways to the Internet. So how do we intercept this 533.13s - 537.57s | mobile network traffic? So if we want to analyze it, we need to see it, to see it 537.57s - 546.43s | we need to somehow intercept it at some point. So of course the easiest way to 546.43s - 553.71s | intercept traffic is on the device, so just log in, run TCP dump, and you will 553.71s - 560.31s | see the network connections. So if you have a Linux based device, the CPU is 560.31s - 564.83s | sending the data to the modem, but you can look at the traffic already on the 564.83s - 570.47s | device, so no need to any


chunk_id: 208_chunk_8
chunk_text:
- 503.99s | this talk not only covers 4G, but all kinds of mobile networks. But usually 503.99s - 510.39s | they have similar way of operating, so first the radio connects to a serving 510.39s - 515.99s | gateway, and some kind of authentication mechanism, so the SIM card from the 515.99s - 523.31s | modem talks with the off, and then your mobile device is then, the traffic is 523.31s - 533.13s | routed with these packet gateways to the Internet. So how do we intercept this 533.13s - 537.57s | mobile network traffic? So if we want to analyze it, we need to see it, to see it 537.57s - 546.43s | we need to somehow intercept it at some point. So of course the easiest way to 546.43s - 553.71s | intercept traffic is on the device, so just log in, run TCP dump, and you will 553.71s - 560.31s | see the network connections. So if you have a Linux based device, the CPU is 560.31s - 564.83s | sending the data to the modem, but you can look at the traffic already on the 564.83s - 570.47s | device, so no need to any kind of fancy things. So if you can do this, it's very 570.47s - 575.35s | powerful, and especially if you want to know if your device is accepting 575.35s - 579.31s | connections, you might want to take a look at that from the device, so no need 579.31s - 584.47s | to scan all UDP ports if you just like type in a command that shows you all 584.47s - 591.32s | listening UDP ports. This however requires root access to the device, so if 591.32s - 597.24s | you want to hack something, you might not have this, or if you have some kind 597.24s - 602.88s | of secure device, like an iPhone, you might not be able to have enough 602.88s - 608.98s | permissions to do this. And also I said that the modem has its own operating 608.98s - 613.66s | system, might have some over there updates, some of the functionality can be 613.66s - 619.30s | offloaded to it, so for example FTP, you can just say to the modem that hey 619.86s - 625.82s | download these files from this FTP server and hand them to me. And that might


chunk_id: 208_chunk_9
chunk_text:
kind of fancy things. So if you can do this, it's very 570.47s - 575.35s | powerful, and especially if you want to know if your device is accepting 575.35s - 579.31s | connections, you might want to take a look at that from the device, so no need 579.31s - 584.47s | to scan all UDP ports if you just like type in a command that shows you all 584.47s - 591.32s | listening UDP ports. This however requires root access to the device, so if 591.32s - 597.24s | you want to hack something, you might not have this, or if you have some kind 597.24s - 602.88s | of secure device, like an iPhone, you might not be able to have enough 602.88s - 608.98s | permissions to do this. And also I said that the modem has its own operating 608.98s - 613.66s | system, might have some over there updates, some of the functionality can be 613.66s - 619.30s | offloaded to it, so for example FTP, you can just say to the modem that hey 619.86s - 625.82s | download these files from this FTP server and hand them to me. And that might not 625.82s - 630.78s | be secure, and if you're just looking at the traffic on the device, you will most 630.78s - 635.26s | likely you will not see that. And if you're doing penetration testing and you 635.26s - 638.50s | have been relying on this, I have bad news for you, you haven't kind of done 638.50s - 647.53s | your work really well. And we have found a lot of vulnerabilities in the modems. 647.53s - 652.93s | So if we actually want to intercept the traffic, there is the CPU, there's a 652.93s - 657.89s | modem, so how this works is they have some kind of serial interface, usually 657.89s - 663.93s | not encrypted because you don't really need to, and just kind of look at the 663.93s - 670.09s | board and find the traces and sniff them. This works with these AT commands, 670.09s - 674.21s | sometimes a little bit different, but basically the CPU says to the modem that 674.25s - 678.85s | hey please make a connection to Google and then send this data through that 678.85s - 686.59s | connection and you will get the traffic. So


chunk_id: 208_chunk_10
chunk_text:
not 625.82s - 630.78s | be secure, and if you're just looking at the traffic on the device, you will most 630.78s - 635.26s | likely you will not see that. And if you're doing penetration testing and you 635.26s - 638.50s | have been relying on this, I have bad news for you, you haven't kind of done 638.50s - 647.53s | your work really well. And we have found a lot of vulnerabilities in the modems. 647.53s - 652.93s | So if we actually want to intercept the traffic, there is the CPU, there's a 652.93s - 657.89s | modem, so how this works is they have some kind of serial interface, usually 657.89s - 663.93s | not encrypted because you don't really need to, and just kind of look at the 663.93s - 670.09s | board and find the traces and sniff them. This works with these AT commands, 670.09s - 674.21s | sometimes a little bit different, but basically the CPU says to the modem that 674.25s - 678.85s | hey please make a connection to Google and then send this data through that 678.85s - 686.59s | connection and you will get the traffic. So you can just kind of sniff the 686.59s - 692.39s | traffic and decode it and or even replace the modem with your own software 692.39s - 698.79s | based simulator. So this is something that we've already done. In some cases 698.79s - 704.27s | it's quite simple, if you have kind of clear traces and you just solder your 704.55s - 711.26s | serial port adapter to it and pull the modem to reset, you can do this. But of 711.26s - 716.14s | course it requires hardware reverse engineering and some tiny soldering and 716.14s - 725.74s | again there's very complex setup sometimes, so it might not be as easy as 725.74s - 736.07s | it's shown here. And we cannot see the modem's own traffic here as well. I 736.19s - 740.63s | usually have written my own because it's quite simple to do, but I found this 740.63s - 746.67s | GitHub project that seems to have made a similar thing. So if you want to play 746.67s - 756.04s | around with this you can look at that and try it out. The next thing I tried to 756.04s - 761.08s | run


chunk_id: 208_chunk_11
chunk_text:
you can just kind of sniff the 686.59s - 692.39s | traffic and decode it and or even replace the modem with your own software 692.39s - 698.79s | based simulator. So this is something that we've already done. In some cases 698.79s - 704.27s | it's quite simple, if you have kind of clear traces and you just solder your 704.55s - 711.26s | serial port adapter to it and pull the modem to reset, you can do this. But of 711.26s - 716.14s | course it requires hardware reverse engineering and some tiny soldering and 716.14s - 725.74s | again there's very complex setup sometimes, so it might not be as easy as 725.74s - 736.07s | it's shown here. And we cannot see the modem's own traffic here as well. I 736.19s - 740.63s | usually have written my own because it's quite simple to do, but I found this 740.63s - 746.67s | GitHub project that seems to have made a similar thing. So if you want to play 746.67s - 756.04s | around with this you can look at that and try it out. The next thing I tried to 756.04s - 761.08s | run my own base station because I want to see the modem traffic. I figured out 761.08s - 767.84s | just like I have my Wi-Fi access point, I'll do a 4G access point. You can buy 767.84s - 774.88s | this, you can build your own and the software defined radios can do pretty 774.88s - 779.60s | much anything nowadays. Just a couple hundred bucks and open source software 779.60s - 786.08s | and you can do this. A basic setup, like a thousand bucks, not that much if you're 786.08s - 792.76s | into kind of professional penetration testing, but it requires a week worth of 792.80s - 798.40s | work to get running and if you want to buy the commercial thing then it's really 798.40s - 806.52s | expensive. The problem with these, the radio bands are heavily licensed, they 806.52s - 812.96s | are used quite a lot and that means that kind of all available bands have been 812.96s - 817.96s | bought by someone, so it's illegal to run without a Faraday cage. So you need to 817.96s - 824.60s | have a kind of pouch that you put your radio in and


chunk_id: 208_chunk_12
chunk_text:
my own base station because I want to see the modem traffic. I figured out 761.08s - 767.84s | just like I have my Wi-Fi access point, I'll do a 4G access point. You can buy 767.84s - 774.88s | this, you can build your own and the software defined radios can do pretty 774.88s - 779.60s | much anything nowadays. Just a couple hundred bucks and open source software 779.60s - 786.08s | and you can do this. A basic setup, like a thousand bucks, not that much if you're 786.08s - 792.76s | into kind of professional penetration testing, but it requires a week worth of 792.80s - 798.40s | work to get running and if you want to buy the commercial thing then it's really 798.40s - 806.52s | expensive. The problem with these, the radio bands are heavily licensed, they 806.52s - 812.96s | are used quite a lot and that means that kind of all available bands have been 812.96s - 817.96s | bought by someone, so it's illegal to run without a Faraday cage. So you need to 817.96s - 824.60s | have a kind of pouch that you put your radio in and your device in and you 824.60s - 829.40s | have to kind of be careful not to leak the thing because someone will find you 829.40s - 835.52s | and come find you. Some of the frequency bands can be licensed, some countries 835.52s - 843.32s | have unlicensed bands, but then you're limited into that one band or that one 843.32s - 850.12s | physical location where you are running this. So if you're into this, there's the 850.12s - 855.08s | LibraCellular, they have good instructions how to do this, but I have 855.08s - 863.88s | something better for you. So let's go back to the 4G mobile network. We have 863.88s - 869.32s | our mobile device, it talks to the cell tower and then there's the authentication 869.32s - 879.14s | and some other stuff. But what exactly is that other stuff? Like I said, the devices 879.18s - 884.54s | are authenticated with SIM cards and then there's some kind of a packet 884.54s - 891.22s | filtering going on. There is this thing called lawful interception that kind of 891.22s - 898.38s | means that your traffic can be inspected by the authorities


chunk_id: 208_chunk_13
chunk_text:
your device in and you 824.60s - 829.40s | have to kind of be careful not to leak the thing because someone will find you 829.40s - 835.52s | and come find you. Some of the frequency bands can be licensed, some countries 835.52s - 843.32s | have unlicensed bands, but then you're limited into that one band or that one 843.32s - 850.12s | physical location where you are running this. So if you're into this, there's the 850.12s - 855.08s | LibraCellular, they have good instructions how to do this, but I have 855.08s - 863.88s | something better for you. So let's go back to the 4G mobile network. We have 863.88s - 869.32s | our mobile device, it talks to the cell tower and then there's the authentication 869.32s - 879.14s | and some other stuff. But what exactly is that other stuff? Like I said, the devices 879.18s - 884.54s | are authenticated with SIM cards and then there's some kind of a packet 884.54s - 891.22s | filtering going on. There is this thing called lawful interception that kind of 891.22s - 898.38s | means that your traffic can be inspected by the authorities and I think if it can 898.38s - 906.10s | be inspected then it most likely is. But yeah, other things that it does is 906.34s - 913.06s | policy enforcement. So basically it means if you buy a slow speed subscription, it 913.06s - 919.38s | will make sure that you won't get good speeds. They calculate the billing, so if 919.38s - 923.54s | you have a kind of per megabyte subscription then they calculate the 923.54s - 931.62s | megabytes. Then they route the packets. So there might be some kind of ISP 931.66s - 936.74s | internal things like DNS servers, so some of the things might not go to the 936.74s - 941.74s | internet at all. So they might go to kind of internal DNS service or something 945.74s - 952.47s | else. But also the packets can be routed internally in different ways. So we have 955.75s - 960.75s | these things called APNs, which basically mean that how to get the packets to the 963.39s - 968.39s | ISP. So this is something that if you're old, you know what these are because 973.03s - 977.63s | you've kind of gotten a


chunk_id: 208_chunk_14
chunk_text:
and I think if it can 898.38s - 906.10s | be inspected then it most likely is. But yeah, other things that it does is 906.34s - 913.06s | policy enforcement. So basically it means if you buy a slow speed subscription, it 913.06s - 919.38s | will make sure that you won't get good speeds. They calculate the billing, so if 919.38s - 923.54s | you have a kind of per megabyte subscription then they calculate the 923.54s - 931.62s | megabytes. Then they route the packets. So there might be some kind of ISP 931.66s - 936.74s | internal things like DNS servers, so some of the things might not go to the 936.74s - 941.74s | internet at all. So they might go to kind of internal DNS service or something 945.74s - 952.47s | else. But also the packets can be routed internally in different ways. So we have 955.75s - 960.75s | these things called APNs, which basically mean that how to get the packets to the 963.39s - 968.39s | ISP. So this is something that if you're old, you know what these are because 973.03s - 977.63s | you've kind of gotten a new SIM card, you put it in and it doesn't work and then 977.63s - 982.11s | you need to go to these and then you need to type something. But nowadays you 982.11s - 986.51s | might not even know that these exist. So and if you need to type something in 986.51s - 992.39s | just type in internet and then you get to the internet. These are actually used 993.39s - 999.23s | so you might have some kind of restricted internet or something. So some 999.23s - 1004.23s | ISPs offer some kind of child safe things so they do more more things. Or 1008.37s - 1012.95s | some kind of at some point you can kind of get more speed if you from some 1012.95s - 1016.95s | certain ISP. So if you don't use the internet but you use something else then 1016.95s - 1020.99s | it's faster because there's less people there or or something like that. But 1020.99s - 1025.99s | usually just you use what comes with the subscription. So these a big change 1030.07s - 1034.63s | nowadays that these are pushed usually through the network to your device. So


chunk_id: 208_chunk_15
chunk_text:
new SIM card, you put it in and it doesn't work and then 977.63s - 982.11s | you need to go to these and then you need to type something. But nowadays you 982.11s - 986.51s | might not even know that these exist. So and if you need to type something in 986.51s - 992.39s | just type in internet and then you get to the internet. These are actually used 993.39s - 999.23s | so you might have some kind of restricted internet or something. So some 999.23s - 1004.23s | ISPs offer some kind of child safe things so they do more more things. Or 1008.37s - 1012.95s | some kind of at some point you can kind of get more speed if you from some 1012.95s - 1016.95s | certain ISP. So if you don't use the internet but you use something else then 1016.95s - 1020.99s | it's faster because there's less people there or or something like that. But 1020.99s - 1025.99s | usually just you use what comes with the subscription. So these a big change 1030.07s - 1034.63s | nowadays that these are pushed usually through the network to your device. So 1034.63s - 1038.37s | when you connect and you don't have an APN, the modem asks the network that 1038.37s - 1045.38s | hey, do you have something for me and then it's automatically set up. You can 1045.38s - 1051.40s | change these, configure them manually on the device, but it might not be 1051.42s - 1055.30s | respected by the ISP. So it basically just tells the ISP hey this is what I 1055.30s - 1063.72s | want but it can of course offer you whatever it wants. So there is this 1065.00s - 1070.00s | thing called private APN. So something that you can kind of buy as a service. 1074.36s - 1079.38s | So if you run big fleets of IOT devices you might want to buy this from an ISP. 1079.84s - 1084.84s | So they will set you up with a internal network where your devices are 1088.12s - 1092.52s | connected to and they might not go to the internet at all or there might be 1092.52s - 1098.16s | some kind of you can run your own server there or something like that. It's a 1098.16s - 1103.16s | private network and


chunk_id: 208_chunk_16
chunk_text:
1034.63s - 1038.37s | when you connect and you don't have an APN, the modem asks the network that 1038.37s - 1045.38s | hey, do you have something for me and then it's automatically set up. You can 1045.38s - 1051.40s | change these, configure them manually on the device, but it might not be 1051.42s - 1055.30s | respected by the ISP. So it basically just tells the ISP hey this is what I 1055.30s - 1063.72s | want but it can of course offer you whatever it wants. So there is this 1065.00s - 1070.00s | thing called private APN. So something that you can kind of buy as a service. 1074.36s - 1079.38s | So if you run big fleets of IOT devices you might want to buy this from an ISP. 1079.84s - 1084.84s | So they will set you up with a internal network where your devices are 1088.12s - 1092.52s | connected to and they might not go to the internet at all or there might be 1092.52s - 1098.16s | some kind of you can run your own server there or something like that. It's a 1098.16s - 1103.16s | private network and they can be configured however. So routing, filtering, 1104.16s - 1109.16s | everything can be configured and direct connection between the devices are 1113.50s - 1118.54s | kind of at least you can configure them to be allowed. So this is a big 1118.54s - 1123.54s | difference to normal APNs that you cannot really do device to device 1125.14s - 1131.88s | connections but you just have to go through the internet. These also by 1131.90s - 1136.90s | default usually they don't filter the traffic so it's sometimes the ISPs 1139.58s - 1144.58s | don't really like some kind of traffic or if you do like port scanning over 1145.68s - 1149.92s | mobile network they might shut you down and you don't really know if it works 1149.92s - 1157.83s | or not. So you can also set the private APN to connect you to the internet so 1159.33s - 1163.57s | you have access to all these services and then you can get also access to the 1163.59s - 1168.59s | internet maybe even with a static IP that then you can configure your servers 1169.53s - 1174.57s | to only accept that. So then it's


chunk_id: 208_chunk_17
chunk_text:
they can be configured however. So routing, filtering, 1104.16s - 1109.16s | everything can be configured and direct connection between the devices are 1113.50s - 1118.54s | kind of at least you can configure them to be allowed. So this is a big 1118.54s - 1123.54s | difference to normal APNs that you cannot really do device to device 1125.14s - 1131.88s | connections but you just have to go through the internet. These also by 1131.90s - 1136.90s | default usually they don't filter the traffic so it's sometimes the ISPs 1139.58s - 1144.58s | don't really like some kind of traffic or if you do like port scanning over 1145.68s - 1149.92s | mobile network they might shut you down and you don't really know if it works 1149.92s - 1157.83s | or not. So you can also set the private APN to connect you to the internet so 1159.33s - 1163.57s | you have access to all these services and then you can get also access to the 1163.59s - 1168.59s | internet maybe even with a static IP that then you can configure your servers 1169.53s - 1174.57s | to only accept that. So then it's used quite heavily in IOT so that's where I 1174.57s - 1179.57s | found out that this exists and a lot of the customers are using this so I kind 1181.61s - 1186.61s | of figured that this sounds something that kind of if we want to do this 1187.33s - 1192.33s | inspect the packets and they use the same things for the lawful interception 1194.07s - 1199.07s | things then it might help me kind of look at my traffic. So I had this 1201.37s - 1206.37s | question, could I get a private APN? Sounds expensive and I went on a journey 1208.35s - 1213.35s | to send a bunch of emails to different ISPs and I found out that there's a huge 1214.33s - 1219.33s | variance in price and usability so the first place I went they had this contact 1221.97s - 1226.97s | us for pricing and they were like yeah we can do this no problem so you just pay 1228.21s - 1233.21s | us 3k to get started and then 500 monthly. So I was like yeah this sounds a bit 1234.31s - 1239.31s | too much for a proof of concept


chunk_id: 208_chunk_18
chunk_text:
used quite heavily in IOT so that's where I 1174.57s - 1179.57s | found out that this exists and a lot of the customers are using this so I kind 1181.61s - 1186.61s | of figured that this sounds something that kind of if we want to do this 1187.33s - 1192.33s | inspect the packets and they use the same things for the lawful interception 1194.07s - 1199.07s | things then it might help me kind of look at my traffic. So I had this 1201.37s - 1206.37s | question, could I get a private APN? Sounds expensive and I went on a journey 1208.35s - 1213.35s | to send a bunch of emails to different ISPs and I found out that there's a huge 1214.33s - 1219.33s | variance in price and usability so the first place I went they had this contact 1221.97s - 1226.97s | us for pricing and they were like yeah we can do this no problem so you just pay 1228.21s - 1233.21s | us 3k to get started and then 500 monthly. So I was like yeah this sounds a bit 1234.31s - 1239.31s | too much for a proof of concept and I might as well just run my own base station 1239.45s - 1244.45s | in a couple of offices. The next place they were also contact us for pricing but 1245.45s - 1250.45s | I was pleasantly surprised so they also said that hey just go to our self service 1251.19s - 1256.19s | portal and activate it and you're good to go and they had a 100 USD setup fee 1257.03s - 1262.03s | and 150 bucks a month so this is completely doable. There was another place 1262.33s - 1267.33s | so they have this $10 setup fee and 75 cents per hour so different pricing 1271.27s - 1276.27s | models so if you look at the similar schemes here so the first one if you kind 1277.51s - 1282.51s | of no matter how much you use it it's 250 bucks but then for a year it's just 1283.65s - 1288.65s | 2k so you can rent it out easily and the other one so 30 bucks a day, 100 bucks 1289.35s - 1294.35s | a week and 6.5k for a year so if you want to kind of do it for longer times you 1296.85s


chunk_id: 208_chunk_19
chunk_text:
and I might as well just run my own base station 1239.45s - 1244.45s | in a couple of offices. The next place they were also contact us for pricing but 1245.45s - 1250.45s | I was pleasantly surprised so they also said that hey just go to our self service 1251.19s - 1256.19s | portal and activate it and you're good to go and they had a 100 USD setup fee 1257.03s - 1262.03s | and 150 bucks a month so this is completely doable. There was another place 1262.33s - 1267.33s | so they have this $10 setup fee and 75 cents per hour so different pricing 1271.27s - 1276.27s | models so if you look at the similar schemes here so the first one if you kind 1277.51s - 1282.51s | of no matter how much you use it it's 250 bucks but then for a year it's just 1283.65s - 1288.65s | 2k so you can rent it out easily and the other one so 30 bucks a day, 100 bucks 1289.35s - 1294.35s | a week and 6.5k for a year so if you want to kind of do it for longer times you 1296.85s - 1301.85s | might want to have this local ISP and then if you just want it for a day then you 1304.59s - 1311.80s | have options for that. There is a lot of difference in coverage so some of them 1312.88s - 1316.78s | are really global they offer services in all the countries some are US specific, 1316.80s - 1321.80s | some are EU specific and even some that are just inside your country. There's 1323.30s - 1327.42s | also differences in the available data plans so you still have to pay for your 1327.42s - 1331.92s | subscription even though you have the private APN because it's kind of a 1331.92s - 1336.92s | different thing. Some of the like IOT orientated ISPs they offer a really good 1339.82s - 1345.76s | pricing that you only pay like 2 bucks a year if you send 100 kilobytes of data a 1345.78s - 1350.78s | year but if you want to look at your phone traffic I recommend not using these 1351.28s - 1356.28s | IOT things because it might be costly but some of just regular ISPs offer this so 1361.20s - 1366.02s | then you


chunk_id: 208_chunk_20
chunk_text:
- 1301.85s | might want to have this local ISP and then if you just want it for a day then you 1304.59s - 1311.80s | have options for that. There is a lot of difference in coverage so some of them 1312.88s - 1316.78s | are really global they offer services in all the countries some are US specific, 1316.80s - 1321.80s | some are EU specific and even some that are just inside your country. There's 1323.30s - 1327.42s | also differences in the available data plans so you still have to pay for your 1327.42s - 1331.92s | subscription even though you have the private APN because it's kind of a 1331.92s - 1336.92s | different thing. Some of the like IOT orientated ISPs they offer a really good 1339.82s - 1345.76s | pricing that you only pay like 2 bucks a year if you send 100 kilobytes of data a 1345.78s - 1350.78s | year but if you want to look at your phone traffic I recommend not using these 1351.28s - 1356.28s | IOT things because it might be costly but some of just regular ISPs offer this so 1361.20s - 1366.02s | then you can use your own already kind of own subscriptions and you can have 1366.02s - 1371.04s | like unlimited data for whatever you are paying for it in your country and then 1371.72s - 1379.12s | you can push that to the private APN. So how to configure this? Like once you buy 1380.52s - 1385.52s | it first you want to disable the traffic filtering if there is one and then disable 1386.96s - 1390.64s | routing to the internet because we don't want the devices to connect to the 1390.64s - 1397.97s | internet without us seeing it. Next just the side to side VPN between the private 1398.31s - 1403.31s | APN and kind of our cloud server. We could do a bunch of these things inside the 1406.41s - 1410.99s | private APN but I kind of like to be in control of what I do and have like a 1410.99s - 1415.99s | command line access to the server where the data is. But once we have the tunnel we 1418.23s - 1423.73s | can set our cloud server as the default gateway for the network and that basically 1423.73s - 1428.77s | means that


chunk_id: 208_chunk_21
chunk_text:
can use your own already kind of own subscriptions and you can have 1366.02s - 1371.04s | like unlimited data for whatever you are paying for it in your country and then 1371.72s - 1379.12s | you can push that to the private APN. So how to configure this? Like once you buy 1380.52s - 1385.52s | it first you want to disable the traffic filtering if there is one and then disable 1386.96s - 1390.64s | routing to the internet because we don't want the devices to connect to the 1390.64s - 1397.97s | internet without us seeing it. Next just the side to side VPN between the private 1398.31s - 1403.31s | APN and kind of our cloud server. We could do a bunch of these things inside the 1406.41s - 1410.99s | private APN but I kind of like to be in control of what I do and have like a 1410.99s - 1415.99s | command line access to the server where the data is. But once we have the tunnel we 1418.23s - 1423.73s | can set our cloud server as the default gateway for the network and that basically 1423.73s - 1428.77s | means that all the data from the SIM cards first go to the private APN and then it 1428.77s - 1433.77s | just shoves through the VPN tunnel into our cloud server. And this basically should 1436.05s - 1443.13s | mean that the SIM card data is now on our cloud server. And so we need to add some 1444.87s - 1449.87s | mobile devices to the private APN so we have our SIM card we push it into the device. 1450.47s - 1455.47s | Some ISPs kind of require you to set some APN settings on the device so they are not 1459.75s - 1464.75s | pushing anything to the devices or they are roaming and you kind of need to set it up. 1467.09s - 1471.95s | And kind of some of the ISPs that say that you need to set the APN and you need to set it to 1471.95s - 1476.97s | this you might be able to just set anything and it works like on some carriers and then some 1477.47s - 1482.47s | it doesn't and it's it's weird. So yeah. And then there are some ISPs like if you actually 1489.05s - 1494.05s | run


chunk_id: 208_chunk_22
chunk_text:
all the data from the SIM cards first go to the private APN and then it 1428.77s - 1433.77s | just shoves through the VPN tunnel into our cloud server. And this basically should 1436.05s - 1443.13s | mean that the SIM card data is now on our cloud server. And so we need to add some 1444.87s - 1449.87s | mobile devices to the private APN so we have our SIM card we push it into the device. 1450.47s - 1455.47s | Some ISPs kind of require you to set some APN settings on the device so they are not 1459.75s - 1464.75s | pushing anything to the devices or they are roaming and you kind of need to set it up. 1467.09s - 1471.95s | And kind of some of the ISPs that say that you need to set the APN and you need to set it to 1471.95s - 1476.97s | this you might be able to just set anything and it works like on some carriers and then some 1477.47s - 1482.47s | it doesn't and it's it's weird. So yeah. And then there are some ISPs like if you actually 1489.05s - 1494.05s | run both the kind of ISP and you run the kind of infrastructure and you run the cell towers 1496.09s - 1501.59s | and everything then you have more control over things. So you have this easy checkbox that 1501.59s - 1506.59s | just redirect everything to the private APN no matter what settings or anything there's on 1507.63s - 1512.63s | the device. So this is something that you want to look for when you are testing devices that 1515.47s - 1520.47s | don't want to be tested because then you just it thinks it's connected to normal internet 1521.51s - 1528.18s | but it's connected to you. And this should be it. So profit. Let's see. So this is a 1533.38s - 1539.62s | proof of concept for this. So I talked about there's the IOT device connected to some of uh 1539.62s - 1544.62s | some AS uh ISP and then there's a private APN configured uh inside the ISP. We have the IPsec 1547.74s - 1552.74s | VPN tunnel to our server and then I'm SSH into the server. So uh yeah. Let's see a demo. So 1553.74s - 1560.69s | um here we have the trusty


chunk_id: 208_chunk_23
chunk_text:
both the kind of ISP and you run the kind of infrastructure and you run the cell towers 1496.09s - 1501.59s | and everything then you have more control over things. So you have this easy checkbox that 1501.59s - 1506.59s | just redirect everything to the private APN no matter what settings or anything there's on 1507.63s - 1512.63s | the device. So this is something that you want to look for when you are testing devices that 1515.47s - 1520.47s | don't want to be tested because then you just it thinks it's connected to normal internet 1521.51s - 1528.18s | but it's connected to you. And this should be it. So profit. Let's see. So this is a 1533.38s - 1539.62s | proof of concept for this. So I talked about there's the IOT device connected to some of uh 1539.62s - 1544.62s | some AS uh ISP and then there's a private APN configured uh inside the ISP. We have the IPsec 1547.74s - 1552.74s | VPN tunnel to our server and then I'm SSH into the server. So uh yeah. Let's see a demo. So 1553.74s - 1560.69s | um here we have the trusty EPC. So it's kind of it's doesn't require fancy things. You just SSH 1569.63s - 1574.63s | into your uh server. My server is called private APN because it's connected to the private APN. 1577.27s - 1582.27s | Here we are running a TCP dump so the interface is the IPsec VPN tunnel interface and we're looking 1582.29s - 1587.29s | for traffic from host uh 10.2.2.2.0.1. And yeah. So we have the uh 2.2.2.0.1 SIM card so that 1599.88s - 1604.88s | has like statically uh static IP that every time that uh SIM card is pushed to a device it will 1606.82s - 1611.82s | get that IP address and here it is uh booting up and I'm really interested to see what it 1612.44s - 1617.44s | actually does. So let's see. Of course takes some time to boot but uh we have uh yeah. And now 1628.04s - 1633.04s | we see some traffic. So it wants to know the time. So not that interesting after all. But if 1635.98s - 1642.16s | you leave the SIM card to the device then you will see some uh unencrypted uh location data 1642.20s - 1648.18s | from


chunk_id: 208_chunk_24
chunk_text:
EPC. So it's kind of it's doesn't require fancy things. You just SSH 1569.63s - 1574.63s | into your uh server. My server is called private APN because it's connected to the private APN. 1577.27s - 1582.27s | Here we are running a TCP dump so the interface is the IPsec VPN tunnel interface and we're looking 1582.29s - 1587.29s | for traffic from host uh 10.2.2.2.0.1. And yeah. So we have the uh 2.2.2.0.1 SIM card so that 1599.88s - 1604.88s | has like statically uh static IP that every time that uh SIM card is pushed to a device it will 1606.82s - 1611.82s | get that IP address and here it is uh booting up and I'm really interested to see what it 1612.44s - 1617.44s | actually does. So let's see. Of course takes some time to boot but uh we have uh yeah. And now 1628.04s - 1633.04s | we see some traffic. So it wants to know the time. So not that interesting after all. But if 1635.98s - 1642.16s | you leave the SIM card to the device then you will see some uh unencrypted uh location data 1642.20s - 1648.18s | from that. So if you're running that tracker somewhere uh the ISP knows where you're kind of 1648.18s - 1653.18s | uh exactly where you're running it. It's kind of uh one nice thing about this setup is also you 1655.22s - 1660.22s | just kind of uh put the SIM card into something and then you see the traffic. So here is a modem. 1662.02s - 1667.02s | It's used to connect uh laptops or ethernet based devices uh to the internet with 4G. So here is 1667.96s - 1672.96s | booting up. And I like I said it runs its own operating system. This is kind of a device but it 1677.00s - 1682.50s | might also be a chip uh inside your phone or whatever. But they run their own operating 1682.50s - 1687.52s | systems. So once it's uh booted up uh we can see that it has so it actually says here zero 1688.52s - 1693.52s | devices connected. But there's uh data there. So it's connecting to netgear.com and uh a lot 1700.06s - 1706.04s | of doing a lot of things. So it's downloading or checking for software updates. But luckily we 1706.04s -


chunk_id: 208_chunk_25
chunk_text:
that. So if you're running that tracker somewhere uh the ISP knows where you're kind of 1648.18s - 1653.18s | uh exactly where you're running it. It's kind of uh one nice thing about this setup is also you 1655.22s - 1660.22s | just kind of uh put the SIM card into something and then you see the traffic. So here is a modem. 1662.02s - 1667.02s | It's used to connect uh laptops or ethernet based devices uh to the internet with 4G. So here is 1667.96s - 1672.96s | booting up. And I like I said it runs its own operating system. This is kind of a device but it 1677.00s - 1682.50s | might also be a chip uh inside your phone or whatever. But they run their own operating 1682.50s - 1687.52s | systems. So once it's uh booted up uh we can see that it has so it actually says here zero 1688.52s - 1693.52s | devices connected. But there's uh data there. So it's connecting to netgear.com and uh a lot 1700.06s - 1706.04s | of doing a lot of things. So it's downloading or checking for software updates. But luckily we 1706.04s - 1712.38s | can see that it's uh 443 so it's DLS traffic and I couldn't use my certmetem tool to hack that. 1712.38s - 1717.38s | So it's it can be okay. Maybe. But now we at least know that it's it's not uh completely bad. 1722.96s - 1727.96s | And also so here next up we have an iPhone. So we're booting it up and uh I have the SIM card 1732.40s - 1738.14s | tray and you can see me struggle getting it in. So this is the kind of hardest part of the setup 1738.14s - 1743.92s | is actually kind of boosting the SIM card inside. One of our project uh kind of penetration 1743.94s - 1747.88s | tester push the SIM card and it we heard this kind of clunk clunk clunk clunk clunk clunk 1747.88s - 1752.38s | because it was inside the device and it was a competition and we only had 30 minutes so we had 1752.38s - 1758.80s | to shake it out of the device. But yeah that was one joke and uh that's all of them. So if we 1758.80s - 1763.66s | push the SIM card into the


chunk_id: 208_chunk_26
chunk_text:
1712.38s | can see that it's uh 443 so it's DLS traffic and I couldn't use my certmetem tool to hack that. 1712.38s - 1717.38s | So it's it can be okay. Maybe. But now we at least know that it's it's not uh completely bad. 1722.96s - 1727.96s | And also so here next up we have an iPhone. So we're booting it up and uh I have the SIM card 1732.40s - 1738.14s | tray and you can see me struggle getting it in. So this is the kind of hardest part of the setup 1738.14s - 1743.92s | is actually kind of boosting the SIM card inside. One of our project uh kind of penetration 1743.94s - 1747.88s | tester push the SIM card and it we heard this kind of clunk clunk clunk clunk clunk clunk 1747.88s - 1752.38s | because it was inside the device and it was a competition and we only had 30 minutes so we had 1752.38s - 1758.80s | to shake it out of the device. But yeah that was one joke and uh that's all of them. So if we 1758.80s - 1763.66s | push the SIM card into the device you can see it's actually locked. So this is the first boot 1763.66s - 1768.66s | before unlock. We push a SIM card into an iPhone. So let's see what happens. Yeah. Okay. So 1774.74s - 1779.74s | it's connecting to somewhere. So in here I think it's doing uh some uh push notifications or it's 1783.92s - 1788.92s | uh getting that. And I think it uh won't do that many things before you actually unlock it but we 1791.06s - 1796.06s | are actually seeing something. So if you are into hacking locked devices you might want to look 1796.52s - 1801.52s | into this. So yeah. So this is the demo. That's uh how easy to actually run it uh once you've set 1808.56s - 1825.88s | it up. Yeah. And let's get back to this question. So is there traffic over 5G as well? So of 1828.28s - 1834.06s | course when I made this slide I was like hey I will need to kind of uh check it. So this is my 1834.08s - 1840.74s | phone. I connected it to a Wi-Fi then I pushed the uh same SIM card into it and


chunk_id: 208_chunk_27
chunk_text:
device you can see it's actually locked. So this is the first boot 1763.66s - 1768.66s | before unlock. We push a SIM card into an iPhone. So let's see what happens. Yeah. Okay. So 1774.74s - 1779.74s | it's connecting to somewhere. So in here I think it's doing uh some uh push notifications or it's 1783.92s - 1788.92s | uh getting that. And I think it uh won't do that many things before you actually unlock it but we 1791.06s - 1796.06s | are actually seeing something. So if you are into hacking locked devices you might want to look 1796.52s - 1801.52s | into this. So yeah. So this is the demo. That's uh how easy to actually run it uh once you've set 1808.56s - 1825.88s | it up. Yeah. And let's get back to this question. So is there traffic over 5G as well? So of 1828.28s - 1834.06s | course when I made this slide I was like hey I will need to kind of uh check it. So this is my 1834.08s - 1840.74s | phone. I connected it to a Wi-Fi then I pushed the uh same SIM card into it and this is what I 1840.74s - 1847.58s | see. So even though it's connected to Wi-Fi you will see traffic. So these are the I think 1847.58s - 1854.00s | similar Apple push notifications. Uh first when I Googled these IP addresses I went kind of uh 1854.00s - 1859.00s | the first match was some weird Russian forum and I got scared. Um but turned out it's uh maybe 1859.88s - 1864.88s | not some uh malware on my phone. But yeah. So there is uh something that the operating system 1872.51s - 1877.51s | does so it overrides the Wi-Fi and pushes directly uh through the 5G. And if there is some kind of 1879.89s - 1887.54s | advanced malware then it might also pop up here. So proof of concept it's kind of uh kind of uh 1887.54s - 1897.28s | yes. So um from kind of moving on from the proof of concept to an actual project that uh you 1903.86s - 1910.10s | guys can use. Uh so I collaborated with some IOT security experts. Some of them are here in the 1910.10s - 1915.10s | room and they have had the same exact problems.


chunk_id: 208_chunk_28
chunk_text:
this is what I 1840.74s - 1847.58s | see. So even though it's connected to Wi-Fi you will see traffic. So these are the I think 1847.58s - 1854.00s | similar Apple push notifications. Uh first when I Googled these IP addresses I went kind of uh 1854.00s - 1859.00s | the first match was some weird Russian forum and I got scared. Um but turned out it's uh maybe 1859.88s - 1864.88s | not some uh malware on my phone. But yeah. So there is uh something that the operating system 1872.51s - 1877.51s | does so it overrides the Wi-Fi and pushes directly uh through the 5G. And if there is some kind of 1879.89s - 1887.54s | advanced malware then it might also pop up here. So proof of concept it's kind of uh kind of uh 1887.54s - 1897.28s | yes. So um from kind of moving on from the proof of concept to an actual project that uh you 1903.86s - 1910.10s | guys can use. Uh so I collaborated with some IOT security experts. Some of them are here in the 1910.10s - 1915.10s | room and they have had the same exact problems. So how do you of course they have the problem 1916.06s - 1921.06s | of how do you kind of uh look at your mobile traffic and a bunch of them were in the face of 1925.00s - 1930.00s | using their own uh kind of mobile base stations and uh software defined radios and kind of 1932.54s - 1936.88s | trying to use an IOT device that you need to kind of boot up and then you need to press a 1936.88s - 1942.76s | button but once it's inside the bag it's kind of hard to best press the button and uh then I 1942.78s - 1947.86s | told about this that hey I I kind of uh think this is the way to do it and and kind of I can 1947.86s - 1952.86s | see them contemplating kind of uh years worth of uh doing all the previous steps. And yeah 1959.44s - 1966.10s | some uh I also heard that they are running similar set up than I do. Like one person I know 1966.10s - 1972.73s | that has been running this uh and a bunch of that haven't. So of course I'm from


chunk_id: 208_chunk_29
chunk_text:
So how do you of course they have the problem 1916.06s - 1921.06s | of how do you kind of uh look at your mobile traffic and a bunch of them were in the face of 1925.00s - 1930.00s | using their own uh kind of mobile base stations and uh software defined radios and kind of 1932.54s - 1936.88s | trying to use an IOT device that you need to kind of boot up and then you need to press a 1936.88s - 1942.76s | button but once it's inside the bag it's kind of hard to best press the button and uh then I 1942.78s - 1947.86s | told about this that hey I I kind of uh think this is the way to do it and and kind of I can 1947.86s - 1952.86s | see them contemplating kind of uh years worth of uh doing all the previous steps. And yeah 1959.44s - 1966.10s | some uh I also heard that they are running similar set up than I do. Like one person I know 1966.10s - 1972.73s | that has been running this uh and a bunch of that haven't. So of course I'm from Finland so I 1974.41s - 1979.69s | we have the kind of uh holy land of uh network connectivity so of course everything works 1979.69s - 1984.69s | there. Uh it's cheap and uh stuff like that. So I wanted to look at the US where it's uh the 1986.79s - 1991.79s | opposite. There's it's not cheap um and also EU and global stuff. So it turns out a lot of ISPs 1996.47s - 2001.47s | and companies offer affordable private APNs and um they a little bit different but uh 2004.47s - 2009.47s | I created this uh GitHub page so it's online now and you can see this uh to get uh uh some up 2014.21s - 2021.05s | to date things. So they are there are global ISPs there so one of the 10 bucks uh to set up 2021.05s - 2026.05s | and 20 bucks per day thing works everywhere. Uh if you've seen me uh before today I've kind of 2026.65s - 2031.65s | given out bunch of SIM cards so you can try this out. But uh there would should be something 2035.29s - 2040.29s | there that works in your country. Uh


chunk_id: 208_chunk_30
chunk_text:
Finland so I 1974.41s - 1979.69s | we have the kind of uh holy land of uh network connectivity so of course everything works 1979.69s - 1984.69s | there. Uh it's cheap and uh stuff like that. So I wanted to look at the US where it's uh the 1986.79s - 1991.79s | opposite. There's it's not cheap um and also EU and global stuff. So it turns out a lot of ISPs 1996.47s - 2001.47s | and companies offer affordable private APNs and um they a little bit different but uh 2004.47s - 2009.47s | I created this uh GitHub page so it's online now and you can see this uh to get uh uh some up 2014.21s - 2021.05s | to date things. So they are there are global ISPs there so one of the 10 bucks uh to set up 2021.05s - 2026.05s | and 20 bucks per day thing works everywhere. Uh if you've seen me uh before today I've kind of 2026.65s - 2031.65s | given out bunch of SIM cards so you can try this out. But uh there would should be something 2035.29s - 2040.29s | there that works in your country. Uh but of course the global IOT uh providers might be too 2043.43s - 2048.57s | expensive for your use case if you want to use more data. Uh and if you want to use kind of 2048.57s - 2055.15s | your existing uh mobile plans or you want to use your local ISP you really should kind of show 2055.15s - 2061.05s | them this GitHub page and ask them hey do you want to go there on the GitHub page so people 2061.05s - 2066.05s | will buy your services and uh figure out if you can make it work. Uh if they have to do it 2068.53s - 2073.53s | manually it will be expensive so uh usually you want to look for something that has a the 2075.23s - 2080.23s | self-service portal that works. But yeah. So this is my kind of uh full set up that I run. 2085.15s - 2090.15s | So I have the multiple IOT devices connecting to an ISP and so a global ISP one of the 2092.99s - 2097.99s | devices is in Helsinki in uh in my home. One is here in Las Vegas and they are kind of


chunk_id: 208_chunk_31
chunk_text:
but of course the global IOT uh providers might be too 2043.43s - 2048.57s | expensive for your use case if you want to use more data. Uh and if you want to use kind of 2048.57s - 2055.15s | your existing uh mobile plans or you want to use your local ISP you really should kind of show 2055.15s - 2061.05s | them this GitHub page and ask them hey do you want to go there on the GitHub page so people 2061.05s - 2066.05s | will buy your services and uh figure out if you can make it work. Uh if they have to do it 2068.53s - 2073.53s | manually it will be expensive so uh usually you want to look for something that has a the 2075.23s - 2080.23s | self-service portal that works. But yeah. So this is my kind of uh full set up that I run. 2085.15s - 2090.15s | So I have the multiple IOT devices connecting to an ISP and so a global ISP one of the 2092.99s - 2097.99s | devices is in Helsinki in uh in my home. One is here in Las Vegas and they are kind of in the 2100.33s - 2105.33s | opposite sides of the world but they still connect to the same ISP and they do the ISP stuff, 2107.73s - 2112.73s | go into the private APN uh different uh ISPs have different kind of uh uh tunnels and 2115.51s - 2120.51s | but uh they end up in my my server. There I run WireGuard but you can also set up uh another 2123.09s - 2128.09s | type of VPN uh for your pentesting like uh workstations. So here I have on the right like a 2130.89s - 2137.03s | Kali Linux machine in Helsinki. Uh some of my colleagues maybe be in Stockholm and they have 2137.03s - 2143.63s | the same. And uh with this uh VPN server on the cloud server so there's like one to one mapping 2143.63s - 2148.63s | so IOT like SIM card one goes to VPN profile one and the VPN profile one is opened uh in 2151.63s - 2158.63s | Helsinki and then the traffic just magically goes there. So once you set up this uh if you are 2158.63s - 2163.71s | working in a company your colleagues will love you. You


chunk_id: 208_chunk_32
chunk_text:
in the 2100.33s - 2105.33s | opposite sides of the world but they still connect to the same ISP and they do the ISP stuff, 2107.73s - 2112.73s | go into the private APN uh different uh ISPs have different kind of uh uh tunnels and 2115.51s - 2120.51s | but uh they end up in my my server. There I run WireGuard but you can also set up uh another 2123.09s - 2128.09s | type of VPN uh for your pentesting like uh workstations. So here I have on the right like a 2130.89s - 2137.03s | Kali Linux machine in Helsinki. Uh some of my colleagues maybe be in Stockholm and they have 2137.03s - 2143.63s | the same. And uh with this uh VPN server on the cloud server so there's like one to one mapping 2143.63s - 2148.63s | so IOT like SIM card one goes to VPN profile one and the VPN profile one is opened uh in 2151.63s - 2158.63s | Helsinki and then the traffic just magically goes there. So once you set up this uh if you are 2158.63s - 2163.71s | working in a company your colleagues will love you. You just hand them out SIM cards, you 2163.71s - 2170.11s | hand them out uh uh VPN profiles and then like they're hey what's this and you just hey push 2170.13s - 2174.97s | that in there and then just double click that and then you see the data and everyone's amazed 2174.97s - 2182.01s | and you're a hero. So uh it's that easy. But you can of course don't have to have this fancy 2182.01s - 2190.68s | setup if you just want to do everything on the cloud server you can do it there. Um also like I 2190.68s - 2195.68s | said on the GitHub you have um a list of uh private APNs. The list is quite small because I use 2195.90s - 2200.90s | things that uh I found that work in Finland. When I flew here I tested uh London so in London 2207.14s - 2214.08s | this works great. Uh here uh I run into the problem that the modem I was using to kind of uh 2214.08s - 2219.08s | figure out if they uh work in different ways uh doesn't work in the US because I noticed that 2219.62s -


chunk_id: 208_chunk_33
chunk_text:
just hand them out SIM cards, you 2163.71s - 2170.11s | hand them out uh uh VPN profiles and then like they're hey what's this and you just hey push 2170.13s - 2174.97s | that in there and then just double click that and then you see the data and everyone's amazed 2174.97s - 2182.01s | and you're a hero. So uh it's that easy. But you can of course don't have to have this fancy 2182.01s - 2190.68s | setup if you just want to do everything on the cloud server you can do it there. Um also like I 2190.68s - 2195.68s | said on the GitHub you have um a list of uh private APNs. The list is quite small because I use 2195.90s - 2200.90s | things that uh I found that work in Finland. When I flew here I tested uh London so in London 2207.14s - 2214.08s | this works great. Uh here uh I run into the problem that the modem I was using to kind of uh 2214.08s - 2219.08s | figure out if they uh work in different ways uh doesn't work in the US because I noticed that 2219.62s - 2224.62s | the US has different mobile network stuff for some reason. But um I I tested that this work 2229.76s - 2234.74s | well on my phone here so I just push it into my phone and I can see the traffic uh on the 2234.74s - 2239.74s | server. So confirm to work well um everywhere in the world. But yeah so let's wrap up and uh 2243.50s - 2248.50s | go back to the kind of why do would you want to do this. So curiosity and privacy. 50 bucks 2255.18s - 2261.76s | couple days of tinkering on a device like that's a good deal. Um it's actually the 15 bucks 2261.76s - 2266.76s | is like one evening of like six hours of of uh tinkering with this. So not not much. And 2267.76s - 2274.76s | even if you use this uh if you want to use it for a longer time you might want to look into uh 2274.76s - 2281.70s | other options that are kind of uh less expensive in long term. But hacker spaces or even 2281.70s - 2287.94s | tiniest penetration testing companies like 2K a year should be


chunk_id: 208_chunk_34
chunk_text:
2224.62s | the US has different mobile network stuff for some reason. But um I I tested that this work 2229.76s - 2234.74s | well on my phone here so I just push it into my phone and I can see the traffic uh on the 2234.74s - 2239.74s | server. So confirm to work well um everywhere in the world. But yeah so let's wrap up and uh 2243.50s - 2248.50s | go back to the kind of why do would you want to do this. So curiosity and privacy. 50 bucks 2255.18s - 2261.76s | couple days of tinkering on a device like that's a good deal. Um it's actually the 15 bucks 2261.76s - 2266.76s | is like one evening of like six hours of of uh tinkering with this. So not not much. And 2267.76s - 2274.76s | even if you use this uh if you want to use it for a longer time you might want to look into uh 2274.76s - 2281.70s | other options that are kind of uh less expensive in long term. But hacker spaces or even 2281.70s - 2287.94s | tiniest penetration testing companies like 2K a year should be a no brainer to uh if you 2287.94s - 2296.02s | really want to uh look at the traffic. Offensive security. So if you do penetration testing 2296.04s - 2302.76s | on IOT and you say to your customers that hey we kind of look at the device and look where 2302.76s - 2308.90s | it's connects to. You really need some kind of setup to do this and 2,000 a year versus an 2308.90s - 2315.60s | illegal setup that's kind of you need to have your best engineers work a week on. So that's 2315.60s - 2322.78s | really expensive as well. These devices especially in industrial IOT um they're everywhere and 2323.10s - 2330.08s | people don't really look at their traffic that much. So there's just a handful of companies 2330.08s - 2335.08s | that actually I know that do this but now anyone can do this. And like I said maybe some 2339.64s - 2345.34s | new attack vectors for high security devices that if you can push a SIM card in and it you get 2345.34s - 2350.34s | the data then you can also uh send some uh malicious things uh to it.


chunk_id: 208_chunk_35
chunk_text:
a no brainer to uh if you 2287.94s - 2296.02s | really want to uh look at the traffic. Offensive security. So if you do penetration testing 2296.04s - 2302.76s | on IOT and you say to your customers that hey we kind of look at the device and look where 2302.76s - 2308.90s | it's connects to. You really need some kind of setup to do this and 2,000 a year versus an 2308.90s - 2315.60s | illegal setup that's kind of you need to have your best engineers work a week on. So that's 2315.60s - 2322.78s | really expensive as well. These devices especially in industrial IOT um they're everywhere and 2323.10s - 2330.08s | people don't really look at their traffic that much. So there's just a handful of companies 2330.08s - 2335.08s | that actually I know that do this but now anyone can do this. And like I said maybe some 2339.64s - 2345.34s | new attack vectors for high security devices that if you can push a SIM card in and it you get 2345.34s - 2350.34s | the data then you can also uh send some uh malicious things uh to it. Defensive point of 2350.86s - 2357.24s | view. So these private APNs uh like I connect it to my server but you can connect the IPsec 2361.98s - 2366.98s | tunnel to your existing firewall. So if you are running some kind of uh firewall then uh you 2369.52s - 2376.06s | can just connect this to it. Um kind of the first devices might kind of uh cost something and 2376.08s - 2381.58s | then you it costs more to add devices but the cost goes down uh gradually. So if you have 2381.58s - 2386.58s | thousands of devices it will be still uh quite uh inexpensive to do. And the mobile phone 2390.93s - 2395.93s | malware infections they might not communicate at all over Wi-Fi or VPN. So there was this uh 2398.13s - 2404.37s | hack some kind of some triangles or something and uh they said that when they noticed the 2404.37s - 2409.71s | hack uh they were uh scanning their or like they were looking at their Wi-Fi traffic at their 2409.71s - 2416.19s | office and they noticed that some of the phones were sending things to some uh C2 servers


chunk_id: 208_chunk_36
chunk_text:
Defensive point of 2350.86s - 2357.24s | view. So these private APNs uh like I connect it to my server but you can connect the IPsec 2361.98s - 2366.98s | tunnel to your existing firewall. So if you are running some kind of uh firewall then uh you 2369.52s - 2376.06s | can just connect this to it. Um kind of the first devices might kind of uh cost something and 2376.08s - 2381.58s | then you it costs more to add devices but the cost goes down uh gradually. So if you have 2381.58s - 2386.58s | thousands of devices it will be still uh quite uh inexpensive to do. And the mobile phone 2390.93s - 2395.93s | malware infections they might not communicate at all over Wi-Fi or VPN. So there was this uh 2398.13s - 2404.37s | hack some kind of some triangles or something and uh they said that when they noticed the 2404.37s - 2409.71s | hack uh they were uh scanning their or like they were looking at their Wi-Fi traffic at their 2409.71s - 2416.19s | office and they noticed that some of the phones were sending things to some uh C2 servers and 2416.19s - 2421.93s | they also analyzed the malware and the malware had these properties that it can detect if it's 2421.93s - 2426.93s | been uh run over Wi-Fi or VPN and not do it. So it might have been misconfigured to allow 2429.57s - 2434.27s | traffic over Wi-Fi because why would you, people are looking at the Wi-Fi why would you do 2434.27s - 2439.55s | your malicious stuff over that? So it might have just been a misconfigured malware that they 2439.55s - 2446.25s | happened to find through their Wi-Fi. So I might think that the advanced malware that sometimes 2446.25s - 2452.35s | are not that advanced uh might get better at this or they might already be doing this and that 2452.35s - 2457.37s | was just one uh slip up. Uh so yeah, if you are targeted by uh advanced malware you might want 2457.47s - 2462.47s | to do kind of this kind of thing. But you can find the project details, you can uh snap a uh photo 2470.36s - 2476.60s | of this to remember it and you can find me here at Defcon or the internet and


chunk_id: 208_chunk_37
chunk_text:
and 2416.19s - 2421.93s | they also analyzed the malware and the malware had these properties that it can detect if it's 2421.93s - 2426.93s | been uh run over Wi-Fi or VPN and not do it. So it might have been misconfigured to allow 2429.57s - 2434.27s | traffic over Wi-Fi because why would you, people are looking at the Wi-Fi why would you do 2434.27s - 2439.55s | your malicious stuff over that? So it might have just been a misconfigured malware that they 2439.55s - 2446.25s | happened to find through their Wi-Fi. So I might think that the advanced malware that sometimes 2446.25s - 2452.35s | are not that advanced uh might get better at this or they might already be doing this and that 2452.35s - 2457.37s | was just one uh slip up. Uh so yeah, if you are targeted by uh advanced malware you might want 2457.47s - 2462.47s | to do kind of this kind of thing. But you can find the project details, you can uh snap a uh photo 2470.36s - 2476.60s | of this to remember it and you can find me here at Defcon or the internet and um thank you for 2476.60s - 2478.60s | your uh coming here.


chunk_id: 209_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=0L6TlFYwy2U", "title": "DEF CON 32 - HookChain A new perspective for Bypassing EDR Solutions - Helvio Carvalho Junior", "description": "In the current digital security ecosystem, where threats evolve rapidly and with complexity, companies developing Endpoint Detection and Response (EDR) solutions are in constant search for innovations that not only keep up but also anticipate emerging attack vectors. In this context, this article introduces the HookChain, a look from another perspective at widely known techniques, which when combined, provide an additional layer of sophisticated evasion against traditional EDR systems.\n\nThrough a precise combination of IAT Hooking techniques, dynamic SSN resolution, and indirect system calls, HookChain redirects the execution flow of Windows subsystems in a way that remains invisible to the vigilant eyes of EDRs that only act on Ntdll.dll, without requiring changes to the source code of the applications and malwares involved.\n\nThis work not only challenges current conventions in cybersecurity but also sheds light on a promising path for future protection strategies, leveraging the understanding that continuous evolution is key to the effectiveness of digital security.\n\nBy developing and exploring the HookChain technique, this study significantly contributes to the body of knowledge in endpoint security, stimulating the development of more robust and adaptive solutions that can effectively address the ever-changing dynamics of digital threats. This work aspires to inspire deep reflection and advancement in the research and development of security technologies that are always several steps ahead of adversaries.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2364, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 6.50s | This text was transcribed using whisper model: large-v2 Welcome Vegas! Woohoo! Let's go guys! Ladies and gentlemen, LVO. Thank you guys to be here. 15.68s - 20.68s | It is amazing experience to be here for my first time. And let's talk about EDR, XDR bypassing. 20.68s - 25.68s | First of all, our agenda. Uh, a little bit who I am. Uh, a little bit what is hookchain and what 36.76s - 41.76s | is not hookchain is. And these research limitations. And after that, let's talk about the 42.76s - 47.76s | basics to understand how does hookchain works. And after, look through hookchain itself. 57.64s - 62.64s | Who I am? My name is Elvio Junior, aka Maverick. Uh, my undergraduation school, uh, I did 65.44s - 70.44s | uh, airplane pilot. So yes, I am a pilot. And I was the pilot for


chunk_id: 209_chunk_1
chunk_text:
and adaptive solutions that can effectively address the ever-changing dynamics of digital threats. This work aspires to inspire deep reflection and advancement in the research and development of security technologies that are always several steps ahead of adversaries.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2364, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 6.50s | This text was transcribed using whisper model: large-v2 Welcome Vegas! Woohoo! Let's go guys! Ladies and gentlemen, LVO. Thank you guys to be here. 15.68s - 20.68s | It is amazing experience to be here for my first time. And let's talk about EDR, XDR bypassing. 20.68s - 25.68s | First of all, our agenda. Uh, a little bit who I am. Uh, a little bit what is hookchain and what 36.76s - 41.76s | is not hookchain is. And these research limitations. And after that, let's talk about the 42.76s - 47.76s | basics to understand how does hookchain works. And after, look through hookchain itself. 57.64s - 62.64s | Who I am? My name is Elvio Junior, aka Maverick. Uh, my undergraduation school, uh, I did 65.44s - 70.44s | uh, airplane pilot. So yes, I am a pilot. And I was the pilot for the first time in my life. 71.76s - 76.76s | The first in America Latina to learn OSCE 3. Uh, and I studying, or maybe studying to OSCE. 82.80s - 87.80s | This research, uh, that I have no much time to study OSCE. And what I like? I like low 91.34s - 96.34s | level exploitation, buffer overflow, shell coding, malware and so on. And also I am CEO 97.34s - 102.34s | of SecForUs, a company, a Brazilian company that uh, provide training and researching, 107.84s - 112.84s | consulting and so on. What is the motivation of this talk and this research? Many people 117.12s - 122.12s | believes that I, I have solution X, that I top of the Gartner and I am a hundred percent 127.30s - 132.30s | protected. No, there is no silver bullet. And when I doing, uh, pentesting or red team 138.58s - 143.58s | exercise, I just need to bypass your environment. I don't need to bypass everything, just 148.28s - 153.28s | your environment. So, and fool undetectable. Sometimes it happens. And what is hookchain? 156.60s - 161.60s | Hookchain is a technique. It is not a tool. I'm


chunk_id: 209_chunk_2
chunk_text:
the first time in my life. 71.76s - 76.76s | The first in America Latina to learn OSCE 3. Uh, and I studying, or maybe studying to OSCE. 82.80s - 87.80s | This research, uh, that I have no much time to study OSCE. And what I like? I like low 91.34s - 96.34s | level exploitation, buffer overflow, shell coding, malware and so on. And also I am CEO 97.34s - 102.34s | of SecForUs, a company, a Brazilian company that uh, provide training and researching, 107.84s - 112.84s | consulting and so on. What is the motivation of this talk and this research? Many people 117.12s - 122.12s | believes that I, I have solution X, that I top of the Gartner and I am a hundred percent 127.30s - 132.30s | protected. No, there is no silver bullet. And when I doing, uh, pentesting or red team 138.58s - 143.58s | exercise, I just need to bypass your environment. I don't need to bypass everything, just 148.28s - 153.28s | your environment. So, and fool undetectable. Sometimes it happens. And what is hookchain? 156.60s - 161.60s | Hookchain is a technique. It is not a tool. I'm not pretending to launch a tool. Yeah, 164.20s - 169.20s | obviously I need to do some programming. I need to, to create a code to prove the concept, 172.04s - 177.04s | but it is a technique. Okay? And what is the focus of hookchain? Do hook, do bypassing of 177.40s - 182.40s | monitoring of EDRs and XDRs inside of NTDLL. In other words, a hundred percent user land. 195.94s - 200.94s | Nothing about kernel land. Okay? And limitation. As I said, it is uh, 64 bits programming 201.50s - 206.50s | and limited just to NTDLL. User land hooks. And I'm not pretending here to classify the EDR 220.58s - 225.58s | vendors, XDR vendors as his effectivity. I'm just launching a new technique. Okay? I need 225.84s - 230.84s | to do some tests, but I'm focused just in one point, not entire ecosystem. So, I'm not 240.08s - 245.08s | pretending to classify EDRs. It must be clear for, for all guys. During this study, I, I 246.00s - 251.00s | did a public call for vendors to work together with me to get early access to this code, to 260.14s - 265.14s |


chunk_id: 209_chunk_3
chunk_text:
not pretending to launch a tool. Yeah, 164.20s - 169.20s | obviously I need to do some programming. I need to, to create a code to prove the concept, 172.04s - 177.04s | but it is a technique. Okay? And what is the focus of hookchain? Do hook, do bypassing of 177.40s - 182.40s | monitoring of EDRs and XDRs inside of NTDLL. In other words, a hundred percent user land. 195.94s - 200.94s | Nothing about kernel land. Okay? And limitation. As I said, it is uh, 64 bits programming 201.50s - 206.50s | and limited just to NTDLL. User land hooks. And I'm not pretending here to classify the EDR 220.58s - 225.58s | vendors, XDR vendors as his effectivity. I'm just launching a new technique. Okay? I need 225.84s - 230.84s | to do some tests, but I'm focused just in one point, not entire ecosystem. So, I'm not 240.08s - 245.08s | pretending to classify EDRs. It must be clear for, for all guys. During this study, I, I 246.00s - 251.00s | did a public call for vendors to work together with me to get early access to this code, to 260.14s - 265.14s | this technique, and no one answered. When I published some bypass in LinkedIn, I received 265.68s - 270.68s | some calls, not too happy calls sometimes, but I received just three years, three weeks ago, 279.06s - 284.06s | some calls in order to test this. Okay? And let's go to the technical things. First of 287.26s - 292.26s | all, we have almost two layers in order to protect and split the time block. Okay? So, 295.44s - 300.44s | inside of our operational test. Ring zero, kernel land, and ring three, user land. To 304.94s - 309.94s | transition between user land to kernel land, in a few words, we have just one way to do 314.48s - 319.48s | this. Using a gate calling system call, or system dispatcher and so on, that I can 319.84s - 324.84s | transit from user mode to the kernel mode. In general, we have this picture where we have 332.92s - 337.92s | user process, system services, and so on. Doesn't matter what, uh, is the, his level is, it 340.68s - 345.70s | is a system level, a certain level, or uh, a simple non-privileged user process. Every time


chunk_id: 209_chunk_4
chunk_text:
this technique, and no one answered. When I published some bypass in LinkedIn, I received 265.68s - 270.68s | some calls, not too happy calls sometimes, but I received just three years, three weeks ago, 279.06s - 284.06s | some calls in order to test this. Okay? And let's go to the technical things. First of 287.26s - 292.26s | all, we have almost two layers in order to protect and split the time block. Okay? So, 295.44s - 300.44s | inside of our operational test. Ring zero, kernel land, and ring three, user land. To 304.94s - 309.94s | transition between user land to kernel land, in a few words, we have just one way to do 314.48s - 319.48s | this. Using a gate calling system call, or system dispatcher and so on, that I can 319.84s - 324.84s | transit from user mode to the kernel mode. In general, we have this picture where we have 332.92s - 337.92s | user process, system services, and so on. Doesn't matter what, uh, is the, his level is, it 340.68s - 345.70s | is a system level, a certain level, or uh, a simple non-privileged user process. Every time 349.84s - 354.84s | I need to do this transition. In general, this, this is a responsibility to NTDLL to do this 359.38s - 364.38s | for me. So, this is a common stack call where I have one common application for, that must 369.72s - 375.06s | be, that need to be, for example, need to execute first a virtual lock to locate a, a 375.08s - 380.08s | memory, and the common stack call, the application will call this from kernel 32 DLL, and 383.16s - 388.16s | the kernel 32 will call another, uh, API inside of NTDLL, and the NTDLL will prepare stack 394.20s - 399.20s | call parameters, register parameters, and we will execute uh, assembly instruction 399.98s - 404.98s | called sys call that will transit from user mode to the kernel mode. This is just another 413.86s - 418.86s | image to explain that. So, I have the user mode application and the important here, system 421.60s - 426.60s | service number. There is a table called system service descriptor table where I have an 427.54s - 432.54s | indexes from zero to, I have no idea how much, more than four hundred,


chunk_id: 209_chunk_5
chunk_text:
349.84s - 354.84s | I need to do this transition. In general, this, this is a responsibility to NTDLL to do this 359.38s - 364.38s | for me. So, this is a common stack call where I have one common application for, that must 369.72s - 375.06s | be, that need to be, for example, need to execute first a virtual lock to locate a, a 375.08s - 380.08s | memory, and the common stack call, the application will call this from kernel 32 DLL, and 383.16s - 388.16s | the kernel 32 will call another, uh, API inside of NTDLL, and the NTDLL will prepare stack 394.20s - 399.20s | call parameters, register parameters, and we will execute uh, assembly instruction 399.98s - 404.98s | called sys call that will transit from user mode to the kernel mode. This is just another 413.86s - 418.86s | image to explain that. So, I have the user mode application and the important here, system 421.60s - 426.60s | service number. There is a table called system service descriptor table where I have an 427.54s - 432.54s | indexes from zero to, I have no idea how much, more than four hundred, uh, numbers that match 441.82s - 446.82s | each ID from a pointer to a kernel function. So, when I need to transit from the user mode 447.82s - 452.82s | to kernel mode, I put the system service number inside of register RAL, sorry about the 460.80s - 465.80s | names, but uh, I put this number in this register and I execute the system call 469.14s - 474.14s | instruction. And system call will come to the kernel uh, address space and this ke- this 474.14s - 479.14s | function will uh, match inside of this table and get the pointer to the real kernel 483.58s - 488.58s | function. And the real kernel function will be executed and return to the user mode space 490.38s - 495.38s | with the return of the the executed function. Doesn't matter uh, what this means. This is 497.76s - 504.06s | another uh, uh, uh, image to illustrate that. System service call, system service 504.06s - 509.06s | descriptor, the table with the indexes and uh, the pointers to the function and the real 511.66s - 516.66s | code from, to the function. Okay? And when I execute some proxies


chunk_id: 209_chunk_6
chunk_text:
uh, numbers that match 441.82s - 446.82s | each ID from a pointer to a kernel function. So, when I need to transit from the user mode 447.82s - 452.82s | to kernel mode, I put the system service number inside of register RAL, sorry about the 460.80s - 465.80s | names, but uh, I put this number in this register and I execute the system call 469.14s - 474.14s | instruction. And system call will come to the kernel uh, address space and this ke- this 474.14s - 479.14s | function will uh, match inside of this table and get the pointer to the real kernel 483.58s - 488.58s | function. And the real kernel function will be executed and return to the user mode space 490.38s - 495.38s | with the return of the the executed function. Doesn't matter uh, what this means. This is 497.76s - 504.06s | another uh, uh, uh, image to illustrate that. System service call, system service 504.06s - 509.06s | descriptor, the table with the indexes and uh, the pointers to the function and the real 511.66s - 516.66s | code from, to the function. Okay? And when I execute some proxies uh, un-executed or uh, 521.70s - 526.70s | when I load uh, DLL inside of another proxies, when I initiate uh, uh, a proxies, several 527.42s - 532.42s | actions are, have been done behind the scenes. One of the most important that uh, uh, to the 537.70s - 542.70s | stock is related to import address table. Import address table in a few words is a table 545.10s - 550.10s | that uh, the name of the function that I want to execute, for example, uh, create proxies and 550.78s - 555.78s | the name of the function and the uh, ID representing, ID representing inside of this table 563.18s - 568.72s | that when I run this, when I run the the application, the operational system that the 568.72s - 573.72s | loading of the operational system will look through uh, all loaded DLLs and fill this table 573.78s - 578.78s | with the address, the real address of this function in the operational system. Virtual 582.26s - 588.36s | address of course, but the virtual address. So when I try to execute this proxies, my 588.36s - 593.36s | application will comes uh, to the import address


chunk_id: 209_chunk_7
chunk_text:
uh, un-executed or uh, 521.70s - 526.70s | when I load uh, DLL inside of another proxies, when I initiate uh, uh, a proxies, several 527.42s - 532.42s | actions are, have been done behind the scenes. One of the most important that uh, uh, to the 537.70s - 542.70s | stock is related to import address table. Import address table in a few words is a table 545.10s - 550.10s | that uh, the name of the function that I want to execute, for example, uh, create proxies and 550.78s - 555.78s | the name of the function and the uh, ID representing, ID representing inside of this table 563.18s - 568.72s | that when I run this, when I run the the application, the operational system that the 568.72s - 573.72s | loading of the operational system will look through uh, all loaded DLLs and fill this table 573.78s - 578.78s | with the address, the real address of this function in the operational system. Virtual 582.26s - 588.36s | address of course, but the virtual address. So when I try to execute this proxies, my 588.36s - 593.36s | application will comes uh, to the import address table and request, import address table, what 596.00s - 601.00s | is the real virtual address to this function? And put this for example in a history and 603.74s - 608.74s | after that call the address of this hazards, history in order to call the uh, real uh, 611.52s - 616.52s | function code. And another things that image loader do is uh, look through the, the loaded 620.62s - 625.62s | DLLs if this DLLs uh, it uh, was already loaded, the recursive loading and so on and fill 628.20s - 633.44s | this, this function pointer. There is another image to, to illustrate this, this same 633.46s - 638.46s | thing that I have the name of the DLLs and the functions that I imported in my application by 640.46s - 647.00s | the full and the, the, the name and the code of the application inside the, the uh, the 647.00s - 652.00s | targeted DLL. Let's start talking about the techniques. Uh, when I, when I saw this, this 652.04s - 657.04s | kind of hooking uh, we need to say, we must say that the techniques that we use to attack, 666.88s - 671.90s


chunk_id: 209_chunk_8
chunk_text:
table and request, import address table, what 596.00s - 601.00s | is the real virtual address to this function? And put this for example in a history and 603.74s - 608.74s | after that call the address of this hazards, history in order to call the uh, real uh, 611.52s - 616.52s | function code. And another things that image loader do is uh, look through the, the loaded 620.62s - 625.62s | DLLs if this DLLs uh, it uh, was already loaded, the recursive loading and so on and fill 628.20s - 633.44s | this, this function pointer. There is another image to, to illustrate this, this same 633.46s - 638.46s | thing that I have the name of the DLLs and the functions that I imported in my application by 640.46s - 647.00s | the full and the, the, the name and the code of the application inside the, the uh, the 647.00s - 652.00s | targeted DLL. Let's start talking about the techniques. Uh, when I, when I saw this, this 652.04s - 657.04s | kind of hooking uh, we need to say, we must say that the techniques that we use to attack, 666.88s - 671.90s | it's the same techniques that the EDR vendors are using to protect. The first time that uh, 674.94s - 679.94s | someone published uh, uh, something related with this techniques in, in Windows, in 682.04s - 687.04s | 1995. So uh, a few, few years ago. Uh, and what is hook? Like a interception of the stack 694.52s - 699.52s | call. When I try to execute some function, this function uh, I, I'm not executing the 702.10s - 707.10s | real function. I, I will be uh, intercepted and redirected to another function. Like a 707.88s - 712.88s | man in the middle. In this case it will be a function in the middle. But it's the same 715.68s - 720.68s | concept. Okay? The, the most common techniques to do that is using instruction jump or call 724.36s - 729.36s | or I can use import address table hooking. How can I do that? Let's see. Uh, talking 730.36s - 735.36s | about jumping. This is a strategy that I, I'm uh, that we can see here. It's the most 740.94s - 745.94s | common strategy uh, used by EDR and XDR vendors. That is, when I


chunk_id: 209_chunk_9
chunk_text:
| it's the same techniques that the EDR vendors are using to protect. The first time that uh, 674.94s - 679.94s | someone published uh, uh, something related with this techniques in, in Windows, in 682.04s - 687.04s | 1995. So uh, a few, few years ago. Uh, and what is hook? Like a interception of the stack 694.52s - 699.52s | call. When I try to execute some function, this function uh, I, I'm not executing the 702.10s - 707.10s | real function. I, I will be uh, intercepted and redirected to another function. Like a 707.88s - 712.88s | man in the middle. In this case it will be a function in the middle. But it's the same 715.68s - 720.68s | concept. Okay? The, the most common techniques to do that is using instruction jump or call 724.36s - 729.36s | or I can use import address table hooking. How can I do that? Let's see. Uh, talking 730.36s - 735.36s | about jumping. This is a strategy that I, I'm uh, that we can see here. It's the most 740.94s - 745.94s | common strategy uh, used by EDR and XDR vendors. That is, when I run a, an application, 750.38s - 755.38s | uh, NTDLL is the first DLL uh, that is, is attached to my process. And after that, the 759.76s - 764.76s | EDR DLL will be uh, attached and the DLL from EDR will patch or change in memory uh, the 771.54s - 776.54s | instructions of the NTDLL. So when I try to execute for example this function, this 778.20s - 783.22s | function is uh, uh, changed to jump to address space of EDR uh, code. In order that the EDR 783.58s - 788.58s | can uh, check our parameters and response and so on. This is uh, an example of original 797.70s - 803.20s | execution flow where when I get the address of the, the, the, the function, the target 803.20s - 808.20s | function, we will receive the real address. But if after the EDR changes or after our 808.92s - 813.92s | change that, because we will change this table, uh, after that, instead of receive the 818.10s - 823.10s | address of the real function, the original function, we will receive an address to a 825.64s - 832.64s | hooked function or to a uh,


chunk_id: 209_chunk_10
chunk_text:
run a, an application, 750.38s - 755.38s | uh, NTDLL is the first DLL uh, that is, is attached to my process. And after that, the 759.76s - 764.76s | EDR DLL will be uh, attached and the DLL from EDR will patch or change in memory uh, the 771.54s - 776.54s | instructions of the NTDLL. So when I try to execute for example this function, this 778.20s - 783.22s | function is uh, uh, changed to jump to address space of EDR uh, code. In order that the EDR 783.58s - 788.58s | can uh, check our parameters and response and so on. This is uh, an example of original 797.70s - 803.20s | execution flow where when I get the address of the, the, the, the function, the target 803.20s - 808.20s | function, we will receive the real address. But if after the EDR changes or after our 808.92s - 813.92s | change that, because we will change this table, uh, after that, instead of receive the 818.10s - 823.10s | address of the real function, the original function, we will receive an address to a 825.64s - 832.64s | hooked function or to a uh, function in the middle in this case. Okay? So we will receive a 832.66s - 837.66s | malicious function or uh, when I EDR doing that, the, the, the address of the EDR function. 840.10s - 845.10s | So when I call this address, we will call the received function. In this case, uh, arbitrary 848.28s - 853.28s | code from EDR or from our perspective and it is a decision if we will or not execute the 853.80s - 858.80s | real function. In uh, talking about EDR infrastructure, the EDR will uh, analyze the 865.88s - 870.88s | parameters and decide yes, uh, LV is a good guy, I can allow this. Oh no, LV is a bad 874.56s - 879.56s | guy, let's drop this. And uh, uh, pop, pop up alert and uh, send this to, to SOC and 879.58s - 884.58s | so on. Uh, this is a, that I am talking, this is a, uh, when I EDR load EDR, put an, another 893.76s - 898.76s | DLL and it will be redirected and decide yes, no, execute or no, and do if, yeah, LV is a 903.04s - 908.04s | good guy, let's


chunk_id: 209_chunk_11
chunk_text:
function in the middle in this case. Okay? So we will receive a 832.66s - 837.66s | malicious function or uh, when I EDR doing that, the, the, the address of the EDR function. 840.10s - 845.10s | So when I call this address, we will call the received function. In this case, uh, arbitrary 848.28s - 853.28s | code from EDR or from our perspective and it is a decision if we will or not execute the 853.80s - 858.80s | real function. In uh, talking about EDR infrastructure, the EDR will uh, analyze the 865.88s - 870.88s | parameters and decide yes, uh, LV is a good guy, I can allow this. Oh no, LV is a bad 874.56s - 879.56s | guy, let's drop this. And uh, uh, pop, pop up alert and uh, send this to, to SOC and 879.58s - 884.58s | so on. Uh, this is a, that I am talking, this is a, uh, when I EDR load EDR, put an, another 893.76s - 898.76s | DLL and it will be redirected and decide yes, no, execute or no, and do if, yeah, LV is a 903.04s - 908.04s | good guy, let's uh, permit this execution, so do system call, include, uh, uh, uh, uh, 909.64s - 914.64s | kernel land, it's everything as usual and after that come back to the user land process. 918.12s - 923.12s | Ok, I can see here an unhooked API, ok, so I can see this typically uh, instructions where 928.46s - 933.46s | uh, there is a, a, a moving from RLCX to R10 and after that there is a, an ID here in 934.00s - 939.00s | hexadecimal, uh, where I put this ID in uh, EAX or RAX, doesn't matter, and after that there is a 948.62s - 953.62s | system call. This is a typical uh, uh, code from NTDLL's uh, uh, functions that will 956.86s - 961.86s | translate from user land to kernel land. And here we can see how can I, how can I, uh, 964.06s - 969.06s | HTTP API where he is unhooked and he is unhooked API. As you can see, there is no this 972.40s - 977.40s | typical code, there is a jump code where I'm doing uh, uh, jumping or interception to the 981.18s - 986.18s | API or to the EDR


chunk_id: 209_chunk_12
chunk_text:
uh, permit this execution, so do system call, include, uh, uh, uh, uh, 909.64s - 914.64s | kernel land, it's everything as usual and after that come back to the user land process. 918.12s - 923.12s | Ok, I can see here an unhooked API, ok, so I can see this typically uh, instructions where 928.46s - 933.46s | uh, there is a, a, a moving from RLCX to R10 and after that there is a, an ID here in 934.00s - 939.00s | hexadecimal, uh, where I put this ID in uh, EAX or RAX, doesn't matter, and after that there is a 948.62s - 953.62s | system call. This is a typical uh, uh, code from NTDLL's uh, uh, functions that will 956.86s - 961.86s | translate from user land to kernel land. And here we can see how can I, how can I, uh, 964.06s - 969.06s | HTTP API where he is unhooked and he is unhooked API. As you can see, there is no this 972.40s - 977.40s | typical code, there is a jump code where I'm doing uh, uh, jumping or interception to the 981.18s - 986.18s | API or to the EDR uh, code. Ok, such that the most common bypasses is remapping NTDLL and 993.56s - 998.56s | but to do that we need to load the NTDLL from the disk or from the another uh, memory area. 1003.10s - 1008.10s | It's, seems to be malicious in most of case. Uh, another technique, it's direct syscall 1011.04s - 1016.04s | when instead of goes through NTDLL, I get the system service number and do uh, and execute 1016.24s - 1021.24s | the system call inside of my, my process. This sounds malicious again because the system 1029.18s - 1034.18s | call was not coming back from NTDLL memory address space, it's coming from my application 1037.92s - 1042.92s | address space. Ok, and EDR catch this. I direct syscall, it's a syscall, it's a syscall 1046.04s - 1051.04s | similar to direct syscall but instead of uh, do uh, system call instruction inside of my 1053.74s - 1058.74s | application, I will jump it to a address inside of NTDLL that exists just system call 1061.68s - 1066.68s | instruction. So, who will execute NTDLL? So, sounds less malicious. But in this case, the 1066.68s - 1071.68s | stack trace


chunk_id: 209_chunk_13
chunk_text:
uh, code. Ok, such that the most common bypasses is remapping NTDLL and 993.56s - 998.56s | but to do that we need to load the NTDLL from the disk or from the another uh, memory area. 1003.10s - 1008.10s | It's, seems to be malicious in most of case. Uh, another technique, it's direct syscall 1011.04s - 1016.04s | when instead of goes through NTDLL, I get the system service number and do uh, and execute 1016.24s - 1021.24s | the system call inside of my, my process. This sounds malicious again because the system 1029.18s - 1034.18s | call was not coming back from NTDLL memory address space, it's coming from my application 1037.92s - 1042.92s | address space. Ok, and EDR catch this. I direct syscall, it's a syscall, it's a syscall 1046.04s - 1051.04s | similar to direct syscall but instead of uh, do uh, system call instruction inside of my 1053.74s - 1058.74s | application, I will jump it to a address inside of NTDLL that exists just system call 1061.68s - 1066.68s | instruction. So, who will execute NTDLL? So, sounds less malicious. But in this case, the 1066.68s - 1071.68s | stack trace will be broken because I'm executing directly from my code inside of NTDLL. In 1080.02s - 1085.02s | general, the application doesn't do that. The application in general calls system 32 DLL, 1088.16s - 1093.16s | kernel base DLLs, GDI DLL and so on. And this DLL will call NTDLL and, and etcetera. So, 1097.40s - 1102.40s | sounds malicious. Then, there are amazing guys uh, without this research, this talk today was 1107.28s - 1114.38s | not possible. So, this is amazing guys uh, created he- uh, Heaven Gate technique, Hell's 1114.38s - 1119.38s | Gate technique and the Hallows Gate technique. So, uh, for this research I used the part of 1120.36s - 1125.36s | Hallows Gate technique in order to uh, resolve dynamically uh, the system service numbers. 1132.00s - 1137.00s | Okay? So, let's understand a little bit better about Hallows Gate, this part of Hallows Gate. 1138.68s - 1143.68s | In general, Hallows Gate locate the current address of the uh, target function, the function 1144.68s - 1149.68s | that I want to execute. For example, uh, create a virtual memory or um, create processor and 1155.40s - 1160.40s | look that uh, that code


chunk_id: 209_chunk_14
chunk_text:
will be broken because I'm executing directly from my code inside of NTDLL. In 1080.02s - 1085.02s | general, the application doesn't do that. The application in general calls system 32 DLL, 1088.16s - 1093.16s | kernel base DLLs, GDI DLL and so on. And this DLL will call NTDLL and, and etcetera. So, 1097.40s - 1102.40s | sounds malicious. Then, there are amazing guys uh, without this research, this talk today was 1107.28s - 1114.38s | not possible. So, this is amazing guys uh, created he- uh, Heaven Gate technique, Hell's 1114.38s - 1119.38s | Gate technique and the Hallows Gate technique. So, uh, for this research I used the part of 1120.36s - 1125.36s | Hallows Gate technique in order to uh, resolve dynamically uh, the system service numbers. 1132.00s - 1137.00s | Okay? So, let's understand a little bit better about Hallows Gate, this part of Hallows Gate. 1138.68s - 1143.68s | In general, Hallows Gate locate the current address of the uh, target function, the function 1144.68s - 1149.68s | that I want to execute. For example, uh, create a virtual memory or um, create processor and 1155.40s - 1160.40s | look that uh, that code that we, we saw, the, the typically code and check if the typically 1164.04s - 1169.04s | code uh, match with these uh, uh, these instructions. If yes, okay, this function was not 1169.04s - 1174.04s | hooked. If no, the function is hooked. Okay? So, we can uh, see that and how can I uh, get 1186.56s - 1191.56s | the system service number if, if the function is hooked. The real code uh, does not exist 1192.02s - 1197.02s | more there. How, how can I see this? Let's, let, let's see uh, uh, another screen here. We can 1202.16s - 1207.16s | see that the functions are linear. So, we can see here, for example, the system service 1211.08s - 1216.08s | number six, system service number seven, this function is hooked. So, in general I have no 1217.08s - 1222.08s | idea what's the, the, the system service ID of this function and the next function will be 1225.28s - 1230.28s | nine and we, the next function will be ten. In other words, we can see the neighborhood uh, 1233.22s - 1238.22s | functions before and after our uh, uh, uh, desired function in order


chunk_id: 209_chunk_15
chunk_text:
that we, we saw, the, the typically code and check if the typically 1164.04s - 1169.04s | code uh, match with these uh, uh, these instructions. If yes, okay, this function was not 1169.04s - 1174.04s | hooked. If no, the function is hooked. Okay? So, we can uh, see that and how can I uh, get 1186.56s - 1191.56s | the system service number if, if the function is hooked. The real code uh, does not exist 1192.02s - 1197.02s | more there. How, how can I see this? Let's, let, let's see uh, uh, another screen here. We can 1202.16s - 1207.16s | see that the functions are linear. So, we can see here, for example, the system service 1211.08s - 1216.08s | number six, system service number seven, this function is hooked. So, in general I have no 1217.08s - 1222.08s | idea what's the, the, the system service ID of this function and the next function will be 1225.28s - 1230.28s | nine and we, the next function will be ten. In other words, we can see the neighborhood uh, 1233.22s - 1238.22s | functions before and after our uh, uh, uh, desired function in order to calculate. If this 1238.38s - 1243.38s | function is six, that function is seven. My function will be eight. So, we can dynamically 1249.82s - 1254.82s | check this. This is hollows gate technique, okay? And uh, before this, this research, this 1258.76s - 1263.76s | study, uh, in a sunny day, uh, playing with my two uh, boys, my two boys, uh, playing with 1268.28s - 1273.28s | two kids, I have an idea. Whoa! The major part of EDRs are hooking in an NTDLL. If I step 1279.82s - 1284.82s | above and try to catch or try to do a, a, a function in the middle, uh, changing the flow 1288.16s - 1293.16s | before NTDLL, okay? Because, because some uh, uh, several EDRs are checking if we are 1294.02s - 1299.02s | changing NTDLL. So, because they are changing there, the EDR are checking if we also change 1305.26s - 1310.26s | there and flag us as malicious. So, if EDR are checking there, and what if I did or I do 1315.70s - 1320.70s | this in a step above? So, to check the uh, viability of this technique, I, I create a 1323.34s


chunk_id: 209_chunk_16
chunk_text:
to calculate. If this 1238.38s - 1243.38s | function is six, that function is seven. My function will be eight. So, we can dynamically 1249.82s - 1254.82s | check this. This is hollows gate technique, okay? And uh, before this, this research, this 1258.76s - 1263.76s | study, uh, in a sunny day, uh, playing with my two uh, boys, my two boys, uh, playing with 1268.28s - 1273.28s | two kids, I have an idea. Whoa! The major part of EDRs are hooking in an NTDLL. If I step 1279.82s - 1284.82s | above and try to catch or try to do a, a, a function in the middle, uh, changing the flow 1288.16s - 1293.16s | before NTDLL, okay? Because, because some uh, uh, several EDRs are checking if we are 1294.02s - 1299.02s | changing NTDLL. So, because they are changing there, the EDR are checking if we also change 1305.26s - 1310.26s | there and flag us as malicious. So, if EDR are checking there, and what if I did or I do 1315.70s - 1320.70s | this in a step above? So, to check the uh, viability of this technique, I, I create a 1323.34s - 1328.34s | code in order to check the EDRs hookings. So, nine percent of EDRs are hooking just in NTDLL. 1336.02s - 1341.02s | So, the technique can be viable, okay? And I created the new technique called hook chain. 1341.02s - 1346.04s | What is hook chain? Hook chain, the first step, I will uh, resolve system service number. 1355.70s - 1360.72s | After that, create a table where I store their system service number in uh, on an address of 1361.02s - 1366.02s | my custom stub function. In other words, the function that will be executed instead of 1373.90s - 1378.90s | original function. EDR do this, whoa, I can do this also. And implant or change the import 1384.48s - 1389.48s | address table from our proxies to our custom stub function. So, this is the hook chain 1390.72s - 1395.72s | and after that, continue as usual. With this, I have in more details the hook chain implant 1402.06s - 1407.06s | flow. First one, uh, I resolve dynamically, map some critical functions because in this, 1412.34s - 1417.34s | in this phase, uh, I have no, uh, I had no bypass at EDR


chunk_id: 209_chunk_17
chunk_text:
- 1328.34s | code in order to check the EDRs hookings. So, nine percent of EDRs are hooking just in NTDLL. 1336.02s - 1341.02s | So, the technique can be viable, okay? And I created the new technique called hook chain. 1341.02s - 1346.04s | What is hook chain? Hook chain, the first step, I will uh, resolve system service number. 1355.70s - 1360.72s | After that, create a table where I store their system service number in uh, on an address of 1361.02s - 1366.02s | my custom stub function. In other words, the function that will be executed instead of 1373.90s - 1378.90s | original function. EDR do this, whoa, I can do this also. And implant or change the import 1384.48s - 1389.48s | address table from our proxies to our custom stub function. So, this is the hook chain 1390.72s - 1395.72s | and after that, continue as usual. With this, I have in more details the hook chain implant 1402.06s - 1407.06s | flow. First one, uh, I resolve dynamically, map some critical functions because in this, 1412.34s - 1417.34s | in this phase, uh, I have no, uh, I had no bypass at EDR yet. So, I have no bypass at EDR 1420.72s - 1425.72s | yet. So, I need to use some functions not uh, monitored by EDR in order to change some 1428.12s - 1433.12s | memory address and change some uh, memory areas and so on. Read and et cetera. Uh, so I 1436.66s - 1441.66s | map statically these main functions that I call it here, critical functions. And after that 1444.10s - 1449.10s | I create a table. We will see the structure of this table uh, later on. Uh, uh, we create a 1450.78s - 1457.78s | table that holds system service number that I already mapped. The function address, the real 1457.78s - 1462.78s | function address inside of NTDLL and uh, the, the closest uh, address that holds a system 1468.86s - 1473.86s | call instruction inside of NTDLL. And after that, I load it, I preloaded some functions. 1474.82s - 1479.82s | For example, uh, if we will run uh, MetaExploit payload or Havoc payload uh, payload and uh, I 1485.56s - 1490.56s | have no idea. Uh, there are another uh, DLLs that must be called before the execution of 1492.94s - 1497.94s |


chunk_id: 209_chunk_18
chunk_text:
yet. So, I have no bypass at EDR 1420.72s - 1425.72s | yet. So, I need to use some functions not uh, monitored by EDR in order to change some 1428.12s - 1433.12s | memory address and change some uh, memory areas and so on. Read and et cetera. Uh, so I 1436.66s - 1441.66s | map statically these main functions that I call it here, critical functions. And after that 1444.10s - 1449.10s | I create a table. We will see the structure of this table uh, later on. Uh, uh, we create a 1450.78s - 1457.78s | table that holds system service number that I already mapped. The function address, the real 1457.78s - 1462.78s | function address inside of NTDLL and uh, the, the closest uh, address that holds a system 1468.86s - 1473.86s | call instruction inside of NTDLL. And after that, I load it, I preloaded some functions. 1474.82s - 1479.82s | For example, uh, if we will run uh, MetaExploit payload or Havoc payload uh, payload and uh, I 1485.56s - 1490.56s | have no idea. Uh, there are another uh, DLLs that must be called before the execution of 1492.94s - 1497.94s | this payload. Because a simple uh, a simple executable for example has no access to the uh, 1498.26s - 1503.26s | URL uh, APIs or uh, crypto APIs. So we must preload this DLL in order to change the import 1510.88s - 1515.88s | address table of this DLL. So here we preloaded these DLLs and after that do the magics. 1518.44s - 1523.44s | Change the import address table of all needed DLLs. In this time I, I, I need to say that 1524.32s - 1529.32s | there's not a good idea to change the import address table of all loaded DLLs. I tried that 1535.36s - 1540.36s | and I lose my hair trying that and that not a good idea. Believe me, believe me. So I, I, I 1544.66s - 1549.66s | created like a, a blacklist DLLs where I put inside of the application and uh, do this 1553.58s - 1558.58s | preloading and after that changing that. This is the typical flow after hookchain planting, 1561.88s - 1566.88s | the simplified version. So my application must call virtual unlock for example to create a 1570.06s - 1576.20s | malicious error in order to put there


chunk_id: 209_chunk_19
chunk_text:
this payload. Because a simple uh, a simple executable for example has no access to the uh, 1498.26s - 1503.26s | URL uh, APIs or uh, crypto APIs. So we must preload this DLL in order to change the import 1510.88s - 1515.88s | address table of this DLL. So here we preloaded these DLLs and after that do the magics. 1518.44s - 1523.44s | Change the import address table of all needed DLLs. In this time I, I, I need to say that 1524.32s - 1529.32s | there's not a good idea to change the import address table of all loaded DLLs. I tried that 1535.36s - 1540.36s | and I lose my hair trying that and that not a good idea. Believe me, believe me. So I, I, I 1544.66s - 1549.66s | created like a, a blacklist DLLs where I put inside of the application and uh, do this 1553.58s - 1558.58s | preloading and after that changing that. This is the typical flow after hookchain planting, 1561.88s - 1566.88s | the simplified version. So my application must call virtual unlock for example to create a 1570.06s - 1576.20s | malicious error in order to put there a MetaExploit shellcode for example. And I need to 1576.20s - 1581.20s | create this, I will call kernel to 32 DLL. Instead of call direct NT DLL, I will call 1583.44s - 1588.44s | DLL this function. As I hook it, as I did the uh, function in the middle, I will, this, 1591.68s - 1596.68s | this flow will be redirected to my application stub code. This application's stub code 1599.36s - 1604.36s | will, will check several things and create a stack frame, a stack call, create uh, uh, put 1606.40s - 1612.00s | the, the, the, the uh, the information inside the registers and after that do a 1612.10s - 1617.10s | indirect syscall in order to execute. And kernel mode as usual. Here there is uh, I can 1622.54s - 1627.54s | present you the, the first struct that I, that I uh, I will use. I will use here uh, a 1630.82s - 1635.82s | list, okay, with this system call information and each entry of this list uh, has a system 1636.38s - 1641.38s | service number, real address from the real function, okay, uh, the, the um, address of the 1652.36s -


chunk_id: 209_chunk_20
chunk_text:
a MetaExploit shellcode for example. And I need to 1576.20s - 1581.20s | create this, I will call kernel to 32 DLL. Instead of call direct NT DLL, I will call 1583.44s - 1588.44s | DLL this function. As I hook it, as I did the uh, function in the middle, I will, this, 1591.68s - 1596.68s | this flow will be redirected to my application stub code. This application's stub code 1599.36s - 1604.36s | will, will check several things and create a stack frame, a stack call, create uh, uh, put 1606.40s - 1612.00s | the, the, the, the uh, the information inside the registers and after that do a 1612.10s - 1617.10s | indirect syscall in order to execute. And kernel mode as usual. Here there is uh, I can 1622.54s - 1627.54s | present you the, the first struct that I, that I uh, I will use. I will use here uh, a 1630.82s - 1635.82s | list, okay, with this system call information and each entry of this list uh, has a system 1636.38s - 1641.38s | service number, real address from the real function, okay, uh, the, the um, address of the 1652.36s - 1657.36s | function or the address that holds the system call instruction and the address of my stub 1658.36s - 1663.36s | function that will be redirected to. And uh, a hash use it to bypass uh, static analysis 1669.16s - 1674.16s | instead of the name of the functions and the, and so on, okay. And this is the entire flow 1677.84s - 1682.84s | where the same, my application want to execute some function, will call kernel 32 DLL and 1682.84s - 1687.84s | that call kernel base DLL and after that I will check in a import address table. When I 1695.34s - 1700.34s | check in import address table instead of receive the original address I will receive my stub 1701.82s - 1706.82s | function. So the application will be, will redirect to my stub function. Inside of this 1707.10s - 1712.10s | function uh, I can check the system call list, the list that I saw and the list there are 1716.78s - 1721.78s | several items in order to check, get the parameters that were the real function, syscall uh, uh, 1723.36s - 1728.36s | address and so on. Create the stack call frame


chunk_id: 209_chunk_21
chunk_text:
1657.36s | function or the address that holds the system call instruction and the address of my stub 1658.36s - 1663.36s | function that will be redirected to. And uh, a hash use it to bypass uh, static analysis 1669.16s - 1674.16s | instead of the name of the functions and the, and so on, okay. And this is the entire flow 1677.84s - 1682.84s | where the same, my application want to execute some function, will call kernel 32 DLL and 1682.84s - 1687.84s | that call kernel base DLL and after that I will check in a import address table. When I 1695.34s - 1700.34s | check in import address table instead of receive the original address I will receive my stub 1701.82s - 1706.82s | function. So the application will be, will redirect to my stub function. Inside of this 1707.10s - 1712.10s | function uh, I can check the system call list, the list that I saw and the list there are 1716.78s - 1721.78s | several items in order to check, get the parameters that were the real function, syscall uh, uh, 1723.36s - 1728.36s | address and so on. Create the stack call frame and put everything that we, we need in the 1729.04s - 1734.04s | registers and after that do indirect syscall. Okay? What are the advantages of that? How this 1741.72s - 1746.72s | works? What, why? Uh, reduction of probability to identification for several reasons. The 1750.36s - 1755.36s | first one, total time of execution. As I have several times similar to the, to the, to the 1758.44s - 1763.44s | regular execution, the, the DDR cannot flag us because the, the total time of execution, the 1765.34s - 1771.64s | telemetry of total time of execution will be okay. Will be uh, seems, seems to be uh, 1771.64s - 1776.66s | valid. And stack, stack framing. Talking about stack frame, I'm flowing, I'm uh, uh, uh, 1780.92s - 1785.92s | executing as usual. Coming for a kernel 32 for example, kernel base and so on. So, I'm 1789.16s - 1794.16s | not stepping steps. Yeah, I'm not skipping steps. Okay? And the most important, I did not or I 1802.18s - 1807.18s | uh, uh, uh, I, I didn't need to change the code of the original application. For example, we 1807.92s - 1812.92s | will see in


chunk_id: 209_chunk_22
chunk_text:
and put everything that we, we need in the 1729.04s - 1734.04s | registers and after that do indirect syscall. Okay? What are the advantages of that? How this 1741.72s - 1746.72s | works? What, why? Uh, reduction of probability to identification for several reasons. The 1750.36s - 1755.36s | first one, total time of execution. As I have several times similar to the, to the, to the 1758.44s - 1763.44s | regular execution, the, the DDR cannot flag us because the, the total time of execution, the 1765.34s - 1771.64s | telemetry of total time of execution will be okay. Will be uh, seems, seems to be uh, 1771.64s - 1776.66s | valid. And stack, stack framing. Talking about stack frame, I'm flowing, I'm uh, uh, uh, 1780.92s - 1785.92s | executing as usual. Coming for a kernel 32 for example, kernel base and so on. So, I'm 1789.16s - 1794.16s | not stepping steps. Yeah, I'm not skipping steps. Okay? And the most important, I did not or I 1802.18s - 1807.18s | uh, uh, uh, I, I didn't need to change the code of the original application. For example, we 1807.92s - 1812.92s | will see in demo, when I want to execute mimikatz for example, I uh, uh, uh, I don't need to 1821.86s - 1826.86s | touch the code. I just execute the hookchain in order to implant and execute mimikatz. That's 1827.00s - 1832.00s | it. Because the hookchain implant and uh, uh, uh, uh, everything that we need. The 1838.44s - 1843.44s | function in the middle. Let's see the first demo where we will execute and uh, command and 1847.78s - 1852.78s | control using Havok. Okay, this is uh, flag as malicious as usual. And let's see this 1857.76s - 1864.14s | first one. Here we can see uh, Bitdefender updated with uh, advanced threat protection 1871.32s - 1876.32s | full enable and in the left side we can see our uh, console where uh, we will have, let me 1881.92s - 1886.92s | see, uh, let's stop here. Just uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, 1888.76s - 1893.76s | uh, let me put here together in order to, okay. Okay, no problem. Uh, first time I will implant a 1900.54s - 1905.54s | hookchain, after that download remotely from HTTP


chunk_id: 209_chunk_23
chunk_text:
demo, when I want to execute mimikatz for example, I uh, uh, uh, I don't need to 1821.86s - 1826.86s | touch the code. I just execute the hookchain in order to implant and execute mimikatz. That's 1827.00s - 1832.00s | it. Because the hookchain implant and uh, uh, uh, uh, everything that we need. The 1838.44s - 1843.44s | function in the middle. Let's see the first demo where we will execute and uh, command and 1847.78s - 1852.78s | control using Havok. Okay, this is uh, flag as malicious as usual. And let's see this 1857.76s - 1864.14s | first one. Here we can see uh, Bitdefender updated with uh, advanced threat protection 1871.32s - 1876.32s | full enable and in the left side we can see our uh, console where uh, we will have, let me 1881.92s - 1886.92s | see, uh, let's stop here. Just uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, 1888.76s - 1893.76s | uh, let me put here together in order to, okay. Okay, no problem. Uh, first time I will implant a 1900.54s - 1905.54s | hookchain, after that download remotely from HTTP the malicious payload and after that 1906.26s - 1911.26s | execute this malicious payload. So we are using Havok to do that. And here we go. Executed 1922.90s - 1927.90s | our first, first command control. We can interact with that without any identification. Thank 1928.18s - 1937.46s | you guys. You are amazing. It's just a starting one. Let's go. Let's go back to the 1945.36s - 1952.89s | presentation. Whoa. Here it is. Looking in details we have. The first step is mapping everything 1953.69s - 1958.69s | that we need. So in this operational system we have four, 472 NTDLL functions where we can 1970.77s - 1975.77s | map and these functions are hooked or I need this as a critical function. And after that I 1975.99s - 1980.99s | create this table, okay. This is the, the, the showing of this table and after that I do the 1987.77s - 1992.77s | import address table hooking. So I can see here the output of this, this hookings in kernel 1995.47s - 2002.20s | to 32, kernel base user 32 and so on. Let's talk about the real environment. The first of 2002.20s - 2007.22s | all,


chunk_id: 209_chunk_24
chunk_text:
the malicious payload and after that 1906.26s - 1911.26s | execute this malicious payload. So we are using Havok to do that. And here we go. Executed 1922.90s - 1927.90s | our first, first command control. We can interact with that without any identification. Thank 1928.18s - 1937.46s | you guys. You are amazing. It's just a starting one. Let's go. Let's go back to the 1945.36s - 1952.89s | presentation. Whoa. Here it is. Looking in details we have. The first step is mapping everything 1953.69s - 1958.69s | that we need. So in this operational system we have four, 472 NTDLL functions where we can 1970.77s - 1975.77s | map and these functions are hooked or I need this as a critical function. And after that I 1975.99s - 1980.99s | create this table, okay. This is the, the, the showing of this table and after that I do the 1987.77s - 1992.77s | import address table hooking. So I can see here the output of this, this hookings in kernel 1995.47s - 2002.20s | to 32, kernel base user 32 and so on. Let's talk about the real environment. The first of 2002.20s - 2007.22s | all, thank you for all friends, all Brazilian community that there are most, most guys 2014.46s - 2019.46s | here. Woo hoo! Uh that share with me uh your environment license and help me and support me in 2019.46s - 2024.48s | order to make this research works. Uh without you guys nothing will be possible. Uh thank 2034.88s - 2039.88s | you, thank, thank you so much. And because obviously some EDR vendors are not too happy 2040.72s - 2045.72s | and not sharing their licenses or their environment in order that I test. So uh there are a 2052.30s - 2057.30s | lot of friends uh sharing his environment with me in order to, to make this test, okay. So 2059.80s - 2064.80s | we did this in a closed environment as the focus, the focus of this research is talking about 2070.74s - 2075.74s | uh EDR protections uh and we will touch here else, else us uh I disabled the run as PPL and 2081.62s - 2087.82s | coordination guard inside of the windows because the tar- the, the target the full focus, it 2087.82s - 2092.82s | is not the windows, it is not the EDR


chunk_id: 209_chunk_25
chunk_text:
thank you for all friends, all Brazilian community that there are most, most guys 2014.46s - 2019.46s | here. Woo hoo! Uh that share with me uh your environment license and help me and support me in 2019.46s - 2024.48s | order to make this research works. Uh without you guys nothing will be possible. Uh thank 2034.88s - 2039.88s | you, thank, thank you so much. And because obviously some EDR vendors are not too happy 2040.72s - 2045.72s | and not sharing their licenses or their environment in order that I test. So uh there are a 2052.30s - 2057.30s | lot of friends uh sharing his environment with me in order to, to make this test, okay. So 2059.80s - 2064.80s | we did this in a closed environment as the focus, the focus of this research is talking about 2070.74s - 2075.74s | uh EDR protections uh and we will touch here else, else us uh I disabled the run as PPL and 2081.62s - 2087.82s | coordination guard inside of the windows because the tar- the, the target the full focus, it 2087.82s - 2092.82s | is not the windows, it is not the EDR and the XDR products. So, let's execute the second 2093.82s - 2098.82s | DEM for you guys. The same as again, we have the antivirals, EDR working with advanced 2111.56s - 2116.56s | threat protection and we will execute uh as usual, Mimikatz. I download it from GitHub 2124.64s - 2129.64s | put on my server as you can see and execute this guy in a protected environment. And let's 2135.12s - 2144.73s | see this working. Woo! It's not all. Execute and show a coffee, it, it's uh easiest part. 2150.71s - 2155.71s | Let's dump the creds. Without creds, we have nothing. So, let's dump the creds. Let's 2159.01s - 2164.01s | yeah, we can touch the else us without any identification with regular Mimikatz guys. 2171.09s - 2180.38s | Woo! Coming to the end, uh we are able to test with 66 uh percent of the products uh 2187.52s - 2192.52s | present in Gartner and in additional four other products. So, we are able to test with 2195.10s - 2200.10s | and this is the result table. Okay? We tested remote process injection, meterpreter and 2206.04s - 2211.04s | have walk as non-privileged user and meterpreter


chunk_id: 209_chunk_26
chunk_text:
and the XDR products. So, let's execute the second 2093.82s - 2098.82s | DEM for you guys. The same as again, we have the antivirals, EDR working with advanced 2111.56s - 2116.56s | threat protection and we will execute uh as usual, Mimikatz. I download it from GitHub 2124.64s - 2129.64s | put on my server as you can see and execute this guy in a protected environment. And let's 2135.12s - 2144.73s | see this working. Woo! It's not all. Execute and show a coffee, it, it's uh easiest part. 2150.71s - 2155.71s | Let's dump the creds. Without creds, we have nothing. So, let's dump the creds. Let's 2159.01s - 2164.01s | yeah, we can touch the else us without any identification with regular Mimikatz guys. 2171.09s - 2180.38s | Woo! Coming to the end, uh we are able to test with 66 uh percent of the products uh 2187.52s - 2192.52s | present in Gartner and in additional four other products. So, we are able to test with 2195.10s - 2200.10s | and this is the result table. Okay? We tested remote process injection, meterpreter and 2206.04s - 2211.04s | have walk as non-privileged user and meterpreter loading QE model, Mimikatz, procdump 2218.58s - 2223.58s | and a custom a hundred percent developed by me, a hundred percent developed by me. 2225.02s - 2230.02s | Assembly else us dump. Okay? I create this in order to do this test. And this is the result 2236.50s - 2241.50s | table. Okay? This is the products that I, I was able to test. And as you can see uh we, we 2243.78s - 2248.78s | have uh a lot of effectivity in order to, to doing this little things. Uh as I told you guys, 2255.88s - 2260.88s | uh three weeks ago two vendors uh reached me in order to, to test uh again. The sentinel one 2266.06s - 2271.06s | was the first and the second one was the trench. This results that I'm showing you uh the 2274.30s - 2279.30s | sentinel one was able to uh stop hookchain. They did some patches in his product and uh 2285.10s - 2290.10s | I was able to, to test this and stop it at all. Okay? Deadline, end line. Uh and the trench uh 2295.12s - 2300.12s | still working on this, this uh uh identification. And


chunk_id: 209_chunk_27
chunk_text:
loading QE model, Mimikatz, procdump 2218.58s - 2223.58s | and a custom a hundred percent developed by me, a hundred percent developed by me. 2225.02s - 2230.02s | Assembly else us dump. Okay? I create this in order to do this test. And this is the result 2236.50s - 2241.50s | table. Okay? This is the products that I, I was able to test. And as you can see uh we, we 2243.78s - 2248.78s | have uh a lot of effectivity in order to, to doing this little things. Uh as I told you guys, 2255.88s - 2260.88s | uh three weeks ago two vendors uh reached me in order to, to test uh again. The sentinel one 2266.06s - 2271.06s | was the first and the second one was the trench. This results that I'm showing you uh the 2274.30s - 2279.30s | sentinel one was able to uh stop hookchain. They did some patches in his product and uh 2285.10s - 2290.10s | I was able to, to test this and stop it at all. Okay? Deadline, end line. Uh and the trench uh 2295.12s - 2300.12s | still working on this, this uh uh identification. And they tried some behaviors but, but not 2302.56s - 2307.56s | at all. Okay? The other vendors, non-contact. Okay? I love it this uh this phrase of 2317.89s - 2322.89s | Sif Hawking. I'm just a child asking who, how and why. Occasionally I found the answer. 2328.67s - 2333.67s | Thank you guys. This is my contact. Full white paper, source code, reference and feel free 2340.61s - 2345.61s | to contact me, feel free to reach me by uh LinkedIn. My LinkedIn, it's my name and 2347.83s - 2352.95s | just Elvio Junior and that's it. Now it's your time, time to ask questions. Thank you.


chunk_id: 209_chunk_28
chunk_text:
they tried some behaviors but, but not 2302.56s - 2307.56s | at all. Okay? The other vendors, non-contact. Okay? I love it this uh this phrase of 2317.89s - 2322.89s | Sif Hawking. I'm just a child asking who, how and why. Occasionally I found the answer. 2328.67s - 2333.67s | Thank you guys. This is my contact. Full white paper, source code, reference and feel free 2340.61s - 2345.61s | to contact me, feel free to reach me by uh LinkedIn. My LinkedIn, it's my name and 2347.83s - 2352.95s | just Elvio Junior and that's it. Now it's your time, time to ask questions. Thank you.


chunk_id: 210_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=EHdI6bdw-wo", "title": "DEF CON 32 - Feet Feud", "description": "Another fascinating DEF CON Game show.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2380, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 15.14s | This text was transcribed using whisper model: large-v2 all right oh god there's lights okay thank you for coming I am Tiberius 15.14s - 21.02s | however when I'm when I'm hacking with the only feet CTF team I take on a new 21.02s - 29.06s | moniker of Tobias so that's who I will be presenting as this evening you also 29.06s - 32.70s | have to forgive the nerves the we've technically done this unofficially at 32.70s - 39.74s | Defcon the past two years the largest crowd we got was 40 there are and it's 39.74s - 42.18s | great actually because the lights I can't really see many people but I 42.18s - 46.70s | assume there are quite a lot more than 40 here we are gonna try and speed 46.70s - 52.42s | through this because we really want hacker jeopardy to go on time so I'm 52.42s - 55.54s | gonna introduce the team captains and then we are very very quickly choose 55.54s - 61.86s | some teams from the audience the captain of team left foot tonight you may know 61.86s - 65.78s | her from her software dev twitch streams you may know her as the writer 65.78s - 70.54s | and host of hack fives threat wire or maybe as one of the minds behind the net 70.54s - 82.06s | gala please give a very warm welcome to Ali diamond hello now for the captain 82.06s - 89.66s | of team right foot some people call him orange flavored John others know him as 89.66s - 97.90s | cyber security Ed Sheeran ladies and gentlemen we spared no expense it's John 97.90s - 107.04s | Hammond you've got so many more cheers than me okay if you would like to play 107.04s - 115.76s | please stand up that okay so basically team right for actually one last year so 115.76s - 121.20s | let's forget to pick first I want him he's look at him who bright orange okay 121.20s - 129.32s | bright orange come over here there are steps over there John pick your teammate 129.32s - 141.73s | orange bowtie all right


chunk_id: 210_chunk_1
chunk_text:
quickly choose 55.54s - 61.86s | some teams from the audience the captain of team left foot tonight you may know 61.86s - 65.78s | her from her software dev twitch streams you may know her as the writer 65.78s - 70.54s | and host of hack fives threat wire or maybe as one of the minds behind the net 70.54s - 82.06s | gala please give a very warm welcome to Ali diamond hello now for the captain 82.06s - 89.66s | of team right foot some people call him orange flavored John others know him as 89.66s - 97.90s | cyber security Ed Sheeran ladies and gentlemen we spared no expense it's John 97.90s - 107.04s | Hammond you've got so many more cheers than me okay if you would like to play 107.04s - 115.76s | please stand up that okay so basically team right for actually one last year so 115.76s - 121.20s | let's forget to pick first I want him he's look at him who bright orange okay 121.20s - 129.32s | bright orange come over here there are steps over there John pick your teammate 129.32s - 141.73s | orange bowtie all right Ali okay I'm seeing that guy over there point at 141.73s - 151.09s | someone okay yes there we go get over here over here pointing girl I want you 151.25s - 169.69s | next let's go I like it can't see distances oh wait oh my god put your 169.69s - 178.02s | hands over the lights it helps so much yeah quickly John always I'll choose for 178.02s - 181.74s | you we have another group of people pointing at people I want you yeah all 181.74s - 193.83s | right yes yeah come through come through come through the feralness Ali 193.83s - 201.97s | right back there yeah not everyone needs a hype crew but I'm hyping you up I 201.97s - 213.85s | don't know who you are yeah no I'm sorry I want that one are we done 214.01s - 225.58s | hang on sorry lost count hell yeah women okay I love women I'm so sorry for 225.58s - 233.50s | kicking you off bro yo I got a ginger what are you gonna do about it okay I 233.50s - 237.58s | am now realizing I probably should have asked if any


chunk_id: 210_chunk_2
chunk_text:
Ali okay I'm seeing that guy over there point at 141.73s - 151.09s | someone okay yes there we go get over here over here pointing girl I want you 151.25s - 169.69s | next let's go I like it can't see distances oh wait oh my god put your 169.69s - 178.02s | hands over the lights it helps so much yeah quickly John always I'll choose for 178.02s - 181.74s | you we have another group of people pointing at people I want you yeah all 181.74s - 193.83s | right yes yeah come through come through come through the feralness Ali 193.83s - 201.97s | right back there yeah not everyone needs a hype crew but I'm hyping you up I 201.97s - 213.85s | don't know who you are yeah no I'm sorry I want that one are we done 214.01s - 225.58s | hang on sorry lost count hell yeah women okay I love women I'm so sorry for 225.58s - 233.50s | kicking you off bro yo I got a ginger what are you gonna do about it okay I 233.50s - 237.58s | am now realizing I probably should have asked if any of these people have played 237.58s - 246.30s | or watched family feud before oh well so round one for a good time Ali and 246.30s - 253.42s | John please step up to these two mics hi everyone and grab a buzzer which I 253.42s - 266.01s | hopefully will work really tall I'm really short am I taller than you okay 266.01s - 271.65s | here's how it's gonna work I'm gonna read the question and if you think you 271.65s - 276.65s | know an answer buzz in do not just blurt out the answer because I have to look 276.65s - 284.10s | down and figure out who buzzed in first I will ask you okay all right let's see 284.10s - 289.38s | the question oh I should probably preface we can these these were survey 289.38s - 293.06s | questions that were generated by members of the community they're also answered 293.06s - 297.30s | by members of the community I did remove all wrong answers and there were 297.30s - 303.90s | quite a lot of them the data has been normalized so basically the max total is 303.90s - 307.46s | a


chunk_id: 210_chunk_3
chunk_text:
of these people have played 237.58s - 246.30s | or watched family feud before oh well so round one for a good time Ali and 246.30s - 253.42s | John please step up to these two mics hi everyone and grab a buzzer which I 253.42s - 266.01s | hopefully will work really tall I'm really short am I taller than you okay 266.01s - 271.65s | here's how it's gonna work I'm gonna read the question and if you think you 271.65s - 276.65s | know an answer buzz in do not just blurt out the answer because I have to look 276.65s - 284.10s | down and figure out who buzzed in first I will ask you okay all right let's see 284.10s - 289.38s | the question oh I should probably preface we can these these were survey 289.38s - 293.06s | questions that were generated by members of the community they're also answered 293.06s - 297.30s | by members of the community I did remove all wrong answers and there were 297.30s - 303.90s | quite a lot of them the data has been normalized so basically the max total is 303.90s - 307.46s | a hundred for each one anyway we're gonna go all right show the question 307.46s - 312.94s | please name a threat actor or a cybercrime group all right that is team 312.94s - 324.30s | right foot John lock bit lock bit survey says okay lock bit is there but it is 324.30s - 329.38s | not the top answer so Ali if you can get answers two or one you will win 329.38s - 333.14s | control of the board okay I'm gonna say a funny one but then in a real one 333.14s - 342.41s | Crowdstrike but actually scattered spider what do you say scattered spider 342.41s - 348.05s | scattered spider survey says unfortunately the fourth answer sorry 348.05s - 350.89s | the sick lancers so John you've been controlled the board that means do you 350.89s - 363.21s | want to play or pass we will play okay thank you please sit down okay bowtie 364.53s - 370.01s | rubber duck bowtie please speak into the mic as well thank you all right name a 370.01s - 384.66s | threat actor or cybercrime group apt 40 survey says no okay glasses and beard 384.66s -


chunk_id: 210_chunk_4
chunk_text:
hundred for each one anyway we're gonna go all right show the question 307.46s - 312.94s | please name a threat actor or a cybercrime group all right that is team 312.94s - 324.30s | right foot John lock bit lock bit survey says okay lock bit is there but it is 324.30s - 329.38s | not the top answer so Ali if you can get answers two or one you will win 329.38s - 333.14s | control of the board okay I'm gonna say a funny one but then in a real one 333.14s - 342.41s | Crowdstrike but actually scattered spider what do you say scattered spider 342.41s - 348.05s | scattered spider survey says unfortunately the fourth answer sorry 348.05s - 350.89s | the sick lancers so John you've been controlled the board that means do you 350.89s - 363.21s | want to play or pass we will play okay thank you please sit down okay bowtie 364.53s - 370.01s | rubber duck bowtie please speak into the mic as well thank you all right name a 370.01s - 384.66s | threat actor or cybercrime group apt 40 survey says no okay glasses and beard 384.66s - 392.96s | I'm just gonna call you that cult of the dead cow a survey says no okay other 392.96s - 404.06s | glasses and beard sorry name a threat actor or cybercrime group no conferring 404.06s - 411.43s | John there's no conferring no you can only confer when it's they're going over 411.43s - 426.89s | to steal yes you say sorry napsis sorry lapses no all right so Ali's team you 426.89s - 431.09s | can confer for a bit and then Ali I want an answer from you if you get any answer 431.09s - 448.47s | on the board you will win the board US government is that your final answer the 448.47s - 465.98s | US government no okay so team right foot win 25 points in round one okay so the 465.98s - 477.42s | seventh answer was alpha the fifth alpha sorry the fifth answer sandworm for cozy 477.42s - 492.14s | bear second Lazarus group and number one fancy bear okay all right bowtie and hard 492.14s - 500.42s | hat please come up to the podium grab yourself a buzzer we have a construction worker because 500.42s - 509.22s |


chunk_id: 210_chunk_5
chunk_text:
392.96s | I'm just gonna call you that cult of the dead cow a survey says no okay other 392.96s - 404.06s | glasses and beard sorry name a threat actor or cybercrime group no conferring 404.06s - 411.43s | John there's no conferring no you can only confer when it's they're going over 411.43s - 426.89s | to steal yes you say sorry napsis sorry lapses no all right so Ali's team you 426.89s - 431.09s | can confer for a bit and then Ali I want an answer from you if you get any answer 431.09s - 448.47s | on the board you will win the board US government is that your final answer the 448.47s - 465.98s | US government no okay so team right foot win 25 points in round one okay so the 465.98s - 477.42s | seventh answer was alpha the fifth alpha sorry the fifth answer sandworm for cozy 477.42s - 492.14s | bear second Lazarus group and number one fancy bear okay all right bowtie and hard 492.14s - 500.42s | hat please come up to the podium grab yourself a buzzer we have a construction worker because 500.42s - 509.22s | we're getting to work okay you guys ready all right show the question please name a 509.22s - 519.18s | security portmanteau do you need an example yes please a secure portmanteau is where you 519.18s - 525.34s | take two or more words and combine them into one word e.g. you could call red teaming reaming 525.34s - 545.25s | okay so that was left foot smishing smishing a survey says it was fishing etc smishing the 545.25s - 552.13s | second answer that means right foot can steal the board I guess by that logic malware ransomware 552.13s - 558.05s | like that what combination what answer do you want oh let's go malware malware a survey says 558.05s - 577.67s | do you want to play or pass John we will pass oh okay left foot are gonna play yes yes yes 577.67s - 589.47s | I don't know how this works all right go with white claw hi yeah I'm gonna steal our collective 589.47s - 602.14s | one can you speak a little louder sorry oh yeah I'm gonna go with ransomware ransomware no discount 602.14s - 625.41s | John Hammond yeah timeout okay I


chunk_id: 210_chunk_6
chunk_text:
we're getting to work okay you guys ready all right show the question please name a 509.22s - 519.18s | security portmanteau do you need an example yes please a secure portmanteau is where you 519.18s - 525.34s | take two or more words and combine them into one word e.g. you could call red teaming reaming 525.34s - 545.25s | okay so that was left foot smishing smishing a survey says it was fishing etc smishing the 545.25s - 552.13s | second answer that means right foot can steal the board I guess by that logic malware ransomware 552.13s - 558.05s | like that what combination what answer do you want oh let's go malware malware a survey says 558.05s - 577.67s | do you want to play or pass John we will pass oh okay left foot are gonna play yes yes yes 577.67s - 589.47s | I don't know how this works all right go with white claw hi yeah I'm gonna steal our collective 589.47s - 602.14s | one can you speak a little louder sorry oh yeah I'm gonna go with ransomware ransomware no discount 602.14s - 625.41s | John Hammond yeah timeout okay I don't know I'm running out of clever nicknames now blackhead guy 625.41s - 634.89s | I'm gonna go with Thunder what do you say sorry Thunder can you speak a little bit sorry Thunder 634.89s - 653.84s | Thunder yes Thunder no so John's team you can steal this we need milk do we have to answer this 653.84s - 659.96s | one correctly to get the points I mean ideally in a quiz show you would give correct answers John 659.96s - 665.60s | I'm not sure it's one of the answers chairman so I consulted with my team and they told me if you put 665.60s - 679.16s | together lock picking you get licking is that the final answer you're going with no all right 679.16s - 689.93s | so team left foot technically win that one black hair you're gonna be disappointed with the answer 689.93s - 700.94s | number seven you're so close it's grunting wait we should get that you don't get that you said 700.94s - 712.70s | thunting I was very clear all right sick dancer Dev second thing me there just say Deborah pen 712.70s - 726.62s | test that's a


chunk_id: 210_chunk_7
chunk_text:
don't know I'm running out of clever nicknames now blackhead guy 625.41s - 634.89s | I'm gonna go with Thunder what do you say sorry Thunder can you speak a little bit sorry Thunder 634.89s - 653.84s | Thunder yes Thunder no so John's team you can steal this we need milk do we have to answer this 653.84s - 659.96s | one correctly to get the points I mean ideally in a quiz show you would give correct answers John 659.96s - 665.60s | I'm not sure it's one of the answers chairman so I consulted with my team and they told me if you put 665.60s - 679.16s | together lock picking you get licking is that the final answer you're going with no all right 679.16s - 689.93s | so team left foot technically win that one black hair you're gonna be disappointed with the answer 689.93s - 700.94s | number seven you're so close it's grunting wait we should get that you don't get that you said 700.94s - 712.70s | thunting I was very clear all right sick dancer Dev second thing me there just say Deborah pen 712.70s - 726.62s | test that's a good for info sec and third activism this is my 13th reason and I just noticed the left 726.62s - 739.78s | foot did score a very nice number of points that round so that's good okay okay glasses and beard 739.78s - 753.95s | versus go with white claw okay round three we see the question please oh the buzzers yes you should 753.95s - 763.19s | probably get the buzzers thank you we'll be better next year all right question please it's not 763.19s - 770.63s | showing it could you go back to scores and try and just go start oh why start round two and why 770.63s - 779.07s | is right for have zero okay hang on you need to update how are we winning there should be a way 779.07s - 792.26s | to update the just the scores Helen oh hang on now they've got zero you just over it oh no they 792.26s - 804.15s | don't okay sorry sorry it looked like they had zero all right round two and well we keep in 804.15s - 808.71s | manual track of the school because honestly I don't really trust this system


chunk_id: 210_chunk_8
chunk_text:
good for info sec and third activism this is my 13th reason and I just noticed the left 726.62s - 739.78s | foot did score a very nice number of points that round so that's good okay okay glasses and beard 739.78s - 753.95s | versus go with white claw okay round three we see the question please oh the buzzers yes you should 753.95s - 763.19s | probably get the buzzers thank you we'll be better next year all right question please it's not 763.19s - 770.63s | showing it could you go back to scores and try and just go start oh why start round two and why 770.63s - 779.07s | is right for have zero okay hang on you need to update how are we winning there should be a way 779.07s - 792.26s | to update the just the scores Helen oh hang on now they've got zero you just over it oh no they 792.26s - 804.15s | don't okay sorry sorry it looked like they had zero all right round two and well we keep in 804.15s - 808.71s | manual track of the school because honestly I don't really trust this system I so just show 808.71s - 816.38s | the question because this might be round if this is round two we just have to go through again okay 816.38s - 827.14s | technical difficulties is this running in PowerPoint it is running in PowerPoint yeah how many engineers 827.14s - 833.06s | does it take to fix a PowerPoint presentation yeah we might to end the show and then okay hang 833.06s - 841.70s | on well hang on well no because we need to reveal the answers anyway name no no no dude let's just 841.70s - 868.49s | restart the presentation okay seriously we can start over all right all right Helen oh y'all 868.49s - 874.69s | saw nothing we have backups we have backup questions don't get too excited we got backup 874.69s - 896.63s | questions I mean time how's everyone doing John yes Ali how's your DEF CON been it's been really 896.63s - 912.99s | good how many years yeah yeah correct yeah huge L um anyways hi everyone thank you so much for 912.99s - 920.71s | coming in the meantime I figured we should be entertaining the you were doing what


chunk_id: 210_chunk_9
chunk_text:
I so just show 808.71s - 816.38s | the question because this might be round if this is round two we just have to go through again okay 816.38s - 827.14s | technical difficulties is this running in PowerPoint it is running in PowerPoint yeah how many engineers 827.14s - 833.06s | does it take to fix a PowerPoint presentation yeah we might to end the show and then okay hang 833.06s - 841.70s | on well hang on well no because we need to reveal the answers anyway name no no no dude let's just 841.70s - 868.49s | restart the presentation okay seriously we can start over all right all right Helen oh y'all 868.49s - 874.69s | saw nothing we have backups we have backup questions don't get too excited we got backup 874.69s - 896.63s | questions I mean time how's everyone doing John yes Ali how's your DEF CON been it's been really 896.63s - 912.99s | good how many years yeah yeah correct yeah huge L um anyways hi everyone thank you so much for 912.99s - 920.71s | coming in the meantime I figured we should be entertaining the you were doing what is it called 920.71s - 927.43s | I did do that what's everyone's favorite village meant so far I want everyone to scream in three 927.43s - 936.19s | two one go yo that's sick those are awesome answers I didn't understand a single one of them 936.19s - 944.03s | but I have to say that's really exciting um who here I want to see a raise of hands who here is 944.03s - 951.47s | this your first DEF CON raise your hand oh my god wait this is so awesome okay wait I'm gonna 951.47s - 957.99s | pick what keep your hands up I'm gonna pick one person and I want you to be very loud and you're 957.99s - 966.56s | gonna tell me why you're here I saw you put that hand on real slow you want it you want to stand 966.56s - 974.24s | up and tell me why no um okay keep your hands up if you want to answer my question um I'm not 974.24s - 980.08s | choosing someone on the stage oh we got to move sorry we'll finish this later love you the most 980.08s - 986.04s


chunk_id: 210_chunk_10
chunk_text:
is it called 920.71s - 927.43s | I did do that what's everyone's favorite village meant so far I want everyone to scream in three 927.43s - 936.19s | two one go yo that's sick those are awesome answers I didn't understand a single one of them 936.19s - 944.03s | but I have to say that's really exciting um who here I want to see a raise of hands who here is 944.03s - 951.47s | this your first DEF CON raise your hand oh my god wait this is so awesome okay wait I'm gonna 951.47s - 957.99s | pick what keep your hands up I'm gonna pick one person and I want you to be very loud and you're 957.99s - 966.56s | gonna tell me why you're here I saw you put that hand on real slow you want it you want to stand 966.56s - 974.24s | up and tell me why no um okay keep your hands up if you want to answer my question um I'm not 974.24s - 980.08s | choosing someone on the stage oh we got to move sorry we'll finish this later love you the most 980.08s - 986.04s | all right I don't know which question everyone saw so we're just gonna forget that happened 986.04s - 996.48s | all right so round three fingers on buzzers all right show the question name an item considered 996.48s - 1004.72s | be PII that is right foot that's me right yeah okay you know what team you're on you're on the 1004.72s - 1013.76s | left side of the stage it should be obvious SSN SSN survey says it's the top answer what do you 1013.76s - 1024.60s | want to do John you want to play or pass your play or pass John I assume you're playing John 1024.60s - 1035.84s | are you playing excellent okay other beard and glasses guy mobile number sorry mobile number 1035.84s - 1050.21s | mobile number survey says correct phone number yes nice nice okay all right name and items 1050.21s - 1061.84s | considered be PII address address our survey says mailing address correct okay back to John 1062.28s - 1076.33s | birth date date of birth birth date a survey says yes name of school or workplace name of school or 1076.33s - 1086.13s | workplace survey says no


chunk_id: 210_chunk_11
chunk_text:
| all right I don't know which question everyone saw so we're just gonna forget that happened 986.04s - 996.48s | all right so round three fingers on buzzers all right show the question name an item considered 996.48s - 1004.72s | be PII that is right foot that's me right yeah okay you know what team you're on you're on the 1004.72s - 1013.76s | left side of the stage it should be obvious SSN SSN survey says it's the top answer what do you 1013.76s - 1024.60s | want to do John you want to play or pass your play or pass John I assume you're playing John 1024.60s - 1035.84s | are you playing excellent okay other beard and glasses guy mobile number sorry mobile number 1035.84s - 1050.21s | mobile number survey says correct phone number yes nice nice okay all right name and items 1050.21s - 1061.84s | considered be PII address address our survey says mailing address correct okay back to John 1062.28s - 1076.33s | birth date date of birth birth date a survey says yes name of school or workplace name of school or 1076.33s - 1086.13s | workplace survey says no we've lost sound but whatever like a health ID a health ID our survey 1086.13s - 1095.81s | says no get ready to steal team left foot banking information like credit card number CVV credit 1095.93s - 1112.94s | card number a survey says yes you're gonna sweep the board email address email address survey says 1112.94s - 1128.34s | yeah John for the win driver's license number driver's license number no okay left foot you 1128.34s - 1141.31s | have one chance for the second most popular answer to this survey question full name full 1141.31s - 1155.69s | name the survey says they 100 points to team left foot coming in with the clutch at the end okay 1155.69s - 1167.09s | round four can we have discount John Hammond and a other guy of beard and glasses please okay take a 1167.09s - 1176.74s | buzzer all right please show the question name a prestigious cybersecurity company might have 1176.74s - 1186.98s | been laid off from left foot buzzed in first speaking to the mic McAfee McAfee survey says 1186.98s - 1199.70s | no right foot crowd straight crowd strike a survey says the number one


chunk_id: 210_chunk_12
chunk_text:
we've lost sound but whatever like a health ID a health ID our survey 1086.13s - 1095.81s | says no get ready to steal team left foot banking information like credit card number CVV credit 1095.93s - 1112.94s | card number a survey says yes you're gonna sweep the board email address email address survey says 1112.94s - 1128.34s | yeah John for the win driver's license number driver's license number no okay left foot you 1128.34s - 1141.31s | have one chance for the second most popular answer to this survey question full name full 1141.31s - 1155.69s | name the survey says they 100 points to team left foot coming in with the clutch at the end okay 1155.69s - 1167.09s | round four can we have discount John Hammond and a other guy of beard and glasses please okay take a 1167.09s - 1176.74s | buzzer all right please show the question name a prestigious cybersecurity company might have 1176.74s - 1186.98s | been laid off from left foot buzzed in first speaking to the mic McAfee McAfee survey says 1186.98s - 1199.70s | no right foot crowd straight crowd strike a survey says the number one answer John John a 1199.70s - 1211.06s | play or pass we will play playing excellent okay pass the mic so go on the end please thank you 1211.26s - 1218.26s | okay name a prestigious cybersecurity company you might have been laid off from Avast sorry what 1218.26s - 1232.38s | Avast Avast survey says no back to John Microsoft Microsoft survey says no blame the community they 1232.38s - 1245.26s | didn't list them enough um Norton Norton a survey says yeah please don't do that no alley 1245.26s - 1253.50s | team left it left foot you can you can uh confer have you already yeah um I'll start with the 1253.50s - 1258.42s | trauma dump and it's not a real answer I personally got laid off from a cybersecurity company but 1258.42s - 1262.22s | we're gonna go with snick not that one but we're going with snick I forgot the name what are you 1262.22s - 1272.98s | going with snick sneak sneak I think all right sneak a survey says no so right foot win that 1272.98s - 1286.91s | round with 37 points hey this is an interesting one Oh what happened


chunk_id: 210_chunk_13
chunk_text:
answer John John a 1199.70s - 1211.06s | play or pass we will play playing excellent okay pass the mic so go on the end please thank you 1211.26s - 1218.26s | okay name a prestigious cybersecurity company you might have been laid off from Avast sorry what 1218.26s - 1232.38s | Avast Avast survey says no back to John Microsoft Microsoft survey says no blame the community they 1232.38s - 1245.26s | didn't list them enough um Norton Norton a survey says yeah please don't do that no alley 1245.26s - 1253.50s | team left it left foot you can you can uh confer have you already yeah um I'll start with the 1253.50s - 1258.42s | trauma dump and it's not a real answer I personally got laid off from a cybersecurity company but 1258.42s - 1262.22s | we're gonna go with snick not that one but we're going with snick I forgot the name what are you 1262.22s - 1272.98s | going with snick sneak sneak I think all right sneak a survey says no so right foot win that 1272.98s - 1286.91s | round with 37 points hey this is an interesting one Oh what happened yeah but does mean you got 1286.91s - 1308.66s | laid off from are we sure what round are we on all right so this all right well I'm just gonna 1308.66s - 1311.74s | read the answers don't click anything because I think we might build the next round but anyway 1311.74s - 1319.26s | all right in sixth place was Palo Alto fifth was Splunk okay we are on the good round fourth was 1319.26s - 1332.75s | NCC third was Rapid 7 second was Mandiant and number one was CrowdStrike okay yeah next round 1332.75s - 1346.90s | all right excellent take a buzzer please yours is on the floor for some reason okay show the 1346.90s - 1358.31s | question please name a DEF CON party oh is it not okay that is team left foot buzzing in all right 1358.31s - 1363.59s | sorry we'll figure that out in a minute team effort the blue team pool party the blue team 1363.59s - 1380.00s | pool party no right foot red team pool parties the red team pool party no left foot what is 1380.00s - 1387.52s | goth con excuse me goth con that's


chunk_id: 210_chunk_14
chunk_text:
yeah but does mean you got 1286.91s - 1308.66s | laid off from are we sure what round are we on all right so this all right well I'm just gonna 1308.66s - 1311.74s | read the answers don't click anything because I think we might build the next round but anyway 1311.74s - 1319.26s | all right in sixth place was Palo Alto fifth was Splunk okay we are on the good round fourth was 1319.26s - 1332.75s | NCC third was Rapid 7 second was Mandiant and number one was CrowdStrike okay yeah next round 1332.75s - 1346.90s | all right excellent take a buzzer please yours is on the floor for some reason okay show the 1346.90s - 1358.31s | question please name a DEF CON party oh is it not okay that is team left foot buzzing in all right 1358.31s - 1363.59s | sorry we'll figure that out in a minute team effort the blue team pool party the blue team 1363.59s - 1380.00s | pool party no right foot red team pool parties the red team pool party no left foot what is 1380.00s - 1387.52s | goth con excuse me goth con that's that's in about an hour but okay goth con correct you 1387.52s - 1396.16s | win control the board Ali do a play or pass play play okay all right Ali it's your turn name a 1396.16s - 1407.78s | DEF CON party queer con queer con oh yeah queer con oh survey says sorry yeah thank you queer 1407.78s - 1427.37s | con second oh god no no conferring no no ninja party the ninja party no arcade con arcade con 1427.37s - 1443.47s | yes for 15 masquerade party the masquerade party no I know don't blame me why I didn't come up 1443.47s - 1455.23s | with these blanket con sorry you speak up blanket con blanket con no John's team can steal what are 1455.23s - 1471.20s | you gonna go with John that con party the vet con party no so team left foot win those points 1471.20s - 1485.85s | 66 points to team left foot okay the sixth answer Florida man the fifth answer Illuminati 1485.85s - 1510.14s | party the third answer DEF CON fuzz okay yeah it's you and John again yeah we should check 1510.14s - 1519.20s | the buzzers


chunk_id: 210_chunk_15
chunk_text:
that's in about an hour but okay goth con correct you 1387.52s - 1396.16s | win control the board Ali do a play or pass play play okay all right Ali it's your turn name a 1396.16s - 1407.78s | DEF CON party queer con queer con oh yeah queer con oh survey says sorry yeah thank you queer 1407.78s - 1427.37s | con second oh god no no conferring no no ninja party the ninja party no arcade con arcade con 1427.37s - 1443.47s | yes for 15 masquerade party the masquerade party no I know don't blame me why I didn't come up 1443.47s - 1455.23s | with these blanket con sorry you speak up blanket con blanket con no John's team can steal what are 1455.23s - 1471.20s | you gonna go with John that con party the vet con party no so team left foot win those points 1471.20s - 1485.85s | 66 points to team left foot okay the sixth answer Florida man the fifth answer Illuminati 1485.85s - 1510.14s | party the third answer DEF CON fuzz okay yeah it's you and John again yeah we should check 1510.14s - 1519.20s | the buzzers hang on for the second round of feet con we will only press buzzers with our feet 1520.80s - 1534.91s | that one works okay they both work good I just changed it all right you can have the buzzers again 1538.18s - 1548.98s | Mimi okay all right show the question please name a popular cyber security cert that is left foot 1549.78s - 1558.26s | CompTIA plus I'm sorry the the CompTIA plus one I only my brain only knows it as CompTIA plus 1558.26s - 1568.10s | I'm a I'm a software engineer no John certified ethical hacker certified ethical hacker 1570.50s - 1574.66s | is that you've been controlled you already answered do you want do you want to play 1574.66s - 1581.78s | we will play all right John's gonna play is it by CompTIA yes it's a plus all right 1582.66s - 1595.58s | sec plus sec plus survey says yes net plus that's not you didn't say anything close to sec plus 1596.30s - 1600.22s | CompTIA plus it's by CompTIA they have they have multiple certs 1600.38s - 1606.22s | I call it in my brain okay wait do you take plus


chunk_id: 210_chunk_16
chunk_text:
hang on for the second round of feet con we will only press buzzers with our feet 1520.80s - 1534.91s | that one works okay they both work good I just changed it all right you can have the buzzers again 1538.18s - 1548.98s | Mimi okay all right show the question please name a popular cyber security cert that is left foot 1549.78s - 1558.26s | CompTIA plus I'm sorry the the CompTIA plus one I only my brain only knows it as CompTIA plus 1558.26s - 1568.10s | I'm a I'm a software engineer no John certified ethical hacker certified ethical hacker 1570.50s - 1574.66s | is that you've been controlled you already answered do you want do you want to play 1574.66s - 1581.78s | we will play all right John's gonna play is it by CompTIA yes it's a plus all right 1582.66s - 1595.58s | sec plus sec plus survey says yes net plus that's not you didn't say anything close to sec plus 1596.30s - 1600.22s | CompTIA plus it's by CompTIA they have they have multiple certs 1600.38s - 1606.22s | I call it in my brain okay wait do you take plus net plus no good huh 1608.38s - 1619.68s | what's your answer I'll go with net plus net plus no all right next 1621.44s - 1632.34s | OSCP huh OSCP OSCP I'm definitely coming back next year all right OSCP a survey says 1632.66s - 1634.82s | yeah number one answer 1639.95s - 1654.32s | CESA you speak intimate yep CESA CESA a survey says no back to John CISSP CISSP survey says 1655.36s - 1666.53s | yes bow tie it's all on you let's go with Cisco CCNA Cisco CCNA a survey says 1667.49s - 1669.97s | no okay Ali's team you have a chance to steal 1672.05s - 1675.33s | Ali I need an answer from you you're a team captain 1677.92s - 1687.34s | sans I'm sorry don't make fun of me I'm a software engineer I don't know what it's called 1687.98s - 1693.55s | what you you can confer with your team what you can confer with your team 1693.79s - 1706.18s | no they said sans sans a survey says no right foot win the round it's okay those are pity points 1707.54s - 1715.46s | all right and the fifth answer was PNPT


chunk_id: 210_chunk_17
chunk_text:
net plus no good huh 1608.38s - 1619.68s | what's your answer I'll go with net plus net plus no all right next 1621.44s - 1632.34s | OSCP huh OSCP OSCP I'm definitely coming back next year all right OSCP a survey says 1632.66s - 1634.82s | yeah number one answer 1639.95s - 1654.32s | CESA you speak intimate yep CESA CESA a survey says no back to John CISSP CISSP survey says 1655.36s - 1666.53s | yes bow tie it's all on you let's go with Cisco CCNA Cisco CCNA a survey says 1667.49s - 1669.97s | no okay Ali's team you have a chance to steal 1672.05s - 1675.33s | Ali I need an answer from you you're a team captain 1677.92s - 1687.34s | sans I'm sorry don't make fun of me I'm a software engineer I don't know what it's called 1687.98s - 1693.55s | what you you can confer with your team what you can confer with your team 1693.79s - 1706.18s | no they said sans sans a survey says no right foot win the round it's okay those are pity points 1707.54s - 1715.46s | all right and the fifth answer was PNPT the fuck is that that's like a transistor 1716.90s - 1722.18s | yo they still haven't figured out if P equals NP this is not fair okay next round math jokes 1725.02s - 1738.11s | okay hoping the buzzer's gonna work can you just hold them up so I can see which buzzer's 1738.11s - 1745.31s | the first yeah okay all right ready to show the question all right name a programming language 1745.87s - 1752.83s | that was team right foot Python Python you're kidding survey says I'm gonna number one answer 1753.79s - 1757.31s | play this mofo that's John's decision but thank you 1759.71s - 1767.71s | yeah I think we'll play this one we're playing excellent all right name a programming language 1767.71s - 1777.15s | let me carry I think we're gonna win this one so I'm gonna go with APL APL a survey says 1778.03s - 1782.91s | no John's dreams of being shattered in front of his eyes 1784.35s - 1794.35s | see was that just where you speak up see see a survey says correct yes third 1795.87s - 1809.63s | did they say lowercase c or uppercase c sharp a


chunk_id: 210_chunk_18
chunk_text:
the fuck is that that's like a transistor 1716.90s - 1722.18s | yo they still haven't figured out if P equals NP this is not fair okay next round math jokes 1725.02s - 1738.11s | okay hoping the buzzer's gonna work can you just hold them up so I can see which buzzer's 1738.11s - 1745.31s | the first yeah okay all right ready to show the question all right name a programming language 1745.87s - 1752.83s | that was team right foot Python Python you're kidding survey says I'm gonna number one answer 1753.79s - 1757.31s | play this mofo that's John's decision but thank you 1759.71s - 1767.71s | yeah I think we'll play this one we're playing excellent all right name a programming language 1767.71s - 1777.15s | let me carry I think we're gonna win this one so I'm gonna go with APL APL a survey says 1778.03s - 1782.91s | no John's dreams of being shattered in front of his eyes 1784.35s - 1794.35s | see was that just where you speak up see see a survey says correct yes third 1795.87s - 1809.63s | did they say lowercase c or uppercase c sharp a survey says yes John rust rust a survey says 1810.43s - 1819.98s | number two answer I'm gonna get hate for this but java java a survey says no 1826.77s - 1830.53s | all right one life left well crap um 1834.10s - 1843.60s | I should have said c but I got the two yeah c plus plus c plus plus a survey says 1844.56s - 1849.76s | yes you're literally kidding me you could tell a bunch of security people filled this out because 1849.76s - 1858.24s | this is not right most popular survey question survey answer was come on down say I'm asking 1858.24s - 1870.32s | you sorry uh uh javascript javascript our survey says no team left foot for the steal good answers 1871.04s - 1871.54s | confer 1874.08s - 1880.96s | it's all right it's all right go lang go lang survey says 1882.96s - 1891.04s | no I ever bolted by this list y'all are wrong for this I'm just gonna say 1892.32s - 1898.08s | there are a lot of funny people who answered the surveys because the sixth answer is of course 1898.80s - 1914.78s | cobalt nasty for this


chunk_id: 210_chunk_19
chunk_text:
survey says yes John rust rust a survey says 1810.43s - 1819.98s | number two answer I'm gonna get hate for this but java java a survey says no 1826.77s - 1830.53s | all right one life left well crap um 1834.10s - 1843.60s | I should have said c but I got the two yeah c plus plus c plus plus a survey says 1844.56s - 1849.76s | yes you're literally kidding me you could tell a bunch of security people filled this out because 1849.76s - 1858.24s | this is not right most popular survey question survey answer was come on down say I'm asking 1858.24s - 1870.32s | you sorry uh uh javascript javascript our survey says no team left foot for the steal good answers 1871.04s - 1871.54s | confer 1874.08s - 1880.96s | it's all right it's all right go lang go lang survey says 1882.96s - 1891.04s | no I ever bolted by this list y'all are wrong for this I'm just gonna say 1892.32s - 1898.08s | there are a lot of funny people who answered the surveys because the sixth answer is of course 1898.80s - 1914.78s | cobalt nasty for this all right the final round round eight 1916.30s - 1924.62s | that was crazy we'll figure out the schools at the end let's 1925.42s - 1928.94s | let's not let's not risk upsetting powerpoint again all right 1932.46s - 1935.18s | we're gonna need that money back we don't win with what 1937.18s - 1939.66s | he didn't he didn't bribe anything I don't remember anything all right 1939.74s - 1945.50s | okay hang on we gotta wait for the I did it oh he did show the question I read the question I 1945.50s - 1952.46s | think that's fair right no in my own head I read it did you see the question sim grip I did too 1952.46s - 1955.82s | okay all right we got an honest person over here all right so right foot 1955.82s - 1960.94s | neighbor's name a code scanning tool sim grip sem grip our survey says 1963.81s - 1967.57s | yes but it's not the top answer so if you can get either one two or three 1970.43s - 1984.59s | sink sorry um I'm gonna need an answer sink skink spank stinky 1989.55s - 1998.74s | no it's actually


chunk_id: 210_chunk_20
chunk_text:
all right the final round round eight 1916.30s - 1924.62s | that was crazy we'll figure out the schools at the end let's 1925.42s - 1928.94s | let's not let's not risk upsetting powerpoint again all right 1932.46s - 1935.18s | we're gonna need that money back we don't win with what 1937.18s - 1939.66s | he didn't he didn't bribe anything I don't remember anything all right 1939.74s - 1945.50s | okay hang on we gotta wait for the I did it oh he did show the question I read the question I 1945.50s - 1952.46s | think that's fair right no in my own head I read it did you see the question sim grip I did too 1952.46s - 1955.82s | okay all right we got an honest person over here all right so right foot 1955.82s - 1960.94s | neighbor's name a code scanning tool sim grip sem grip our survey says 1963.81s - 1967.57s | yes but it's not the top answer so if you can get either one two or three 1970.43s - 1984.59s | sink sorry um I'm gonna need an answer sink skink spank stinky 1989.55s - 1998.74s | no it's actually it's a reg ex you should like fill it in okay john do you wanna play or pass 2001.47s - 2006.83s | we will play okay all right name a code can you pass the mic down yeah I'm sorry 2006.83s - 2016.94s | it name a code scanning tool link can you speak up link link lint 2018.14s - 2032.03s | our survey says no sorry all right name a code scanning tool honestly don't have a clue 2032.03s - 2041.71s | diff diff all right no john check marks check marks our survey says yes 2042.51s - 2052.34s | uh I'm gonna answer sneak sneak our survey says yes the top answer 2053.78s - 2066.48s | alley in no world was that sneak you can't just take four letters to begin with s n y and just 2067.52s - 2079.49s | iterate through the other one okay name a code scanning tool um in solidarity with our 2079.89s - 2084.53s | friends over there I don't have one because she should have got that we love honesty 2086.77s - 2093.17s | okay well unfortunately that's incorrect so team left foot you do get a chance to steal 2104.05s


chunk_id: 210_chunk_21
chunk_text:
it's a reg ex you should like fill it in okay john do you wanna play or pass 2001.47s - 2006.83s | we will play okay all right name a code can you pass the mic down yeah I'm sorry 2006.83s - 2016.94s | it name a code scanning tool link can you speak up link link lint 2018.14s - 2032.03s | our survey says no sorry all right name a code scanning tool honestly don't have a clue 2032.03s - 2041.71s | diff diff all right no john check marks check marks our survey says yes 2042.51s - 2052.34s | uh I'm gonna answer sneak sneak our survey says yes the top answer 2053.78s - 2066.48s | alley in no world was that sneak you can't just take four letters to begin with s n y and just 2067.52s - 2079.49s | iterate through the other one okay name a code scanning tool um in solidarity with our 2079.89s - 2084.53s | friends over there I don't have one because she should have got that we love honesty 2086.77s - 2093.17s | okay well unfortunately that's incorrect so team left foot you do get a chance to steal 2104.05s - 2111.86s | coverity do you have an answer though alley you have to say it 2112.66s - 2122.10s | coverity coverity so they says yes wait wait hang on okay that should be four points 2123.62s - 2130.50s | oh hell yeah that's a typo that I did not check earlier okay so just subtract 50 from the score 2130.50s - 2142.06s | we're gonna add all right yeah so left foot does win that work repos right now okay so 305 2142.86s - 2150.06s | all right that is it so go back to the scores who did win oh yeah I'm sorry I'm new at this 2150.06s - 2162.94s | all right the third answer was sonar cube the second answer bearer code all right back to the 2162.94s - 2182.85s | scores who won oh well left foot crushed it but yeah left foot win 305 to 255 what comtia plus 2186.67s - 2197.31s | honestly okay honestly I accept it all right so we'll give out the prizes now so 2197.95s - 2199.07s | wait can I get my money back 2204.03s - 2212.59s | really okay good all right the money is mine okay


chunk_id: 210_chunk_22
chunk_text:
- 2111.86s | coverity do you have an answer though alley you have to say it 2112.66s - 2122.10s | coverity coverity so they says yes wait wait hang on okay that should be four points 2123.62s - 2130.50s | oh hell yeah that's a typo that I did not check earlier okay so just subtract 50 from the score 2130.50s - 2142.06s | we're gonna add all right yeah so left foot does win that work repos right now okay so 305 2142.86s - 2150.06s | all right that is it so go back to the scores who did win oh yeah I'm sorry I'm new at this 2150.06s - 2162.94s | all right the third answer was sonar cube the second answer bearer code all right back to the 2162.94s - 2182.85s | scores who won oh well left foot crushed it but yeah left foot win 305 to 255 what comtia plus 2186.67s - 2197.31s | honestly okay honestly I accept it all right so we'll give out the prizes now so 2197.95s - 2199.07s | wait can I get my money back 2204.03s - 2212.59s | really okay good all right the money is mine okay so the grand prize for each of you hack the box 2212.59s - 2219.63s | have kindly sponsored for one year vip voucher each also if you bring the card with this on to 2219.63s - 2223.71s | the hack sorry the hack the box booth tomorrow they will give you a free piece of merch 2226.94s - 2232.86s | can you distribute them so they they do have the codes printed on them so just keep that secret 2234.22s - 2244.66s | um you also get their prizes you also get the uh the black badge raffle feet feud card 2254.06s - 2261.52s | okay uh helen yep yeah so you also get a pair of coding socks 2262.48s - 2275.18s | each okay but wait wait this has a list of languages on it of course team right 2275.18s - 2283.34s | thought valiantly you get a weirdly little it's like a baby foot candle it's I don't know 2285.92s - 2292.08s | it was a very weird night on amazon um so yeah it's like a candle in the shape of a baby foot 2292.64s - 2302.66s | and also fruit by the foot that's the real


chunk_id: 210_chunk_23
chunk_text:
so the grand prize for each of you hack the box 2212.59s - 2219.63s | have kindly sponsored for one year vip voucher each also if you bring the card with this on to 2219.63s - 2223.71s | the hack sorry the hack the box booth tomorrow they will give you a free piece of merch 2226.94s - 2232.86s | can you distribute them so they they do have the codes printed on them so just keep that secret 2234.22s - 2244.66s | um you also get their prizes you also get the uh the black badge raffle feet feud card 2254.06s - 2261.52s | okay uh helen yep yeah so you also get a pair of coding socks 2262.48s - 2275.18s | each okay but wait wait this has a list of languages on it of course team right 2275.18s - 2283.34s | thought valiantly you get a weirdly little it's like a baby foot candle it's I don't know 2285.92s - 2292.08s | it was a very weird night on amazon um so yeah it's like a candle in the shape of a baby foot 2292.64s - 2302.66s | and also fruit by the foot that's the real prize we really won honestly damn that's crazy 2306.10s - 2311.14s | we have extras excellent everyone gets fruit by the foot all right best day ever 2312.42s - 2318.74s | there's starburst flavored that is our show uh I hope everybody enjoyed it um hopefully we'll be 2318.74s - 2325.30s | back next year with bigger prizes wait I'd like a bigger audience but you've been fantastic so give 2325.30s - 2332.02s | yourselves a round of applause thank you everybody please also a huge round of applause to helen and 2332.02s - 2343.23s | wolfie for helping make this and run it and tips give it up for tips please also give a hand to 2343.23s - 2347.87s | wolfie and helen my assistants who have corrected me numerous times as i've fucked everything up 2348.59s - 2355.79s | no powerpoint next year maybe another round of applause for right foot sorry left foot 2358.03s - 2360.99s | and right foot i'm selling my socks if anyone wants 2360.99s - 2364.67s | i've been so furious this has been feet view thank you so much for watching 2364.67s - 2368.35s | does anyone want to buy my left


chunk_id: 210_chunk_24
chunk_text:
prize we really won honestly damn that's crazy 2306.10s - 2311.14s | we have extras excellent everyone gets fruit by the foot all right best day ever 2312.42s - 2318.74s | there's starburst flavored that is our show uh I hope everybody enjoyed it um hopefully we'll be 2318.74s - 2325.30s | back next year with bigger prizes wait I'd like a bigger audience but you've been fantastic so give 2325.30s - 2332.02s | yourselves a round of applause thank you everybody please also a huge round of applause to helen and 2332.02s - 2343.23s | wolfie for helping make this and run it and tips give it up for tips please also give a hand to 2343.23s - 2347.87s | wolfie and helen my assistants who have corrected me numerous times as i've fucked everything up 2348.59s - 2355.79s | no powerpoint next year maybe another round of applause for right foot sorry left foot 2358.03s - 2360.99s | and right foot i'm selling my socks if anyone wants 2360.99s - 2364.67s | i've been so furious this has been feet view thank you so much for watching 2364.67s - 2368.35s | does anyone want to buy my left sock or what have a great rest of the evening and enjoy 2368.35s - 2377.09s | hacker jeopardy thousand dollars thank you guys you did amazing i'm so proud of you


chunk_id: 210_chunk_25
chunk_text:
sock or what have a great rest of the evening and enjoy 2368.35s - 2377.09s | hacker jeopardy thousand dollars thank you guys you did amazing i'm so proud of you


chunk_id: 211_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=70yyOMFylUA", "title": "DEF CON 32 - Gotta Cache \u2018em all bending the rules of web cache exploitation - Martin Doyhenard", "description": "In recent years, web cache attacks have become a popular way to steal sensitive data, deface websites, and deliver exploits. We've also seen parser inconsistencies causing critical vulnerabilities like HTTP Request Smuggling. This raises the question: what happens if we attack web caches' URL-parsers?\n\nIn this session, I'll introduce two powerful new techniques that exploit RFC ambiguities to bypass the limitations of web cache deception and poisoning attacks.\n\nFirst, I'll introduce Static Path Deception, a novel technique to completely compromise the confidentiality of an application. I\u2019ll illustrate this with a case study showing how such a breach can be replicated in environments like Nginx behind Cloudflare.\n\nNext, I'll present Cache Key Confusion, and show how to exploit URL parsing inconsistencies in major platforms, including Microsoft Azure Cloud. I\u2019ll then show how to achieve arbitrary cache poisoning and full denial of service.\n\nFinally, I'll reveal how to supercharge these vulnerabilities with a live demo that blends Cache Key Confusion with a \u201cnon-exploitable\u201d open redirect to execute arbitrary JS code for complete site takeover.\n\nAttendees will depart armed with a set of innovative techniques, along with a definitive methodology to find and exploit these and other URL or HTTP discrepancies.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2638, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 5.00s | This text was transcribed using whisper model: large-v2 Uh welcome to track 2 talk number 2 on Saturday. Uh this morning we uh have Martin and he's 7.40s - 11.88s | gonna talk about breaking the rules of webcache exploitation. So are you ready Martin? 11.88s - 21.66s | I'm ready. Let's hear it for Martin. Thank you. Hello everyone. Welcome to Gara Cache Mall 21.66s - 28.14s | bending the rules of webcache exploitation. Uh it's already not working. So this is the 29.14s - 34.14s | agenda for today. First I'm going to briefly explain how a webcache works and then I'm 36.78s - 42.68s | going to show how we can abuse um discrepancies between the URL parsers of HTTP servers and 42.68s - 48.28s | cache proxies in order to steal secret information from victims using arbitrary webcache 48.28s - 54.32s | deception. Next I'm going to show how use the same techniques or similar techniques to 54.32s - 60.68s | obtain arbitrary webcache poisoning


chunk_id: 211_chunk_1
chunk_text:
along with a definitive methodology to find and exploit these and other URL or HTTP discrepancies.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2638, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 5.00s | This text was transcribed using whisper model: large-v2 Uh welcome to track 2 talk number 2 on Saturday. Uh this morning we uh have Martin and he's 7.40s - 11.88s | gonna talk about breaking the rules of webcache exploitation. So are you ready Martin? 11.88s - 21.66s | I'm ready. Let's hear it for Martin. Thank you. Hello everyone. Welcome to Gara Cache Mall 21.66s - 28.14s | bending the rules of webcache exploitation. Uh it's already not working. So this is the 29.14s - 34.14s | agenda for today. First I'm going to briefly explain how a webcache works and then I'm 36.78s - 42.68s | going to show how we can abuse um discrepancies between the URL parsers of HTTP servers and 42.68s - 48.28s | cache proxies in order to steal secret information from victims using arbitrary webcache 48.28s - 54.32s | deception. Next I'm going to show how use the same techniques or similar techniques to 54.32s - 60.68s | obtain arbitrary webcache poisoning by modifying the keys of a store resource. Then I'm 60.68s - 66.16s | going to combine both techniques in order to store whatever I want in the webcache with any 66.16s - 71.86s | key so this will allow us to create a full defacement of a website. And finally I'm going to 71.86s - 76.00s | present some protections that can be used to defend against those attacks and it takes hours 76.00s - 83.14s | of the session. So before I start eh I want to clarify that most of the or all the examples 83.16s - 88.54s | are going to be based on CDNs like CloudFront, CloudFront, Akamai but the idea is that you 88.54s - 94.20s | can use all of these techniques with any HTTP with any webcache eh proxy or with any webcache 94.20s - 100.98s | that you want even those that are included in the HTTP server. So whenever someone sends a 100.98s - 105.26s | request to a website using a webcache basically the first thing that is going to happen is 105.26s - 109.56s | that the cache proxy is going to handle the request and is going


chunk_id: 211_chunk_2
chunk_text:
by modifying the keys of a store resource. Then I'm 60.68s - 66.16s | going to combine both techniques in order to store whatever I want in the webcache with any 66.16s - 71.86s | key so this will allow us to create a full defacement of a website. And finally I'm going to 71.86s - 76.00s | present some protections that can be used to defend against those attacks and it takes hours 76.00s - 83.14s | of the session. So before I start eh I want to clarify that most of the or all the examples 83.16s - 88.54s | are going to be based on CDNs like CloudFront, CloudFront, Akamai but the idea is that you 88.54s - 94.20s | can use all of these techniques with any HTTP with any webcache eh proxy or with any webcache 94.20s - 100.98s | that you want even those that are included in the HTTP server. So whenever someone sends a 100.98s - 105.26s | request to a website using a webcache basically the first thing that is going to happen is 105.26s - 109.56s | that the cache proxy is going to handle the request and is going to try to generate the 109.58s - 114.28s | response without having to communicate with the original server. And this is going to be 114.28s - 120.06s | done by calculating a key and then this key is basically an identifier of the request that 120.06s - 125.26s | states which is the resource that is being requested and it's not really important other 125.26s - 129.64s | other things like the the headers like cookies or user agent because when we have two 129.64s - 134.94s | requests that are looking for the same resource and that resource is static then we just need 134.96s - 140.10s | to provide the resource and we don't care about processing anything else. So we will see 140.10s - 145.10s | that the keys are just URLs and host names and in this talk we will just focus on the URL. So 147.74s - 153.44s | when the cache proxy calculated this key and is looking for a re- a response that can be 153.44s - 159.08s | served eh to this to this request it will he will look at the cache table and if there's 159.08s - 163.96s | nothing


chunk_id: 211_chunk_3
chunk_text:
to try to generate the 109.58s - 114.28s | response without having to communicate with the original server. And this is going to be 114.28s - 120.06s | done by calculating a key and then this key is basically an identifier of the request that 120.06s - 125.26s | states which is the resource that is being requested and it's not really important other 125.26s - 129.64s | other things like the the headers like cookies or user agent because when we have two 129.64s - 134.94s | requests that are looking for the same resource and that resource is static then we just need 134.96s - 140.10s | to provide the resource and we don't care about processing anything else. So we will see 140.10s - 145.10s | that the keys are just URLs and host names and in this talk we will just focus on the URL. So 147.74s - 153.44s | when the cache proxy calculated this key and is looking for a re- a response that can be 153.44s - 159.08s | served eh to this to this request it will he will look at the cache table and if there's 159.08s - 163.96s | nothing there it will send the request to the original server. Now the original server is 163.98s - 169.84s | going to parse the URL obtaining the path and then it's going to use an endpoint to resolve 169.84s - 174.66s | the request. Sometimes it's just a static endpoint like a file and sometimes it's a dynamic 174.66s - 181.66s | one that is generated by a program back then. So when this response is sent back to the cache 181.66s - 187.44s | proxy the well the cache proxy is going to generate to evaluate some rules to see if this 187.44s - 193.44s | response should be stored in the cache. So if it's static or not. These rules are usually 193.46s - 199.76s | evaluated on the response using the cache control header but also in the request the cache 199.76s - 204.50s | proxy is going to extract the path and it's going to evaluate it with some of the other rules. 204.50s - 210.70s | For example the static extension one which is by default in most CDNs that looks for static 210.70s - 216.24s | extensions. So basically this is the list that Cloudflare


chunk_id: 211_chunk_4
chunk_text:
there it will send the request to the original server. Now the original server is 163.98s - 169.84s | going to parse the URL obtaining the path and then it's going to use an endpoint to resolve 169.84s - 174.66s | the request. Sometimes it's just a static endpoint like a file and sometimes it's a dynamic 174.66s - 181.66s | one that is generated by a program back then. So when this response is sent back to the cache 181.66s - 187.44s | proxy the well the cache proxy is going to generate to evaluate some rules to see if this 187.44s - 193.44s | response should be stored in the cache. So if it's static or not. These rules are usually 193.46s - 199.76s | evaluated on the response using the cache control header but also in the request the cache 199.76s - 204.50s | proxy is going to extract the path and it's going to evaluate it with some of the other rules. 204.50s - 210.70s | For example the static extension one which is by default in most CDNs that looks for static 210.70s - 216.24s | extensions. So basically this is the list that Cloudflare has. Uh it will look for the path 216.24s - 221.88s | and the extension of that path and if it ends with any of these eh extension any of these 221.92s - 226.06s | strings then it's going to decide that this is a static respo- resource and it's going to 226.06s - 232.20s | store it in the in the web cache. So in this example we see that styles.css ends with a 232.20s - 236.94s | static extension and therefore it's going to be cached using the key that was calculated in 236.94s - 243.70s | the first step. Now whenever another client or even the same client sends a request to the 243.70s - 248.24s | same resource the cache proxy is going to handle that, it's going to get the key of that 248.24s - 253.84s | request and then it's going to retrieve the res- the store resource because it doesn't need to 253.84s - 259.26s | interact with the origin server. And that's basically how a web cache works. Now we can 259.26s - 264.66s | exploit this in many ways. The first one is usually is the first one I'm going to


chunk_id: 211_chunk_5
chunk_text:
has. Uh it will look for the path 216.24s - 221.88s | and the extension of that path and if it ends with any of these eh extension any of these 221.92s - 226.06s | strings then it's going to decide that this is a static respo- resource and it's going to 226.06s - 232.20s | store it in the in the web cache. So in this example we see that styles.css ends with a 232.20s - 236.94s | static extension and therefore it's going to be cached using the key that was calculated in 236.94s - 243.70s | the first step. Now whenever another client or even the same client sends a request to the 243.70s - 248.24s | same resource the cache proxy is going to handle that, it's going to get the key of that 248.24s - 253.84s | request and then it's going to retrieve the res- the store resource because it doesn't need to 253.84s - 259.26s | interact with the origin server. And that's basically how a web cache works. Now we can 259.26s - 264.66s | exploit this in many ways. The first one is usually is the first one I'm going to describe 264.66s - 269.66s | actually is the one that was discovered by Omer Gil in 2017 which is a web cache deception 271.86s - 277.54s | and basically this attack is based on the idea that some backend servers use this special 277.54s - 282.38s | mapping where they are going to put some parameters in the path, this is called path 282.38s - 286.42s | parameters, and they are going to just look for the beginning of the path and they will try to 286.42s - 293.08s | match it with uh with any regex that is eh relate- related with the handler. So in this case 293.08s - 298.52s | if we send a request to slash my account slash param1, param2 then the only the first part 298.52s - 305.04s | is going to be used to map the endpoint and then this in this case is going to the origin 305.04s - 308.40s | server is going to generate a response which contains a lot of information from the victim 308.40s - 315.28s | because it is my account and it contains for instance the mail or the credit card details so 315.28s - 322.17s


chunk_id: 211_chunk_6
chunk_text:
describe 264.66s - 269.66s | actually is the one that was discovered by Omer Gil in 2017 which is a web cache deception 271.86s - 277.54s | and basically this attack is based on the idea that some backend servers use this special 277.54s - 282.38s | mapping where they are going to put some parameters in the path, this is called path 282.38s - 286.42s | parameters, and they are going to just look for the beginning of the path and they will try to 286.42s - 293.08s | match it with uh with any regex that is eh relate- related with the handler. So in this case 293.08s - 298.52s | if we send a request to slash my account slash param1, param2 then the only the first part 298.52s - 305.04s | is going to be used to map the endpoint and then this in this case is going to the origin 305.04s - 308.40s | server is going to generate a response which contains a lot of information from the victim 308.40s - 315.28s | because it is my account and it contains for instance the mail or the credit card details so 315.28s - 322.17s | basically this is what we want to steal. And to do so the first thing is to send uh a link to 322.17s - 327.71s | the victim, this requires user interaction and the link will start with the endpoint that we 327.71s - 332.65s | want to to steal the response so in this case it's my account and then it will use as a 332.67s - 338.95s | parameter a dot js. And the reason this is because first when it's handled by the origin 338.95s - 344.19s | server this is going to be mapped to my account using the cookies of the victim and so the 344.19s - 349.39s | response with the sensitive information is going to be sent back to the to the proxy and now 349.39s - 354.99s | with the cache proxy it evaluates the the path, this in this case it doesn't know anything 354.99s - 359.13s | about this mapping so it will think that the last part is just a parameter it's not a 359.15s - 363.63s | parameter sorry it's a path it's part of a path and therefore it will think that it has a static


chunk_id: 211_chunk_7
chunk_text:
| basically this is what we want to steal. And to do so the first thing is to send uh a link to 322.17s - 327.71s | the victim, this requires user interaction and the link will start with the endpoint that we 327.71s - 332.65s | want to to steal the response so in this case it's my account and then it will use as a 332.67s - 338.95s | parameter a dot js. And the reason this is because first when it's handled by the origin 338.95s - 344.19s | server this is going to be mapped to my account using the cookies of the victim and so the 344.19s - 349.39s | response with the sensitive information is going to be sent back to the to the proxy and now 349.39s - 354.99s | with the cache proxy it evaluates the the path, this in this case it doesn't know anything 354.99s - 359.13s | about this mapping so it will think that the last part is just a parameter it's not a 359.15s - 363.63s | parameter sorry it's a path it's part of a path and therefore it will think that it has a static 363.63s - 368.89s | extension in this case dot js and so it will store this response containing all the secret 368.89s - 373.87s | information. Now the attacker can send the same request and as the cookies are not important 373.87s - 379.07s | as the only important thing is just getting the same path well the cache proxy is going to 379.07s - 383.85s | match it with the key that already calculated in the first place and it will retrieve the 383.85s - 388.35s | victim's response containing all the secret information. Now the problem with this 388.37s - 393.21s | technique is that we need a special mapping for that basically we need this special my 393.21s - 397.75s | account thing and then we also require that the parameters that we are sending in this case 397.75s - 403.31s | a dot js doesn't have any effect on the backend because if not maybe the the response is not 403.31s - 409.74s | going to contain that information that we want. So I started looking at different ways to 409.74s - 414.24s | obtain arbitrary web cache deception which is basically obtaining the same thing


chunk_id: 211_chunk_8
chunk_text:
363.63s - 368.89s | extension in this case dot js and so it will store this response containing all the secret 368.89s - 373.87s | information. Now the attacker can send the same request and as the cookies are not important 373.87s - 379.07s | as the only important thing is just getting the same path well the cache proxy is going to 379.07s - 383.85s | match it with the key that already calculated in the first place and it will retrieve the 383.85s - 388.35s | victim's response containing all the secret information. Now the problem with this 388.37s - 393.21s | technique is that we need a special mapping for that basically we need this special my 393.21s - 397.75s | account thing and then we also require that the parameters that we are sending in this case 397.75s - 403.31s | a dot js doesn't have any effect on the backend because if not maybe the the response is not 403.31s - 409.74s | going to contain that information that we want. So I started looking at different ways to 409.74s - 414.24s | obtain arbitrary web cache deception which is basically obtaining the same thing but for any 414.26s - 420.72s | kind of uh end point that we want. And to do this I started looking at how the the path is 420.72s - 426.76s | obtained at each state. So basically the path is obtained from a URL by using these 426.76s - 431.90s | delimiters which are basically characters that can then can be used to know where each part of 431.90s - 438.10s | the URL or each part of the elements of the URL start and begin uh and end. There are a lot of 438.10s - 443.72s | them defined by the RFC so we can see that the URL has things like the scheme, the 443.72s - 449.26s | credentials, the host, the path query and fragment. So to split the each of them in a URL we 449.26s - 455.20s | need these these delimiters. The problem is that the RFC says that any any of these 455.20s - 460.34s | delimiters may or may not be or any of these characters may or may not be used as delimiters. 460.34s - 464.88s | And so each implementation can choose new delimiters and this could create some


chunk_id: 211_chunk_9
chunk_text:
but for any 414.26s - 420.72s | kind of uh end point that we want. And to do this I started looking at how the the path is 420.72s - 426.76s | obtained at each state. So basically the path is obtained from a URL by using these 426.76s - 431.90s | delimiters which are basically characters that can then can be used to know where each part of 431.90s - 438.10s | the URL or each part of the elements of the URL start and begin uh and end. There are a lot of 438.10s - 443.72s | them defined by the RFC so we can see that the URL has things like the scheme, the 443.72s - 449.26s | credentials, the host, the path query and fragment. So to split the each of them in a URL we 449.26s - 455.20s | need these these delimiters. The problem is that the RFC says that any any of these 455.20s - 460.34s | delimiters may or may not be or any of these characters may or may not be used as delimiters. 460.34s - 464.88s | And so each implementation can choose new delimiters and this could create some 464.88s - 471.82s | discrepancies. So let's say we find a server that is using a cache proxy and that is using 471.82s - 478.00s | the dollar sign as a delimiter. Then if we send a request to my account dollar sign 8 dot JS 478.00s - 483.20s | this is just going to be interpreted as my account because of the delimiter. However as I 483.20s - 488.20s | said in the front end there's no delimiter being being said with eh the dollar sign and 488.20s - 492.18s | therefore this is going to be interpreted the entire URL is going to be interpreted as the 492.18s - 497.92s | path and the last part which is 8 dot JS is going to be used as the extension. In this case 497.92s - 502.52s | actually it's dot JS the extension and so this is going to be stored in the cache just 502.52s - 507.70s | because of that delimiter. And in this case we can use it with any kind of path we want 507.70s - 512.66s | because we are not attacking a mapping we are attacking the entire way of obtaining the path


chunk_id: 211_chunk_10
chunk_text:
464.88s - 471.82s | discrepancies. So let's say we find a server that is using a cache proxy and that is using 471.82s - 478.00s | the dollar sign as a delimiter. Then if we send a request to my account dollar sign 8 dot JS 478.00s - 483.20s | this is just going to be interpreted as my account because of the delimiter. However as I 483.20s - 488.20s | said in the front end there's no delimiter being being said with eh the dollar sign and 488.20s - 492.18s | therefore this is going to be interpreted the entire URL is going to be interpreted as the 492.18s - 497.92s | path and the last part which is 8 dot JS is going to be used as the extension. In this case 497.92s - 502.52s | actually it's dot JS the extension and so this is going to be stored in the cache just 502.52s - 507.70s | because of that delimiter. And in this case we can use it with any kind of path we want 507.70s - 512.66s | because we are not attacking a mapping we are attacking the entire way of obtaining the path 512.66s - 518.94s | from the URL. Now which kind of delimiters we can find in the well well there are a lot of 518.94s - 525.12s | them. Some I listed were in the frameworks is eh the first one is semi the semicolon in 525.12s - 531.72s | spring so basically to define a matrix variable that is similar to a path eh parameter we can 531.72s - 537.46s | use a semicolon. And the thing is that if we send something like my account semicolon 8 dot 537.46s - 543.84s | JS anyone using Java probably Java in the well so they are going to consider this as my 543.84s - 548.48s | account. This includes Google or big companies that are using Java because this is how 548.50s - 555.52s | Spring works. And so we can use this for the attack. Now in Rails there's another really 555.52s - 561.96s | interesting case which is they use the dot as a delimiter and that's because ehm the user is 561.96s - 567.46s | able to send an extension with a valid endpoint and this will eh the effect that this will 567.46s - 573.26s |


chunk_id: 211_chunk_11
chunk_text:
512.66s - 518.94s | from the URL. Now which kind of delimiters we can find in the well well there are a lot of 518.94s - 525.12s | them. Some I listed were in the frameworks is eh the first one is semi the semicolon in 525.12s - 531.72s | spring so basically to define a matrix variable that is similar to a path eh parameter we can 531.72s - 537.46s | use a semicolon. And the thing is that if we send something like my account semicolon 8 dot 537.46s - 543.84s | JS anyone using Java probably Java in the well so they are going to consider this as my 543.84s - 548.48s | account. This includes Google or big companies that are using Java because this is how 548.50s - 555.52s | Spring works. And so we can use this for the attack. Now in Rails there's another really 555.52s - 561.96s | interesting case which is they use the dot as a delimiter and that's because ehm the user is 561.96s - 567.46s | able to send an extension with a valid endpoint and this will eh the effect that this will 567.46s - 573.26s | have is that Rails will look for a specific view for that eh request. So let's say we define 573.32s - 578.76s | an endpoint which is my account and then when we send a request to my account Rails will just 578.76s - 585.26s | go and look for the HTML view. Now if we send something like my account dot CSS, Rails will 585.26s - 591.24s | not just return a not a not found but it will look for the view of the the CSS view of my 591.24s - 597.78s | account. Usually there's no CSS view for my account so we'll just receive a 406 error. But 597.78s - 602.62s | the thing is that if the extension that we include is not recognized by Rails so let's say we 602.64s - 607.88s | send something like my account dot AAA then Rails is just going to send us the default view 607.88s - 614.32s | which is HTML. Remember all these eh all these extensions that are defined by Cloudflare. 614.32s - 620.32s | Well in green you can see the ones that are recognized by Rails. So if we send my account 620.32s


chunk_id: 211_chunk_12
chunk_text:
have is that Rails will look for a specific view for that eh request. So let's say we define 573.32s - 578.76s | an endpoint which is my account and then when we send a request to my account Rails will just 578.76s - 585.26s | go and look for the HTML view. Now if we send something like my account dot CSS, Rails will 585.26s - 591.24s | not just return a not a not found but it will look for the view of the the CSS view of my 591.24s - 597.78s | account. Usually there's no CSS view for my account so we'll just receive a 406 error. But 597.78s - 602.62s | the thing is that if the extension that we include is not recognized by Rails so let's say we 602.64s - 607.88s | send something like my account dot AAA then Rails is just going to send us the default view 607.88s - 614.32s | which is HTML. Remember all these eh all these extensions that are defined by Cloudflare. 614.32s - 620.32s | Well in green you can see the ones that are recognized by Rails. So if we send my account 620.32s - 626.94s | dot PNG or dot GPA or CSS then all of them are going to be recognized by Rails and it's going 626.94s - 631.98s | to try to look for that response. And if there's no view for that extension then it's just 632.00s - 636.68s | going to return us an error. But in red we see all the other extensions that are not 636.68s - 642.44s | recognized by Rails. So if we send something like my account dot ICO then we are going to 642.44s - 649.74s | get the default view but Cloudflare is going to think that this is a catchable resource. Now 649.74s - 653.88s | there are other delimiters that can be used in HTTP servers instead of frameworks such as 653.88s - 659.28s | the encoded null byte which is the case of open light speed. So basically this works like a 659.30s - 664.10s | question mark if we send something like my account null encoded byte A dot JS then this is 664.10s - 670.00s | just going to be used as my account. The problem for this is that we cannot send it through 670.00s -


chunk_id: 211_chunk_13
chunk_text:
- 626.94s | dot PNG or dot GPA or CSS then all of them are going to be recognized by Rails and it's going 626.94s - 631.98s | to try to look for that response. And if there's no view for that extension then it's just 632.00s - 636.68s | going to return us an error. But in red we see all the other extensions that are not 636.68s - 642.44s | recognized by Rails. So if we send something like my account dot ICO then we are going to 642.44s - 649.74s | get the default view but Cloudflare is going to think that this is a catchable resource. Now 649.74s - 653.88s | there are other delimiters that can be used in HTTP servers instead of frameworks such as 653.88s - 659.28s | the encoded null byte which is the case of open light speed. So basically this works like a 659.30s - 664.10s | question mark if we send something like my account null encoded byte A dot JS then this is 664.10s - 670.00s | just going to be used as my account. The problem for this is that we cannot send it through 670.00s - 675.44s | many CDNs like Azure, Imperva, Cloudfront, Cloudflare, Google Cloud. That's because they 675.44s - 680.62s | don't accept null encoded bytes. But fortunately Akamai and FastCDC yes so we can use them 680.62s - 687.36s | for eh this explanation. And finally in Nginx we have a delimiter whenever whenever we 687.40s - 693.54s | find a rewrite rule and the delimiter is the new line encoded and so basically it works just 693.54s - 698.58s | as in open light with a null encoded byte and in this case we can send it through any CDN we 698.58s - 705.12s | want. So if we send a request using any of these delimiters with the correct with the 705.12s - 710.42s | corresponding eh backend then all of them are going to be interpreted as my account. The 710.42s - 715.26s | response is going to be sent back but in this case the web caches are going to just store that 715.26s - 722.72s | because of the static extension. But the problem with this attack is that many CDNs are 722.72s - 727.08s | are already aware of this and they are implementing some detection


chunk_id: 211_chunk_14
chunk_text:
675.44s | many CDNs like Azure, Imperva, Cloudfront, Cloudflare, Google Cloud. That's because they 675.44s - 680.62s | don't accept null encoded bytes. But fortunately Akamai and FastCDC yes so we can use them 680.62s - 687.36s | for eh this explanation. And finally in Nginx we have a delimiter whenever whenever we 687.40s - 693.54s | find a rewrite rule and the delimiter is the new line encoded and so basically it works just 693.54s - 698.58s | as in open light with a null encoded byte and in this case we can send it through any CDN we 698.58s - 705.12s | want. So if we send a request using any of these delimiters with the correct with the 705.12s - 710.42s | corresponding eh backend then all of them are going to be interpreted as my account. The 710.42s - 715.26s | response is going to be sent back but in this case the web caches are going to just store that 715.26s - 722.72s | because of the static extension. But the problem with this attack is that many CDNs are 722.72s - 727.08s | are already aware of this and they are implementing some detection some protection for for 727.08s - 731.86s | this kind of attacks. In the case of Cloudflare for instance is web cache deception armor 731.86s - 737.50s | which what it does is it looks for the extension of the request and the content type of the 737.50s - 742.30s | response. And if they don't match for for instance for instance in this example we are using 742.30s - 748.68s | dot CSS as the extension and the content type is text HTML so if they don't match basically 748.68s - 755.22s | this is an attack and Cloudflare won't store this in the cache. So we can attack other rules 755.22s - 761.46s | like the static directories one. That's a rule that we can create as a user that states that 761.46s - 766.16s | anything starting with a specific path is going to be stored in the cache and that's really 766.16s - 771.20s | common in many applications because we we usually store static files in the same directory 771.24s - 776.88s | like share, public, assets, resources, anything that you can think. Uh and so we can use 776.88s - 782.24s | this to


chunk_id: 211_chunk_15
chunk_text:
some protection for for 727.08s - 731.86s | this kind of attacks. In the case of Cloudflare for instance is web cache deception armor 731.86s - 737.50s | which what it does is it looks for the extension of the request and the content type of the 737.50s - 742.30s | response. And if they don't match for for instance for instance in this example we are using 742.30s - 748.68s | dot CSS as the extension and the content type is text HTML so if they don't match basically 748.68s - 755.22s | this is an attack and Cloudflare won't store this in the cache. So we can attack other rules 755.22s - 761.46s | like the static directories one. That's a rule that we can create as a user that states that 761.46s - 766.16s | anything starting with a specific path is going to be stored in the cache and that's really 766.16s - 771.20s | common in many applications because we we usually store static files in the same directory 771.24s - 776.88s | like share, public, assets, resources, anything that you can think. Uh and so we can use 776.88s - 782.24s | this to attack this kind of eh this kind of web caches that are used in the rules. To create 782.24s - 788.18s | an attack in this case we will need some payload that is interpreted in the front end with 788.18s - 793.60s | the static directory at the beginning so basically in if the static directory is called static 793.60s - 799.36s | then we want the path to start with static slash and anything we want. And then in the back 799.36s - 804.70s | end we still want my account because we in this case want to steal my account we could steal 804.70s - 810.90s | anything else we want. So if we have a delimiter in the back end we can try to do this but we 810.90s - 817.18s | will need something else. And as I said to extract the path from a URL we just need the 817.18s - 822.82s | delimiter and then that path is used in the keys rules and mapping. Well not really. There's 822.82s - 828.86s | one extra step which is normalization. We need to normalize the path and most CDNs and 828.86s - 834.14s |


chunk_id: 211_chunk_16
chunk_text:
attack this kind of eh this kind of web caches that are used in the rules. To create 782.24s - 788.18s | an attack in this case we will need some payload that is interpreted in the front end with 788.18s - 793.60s | the static directory at the beginning so basically in if the static directory is called static 793.60s - 799.36s | then we want the path to start with static slash and anything we want. And then in the back 799.36s - 804.70s | end we still want my account because we in this case want to steal my account we could steal 804.70s - 810.90s | anything else we want. So if we have a delimiter in the back end we can try to do this but we 810.90s - 817.18s | will need something else. And as I said to extract the path from a URL we just need the 817.18s - 822.82s | delimiter and then that path is used in the keys rules and mapping. Well not really. There's 822.82s - 828.86s | one extra step which is normalization. We need to normalize the path and most CDNs and 828.86s - 834.14s | back end servers do normalize the path. This includes decoding the the characters. We can 834.14s - 840.80s | send them with URL encoded eh notation that is percentage eh and the excite small value of a 840.80s - 846.54s | character. And then in some cases the eh other other characters like segment delimiters like 846.54s - 852.88s | the slash or the dot are also going to be decoded so this is going to be really useful. And 852.88s - 858.98s | then the normalization also includes dot segments eh resolution which is just resolving 858.98s - 863.22s | path traversals and whenever we find a dot segment then we just remove the previous 863.22s - 868.22s | segment. And some parsers like the IIS one eh will also convert back slashes to slashes. So 872.20s - 876.94s | now that we know this we can actually create a new payload that is going to use normalization. 876.94s - 881.48s | Again we are using a delimiter so everything before the delimiter is going to be interpreted 881.48s - 888.12s | in the back end server. But now we are also sending an encoded eh path traversal. And


chunk_id: 211_chunk_17
chunk_text:
back end servers do normalize the path. This includes decoding the the characters. We can 834.14s - 840.80s | send them with URL encoded eh notation that is percentage eh and the excite small value of a 840.80s - 846.54s | character. And then in some cases the eh other other characters like segment delimiters like 846.54s - 852.88s | the slash or the dot are also going to be decoded so this is going to be really useful. And 852.88s - 858.98s | then the normalization also includes dot segments eh resolution which is just resolving 858.98s - 863.22s | path traversals and whenever we find a dot segment then we just remove the previous 863.22s - 868.22s | segment. And some parsers like the IIS one eh will also convert back slashes to slashes. So 872.20s - 876.94s | now that we know this we can actually create a new payload that is going to use normalization. 876.94s - 881.48s | Again we are using a delimiter so everything before the delimiter is going to be interpreted 881.48s - 888.12s | in the back end server. But now we are also sending an encoded eh path traversal. And that is 888.12s - 894.46s | because the front end is not using the delimiter so it's going to resolve this into this. And 894.46s - 900.72s | this includes a path traversal which is going to convert it to static WCD. So now in the front 900.72s - 905.24s | end we see that there are static characters there so this is going to be stored in the web 905.24s - 910.44s | cache. And in this way we are able to bypass the web cache deception armor because there's no 910.46s - 918.36s | extension so nothing to compare. Now let's see how how we can how we can apply this in a 918.36s - 923.36s | real environment. And so first we need a a front end that is normalizing the path. Sorry. Eh 926.76s - 932.46s | this is the case for CloudFront, Imperva and Azure. And so if we combine them with any back 932.46s - 937.64s | end that is using a specific delimiter like for instance Tomcat then we can send the same 938.26s - 944.70s | payload which is secret the semicolon with that represented delimiter. And this will cause 944.70s -


chunk_id: 211_chunk_18
chunk_text:
that is 888.12s - 894.46s | because the front end is not using the delimiter so it's going to resolve this into this. And 894.46s - 900.72s | this includes a path traversal which is going to convert it to static WCD. So now in the front 900.72s - 905.24s | end we see that there are static characters there so this is going to be stored in the web 905.24s - 910.44s | cache. And in this way we are able to bypass the web cache deception armor because there's no 910.46s - 918.36s | extension so nothing to compare. Now let's see how how we can how we can apply this in a 918.36s - 923.36s | real environment. And so first we need a a front end that is normalizing the path. Sorry. Eh 926.76s - 932.46s | this is the case for CloudFront, Imperva and Azure. And so if we combine them with any back 932.46s - 937.64s | end that is using a specific delimiter like for instance Tomcat then we can send the same 938.26s - 944.70s | payload which is secret the semicolon with that represented delimiter. And this will cause 944.70s - 949.84s | that in the back end we see secret. And in the front end again the semicolon is not a 949.84s - 954.88s | delimiter for either CloudFront I Azure or Imperva. And therefore this is going to be 954.88s - 962.12s | resolved to static slash X. And this way we will be able to steal any response we want in an 962.14s - 967.42s | environment that is using basic basic and default configured eh Tomcat and any of the CDNs 967.42s - 972.42s | that I showed. This can be used also with other back ends like eh Rails and Puma or even some 975.06s - 980.22s | in the same case that we observed in the in the first example when we had a special mapping 980.22s - 985.80s | in the back end. In this case there is no delimiter the the delimiter is just the the path 985.82s - 993.73s | that we are attacking. Now we could also try another attack that is using the opposite 993.73s - 997.51s | normalization so basically in the front end we don't have normalization that's the case of 997.51s - 1003.15s | CloudFront eh Google


chunk_id: 211_chunk_19
chunk_text:
949.84s | that in the back end we see secret. And in the front end again the semicolon is not a 949.84s - 954.88s | delimiter for either CloudFront I Azure or Imperva. And therefore this is going to be 954.88s - 962.12s | resolved to static slash X. And this way we will be able to steal any response we want in an 962.14s - 967.42s | environment that is using basic basic and default configured eh Tomcat and any of the CDNs 967.42s - 972.42s | that I showed. This can be used also with other back ends like eh Rails and Puma or even some 975.06s - 980.22s | in the same case that we observed in the in the first example when we had a special mapping 980.22s - 985.80s | in the back end. In this case there is no delimiter the the delimiter is just the the path 985.82s - 993.73s | that we are attacking. Now we could also try another attack that is using the opposite 993.73s - 997.51s | normalization so basically in the front end we don't have normalization that's the case of 997.51s - 1003.15s | CloudFront eh Google Cloud Platform and Fastly. And in the back end we have normalization 1003.15s - 1008.15s | in Nginx, IIS and open light speed. So if we use this we can create the attack by starting 1011.15s - 1016.89s | with the static directory. In this case it's slash static. And this is because the path is 1016.91s - 1022.31s | not normalized and so CloudFront for instance will think that this is the entire URL is the 1022.31s - 1029.21s | path. But in the back end this is going to be normalized and therefore anyone using Nginx or 1029.21s - 1034.99s | IIS or open light speed is going to see that the response is going to be for secret and this 1034.99s - 1041.43s | will be storing the cache because of the static path. This worked on OpenAI and many other 1041.43s - 1046.45s | bounties that I wasn't able to be eh I'm not able to talk about. And also this can be used 1050.45s - 1056.95s | with IIS basically IIS is the only one that is decoding uh normalizing the backslash so if we 1056.95s - 1063.09s | send something like using the in


chunk_id: 211_chunk_20
chunk_text:
Cloud Platform and Fastly. And in the back end we have normalization 1003.15s - 1008.15s | in Nginx, IIS and open light speed. So if we use this we can create the attack by starting 1011.15s - 1016.89s | with the static directory. In this case it's slash static. And this is because the path is 1016.91s - 1022.31s | not normalized and so CloudFront for instance will think that this is the entire URL is the 1022.31s - 1029.21s | path. But in the back end this is going to be normalized and therefore anyone using Nginx or 1029.21s - 1034.99s | IIS or open light speed is going to see that the response is going to be for secret and this 1034.99s - 1041.43s | will be storing the cache because of the static path. This worked on OpenAI and many other 1041.43s - 1046.45s | bounties that I wasn't able to be eh I'm not able to talk about. And also this can be used 1050.45s - 1056.95s | with IIS basically IIS is the only one that is decoding uh normalizing the backslash so if we 1056.95s - 1063.09s | send something like using the in the slide this is going to be converted to static eh and 1063.09s - 1067.73s | basically a dot segment with a backslash and it's going to be converted to account in IIS but 1067.73s - 1073.67s | not in any other eh CDN because IIS decided that this is a cool idea. And so yeah they are 1073.67s - 1080.52s | the only ones that I can be attacking with any other CDN. Now if we don't find one of these 1080.52s - 1086.84s | rules well there's there's another rule that we can use which is the static files. Eh in many 1086.84s - 1093.90s | in many CDNs we will see that there's a static file rule by default to store robots dot txt but 1093.90s - 1100.10s | we can also find others for favicon or for index dot html or for any the any file that is 1100.10s - 1105.74s | usually accessed by people and is static. And in this case we can use the same attack only 1105.74s - 1110.72s | that we are not going to target a static directory we are just going to target something that 1110.72s - 1117.72s |


chunk_id: 211_chunk_21
chunk_text:
the slide this is going to be converted to static eh and 1063.09s - 1067.73s | basically a dot segment with a backslash and it's going to be converted to account in IIS but 1067.73s - 1073.67s | not in any other eh CDN because IIS decided that this is a cool idea. And so yeah they are 1073.67s - 1080.52s | the only ones that I can be attacking with any other CDN. Now if we don't find one of these 1080.52s - 1086.84s | rules well there's there's another rule that we can use which is the static files. Eh in many 1086.84s - 1093.90s | in many CDNs we will see that there's a static file rule by default to store robots dot txt but 1093.90s - 1100.10s | we can also find others for favicon or for index dot html or for any the any file that is 1100.10s - 1105.74s | usually accessed by people and is static. And in this case we can use the same attack only 1105.74s - 1110.72s | that we are not going to target a static directory we are just going to target something that 1110.72s - 1117.72s | is being stored by the front end. So we can do something like secret then the delimiter 1117.74s - 1123.26s | then coded eh dot segment and finally robot dot txt and this should work in many in many 1123.26s - 1128.92s | applications. And also we can try to find other files. I found that there are many in in in the 1128.92s - 1136.20s | wild so you should be able to find many others if you look for. So web cache deception is 1136.20s - 1140.94s | pretty cool but the thing is you need user interaction and we don't really want user 1140.94s - 1147.38s | interaction. So web cache poisoning is there for rescue us and the idea in web cache 1147.44s - 1153.28s | poisoning is that we are going to try to store a malicious response in in a with a key that is 1153.28s - 1158.78s | going to be accessed by other people. So let's say we want to eh hijack someone that is 1158.78s - 1163.72s | using eh this this website this website and is accessing to the home page. Well if we are 1163.72s - 1167.96s | able


chunk_id: 211_chunk_22
chunk_text:
is being stored by the front end. So we can do something like secret then the delimiter 1117.74s - 1123.26s | then coded eh dot segment and finally robot dot txt and this should work in many in many 1123.26s - 1128.92s | applications. And also we can try to find other files. I found that there are many in in in the 1128.92s - 1136.20s | wild so you should be able to find many others if you look for. So web cache deception is 1136.20s - 1140.94s | pretty cool but the thing is you need user interaction and we don't really want user 1140.94s - 1147.38s | interaction. So web cache poisoning is there for rescue us and the idea in web cache 1147.44s - 1153.28s | poisoning is that we are going to try to store a malicious response in in a with a key that is 1153.28s - 1158.78s | going to be accessed by other people. So let's say we want to eh hijack someone that is 1158.78s - 1163.72s | using eh this this website this website and is accessing to the home page. Well if we are 1163.72s - 1167.96s | able to find a payload that is stored in the home page then everyone navigating through the 1167.96s - 1172.76s | web page is going to be affected. And usually you will look for something that is not 1172.78s - 1178.52s | stored like that is not used in the key so in this case if the cookie value is reflected in the 1178.52s - 1184.62s | in the body of the response then we are able to store this and anyone using the home page is 1184.62s - 1190.54s | going to be affected and is going to re is going to retrieve the malicious response. The 1190.54s - 1195.64s | problem with this attack is that in many cases we will find eh an example of a cache 1195.64s - 1200.38s | poisoning but is with a is using a key or is using a resource that is not going to be 1200.40s - 1204.90s | accessed by anyone. Like for instance if we are able to poison something that starts with 1204.90s - 1211.04s | files then our username and then our unique ID no one is going to be accessing that eh that 1211.04s - 1216.04s |


chunk_id: 211_chunk_23
chunk_text:
to find a payload that is stored in the home page then everyone navigating through the 1167.96s - 1172.76s | web page is going to be affected. And usually you will look for something that is not 1172.78s - 1178.52s | stored like that is not used in the key so in this case if the cookie value is reflected in the 1178.52s - 1184.62s | in the body of the response then we are able to store this and anyone using the home page is 1184.62s - 1190.54s | going to be affected and is going to re is going to retrieve the malicious response. The 1190.54s - 1195.64s | problem with this attack is that in many cases we will find eh an example of a cache 1195.64s - 1200.38s | poisoning but is with a is using a key or is using a resource that is not going to be 1200.40s - 1204.90s | accessed by anyone. Like for instance if we are able to poison something that starts with 1204.90s - 1211.04s | files then our username and then our unique ID no one is going to be accessing that eh that 1211.04s - 1216.04s | path by themself so we will need user interaction. And that's not really cool. So to avoid 1218.88s - 1224.16s | having to interact with any victim I designed an attack that is going to be able it's going 1224.18s - 1229.18s | to allow us to change the key of the eh poison resource. Now in this case we will need key 1231.44s - 1237.12s | normalization and this is by default in impaired but Azure is just normalizing the key eh and 1237.12s - 1243.16s | it's partially by default also in Akamai and it's configured in all the other CDNs and what's 1243.16s - 1247.60s | really interesting about this is that if you remember CloudFront for instance was 1247.60s - 1251.86s | normalizing the rules but is not normalizing the key. So that means that they have different 1251.86s - 1257.14s | parsers for each of these processes which is even in the same eh in the same HTTP parser 1257.14s - 1263.42s | probably. So this this tell us that we can even find other desynchronization attacks or 1263.42s - 1268.42s | other discrepancies even in the same eh in the same web cache. So


chunk_id: 211_chunk_24
chunk_text:
path by themself so we will need user interaction. And that's not really cool. So to avoid 1218.88s - 1224.16s | having to interact with any victim I designed an attack that is going to be able it's going 1224.18s - 1229.18s | to allow us to change the key of the eh poison resource. Now in this case we will need key 1231.44s - 1237.12s | normalization and this is by default in impaired but Azure is just normalizing the key eh and 1237.12s - 1243.16s | it's partially by default also in Akamai and it's configured in all the other CDNs and what's 1243.16s - 1247.60s | really interesting about this is that if you remember CloudFront for instance was 1247.60s - 1251.86s | normalizing the rules but is not normalizing the key. So that means that they have different 1251.86s - 1257.14s | parsers for each of these processes which is even in the same eh in the same HTTP parser 1257.14s - 1263.42s | probably. So this this tell us that we can even find other desynchronization attacks or 1263.42s - 1268.42s | other discrepancies even in the same eh in the same web cache. So as I said what we need is 1271.76s - 1277.06s | a a front end that is normalizing the key and what we can do to detect this is to send a 1277.10s - 1281.94s | request to a static resource like style.css and whenever we see evidence that this is of 1281.94s - 1288.30s | being obtained from the web cache so for instance we have an X cache hit value eh hitter or we 1288.30s - 1293.98s | can just compare the time of the response and whenever we find this then we need to modify the 1293.98s - 1300.48s | path so that when normalized we still have style.css and if we send this request and the 1300.48s - 1304.66s | response is still from the cache then it means that the key was normalized and so we 1304.66s - 1311.70s | detected key normalization. And how we can exploit eh web cache poisoning with this? Well 1311.70s - 1316.88s | basically we will try to modify as I said the key by sending first the exploit that we want 1316.88s - 1322.78s | so this is the the the response that we will we will use


chunk_id: 211_chunk_25
chunk_text:
as I said what we need is 1271.76s - 1277.06s | a a front end that is normalizing the key and what we can do to detect this is to send a 1277.10s - 1281.94s | request to a static resource like style.css and whenever we see evidence that this is of 1281.94s - 1288.30s | being obtained from the web cache so for instance we have an X cache hit value eh hitter or we 1288.30s - 1293.98s | can just compare the time of the response and whenever we find this then we need to modify the 1293.98s - 1300.48s | path so that when normalized we still have style.css and if we send this request and the 1300.48s - 1304.66s | response is still from the cache then it means that the key was normalized and so we 1304.66s - 1311.70s | detected key normalization. And how we can exploit eh web cache poisoning with this? Well 1311.70s - 1316.88s | basically we will try to modify as I said the key by sending first the exploit that we want 1316.88s - 1322.78s | so this is the the the response that we will we will use to poison eh usually contains a 1322.78s - 1328.48s | malicious payload then a delimiter so again we will need a delimiter in the back end but as I 1328.48s - 1334.22s | said this is really common and we can find them almost anywhere and then we will need 1334.26s - 1339.86s | some normalization in the front end so Imperva, Azure uh and sometimes Akamai and all the 1339.86s - 1345.10s | others that are configured eh and this is going to be resolved with Poison so basically the 1345.10s - 1349.80s | web cache is going to store the exploit response in the Poison endpoint which is something 1349.80s - 1360.13s | we control so it's arbitrary we can just wire up a path we want usually the home page. So in 1360.13s - 1364.41s | the in the first example I didn't talk w- about one of the delimiters because we weren't 1364.41s - 1369.55s | able to send it with web cache deception and that's because the user needs to send it 1369.55s - 1374.95s | through his browser and anything but uh and if the browser sees a hash then it's not going to


chunk_id: 211_chunk_26
chunk_text:
to poison eh usually contains a 1322.78s - 1328.48s | malicious payload then a delimiter so again we will need a delimiter in the back end but as I 1328.48s - 1334.22s | said this is really common and we can find them almost anywhere and then we will need 1334.26s - 1339.86s | some normalization in the front end so Imperva, Azure uh and sometimes Akamai and all the 1339.86s - 1345.10s | others that are configured eh and this is going to be resolved with Poison so basically the 1345.10s - 1349.80s | web cache is going to store the exploit response in the Poison endpoint which is something 1349.80s - 1360.13s | we control so it's arbitrary we can just wire up a path we want usually the home page. So in 1360.13s - 1364.41s | the in the first example I didn't talk w- about one of the delimiters because we weren't 1364.41s - 1369.55s | able to send it with web cache deception and that's because the user needs to send it 1369.55s - 1374.95s | through his browser and anything but uh and if the browser sees a hash then it's not going to 1374.95s - 1381.63s | send the fragment but in web cache poisoning we can use the fragment. So I I started 1381.63s - 1386.19s | looking at different at the behavior of different CDNs and HTTP servers and even 1386.19s - 1393.01s | frameworks in regarding the the hash and I found that there were a lot of differences. The 1393.01s - 1397.41s | most interesting one was again Imperva because they were no likes in the key. Eh Cloud 1397.41s - 1402.09s | Front well sorry Cloud Front can be configured to to do the same thing so it's interesting to 1402.09s - 1407.09s | see they are too. And basically if we have a hash and eh and key normalization then we can 1409.59s - 1414.37s | use Imperva for for this exploit that I'm going to show. And in the back end we can use 1414.37s - 1419.63s | pretty much any HTTP server like NGINX, Unicorn, Puma then we can use also frameworks like 1419.63s - 1425.73s | Rails, Flash, Laravel they are not going to see the hash as a delimiter. Sorry they are 1425.73s - 1431.27s | going to see the hash as a


chunk_id: 211_chunk_27
chunk_text:
1374.95s - 1381.63s | send the fragment but in web cache poisoning we can use the fragment. So I I started 1381.63s - 1386.19s | looking at different at the behavior of different CDNs and HTTP servers and even 1386.19s - 1393.01s | frameworks in regarding the the hash and I found that there were a lot of differences. The 1393.01s - 1397.41s | most interesting one was again Imperva because they were no likes in the key. Eh Cloud 1397.41s - 1402.09s | Front well sorry Cloud Front can be configured to to do the same thing so it's interesting to 1402.09s - 1407.09s | see they are too. And basically if we have a hash and eh and key normalization then we can 1409.59s - 1414.37s | use Imperva for for this exploit that I'm going to show. And in the back end we can use 1414.37s - 1419.63s | pretty much any HTTP server like NGINX, Unicorn, Puma then we can use also frameworks like 1419.63s - 1425.73s | Rails, Flash, Laravel they are not going to see the hash as a delimiter. Sorry they are 1425.73s - 1431.27s | going to see the hash as a delimiter. Eh so basically we can send an attack that uses the 1431.27s - 1435.45s | hash. First we are going to send what we want to be interpreted in the back end because it's 1435.45s - 1441.85s | going to be using the hash and so if we send something like this then the XSS is going to be 1441.85s - 1446.09s | interpreted as the path in the back end. It's going to retrieve retrieve the response the 1446.09s - 1451.29s | malicious response and now this is going to be normalized the key so we will be able to 1451.29s - 1456.29s | poison the home page with any any web cache poisoning eh payload that we have. This was 1458.63s - 1464.77s | found in Vista, Mastercard and T-Mobile and again many others that I'm still unable to 1464.77s - 1469.77s | talk about. And of course we can use the same attack for with eh Azure and Imperva and also 1470.17s - 1475.17s | with Tomcat, with Rails, with NGINX, with a new line encoded and also again with any back end 1481.37s - 1486.71s | that is using a special mapping. So it should


chunk_id: 211_chunk_28
chunk_text:
delimiter. Eh so basically we can send an attack that uses the 1431.27s - 1435.45s | hash. First we are going to send what we want to be interpreted in the back end because it's 1435.45s - 1441.85s | going to be using the hash and so if we send something like this then the XSS is going to be 1441.85s - 1446.09s | interpreted as the path in the back end. It's going to retrieve retrieve the response the 1446.09s - 1451.29s | malicious response and now this is going to be normalized the key so we will be able to 1451.29s - 1456.29s | poison the home page with any any web cache poisoning eh payload that we have. This was 1458.63s - 1464.77s | found in Vista, Mastercard and T-Mobile and again many others that I'm still unable to 1464.77s - 1469.77s | talk about. And of course we can use the same attack for with eh Azure and Imperva and also 1470.17s - 1475.17s | with Tomcat, with Rails, with NGINX, with a new line encoded and also again with any back end 1481.37s - 1486.71s | that is using a special mapping. So it should be pretty easy and I already saw many people 1486.71s - 1491.75s | exploiting this eh since I give this talk in black hat so it seems like there are a lot of 1491.75s - 1498.05s | targets. Now we can do similar a similar thing with Azure only in this case Azure is 1498.07s - 1505.07s | considering the front the hash as a delimiter and this is not the case for OpenLaySpeed, 1505.07s - 1511.69s | Express and Django. So what we are going to do is we're going to send a payload that in this 1511.69s - 1517.39s | case starts with what we want to poison so the keys the beginning and that's because the 1517.39s - 1522.59s | front end is using the hash as a delimiter then the rest is going to be normalized and we 1522.61s - 1527.61s | have the exploit. And again we can poison any path we want that is using Azure and OpenLight 1529.77s - 1534.65s | or other frameworks there are other examples but as I in this research I wasn't able to look 1534.65s - 1539.65s | for all all servers but yeah. And this was found


chunk_id: 211_chunk_29
chunk_text:
be pretty easy and I already saw many people 1486.71s - 1491.75s | exploiting this eh since I give this talk in black hat so it seems like there are a lot of 1491.75s - 1498.05s | targets. Now we can do similar a similar thing with Azure only in this case Azure is 1498.07s - 1505.07s | considering the front the hash as a delimiter and this is not the case for OpenLaySpeed, 1505.07s - 1511.69s | Express and Django. So what we are going to do is we're going to send a payload that in this 1511.69s - 1517.39s | case starts with what we want to poison so the keys the beginning and that's because the 1517.39s - 1522.59s | front end is using the hash as a delimiter then the rest is going to be normalized and we 1522.61s - 1527.61s | have the exploit. And again we can poison any path we want that is using Azure and OpenLight 1529.77s - 1534.65s | or other frameworks there are other examples but as I in this research I wasn't able to look 1534.65s - 1539.65s | for all all servers but yeah. And this was found again in OpenAI so yeah they they acted 1543.19s - 1547.29s | really fast and they fixed the issue which I'm not sure really sure how they fixed because 1547.29s - 1555.77s | it's still there. Eh and so what if we don't have a payload so let's say we don't have 1555.77s - 1561.37s | anything that we can use to poison a malicious response we only we are only able to change 1561.37s - 1567.55s | the keys well we still can do something we can start poisoning all the paths with a static 1567.55s - 1573.75s | file. So let's say we use styles.css this will poison every single path and so when a user 1573.79s - 1579.23s | sends a request to home my account or any other path he will just get CSS and therefore a 1579.23s - 1586.66s | denial of service. Which many companies think that this is not a vulnerability. So sorry so 1588.60s - 1594.06s | we already saw how we can poison anything we want and how we can change the keys so it's just 1594.06s - 1600.68s | combining those ideas to create a very useful payload. And the


chunk_id: 211_chunk_30
chunk_text:
again in OpenAI so yeah they they acted 1543.19s - 1547.29s | really fast and they fixed the issue which I'm not sure really sure how they fixed because 1547.29s - 1555.77s | it's still there. Eh and so what if we don't have a payload so let's say we don't have 1555.77s - 1561.37s | anything that we can use to poison a malicious response we only we are only able to change 1561.37s - 1567.55s | the keys well we still can do something we can start poisoning all the paths with a static 1567.55s - 1573.75s | file. So let's say we use styles.css this will poison every single path and so when a user 1573.79s - 1579.23s | sends a request to home my account or any other path he will just get CSS and therefore a 1579.23s - 1586.66s | denial of service. Which many companies think that this is not a vulnerability. So sorry so 1588.60s - 1594.06s | we already saw how we can poison anything we want and how we can change the keys so it's just 1594.06s - 1600.68s | combining those ideas to create a very useful payload. And the first thing we need to do to 1600.68s - 1605.54s | store everything anything we want in anywhere is to identify a malicious response that we 1605.54s - 1610.98s | want to use. And this malicious response the the what's interesting about this attack is 1610.98s - 1616.04s | that we are going to combine both so the response doesn't need to be eh cacheable. So we 1616.04s - 1620.22s | can use anything we want in this case we are going to use an open redirect which is not 1620.22s - 1624.52s | stored which is not cacheable and therefore it's it's not a vulnerability you can't report 1624.52s - 1630.20s | this to anyone because it's really not a vulnerability. Then we need to choose what we are 1630.20s - 1635.80s | going to poison and what I usually recommend is to poison some script that is being 1635.80s - 1640.44s | included in uh in any web page usually the home page so in this case we have a home page 1640.44s - 1645.94s | that is eh loading a main dot JS script. So we are going to poison that with a open 1645.94s - 1651.82s


chunk_id: 211_chunk_31
chunk_text:
first thing we need to do to 1600.68s - 1605.54s | store everything anything we want in anywhere is to identify a malicious response that we 1605.54s - 1610.98s | want to use. And this malicious response the the what's interesting about this attack is 1610.98s - 1616.04s | that we are going to combine both so the response doesn't need to be eh cacheable. So we 1616.04s - 1620.22s | can use anything we want in this case we are going to use an open redirect which is not 1620.22s - 1624.52s | stored which is not cacheable and therefore it's it's not a vulnerability you can't report 1624.52s - 1630.20s | this to anyone because it's really not a vulnerability. Then we need to choose what we are 1630.20s - 1635.80s | going to poison and what I usually recommend is to poison some script that is being 1635.80s - 1640.44s | included in uh in any web page usually the home page so in this case we have a home page 1640.44s - 1645.94s | that is eh loading a main dot JS script. So we are going to poison that with a open 1645.94s - 1651.82s | redirect. Why? Well because first as I said we are going to use this technique in this in this 1651.82s - 1657.16s | example this demo I'm going to show it using Azure and Tomcat I finished coding this this 1657.16s - 1663.16s | morning so it could work it could not work but eh the thing is if we send something that 1663.16s - 1667.80s | starts with in this case logout which is the open redirect then the semicolon which is the 1667.80s - 1672.44s | delimiter this is going to be interpreted as logout using the x forwarded host header which 1672.44s - 1677.44s | is going to sh- to to show to send the the victim to the evil dot com. And then this is 1679.90s - 1684.92s | going to be normalized so we are going to poison main dot JS and this is because it has a 1684.94s - 1690.12s | static extension so even if the operator wasn't storable by default well we have the static 1690.12s - 1695.82s | extension so we are able to poison main dot JS using this attack. Now when a user loads the 1695.82s - 1702.42s


chunk_id: 211_chunk_32
chunk_text:
| redirect. Why? Well because first as I said we are going to use this technique in this in this 1651.82s - 1657.16s | example this demo I'm going to show it using Azure and Tomcat I finished coding this this 1657.16s - 1663.16s | morning so it could work it could not work but eh the thing is if we send something that 1663.16s - 1667.80s | starts with in this case logout which is the open redirect then the semicolon which is the 1667.80s - 1672.44s | delimiter this is going to be interpreted as logout using the x forwarded host header which 1672.44s - 1677.44s | is going to sh- to to show to send the the victim to the evil dot com. And then this is 1679.90s - 1684.92s | going to be normalized so we are going to poison main dot JS and this is because it has a 1684.94s - 1690.12s | static extension so even if the operator wasn't storable by default well we have the static 1690.12s - 1695.82s | extension so we are able to poison main dot JS using this attack. Now when a user loads the 1695.82s - 1702.42s | home page he will again load the main dot JS script and when this request is eh is received 1702.42s - 1708.80s | by the by Azure he will just send the open redirect which will redirect the victim to the 1708.82s - 1715.56s | evil dot com server will load the malicious JavaScript and we will be able to poison any any 1715.56s - 1721.54s | victim with a malicious script that we completely control. And if we have the content security 1721.54s - 1726.84s | policy enabled to provide to avoid this kind of attacks then we can use something like CSX 1726.84s - 1731.84s | exfiltration to obtain anything we want you can ask Gareth about that he knows a lot. And so 1732.56s - 1742.49s | yeah this is the demo. Eh so yeah so this is the web page. This is using Azure right now and 1749.17s - 1754.17s | maybe this is yeah this is loading perfect. Internet. Eh so when we send a request to the 1756.51s - 1761.51s | home page which is caches cache all Azure blah blah. Don't hack it right now please. Eh yeah 1762.23s - 1767.23s |


chunk_id: 211_chunk_33
chunk_text:
| home page he will again load the main dot JS script and when this request is eh is received 1702.42s - 1708.80s | by the by Azure he will just send the open redirect which will redirect the victim to the 1708.82s - 1715.56s | evil dot com server will load the malicious JavaScript and we will be able to poison any any 1715.56s - 1721.54s | victim with a malicious script that we completely control. And if we have the content security 1721.54s - 1726.84s | policy enabled to provide to avoid this kind of attacks then we can use something like CSX 1726.84s - 1731.84s | exfiltration to obtain anything we want you can ask Gareth about that he knows a lot. And so 1732.56s - 1742.49s | yeah this is the demo. Eh so yeah so this is the web page. This is using Azure right now and 1749.17s - 1754.17s | maybe this is yeah this is loading perfect. Internet. Eh so when we send a request to the 1756.51s - 1761.51s | home page which is caches cache all Azure blah blah. Don't hack it right now please. Eh yeah 1762.23s - 1767.23s | so we see that the main dot JS is being imported so that's what we want to attack. This is 1772.95s - 1780.32s | main dot JS. Main dot JS is being obtained from the cache right now so it's going to last 1783.86s - 1787.80s | twenty seconds. I said twenty seconds probably is going to in a real application is going to 1787.80s - 1792.90s | be a day or maybe some days so you will need to wait for that to stop doing you can just use 1792.92s - 1799.72s | uh an intruder session. Now this is the open redirect that we are going to use. This is the 1799.72s - 1808.84s | evil dot com. And as you can see this is being this is an open redirect that is not being 1808.84s - 1813.84s | cacheable. Config no cache means no cacheable. This is the evil dot com server that is going 1816.56s - 1823.56s | to load our arbitrary JavaScript. And this is the exploit. Now I'm going to try to code it 1823.56s - 1829.14s | by myself. So again the exploit is going to work like this. First we put the


chunk_id: 211_chunk_34
chunk_text:
so we see that the main dot JS is being imported so that's what we want to attack. This is 1772.95s - 1780.32s | main dot JS. Main dot JS is being obtained from the cache right now so it's going to last 1783.86s - 1787.80s | twenty seconds. I said twenty seconds probably is going to in a real application is going to 1787.80s - 1792.90s | be a day or maybe some days so you will need to wait for that to stop doing you can just use 1792.92s - 1799.72s | uh an intruder session. Now this is the open redirect that we are going to use. This is the 1799.72s - 1808.84s | evil dot com. And as you can see this is being this is an open redirect that is not being 1808.84s - 1813.84s | cacheable. Config no cache means no cacheable. This is the evil dot com server that is going 1816.56s - 1823.56s | to load our arbitrary JavaScript. And this is the exploit. Now I'm going to try to code it 1823.56s - 1829.14s | by myself. So again the exploit is going to work like this. First we put the thing that we 1829.14s - 1834.14s | want to to log so this is going to be used in the backend. Log out. Log out is the open 1836.18s - 1841.18s | redirect. Then the semicolon to um to use as a delimiter. Now because the way that Java 1844.38s - 1850.26s | use semicolons is eh is a semicolons only work for a segment so we cannot put a slash after 1850.26s - 1854.56s | the semicolon because it's not going to be it's not going to work. So we need to send the 1854.56s - 1861.64s | slashes and everything encoded in this case. So this is a slash encoded. This is a dot 1861.64s - 1871.08s | encoded. Yeah the dot en- the dot segment encoded. And then we will put what we want to 1871.08s - 1879.60s | poison which is main dot js. And it seems we are lucky enough. Yeah. So first as you if you 1880.60s - 1885.60s | observe the first time we got a miss so nothing there. Now we got a hit so it seems it worked. 1890.24s - 1896.22s | So if we load if we try to get


chunk_id: 211_chunk_35
chunk_text:
thing that we 1829.14s - 1834.14s | want to to log so this is going to be used in the backend. Log out. Log out is the open 1836.18s - 1841.18s | redirect. Then the semicolon to um to use as a delimiter. Now because the way that Java 1844.38s - 1850.26s | use semicolons is eh is a semicolons only work for a segment so we cannot put a slash after 1850.26s - 1854.56s | the semicolon because it's not going to be it's not going to work. So we need to send the 1854.56s - 1861.64s | slashes and everything encoded in this case. So this is a slash encoded. This is a dot 1861.64s - 1871.08s | encoded. Yeah the dot en- the dot segment encoded. And then we will put what we want to 1871.08s - 1879.60s | poison which is main dot js. And it seems we are lucky enough. Yeah. So first as you if you 1880.60s - 1885.60s | observe the first time we got a miss so nothing there. Now we got a hit so it seems it worked. 1890.24s - 1896.22s | So if we load if we try to get the main dot js now instead of getting the js that we had we 1896.22s - 1901.22s | have an open redirect. So now if we load let's try let's try it again. The problem is the 1907.25s - 1913.95s | time because yeah so I need to wait the twenty seconds for this to stop being cached. 1919.03s - 1931.76s | Unfortunately. See cached. So as you see I'm getting the main dot js that's because it's 1931.76s - 1937.66s | being resolved the key and I'm getting the restore resource right now. But right now it 1937.66s - 1942.66s | worked. So okay. So now if I go I do this. This is going to do everything that we saw. And 1949.64s - 1965.36s | it's great. I'm running out of battery. Okay so I have time for this secret demo. Okay so we 1980.34s - 1984.98s | already saw how we can use different discrepancies between URL parsers to exploit web 1984.98s - 1989.98s | caches. But there are other kind of discrepancies where you can use and there are many other 1989.98s - 1995.02s | discrepancies that I didn't research on but probably you can look


chunk_id: 211_chunk_36
chunk_text:
the main dot js now instead of getting the js that we had we 1896.22s - 1901.22s | have an open redirect. So now if we load let's try let's try it again. The problem is the 1907.25s - 1913.95s | time because yeah so I need to wait the twenty seconds for this to stop being cached. 1919.03s - 1931.76s | Unfortunately. See cached. So as you see I'm getting the main dot js that's because it's 1931.76s - 1937.66s | being resolved the key and I'm getting the restore resource right now. But right now it 1937.66s - 1942.66s | worked. So okay. So now if I go I do this. This is going to do everything that we saw. And 1949.64s - 1965.36s | it's great. I'm running out of battery. Okay so I have time for this secret demo. Okay so we 1980.34s - 1984.98s | already saw how we can use different discrepancies between URL parsers to exploit web 1984.98s - 1989.98s | caches. But there are other kind of discrepancies where you can use and there are many other 1989.98s - 1995.02s | discrepancies that I didn't research on but probably you can look for them. One of them is 1995.04s - 2000.04s | the HTTP 0.9 smuggling. And basically I trust that most of you already know what HTTP is. The 2002.94s - 2008.82s | basic protocol that we use everyday to communicate in the internet. But and probably you 2008.82s - 2013.82s | already know the really new HTTP 3, the still new HTTP 2, the classic HTTP 1.1 and even 2017.00s - 2022.00s | HTTP 1.0. But maybe you don't know that there's HTTP 0.9. 0.9 is basically a legacy 2022.44s - 2027.44s | protocol that shouldn't be used by anyone unless you are NGINX, Apache, IIS or any other 2031.06s - 2037.42s | HTTP server in the world. And the uh the thing with HTTP 0.9 is that we don't have any 2037.42s - 2042.56s | headers. So no header for requests, no header for responses. And the con- the connections 2042.56s - 2049.00s | are not persisted. Their add responses of course shouldn't be cacheable. So this is a 2049.00s - 2055.24s | basically uh a basic 1.1 request, a HTTP 1.1 request. We send a request to home, we get a 2055.24s - 2060.26s | response, nothing strange.


chunk_id: 211_chunk_37
chunk_text:
for them. One of them is 1995.04s - 2000.04s | the HTTP 0.9 smuggling. And basically I trust that most of you already know what HTTP is. The 2002.94s - 2008.82s | basic protocol that we use everyday to communicate in the internet. But and probably you 2008.82s - 2013.82s | already know the really new HTTP 3, the still new HTTP 2, the classic HTTP 1.1 and even 2017.00s - 2022.00s | HTTP 1.0. But maybe you don't know that there's HTTP 0.9. 0.9 is basically a legacy 2022.44s - 2027.44s | protocol that shouldn't be used by anyone unless you are NGINX, Apache, IIS or any other 2031.06s - 2037.42s | HTTP server in the world. And the uh the thing with HTTP 0.9 is that we don't have any 2037.42s - 2042.56s | headers. So no header for requests, no header for responses. And the con- the connections 2042.56s - 2049.00s | are not persisted. Their add responses of course shouldn't be cacheable. So this is a 2049.00s - 2055.24s | basically uh a basic 1.1 request, a HTTP 1.1 request. We send a request to home, we get a 2055.24s - 2060.26s | response, nothing strange. Now if we remove the HTTP version and we just send get uh the 2062.82s - 2069.82s | and the URL, the entire URL, then we will receive uh 0.9 response if we are targeting NGINX 2069.82s - 2075.40s | as I said, Apache, IIS, Tomcat, any HTTP server basically. You will just get the response 2075.40s - 2081.98s | which is the body. If you send something like this, then still HTTP 0.9. If you send 2081.98s - 2086.98s | something like this, 0.9. And if you send this, 0.9. So why is this interesting at all? Well 2090.08s - 2095.42s | browsers are a little bit smarter than others and they knew that it doesn't make sense to 2095.42s - 2101.86s | keep talking this uh this old protocol so you cannot send a 0.9 request through browsers. So 2101.86s - 2107.40s | most of the attacks are discarded just because of that. But let's see what happen if the 2107.40s - 2111.94s | front end and the back end are not doing the same thing or they don't talk the same 2111.94s - 2116.94s | protocol. So if we send a request like a HTTP 0.9 request


chunk_id: 211_chunk_38
chunk_text:
Now if we remove the HTTP version and we just send get uh the 2062.82s - 2069.82s | and the URL, the entire URL, then we will receive uh 0.9 response if we are targeting NGINX 2069.82s - 2075.40s | as I said, Apache, IIS, Tomcat, any HTTP server basically. You will just get the response 2075.40s - 2081.98s | which is the body. If you send something like this, then still HTTP 0.9. If you send 2081.98s - 2086.98s | something like this, 0.9. And if you send this, 0.9. So why is this interesting at all? Well 2090.08s - 2095.42s | browsers are a little bit smarter than others and they knew that it doesn't make sense to 2095.42s - 2101.86s | keep talking this uh this old protocol so you cannot send a 0.9 request through browsers. So 2101.86s - 2107.40s | most of the attacks are discarded just because of that. But let's see what happen if the 2107.40s - 2111.94s | front end and the back end are not doing the same thing or they don't talk the same 2111.94s - 2116.94s | protocol. So if we send a request like a HTTP 0.9 request and we send it through uh CDN, 2120.88s - 2125.88s | most CDNs will take this request and they will upgrade it to HTTP 1.1. So then the back 2126.24s - 2131.24s | end will just generate a 1.1 response. The body will be extracted and sorry, the response 2135.78s - 2142.40s | will be actually downgraded and we will just be left with the body. And this works basically 2142.40s - 2149.30s | even if no one should be using 0.9, this works because if the upgrade and downgrading is 2149.30s - 2155.40s | done correctly then this works. And also connections are not persistent so a lot of 2155.42s - 2161.84s | attacks are also discarded because of that. But the interesting thing is that some CDNs such 2161.84s - 2168.14s | as Imperva, they don't verify the HTTP version before forwarding a request. So if we send a 2168.14s - 2173.14s | request, a 0.9 request, Imperva will say well I will just forward it, I don't care. And the 2175.38s - 2180.06s | problem is Imperva is not just going to forward it, it's going to think that this is a 1.1 2180.12s - 2185.12s |


chunk_id: 211_chunk_39
chunk_text:
and we send it through uh CDN, 2120.88s - 2125.88s | most CDNs will take this request and they will upgrade it to HTTP 1.1. So then the back 2126.24s - 2131.24s | end will just generate a 1.1 response. The body will be extracted and sorry, the response 2135.78s - 2142.40s | will be actually downgraded and we will just be left with the body. And this works basically 2142.40s - 2149.30s | even if no one should be using 0.9, this works because if the upgrade and downgrading is 2149.30s - 2155.40s | done correctly then this works. And also connections are not persistent so a lot of 2155.42s - 2161.84s | attacks are also discarded because of that. But the interesting thing is that some CDNs such 2161.84s - 2168.14s | as Imperva, they don't verify the HTTP version before forwarding a request. So if we send a 2168.14s - 2173.14s | request, a 0.9 request, Imperva will say well I will just forward it, I don't care. And the 2175.38s - 2180.06s | problem is Imperva is not just going to forward it, it's going to think that this is a 1.1 2180.12s - 2185.12s | request because Imperva doesn't know about 0.9. And the back end will send a body because it's 2188.02s - 2194.70s | 0.9 and so no headers and now Imperva is going to try to use this as a response and probably 2194.70s - 2199.50s | it's going to fail. And so you are not going to see a lot of valid responses because of the 2199.50s - 2204.18s | parsing. Because when Imperva tries to parse a body of a response that doesn't contain 2204.20s - 2210.78s | valid HTTP headers then this is going to be interpreted as an error. But what if the body does 2210.78s - 2215.78s | have these valid HTTP response headers? So let's say we have uh upload download uh file 2218.72s - 2225.02s | feature or let's say we can control the body of a plain text or let's say we are even able to 2225.02s - 2230.86s | modify the response using byte range or something like that. Then if by any means we are able 2230.88s - 2235.66s | to control the response, then the body of the response no matter what the content type, no 2235.66s - 2245.25s | matter


chunk_id: 211_chunk_40
chunk_text:
request because Imperva doesn't know about 0.9. And the back end will send a body because it's 2188.02s - 2194.70s | 0.9 and so no headers and now Imperva is going to try to use this as a response and probably 2194.70s - 2199.50s | it's going to fail. And so you are not going to see a lot of valid responses because of the 2199.50s - 2204.18s | parsing. Because when Imperva tries to parse a body of a response that doesn't contain 2204.20s - 2210.78s | valid HTTP headers then this is going to be interpreted as an error. But what if the body does 2210.78s - 2215.78s | have these valid HTTP response headers? So let's say we have uh upload download uh file 2218.72s - 2225.02s | feature or let's say we can control the body of a plain text or let's say we are even able to 2225.02s - 2230.86s | modify the response using byte range or something like that. Then if by any means we are able 2230.88s - 2235.66s | to control the response, then the body of the response no matter what the content type, no 2235.66s - 2245.25s | matter anything, then we will be able to use this attack. Again this demo, I hope it works. 2245.25s - 2253.42s | Okay, yeah. So in this super page, web page I created an upload file feature, okay. And in 2258.50s - 2263.52s | this upload file feature we can upload any file we want, in this case an evil file that if you 2264.38s - 2269.38s | want to see it, well it's really really small, but basically it's a response containing a 2272.48s - 2278.38s | script and containing a cache control header, probably you can't see it, but yeah it 2278.38s - 2284.06s | contains a cache control header saying that it should be stored for ten seconds I think. 2284.06s - 2289.06s | Let's put one hundred seconds. And so when I upload this, I will also be able to retrieve it. 2289.08s - 2296.42s | So, it seems like it was uploaded. So let's go back to burp. Okay, so this is the file that I 2305.68s - 2310.02s | uploaded. Okay, let's say we have this upload download feature which is pretty common in 2310.02s - 2318.21s | many applications. And this works, yeah. As


chunk_id: 211_chunk_41
chunk_text:
anything, then we will be able to use this attack. Again this demo, I hope it works. 2245.25s - 2253.42s | Okay, yeah. So in this super page, web page I created an upload file feature, okay. And in 2258.50s - 2263.52s | this upload file feature we can upload any file we want, in this case an evil file that if you 2264.38s - 2269.38s | want to see it, well it's really really small, but basically it's a response containing a 2272.48s - 2278.38s | script and containing a cache control header, probably you can't see it, but yeah it 2278.38s - 2284.06s | contains a cache control header saying that it should be stored for ten seconds I think. 2284.06s - 2289.06s | Let's put one hundred seconds. And so when I upload this, I will also be able to retrieve it. 2289.08s - 2296.42s | So, it seems like it was uploaded. So let's go back to burp. Okay, so this is the file that I 2305.68s - 2310.02s | uploaded. Okay, let's say we have this upload download feature which is pretty common in 2310.02s - 2318.21s | many applications. And this works, yeah. As you can see, I uploaded this file which in the 2318.21s - 2324.75s | body will have a valid HTTP response. Containing headers, containing everything we want. 2324.77s - 2329.77s | Now, if I send an, let's say I send a, an HTTP 0.9 request, which is basically this request 2333.73s - 2342.78s | that doesn't contain any header here. As you can see, Imperva sends, says that it's an error 2342.78s - 2347.28s | because it was trying to load the home page as a 0.9, it was trying to parse the response 2347.28s - 2352.28s | body of the home page as 0.9, failed. Okay. Now, what if we send the same but for this 2352.36s - 2357.36s | response? And as you can see, Imperva thinks that this is a valid response. It's actually 2366.64s - 2371.62s | using the cache control header and it's contain, it's putting everything, it's also including 2371.62s - 2376.62s | his own header so it seems like it's working. So, yeah, we can poison this file. Great. So 2379.22s - 2382.96s | someone that is accessing this file is going to receive this response and is going to be 2383.00s -


chunk_id: 211_chunk_42
chunk_text:
you can see, I uploaded this file which in the 2318.21s - 2324.75s | body will have a valid HTTP response. Containing headers, containing everything we want. 2324.77s - 2329.77s | Now, if I send an, let's say I send a, an HTTP 0.9 request, which is basically this request 2333.73s - 2342.78s | that doesn't contain any header here. As you can see, Imperva sends, says that it's an error 2342.78s - 2347.28s | because it was trying to load the home page as a 0.9, it was trying to parse the response 2347.28s - 2352.28s | body of the home page as 0.9, failed. Okay. Now, what if we send the same but for this 2352.36s - 2357.36s | response? And as you can see, Imperva thinks that this is a valid response. It's actually 2366.64s - 2371.62s | using the cache control header and it's contain, it's putting everything, it's also including 2371.62s - 2376.62s | his own header so it seems like it's working. So, yeah, we can poison this file. Great. So 2379.22s - 2382.96s | someone that is accessing this file is going to receive this response and is going to be 2383.00s - 2388.10s | attacked. Now, not really cool. So we can use something that I just explained which is 2388.10s - 2393.74s | modifying the old cache key. Again, we can use the request to the thing that we want to 2393.74s - 2399.22s | store. Then the hash, in this case we are using Imperva. Imperva doesn't think that the hash 2399.22s - 2404.22s | is a, is a delimiter. Ah, this, sorry, this time we are using Imperva and Nginx. And the, 2406.72s - 2412.56s | then we have a path traversal. I added a few, eh, slashes because it's the way to avoid 2412.56s - 2417.56s | being detected as an attack by, eh, many CDNs. And so, I have this path traversal that 2420.30s - 2425.30s | removes the files, removes the abl file.txt and so basically is the path is going to be 2425.30s - 2431.64s | converted to the home page which is index. And so we are going to poison the index. So if 2431.64s - 2438.08s | we send this, I will have a little bit of luck. Yeah, it seems it's working because the 2438.08s - 2448.78s | second time was obtained


chunk_id: 211_chunk_43
chunk_text:
2388.10s | attacked. Now, not really cool. So we can use something that I just explained which is 2388.10s - 2393.74s | modifying the old cache key. Again, we can use the request to the thing that we want to 2393.74s - 2399.22s | store. Then the hash, in this case we are using Imperva. Imperva doesn't think that the hash 2399.22s - 2404.22s | is a, is a delimiter. Ah, this, sorry, this time we are using Imperva and Nginx. And the, 2406.72s - 2412.56s | then we have a path traversal. I added a few, eh, slashes because it's the way to avoid 2412.56s - 2417.56s | being detected as an attack by, eh, many CDNs. And so, I have this path traversal that 2420.30s - 2425.30s | removes the files, removes the abl file.txt and so basically is the path is going to be 2425.30s - 2431.64s | converted to the home page which is index. And so we are going to poison the index. So if 2431.64s - 2438.08s | we send this, I will have a little bit of luck. Yeah, it seems it's working because the 2438.08s - 2448.78s | second time was obtained from the cache. So now, if I go back to the home page, it's not 2448.78s - 2453.78s | working. Ah, sorry, I was using this. Ah, not good. This was, eh, this was the Azure one. This 2456.32s - 2463.21s | is the Imperva one, fortunately. So if we go to Imperva, arbitrary cache. Okay, so how we 2480.24s - 2486.18s | can defend against these kinds of attacks? Well, first we need to use the, eh, cache 2486.20s - 2491.68s | control heater for web cache deception. So whenever we have a response that we don't want 2491.68s - 2495.92s | to, anyone to store it, then just use private and no store for the web, for the cache 2495.92s - 2501.18s | control heater. But also, eh, I wasn't able to show it in the example but there are many 2501.18s - 2506.26s | CDNs that will override this cache control heater if there's a rule for the path. So 2506.26s - 2511.84s | sometimes the rules for the request have priority and therefore it's important to check if 2511.86s - 2516.50s | this is happening. If this is happening, try to modify this. And if it's


chunk_id: 211_chunk_44
chunk_text:
from the cache. So now, if I go back to the home page, it's not 2448.78s - 2453.78s | working. Ah, sorry, I was using this. Ah, not good. This was, eh, this was the Azure one. This 2456.32s - 2463.21s | is the Imperva one, fortunately. So if we go to Imperva, arbitrary cache. Okay, so how we 2480.24s - 2486.18s | can defend against these kinds of attacks? Well, first we need to use the, eh, cache 2486.20s - 2491.68s | control heater for web cache deception. So whenever we have a response that we don't want 2491.68s - 2495.92s | to, anyone to store it, then just use private and no store for the web, for the cache 2495.92s - 2501.18s | control heater. But also, eh, I wasn't able to show it in the example but there are many 2501.18s - 2506.26s | CDNs that will override this cache control heater if there's a rule for the path. So 2506.26s - 2511.84s | sometimes the rules for the request have priority and therefore it's important to check if 2511.86s - 2516.50s | this is happening. If this is happening, try to modify this. And if it's not possible, then 2516.50s - 2523.40s | try to consider using another CDN. And then, eh, for cache poisoning, well, we can try to 2523.40s - 2528.28s | abort, to disable the key normalization. In some cases it's possible, in some cases not. So 2528.28s - 2533.12s | in those cases, I suggest using the tool that I will provide that will let you know if 2533.12s - 2537.86s | there's any discrepancy between normalization and, eh, delimiters and anything. So this 2537.88s - 2542.62s | will allow you to know if you need to change either your HTTP server or your front end 2542.62s - 2549.62s | server. These are all the references, eh, for the research. I, I use all this information. 2549.62s - 2556.20s | All the other attacks that inspired me. And also in the slide you have the, eh, the links 2556.20s - 2561.00s | for the cache poisoning and cache deception academy topics. We just released the academy 2561.00s - 2567.34s | topic for deception. And also the extension for cache killer which is the, the extension I 2567.36s - 2573.96s | created for, to detect this. It's still in progress. Eh, it should


chunk_id: 211_chunk_45
chunk_text:
not possible, then 2516.50s - 2523.40s | try to consider using another CDN. And then, eh, for cache poisoning, well, we can try to 2523.40s - 2528.28s | abort, to disable the key normalization. In some cases it's possible, in some cases not. So 2528.28s - 2533.12s | in those cases, I suggest using the tool that I will provide that will let you know if 2533.12s - 2537.86s | there's any discrepancy between normalization and, eh, delimiters and anything. So this 2537.88s - 2542.62s | will allow you to know if you need to change either your HTTP server or your front end 2542.62s - 2549.62s | server. These are all the references, eh, for the research. I, I use all this information. 2549.62s - 2556.20s | All the other attacks that inspired me. And also in the slide you have the, eh, the links 2556.20s - 2561.00s | for the cache poisoning and cache deception academy topics. We just released the academy 2561.00s - 2567.34s | topic for deception. And also the extension for cache killer which is the, the extension I 2567.36s - 2573.96s | created for, to detect this. It's still in progress. Eh, it should work but I will, I will 2573.96s - 2579.06s | keep working on, on this, on this tool for the next probably month or two. And the 2579.06s - 2584.70s | takeaways. Basically I showed that we can use any kind of discrepancy we, we find in the, in 2584.70s - 2589.78s | the wild to exploit, eh, different servers using web cache. So web cache poisoning and 2589.78s - 2594.48s | deception, eh, can be used in many, many cases wherever we find these kind of 2594.48s - 2601.02s | discrepancies. Then we can use the exploitation things in many bounties because I found 2601.02s - 2605.76s | that these kind of delimiters are being used in many systems. So I invite you to look for 2605.76s - 2610.56s | them in different bounties and collect them and send me a message to just add you in the list 2610.56s - 2616.90s | of people that are using this. And finally, eh, I found, I showed you a way of changing 2616.90s - 2621.28s | these vulnerabilities but you probably can think of many other ways to combine it with 2621.28s - 2625.62s | different vulnerabilities. Probably to upgrade


chunk_id: 211_chunk_46
chunk_text:
work but I will, I will 2573.96s - 2579.06s | keep working on, on this, on this tool for the next probably month or two. And the 2579.06s - 2584.70s | takeaways. Basically I showed that we can use any kind of discrepancy we, we find in the, in 2584.70s - 2589.78s | the wild to exploit, eh, different servers using web cache. So web cache poisoning and 2589.78s - 2594.48s | deception, eh, can be used in many, many cases wherever we find these kind of 2594.48s - 2601.02s | discrepancies. Then we can use the exploitation things in many bounties because I found 2601.02s - 2605.76s | that these kind of delimiters are being used in many systems. So I invite you to look for 2605.76s - 2610.56s | them in different bounties and collect them and send me a message to just add you in the list 2610.56s - 2616.90s | of people that are using this. And finally, eh, I found, I showed you a way of changing 2616.90s - 2621.28s | these vulnerabilities but you probably can think of many other ways to combine it with 2621.28s - 2625.62s | different vulnerabilities. Probably to upgrade vulnerabilities that are not really 2625.62s - 2631.06s | useful and probably to be, to get better payments in bug bounties so I hope this helps 2631.06s - 2634.56s | everyone. Uh, that's it. Thank you.


chunk_id: 211_chunk_47
chunk_text:
vulnerabilities that are not really 2625.62s - 2631.06s | useful and probably to be, to get better payments in bug bounties so I hope this helps 2631.06s - 2634.56s | everyone. Uh, that's it. Thank you.


chunk_id: 212_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=zH6qbJuqhOM", "title": "DEF CON 32 - Mutual authentication is optional - Xavier Zhang", "description": "Physical access control systems are often exploited in a number of ways. It could be weaknesses found within the credential itself, the antiquated communication protocol, the hardware itself, or the firmware it is running. But more often than not, it is a combination of factors that allow a variety of attacks from multiple dimensions. Some are extremely trivial and require little to no skill to perform, whereas some attacks require a bit more setup and knowledge of how the underlying technology works. We will go into detail on how these systems work, why verifying mutual authentication is important for physical access control systems and the exploits that can be accomplished, as well as ways to mitigate these exploits to make your facility more secure. This talk will include interactive demos involving official HID readers and hardware, proxmark3, and the flipper zero.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 1031, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.14s - 5.14s | This text was transcribed using whisper model: large-v2 All right. Are we ready? So today's talk is called Mutual Authentication is Optional. And 8.48s - 14.08s | it's going to get into how we can uh get past HID I-class SE readers that are enforcing 14.08s - 19.22s | secure credentials. We'll also go over a technical overview of all the other I-class 19.22s - 24.22s | credentials. So who am I? So my name is uh Xavier. And I like all things physical security 25.12s - 30.12s | and I am a RFID researcher. I'm a HID credential enthusiast. I like NFC. So yeah, that's me. 39.56s - 43.70s | So today we're going to cover a few things in our agenda today. We're going to go over 43.70s - 49.14s | cloning, downgrading, emulation, and we're going to get into buildings enforcing secure 49.14s - 54.14s | credentials without one. So we're going to go over a few ways to get an exploit HID I-class 55.04s - 60.04s | credentials to gain unauthorized access into a facility. So we're going to go over four 62.94s - 68.22s | different attacks today in varied degrees of complexity. So the most simple one attack 68.22s - 74.62s | we're going to go over is cloning, which is going to be the least complicated attack. 74.62s - 79.86s |


chunk_id: 212_chunk_1
chunk_text:
going to get into how we can uh get past HID I-class SE readers that are enforcing 14.08s - 19.22s | secure credentials. We'll also go over a technical overview of all the other I-class 19.22s - 24.22s | credentials. So who am I? So my name is uh Xavier. And I like all things physical security 25.12s - 30.12s | and I am a RFID researcher. I'm a HID credential enthusiast. I like NFC. So yeah, that's me. 39.56s - 43.70s | So today we're going to cover a few things in our agenda today. We're going to go over 43.70s - 49.14s | cloning, downgrading, emulation, and we're going to get into buildings enforcing secure 49.14s - 54.14s | credentials without one. So we're going to go over a few ways to get an exploit HID I-class 55.04s - 60.04s | credentials to gain unauthorized access into a facility. So we're going to go over four 62.94s - 68.22s | different attacks today in varied degrees of complexity. So the most simple one attack 68.22s - 74.62s | we're going to go over is cloning, which is going to be the least complicated attack. 74.62s - 79.86s | Most I-class legacy credentials use the standard mas- standard authentication key, which 79.86s - 84.86s | has been a- a- which has been a- obtained in the Heart of Darkness paper in 2010. Now, if 87.56s - 93.40s | you've not read this legendary paper yet, you should go, it's totally worth a read. If the 93.40s - 98.40s | systems are not standard key, those keys can be extracted using a attack called low-class. 102.61s - 107.59s | Overall, these credentials are fairly trivial to make a copy of. It's been, it's it's it's 107.59s - 112.99s | been done for over a decade now, so nothing much to write home about. But we're going to have 112.99s - 119.13s | to cover it anyways. Our next attack we're going to go over is a downgrade attack, where we're 119.13s - 123.17s | going to take a secure credential, we're going to move the uh payload over to a insecure 123.17s - 131.37s | credential. So for example, this would be turning an SE credential into a legacy credential. 131.37s - 137.99s | We're also going to cover emulation today. So what if that downgrade didn't work? We're going


chunk_id: 212_chunk_2
chunk_text:
Most I-class legacy credentials use the standard mas- standard authentication key, which 79.86s - 84.86s | has been a- a- which has been a- obtained in the Heart of Darkness paper in 2010. Now, if 87.56s - 93.40s | you've not read this legendary paper yet, you should go, it's totally worth a read. If the 93.40s - 98.40s | systems are not standard key, those keys can be extracted using a attack called low-class. 102.61s - 107.59s | Overall, these credentials are fairly trivial to make a copy of. It's been, it's it's it's 107.59s - 112.99s | been done for over a decade now, so nothing much to write home about. But we're going to have 112.99s - 119.13s | to cover it anyways. Our next attack we're going to go over is a downgrade attack, where we're 119.13s - 123.17s | going to take a secure credential, we're going to move the uh payload over to a insecure 123.17s - 131.37s | credential. So for example, this would be turning an SE credential into a legacy credential. 131.37s - 137.99s | We're also going to cover emulation today. So what if that downgrade didn't work? We're going 138.01s - 143.51s | to do something by emulating a virtual credential. So this can be done with like ele- electronic 143.51s - 149.99s | tools such as the Proxmark 3 or the Flipper 0. This exploits the HID tra- transitional 149.99s - 156.59s | credentials, also known as SR. And finally, the fun part of today's talk is going to be exploiting 160.03s - 166.97s | the bugs in reader firmware to gain access to facilities that only su- only enforce using a 166.99s - 174.93s | secure credential. So we're going to go over some background tech today, so you guys sort of 174.93s - 179.37s | know what we are talking about. So, you guys are all familiar with physical access control 179.37s - 186.15s | systems, right? You probably interacted with one without thinking twice. There are a ton of 186.15s - 191.15s | those HID Rev-E readers scattered around this convention floor today. Uh, WGAN protocol. That 199.85s - 204.81s | is the signaling protocol between the reader and the controller. Simple signaling protocol 204.81s - 211.19s | over two wires. Really old actually. Developed by John Wiegand in 1975. Still used today in the


chunk_id: 212_chunk_3
chunk_text:
138.01s - 143.51s | to do something by emulating a virtual credential. So this can be done with like ele- electronic 143.51s - 149.99s | tools such as the Proxmark 3 or the Flipper 0. This exploits the HID tra- transitional 149.99s - 156.59s | credentials, also known as SR. And finally, the fun part of today's talk is going to be exploiting 160.03s - 166.97s | the bugs in reader firmware to gain access to facilities that only su- only enforce using a 166.99s - 174.93s | secure credential. So we're going to go over some background tech today, so you guys sort of 174.93s - 179.37s | know what we are talking about. So, you guys are all familiar with physical access control 179.37s - 186.15s | systems, right? You probably interacted with one without thinking twice. There are a ton of 186.15s - 191.15s | those HID Rev-E readers scattered around this convention floor today. Uh, WGAN protocol. That 199.85s - 204.81s | is the signaling protocol between the reader and the controller. Simple signaling protocol 204.81s - 211.19s | over two wires. Really old actually. Developed by John Wiegand in 1975. Still used today in the 211.19s - 216.73s | majority of installations. It is basically just binary data that is being transmitted to the 216.73s - 221.93s | reader, to the door controller. And it is up to the controller to determine access. The reader is 221.93s - 227.27s | just there to read the credential. These are usually padded with a preamble to tell the 227.27s - 234.05s | controller what bit length the uh, the credential is. And also has a uh, checksum to ve- verify 234.05s - 240.82s | the data integrity. You know, access control systems, access control controllers are pretty 240.82s - 247.60s | dumb. They can't tell what type of credential is presented for the most part. So they only read 247.60s - 251.84s | credentials. So in the case of my class, it is going to read any credential that has the same 251.84s - 256.84s | key. And we know that- well the cards have the same key for the most part. This just doesn't 256.84s - 263.98s | cover like special functions such as readers in key rolling or any uh- and they- they're just 263.98s - 271.02s | gonna- it's up to the controller to


chunk_id: 212_chunk_4
chunk_text:
211.19s - 216.73s | majority of installations. It is basically just binary data that is being transmitted to the 216.73s - 221.93s | reader, to the door controller. And it is up to the controller to determine access. The reader is 221.93s - 227.27s | just there to read the credential. These are usually padded with a preamble to tell the 227.27s - 234.05s | controller what bit length the uh, the credential is. And also has a uh, checksum to ve- verify 234.05s - 240.82s | the data integrity. You know, access control systems, access control controllers are pretty 240.82s - 247.60s | dumb. They can't tell what type of credential is presented for the most part. So they only read 247.60s - 251.84s | credentials. So in the case of my class, it is going to read any credential that has the same 251.84s - 256.84s | key. And we know that- well the cards have the same key for the most part. This just doesn't 256.84s - 263.98s | cover like special functions such as readers in key rolling or any uh- and they- they're just 263.98s - 271.02s | gonna- it's up to the controller to determine access. Whether to allow or deny the access. And 271.02s - 276.36s | finally card cloning. That is just gonna be making a physical copy of a credential onto another 276.36s - 282.46s | credential. Just a direct copy. Card emulation would be to make a digital copy of a physical 282.46s - 288.80s | credential. With the- and emulating that with a device like a Proxmark 3 or a Flipper 0. A real 288.80s - 295.76s | world use case for this would be the HID Transitional Credentials called SR, iClass SR. 295.76s - 302.84s | And uh, those have a unique part where these uh, the secure part of the credential, the se- 302.84s - 307.88s | secure identity object is actually s- is actually cryptographically bound to the card's serial 307.88s - 314.48s | number. And since there are no uh, serial number changeable iClass cards, you're unable to make a 314.84s - 321.62s | direct copy. Which means we're going to emulate those. Here are just an overview of all the 321.62s - 326.50s | different uh, HID credential types. Starting with Prox. It's a bit out of scope for today's 326.50s - 333.64s |


chunk_id: 212_chunk_5
chunk_text:
determine access. Whether to allow or deny the access. And 271.02s - 276.36s | finally card cloning. That is just gonna be making a physical copy of a credential onto another 276.36s - 282.46s | credential. Just a direct copy. Card emulation would be to make a digital copy of a physical 282.46s - 288.80s | credential. With the- and emulating that with a device like a Proxmark 3 or a Flipper 0. A real 288.80s - 295.76s | world use case for this would be the HID Transitional Credentials called SR, iClass SR. 295.76s - 302.84s | And uh, those have a unique part where these uh, the secure part of the credential, the se- 302.84s - 307.88s | secure identity object is actually s- is actually cryptographically bound to the card's serial 307.88s - 314.48s | number. And since there are no uh, serial number changeable iClass cards, you're unable to make a 314.84s - 321.62s | direct copy. Which means we're going to emulate those. Here are just an overview of all the 321.62s - 326.50s | different uh, HID credential types. Starting with Prox. It's a bit out of scope for today's 326.50s - 333.64s | topic but we have a reader here anyway. It's a- it's a low frequency credential. And then moving 333.64s - 338.88s | on to the- around 2000 when we have iClass Legacy that first came out. And uh, those were 338.88s - 346.38s | unique because those were actually encrypted with a 64-bit key. These were broken in 2010 by 346.50s - 350.56s | Miloš Maryak during the Heart of Darkness attack. Where two readers were actually 350.56s - 354.64s | destructively attacked in a way to dump the firmware to derive the master identification 354.64s - 363.99s | keys. Going on to around the 2010s we have the uh, we have iClass SE. Also known as SIO 363.99s - 373.94s | Enabled. SIO meaning secure identity object. And SEOS would still be the uh, flagship 373.94s - 382.00s | credential from HID up to today. So we're going to go over a few possible attack vectors. So 382.00s - 388.02s | we're going to go over card only attacks and card and reader attacks. Card only attacks are 388.02s - 392.92s | very simple because it involves one thing. The physical credential itself and that's it. But 392.92s -


chunk_id: 212_chunk_6
chunk_text:
topic but we have a reader here anyway. It's a- it's a low frequency credential. And then moving 333.64s - 338.88s | on to the- around 2000 when we have iClass Legacy that first came out. And uh, those were 338.88s - 346.38s | unique because those were actually encrypted with a 64-bit key. These were broken in 2010 by 346.50s - 350.56s | Miloš Maryak during the Heart of Darkness attack. Where two readers were actually 350.56s - 354.64s | destructively attacked in a way to dump the firmware to derive the master identification 354.64s - 363.99s | keys. Going on to around the 2010s we have the uh, we have iClass SE. Also known as SIO 363.99s - 373.94s | Enabled. SIO meaning secure identity object. And SEOS would still be the uh, flagship 373.94s - 382.00s | credential from HID up to today. So we're going to go over a few possible attack vectors. So 382.00s - 388.02s | we're going to go over card only attacks and card and reader attacks. Card only attacks are 388.02s - 392.92s | very simple because it involves one thing. The physical credential itself and that's it. But 392.92s - 397.66s | you can only do a limited things with um, with just the card. One attack that's possible is 397.66s - 403.86s | just a downgrade to iClass Legacy because they would just send the same PAX payload on a 403.86s - 409.84s | different type of media. You can think of cards as just an encrypted storage device like a USB 409.84s - 414.84s | stick but crappier. Since you can just read the distance from quite a distance in the case of 414.84s - 422.96s | iClass. The power efficiency, simple cryptography and the ISO 15693 protocol all contribute to 422.96s - 432.78s | enhanced read ranges using long range readers. This is when card and reader attacks come in. 432.82s - 438.26s | Card and reader attacks are very fun because you would think the reader on the building is there 438.26s - 445.67s | to secure the, secure the building right? But we're going to use that exact reader that's 445.67s - 450.05s | outside the building and use that to compromise the security of the building which we'll get 450.05s - 461.81s | into a bit later. So how secure are each of these


chunk_id: 212_chunk_7
chunk_text:
397.66s | you can only do a limited things with um, with just the card. One attack that's possible is 397.66s - 403.86s | just a downgrade to iClass Legacy because they would just send the same PAX payload on a 403.86s - 409.84s | different type of media. You can think of cards as just an encrypted storage device like a USB 409.84s - 414.84s | stick but crappier. Since you can just read the distance from quite a distance in the case of 414.84s - 422.96s | iClass. The power efficiency, simple cryptography and the ISO 15693 protocol all contribute to 422.96s - 432.78s | enhanced read ranges using long range readers. This is when card and reader attacks come in. 432.82s - 438.26s | Card and reader attacks are very fun because you would think the reader on the building is there 438.26s - 445.67s | to secure the, secure the building right? But we're going to use that exact reader that's 445.67s - 450.05s | outside the building and use that to compromise the security of the building which we'll get 450.05s - 461.81s | into a bit later. So how secure are each of these HID credentials? So starting with the least 461.81s - 467.69s | secure one that is broken for over a decade now, we have iClass Legacy. The cryptography is 467.69s - 472.93s | completely broken. Keys are leaked. Card's serial number is not relevant in the PAX payload 472.93s - 481.17s | which means cloning is extremely trivial. And elite keys are recoverable by low class attack. 481.17s - 489.51s | PAX payload is easily transferable by copying block six to nine to the, to another card. We 489.51s - 495.41s | have iClass SR which is a transitional credential and the application instruction area on the 495.41s - 502.91s | card is going to tell the reader that it has a secure identity object. This is good for 502.91s - 509.09s | transitioning between uh buildings that have SE secure readers and legacy readers. And these 509.09s - 514.85s | are easily downgradable to iClass Legacy or you can emulate this credential with the correct 514.85s - 523.04s | card serial number for a complete clone. Going to iClass SE, standard key and the key 523.06s - 529.46s | deprivation function are not leaked and the keys are not recoverable


chunk_id: 212_chunk_8
chunk_text:
HID credentials? So starting with the least 461.81s - 467.69s | secure one that is broken for over a decade now, we have iClass Legacy. The cryptography is 467.69s - 472.93s | completely broken. Keys are leaked. Card's serial number is not relevant in the PAX payload 472.93s - 481.17s | which means cloning is extremely trivial. And elite keys are recoverable by low class attack. 481.17s - 489.51s | PAX payload is easily transferable by copying block six to nine to the, to another card. We 489.51s - 495.41s | have iClass SR which is a transitional credential and the application instruction area on the 495.41s - 502.91s | card is going to tell the reader that it has a secure identity object. This is good for 502.91s - 509.09s | transitioning between uh buildings that have SE secure readers and legacy readers. And these 509.09s - 514.85s | are easily downgradable to iClass Legacy or you can emulate this credential with the correct 514.85s - 523.04s | card serial number for a complete clone. Going to iClass SE, standard key and the key 523.06s - 529.46s | deprivation function are not leaked and the keys are not recoverable by low class. Currently 529.46s - 534.48s | we still do not have the master authentication key for SE. These can be standard, elite keyed 534.48s - 539.48s | or custom keyed and these can also be duplicated if it's an open format like uh HID 26 bit and 542.38s - 547.38s | you'll be able to use a HID encoder to uh create another SE card, actually a legit copy because 548.00s - 553.00s | they are freely encodable, it's an open format. These are also downgradable to Legacy or SR and 557.68s - 564.19s | these can also be emulated which we'll get into and it will work on most readers. So we're 564.19s - 568.69s | going to get pa- so how are we going to get past HID readers that are enforcing secure 568.69s - 573.99s | credentials? The first would be a downgrade. So using official HID hardware against their 573.99s - 579.31s | credentials to perform downgrade attacks. So so we're going to use a HID Omni key reader 579.31s - 583.85s | which is the official HID hardware that plugs into a computer, acts like a keyboard and we're 583.85s - 588.85s |


chunk_id: 212_chunk_9
chunk_text:
by low class. Currently 529.46s - 534.48s | we still do not have the master authentication key for SE. These can be standard, elite keyed 534.48s - 539.48s | or custom keyed and these can also be duplicated if it's an open format like uh HID 26 bit and 542.38s - 547.38s | you'll be able to use a HID encoder to uh create another SE card, actually a legit copy because 548.00s - 553.00s | they are freely encodable, it's an open format. These are also downgradable to Legacy or SR and 557.68s - 564.19s | these can also be emulated which we'll get into and it will work on most readers. So we're 564.19s - 568.69s | going to get pa- so how are we going to get past HID readers that are enforcing secure 568.69s - 573.99s | credentials? The first would be a downgrade. So using official HID hardware against their 573.99s - 579.31s | credentials to perform downgrade attacks. So so we're going to use a HID Omni key reader 579.31s - 583.85s | which is the official HID hardware that plugs into a computer, acts like a keyboard and we're 583.85s - 588.85s | just going to configure it to uh spit out the uh payload data along with the commands in the 590.95s - 596.49s | Proxmark 3 to just make another copy without ever typing on the computer. We have a we have a 596.49s - 615.47s | quick demo of this here. And one of the cards is SE and one of the cards is Legacy. We're just 615.47s - 620.75s | going to put the Legacy card on the Proxmark and we're going to read the SE card on the uh HID 620.75s - 628.44s | reader. Types out the command and there you go. The downgrade is done. Like this person said, 641.58s - 645.78s | like the cheapest way isn't even to use the flipper with that add-on board to downgrade the SE 645.78s - 651.46s | cards anymore. You can literally just buy that HID reader on Amazon for about $130, load up 651.46s - 660.15s | that config and it's ready to downgrade any amount of standard keyed SE credentials. So now 660.15s - 665.13s | we're going to get into I-Class SR. We have another way. So we're going to emulate an I-Class 665.13s -


chunk_id: 212_chunk_10
chunk_text:
just going to configure it to uh spit out the uh payload data along with the commands in the 590.95s - 596.49s | Proxmark 3 to just make another copy without ever typing on the computer. We have a we have a 596.49s - 615.47s | quick demo of this here. And one of the cards is SE and one of the cards is Legacy. We're just 615.47s - 620.75s | going to put the Legacy card on the Proxmark and we're going to read the SE card on the uh HID 620.75s - 628.44s | reader. Types out the command and there you go. The downgrade is done. Like this person said, 641.58s - 645.78s | like the cheapest way isn't even to use the flipper with that add-on board to downgrade the SE 645.78s - 651.46s | cards anymore. You can literally just buy that HID reader on Amazon for about $130, load up 651.46s - 660.15s | that config and it's ready to downgrade any amount of standard keyed SE credentials. So now 660.15s - 665.13s | we're going to get into I-Class SR. We have another way. So we're going to emulate an I-Class 665.13s - 670.67s | SR with the correct card serial number and the secure identity object. And to accomplish this 670.67s - 675.13s | we're going to actually need to do something special which is dump the SIO, the secure identity 675.13s - 683.06s | object. So here in this example we're going to get the publicly accessible parts of the card 683.06s - 687.96s | which is the uh the card serial number, the E-Purse and the application instruction area from 687.96s - 692.90s | that I-Class SE card. And uh we're going to populate those values in a dump file and get them 692.90s - 697.90s | ready to emulate. And that those bytes 0006 instructs the reader that hey there is an SIO. 700.14s - 703.74s | We're going to use the reader on the building that's supposed to secure against uh secure the 703.74s - 712.82s | building against uh like attackers to generate a successful challenge to dump the card. So once 712.82s - 717.00s | you have emulated that partial card against that reader you're going to gather a trace. So that's 717.00s - 720.40s | what the reader is uh that's what the reader is


chunk_id: 212_chunk_11
chunk_text:
670.67s | SR with the correct card serial number and the secure identity object. And to accomplish this 670.67s - 675.13s | we're going to actually need to do something special which is dump the SIO, the secure identity 675.13s - 683.06s | object. So here in this example we're going to get the publicly accessible parts of the card 683.06s - 687.96s | which is the uh the card serial number, the E-Purse and the application instruction area from 687.96s - 692.90s | that I-Class SE card. And uh we're going to populate those values in a dump file and get them 692.90s - 697.90s | ready to emulate. And that those bytes 0006 instructs the reader that hey there is an SIO. 700.14s - 703.74s | We're going to use the reader on the building that's supposed to secure against uh secure the 703.74s - 712.82s | building against uh like attackers to generate a successful challenge to dump the card. So once 712.82s - 717.00s | you have emulated that partial card against that reader you're going to gather a trace. So that's 717.00s - 720.40s | what the reader is uh that's what the reader is sending to the card and we're intercepting that 720.40s - 727.40s | data. And we see here where we underline here as that there is a MAC that that we got. A 727.40s - 730.68s | message authentication code and that is what we're going to use to generate a successful 730.68s - 737.94s | challenge to dump that credential. So after we have got gotten that we're going to run that 737.94s - 743.24s | standard uh dump command. And what what you got? The card just puked out all of its secure 743.24s - 748.84s | contents that's supposed to be secure. So manual dumping of that SIO is possible on the 748.86s - 754.44s | Proxmox 3 on the command line. But to build on that recently Eric Betts, Betsy, also 754.44s - 759.40s | implemented NRMAC dumping on the Flipper Zero very recently with a very intuitive workflow. 759.40s - 763.68s | And this allows reading the publicly accessible parts of the card without authentication. 763.68s - 769.96s | Emulating that on the reader and and using that to generate a successful challenge to dump the 769.96s - 776.96s | card. This as a side effect


chunk_id: 212_chunk_12
chunk_text:
sending to the card and we're intercepting that 720.40s - 727.40s | data. And we see here where we underline here as that there is a MAC that that we got. A 727.40s - 730.68s | message authentication code and that is what we're going to use to generate a successful 730.68s - 737.94s | challenge to dump that credential. So after we have got gotten that we're going to run that 737.94s - 743.24s | standard uh dump command. And what what you got? The card just puked out all of its secure 743.24s - 748.84s | contents that's supposed to be secure. So manual dumping of that SIO is possible on the 748.86s - 754.44s | Proxmox 3 on the command line. But to build on that recently Eric Betts, Betsy, also 754.44s - 759.40s | implemented NRMAC dumping on the Flipper Zero very recently with a very intuitive workflow. 759.40s - 763.68s | And this allows reading the publicly accessible parts of the card without authentication. 763.68s - 769.96s | Emulating that on the reader and and using that to generate a successful challenge to dump the 769.96s - 776.96s | card. This as a side effect also allows users of the Flipper Zero who do not have a NARD 777.02s - 783.56s | add-on board or the secure access module to dump the credential. Send it to someone who has 783.56s - 790.56s | that reader and to use that to use that and use that to decrypt the copy and make a logical 790.56s - 796.90s | copy off-site. So we're going to prepare our traditional transitional credential by just 796.90s - 803.08s | transferring those over to the to another card. Like we see here those uh the the blue 803.10s - 808.10s | blocks are transferred under the uh under the legacy payload and there we go we have the SR 810.80s - 822.62s | credential already done. So now we're going to get into the readers that enforce secure 822.62s - 828.96s | credentials. So now we do since we have a full dump of that SE card already we can emulate 828.96s - 833.60s | the high security SIO only secure credential using a bug in reader firmware that was 833.62s - 838.52s | originally discovered by NVX about a year and a half ago and also ported over to the


chunk_id: 212_chunk_13
chunk_text:
also allows users of the Flipper Zero who do not have a NARD 777.02s - 783.56s | add-on board or the secure access module to dump the credential. Send it to someone who has 783.56s - 790.56s | that reader and to use that to use that and use that to decrypt the copy and make a logical 790.56s - 796.90s | copy off-site. So we're going to prepare our traditional transitional credential by just 796.90s - 803.08s | transferring those over to the to another card. Like we see here those uh the the blue 803.10s - 808.10s | blocks are transferred under the uh under the legacy payload and there we go we have the SR 810.80s - 822.62s | credential already done. So now we're going to get into the readers that enforce secure 822.62s - 828.96s | credentials. So now we do since we have a full dump of that SE card already we can emulate 828.96s - 833.60s | the high security SIO only secure credential using a bug in reader firmware that was 833.62s - 838.52s | originally discovered by NVX about a year and a half ago and also ported over to the uh 838.52s - 845.56s | Flipper Zero by editing some code. So these actually work on signal readers revision uh on 845.56s - 852.40s | firmware 10.0 5.6 or older and REV-E readers are still not patched at the moment. And you can 852.40s - 856.20s | also use reader manager to inspect those signal readers without even being close to them 856.20s - 870.70s | and you can verify what firmware they are running. So we can make we can make installations 870.74s - 877.28s | more secure in a few ways. By using a high security key set such as standard two. Elite custom 877.28s - 883.92s | keys for SE installations. Updating firmware. Disabling or disabling all legacy technologies 883.92s - 889.66s | and issuing secure credentials such as SEOS, DESPIRE, mobile credentials. And now we're 889.66s - 894.94s | going to get into some fun stuff. What not to do. Over the years I've seen a lot of terrible 894.94s - 901.64s | installations of secure credentials being issued to clients. Such as this one here. You can 901.64s - 905.96s | see this is a very popular vendor in Canada. They're located in B.C. and


chunk_id: 212_chunk_14
chunk_text:
uh 838.52s - 845.56s | Flipper Zero by editing some code. So these actually work on signal readers revision uh on 845.56s - 852.40s | firmware 10.0 5.6 or older and REV-E readers are still not patched at the moment. And you can 852.40s - 856.20s | also use reader manager to inspect those signal readers without even being close to them 856.20s - 870.70s | and you can verify what firmware they are running. So we can make we can make installations 870.74s - 877.28s | more secure in a few ways. By using a high security key set such as standard two. Elite custom 877.28s - 883.92s | keys for SE installations. Updating firmware. Disabling or disabling all legacy technologies 883.92s - 889.66s | and issuing secure credentials such as SEOS, DESPIRE, mobile credentials. And now we're 889.66s - 894.94s | going to get into some fun stuff. What not to do. Over the years I've seen a lot of terrible 894.94s - 901.64s | installations of secure credentials being issued to clients. Such as this one here. You can 901.64s - 905.96s | see this is a very popular vendor in Canada. They're located in B.C. and they have all the 905.96s - 910.72s | latest signal readers on all their buildings. But um all their readers are pro- all their 910.72s - 914.22s | credentials are programmed the same facility code as laid out in their official documentation 914.22s - 922.05s | that's available publicly online. And what do you know? All the all the legacy technologies 922.05s - 927.05s | are enabled on that reader too. So yeah. You can just they are easily downgradable. And that's 929.69s - 934.85s | not even the worst part. Is that you don't even need the credential to make a copy because 934.85s - 940.13s | since we know that the facility code is the same we can just uh if the numbers aren't rubbed 940.13s - 944.71s | off on the back yet we can just uh take those numbers and just encode another one. And it's 944.71s - 952.08s | gonna work. So given what we know we can literally make a copy of that fob in that picture 952.10s - 957.44s | there. And we can make a logical copy that is gonna work on all of those readers from this 957.44s - 965.16s |


chunk_id: 212_chunk_15
chunk_text:
they have all the 905.96s - 910.72s | latest signal readers on all their buildings. But um all their readers are pro- all their 910.72s - 914.22s | credentials are programmed the same facility code as laid out in their official documentation 914.22s - 922.05s | that's available publicly online. And what do you know? All the all the legacy technologies 922.05s - 927.05s | are enabled on that reader too. So yeah. You can just they are easily downgradable. And that's 929.69s - 934.85s | not even the worst part. Is that you don't even need the credential to make a copy because 934.85s - 940.13s | since we know that the facility code is the same we can just uh if the numbers aren't rubbed 940.13s - 944.71s | off on the back yet we can just uh take those numbers and just encode another one. And it's 944.71s - 952.08s | gonna work. So given what we know we can literally make a copy of that fob in that picture 952.10s - 957.44s | there. And we can make a logical copy that is gonna work on all of those readers from this 957.44s - 965.16s | specific integrator. And that concludes my presentation for today. I want to say I have a 965.16s - 970.16s | special thanks for the uh RFID hacking community. Uh Eric Betts also known as Betsy. Has the uh 972.56s - 977.56s | pretty good documentation on all the uh I-class credentials and how the data is laid out. NBX 977.98s - 982.98s | who discovered, originally discovered the authentication bypass bug which allows 984.06s - 989.06s | working uh allows um working I-class SE emulation. As well as the people class emulation 991.00s - 996.00s | code for the Flipper Zero. Kate or Miss Steel Dev. Genius on all things HID. And have to 999.16s - 1004.18s | thank her for uh taking in my uh HID readers that I have pricked by bad firmware updates. And 1005.04s - 1010.04s | Iceman. And I wouldn't be here without Iceman urging me to do this talk on uh I-class SE 1014.58s - 1021.60s | today. So if you have any questions I'll be at the NFC table in the RF village. And thank you 1024.04s - 1025.04s | for attending.


chunk_id: 212_chunk_16
chunk_text:
specific integrator. And that concludes my presentation for today. I want to say I have a 965.16s - 970.16s | special thanks for the uh RFID hacking community. Uh Eric Betts also known as Betsy. Has the uh 972.56s - 977.56s | pretty good documentation on all the uh I-class credentials and how the data is laid out. NBX 977.98s - 982.98s | who discovered, originally discovered the authentication bypass bug which allows 984.06s - 989.06s | working uh allows um working I-class SE emulation. As well as the people class emulation 991.00s - 996.00s | code for the Flipper Zero. Kate or Miss Steel Dev. Genius on all things HID. And have to 999.16s - 1004.18s | thank her for uh taking in my uh HID readers that I have pricked by bad firmware updates. And 1005.04s - 1010.04s | Iceman. And I wouldn't be here without Iceman urging me to do this talk on uh I-class SE 1014.58s - 1021.60s | today. So if you have any questions I'll be at the NFC table in the RF village. And thank you 1024.04s - 1025.04s | for attending.


chunk_id: 213_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=oAriLYN-5HA", "title": "DEF CON 32 - Exploiting Cloud Provider Vulnerabilities for Initial Access - Nick Frichette", "description": "\"In this talk we will explore vulnerabilities in Amazon Web Services (AWS) products which allowed us to gain access to cloud environments.\n\n\nTraditionally, adversaries have abused misconfigurations and leaked credentials to gain access to AWS workloads. Things like exposed long-lived access keys and exploiting the privileges of virtual machines have allowed adversaries to breach cloud resources. However, these mistakes are on the customer side of the shared responsibility model. In this session, we will cover vulnerabilities in AWS services that have been fixed and that previously allowed us to access cloud resources.\n\n\nWe will start with an exploration of how Identity and Access Management (IAM) roles establish trust with AWS services and cover the mechanisms that prevent an adversary from assuming roles in other AWS accounts. We\u2019ll then demonstrate a vulnerability that bypassed those protections. We\u2019ll cover a real world example of a confused deputy vulnerability we found in AWS AppSync that allowed us to hijack IAM roles in other accounts.\n\n\nNext, we'll highlight potential misconfigurations involving IAM roles leveraging sts:AssumeRoleWithWebIdentity. These misconfigurations cloud permit unauthorized global access to these roles without the need for authentication, affecting services like Amazon Cognito, GitHub Actions, and more.\n\n\nFinally, we\u2019ll cover a vulnerability we found in AWS Amplify that exposed customer IAM roles associated with the service to takeover, allowing anyone the ability to gain a foothold in that victim account. We\u2019ll also discuss how security practitioners can secure their environments, even against a zero-day like one we\u2019ll demonstrate.\n\n\nJoin us to learn how attackers search for and exploit vulnerabilities in AWS services to gain access to cloud environments.\"", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2361, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.40s - 5.90s | This text was transcribed using whisper model: large-v2 Good afternoon DEF CON. Thank you so much for being here. Welcome to my talk on exploiting AWS 5.90s - 11.08s | service vulnerabilities for initial access. My name's Nick Frechette. I'm a security 11.08s - 16.72s | researcher over at Datadog where I specialize in AWS offensive security. So finding ways to 16.72s - 21.48s | more effectively attack AWS environments and then hopefully how do we detect that behavior 21.48s - 26.22s | or potentially prevent it entirely. As a result of that research sometimes I find 26.22s - 30.42s | vulnerabilities in the underlying


chunk_id: 213_chunk_1
chunk_text:
for authentication, affecting services like Amazon Cognito, GitHub Actions, and more.\n\n\nFinally, we\u2019ll cover a vulnerability we found in AWS Amplify that exposed customer IAM roles associated with the service to takeover, allowing anyone the ability to gain a foothold in that victim account. We\u2019ll also discuss how security practitioners can secure their environments, even against a zero-day like one we\u2019ll demonstrate.\n\n\nJoin us to learn how attackers search for and exploit vulnerabilities in AWS services to gain access to cloud environments.\"", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2361, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.40s - 5.90s | This text was transcribed using whisper model: large-v2 Good afternoon DEF CON. Thank you so much for being here. Welcome to my talk on exploiting AWS 5.90s - 11.08s | service vulnerabilities for initial access. My name's Nick Frechette. I'm a security 11.08s - 16.72s | researcher over at Datadog where I specialize in AWS offensive security. So finding ways to 16.72s - 21.48s | more effectively attack AWS environments and then hopefully how do we detect that behavior 21.48s - 26.22s | or potentially prevent it entirely. As a result of that research sometimes I find 26.22s - 30.42s | vulnerabilities in the underlying AWS services. Some of which we're going to be talking 30.42s - 35.72s | about today. Uh in my free time I'm the creator and maintainer of Hacking the Cloud which 35.72s - 40.40s | is an open source encyclopedia of offensive security techniques that you can use in cloud 40.40s - 44.34s | hacking adventures. Uh if you'd like a Hacking the Cloud sticker come find me after. I have 44.34s - 51.18s | quite a few to give away. Now breaking into AWS accounts is a topic that's near and dear 51.18s - 56.82s | to my heart. And I'm sure it is for many of you as well. But I think if we're being honest 56.82s - 61.82s | with ourselves the traditional methods for gaining access to AWS environments are boring. 64.32s - 69.52s | If we were to poll the audience for real world AWS breaches, compromises and other security 69.52s - 75.96s | incidents I guarantee 95 percent of scenarios would fall into one of three categories. They 75.98s - 81.82s | were either caused by a leaked access key, an exposed S3 bucket or an exploited EC2 81.82s - 86.82s | instance. These


chunk_id: 213_chunk_2
chunk_text:
AWS services. Some of which we're going to be talking 30.42s - 35.72s | about today. Uh in my free time I'm the creator and maintainer of Hacking the Cloud which 35.72s - 40.40s | is an open source encyclopedia of offensive security techniques that you can use in cloud 40.40s - 44.34s | hacking adventures. Uh if you'd like a Hacking the Cloud sticker come find me after. I have 44.34s - 51.18s | quite a few to give away. Now breaking into AWS accounts is a topic that's near and dear 51.18s - 56.82s | to my heart. And I'm sure it is for many of you as well. But I think if we're being honest 56.82s - 61.82s | with ourselves the traditional methods for gaining access to AWS environments are boring. 64.32s - 69.52s | If we were to poll the audience for real world AWS breaches, compromises and other security 69.52s - 75.96s | incidents I guarantee 95 percent of scenarios would fall into one of three categories. They 75.98s - 81.82s | were either caused by a leaked access key, an exposed S3 bucket or an exploited EC2 81.82s - 86.82s | instance. These are the stereotypical ways that adversaries gain access to AWS accounts. And 89.30s - 94.90s | to be clear these are very real risks that we do have to contend with but it's nothing you 94.90s - 100.98s | haven't seen before and again these methods are boring. What we're going to be doing instead 100.98s - 105.64s | is kicking it in the door to the cloud and exploiting vulnerabilities in AWS services to get 105.66s - 112.60s | initial access. Particularly by abusing pre-existing trust. What I mean by that is a 112.60s - 118.98s | common design pattern in AWS is to have IAM roles in your account that have a trust 118.98s - 123.98s | relationship back to some AWS service. This enables that service to perform actions and uh do 127.12s - 131.68s | functionality in your account. Today we're going to look at some vulnerabilities that would 131.70s - 136.80s | allow us to hijack that trust relationship and gain access to victim accounts so that from 136.80s - 142.74s | there we can escalate privileges, move laterally, access resources and more. In this session 142.74s - 147.92s | we're going to talk a


chunk_id: 213_chunk_3
chunk_text:
are the stereotypical ways that adversaries gain access to AWS accounts. And 89.30s - 94.90s | to be clear these are very real risks that we do have to contend with but it's nothing you 94.90s - 100.98s | haven't seen before and again these methods are boring. What we're going to be doing instead 100.98s - 105.64s | is kicking it in the door to the cloud and exploiting vulnerabilities in AWS services to get 105.66s - 112.60s | initial access. Particularly by abusing pre-existing trust. What I mean by that is a 112.60s - 118.98s | common design pattern in AWS is to have IAM roles in your account that have a trust 118.98s - 123.98s | relationship back to some AWS service. This enables that service to perform actions and uh do 127.12s - 131.68s | functionality in your account. Today we're going to look at some vulnerabilities that would 131.70s - 136.80s | allow us to hijack that trust relationship and gain access to victim accounts so that from 136.80s - 142.74s | there we can escalate privileges, move laterally, access resources and more. In this session 142.74s - 147.92s | we're going to talk a little bit about how trust is established between IAM roles and AWS 147.92s - 152.86s | services. Then we're going to dive deep on two vulnerabilities as well as a more general 152.86s - 157.52s | misconfiguration that would allow us to take advantage of this. And finally we're going to 157.54s - 163.04s | discuss prevention options. In the absolute worst case scenario of an adversary having a 163.04s - 168.04s | cross-tenant zero day in AWS, what options do we have to try and mitigate some of these 168.04s - 173.18s | attacks? Now it's worth noting that the majority of the vulnerabilities we're going to be 173.18s - 178.48s | talking about today have been remediated by AWS. So think of this more from the perspective 178.48s - 182.96s | of what can we learn from these vulnerabilities that we can apply to better attack or defend 183.00s - 188.80s | cloud environments. To get us started on the topic of abusing pre-existing trust, we should 188.80s - 193.82s | probably talk about how that trust is established. In AWS, every IAM role is going to have a 196.82s - 201.82s | role trust policy. And this


chunk_id: 213_chunk_4
chunk_text:
little bit about how trust is established between IAM roles and AWS 147.92s - 152.86s | services. Then we're going to dive deep on two vulnerabilities as well as a more general 152.86s - 157.52s | misconfiguration that would allow us to take advantage of this. And finally we're going to 157.54s - 163.04s | discuss prevention options. In the absolute worst case scenario of an adversary having a 163.04s - 168.04s | cross-tenant zero day in AWS, what options do we have to try and mitigate some of these 168.04s - 173.18s | attacks? Now it's worth noting that the majority of the vulnerabilities we're going to be 173.18s - 178.48s | talking about today have been remediated by AWS. So think of this more from the perspective 178.48s - 182.96s | of what can we learn from these vulnerabilities that we can apply to better attack or defend 183.00s - 188.80s | cloud environments. To get us started on the topic of abusing pre-existing trust, we should 188.80s - 193.82s | probably talk about how that trust is established. In AWS, every IAM role is going to have a 196.82s - 201.82s | role trust policy. And this policy determines who or what is permitted to assume a role. 204.96s - 211.56s | Trust policies can trust a variety of identities. Users, roles, AWS organizations, uh identity 211.56s - 217.40s | providers and many others. But where I think it's most interesting is when they trust an AWS 217.40s - 223.70s | service itself. What you see here on the slide is the default trust policy that is associated 223.70s - 228.94s | with roles for the Lambda service. If you were to create a Lambda function today, the role 228.94s - 233.66s | that would be created for you would have this very same trust policy. And what it says is 233.66s - 239.32s | that we're going to allow the Lambda service to assume role with web or sorry to assume 239.38s - 246.26s | role. Now the way this works in practice is every time your Lambda function runs, the Lambda 246.26s - 252.46s | service assumes that role in your account and does whatever it is that you want it to do. This 252.46s - 257.90s | behavior introduces some really interesting questions. Since I already said that this is the 257.90s - 264.90s


chunk_id: 213_chunk_5
chunk_text:
policy determines who or what is permitted to assume a role. 204.96s - 211.56s | Trust policies can trust a variety of identities. Users, roles, AWS organizations, uh identity 211.56s - 217.40s | providers and many others. But where I think it's most interesting is when they trust an AWS 217.40s - 223.70s | service itself. What you see here on the slide is the default trust policy that is associated 223.70s - 228.94s | with roles for the Lambda service. If you were to create a Lambda function today, the role 228.94s - 233.66s | that would be created for you would have this very same trust policy. And what it says is 233.66s - 239.32s | that we're going to allow the Lambda service to assume role with web or sorry to assume 239.38s - 246.26s | role. Now the way this works in practice is every time your Lambda function runs, the Lambda 246.26s - 252.46s | service assumes that role in your account and does whatever it is that you want it to do. This 252.46s - 257.90s | behavior introduces some really interesting questions. Since I already said that this is the 257.90s - 264.90s | default policy, theoretically the majority of roles using Lambda would have it. And since the 264.90s - 270.56s | trust policy just says that it trusts Lambda, could I do something a little bit sneaky? Could I 270.56s - 276.10s | create a Lambda function in my account but point to or reference a role in a different AWS 276.10s - 282.14s | account? Preferably one that I don't have legitimate access to. Uh could we cause that Lambda 282.14s - 287.78s | service to assume that role in the victim account and carry out whatever operations would be 287.78s - 292.92s | beneficial to us as adversaries? Well, the good news or bad news depending on your 292.94s - 298.14s | perspective is there is something that stops this. And that's called pass role. Anytime you are 298.14s - 304.68s | providing a role to an AWS service for it to assume it, you're interacting with pass role. One 304.68s - 311.16s | of the core rules of which is that you can only pass a role within your same AWS account. If 311.16s - 315.76s | you try to pass a role outside of it, you get


chunk_id: 213_chunk_6
chunk_text:
| default policy, theoretically the majority of roles using Lambda would have it. And since the 264.90s - 270.56s | trust policy just says that it trusts Lambda, could I do something a little bit sneaky? Could I 270.56s - 276.10s | create a Lambda function in my account but point to or reference a role in a different AWS 276.10s - 282.14s | account? Preferably one that I don't have legitimate access to. Uh could we cause that Lambda 282.14s - 287.78s | service to assume that role in the victim account and carry out whatever operations would be 287.78s - 292.92s | beneficial to us as adversaries? Well, the good news or bad news depending on your 292.94s - 298.14s | perspective is there is something that stops this. And that's called pass role. Anytime you are 298.14s - 304.68s | providing a role to an AWS service for it to assume it, you're interacting with pass role. One 304.68s - 311.16s | of the core rules of which is that you can only pass a role within your same AWS account. If 311.16s - 315.76s | you try to pass a role outside of it, you get the error message, access denied, cross account 315.76s - 321.80s | pass role is not allowed. Now this is a very important security boundary in AWS because 321.82s - 327.22s | without it, theoretically we could just arbitrarily assume role into pretty much any account and 327.22s - 331.66s | access any of the resources associated with it. So this is going to be the goal for the first 331.66s - 336.56s | part of our session today. Finding a vulnerability in the pass role implementation to allow us 336.56s - 343.00s | to weaponize a service against roles that trust it and access resources in victim accounts. 343.00s - 348.50s | So the first vulnerability is a confused deputy vuln in AWS AppSync. If you're not familiar 348.54s - 354.32s | with AppSync, AppSync is a managed GraphQL service offered by AWS. And it allows you to 354.32s - 360.62s | quickly and easily build GraphQL APIs. The way that it works is pretty similar to what I 360.62s - 365.76s | described with Lambda. Where you first create an AppSync API in your account, configure it, set 365.76s - 370.60s | your schema, uh and so on. And


chunk_id: 213_chunk_7
chunk_text:
the error message, access denied, cross account 315.76s - 321.80s | pass role is not allowed. Now this is a very important security boundary in AWS because 321.82s - 327.22s | without it, theoretically we could just arbitrarily assume role into pretty much any account and 327.22s - 331.66s | access any of the resources associated with it. So this is going to be the goal for the first 331.66s - 336.56s | part of our session today. Finding a vulnerability in the pass role implementation to allow us 336.56s - 343.00s | to weaponize a service against roles that trust it and access resources in victim accounts. 343.00s - 348.50s | So the first vulnerability is a confused deputy vuln in AWS AppSync. If you're not familiar 348.54s - 354.32s | with AppSync, AppSync is a managed GraphQL service offered by AWS. And it allows you to 354.32s - 360.62s | quickly and easily build GraphQL APIs. The way that it works is pretty similar to what I 360.62s - 365.76s | described with Lambda. Where you first create an AppSync API in your account, configure it, set 365.76s - 370.60s | your schema, uh and so on. And then as a part of setting your data source, a role will be 370.60s - 376.94s | created for you that by default has a trust policy back to the AppSync service. Then when 376.94s - 382.42s | your AppSync API is run, the AppSync service assumes that role and does whatever that API is 382.42s - 387.48s | supposed to do. And again, if you try to pass a role outside of your account, cross account 387.48s - 393.22s | pass role is not allowed. Now, I recognize this is DefCon and I'm sure many of you are already 393.22s - 397.90s | trying to come up with ways that we can bypass this control. Things like unique encoding 397.90s - 403.54s | schemes, maybe something like HTTP request smuggling or maybe even something more exotic. 403.54s - 408.42s | These are all great ideas and I strongly encourage you to pursue them. But we actually found a 408.42s - 413.42s | much simpler approach to get around this. Through the power of Spongebob memes. See, under 415.92s - 421.52s | normal circumstances, the AWS API is typically case sensitive. And what I mean by that is, if 421.52s


chunk_id: 213_chunk_8
chunk_text:
then as a part of setting your data source, a role will be 370.60s - 376.94s | created for you that by default has a trust policy back to the AppSync service. Then when 376.94s - 382.42s | your AppSync API is run, the AppSync service assumes that role and does whatever that API is 382.42s - 387.48s | supposed to do. And again, if you try to pass a role outside of your account, cross account 387.48s - 393.22s | pass role is not allowed. Now, I recognize this is DefCon and I'm sure many of you are already 393.22s - 397.90s | trying to come up with ways that we can bypass this control. Things like unique encoding 397.90s - 403.54s | schemes, maybe something like HTTP request smuggling or maybe even something more exotic. 403.54s - 408.42s | These are all great ideas and I strongly encourage you to pursue them. But we actually found a 408.42s - 413.42s | much simpler approach to get around this. Through the power of Spongebob memes. See, under 415.92s - 421.52s | normal circumstances, the AWS API is typically case sensitive. And what I mean by that is, if 421.52s - 428.20s | you pass a parameter to the AWS API, it expects it in a very particular casing format. If you 428.20s - 434.00s | don't meet that expectation, you'll get an error. So to demonstrate this with a completely 434.00s - 440.18s | unrelated API, here we're performing secrets manager create secret. And that API expects a 440.18s - 446.54s | name parameter with a capital N. So long as you pass it in that format, 200 OK, everything 446.54s - 453.76s | worked, you created a secret. However, if we were to deviate from that format in any way, in 453.78s - 459.26s | this case we've put it to all uppercase, we try to pass that to the API, it complains. 400 bad 459.26s - 465.30s | requests, member must not be null. The reason for this is, well, we didn't pass the parameter 465.30s - 470.64s | it was looking for. It might be the right alphabetical characters, but it's not the specific 470.64s - 476.64s | one and so it rightfully so throws an error. While this may sound like a fairly obvious thing 476.64s - 481.44s | to point out, the reason it


chunk_id: 213_chunk_9
chunk_text:
- 428.20s | you pass a parameter to the AWS API, it expects it in a very particular casing format. If you 428.20s - 434.00s | don't meet that expectation, you'll get an error. So to demonstrate this with a completely 434.00s - 440.18s | unrelated API, here we're performing secrets manager create secret. And that API expects a 440.18s - 446.54s | name parameter with a capital N. So long as you pass it in that format, 200 OK, everything 446.54s - 453.76s | worked, you created a secret. However, if we were to deviate from that format in any way, in 453.78s - 459.26s | this case we've put it to all uppercase, we try to pass that to the API, it complains. 400 bad 459.26s - 465.30s | requests, member must not be null. The reason for this is, well, we didn't pass the parameter 465.30s - 470.64s | it was looking for. It might be the right alphabetical characters, but it's not the specific 470.64s - 476.64s | one and so it rightfully so throws an error. While this may sound like a fairly obvious thing 476.64s - 481.44s | to point out, the reason it matters is that by comparison, the AppSync API was a bit of an 481.46s - 488.14s | oddity. It was not case sensitive. We could pass arbitrary parameters of mixed casing and 488.14s - 493.28s | the API would take it totally fine. Presumably somewhere on the back end it was normalizing 493.28s - 498.28s | these values in some way. Now, the parameter you would use to pass a role ARN to the AppSync 501.18s - 507.28s | service was called service role ARN. Capital R, capital A. If you try to pass a role outside 507.30s - 513.40s | of your account, once again, cross account pass role is not allowed. But, if we change the 513.40s - 519.04s | casing on that parameter in any way, even on just a single character, in this case we made it 519.04s - 524.72s | all lowercase, and we try to pass a role outside of our account, for some unknown reason, 524.72s - 528.92s | whatever filtering or allow listing or checking that was supposed to occur, either didn't 528.92s - 534.06s | happen at all or completely failed. And so by changing the casing on a parameter, we


chunk_id: 213_chunk_10
chunk_text:
matters is that by comparison, the AppSync API was a bit of an 481.46s - 488.14s | oddity. It was not case sensitive. We could pass arbitrary parameters of mixed casing and 488.14s - 493.28s | the API would take it totally fine. Presumably somewhere on the back end it was normalizing 493.28s - 498.28s | these values in some way. Now, the parameter you would use to pass a role ARN to the AppSync 501.18s - 507.28s | service was called service role ARN. Capital R, capital A. If you try to pass a role outside 507.30s - 513.40s | of your account, once again, cross account pass role is not allowed. But, if we change the 513.40s - 519.04s | casing on that parameter in any way, even on just a single character, in this case we made it 519.04s - 524.72s | all lowercase, and we try to pass a role outside of our account, for some unknown reason, 524.72s - 528.92s | whatever filtering or allow listing or checking that was supposed to occur, either didn't 528.92s - 534.06s | happen at all or completely failed. And so by changing the casing on a parameter, we were 534.08s - 540.84s | able to now arbitrarily specify roles for the AppSync service to try and assume. And so we 540.84s - 547.72s | were able to break a major security boundary in AWS with Spongebob memes. To put this in 547.72s - 553.82s | another, in another context, what this allowed us to do was to target any role that 553.82s - 560.20s | legitimately used the AppSync service in any AWS account. We could now provide that role to 560.20s - 566.24s | the service and arbitrarily assume it and access whatever resources were associated with it. 566.24s - 571.68s | This is an example of a cross service confused epi attack, where a lower privilege entity, in 571.68s - 576.88s | this case us, was able to trick or coerce a higher privilege entity, in this case the 576.88s - 582.46s | AppSync service, to do something on our behalf. In this scenario, that was assuming a role in 582.46s - 587.64s | a victim account. It's really important to stress, the thing that makes this possible, the 587.64s - 593.68s | thing that enables this attack, is that pre-existing trust relationship between those IEM


chunk_id: 213_chunk_11
chunk_text:
were 534.08s - 540.84s | able to now arbitrarily specify roles for the AppSync service to try and assume. And so we 540.84s - 547.72s | were able to break a major security boundary in AWS with Spongebob memes. To put this in 547.72s - 553.82s | another, in another context, what this allowed us to do was to target any role that 553.82s - 560.20s | legitimately used the AppSync service in any AWS account. We could now provide that role to 560.20s - 566.24s | the service and arbitrarily assume it and access whatever resources were associated with it. 566.24s - 571.68s | This is an example of a cross service confused epi attack, where a lower privilege entity, in 571.68s - 576.88s | this case us, was able to trick or coerce a higher privilege entity, in this case the 576.88s - 582.46s | AppSync service, to do something on our behalf. In this scenario, that was assuming a role in 582.46s - 587.64s | a victim account. It's really important to stress, the thing that makes this possible, the 587.64s - 593.68s | thing that enables this attack, is that pre-existing trust relationship between those IEM 593.68s - 599.22s | roles and the AppSync service. Because the roles trust AppSync and because we found a way to 599.22s - 604.12s | weaponize that service against them, this is the path that allows us to assume those roles in 604.12s - 610.36s | victim accounts. Now if you've ever done cross tenant attacks in AWS, you know that assuming a 610.36s - 615.94s | role is only half the battle. From here, we have to actually do something useful. If we were 615.94s - 620.98s | in a scenario where, say we had a vulnerability similar to this, but we were limited to 620.98s - 627.22s | something like S3 list buckets as the only API call we could make, well yeah it's not great, um 627.22s - 631.52s | I wouldn't be very happy of it if I was a defender, but at the end of the day there's very 631.52s - 636.26s | little risk that could be demonstrated there. The good news for us is that in this scenario, 636.26s - 642.14s | the AppSync service is more than happy to provide. In particular, AppSync allows you to run 642.14s - 647.14s | arbitrary


chunk_id: 213_chunk_12
chunk_text:
593.68s - 599.22s | roles and the AppSync service. Because the roles trust AppSync and because we found a way to 599.22s - 604.12s | weaponize that service against them, this is the path that allows us to assume those roles in 604.12s - 610.36s | victim accounts. Now if you've ever done cross tenant attacks in AWS, you know that assuming a 610.36s - 615.94s | role is only half the battle. From here, we have to actually do something useful. If we were 615.94s - 620.98s | in a scenario where, say we had a vulnerability similar to this, but we were limited to 620.98s - 627.22s | something like S3 list buckets as the only API call we could make, well yeah it's not great, um 627.22s - 631.52s | I wouldn't be very happy of it if I was a defender, but at the end of the day there's very 631.52s - 636.26s | little risk that could be demonstrated there. The good news for us is that in this scenario, 636.26s - 642.14s | the AppSync service is more than happy to provide. In particular, AppSync allows you to run 642.14s - 647.14s | arbitrary AWS API calls. So you now have the full spectrum of API calls that you can invoke at 650.54s - 656.82s | your choosing. Now for a step by step practical example of how we'd exploit this, as an 656.82s - 662.32s | attacker we'd create our own AppSync API. Configure it, set the schema, create our data 662.32s - 667.36s | sources and so on. Then we would perform that pass role bypass to specify what role in the 667.36s - 672.86s | victim account we want to assume. And then under normal circumstances, the AppSync service 672.86s - 677.46s | would assume the role in our account. But because of this vulnerability, it now assumes the 677.46s - 683.40s | role in the victim account and carries out whatever API operation we asked it to perform. The 683.40s - 688.04s | neat thing about this, from a attacker's perspective, is if you've ever done pen testing or 688.04s - 692.42s | red teaming in AWS, you know that one of the challenges you have is that you're trying to find 692.42s - 696.18s | credentials with access to things that you care about. And if you can't find


chunk_id: 213_chunk_13
chunk_text:
AWS API calls. So you now have the full spectrum of API calls that you can invoke at 650.54s - 656.82s | your choosing. Now for a step by step practical example of how we'd exploit this, as an 656.82s - 662.32s | attacker we'd create our own AppSync API. Configure it, set the schema, create our data 662.32s - 667.36s | sources and so on. Then we would perform that pass role bypass to specify what role in the 667.36s - 672.86s | victim account we want to assume. And then under normal circumstances, the AppSync service 672.86s - 677.46s | would assume the role in our account. But because of this vulnerability, it now assumes the 677.46s - 683.40s | role in the victim account and carries out whatever API operation we asked it to perform. The 683.40s - 688.04s | neat thing about this, from a attacker's perspective, is if you've ever done pen testing or 688.04s - 692.42s | red teaming in AWS, you know that one of the challenges you have is that you're trying to find 692.42s - 696.18s | credentials with access to things that you care about. And if you can't find them 696.20s - 700.88s | immediately, how can you move laterally, escalate privileges, find other credentials and 700.88s - 706.44s | things like that? Becomes a bit of a hassle. By comparison, with confused deputy attacks, you 706.44s - 712.12s | can just land as the identity of a production application. If there's a production AppSync 712.12s - 718.12s | API, it has privileges to do whatever that service needs to do. Whether that is upload S3, 718.12s - 724.70s | write to DynamoDB, read from RDS or anything else. Because we land as that role, we have 724.72s - 729.46s | access to whatever privileges are associated with it and these tend to be fairly beneficial. 729.46s - 735.10s | So no need for weird bloodhound-esque lateral movement paths, you just pass that role and 735.10s - 739.64s | yow you're in. That's how we can do things like this in this screenshot where we dump the 739.64s - 745.64s | contents of a DynamoDB table, cross tenant in AWS, by asking it to perform the DynamoDB 745.64s - 750.88s | scan operation. If you're interested in this vulnerability and you'd like to learn more, 750.90s - 756.74s |


chunk_id: 213_chunk_14
chunk_text:
them 696.20s - 700.88s | immediately, how can you move laterally, escalate privileges, find other credentials and 700.88s - 706.44s | things like that? Becomes a bit of a hassle. By comparison, with confused deputy attacks, you 706.44s - 712.12s | can just land as the identity of a production application. If there's a production AppSync 712.12s - 718.12s | API, it has privileges to do whatever that service needs to do. Whether that is upload S3, 718.12s - 724.70s | write to DynamoDB, read from RDS or anything else. Because we land as that role, we have 724.72s - 729.46s | access to whatever privileges are associated with it and these tend to be fairly beneficial. 729.46s - 735.10s | So no need for weird bloodhound-esque lateral movement paths, you just pass that role and 735.10s - 739.64s | yow you're in. That's how we can do things like this in this screenshot where we dump the 739.64s - 745.64s | contents of a DynamoDB table, cross tenant in AWS, by asking it to perform the DynamoDB 745.64s - 750.88s | scan operation. If you're interested in this vulnerability and you'd like to learn more, 750.90s - 756.74s | AWS did release a security bulletin for it and in addition we have a blog post with a ton of 756.74s - 761.48s | additional information on conducting confused deputy attacks in AWS and some things to look 761.48s - 766.48s | out for. Um the respective QR codes with the arrows will take you to each of those. Now 768.48s - 772.96s | before we get to our next vulnerability, it's important that we learn a few things about a 772.96s - 779.06s | assume role with web identity. Up until this point, we've been talking about plain assume 779.14s - 785.92s | role, which is typically used for AWS to AWS role assumption. As an example, if you have an 785.92s - 790.98s | AWS account and you would like me to assume a role in that account to do something, we'd 790.98s - 796.86s | probably end up using assume role. Now while this is great, it does have sort of a limitation 796.86s - 803.66s | and that it requires the entity doing the role assumption to originate from AWS. And 803.66s - 807.70s | unfortunately there are a variety of use cases in which you


chunk_id: 213_chunk_15
chunk_text:
AWS did release a security bulletin for it and in addition we have a blog post with a ton of 756.74s - 761.48s | additional information on conducting confused deputy attacks in AWS and some things to look 761.48s - 766.48s | out for. Um the respective QR codes with the arrows will take you to each of those. Now 768.48s - 772.96s | before we get to our next vulnerability, it's important that we learn a few things about a 772.96s - 779.06s | assume role with web identity. Up until this point, we've been talking about plain assume 779.14s - 785.92s | role, which is typically used for AWS to AWS role assumption. As an example, if you have an 785.92s - 790.98s | AWS account and you would like me to assume a role in that account to do something, we'd 790.98s - 796.86s | probably end up using assume role. Now while this is great, it does have sort of a limitation 796.86s - 803.66s | and that it requires the entity doing the role assumption to originate from AWS. And 803.66s - 807.70s | unfortunately there are a variety of use cases in which you might want to have an identity 807.74s - 813.44s | from outside Amazon have the ability to assume role in your account. What do you do? Well 813.44s - 818.08s | that's where assume role with web identity comes in. The core idea here is that you 818.08s - 823.72s | essentially offload the responsibility of authorizing that role assumption onto an identity 823.72s - 828.80s | provider of your choosing. This can be a private identity provider, one that you or your 828.80s - 833.70s | company own and maintain, or it can be a public identity provider. Think things like 833.70s - 840.34s | Facebook, Amazon, Google, GitHub and many others. The sort of core idea here is that your 840.34s - 845.02s | external users, whether they be human or machine, interact with the identity provider to 845.02s - 850.36s | generate a JWT. They pass that into the assume role with web identity call and this enables 850.36s - 855.70s | them to assume a role in your account. Now before we go any further, I really want to stress 855.70s - 861.10s | that assume role with web identity is a general design pattern. A


chunk_id: 213_chunk_16
chunk_text:
might want to have an identity 807.74s - 813.44s | from outside Amazon have the ability to assume role in your account. What do you do? Well 813.44s - 818.08s | that's where assume role with web identity comes in. The core idea here is that you 818.08s - 823.72s | essentially offload the responsibility of authorizing that role assumption onto an identity 823.72s - 828.80s | provider of your choosing. This can be a private identity provider, one that you or your 828.80s - 833.70s | company own and maintain, or it can be a public identity provider. Think things like 833.70s - 840.34s | Facebook, Amazon, Google, GitHub and many others. The sort of core idea here is that your 840.34s - 845.02s | external users, whether they be human or machine, interact with the identity provider to 845.02s - 850.36s | generate a JWT. They pass that into the assume role with web identity call and this enables 850.36s - 855.70s | them to assume a role in your account. Now before we go any further, I really want to stress 855.70s - 861.10s | that assume role with web identity is a general design pattern. A variety of technologies 861.10s - 867.38s | and services, both native to AWS and outside of it, will use this general design pattern. In 867.38s - 872.12s | the next couple slides we're going to use GitHub Actions as an example, just to sort of 872.12s - 875.78s | explain how this works and talk a little bit more about the underpinnings, but I really want 875.78s - 884.80s | to stress, this is not limited to just GitHub Actions. To one common problem with CIC pipelines, 884.80s - 888.50s | particularly if they're outside of your cloud provider, if you're using something like GitHub 888.50s - 894.14s | Actions, well, how do you authenticate to an S3 bucket if you wanted to upload, say, some 894.14s - 898.48s | sort of build artifact or logs or anything else? Well, we could use assume role with web 898.48s - 904.68s | identity. To set this up, we initially create a trust relationship between our AWS account 904.68s - 909.26s | and an identity provider. Since we're already using GitHub Actions, we might as well use 909.26s - 915.96s | GitHub's provided identity provider. Once that trust is established, we then


chunk_id: 213_chunk_17
chunk_text:
variety of technologies 861.10s - 867.38s | and services, both native to AWS and outside of it, will use this general design pattern. In 867.38s - 872.12s | the next couple slides we're going to use GitHub Actions as an example, just to sort of 872.12s - 875.78s | explain how this works and talk a little bit more about the underpinnings, but I really want 875.78s - 884.80s | to stress, this is not limited to just GitHub Actions. To one common problem with CIC pipelines, 884.80s - 888.50s | particularly if they're outside of your cloud provider, if you're using something like GitHub 888.50s - 894.14s | Actions, well, how do you authenticate to an S3 bucket if you wanted to upload, say, some 894.14s - 898.48s | sort of build artifact or logs or anything else? Well, we could use assume role with web 898.48s - 904.68s | identity. To set this up, we initially create a trust relationship between our AWS account 904.68s - 909.26s | and an identity provider. Since we're already using GitHub Actions, we might as well use 909.26s - 915.96s | GitHub's provided identity provider. Once that trust is established, we then create an IEM 915.96s - 921.92s | role. And like I said before, all roles have a role trust policy, and in that policy we 921.92s - 928.10s | specify the identity provider as the entity that's allowed to assume the role. Then every 928.10s - 934.40s | time our Git GitHub Action job runs, it will retrieve a JWT that has been signed by that 934.40s - 939.74s | identity provider, that JWT is passed to an assume role with web identity call, and thus 939.74s - 943.98s | that job at that pipeline is able to assume the role in our account and do whatever it 944.00s - 950.28s | wants to do, whether that is upload something to S3 or call any other API calls. Now, 950.28s - 953.64s | throughout that explanation, you might have noticed something a little bit scary and 953.64s - 958.28s | thought, perhaps I misspoke or maybe I said something wrong. And I assure you, it's just as 958.28s - 964.66s | scary as it sounds. What you see here is the most basic, bare bones, simple trust policy 964.66s - 970.30s | you could possibly write when using assume role


chunk_id: 213_chunk_18
chunk_text:
create an IEM 915.96s - 921.92s | role. And like I said before, all roles have a role trust policy, and in that policy we 921.92s - 928.10s | specify the identity provider as the entity that's allowed to assume the role. Then every 928.10s - 934.40s | time our Git GitHub Action job runs, it will retrieve a JWT that has been signed by that 934.40s - 939.74s | identity provider, that JWT is passed to an assume role with web identity call, and thus 939.74s - 943.98s | that job at that pipeline is able to assume the role in our account and do whatever it 944.00s - 950.28s | wants to do, whether that is upload something to S3 or call any other API calls. Now, 950.28s - 953.64s | throughout that explanation, you might have noticed something a little bit scary and 953.64s - 958.28s | thought, perhaps I misspoke or maybe I said something wrong. And I assure you, it's just as 958.28s - 964.66s | scary as it sounds. What you see here is the most basic, bare bones, simple trust policy 964.66s - 970.30s | you could possibly write when using assume role with web identity. And what it says is that 970.32s - 975.12s | we're going to allow the GitHub identity provider the ability to assume role with web 975.12s - 979.80s | identity. And that's a really scary thought, because if we think about it, GitHub's 979.80s - 985.96s | identity provider is public. It's global. Anybody has access to it. There's nothing 985.96s - 989.88s | stopping someone from creating their own GitHub account, creating their own GitHub 989.88s - 996.48s | Action to generate a JWT signed by that very same provider and passing that into the 996.50s - 1001.90s | assume role with web identity call, allowing them to access those roles in your account. If 1001.90s - 1007.34s | you had this trust policy on a role, anybody with access to a GitHub account could have 1007.34s - 1013.24s | just hijacked it and accessed anything associated with it. That's why anytime you use assume 1013.24s - 1019.48s | role with web identity with a identity provider that is public or global, you need to also 1019.48s - 1025.92s | have a condition which restricts specifically who is allowed to assume that role. Again, 1025.96s -


chunk_id: 213_chunk_19
chunk_text:
with web identity. And what it says is that 970.32s - 975.12s | we're going to allow the GitHub identity provider the ability to assume role with web 975.12s - 979.80s | identity. And that's a really scary thought, because if we think about it, GitHub's 979.80s - 985.96s | identity provider is public. It's global. Anybody has access to it. There's nothing 985.96s - 989.88s | stopping someone from creating their own GitHub account, creating their own GitHub 989.88s - 996.48s | Action to generate a JWT signed by that very same provider and passing that into the 996.50s - 1001.90s | assume role with web identity call, allowing them to access those roles in your account. If 1001.90s - 1007.34s | you had this trust policy on a role, anybody with access to a GitHub account could have 1007.34s - 1013.24s | just hijacked it and accessed anything associated with it. That's why anytime you use assume 1013.24s - 1019.48s | role with web identity with a identity provider that is public or global, you need to also 1019.48s - 1025.92s | have a condition which restricts specifically who is allowed to assume that role. Again, 1025.96s - 1030.50s | assume role with web identity is a general design pattern. The specific condition you'll need 1030.50s - 1035.70s | will differ depending on the service and what specific scenario you're in. Um, to continue 1035.70s - 1041.54s | using GitHub Actions as an example, uh, you need to specify what GitHub repo or what GitHub 1041.54s - 1047.54s | organization is allowed to assume that role. Uh, if you're a heavy AWS user, strongly 1047.54s - 1051.62s | encourage you to audit your roles that use assume role with web identity for this 1051.72s - 1056.56s | misconfiguration, because again, if you make this mistake, theoretically anybody could just 1056.56s - 1063.20s | assume that role in your account, which is not optimal. Um, now the good news to all this is 1063.20s - 1067.50s | this attack that I just described was very much in vogue last year. Number of security 1067.50s - 1071.48s | researchers, including my own colleague Christoph, identified that this was a potential 1071.48s - 1076.08s | issue and raised awareness about it. If you'd like to learn a little bit more about the GitHub 1076.08s - 1080.08s | specific situation, uh, we


chunk_id: 213_chunk_20
chunk_text:
1030.50s | assume role with web identity is a general design pattern. The specific condition you'll need 1030.50s - 1035.70s | will differ depending on the service and what specific scenario you're in. Um, to continue 1035.70s - 1041.54s | using GitHub Actions as an example, uh, you need to specify what GitHub repo or what GitHub 1041.54s - 1047.54s | organization is allowed to assume that role. Uh, if you're a heavy AWS user, strongly 1047.54s - 1051.62s | encourage you to audit your roles that use assume role with web identity for this 1051.72s - 1056.56s | misconfiguration, because again, if you make this mistake, theoretically anybody could just 1056.56s - 1063.20s | assume that role in your account, which is not optimal. Um, now the good news to all this is 1063.20s - 1067.50s | this attack that I just described was very much in vogue last year. Number of security 1067.50s - 1071.48s | researchers, including my own colleague Christoph, identified that this was a potential 1071.48s - 1076.08s | issue and raised awareness about it. If you'd like to learn a little bit more about the GitHub 1076.08s - 1080.08s | specific situation, uh, we have a blog post with a ton of details and that QR code will take 1080.08s - 1085.82s | you there. Uh, now, to AWS's credit, they actually did something about this. In 1085.82s - 1092.12s | particular, they made what was once an optional condition now mandatory. You can no longer 1092.12s - 1097.06s | create a role trust policy for the GitHub identity provider that doesn't include a 1097.06s - 1103.44s | condition. And so, that's good. Kudos to AWS, that's a great change. But, if we were to 1103.44s - 1107.90s | nitpick it, remember, I said assume role with web identity is used all over the place in a 1107.92s - 1113.16s | variety of contexts and they only fixed it specifically to GitHub actions. Any of the other 1113.16s - 1119.00s | technologies or services that have this very same potential misconfiguration were slash are 1119.00s - 1124.34s | still vulnerable. So again, definitely encourage you to audit your roles. There is one such 1124.34s - 1129.18s | service that I'd like to dive a little bit more deeply on, uh, and that is Cognito. Uh, 1129.18s - 1135.52s | Cognito is a sign in


chunk_id: 213_chunk_21
chunk_text:
have a blog post with a ton of details and that QR code will take 1080.08s - 1085.82s | you there. Uh, now, to AWS's credit, they actually did something about this. In 1085.82s - 1092.12s | particular, they made what was once an optional condition now mandatory. You can no longer 1092.12s - 1097.06s | create a role trust policy for the GitHub identity provider that doesn't include a 1097.06s - 1103.44s | condition. And so, that's good. Kudos to AWS, that's a great change. But, if we were to 1103.44s - 1107.90s | nitpick it, remember, I said assume role with web identity is used all over the place in a 1107.92s - 1113.16s | variety of contexts and they only fixed it specifically to GitHub actions. Any of the other 1113.16s - 1119.00s | technologies or services that have this very same potential misconfiguration were slash are 1119.00s - 1124.34s | still vulnerable. So again, definitely encourage you to audit your roles. There is one such 1124.34s - 1129.18s | service that I'd like to dive a little bit more deeply on, uh, and that is Cognito. Uh, 1129.18s - 1135.52s | Cognito is a sign in as a service offering from AWS. If you want to store user credentials 1135.54s - 1140.14s | but you don't want to deal with the hassle of, uh, hashing, salting, password reset flows 1140.14s - 1144.68s | and things like that, you can pay Amazon a fee and they'll take care of that for you. One of 1144.68s - 1150.02s | the core features of Cognito is something called an identity pool. And an identity pool is a 1150.02s - 1155.26s | resource you can create in your account that allows you to distribute short lived IEM 1155.26s - 1162.40s | credentials to your users. So that they can assume roles in your account. As an example, say 1162.42s - 1167.42s | you're building a web application and you want your users to be able to upload content to S3 1167.42s - 1172.22s | or invoke an API gateway using IEM auth, the way you could achieve this is creating a 1172.22s - 1176.56s | Cognito identity pool, allowing your users to interact with it, to generate tokens. They 1176.56s - 1180.40s | would then, uh, through a library in the client, pass that to the assume role with web


chunk_id: 213_chunk_22
chunk_text:
as a service offering from AWS. If you want to store user credentials 1135.54s - 1140.14s | but you don't want to deal with the hassle of, uh, hashing, salting, password reset flows 1140.14s - 1144.68s | and things like that, you can pay Amazon a fee and they'll take care of that for you. One of 1144.68s - 1150.02s | the core features of Cognito is something called an identity pool. And an identity pool is a 1150.02s - 1155.26s | resource you can create in your account that allows you to distribute short lived IEM 1155.26s - 1162.40s | credentials to your users. So that they can assume roles in your account. As an example, say 1162.42s - 1167.42s | you're building a web application and you want your users to be able to upload content to S3 1167.42s - 1172.22s | or invoke an API gateway using IEM auth, the way you could achieve this is creating a 1172.22s - 1176.56s | Cognito identity pool, allowing your users to interact with it, to generate tokens. They 1176.56s - 1180.40s | would then, uh, through a library in the client, pass that to the assume role with web 1180.40s - 1186.70s | identity call and assume the role in your account. The good news about Cognito is that they 1186.70s - 1191.40s | seemingly foresaw the very same attack that occurred with GitHub actions. They do by 1191.40s - 1198.48s | default include a condition to defend against it. Specifically, the condition will restrict 1198.48s - 1204.56s | which identity pool is allowed to assume a role. And this is very important because if the 1204.56s - 1209.56s | trust policy looked like this, anyone in the world would be able to assume that role. And 1209.56s - 1212.90s | we're gonna talk about some reasons why that trust policy might look like this in just a 1212.90s - 1219.20s | little bit. Uh, the way that we can take advantage of it is slightly different than what we 1219.24s - 1224.24s | described with GitHub actions. This is mostly an implementation detail specific to Cognito 1224.24s - 1229.24s | identity pools. Specifically, what we're gonna do is use a, uh, Cognito offload. Offloads 1230.98s - 1235.98s | are essentially like the, uh, essentially the step by step operations, uh, that a user 1238.66s - 1243.42s | would


chunk_id: 213_chunk_23
chunk_text:
1180.40s - 1186.70s | identity call and assume the role in your account. The good news about Cognito is that they 1186.70s - 1191.40s | seemingly foresaw the very same attack that occurred with GitHub actions. They do by 1191.40s - 1198.48s | default include a condition to defend against it. Specifically, the condition will restrict 1198.48s - 1204.56s | which identity pool is allowed to assume a role. And this is very important because if the 1204.56s - 1209.56s | trust policy looked like this, anyone in the world would be able to assume that role. And 1209.56s - 1212.90s | we're gonna talk about some reasons why that trust policy might look like this in just a 1212.90s - 1219.20s | little bit. Uh, the way that we can take advantage of it is slightly different than what we 1219.24s - 1224.24s | described with GitHub actions. This is mostly an implementation detail specific to Cognito 1224.24s - 1229.24s | identity pools. Specifically, what we're gonna do is use a, uh, Cognito offload. Offloads 1230.98s - 1235.98s | are essentially like the, uh, essentially the step by step operations, uh, that a user 1238.66s - 1243.42s | would use to generate those credentials. There are two offloads currently supported. An 1243.42s - 1249.06s | enhanced offload and a basic offload, sometimes referred to as classic. We're gonna 1249.06s - 1254.06s | focus on classic because that allows us to actually specify the role we want to assume 1254.06s - 1259.24s | because the final operation in this chain is assume a role with web identity. Um, the 1259.24s - 1263.20s | specific step by steps are as an attacker, we're gonna create our own Cognito identity 1263.20s - 1268.64s | pool. We're gonna, going to then perform get ID and get open ID tokens to generate that 1268.64s - 1273.68s | JWT. And once we have that JWT, we pass it in an assume role with web identity call and 1273.68s - 1278.32s | this allows us to assume the role in the victim account. So for our purposes, for the 1278.32s - 1283.82s | remainder of this talk, we'll refer to this as the variant one vulnerable trust policy. A 1283.82s - 1288.72s | trust policy tied back to, uh, the Cognito service but not including a condition to 1288.72s - 1294.00s | restrict which identity pool


chunk_id: 213_chunk_24
chunk_text:
use to generate those credentials. There are two offloads currently supported. An 1243.42s - 1249.06s | enhanced offload and a basic offload, sometimes referred to as classic. We're gonna 1249.06s - 1254.06s | focus on classic because that allows us to actually specify the role we want to assume 1254.06s - 1259.24s | because the final operation in this chain is assume a role with web identity. Um, the 1259.24s - 1263.20s | specific step by steps are as an attacker, we're gonna create our own Cognito identity 1263.20s - 1268.64s | pool. We're gonna, going to then perform get ID and get open ID tokens to generate that 1268.64s - 1273.68s | JWT. And once we have that JWT, we pass it in an assume role with web identity call and 1273.68s - 1278.32s | this allows us to assume the role in the victim account. So for our purposes, for the 1278.32s - 1283.82s | remainder of this talk, we'll refer to this as the variant one vulnerable trust policy. A 1283.82s - 1288.72s | trust policy tied back to, uh, the Cognito service but not including a condition to 1288.72s - 1294.00s | restrict which identity pool is allowed to assume it. The reason we call this variant one 1294.00s - 1297.46s | is cause there's a variant two as well. You might have noticed there's actually two 1297.46s - 1303.30s | conditions on the default trust policy associated with roles using Cognito. And this 1303.32s - 1309.12s | condition is the AMR condition or the authentication methods references. And this value can 1309.12s - 1313.24s | be either authenticated or unauthenticated. You might wonder, could we assume a role if 1313.24s - 1317.94s | this condition was set? And it turns out, yeah, absolutely, we totally could. If the value 1317.94s - 1322.28s | was set to unauthenticated, then literally everything I just said works completely the same, 1322.28s - 1327.28s | no changes required. If the value is authenticated, then we do have to jump through some 1327.28s - 1331.52s | extra hoops. In particular, in our attacker controlled account, we have to create a 1331.54s - 1336.74s | Cognito user pool, configure it alongside the identity pool, and then from there, basically 1336.74s - 1342.58s | all the same steps apply with some minor changes. All this condition is doing is checking 1342.58s -


chunk_id: 213_chunk_25
chunk_text:
is allowed to assume it. The reason we call this variant one 1294.00s - 1297.46s | is cause there's a variant two as well. You might have noticed there's actually two 1297.46s - 1303.30s | conditions on the default trust policy associated with roles using Cognito. And this 1303.32s - 1309.12s | condition is the AMR condition or the authentication methods references. And this value can 1309.12s - 1313.24s | be either authenticated or unauthenticated. You might wonder, could we assume a role if 1313.24s - 1317.94s | this condition was set? And it turns out, yeah, absolutely, we totally could. If the value 1317.94s - 1322.28s | was set to unauthenticated, then literally everything I just said works completely the same, 1322.28s - 1327.28s | no changes required. If the value is authenticated, then we do have to jump through some 1327.28s - 1331.52s | extra hoops. In particular, in our attacker controlled account, we have to create a 1331.54s - 1336.74s | Cognito user pool, configure it alongside the identity pool, and then from there, basically 1336.74s - 1342.58s | all the same steps apply with some minor changes. All this condition is doing is checking 1342.58s - 1347.36s | that you are authenticated to an identity pool, not that you are authenticated to a 1347.36s - 1351.76s | specific identity pool. And since we can just create our own identity pool, we can 1351.76s - 1357.04s | configure it however we like, so we can add authentication if we need to. Now, earlier 1357.04s - 1361.10s | you might have noticed that I called this a misconfiguration, and that's because it is. 1361.12s - 1366.06s | The GitHub action stuff, this Cognito stuff, any of the other myriad of services which have 1366.06s - 1371.80s | this very same issue, all of these are misconfigurations, not a vulnerability. Had you 1371.80s - 1376.54s | suffered a breach, compromise, or other security incident as a result of it, well, 1376.54s - 1380.34s | unfortunately that would be your responsibility as a part of the AWS shared responsibility 1380.34s - 1385.08s | model. And so you're probably wondering, well Nick, I was promised a second vulnerability, 1385.08s - 1390.22s | you're calling this a misconfiguration, what gives? Well, uh, this is where things get weird, 1390.24s - 1395.68s | and we dive into our second vulnerability of the day,


chunk_id: 213_chunk_26
chunk_text:
1347.36s | that you are authenticated to an identity pool, not that you are authenticated to a 1347.36s - 1351.76s | specific identity pool. And since we can just create our own identity pool, we can 1351.76s - 1357.04s | configure it however we like, so we can add authentication if we need to. Now, earlier 1357.04s - 1361.10s | you might have noticed that I called this a misconfiguration, and that's because it is. 1361.12s - 1366.06s | The GitHub action stuff, this Cognito stuff, any of the other myriad of services which have 1366.06s - 1371.80s | this very same issue, all of these are misconfigurations, not a vulnerability. Had you 1371.80s - 1376.54s | suffered a breach, compromise, or other security incident as a result of it, well, 1376.54s - 1380.34s | unfortunately that would be your responsibility as a part of the AWS shared responsibility 1380.34s - 1385.08s | model. And so you're probably wondering, well Nick, I was promised a second vulnerability, 1385.08s - 1390.22s | you're calling this a misconfiguration, what gives? Well, uh, this is where things get weird, 1390.24s - 1395.68s | and we dive into our second vulnerability of the day, the AWS Amplify service exposing 1395.68s - 1401.02s | IEM roles to take over. Uh, see, earlier this year, when we noticed this capability in 1401.02s - 1405.86s | Cognito, one of the first questions we had was, okay, cool, I wonder how common this 1405.86s - 1411.00s | misconfiguration is? And because it could be used for initial access, literally just a 1411.00s - 1415.24s | Zoom rolling into victim accounts, we wanted to know if we could use publicly available 1415.26s - 1421.26s | data to find vulnerable roles and notify their owners so they could be fixed. To do this, we 1421.26s - 1425.94s | used a tool called Sourcegraph, one of the free features of which is essentially like a 1425.94s - 1432.08s | Google search, but for public GitHub repos. Uh, we, we wrote a regular expression to find 1432.08s - 1437.78s | IEM role ARNs, threw that into Sourcegraph, got back results, deduplicated them, removed 1437.78s - 1442.22s | like clearly placeholder ARNs, like account IDs with all one digit or incrementing digits, 1442.24s - 1447.90s | things like that. Uh, and that left us with a little over 8,000 results. We then tried


chunk_id: 213_chunk_27
chunk_text:
the AWS Amplify service exposing 1395.68s - 1401.02s | IEM roles to take over. Uh, see, earlier this year, when we noticed this capability in 1401.02s - 1405.86s | Cognito, one of the first questions we had was, okay, cool, I wonder how common this 1405.86s - 1411.00s | misconfiguration is? And because it could be used for initial access, literally just a 1411.00s - 1415.24s | Zoom rolling into victim accounts, we wanted to know if we could use publicly available 1415.26s - 1421.26s | data to find vulnerable roles and notify their owners so they could be fixed. To do this, we 1421.26s - 1425.94s | used a tool called Sourcegraph, one of the free features of which is essentially like a 1425.94s - 1432.08s | Google search, but for public GitHub repos. Uh, we, we wrote a regular expression to find 1432.08s - 1437.78s | IEM role ARNs, threw that into Sourcegraph, got back results, deduplicated them, removed 1437.78s - 1442.22s | like clearly placeholder ARNs, like account IDs with all one digit or incrementing digits, 1442.24s - 1447.90s | things like that. Uh, and that left us with a little over 8,000 results. We then tried to 1447.90s - 1452.88s | assume each role twice, once authenticated and once unauthenticated, and we let our 1452.88s - 1458.52s | automation run, and pretty much immediately it was clear, something was terribly wrong. 1458.52s - 1463.56s | Remember, this was across all of public GitHub, across teams, organi- organizations, 1463.56s - 1469.10s | individuals, and companies, so why was it then that the overwhelming majority of roles 1469.10s - 1475.02s | that we found to be vulnerable all had this weirdly specific naming convention? What you 1475.02s - 1479.82s | see here on the slide are real, real, real roles that we found in the wild that were 1479.82s - 1484.60s | vulnerable, that we have slightly modified the names of so as to respect the anonymity of 1484.60s - 1489.80s | their owners. Now, what made these roles so weird was that they all ended in either auth 1489.80s - 1494.96s | role or unauth role. And additionally, they had what appeared to be either a time stamp 1494.96s - 1501.04s | dating back to 2018 or 2019, or they had a six digit integer. Presumably, these were the 1501.04s - 1505.98s | newer ones. To make


chunk_id: 213_chunk_28
chunk_text:
to 1447.90s - 1452.88s | assume each role twice, once authenticated and once unauthenticated, and we let our 1452.88s - 1458.52s | automation run, and pretty much immediately it was clear, something was terribly wrong. 1458.52s - 1463.56s | Remember, this was across all of public GitHub, across teams, organi- organizations, 1463.56s - 1469.10s | individuals, and companies, so why was it then that the overwhelming majority of roles 1469.10s - 1475.02s | that we found to be vulnerable all had this weirdly specific naming convention? What you 1475.02s - 1479.82s | see here on the slide are real, real, real roles that we found in the wild that were 1479.82s - 1484.60s | vulnerable, that we have slightly modified the names of so as to respect the anonymity of 1484.60s - 1489.80s | their owners. Now, what made these roles so weird was that they all ended in either auth 1489.80s - 1494.96s | role or unauth role. And additionally, they had what appeared to be either a time stamp 1494.96s - 1501.04s | dating back to 2018 or 2019, or they had a six digit integer. Presumably, these were the 1501.04s - 1505.98s | newer ones. To make things even more weird, as we were going through the results, we actually 1505.98s - 1511.88s | found three roles that belonged to AWS themselves. And so at this point, it wasn't clear if 1511.88s - 1517.02s | this was some sort of uh, tutorial gone wrong, where somebody was demoing how to set this 1517.02s - 1522.02s | up with OIDC, not realizing that it was vulnerable and letting anybody just assume these 1522.02s - 1528.30s | roles in anybody's account. Uh, using source graph, we were able to see the name of the file 1528.30s - 1533.34s | where these roles were being found. And again, the overwhelming majority were found in 1533.34s - 1540.14s | files called team provider info dot Jason. And through this, this led us ultimately to the 1540.14s - 1546.08s | culprit. The thing that was causing all these roles to let anybody assume them. Turns out it 1546.08s - 1552.98s | was AWS Amplify. Normally, when we're talking about a misconfiguration, we're talking 1552.98s - 1557.26s | about a mistake, misunderstanding, developers moving a little bit too quickly and breaking 1557.26s - 1562.66s | things or not realizing that something is as


chunk_id: 213_chunk_29
chunk_text:
things even more weird, as we were going through the results, we actually 1505.98s - 1511.88s | found three roles that belonged to AWS themselves. And so at this point, it wasn't clear if 1511.88s - 1517.02s | this was some sort of uh, tutorial gone wrong, where somebody was demoing how to set this 1517.02s - 1522.02s | up with OIDC, not realizing that it was vulnerable and letting anybody just assume these 1522.02s - 1528.30s | roles in anybody's account. Uh, using source graph, we were able to see the name of the file 1528.30s - 1533.34s | where these roles were being found. And again, the overwhelming majority were found in 1533.34s - 1540.14s | files called team provider info dot Jason. And through this, this led us ultimately to the 1540.14s - 1546.08s | culprit. The thing that was causing all these roles to let anybody assume them. Turns out it 1546.08s - 1552.98s | was AWS Amplify. Normally, when we're talking about a misconfiguration, we're talking 1552.98s - 1557.26s | about a mistake, misunderstanding, developers moving a little bit too quickly and breaking 1557.26s - 1562.66s | things or not realizing that something is as vulnerable as it actually was. This was a rare 1562.66s - 1568.60s | circumstance in which an AWS service itself was exposing IEM roles such that anyone could 1568.60s - 1573.64s | assume them. The vulnerability was not that you could misconfigure roles, it's that AWS 1573.64s - 1578.44s | was doing it to you. And fortunately not just once, they actually did it twice. If you're not 1578.44s - 1583.44s | familiar with Amplify, Amplify is a uh, web and mobile application framework that lets you 1583.44s - 1588.92s | build these technologies. Uh, one of the core selling points to Amplify is essentially that 1588.92s - 1595.22s | uh, by using Amplify, it will abstract away a lot of the underlying infrastructure. So, if 1595.22s - 1599.96s | you build a web application and you want your users to be able to create accounts, sign up, 1599.98s - 1605.12s | change the password and so on, your developers don't even need to know what Cognito is. They 1605.12s - 1611.20s | can simply add authentication through Amplify and Amplify goes in, creates Cognito resources, 1611.20s - 1616.96s | configures them, sets them up and so on. Key emphasis,


chunk_id: 213_chunk_30
chunk_text:
vulnerable as it actually was. This was a rare 1562.66s - 1568.60s | circumstance in which an AWS service itself was exposing IEM roles such that anyone could 1568.60s - 1573.64s | assume them. The vulnerability was not that you could misconfigure roles, it's that AWS 1573.64s - 1578.44s | was doing it to you. And fortunately not just once, they actually did it twice. If you're not 1578.44s - 1583.44s | familiar with Amplify, Amplify is a uh, web and mobile application framework that lets you 1583.44s - 1588.92s | build these technologies. Uh, one of the core selling points to Amplify is essentially that 1588.92s - 1595.22s | uh, by using Amplify, it will abstract away a lot of the underlying infrastructure. So, if 1595.22s - 1599.96s | you build a web application and you want your users to be able to create accounts, sign up, 1599.98s - 1605.12s | change the password and so on, your developers don't even need to know what Cognito is. They 1605.12s - 1611.20s | can simply add authentication through Amplify and Amplify goes in, creates Cognito resources, 1611.20s - 1616.96s | configures them, sets them up and so on. Key emphasis, Amplify configures those Cognito 1616.96s - 1622.60s | resources. Now, there's two ways you can build an Amplify app or configure them. Uh, they're 1622.60s - 1627.48s | not mutually exclusive, you can use either or. Uh, there is the studio which is the web 1627.50s - 1632.40s | console portal equivalent and then there is the CLI which you can run from your local machine 1632.40s - 1637.84s | or as a part of your CI city pipeline. Now, typically when we do cloud security research, one 1637.84s - 1642.24s | of the challenges we often have is it's not really clear why this vulnerable, vulnerable 1642.24s - 1646.68s | behavior is occurring. We might be able to see that something has security impacts but it's 1646.68s - 1650.76s | not clear what exactly happened or why it's doing this. For example, with the first 1650.76s - 1654.96s | vulnerability, for some remarkably strange reason, changing the casing on a JSON 1654.98s - 1660.18s | parameter let us break a major security boundary in AWS. So, we run into these types of 1660.18s - 1664.62s | scenarios fairly frequently. What's neat about this Amplify vulnerability and why it's 1664.62s


chunk_id: 213_chunk_31
chunk_text:
Amplify configures those Cognito 1616.96s - 1622.60s | resources. Now, there's two ways you can build an Amplify app or configure them. Uh, they're 1622.60s - 1627.48s | not mutually exclusive, you can use either or. Uh, there is the studio which is the web 1627.50s - 1632.40s | console portal equivalent and then there is the CLI which you can run from your local machine 1632.40s - 1637.84s | or as a part of your CI city pipeline. Now, typically when we do cloud security research, one 1637.84s - 1642.24s | of the challenges we often have is it's not really clear why this vulnerable, vulnerable 1642.24s - 1646.68s | behavior is occurring. We might be able to see that something has security impacts but it's 1646.68s - 1650.76s | not clear what exactly happened or why it's doing this. For example, with the first 1650.76s - 1654.96s | vulnerability, for some remarkably strange reason, changing the casing on a JSON 1654.98s - 1660.18s | parameter let us break a major security boundary in AWS. So, we run into these types of 1660.18s - 1664.62s | scenarios fairly frequently. What's neat about this Amplify vulnerability and why it's 1664.62s - 1669.56s | personally one of my favorites is that this is actually a rare instance where we are able to 1669.56s - 1675.56s | know not only how did this become vulnerable but when. That's because the Amplify CLI 1675.56s - 1681.40s | written by AWS is actually open source and by digging through the commit history we can 1681.44s - 1686.88s | see how and when these vulnerabilities were introduced. And we didn't know it at the time 1686.88s - 1692.38s | but later on in speaking to AWS employees we came to find out that the Amplify studio, the 1692.38s - 1698.46s | web console equivalent actually uses parts of the CLI as libraries. And that's how I can 1698.46s - 1704.20s | tell you with confidence that both the Amplify studio and CLI became vulnerable on or around 1704.20s - 1710.64s | July 3rd 2018 to the variant 2 vulnerable trust policy. Allowing anyone in the world the 1710.64s - 1716.32s | ability to assume these roles. What happened here is that any time you create an Amplify 1716.32s - 1721.76s | project 2 roles are created for your account. An auth role and an unauth


chunk_id: 213_chunk_32
chunk_text:
- 1669.56s | personally one of my favorites is that this is actually a rare instance where we are able to 1669.56s - 1675.56s | know not only how did this become vulnerable but when. That's because the Amplify CLI 1675.56s - 1681.40s | written by AWS is actually open source and by digging through the commit history we can 1681.44s - 1686.88s | see how and when these vulnerabilities were introduced. And we didn't know it at the time 1686.88s - 1692.38s | but later on in speaking to AWS employees we came to find out that the Amplify studio, the 1692.38s - 1698.46s | web console equivalent actually uses parts of the CLI as libraries. And that's how I can 1698.46s - 1704.20s | tell you with confidence that both the Amplify studio and CLI became vulnerable on or around 1704.20s - 1710.64s | July 3rd 2018 to the variant 2 vulnerable trust policy. Allowing anyone in the world the 1710.64s - 1716.32s | ability to assume these roles. What happened here is that any time you create an Amplify 1716.32s - 1721.76s | project 2 roles are created for your account. An auth role and an unauth role like we saw 1721.76s - 1728.76s | previously. Unfortunately as a part of this commit the default trust policy associated with 1728.76s - 1733.74s | those roles was set to this which would allow anybody in the world to assume them. So, if 1733.74s - 1737.70s | you thought you were building a private internal only application that required 1737.70s - 1741.18s | authentication and you were gatekeeping who could create accounts so that you could 1741.18s - 1746.50s | protect your stuff, well, um, sorry, no, no you weren't. Anybody could just assume those 1746.50s - 1751.58s | roles and access whatever was associated with them. Like I said that was introduced on July 1751.58s - 1756.58s | 3rd 2018. A little over a year later on August 8th 2019 AWS sort of fixed this issue. Uh, 1760.22s - 1765.12s | seemingly unintentionally. What they did was they set the default effect to a deny and 1765.12s - 1769.76s | they removed the condition entirely. This is actually the exact same behaviour we see 1769.76s - 1775.30s | today when uh creating a new Amplify project. It's really important to stress though that 1775.30s - 1780.56s | what


chunk_id: 213_chunk_33
chunk_text:
role like we saw 1721.76s - 1728.76s | previously. Unfortunately as a part of this commit the default trust policy associated with 1728.76s - 1733.74s | those roles was set to this which would allow anybody in the world to assume them. So, if 1733.74s - 1737.70s | you thought you were building a private internal only application that required 1737.70s - 1741.18s | authentication and you were gatekeeping who could create accounts so that you could 1741.18s - 1746.50s | protect your stuff, well, um, sorry, no, no you weren't. Anybody could just assume those 1746.50s - 1751.58s | roles and access whatever was associated with them. Like I said that was introduced on July 1751.58s - 1756.58s | 3rd 2018. A little over a year later on August 8th 2019 AWS sort of fixed this issue. Uh, 1760.22s - 1765.12s | seemingly unintentionally. What they did was they set the default effect to a deny and 1765.12s - 1769.76s | they removed the condition entirely. This is actually the exact same behaviour we see 1769.76s - 1775.30s | today when uh creating a new Amplify project. It's really important to stress though that 1775.30s - 1780.56s | what this change did in August of 2019 was make it so that no future roles would become 1780.56s - 1786.24s | misconfigured. Any that had already been created were still vulnerable and that's how we 1786.24s - 1791.24s | were able to assume them in 2024. Later on in July of 2020 variant 1 was introduced to the 1791.60s - 1796.60s | Amplify CLI in studio. And this one was a bit more complicated than the previous one. What 1798.98s - 1804.08s | happened here was that, like I said previously, you can add authentication to an Amplify 1804.08s - 1809.52s | project. If at any time you chose to remove authentication for any reason, that would 1809.52s - 1814.56s | introduce the variant 1 policy. Uh, in speaking to developers who were affected by this, it 1814.56s - 1820.06s | seems the most common reason that this occurred was situations in which uh, uh, projects 1820.08s - 1825.26s | started with the built-in Amplify controlled Cognito resources and then at a later time 1825.26s - 1830.46s | moved to Cognito outside of Amplify or to just a different identity provider entirely. 1830.46s - 1835.50s | Regardless of the reason


