# MediaChunks

chunk_id: 200_chunk_1
chunk_text:
"upload_date": "20241016" } 0.00s - 7.00s | This text was transcribed using whisper model: large-v2 My name is Mikhail Shcherbakov, and today I want to tell you a few stories about Kibana bug bounty. 8.00s - 14.00s | This first part of the talk is about vulnerabilities that I found in Kibana, 14.00s - 23.00s | and I combined only remote code execution vulnerabilities in this talk, just because of time limits. 23.00s - 27.00s | A few words about me. 27.00s - 33.00s | Now I am finishing my PhD studies at KTH University Stockholm, 33.00s - 41.00s | and working on the thesis Code Reuse Attacks in Managed Programming Languages and Runtimes. 41.00s - 52.00s | My main research interests are static code analysis, dynamic program analysis, and language-based security in general. 52.00s - 62.00s | I participated in bug bounty programs of Microsoft, GitHub, some open source projects, and Elastic. 62.00s - 71.00s | Today we will talk about Elastic bug bounty program, namely Kibana bug bounty program. 71.00s - 73.00s | Who is Kibana? 73.00s - 84.00s | Kibana is a part of popular ILCA stack that includes Elasticsearch, Logstash, and Kibana. 84.00s - 92.00s | It is used for data visualization and real-time analysis. 93.00s - 104.00s | Kibana is an open source project, all code is available, and it is possible to analyze statically or just make a manual review. 104.00s - 112.00s | It is definitely a large project, probably one of the largest, it is written in TypeScript, 112.00s - 124.00s | and they have an interesting bug bounty program with 3,000-7,000 rewards for critical vulnerabilities. 124.00s - 136.00s | All of that makes Kibana a great target for bug hunters, and I contributed a lot last year in this program. 137.00s - 146.00s | Before starting to tell about vulnerabilities in Kibana, I would like to say my thanks to Elastic Security team. 146.00s - 156.00s | In my practice, in my experience, it is one of the best bug bounty programs that is managed by Elastic Security team. 156.00s - 169.00s | Thank you guys for your work, and the main reason that I contribute a lot in this bug bounty is just a good experience of this work. 169.00s - 175.00s | So, story number one, how it all began. 176.00s - 190.00s | One year ago, in the


chunk_id: 200_chunk_2
chunk_text:
It is used for data visualization and real-time analysis. 93.00s - 104.00s | Kibana is an open source project, all code is available, and it is possible to analyze statically or just make a manual review. 104.00s - 112.00s | It is definitely a large project, probably one of the largest, it is written in TypeScript, 112.00s - 124.00s | and they have an interesting bug bounty program with 3,000-7,000 rewards for critical vulnerabilities. 124.00s - 136.00s | All of that makes Kibana a great target for bug hunters, and I contributed a lot last year in this program. 137.00s - 146.00s | Before starting to tell about vulnerabilities in Kibana, I would like to say my thanks to Elastic Security team. 146.00s - 156.00s | In my practice, in my experience, it is one of the best bug bounty programs that is managed by Elastic Security team. 156.00s - 169.00s | Thank you guys for your work, and the main reason that I contribute a lot in this bug bounty is just a good experience of this work. 169.00s - 175.00s | So, story number one, how it all began. 176.00s - 190.00s | One year ago, in the last August, after DEFCON, I found that Elastic Bug Bounty started compiling for a new feature 190.00s - 200.00s | that's called synthetic monitoring in the Kibana product that can be used for some dashboard. 200.00s - 210.00s | The idea of the feature that you can set up some monitors for websites and see how the website is available 210.00s - 217.00s | or some content was changed and make some reports based on such monitoring. 217.00s - 224.00s | Okay, let's see how this feature looks like in practice. 224.00s - 231.00s | In this main page of the Kibana, you can find synthetics, the feature that we discussed. 231.00s - 236.00s | You can create new monitor to monitor some website. 236.00s - 244.00s | You need to set the name of the monitor, location, when your agent will be run to make a request to the site. 244.00s - 249.00s | And look, you can define some script. 249.00s - 253.00s | So, it looks interesting. 253.00s - 258.00s | We have some script editor and we can pass all the script here. 258.00s - 263.00s | Let's check the documentation, how such scripts look like.


chunk_id: 200_chunk_3
chunk_text:
last August, after DEFCON, I found that Elastic Bug Bounty started compiling for a new feature 190.00s - 200.00s | that's called synthetic monitoring in the Kibana product that can be used for some dashboard. 200.00s - 210.00s | The idea of the feature that you can set up some monitors for websites and see how the website is available 210.00s - 217.00s | or some content was changed and make some reports based on such monitoring. 217.00s - 224.00s | Okay, let's see how this feature looks like in practice. 224.00s - 231.00s | In this main page of the Kibana, you can find synthetics, the feature that we discussed. 231.00s - 236.00s | You can create new monitor to monitor some website. 236.00s - 244.00s | You need to set the name of the monitor, location, when your agent will be run to make a request to the site. 244.00s - 249.00s | And look, you can define some script. 249.00s - 253.00s | So, it looks interesting. 253.00s - 258.00s | We have some script editor and we can pass all the script here. 258.00s - 263.00s | Let's check the documentation, how such scripts look like. 263.00s - 273.00s | It's one of the examples, a simple script that's just open the example.org and check some element, 273.00s - 280.00s | the text and the element and check that it equals to example domain. 280.00s - 285.00s | Okay, but it looks like a JavaScript, right? 285.00s - 294.00s | So, if you just replace the body of this method and write, for example, to run a reverse shell, 294.00s - 297.00s | probably we can execute it. 297.00s - 302.00s | But exactly this code doesn't work because of requiring. 302.00s - 309.00s | If you did some JavaScript CTF, you probably already know about this problem. 309.00s - 315.00s | You don't have a require in the scope, but you can bypass it for Node.js, for example. 315.00s - 331.00s | You can use load, underscore load method in the process main module to load any module, including child process. 331.00s - 334.00s | And you can run a reverse shell. 334.00s - 336.00s | Let's see on the demo. 336.00s - 345.00s | We paste this code, click on the run and see you have already connection from the reverse shell, from the


chunk_id: 200_chunk_4
chunk_text:
263.00s - 273.00s | It's one of the examples, a simple script that's just open the example.org and check some element, 273.00s - 280.00s | the text and the element and check that it equals to example domain. 280.00s - 285.00s | Okay, but it looks like a JavaScript, right? 285.00s - 294.00s | So, if you just replace the body of this method and write, for example, to run a reverse shell, 294.00s - 297.00s | probably we can execute it. 297.00s - 302.00s | But exactly this code doesn't work because of requiring. 302.00s - 309.00s | If you did some JavaScript CTF, you probably already know about this problem. 309.00s - 315.00s | You don't have a require in the scope, but you can bypass it for Node.js, for example. 315.00s - 331.00s | You can use load, underscore load method in the process main module to load any module, including child process. 331.00s - 334.00s | And you can run a reverse shell. 334.00s - 336.00s | Let's see on the demo. 336.00s - 345.00s | We paste this code, click on the run and see you have already connection from the reverse shell, from the agent. 345.00s - 353.00s | We see the file system and the user on this agent, on the harebit engine. 353.00s - 359.00s | You can see the harebit name of the user that we get. 360.00s - 363.00s | That monitor any websites. 363.00s - 366.00s | Okay, this is a remote code execution. 366.00s - 371.00s | I think it's the simplest remote code execution that I reported. 371.00s - 375.00s | And in the last August, I made a report. 375.00s - 384.00s | The program, the company already finishing and it was the last days. 384.00s - 388.00s | And also the rules for the post-exploitation was not clear. 388.00s - 392.00s | And I decided, okay, I found it, I will report it and let's see. 392.00s - 397.00s | We discount this report with Elastic security team in September. 397.00s - 401.00s | And in October, they came back with the feedback. 401.00s - 407.00s | Synthetics by design is arbitrary code execution as a service, 407.00s - 413.00s | in which Elastic deploys a number of security features to prevent exploitation. 413.00s - 421.00s | For successful exploit, someone would have to do


chunk_id: 200_chunk_5
chunk_text:
agent. 345.00s - 353.00s | We see the file system and the user on this agent, on the harebit engine. 353.00s - 359.00s | You can see the harebit name of the user that we get. 360.00s - 363.00s | That monitor any websites. 363.00s - 366.00s | Okay, this is a remote code execution. 366.00s - 371.00s | I think it's the simplest remote code execution that I reported. 371.00s - 375.00s | And in the last August, I made a report. 375.00s - 384.00s | The program, the company already finishing and it was the last days. 384.00s - 388.00s | And also the rules for the post-exploitation was not clear. 388.00s - 392.00s | And I decided, okay, I found it, I will report it and let's see. 392.00s - 397.00s | We discount this report with Elastic security team in September. 397.00s - 401.00s | And in October, they came back with the feedback. 401.00s - 407.00s | Synthetics by design is arbitrary code execution as a service, 407.00s - 413.00s | in which Elastic deploys a number of security features to prevent exploitation. 413.00s - 421.00s | For successful exploit, someone would have to do something beyond getting a shell. 421.00s - 425.00s | Okay, so it makes sense. 425.00s - 433.00s | If you make such feature, probably you already isolated this code on the container. 433.00s - 437.00s | And what they actually did. 438.00s - 446.00s | Okay, we discussed it and I decided to continue exploitation of this container 446.00s - 450.00s | and see what I can get in the end. 450.00s - 452.00s | Where we are? 452.00s - 455.00s | This is an isolated container. 455.00s - 462.00s | After some investigation, I see that it's run in the Kubernetes cluster on Google Cloud Platform. 462.00s - 471.00s | Probably it was managed Kubernetes cluster, but the details are not important here. 471.00s - 477.00s | The first idea was to try to affect another client on the same container. 477.00s - 482.00s | But the container was running per task. 482.00s - 486.00s | So we don't have any persistent state. 486.00s - 493.00s | After execution of the code that we injected, the container just restarted. 493.00s - 496.00s | And no any client there. 496.00s - 499.00s | Okay, try to escape the container. 499.00s


chunk_id: 200_chunk_6
chunk_text:
something beyond getting a shell. 421.00s - 425.00s | Okay, so it makes sense. 425.00s - 433.00s | If you make such feature, probably you already isolated this code on the container. 433.00s - 437.00s | And what they actually did. 438.00s - 446.00s | Okay, we discussed it and I decided to continue exploitation of this container 446.00s - 450.00s | and see what I can get in the end. 450.00s - 452.00s | Where we are? 452.00s - 455.00s | This is an isolated container. 455.00s - 462.00s | After some investigation, I see that it's run in the Kubernetes cluster on Google Cloud Platform. 462.00s - 471.00s | Probably it was managed Kubernetes cluster, but the details are not important here. 471.00s - 477.00s | The first idea was to try to affect another client on the same container. 477.00s - 482.00s | But the container was running per task. 482.00s - 486.00s | So we don't have any persistent state. 486.00s - 493.00s | After execution of the code that we injected, the container just restarted. 493.00s - 496.00s | And no any client there. 496.00s - 499.00s | Okay, try to escape the container. 499.00s - 504.00s | It was secure configuration of up-to-date Kubernetes version. 504.00s - 507.00s | So it looks like not possible. 507.00s - 511.00s | Access to Google Cloud Platform metadata API? 511.00s - 512.00s | No again. 512.00s - 517.00s | So I think it's one of the first thing that they checked. 517.00s - 521.00s | It looks like unexploitable case. 521.00s - 530.00s | So we found remote code execution, but we cannot bypass the container isolation. 530.00s - 543.64s | I continue investigated some things around and found the same Docker container for private Kubernetes cluster. 543.64s - 547.64s | That means we can run it in the own Kubernetes cluster. 547.64s - 555.64s | It makes threat model a little bit weak because we don't have exactly the same settings. 555.64s - 567.64s | We can say if we can escape from container or affect some another services or features in the default configuration on the Kubernetes. 567.64s - 573.64s | It looks like possible exploitation flaw. 573.64s - 582.64s | And I also found that this container already have natural capabilities. 582.64s - 588.64s | It means that we can send any raw package


chunk_id: 200_chunk_7
chunk_text:
- 504.00s | It was secure configuration of up-to-date Kubernetes version. 504.00s - 507.00s | So it looks like not possible. 507.00s - 511.00s | Access to Google Cloud Platform metadata API? 511.00s - 512.00s | No again. 512.00s - 517.00s | So I think it's one of the first thing that they checked. 517.00s - 521.00s | It looks like unexploitable case. 521.00s - 530.00s | So we found remote code execution, but we cannot bypass the container isolation. 530.00s - 543.64s | I continue investigated some things around and found the same Docker container for private Kubernetes cluster. 543.64s - 547.64s | That means we can run it in the own Kubernetes cluster. 547.64s - 555.64s | It makes threat model a little bit weak because we don't have exactly the same settings. 555.64s - 567.64s | We can say if we can escape from container or affect some another services or features in the default configuration on the Kubernetes. 567.64s - 573.64s | It looks like possible exploitation flaw. 573.64s - 582.64s | And I also found that this container already have natural capabilities. 582.64s - 588.64s | It means that we can send any raw package to the network. 588.64s - 590.64s | Any package. 590.64s - 593.64s | It means we can emulate any protocol. 593.64s - 598.64s | For example, we can say send ARP packages. 598.64s - 605.64s | I think you already understand my idea and get what I want to do. 605.64s - 614.64s | Yeah, let's try to do ARP spoofing attack in 2024. 615.64s - 625.64s | So our protocol allows to send some request to match IP address to the MAC address of any computer. 625.64s - 634.64s | And for example, in the network, when Bob tried to connect to Mary and communicate by IP transport, 634.64s - 646.64s | we can say to Bob that Mary is an attacker computer and say to Mary that Bob is an attacker computer and intercept the traffic between these two machines. 646.64s - 653.64s | It's a simple, old, very old, old school attack. 653.64s - 657.64s | But what about Kubernetes? 658.64s - 665.64s | I already wanted to start to run Wireshark and investigate the traffic, what actually happens. 665.64s - 672.64s | And found a nice blog post from Nir Chacko. 672.64s - 677.64s | Attacking


chunk_id: 200_chunk_8
chunk_text:
to the network. 588.64s - 590.64s | Any package. 590.64s - 593.64s | It means we can emulate any protocol. 593.64s - 598.64s | For example, we can say send ARP packages. 598.64s - 605.64s | I think you already understand my idea and get what I want to do. 605.64s - 614.64s | Yeah, let's try to do ARP spoofing attack in 2024. 615.64s - 625.64s | So our protocol allows to send some request to match IP address to the MAC address of any computer. 625.64s - 634.64s | And for example, in the network, when Bob tried to connect to Mary and communicate by IP transport, 634.64s - 646.64s | we can say to Bob that Mary is an attacker computer and say to Mary that Bob is an attacker computer and intercept the traffic between these two machines. 646.64s - 653.64s | It's a simple, old, very old, old school attack. 653.64s - 657.64s | But what about Kubernetes? 658.64s - 665.64s | I already wanted to start to run Wireshark and investigate the traffic, what actually happens. 665.64s - 672.64s | And found a nice blog post from Nir Chacko. 672.64s - 677.64s | Attacking Kubernetes clusters throws your network plumbing. 677.64s - 694.64s | So, he described the same idea of ARP spoofing to replace DNS server that available in the Kubernetes to the own DNS server. 694.64s - 710.64s | And in this case, you can hijack any DNS request and send the request to the own web server instead of any available web server. 710.64s - 716.64s | And the crucial component of this attack, this is this bridge. 716.64s - 720.64s | Let's call it BR0 on this figure. 720.64s - 740.64s | So, this bridge supports ARP protocol and has own ARP table that has any IP addresses and MAC addresses of the ports that run on the same node. 740.64s - 743.64s | So, it looks like very restricted attack. 743.64s - 747.64s | We can affect only ports on the same node. 747.64s - 758.64s | But default network interface in Kubernetes allows us to exploit ARP spoofing. 758.64s - 760.64s | Let's see on the demo. 760.64s - 768.64s | So, the one of the idea to start this attack was to use some cloud environment. 768.64s - 774.64s | I check Microsoft Azure and they allow


chunk_id: 200_chunk_9
chunk_text:
Kubernetes clusters throws your network plumbing. 677.64s - 694.64s | So, he described the same idea of ARP spoofing to replace DNS server that available in the Kubernetes to the own DNS server. 694.64s - 710.64s | And in this case, you can hijack any DNS request and send the request to the own web server instead of any available web server. 710.64s - 716.64s | And the crucial component of this attack, this is this bridge. 716.64s - 720.64s | Let's call it BR0 on this figure. 720.64s - 740.64s | So, this bridge supports ARP protocol and has own ARP table that has any IP addresses and MAC addresses of the ports that run on the same node. 740.64s - 743.64s | So, it looks like very restricted attack. 743.64s - 747.64s | We can affect only ports on the same node. 747.64s - 758.64s | But default network interface in Kubernetes allows us to exploit ARP spoofing. 758.64s - 760.64s | Let's see on the demo. 760.64s - 768.64s | So, the one of the idea to start this attack was to use some cloud environment. 768.64s - 774.64s | I check Microsoft Azure and they allow us to use default Kubernetes. 774.64s - 776.64s | So, you can see the console. 776.64s - 785.64s | I already started attacker at victim ports and you can see that it's run on the same node in Kubernetes cluster. 785.64s - 792.64s | It allows us to perform attack from the attacker to affect the victim. 792.64s - 800.64s | First of all, we install proof of concept script and some additional dependencies on the attacker. 800.64s - 803.64s | At the same time, we open the victim machine. 803.64s - 808.64s | We will install KURL there to emulate some web requests. 808.64s - 811.64s | Yeah, it's the console of the victim machine. 811.64s - 822.24s | And after installation of the KURL, the idea that we try to get the data from the google.com. 822.24s - 831.24s | After that, we start the attack and try to use own web server instead of the google.com. 831.24s - 837.24s | So, now you see the usual, the valid response from the google.com. 837.24s - 839.24s | And this is the attacker port. 839.24s - 849.24s | We run DNS spoofing proof of concept that I found in


chunk_id: 200_chunk_10
chunk_text:
us to use default Kubernetes. 774.64s - 776.64s | So, you can see the console. 776.64s - 785.64s | I already started attacker at victim ports and you can see that it's run on the same node in Kubernetes cluster. 785.64s - 792.64s | It allows us to perform attack from the attacker to affect the victim. 792.64s - 800.64s | First of all, we install proof of concept script and some additional dependencies on the attacker. 800.64s - 803.64s | At the same time, we open the victim machine. 803.64s - 808.64s | We will install KURL there to emulate some web requests. 808.64s - 811.64s | Yeah, it's the console of the victim machine. 811.64s - 822.24s | And after installation of the KURL, the idea that we try to get the data from the google.com. 822.24s - 831.24s | After that, we start the attack and try to use own web server instead of the google.com. 831.24s - 837.24s | So, now you see the usual, the valid response from the google.com. 837.24s - 839.24s | And this is the attacker port. 839.24s - 849.24s | We run DNS spoofing proof of concept that I found in that blog post. 849.24s - 854.24s | I also improved it to use it on Azure. 854.24s - 857.24s | By default, it did not support it. 857.24s - 860.24s | And we start the attack here. 860.24s - 864.24s | And now we do the same request. 864.24s - 871.24s | And you can see that our web server responds instead of the google.com. 871.24s - 878.24s | So, it's a classic DNS spoofing that we demonstrated in this demo. 878.24s - 883.24s | And I updated the report to demonstrate this attack. 883.24s - 886.24s | Elastic changed the report. 887.24s - 899.24s | And a few days, one week ago, they rewarded with almost 4000 bounties for this attack. 899.24s - 905.24s | Not bad for unexploitable case and very exotic attack. 906.24s - 916.24s | And it was very interesting experience to try to use ARP spoofing in the real bug bounty case. 916.24s - 924.24s | So, I missed a lot of the details of network configuration of the Kubernetes. 924.24s - 928.24s | If you're interested in that, read the blog post. 928.24s - 930.24s | I'm sure you'll enjoy it. 930.24s - 937.24s


chunk_id: 200_chunk_11
chunk_text:
that blog post. 849.24s - 854.24s | I also improved it to use it on Azure. 854.24s - 857.24s | By default, it did not support it. 857.24s - 860.24s | And we start the attack here. 860.24s - 864.24s | And now we do the same request. 864.24s - 871.24s | And you can see that our web server responds instead of the google.com. 871.24s - 878.24s | So, it's a classic DNS spoofing that we demonstrated in this demo. 878.24s - 883.24s | And I updated the report to demonstrate this attack. 883.24s - 886.24s | Elastic changed the report. 887.24s - 899.24s | And a few days, one week ago, they rewarded with almost 4000 bounties for this attack. 899.24s - 905.24s | Not bad for unexploitable case and very exotic attack. 906.24s - 916.24s | And it was very interesting experience to try to use ARP spoofing in the real bug bounty case. 916.24s - 924.24s | So, I missed a lot of the details of network configuration of the Kubernetes. 924.24s - 928.24s | If you're interested in that, read the blog post. 928.24s - 930.24s | I'm sure you'll enjoy it. 930.24s - 937.24s | It's one of the best blog posts about Kubernetes networking that I was read. 937.24s - 941.24s | The links, all links will be in the end of the presentation. 941.24s - 945.24s | Let's see on another attacks. 945.24s - 956.24s | The main topic in my PhD studies for last two years was server-side prototype pollution vulnerabilities. 956.24s - 958.24s | We published three papers about that. 958.24s - 964.24s | When we found, we implemented some tool chain to find prototype pollution vulnerabilities. 964.24s - 975.24s | We found prototype pollution gadgets that allows us to exploit prototype pollution and achieve remote code execution attack. 975.24s - 982.24s | In Node.js itself, in Deno, in NPM packages. 982.24s - 985.24s | If you're interested in this, read the papers. 985.24s - 994.24s | And I also give us some short introduction of our research and prototype pollution attack the last year on DEF CON. 994.24s - 1002.24s | And many technical details of the gadgets that we found in Node.js itself in another talk on the Black Hat Asia. 1002.24s - 1013.24s | And today I will tell you short introduction what the prototype pollution is,


chunk_id: 200_chunk_12
chunk_text:
| It's one of the best blog posts about Kubernetes networking that I was read. 937.24s - 941.24s | The links, all links will be in the end of the presentation. 941.24s - 945.24s | Let's see on another attacks. 945.24s - 956.24s | The main topic in my PhD studies for last two years was server-side prototype pollution vulnerabilities. 956.24s - 958.24s | We published three papers about that. 958.24s - 964.24s | When we found, we implemented some tool chain to find prototype pollution vulnerabilities. 964.24s - 975.24s | We found prototype pollution gadgets that allows us to exploit prototype pollution and achieve remote code execution attack. 975.24s - 982.24s | In Node.js itself, in Deno, in NPM packages. 982.24s - 985.24s | If you're interested in this, read the papers. 985.24s - 994.24s | And I also give us some short introduction of our research and prototype pollution attack the last year on DEF CON. 994.24s - 1002.24s | And many technical details of the gadgets that we found in Node.js itself in another talk on the Black Hat Asia. 1002.24s - 1013.24s | And today I will tell you short introduction what the prototype pollution is, just to be on the same page. 1013.24s - 1020.35s | So let's assume that we have a Node.js application. 1020.35s - 1024.35s | We run some web server, you see index.js. 1024.35s - 1030.35s | It's very simple web server that can handle two requests, update and backup. 1030.35s - 1033.35s | For update request, we provide some arguments. 1033.35s - 1038.35s | For backup request, we just trigger the backup of database. 1038.35s - 1040.35s | Okay, it's all set up. 1040.35s - 1044.60s | So we have attacker in this threat model. 1044.60s - 1048.60s | It's any user that can send any request to the web server. 1048.60s - 1058.60s | And if the attacker send such request with these parameters, and we have a handler for update request. 1058.60s - 1064.60s | The handler in the first line create empty object. 1065.60s - 1075.60s | And run time in the same time, create empty object with the built-in property proto that points to the object prototype. 1075.60s - 1081.60s | That contains a lot of function like toString, valueOf that we can reuse. 1081.60s - 1090.60s | So it's like inheritance implementation for JavaScript and


chunk_id: 200_chunk_13
chunk_text:
just to be on the same page. 1013.24s - 1020.35s | So let's assume that we have a Node.js application. 1020.35s - 1024.35s | We run some web server, you see index.js. 1024.35s - 1030.35s | It's very simple web server that can handle two requests, update and backup. 1030.35s - 1033.35s | For update request, we provide some arguments. 1033.35s - 1038.35s | For backup request, we just trigger the backup of database. 1038.35s - 1040.35s | Okay, it's all set up. 1040.35s - 1044.60s | So we have attacker in this threat model. 1044.60s - 1048.60s | It's any user that can send any request to the web server. 1048.60s - 1058.60s | And if the attacker send such request with these parameters, and we have a handler for update request. 1058.60s - 1064.60s | The handler in the first line create empty object. 1065.60s - 1075.60s | And run time in the same time, create empty object with the built-in property proto that points to the object prototype. 1075.60s - 1081.60s | That contains a lot of function like toString, valueOf that we can reuse. 1081.60s - 1090.60s | So it's like inheritance implementation for JavaScript and TypeScript. 1091.60s - 1103.60s | In the second line, you can see that we read the property from the object that specified in the argument org. 1103.60s - 1105.60s | This is the proto. 1105.60s - 1109.60s | It means we get a reference to this object. 1109.60s - 1123.60s | In the last line of the code, we assign a value from details to another property of the prototype, the property shell. 1123.60s - 1132.60s | So we read the proto, we assign value calc in the shell, and we get it in the prototype. 1132.60s - 1136.60s | This code pattern is called prototype pollution. 1136.60s - 1143.60s | Because we pollute, we add some property or replace some property in the object prototypes itself. 1143.60s - 1147.60s | Let's assume that we have such code for backup handler. 1147.60s - 1154.60s | This function try to run the backup script, this one. 1154.60s - 1163.60s | And use the shell from the options and default shell if the shell is undefined. 1164.60s - 1169.60s | In our case, shell is undefined and it will be used default shell. 1169.60s - 1172.60s | Okay, it's very common pattern


chunk_id: 200_chunk_14
chunk_text:
TypeScript. 1091.60s - 1103.60s | In the second line, you can see that we read the property from the object that specified in the argument org. 1103.60s - 1105.60s | This is the proto. 1105.60s - 1109.60s | It means we get a reference to this object. 1109.60s - 1123.60s | In the last line of the code, we assign a value from details to another property of the prototype, the property shell. 1123.60s - 1132.60s | So we read the proto, we assign value calc in the shell, and we get it in the prototype. 1132.60s - 1136.60s | This code pattern is called prototype pollution. 1136.60s - 1143.60s | Because we pollute, we add some property or replace some property in the object prototypes itself. 1143.60s - 1147.60s | Let's assume that we have such code for backup handler. 1147.60s - 1154.60s | This function try to run the backup script, this one. 1154.60s - 1163.60s | And use the shell from the options and default shell if the shell is undefined. 1164.60s - 1169.60s | In our case, shell is undefined and it will be used default shell. 1169.60s - 1172.60s | Okay, it's very common pattern in the JavaScript. 1172.60s - 1179.60s | But what actually happens if we trigger this handler after prototype pollution? 1179.60s - 1185.60s | We create options that points to the same object prototype. 1185.60s - 1197.60s | We read the shell and the runtime lookups for the shell property in the prototype chain and reads the polluted shell property. 1197.60s - 1210.60s | And the exec command run a calculator because we get a calc in the shell, in the cmd variable at the end. 1210.60s - 1221.60s | Okay, this is prototype pollution and remote code execution that we can achieve by prototype pollution in the end. 1221.60s - 1227.60s | And this code pattern is called a gadget, prototype pollution gadget. 1227.60s - 1237.60s | Let's start the story too about prototype pollution and remote code execution based on that. 1238.60s - 1241.60s | So, I tried to use SilentSpring. 1241.60s - 1254.60s | It's our first research on the prototype pollution, the toolchain that we implemented based on the CodeQL to detect prototype pollution vulnerabilities in Kibana. 1254.60s - 1264.60s | So the first attempt CodeQL terminated by timeout because of too large database that I tried


chunk_id: 200_chunk_15
chunk_text:
in the JavaScript. 1172.60s - 1179.60s | But what actually happens if we trigger this handler after prototype pollution? 1179.60s - 1185.60s | We create options that points to the same object prototype. 1185.60s - 1197.60s | We read the shell and the runtime lookups for the shell property in the prototype chain and reads the polluted shell property. 1197.60s - 1210.60s | And the exec command run a calculator because we get a calc in the shell, in the cmd variable at the end. 1210.60s - 1221.60s | Okay, this is prototype pollution and remote code execution that we can achieve by prototype pollution in the end. 1221.60s - 1227.60s | And this code pattern is called a gadget, prototype pollution gadget. 1227.60s - 1237.60s | Let's start the story too about prototype pollution and remote code execution based on that. 1238.60s - 1241.60s | So, I tried to use SilentSpring. 1241.60s - 1254.60s | It's our first research on the prototype pollution, the toolchain that we implemented based on the CodeQL to detect prototype pollution vulnerabilities in Kibana. 1254.60s - 1264.60s | So the first attempt CodeQL terminated by timeout because of too large database that I tried to analyze. 1265.60s - 1274.60s | I implemented a script that rerun CodeQL for subfolders if the analysis is timed out. 1274.60s - 1281.60s | And this script reported 77 cases in the application itself. 1281.60s - 1285.60s | I will add the script in the same repository if you're interested. 1285.60s - 1286.60s | You can find it there. 1286.60s - 1288.60s | Try to play with that. 1289.60s - 1298.60s | So, we get 44 server-side cases including some false positive testing code. 1298.60s - 1307.60s | And today I will show you a couple cases from these that was exploited. 1309.60s - 1317.60s | So, the first case, this is prototype pollution pattern that was detected in the config parser. 1317.60s - 1327.60s | The config parser take some YAML document, main config of the Kibana when you restart Kibana. 1327.60s - 1342.60s | And after the parsing it also tried to expand dot-separated names in this YAML config to such nested object. 1343.60s - 1350.60s | So, a.b becomes a object that contains nested object with property b. 1350.60s - 1354.60s | So, very simple idea. 1354.60s - 1359.60s | But the code that does it


chunk_id: 200_chunk_16
chunk_text:
to analyze. 1265.60s - 1274.60s | I implemented a script that rerun CodeQL for subfolders if the analysis is timed out. 1274.60s - 1281.60s | And this script reported 77 cases in the application itself. 1281.60s - 1285.60s | I will add the script in the same repository if you're interested. 1285.60s - 1286.60s | You can find it there. 1286.60s - 1288.60s | Try to play with that. 1289.60s - 1298.60s | So, we get 44 server-side cases including some false positive testing code. 1298.60s - 1307.60s | And today I will show you a couple cases from these that was exploited. 1309.60s - 1317.60s | So, the first case, this is prototype pollution pattern that was detected in the config parser. 1317.60s - 1327.60s | The config parser take some YAML document, main config of the Kibana when you restart Kibana. 1327.60s - 1342.60s | And after the parsing it also tried to expand dot-separated names in this YAML config to such nested object. 1343.60s - 1350.60s | So, a.b becomes a object that contains nested object with property b. 1350.60s - 1354.60s | So, very simple idea. 1354.60s - 1359.60s | But the code that does it is vulnerable to prototype pollution. 1359.60s - 1364.60s | First of all, it take a key like ab in our case, split it by the dot. 1364.60s - 1371.60s | So, we get array a and b and call walk function. 1371.60s - 1386.60s | In the walk function we get the first key a and read the value of the a and call walk recursively. 1386.60s - 1388.60s | So, okay. 1388.60s - 1399.60s | And for the next case, if we have a last case, vary the b, case becomes empty array now. 1399.60s - 1404.60s | And we assign the value to the b. 1404.60s - 1410.60s | So, it's absolutely the same pattern that I've shown you before in the prototype pollution. 1410.60s - 1417.60s | And such payload leads to prototype pollution vulnerabilities in this case. 1417.60s - 1426.60s | So, we can add any property and we control the value of the polluted property. 1426.60s - 1428.60s | Good. 1428.60s - 1441.60s | I found it and also Elastic Cloud Enterprise, it's an on-premise version of the ILCA stack, 1441.60s - 1444.60s | provides web UI to edit Kibana YAML. 1444.60s - 1448.60s |


chunk_id: 200_chunk_17
chunk_text:
is vulnerable to prototype pollution. 1359.60s - 1364.60s | First of all, it take a key like ab in our case, split it by the dot. 1364.60s - 1371.60s | So, we get array a and b and call walk function. 1371.60s - 1386.60s | In the walk function we get the first key a and read the value of the a and call walk recursively. 1386.60s - 1388.60s | So, okay. 1388.60s - 1399.60s | And for the next case, if we have a last case, vary the b, case becomes empty array now. 1399.60s - 1404.60s | And we assign the value to the b. 1404.60s - 1410.60s | So, it's absolutely the same pattern that I've shown you before in the prototype pollution. 1410.60s - 1417.60s | And such payload leads to prototype pollution vulnerabilities in this case. 1417.60s - 1426.60s | So, we can add any property and we control the value of the polluted property. 1426.60s - 1428.60s | Good. 1428.60s - 1441.60s | I found it and also Elastic Cloud Enterprise, it's an on-premise version of the ILCA stack, 1441.60s - 1444.60s | provides web UI to edit Kibana YAML. 1444.60s - 1448.60s | It means we can edit it with admin privileges. 1448.60s - 1457.60s | So, we need some high-level privileges, but we can do this attack through the web. 1457.60s - 1468.68s | Attacker can store any payload in Kibana and restart Kibana to load all configs. 1468.68s - 1475.68s | The problem here that Kibana crashes immediately after prototype pollution, of course, 1475.68s - 1482.68s | because other code does not expect some properties, some additional properties in the object prototypes. 1482.68s - 1494.68s | It happens before we get started web server. 1494.68s - 1503.98s | We cannot send any other request to trigger any gadget. 1503.98s - 1512.98s | It means we can only control the prototype pollution point. 1512.98s - 1519.98s | And it's some difficulty with that because nothing dangerous happened between restarting Kibana 1519.98s - 1525.98s | and prototype pollution triggering and the crash of the application. 1525.98s - 1535.98s | It just tried to load some modules, tried to load configs, prepare some caches. 1535.98s - 1542.98s | Nothing dangerous like starting new process or evaluate some function. 1542.98s - 1546.98s | And the attack looks like unexploitable. 1546.98s - 1553.98s | So, you


chunk_id: 200_chunk_18
chunk_text:
It means we can edit it with admin privileges. 1448.60s - 1457.60s | So, we need some high-level privileges, but we can do this attack through the web. 1457.60s - 1468.68s | Attacker can store any payload in Kibana and restart Kibana to load all configs. 1468.68s - 1475.68s | The problem here that Kibana crashes immediately after prototype pollution, of course, 1475.68s - 1482.68s | because other code does not expect some properties, some additional properties in the object prototypes. 1482.68s - 1494.68s | It happens before we get started web server. 1494.68s - 1503.98s | We cannot send any other request to trigger any gadget. 1503.98s - 1512.98s | It means we can only control the prototype pollution point. 1512.98s - 1519.98s | And it's some difficulty with that because nothing dangerous happened between restarting Kibana 1519.98s - 1525.98s | and prototype pollution triggering and the crash of the application. 1525.98s - 1535.98s | It just tried to load some modules, tried to load configs, prepare some caches. 1535.98s - 1542.98s | Nothing dangerous like starting new process or evaluate some function. 1542.98s - 1546.98s | And the attack looks like unexploitable. 1546.98s - 1553.98s | So, you can achieve denial of the service, but if you are administrator and you restart Kibana, 1553.98s - 1555.98s | it's nothing actually. 1555.98s - 1558.98s | What we can do in this case? 1558.98s - 1563.98s | Let's see what Kibana did before the crash. 1563.98s - 1566.98s | It tried to load some modules. 1566.98s - 1575.98s | It would be nice if we have a gadget in the require call that loads modules. 1575.98s - 1581.98s | Because the require, it will read the code that it loads from the module. 1581.98s - 1589.98s | And if we can replace the module to the own code, we can get remote code execution before the crash. 1589.98s - 1591.98s | That's a nice idea. 1591.98s - 1602.98s | And we already found the gadget in the require when we worked on the first paper, Silent Spring, that I mentioned today. 1603.98s - 1611.98s | Actually, we can run any malicious JS file through the prototype pollution. 1611.98s - 1616.98s | Let's see on the require gadget how it works. 1616.98s - 1622.98s | So, let's assume that we have the same prototype pollution from the first example. 1622.98s -


chunk_id: 200_chunk_19
chunk_text:
can achieve denial of the service, but if you are administrator and you restart Kibana, 1553.98s - 1555.98s | it's nothing actually. 1555.98s - 1558.98s | What we can do in this case? 1558.98s - 1563.98s | Let's see what Kibana did before the crash. 1563.98s - 1566.98s | It tried to load some modules. 1566.98s - 1575.98s | It would be nice if we have a gadget in the require call that loads modules. 1575.98s - 1581.98s | Because the require, it will read the code that it loads from the module. 1581.98s - 1589.98s | And if we can replace the module to the own code, we can get remote code execution before the crash. 1589.98s - 1591.98s | That's a nice idea. 1591.98s - 1602.98s | And we already found the gadget in the require when we worked on the first paper, Silent Spring, that I mentioned today. 1603.98s - 1611.98s | Actually, we can run any malicious JS file through the prototype pollution. 1611.98s - 1616.98s | Let's see on the require gadget how it works. 1616.98s - 1622.98s | So, let's assume that we have the same prototype pollution from the first example. 1622.98s - 1629.98s | And we can trigger and pollute some property main in the object prototype. 1630.98s - 1638.98s | We can pollute one more property environment and trigger or handle backup. 1638.98s - 1643.98s | Handle backup has only one line, a require to the some module. 1643.98s - 1651.98s | And when require tries to load the module bytes, it has such code. 1652.98s - 1654.98s | It do a load config. 1654.98s - 1671.42s | And for load config, this function returns the parsed JSON, like this one, with all properties from the config. 1671.42s - 1679.42s | But some package JSON, the configuration file, does not have main. 1679.42s - 1684.42s | In this case, the default behavior should be get index JS. 1684.42s - 1690.42s | But we have main read expression here. 1690.42s - 1697.42s | And it tries to read the main that we polluted before from the object prototype. 1697.42s - 1705.42s | It means we can read any JS file that exists in the system. 1706.42s - 1712.42s | And it's some limitation for the require gadget, but we combine it with another attack. 1712.42s - 1723.42s | If we can find


chunk_id: 200_chunk_20
chunk_text:
1629.98s | And we can trigger and pollute some property main in the object prototype. 1630.98s - 1638.98s | We can pollute one more property environment and trigger or handle backup. 1638.98s - 1643.98s | Handle backup has only one line, a require to the some module. 1643.98s - 1651.98s | And when require tries to load the module bytes, it has such code. 1652.98s - 1654.98s | It do a load config. 1654.98s - 1671.42s | And for load config, this function returns the parsed JSON, like this one, with all properties from the config. 1671.42s - 1679.42s | But some package JSON, the configuration file, does not have main. 1679.42s - 1684.42s | In this case, the default behavior should be get index JS. 1684.42s - 1690.42s | But we have main read expression here. 1690.42s - 1697.42s | And it tries to read the main that we polluted before from the object prototype. 1697.42s - 1705.42s | It means we can read any JS file that exists in the system. 1706.42s - 1712.42s | And it's some limitation for the require gadget, but we combine it with another attack. 1712.42s - 1723.42s | If we can find some JS file that, for example, start new process, do child process exec, we can combine it with another function. 1723.42s - 1731.42s | And npm JS, actually, when we load it, starts new process. 1731.42s - 1735.42s | It does such code. 1735.42s - 1737.42s | It executes spawn function. 1737.42s - 1744.42s | These two arguments, not executable process and some arguments. 1744.42s - 1752.42s | And the implementation on the spawn function, we have another gadget. 1752.42s - 1759.42s | Let's try to read property shell and nth from the options. 1759.42s - 1765.42s | And options was empty, undefined. 1765.42s - 1768.42s | It means it becomes an empty object. 1768.42s - 1774.42s | And when we read nth here, we read it from the empty object. 1774.42s - 1779.42s | And we actually read the value from the prototype. 1780.42s - 1781.42s | Okay. 1781.42s - 1783.42s | That's the idea of the require gadget. 1783.42s - 1789.42s | The problem is that this gadget has been fixed by Node.js team. 1789.42s - 1793.42s | And I already knew this when I found it. 1793.42s - 1798.42s | And in parallel, I worked on some


chunk_id: 200_chunk_21
chunk_text:
some JS file that, for example, start new process, do child process exec, we can combine it with another function. 1723.42s - 1731.42s | And npm JS, actually, when we load it, starts new process. 1731.42s - 1735.42s | It does such code. 1735.42s - 1737.42s | It executes spawn function. 1737.42s - 1744.42s | These two arguments, not executable process and some arguments. 1744.42s - 1752.42s | And the implementation on the spawn function, we have another gadget. 1752.42s - 1759.42s | Let's try to read property shell and nth from the options. 1759.42s - 1765.42s | And options was empty, undefined. 1765.42s - 1768.42s | It means it becomes an empty object. 1768.42s - 1774.42s | And when we read nth here, we read it from the empty object. 1774.42s - 1779.42s | And we actually read the value from the prototype. 1780.42s - 1781.42s | Okay. 1781.42s - 1783.42s | That's the idea of the require gadget. 1783.42s - 1789.42s | The problem is that this gadget has been fixed by Node.js team. 1789.42s - 1793.42s | And I already knew this when I found it. 1793.42s - 1798.42s | And in parallel, I worked on some other tool, some dynamic analysis. 1798.42s - 1799.42s | It's called gHunters. 1799.42s - 1803.42s | I described it in the last paper that we published. 1803.42s - 1808.42s | And that will be presented in using security in a few days, next week. 1809.42s - 1819.42s | And working on that tool, I investigated require gadget and the fix. 1819.42s - 1822.42s | And the require gadget looks like this. 1822.42s - 1825.42s | So, the code that we already saw. 1825.42s - 1827.42s | We have a load config. 1827.42s - 1832.42s | So, we have such code that read package JSON. 1832.42s - 1835.42s | Try to parse it by JSON parse. 1835.42s - 1841.42s | And JSON parse is an object that has an object prototype in the chain. 1841.42s - 1845.42s | And it tried to read the main property. 1845.42s - 1854.42s | And at that moment, it can read the polluted property if we already polluted main in the object prototype. 1854.42s - 1856.42s | So, this gadget. 1856.42s - 1858.42s | And Node.js team fixed it. 1858.42s - 1861.42s | So, the fix looks like this. 1861.42s - 1870.42s | They wrote


chunk_id: 200_chunk_22
chunk_text:
other tool, some dynamic analysis. 1798.42s - 1799.42s | It's called gHunters. 1799.42s - 1803.42s | I described it in the last paper that we published. 1803.42s - 1808.42s | And that will be presented in using security in a few days, next week. 1809.42s - 1819.42s | And working on that tool, I investigated require gadget and the fix. 1819.42s - 1822.42s | And the require gadget looks like this. 1822.42s - 1825.42s | So, the code that we already saw. 1825.42s - 1827.42s | We have a load config. 1827.42s - 1832.42s | So, we have such code that read package JSON. 1832.42s - 1835.42s | Try to parse it by JSON parse. 1835.42s - 1841.42s | And JSON parse is an object that has an object prototype in the chain. 1841.42s - 1845.42s | And it tried to read the main property. 1845.42s - 1854.42s | And at that moment, it can read the polluted property if we already polluted main in the object prototype. 1854.42s - 1856.42s | So, this gadget. 1856.42s - 1858.42s | And Node.js team fixed it. 1858.42s - 1861.42s | So, the fix looks like this. 1861.42s - 1870.42s | They wrote some filter on properties that actually read this list of properties exactly from the object itself. 1870.42s - 1873.42s | Does not check it in the prototype chain. 1873.42s - 1880.42s | So, it means we cannot affect reading on the main property anymore after that fix. 1880.42s - 1889.42s | But at some moment, gHunters start detect the require gadget again. 1889.42s - 1892.42s | In the new version of the Node.js. 1892.42s - 1896.42s | And I double checked all experiments. 1896.42s - 1900.42s | And I see that require detected again and again for some cases. 1900.42s - 1905.42s | And I start to see on this fix more closely. 1905.42s - 1909.42s | And it has another gadget. 1909.42s - 1911.42s | I will zoom in. 1911.42s - 1913.42s | You can see. 1913.42s - 1916.42s | Exactly in these slides. 1917.42s - 1920.42s | We have this if statement. 1920.42s - 1924.42s | If JSON is undefined, the function returns false. 1924.42s - 1929.42s | The function loadConfig returns false. 1929.42s - 1932.42s | ParseJSON becomes a false. 1932.42s - 1935.42s | And we try to read the main from the false. 1935.42s - 1940.42s


chunk_id: 200_chunk_23
chunk_text:
some filter on properties that actually read this list of properties exactly from the object itself. 1870.42s - 1873.42s | Does not check it in the prototype chain. 1873.42s - 1880.42s | So, it means we cannot affect reading on the main property anymore after that fix. 1880.42s - 1889.42s | But at some moment, gHunters start detect the require gadget again. 1889.42s - 1892.42s | In the new version of the Node.js. 1892.42s - 1896.42s | And I double checked all experiments. 1896.42s - 1900.42s | And I see that require detected again and again for some cases. 1900.42s - 1905.42s | And I start to see on this fix more closely. 1905.42s - 1909.42s | And it has another gadget. 1909.42s - 1911.42s | I will zoom in. 1911.42s - 1913.42s | You can see. 1913.42s - 1916.42s | Exactly in these slides. 1917.42s - 1920.42s | We have this if statement. 1920.42s - 1924.42s | If JSON is undefined, the function returns false. 1924.42s - 1929.42s | The function loadConfig returns false. 1929.42s - 1932.42s | ParseJSON becomes a false. 1932.42s - 1935.42s | And we try to read the main from the false. 1935.42s - 1940.42s | JSRuntime in this case tried to box primitive type, boolean type. 1940.42s - 1944.42s | And add object prototype in the prototype chain. 1944.42s - 1947.42s | And we again can read the main. 1947.42s - 1951.42s | But from the false, actually. 1951.42s - 1954.42s | So, it's new gadget. 1954.42s - 1957.42s | And when I figure out it. 1957.42s - 1969.42s | So, I add the payload for the require in the original Kibana YAML file. 1969.42s - 1973.42s | And it allows us to exploit this prototype pollution. 1973.42s - 1978.42s | And achieve remote code execution. 1978.42s - 1983.42s | So, this vulnerability did not get a high score. 1983.42s - 1986.42s | Because it required high privileged user. 1986.42s - 1990.42s | But still it's almost 4,000 bounces. 1990.42s - 1994.74s | Let's see on the next story. 1994.74s - 1998.74s | About prototype pollution and remote code execution. 1998.74s - 2003.74s | Another case that was reported by our script. 2003.74s - 2007.74s | SilentSpring Node.js queries. 2007.74s - 2012.74s | Was a prototype pollution in some handler. 2012.74s - 2014.74s | Web handler. 2014.74s - 2016.74s | So, it's very simple


chunk_id: 200_chunk_24
chunk_text:
| JSRuntime in this case tried to box primitive type, boolean type. 1940.42s - 1944.42s | And add object prototype in the prototype chain. 1944.42s - 1947.42s | And we again can read the main. 1947.42s - 1951.42s | But from the false, actually. 1951.42s - 1954.42s | So, it's new gadget. 1954.42s - 1957.42s | And when I figure out it. 1957.42s - 1969.42s | So, I add the payload for the require in the original Kibana YAML file. 1969.42s - 1973.42s | And it allows us to exploit this prototype pollution. 1973.42s - 1978.42s | And achieve remote code execution. 1978.42s - 1983.42s | So, this vulnerability did not get a high score. 1983.42s - 1986.42s | Because it required high privileged user. 1986.42s - 1990.42s | But still it's almost 4,000 bounces. 1990.42s - 1994.74s | Let's see on the next story. 1994.74s - 1998.74s | About prototype pollution and remote code execution. 1998.74s - 2003.74s | Another case that was reported by our script. 2003.74s - 2007.74s | SilentSpring Node.js queries. 2007.74s - 2012.74s | Was a prototype pollution in some handler. 2012.74s - 2014.74s | Web handler. 2014.74s - 2016.74s | So, it's very simple prototype pollution. 2016.74s - 2019.74s | You can see we create empty object. 2019.74s - 2024.74s | It means this object has the prototype points to the object prototype. 2024.74s - 2028.74s | And we have this line of the code. 2028.74s - 2033.74s | If namespace is __prot__. 2033.74s - 2037.74s | And the key is the key controlled by the attacker. 2037.74s - 2039.74s | That's all. 2039.74s - 2042.74s | And the value also can be controlled by the attacker. 2042.74s - 2046.74s | It means we can add any key with controlled value to the object prototype. 2046.74s - 2048.74s | Very simple. 2048.74s - 2051.74s | You don't even need a script to find it. 2052.74s - 2056.43s | Okay. 2056.43s - 2060.43s | So, when I started working on this script. 2060.43s - 2062.43s | The question, we need to find a gadget. 2062.43s - 2064.43s | We worked on the Dusty. 2064.43s - 2068.43s | It's another project that detected 49 gadgets. 2068.43s - 2073.43s | Leading to remote code execution in NPM packages. 2073.43s - 2078.43s | We took 1,000 popular NPM packages. 2078.43s - 2083.43s | And run dynamic analysis that


chunk_id: 200_chunk_25
chunk_text:
prototype pollution. 2016.74s - 2019.74s | You can see we create empty object. 2019.74s - 2024.74s | It means this object has the prototype points to the object prototype. 2024.74s - 2028.74s | And we have this line of the code. 2028.74s - 2033.74s | If namespace is __prot__. 2033.74s - 2037.74s | And the key is the key controlled by the attacker. 2037.74s - 2039.74s | That's all. 2039.74s - 2042.74s | And the value also can be controlled by the attacker. 2042.74s - 2046.74s | It means we can add any key with controlled value to the object prototype. 2046.74s - 2048.74s | Very simple. 2048.74s - 2051.74s | You don't even need a script to find it. 2052.74s - 2056.43s | Okay. 2056.43s - 2060.43s | So, when I started working on this script. 2060.43s - 2062.43s | The question, we need to find a gadget. 2062.43s - 2064.43s | We worked on the Dusty. 2064.43s - 2068.43s | It's another project that detected 49 gadgets. 2068.43s - 2073.43s | Leading to remote code execution in NPM packages. 2073.43s - 2078.43s | We took 1,000 popular NPM packages. 2078.43s - 2083.43s | And run dynamic analysis that try to instrument the package. 2083.43s - 2087.43s | And investigate what the flows can lead to. 2087.43s - 2091.43s | Read the properties from the prototype. 2091.43s - 2094.43s | And can lead to remote code execution in NPM. 2094.43s - 2102.43s | And one of the package that has gadget was NodeMailer. 2102.43s - 2107.43s | And Kibana uses this gadget to send emails. 2107.43s - 2114.43s | So, the idea, we have some send mailer transport that's optional. 2114.43s - 2118.43s | But you also can pollute some option to enable it. 2118.43s - 2127.43s | And it has some options that's by default empty. 2128.43s - 2135.43s | And if we have path in the options. 2135.43s - 2139.43s | The path of the run program that should be send mailer. 2139.43s - 2143.43s | And args will be read from the options object. 2143.43s - 2145.43s | And prototype in our case. 2145.43s - 2147.43s | And send to the spawn function. 2147.43s - 2149.43s | Okay. 2149.43s - 2151.43s | So, it means we can inject any command. 2151.43s - 2158.43s | And execute, start any process on the victim machine. 2158.43s - 2165.86s


chunk_id: 200_chunk_26
chunk_text:
try to instrument the package. 2083.43s - 2087.43s | And investigate what the flows can lead to. 2087.43s - 2091.43s | Read the properties from the prototype. 2091.43s - 2094.43s | And can lead to remote code execution in NPM. 2094.43s - 2102.43s | And one of the package that has gadget was NodeMailer. 2102.43s - 2107.43s | And Kibana uses this gadget to send emails. 2107.43s - 2114.43s | So, the idea, we have some send mailer transport that's optional. 2114.43s - 2118.43s | But you also can pollute some option to enable it. 2118.43s - 2127.43s | And it has some options that's by default empty. 2128.43s - 2135.43s | And if we have path in the options. 2135.43s - 2139.43s | The path of the run program that should be send mailer. 2139.43s - 2143.43s | And args will be read from the options object. 2143.43s - 2145.43s | And prototype in our case. 2145.43s - 2147.43s | And send to the spawn function. 2147.43s - 2149.43s | Okay. 2149.43s - 2151.43s | So, it means we can inject any command. 2151.43s - 2158.43s | And execute, start any process on the victim machine. 2158.43s - 2165.86s | But the problem that delete handler creates the application. 2165.86s - 2169.86s | In less than one second after the prototype pollution. 2169.86s - 2172.86s | So, it's also becomes immediately. 2172.86s - 2176.86s | Because some code in the end of the handler, of the same handler. 2176.86s - 2179.86s | Does not expect the property, some additional property. 2179.86s - 2182.86s | And throw exception that's not handled correctly. 2182.86s - 2184.86s | And we get denial of the service. 2184.86s - 2189.86s | That's not much interesting for such vulnerability. 2189.86s - 2192.86s | So, it looks like unexploitable. 2192.86s - 2194.86s | Denial of the service. 2194.86s - 2199.86s | I could not say that it's interesting impact that we want to show. 2199.86s - 2204.86s | But if we try to emulate some race condition. 2204.86s - 2209.86s | By sending a lot of gadget triggered request in parallel. 2209.86s - 2213.86s | And one prototype pollution triggered request between them. 2213.86s - 2220.86s | We can try to get the situation that gadget triggered request. 2220.86s - 2227.86s | Will be in the small time exactly after the prototype pollution request. 2227.86s -


chunk_id: 200_chunk_27
chunk_text:
| But the problem that delete handler creates the application. 2165.86s - 2169.86s | In less than one second after the prototype pollution. 2169.86s - 2172.86s | So, it's also becomes immediately. 2172.86s - 2176.86s | Because some code in the end of the handler, of the same handler. 2176.86s - 2179.86s | Does not expect the property, some additional property. 2179.86s - 2182.86s | And throw exception that's not handled correctly. 2182.86s - 2184.86s | And we get denial of the service. 2184.86s - 2189.86s | That's not much interesting for such vulnerability. 2189.86s - 2192.86s | So, it looks like unexploitable. 2192.86s - 2194.86s | Denial of the service. 2194.86s - 2199.86s | I could not say that it's interesting impact that we want to show. 2199.86s - 2204.86s | But if we try to emulate some race condition. 2204.86s - 2209.86s | By sending a lot of gadget triggered request in parallel. 2209.86s - 2213.86s | And one prototype pollution triggered request between them. 2213.86s - 2220.86s | We can try to get the situation that gadget triggered request. 2220.86s - 2227.86s | Will be in the small time exactly after the prototype pollution request. 2227.86s - 2231.86s | Let me explain it based on the script. 2231.86s - 2233.86s | On the exploit script. 2234.86s - 2240.86s | So, we can implement such race condition exploit on the bash. 2240.86s - 2242.86s | Or any other language. 2242.86s - 2244.86s | So, the idea. 2244.86s - 2249.86s | We send 20 requests that trigger a gadget first. 2249.86s - 2254.86s | And after that we send the request that trigger a prototype pollution. 2254.86s - 2260.86s | And after that we send 50 requests that trigger a gadget again. 2260.86s - 2270.86s | And this ampersand means that all of these commands will be executed in parallel. 2270.86s - 2273.86s | So, we send a lot request. 2273.86s - 2277.86s | Let's see how it works in the demo. 2277.86s - 2281.86s | So, I run it from my laptop. 2281.86s - 2284.86s | Through the Wi-Fi. 2285.86s - 2294.86s | And first of all I start some payload that created email connector. 2294.86s - 2302.86s | That we need to know to send the request to trigger node mailer package. 2302.86s - 2311.86s | So, we change in this or exploit SH script this connector.


chunk_id: 200_chunk_28
chunk_text:
2231.86s | Let me explain it based on the script. 2231.86s - 2233.86s | On the exploit script. 2234.86s - 2240.86s | So, we can implement such race condition exploit on the bash. 2240.86s - 2242.86s | Or any other language. 2242.86s - 2244.86s | So, the idea. 2244.86s - 2249.86s | We send 20 requests that trigger a gadget first. 2249.86s - 2254.86s | And after that we send the request that trigger a prototype pollution. 2254.86s - 2260.86s | And after that we send 50 requests that trigger a gadget again. 2260.86s - 2270.86s | And this ampersand means that all of these commands will be executed in parallel. 2270.86s - 2273.86s | So, we send a lot request. 2273.86s - 2277.86s | Let's see how it works in the demo. 2277.86s - 2281.86s | So, I run it from my laptop. 2281.86s - 2284.86s | Through the Wi-Fi. 2285.86s - 2294.86s | And first of all I start some payload that created email connector. 2294.86s - 2302.86s | That we need to know to send the request to trigger node mailer package. 2302.86s - 2311.86s | So, we change in this or exploit SH script this connector. 2312.86s - 2315.86s | And run the exploit script. 2315.86s - 2321.86s | And I started this webpage to see which request we will get. 2321.86s - 2323.86s | So, I did not run a reverse shell. 2323.86s - 2329.86s | I just sent a request to this webpage. 2329.86s - 2335.86s | You can see that five requests will be successfully received. 2335.86s - 2346.86s | It means that five cases will be for so short time that were executed before the crash. 2346.86s - 2350.86s | So, this attack was run from the Wi-Fi. 2350.86s - 2358.86s | You can get more interesting, I guess, if you run it on the same server in the same network like in cloud or some places. 2359.86s - 2360.86s | Okay. 2360.86s - 2367.86s | This attack give me biggest bounty that I got from the Elastic. 2367.86s - 2371.86s | And not only this prototype pollution that I reported was exploited. 2371.86s - 2374.86s | This case was closed a few days ago. 2374.86s - 2377.86s | I did not have time to edit in the presentation. 2377.86s - 2380.86s | And also we don't have much time. 2380.86s -


chunk_id: 200_chunk_29
chunk_text:
2312.86s - 2315.86s | And run the exploit script. 2315.86s - 2321.86s | And I started this webpage to see which request we will get. 2321.86s - 2323.86s | So, I did not run a reverse shell. 2323.86s - 2329.86s | I just sent a request to this webpage. 2329.86s - 2335.86s | You can see that five requests will be successfully received. 2335.86s - 2346.86s | It means that five cases will be for so short time that were executed before the crash. 2346.86s - 2350.86s | So, this attack was run from the Wi-Fi. 2350.86s - 2358.86s | You can get more interesting, I guess, if you run it on the same server in the same network like in cloud or some places. 2359.86s - 2360.86s | Okay. 2360.86s - 2367.86s | This attack give me biggest bounty that I got from the Elastic. 2367.86s - 2371.86s | And not only this prototype pollution that I reported was exploited. 2371.86s - 2374.86s | This case was closed a few days ago. 2374.86s - 2377.86s | I did not have time to edit in the presentation. 2377.86s - 2380.86s | And also we don't have much time. 2380.86s - 2384.86s | And another case that was reported also. 2384.86s - 2388.86s | This is a chain that leads to account takeover. 2388.86s - 2392.86s | Maybe I will do it in the next presentation. 2392.86s - 2393.86s | Let's see. 2395.86s - 2405.86s | As a bonus part, I want to explain some advanced technique for the prototype pollution. 2405.86s - 2409.86s | When we pollute the objects in the prototype, not the prototype itself. 2412.86s - 2423.86s | When I understood this trick, it allows me to report few new vulnerabilities that I actually thought unexploitable before. 2423.86s - 2425.86s | Let's see on the example. 2425.86s - 2431.86s | We have a prototype pollution from our original example. 2431.86s - 2433.86s | Very simple code that we already know. 2433.86s - 2434.86s | We have a gadget. 2434.86s - 2443.86s | The gadget read options and check the property runner. 2443.86s - 2447.86s | So the options empty object by default. 2447.86s - 2457.86s | And if the runner is defined, we read paths and arcs and spawn a new process for that. 2457.86s - 2462.86s | So it means we need to pollute a runner in


chunk_id: 200_chunk_30
chunk_text:
2384.86s | And another case that was reported also. 2384.86s - 2388.86s | This is a chain that leads to account takeover. 2388.86s - 2392.86s | Maybe I will do it in the next presentation. 2392.86s - 2393.86s | Let's see. 2395.86s - 2405.86s | As a bonus part, I want to explain some advanced technique for the prototype pollution. 2405.86s - 2409.86s | When we pollute the objects in the prototype, not the prototype itself. 2412.86s - 2423.86s | When I understood this trick, it allows me to report few new vulnerabilities that I actually thought unexploitable before. 2423.86s - 2425.86s | Let's see on the example. 2425.86s - 2431.86s | We have a prototype pollution from our original example. 2431.86s - 2433.86s | Very simple code that we already know. 2433.86s - 2434.86s | We have a gadget. 2434.86s - 2443.86s | The gadget read options and check the property runner. 2443.86s - 2447.86s | So the options empty object by default. 2447.86s - 2457.86s | And if the runner is defined, we read paths and arcs and spawn a new process for that. 2457.86s - 2462.86s | So it means we need to pollute a runner in the object prototype. 2462.86s - 2463.86s | So like this. 2463.86s - 2471.86s | So we add a runner with this object as a value. 2471.86s - 2472.86s | Okay. 2472.86s - 2479.86s | And after that we trigger handleback, of course, to trigger a gadget. 2479.86s - 2488.86s | What if this prototype pollution does not allow us to control the value? 2488.86s - 2494.86s | For example, it's some object with predefined identifier or another properties. 2494.86s - 2496.86s | We cannot control it. 2496.86s - 2499.86s | Or it's empty array. 2499.86s - 2502.86s | Array does not have any properties. 2502.86s - 2503.86s | Right? 2503.86s - 2507.86s | So it looks like unexploitable. 2507.86s - 2509.86s | At least for such gadget. 2509.86s - 2512.86s | Maximum we can get denial of the service. 2512.86s - 2517.86s | But what if we have such code? 2517.86s - 2518.86s | It's fixed. 2518.86s - 2520.86s | I call it fixed prototype pollution. 2520.86s - 2529.86s | We check that org does not equal a proto and execute this code only for that. 2529.86s - 2532.86s | It cannot lead to prototype pollution. 2532.86s - 2539.86s |


chunk_id: 200_chunk_31
chunk_text:
the object prototype. 2462.86s - 2463.86s | So like this. 2463.86s - 2471.86s | So we add a runner with this object as a value. 2471.86s - 2472.86s | Okay. 2472.86s - 2479.86s | And after that we trigger handleback, of course, to trigger a gadget. 2479.86s - 2488.86s | What if this prototype pollution does not allow us to control the value? 2488.86s - 2494.86s | For example, it's some object with predefined identifier or another properties. 2494.86s - 2496.86s | We cannot control it. 2496.86s - 2499.86s | Or it's empty array. 2499.86s - 2502.86s | Array does not have any properties. 2502.86s - 2503.86s | Right? 2503.86s - 2507.86s | So it looks like unexploitable. 2507.86s - 2509.86s | At least for such gadget. 2509.86s - 2512.86s | Maximum we can get denial of the service. 2512.86s - 2517.86s | But what if we have such code? 2517.86s - 2518.86s | It's fixed. 2518.86s - 2520.86s | I call it fixed prototype pollution. 2520.86s - 2529.86s | We check that org does not equal a proto and execute this code only for that. 2529.86s - 2532.86s | It cannot lead to prototype pollution. 2532.86s - 2539.86s | But we can combine these two code snippets. 2539.86s - 2546.86s | So it's absolutely safe code separately from this one. 2546.86s - 2549.86s | But what we can do together with these components? 2549.86s - 2552.86s | First of all, we need to pollute the prototype. 2552.86s - 2560.86s | We add a runner with a value of empty array in the prototype to trigger handle update. 2560.86s - 2562.86s | Good. 2562.86s - 2574.42s | After that, we trigger this save function with org that has a runner value. 2574.42s - 2580.42s | It means we will try to read the runner from the prototype at this step. 2580.42s - 2583.42s | And we pollute the runner after that. 2583.42s - 2589.42s | We can't feel any additional properties in the runner. 2589.42s - 2591.42s | By this call and the second call. 2591.42s - 2595.42s | And after that, we trigger backup handler. 2595.42s - 2601.42s | It gives us the remote code execution again by this chain of the calls. 2602.42s - 2606.42s | The web request that triggers such functions. 2606.42s - 2611.42s | If you think that it's unlikely that we find some fixed


chunk_id: 200_chunk_32
chunk_text:
But we can combine these two code snippets. 2539.86s - 2546.86s | So it's absolutely safe code separately from this one. 2546.86s - 2549.86s | But what we can do together with these components? 2549.86s - 2552.86s | First of all, we need to pollute the prototype. 2552.86s - 2560.86s | We add a runner with a value of empty array in the prototype to trigger handle update. 2560.86s - 2562.86s | Good. 2562.86s - 2574.42s | After that, we trigger this save function with org that has a runner value. 2574.42s - 2580.42s | It means we will try to read the runner from the prototype at this step. 2580.42s - 2583.42s | And we pollute the runner after that. 2583.42s - 2589.42s | We can't feel any additional properties in the runner. 2589.42s - 2591.42s | By this call and the second call. 2591.42s - 2595.42s | And after that, we trigger backup handler. 2595.42s - 2601.42s | It gives us the remote code execution again by this chain of the calls. 2602.42s - 2606.42s | The web request that triggers such functions. 2606.42s - 2611.42s | If you think that it's unlikely that we find some fixed prototype pollution case 2611.42s - 2616.42s | and unfixed prototype pollution case in the same application, 2616.42s - 2619.42s | I can say to you that, for example, 2619.42s - 2628.42s | merge functions are very typical in the fixed prototype pollutions. 2628.42s - 2638.42s | A merge function of the very popular package lodash allows us to pollute a runner with such payload. 2638.42s - 2643.42s | And you can find lodash merge calls in many applications. 2643.42s - 2647.42s | And that's important that these two parts can be unrelated. 2647.42s - 2655.42s | It could be absolutely different features in the application. 2656.42s - 2660.42s | Use it for fun and bounces. 2660.42s - 2667.42s | In conclusion, in this talk, I wanted to show the cases that look unexploitable. 2667.42s - 2670.42s | And say, don't give up. 2670.42s - 2676.42s | Try to achieve remote code execution even when it looks impossible. 2676.42s - 2681.42s | If you're interested in prototype pollution research, check out our papers. 2681.42s - 2685.42s | SilentSpring, G-Hunter and Dusty that I mentioned in the talk. 2685.42s - 2692.42s | Check out the collection of server-side prototype pollution gadgets that


chunk_id: 200_chunk_33
chunk_text:
prototype pollution case 2611.42s - 2616.42s | and unfixed prototype pollution case in the same application, 2616.42s - 2619.42s | I can say to you that, for example, 2619.42s - 2628.42s | merge functions are very typical in the fixed prototype pollutions. 2628.42s - 2638.42s | A merge function of the very popular package lodash allows us to pollute a runner with such payload. 2638.42s - 2643.42s | And you can find lodash merge calls in many applications. 2643.42s - 2647.42s | And that's important that these two parts can be unrelated. 2647.42s - 2655.42s | It could be absolutely different features in the application. 2656.42s - 2660.42s | Use it for fun and bounces. 2660.42s - 2667.42s | In conclusion, in this talk, I wanted to show the cases that look unexploitable. 2667.42s - 2670.42s | And say, don't give up. 2670.42s - 2676.42s | Try to achieve remote code execution even when it looks impossible. 2676.42s - 2681.42s | If you're interested in prototype pollution research, check out our papers. 2681.42s - 2685.42s | SilentSpring, G-Hunter and Dusty that I mentioned in the talk. 2685.42s - 2692.42s | Check out the collection of server-side prototype pollution gadgets that we shared. 2692.42s - 2701.42s | This is a gadget in Node.js itself and Deno and NPM packages that I also use in my bug bounty cases. 2701.42s - 2709.42s | If you're interested in networking attacks and this story about ARP spoofing, 2709.42s - 2712.42s | I highly recommend to read this blog post. 2712.42s - 2717.42s | ARP spoofing in Kubernetes is not so easy as it looks like. 2717.42s - 2726.42s | It also has some difficulties with IP table rules that was bypassed by this talk. 2726.42s - 2729.42s | Check out this blog post. 2729.42s - 2731.42s | I think you'll enjoy it. 2731.42s - 2737.42s | And follow me on Twitter if you're interested in some details of code reuse attacks. 2737.42s - 2742.42s | I want to share some findings that I am now including in my thesis. 2742.42s - 2746.42s | And thank you for your attention. 2746.42s - 2748.42s | Enjoy DEF CON. 2748.42s - 2749.42s | Bye-bye.


chunk_id: 200_chunk_34
chunk_text:
we shared. 2692.42s - 2701.42s | This is a gadget in Node.js itself and Deno and NPM packages that I also use in my bug bounty cases. 2701.42s - 2709.42s | If you're interested in networking attacks and this story about ARP spoofing, 2709.42s - 2712.42s | I highly recommend to read this blog post. 2712.42s - 2717.42s | ARP spoofing in Kubernetes is not so easy as it looks like. 2717.42s - 2726.42s | It also has some difficulties with IP table rules that was bypassed by this talk. 2726.42s - 2729.42s | Check out this blog post. 2729.42s - 2731.42s | I think you'll enjoy it. 2731.42s - 2737.42s | And follow me on Twitter if you're interested in some details of code reuse attacks. 2737.42s - 2742.42s | I want to share some findings that I am now including in my thesis. 2742.42s - 2746.42s | And thank you for your attention. 2746.42s - 2748.42s | Enjoy DEF CON. 2748.42s - 2749.42s | Bye-bye.


chunk_id: 201_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=Eyl_0YxfnpQ", "title": "DEF CON 32 - Using ALPC security features to compromise RPC services - WanJunJie Zhang, Yisheng He", "description": "Advanced Local Procedure Call (ALPC) is an Inter Process Communication method in the Windows kernel. In the past few years, Windows ALPC and RPC vulnerabilities have emerged in an endless stream. These vulnerabilities are mainly based on TOCTOU file operations, memory corruption vulnerabilities in RPC services and ALPC syscalls in ntoskrnl.\n\nWindows kernel provides a variety of security measures to ensure that the data and context accepted by the ALPC and RPC servers are safe. We noticed the attack surface in the security mechanism of the ALPC kernel, and we found a security flaw in this mechanism (magic) and successfully obtained the system privilege from unauthorized users (defeating magic by magic).\n\nIn this talk, we will first overview the communication mechanism of ALPC and RPC services. We will discuss the details of ALPC and RPC in the marshal/unmarshal process that has not been disclosed before. We'll also talk about the kernel security mechanism in ALPC syscalls. Then we will analyze some historical bugs in ALPC and RPC, and disclose the details of the vulnerability we found, discussing how we bypassed the security mechanism through a small security flaw in security mechanisms. Later we'll discuss the exploitation, you will learn about the multiple ways. Finally, We'll make conclusions and share our opinions on this attack surface, including some tips and opinions on how to find these kinds of bugs.\n\nA view into ALPC-RPC by Clement Rouault and Thomas Imbert Hack.lu 2017\nExploiting Errors in Windows Error Reporting - Gal De Leon\nWindows Internals, Part 2, 7th Edition", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2637, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.07s - 4.75s | This text was transcribed using whisper model: large-v2 I can start? 4.75s - 8.66s | Okay. 8.66s - 9.66s | Yeah. 9.66s - 10.66s | Yeah. 10.66s - 11.66s | Yeah. 11.66s - 14.07s | Yeah. 14.07s - 15.07s | Thank you. 15.07s - 16.07s | It's good to be here. 16.07s - 17.07s | Yeah. 17.07s - 18.07s | I'm Wang Junjie Zhang. 18.07s - 19.07s | Yeah. 19.07s - 28.19s | I'm a security researcher from the Hailstone Networks. 28.19s - 34.59s | My research direction is Windows vulnerability research, including the user mode and the 34.59s - 36.83s | kernel mode. 36.83s - 44.91s | And also, I've been


chunk_id: 201_chunk_1
chunk_text:
the security mechanism through a small security flaw in security mechanisms. Later we'll discuss the exploitation, you will learn about the multiple ways. Finally, We'll make conclusions and share our opinions on this attack surface, including some tips and opinions on how to find these kinds of bugs.\n\nA view into ALPC-RPC by Clement Rouault and Thomas Imbert Hack.lu 2017\nExploiting Errors in Windows Error Reporting - Gal De Leon\nWindows Internals, Part 2, 7th Edition", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2637, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.07s - 4.75s | This text was transcribed using whisper model: large-v2 I can start? 4.75s - 8.66s | Okay. 8.66s - 9.66s | Yeah. 9.66s - 10.66s | Yeah. 10.66s - 11.66s | Yeah. 11.66s - 14.07s | Yeah. 14.07s - 15.07s | Thank you. 15.07s - 16.07s | It's good to be here. 16.07s - 17.07s | Yeah. 17.07s - 18.07s | I'm Wang Junjie Zhang. 18.07s - 19.07s | Yeah. 19.07s - 28.19s | I'm a security researcher from the Hailstone Networks. 28.19s - 34.59s | My research direction is Windows vulnerability research, including the user mode and the 34.59s - 36.83s | kernel mode. 36.83s - 44.91s | And also, I've been listed as the most valuable researcher of the Microsoft 2020, 2022, and 44.91s - 46.91s | 2023, 2024. 46.91s - 47.91s | Yeah. 47.91s - 48.91s | Okay. 48.91s - 55.63s | So, let's just start my talk. 55.63s - 56.63s | And this is... 56.63s - 62.43s | I already introduced myself and our colleague here. 62.43s - 67.51s | Firstly, let's see our agenda today. 67.51s - 70.71s | It mainly consists of four parts. 70.71s - 74.51s | We'll introduce architecture of the LPC and RPC. 74.51s - 81.15s | So we will have a deeper understanding of it, and then look at some common vulnerabilities 81.15s - 84.83s | inside LPC and RPC. 84.83s - 89.35s | And we will study some root cause of the vulnerabilities. 89.35s - 94.59s | And then I will share some details of the vulnerabilities I found by myself and my team, 94.59s - 99.63s | and which can bypass the LPC, RPC security mechanism. 99.63s - 106.99s | I will show you step-by-step to use this small security flaw to bypass the security mitigations 106.99s - 111.99s | like ACR, DEP, XFG, and finally, get system shell. 111.99s -


chunk_id: 201_chunk_2
chunk_text:
listed as the most valuable researcher of the Microsoft 2020, 2022, and 44.91s - 46.91s | 2023, 2024. 46.91s - 47.91s | Yeah. 47.91s - 48.91s | Okay. 48.91s - 55.63s | So, let's just start my talk. 55.63s - 56.63s | And this is... 56.63s - 62.43s | I already introduced myself and our colleague here. 62.43s - 67.51s | Firstly, let's see our agenda today. 67.51s - 70.71s | It mainly consists of four parts. 70.71s - 74.51s | We'll introduce architecture of the LPC and RPC. 74.51s - 81.15s | So we will have a deeper understanding of it, and then look at some common vulnerabilities 81.15s - 84.83s | inside LPC and RPC. 84.83s - 89.35s | And we will study some root cause of the vulnerabilities. 89.35s - 94.59s | And then I will share some details of the vulnerabilities I found by myself and my team, 94.59s - 99.63s | and which can bypass the LPC, RPC security mechanism. 99.63s - 106.99s | I will show you step-by-step to use this small security flaw to bypass the security mitigations 106.99s - 111.99s | like ACR, DEP, XFG, and finally, get system shell. 111.99s - 114.43s | You won't get it from anywhere else. 114.43s - 115.43s | So... 115.43s - 119.71s | And that's the way I make a conclusion. 119.71s - 120.71s | Yeah. 120.71s - 124.23s | So it's architecture, yeah. 124.23s - 131.99s | We already know LPC was introduced to replace the ARPC. 131.99s - 140.95s | It's called Lightweight Procedure Core, mainly used in Windows system, inside the Windows 140.95s - 143.47s | system services. 143.47s - 152.40s | And it's concerned by many researchers for its huge attack service. 152.40s - 158.20s | And this is a LPC and RPC architecture. 158.20s - 168.76s | And why we combine the ARPC and RPC together? 168.76s - 171.02s | Why we combine it together? 171.02s - 177.10s | For reason listed below, most RPC services is based on the ARPC or NAND pipe. 177.10s - 181.50s | So it's almost based on the same security mechanism. 181.50s - 189.62s | And the security flaw inside the ARPC can affect the security of RPC services. 189.62s - 194.70s | And this is also the architecture of the ARPC, RPC from Windows internal. 194.70s - 199.46s | You can see the


chunk_id: 201_chunk_3
chunk_text:
114.43s | You won't get it from anywhere else. 114.43s - 115.43s | So... 115.43s - 119.71s | And that's the way I make a conclusion. 119.71s - 120.71s | Yeah. 120.71s - 124.23s | So it's architecture, yeah. 124.23s - 131.99s | We already know LPC was introduced to replace the ARPC. 131.99s - 140.95s | It's called Lightweight Procedure Core, mainly used in Windows system, inside the Windows 140.95s - 143.47s | system services. 143.47s - 152.40s | And it's concerned by many researchers for its huge attack service. 152.40s - 158.20s | And this is a LPC and RPC architecture. 158.20s - 168.76s | And why we combine the ARPC and RPC together? 168.76s - 171.02s | Why we combine it together? 171.02s - 177.10s | For reason listed below, most RPC services is based on the ARPC or NAND pipe. 177.10s - 181.50s | So it's almost based on the same security mechanism. 181.50s - 189.62s | And the security flaw inside the ARPC can affect the security of RPC services. 189.62s - 194.70s | And this is also the architecture of the ARPC, RPC from Windows internal. 194.70s - 199.46s | You can see the communication module inside it. 199.46s - 204.46s | And it also supports some message queries and some share section. 204.46s - 210.77s | Also supports share section to pass the message. 210.77s - 214.95s | Why we use section here? 214.95s - 220.45s | Because it's a more effective data passing mechanism on Windows section object. 220.45s - 222.17s | More efficient and fast. 222.17s - 223.17s | And what about the region? 223.17s - 224.17s | Why region? 224.17s - 229.29s | It's a representative range of the shared memory that can be opened within the context 229.29s - 231.17s | of a given port. 231.17s - 237.41s | The section can be shared access by one process, which only have right access. 237.41s - 242.49s | And meanwhile, the client only have the right access. 242.49s - 245.89s | This picture describe the relationship between the section. 245.89s - 246.89s | Yeah. 246.89s - 251.45s | We can split up the whole section into different region. 251.45s - 255.81s | One piece is represented by one region object. 255.81s - 261.09s | We have a set size, which is representing the map of the set and the size


chunk_id: 201_chunk_4
chunk_text:
communication module inside it. 199.46s - 204.46s | And it also supports some message queries and some share section. 204.46s - 210.77s | Also supports share section to pass the message. 210.77s - 214.95s | Why we use section here? 214.95s - 220.45s | Because it's a more effective data passing mechanism on Windows section object. 220.45s - 222.17s | More efficient and fast. 222.17s - 223.17s | And what about the region? 223.17s - 224.17s | Why region? 224.17s - 229.29s | It's a representative range of the shared memory that can be opened within the context 229.29s - 231.17s | of a given port. 231.17s - 237.41s | The section can be shared access by one process, which only have right access. 237.41s - 242.49s | And meanwhile, the client only have the right access. 242.49s - 245.89s | This picture describe the relationship between the section. 245.89s - 246.89s | Yeah. 246.89s - 251.45s | We can split up the whole section into different region. 251.45s - 255.81s | One piece is represented by one region object. 255.81s - 261.09s | We have a set size, which is representing the map of the set and the size of the set 261.09s - 262.09s | section. 262.09s - 263.09s | Yeah. 263.09s - 271.61s | I see some historical vulnerabilities, yeah. 271.61s - 279.49s | First kind of bug is kind of logical bug in ARPC when, you know, there's too much research 279.49s - 289.61s | on the internet related to doing when the service doing some file operations, is a need 289.61s - 295.05s | to impersonate the colors or token and doing some operations on file. 295.05s - 300.73s | However, you know, sometimes the fellows will probably handle the file operation with a 300.73s - 303.33s | file like a symbol link. 303.33s - 310.65s | It may be resulting the service being able to modify, or write, or delete, and even create 310.65s - 315.45s | some files when client should not have the permission on these operations. 315.45s - 325.05s | So this vulnerability, CVE-2020 and 0911 is an example of the using users device map 325.05s - 333.81s | and impersonating users and the service will operate on malicious MSAI files in the user's 333.81s - 338.37s | device map installer directory, and it was directed to another path. 338.37s -


chunk_id: 201_chunk_5
chunk_text:
of the set 261.09s - 262.09s | section. 262.09s - 263.09s | Yeah. 263.09s - 271.61s | I see some historical vulnerabilities, yeah. 271.61s - 279.49s | First kind of bug is kind of logical bug in ARPC when, you know, there's too much research 279.49s - 289.61s | on the internet related to doing when the service doing some file operations, is a need 289.61s - 295.05s | to impersonate the colors or token and doing some operations on file. 295.05s - 300.73s | However, you know, sometimes the fellows will probably handle the file operation with a 300.73s - 303.33s | file like a symbol link. 303.33s - 310.65s | It may be resulting the service being able to modify, or write, or delete, and even create 310.65s - 315.45s | some files when client should not have the permission on these operations. 315.45s - 325.05s | So this vulnerability, CVE-2020 and 0911 is an example of the using users device map 325.05s - 333.81s | and impersonating users and the service will operate on malicious MSAI files in the user's 333.81s - 338.37s | device map installer directory, and it was directed to another path. 338.37s - 344.01s | So when the service revert to the system privilege, it also trust the content to read from the 344.01s - 348.21s | client installer directory and source. 348.21s - 355.01s | The privilege exhalation happen, yeah. 355.05s - 361.25s | So this kind of bug exhalation have much articles and research on the internet by using tricks 361.25s - 370.25s | of firstly, I think it's discovered by Google research by using tricks like NTFS junctions, 370.25s - 374.85s | higher link or object symbol links, and opportunities locks. 374.85s - 381.53s | You can easily write exhortations on this kind of bugs. 381.53s - 388.85s | The second example is malicious memory corruption bug inside the LPC RPC kernel in recent years. 388.85s - 395.57s | We have seen a lot of memory corruption issues inside the LPC RPC kernel. 395.57s - 400.45s | So the following code snippet is a part of the vulnerability and is associated with the 400.45s - 407.81s | LPC section blob object where we create a LPC section in the map legacy port view function. 407.81s - 412.97s | And there's a race window before the function with the view port,


chunk_id: 201_chunk_6
chunk_text:
344.01s | So when the service revert to the system privilege, it also trust the content to read from the 344.01s - 348.21s | client installer directory and source. 348.21s - 355.01s | The privilege exhalation happen, yeah. 355.05s - 361.25s | So this kind of bug exhalation have much articles and research on the internet by using tricks 361.25s - 370.25s | of firstly, I think it's discovered by Google research by using tricks like NTFS junctions, 370.25s - 374.85s | higher link or object symbol links, and opportunities locks. 374.85s - 381.53s | You can easily write exhortations on this kind of bugs. 381.53s - 388.85s | The second example is malicious memory corruption bug inside the LPC RPC kernel in recent years. 388.85s - 395.57s | We have seen a lot of memory corruption issues inside the LPC RPC kernel. 395.57s - 400.45s | So the following code snippet is a part of the vulnerability and is associated with the 400.45s - 407.81s | LPC section blob object where we create a LPC section in the map legacy port view function. 407.81s - 412.97s | And there's a race window before the function with the view port, view object. 412.97s - 421.85s | During this race window, attacker can destroy the LPC port object causing it LPC section 421.85s - 426.13s | view function access 3D pointer. 426.13s - 432.05s | The picture describe the race window in the connect port function. 432.05s - 440.33s | The kernel creates the first LPC port and we can try to close the handle table in the second thread. 440.33s - 445.77s | If this moment, close moment, between the create section and the create view port function, 445.77s - 447.73s | you can get a blue screen. 447.73s - 453.13s | But however, this kind of issue is, I think it's a little bit hard to exploit because you need to 453.13s - 456.33s | win the race first. 456.37s - 462.93s | What we observe is that most of these memory corruption bug inside LPC kernel or RPC services, 462.93s - 468.93s | and most of them are traditionally memory corruption bugs due to the server side lack of check 468.93s - 474.13s | when RPC services handle data from the client side. 474.13s - 479.97s | And last example is, I think it's very interesting, logical fallback


chunk_id: 201_chunk_7
chunk_text:
view object. 412.97s - 421.85s | During this race window, attacker can destroy the LPC port object causing it LPC section 421.85s - 426.13s | view function access 3D pointer. 426.13s - 432.05s | The picture describe the race window in the connect port function. 432.05s - 440.33s | The kernel creates the first LPC port and we can try to close the handle table in the second thread. 440.33s - 445.77s | If this moment, close moment, between the create section and the create view port function, 445.77s - 447.73s | you can get a blue screen. 447.73s - 453.13s | But however, this kind of issue is, I think it's a little bit hard to exploit because you need to 453.13s - 456.33s | win the race first. 456.37s - 462.93s | What we observe is that most of these memory corruption bug inside LPC kernel or RPC services, 462.93s - 468.93s | and most of them are traditionally memory corruption bugs due to the server side lack of check 468.93s - 474.13s | when RPC services handle data from the client side. 474.13s - 479.97s | And last example is, I think it's very interesting, logical fallback in LPC RPC discovered in 480.81s - 482.09s | 2017. 482.09s - 487.01s | Research found that the kernel doesn't protect the share memory privilege when using it to pass 487.01s - 489.49s | the message data. 489.49s - 495.65s | In theory, the kernel changed the share section protection in client-side to read-only, 495.65s - 500.85s | preventing the client-side changing the memory while server-side calling stop code that may be 500.85s - 504.17s | causing double fetch flaws in server-side. 504.21s - 511.09s | You can use the virtual protect function to change the share memory from read-only to read-write 511.09s - 513.97s | and causing data race condition in server-side. 513.97s - 517.57s | It's pretty doable, right? 517.57s - 524.77s | Imagine we already have a RPC function, accepts a string parameter and print it twice with a 524.77s - 527.49s | sleep between these two options. 527.49s - 532.53s | We write a POC and send a string and try to call the virtual protect and change the content of 532.53s - 533.57s | the string. 533.61s - 538.65s | We can see the server-side printed two different strings. 538.65s - 545.49s | It means


chunk_id: 201_chunk_8
chunk_text:
in LPC RPC discovered in 480.81s - 482.09s | 2017. 482.09s - 487.01s | Research found that the kernel doesn't protect the share memory privilege when using it to pass 487.01s - 489.49s | the message data. 489.49s - 495.65s | In theory, the kernel changed the share section protection in client-side to read-only, 495.65s - 500.85s | preventing the client-side changing the memory while server-side calling stop code that may be 500.85s - 504.17s | causing double fetch flaws in server-side. 504.21s - 511.09s | You can use the virtual protect function to change the share memory from read-only to read-write 511.09s - 513.97s | and causing data race condition in server-side. 513.97s - 517.57s | It's pretty doable, right? 517.57s - 524.77s | Imagine we already have a RPC function, accepts a string parameter and print it twice with a 524.77s - 527.49s | sleep between these two options. 527.49s - 532.53s | We write a POC and send a string and try to call the virtual protect and change the content of 532.53s - 533.57s | the string. 533.61s - 538.65s | We can see the server-side printed two different strings. 538.65s - 545.49s | It means that we can change a parameter while the server-side perform any other operation. 545.49s - 553.29s | Although this vulnerability has been fixed, I decided to learn more from it. 553.29s - 557.85s | Maybe we can find more interesting stuff. 557.85s - 565.11s | So, first question is, is it really secure after a patch? 565.15s - 576.07s | Yeah, from all of the research results I know, share memory is available for almost any RPC 576.07s - 577.91s | over ARPC services. 577.91s - 585.35s | So, I decided to write a custom RPC services and try to change the memory protection again, 585.35s - 588.95s | but finally get virtual protect EX error. 588.95s - 593.07s | So, what happened after the patch? 593.07s - 597.35s | So, I decided to learn more from the reverse engineering. 597.35s - 601.39s | First, N2S kernel try to secure the view of the section. 601.39s - 604.99s | It doesn't allow to change the memory attribute from the user space. 604.99s - 613.03s | And secondly, both N2S and RPC RT4 module DLL enable secure mode in mode check. 613.03s - 617.47s | It means that the server will


chunk_id: 201_chunk_9
chunk_text:
that we can change a parameter while the server-side perform any other operation. 545.49s - 553.29s | Although this vulnerability has been fixed, I decided to learn more from it. 553.29s - 557.85s | Maybe we can find more interesting stuff. 557.85s - 565.11s | So, first question is, is it really secure after a patch? 565.15s - 576.07s | Yeah, from all of the research results I know, share memory is available for almost any RPC 576.07s - 577.91s | over ARPC services. 577.91s - 585.35s | So, I decided to write a custom RPC services and try to change the memory protection again, 585.35s - 588.95s | but finally get virtual protect EX error. 588.95s - 593.07s | So, what happened after the patch? 593.07s - 597.35s | So, I decided to learn more from the reverse engineering. 597.35s - 601.39s | First, N2S kernel try to secure the view of the section. 601.39s - 604.99s | It doesn't allow to change the memory attribute from the user space. 604.99s - 613.03s | And secondly, both N2S and RPC RT4 module DLL enable secure mode in mode check. 613.03s - 617.47s | It means that the server will not manipulate the share memory when it detected the share 617.47s - 621.59s | memory is unsafe. 622.55s - 624.63s | This is the technique details. 624.63s - 629.67s | The security mechanism will handle share memory from client-side. 629.67s - 634.79s | Kernel use map view, secure view of section function to create a security view. 634.79s - 768.27s | So, you secure virtual memory and you can't change attribute. 768.27s - 773.51s | And when sending the attribute, sending message to the server, it's check the RPC section 773.51s - 777.87s | and the region we use to send the message to see if it's safe. 777.87s - 782.15s | And the region can't bind with more than two view objects. 782.15s - 787.91s | It's trying to change the attributes of the share memory address to read only. 787.91s - 794.67s | If this step falls, then the server-side will be marked with unsafe and the RPC RT4.DLL 794.67s - 800.47s | will use the share memory to unmarshal the server-side. 800.47s - 805.19s | And this is the code pieces from the user mode in RPC RT4. 805.19s - 812.55s | It will acquire the RPC


chunk_id: 201_chunk_10
chunk_text:
not manipulate the share memory when it detected the share 617.47s - 621.59s | memory is unsafe. 622.55s - 624.63s | This is the technique details. 624.63s - 629.67s | The security mechanism will handle share memory from client-side. 629.67s - 634.79s | Kernel use map view, secure view of section function to create a security view. 634.79s - 768.27s | So, you secure virtual memory and you can't change attribute. 768.27s - 773.51s | And when sending the attribute, sending message to the server, it's check the RPC section 773.51s - 777.87s | and the region we use to send the message to see if it's safe. 777.87s - 782.15s | And the region can't bind with more than two view objects. 782.15s - 787.91s | It's trying to change the attributes of the share memory address to read only. 787.91s - 794.67s | If this step falls, then the server-side will be marked with unsafe and the RPC RT4.DLL 794.67s - 800.47s | will use the share memory to unmarshal the server-side. 800.47s - 805.19s | And this is the code pieces from the user mode in RPC RT4. 805.19s - 812.55s | It will acquire the RPC message attributes, including the security flag of the RPC region. 812.55s - 816.95s | If the region is unsecure, you can see it will lock its heap buffer. 816.95s - 821.31s | It's managed by pcache object and copying the share memory to the heap buffer. 821.31s - 824.83s | So it will not cause double fish vulnerability. 824.83s - 829.19s | So when the server detect the region is unsafe. 830.19s - 837.63s | I also take a look at the virtual protect ES function to see how the kernel patch protects 837.63s - 838.63s | the share memory. 838.63s - 848.83s | As you know, I found a special bad event object to secure the bad object is a security view 848.83s - 849.83s | or not. 849.83s - 857.07s | So we know that Windows kernel use MMBad object to describe one virtual address in user space. 857.07s - 862.03s | It is describe the start and the ending of the virtual page. 862.03s - 867.71s | When changing the memory of a production, it will check if the bad event object is in 867.71s - 874.67s | the virtual address, uh, distribute the object, check if


chunk_id: 201_chunk_11
chunk_text:
message attributes, including the security flag of the RPC region. 812.55s - 816.95s | If the region is unsecure, you can see it will lock its heap buffer. 816.95s - 821.31s | It's managed by pcache object and copying the share memory to the heap buffer. 821.31s - 824.83s | So it will not cause double fish vulnerability. 824.83s - 829.19s | So when the server detect the region is unsafe. 830.19s - 837.63s | I also take a look at the virtual protect ES function to see how the kernel patch protects 837.63s - 838.63s | the share memory. 838.63s - 848.83s | As you know, I found a special bad event object to secure the bad object is a security view 848.83s - 849.83s | or not. 849.83s - 857.07s | So we know that Windows kernel use MMBad object to describe one virtual address in user space. 857.07s - 862.03s | It is describe the start and the ending of the virtual page. 862.03s - 867.71s | When changing the memory of a production, it will check if the bad event object is in 867.71s - 874.67s | the virtual address, uh, distribute the object, check if it had a bad event object in the 874.67s - 875.67s | event list. 875.67s - 881.59s | Unfortunately, the bad event structure symbol was deleted from Windows 11, so I can only 881.59s - 885.27s | use the old symbol from Windows 10. 885.27s - 890.59s | And digging into it, there's two key function for address protection. 890.59s - 897.87s | One is MSSLE protection and revert valid PTE function. 897.87s - 906.39s | This is the output from the debug in the right picture, and you can see before and after 906.39s - 913.59s | the MSSLE protection, it's changed a bit of the MSSLE protection from 4 to 1. 913.59s - 919.63s | I guess it's mean to read-write when the value is 4 and no access value is 1. 919.63s - 925.99s | Left picture describe the PTE content about Intel, which also, you know, is the page table 925.99s - 926.99s | structure. 926.99s - 933.07s | After the function of the MI revert valid PTE, the R and the right bit were set to 0, 933.07s - 940.03s | so the whole page in the kernel side will change to the read-only. 940.03s


chunk_id: 201_chunk_12
chunk_text:
it had a bad event object in the 874.67s - 875.67s | event list. 875.67s - 881.59s | Unfortunately, the bad event structure symbol was deleted from Windows 11, so I can only 881.59s - 885.27s | use the old symbol from Windows 10. 885.27s - 890.59s | And digging into it, there's two key function for address protection. 890.59s - 897.87s | One is MSSLE protection and revert valid PTE function. 897.87s - 906.39s | This is the output from the debug in the right picture, and you can see before and after 906.39s - 913.59s | the MSSLE protection, it's changed a bit of the MSSLE protection from 4 to 1. 913.59s - 919.63s | I guess it's mean to read-write when the value is 4 and no access value is 1. 919.63s - 925.99s | Left picture describe the PTE content about Intel, which also, you know, is the page table 925.99s - 926.99s | structure. 926.99s - 933.07s | After the function of the MI revert valid PTE, the R and the right bit were set to 0, 933.07s - 940.03s | so the whole page in the kernel side will change to the read-only. 940.03s - 944.59s | And the server side will use another page table. 944.59s - 947.35s | So what about the WLC protection? 947.35s - 955.55s | I think this bit from 60 to 62 is reversed according to Intel's documentation, so I guess 955.55s - 960.23s | Microsoft used it for some special purpose, yeah. 960.23s - 965.47s | And when changing the address protection, it's called MMCheckSecuritySecureVal to check 965.47s - 970.75s | if there's a special value event, as we talked before. 970.75s - 977.15s | And when we call the comparePTEProtection, it will compare the page table. 977.15s - 984.27s | Finally, compare the page table protection with the desired protection mask. 984.27s - 996.35s | We process the – we pass to the virtualprotect.ex to see a return change attribute if two value 996.35s - 997.35s | is the same. 997.35s - 1001.99s | If it's not equal to the virtualprotect.ex, it will return error. 1001.99s - 1007.15s | Unfortunately, WLC protection now is 1, so it's not the same as before. 1007.15s - 1013.47s | It really has some weird details you see when changing the protection from the address. 1013.47s - 1019.23s | It's


chunk_id: 201_chunk_13
chunk_text:
- 944.59s | And the server side will use another page table. 944.59s - 947.35s | So what about the WLC protection? 947.35s - 955.55s | I think this bit from 60 to 62 is reversed according to Intel's documentation, so I guess 955.55s - 960.23s | Microsoft used it for some special purpose, yeah. 960.23s - 965.47s | And when changing the address protection, it's called MMCheckSecuritySecureVal to check 965.47s - 970.75s | if there's a special value event, as we talked before. 970.75s - 977.15s | And when we call the comparePTEProtection, it will compare the page table. 977.15s - 984.27s | Finally, compare the page table protection with the desired protection mask. 984.27s - 996.35s | We process the – we pass to the virtualprotect.ex to see a return change attribute if two value 996.35s - 997.35s | is the same. 997.35s - 1001.99s | If it's not equal to the virtualprotect.ex, it will return error. 1001.99s - 1007.15s | Unfortunately, WLC protection now is 1, so it's not the same as before. 1007.15s - 1013.47s | It really has some weird details you see when changing the protection from the address. 1013.47s - 1019.23s | It's really not the same as we thought. 1019.23s - 1024.71s | I should actually try to bypass this function. 1024.71s - 1047.81s | So it's changing the – so it's changing – oh, now it's okay, yeah. 1047.81s - 1053.97s | So I tried to bypass this function, and it changed the protection one page. 1053.97s - 1058.73s | So if you are lucky to share memory for more than two page, and you only write data to 1058.73s - 1065.85s | the first page without doing any other operations, so the operation will fail. 1066.09s - 1072.65s | The security function, you know, because the rest of the page doesn't even have the page 1072.65s - 1076.17s | table, so you can't change the attributes. 1076.17s - 1084.84s | Okay, let's see the vulnerability details we found in the region. 1084.84s - 1091.40s | You can always try to align the allocation size to one page. 1091.40s - 1093.52s | You can split the session object. 1093.52s - 1101.80s | The starting offset section actually is auto-increased based on the last region and the offset. 1101.80s - 1104.24s | However, the allocation size is unchecked. 1104.24s - 1111.00s |


chunk_id: 201_chunk_14
chunk_text:
really not the same as we thought. 1019.23s - 1024.71s | I should actually try to bypass this function. 1024.71s - 1047.81s | So it's changing the – so it's changing – oh, now it's okay, yeah. 1047.81s - 1053.97s | So I tried to bypass this function, and it changed the protection one page. 1053.97s - 1058.73s | So if you are lucky to share memory for more than two page, and you only write data to 1058.73s - 1065.85s | the first page without doing any other operations, so the operation will fail. 1066.09s - 1072.65s | The security function, you know, because the rest of the page doesn't even have the page 1072.65s - 1076.17s | table, so you can't change the attributes. 1076.17s - 1084.84s | Okay, let's see the vulnerability details we found in the region. 1084.84s - 1091.40s | You can always try to align the allocation size to one page. 1091.40s - 1093.52s | You can split the session object. 1093.52s - 1101.80s | The starting offset section actually is auto-increased based on the last region and the offset. 1101.80s - 1104.24s | However, the allocation size is unchecked. 1104.24s - 1111.00s | So what about this small security flaw? 1111.00s - 1116.40s | What is small undiscovered issue can cause afterwards? 1116.40s - 1118.80s | But you still remember the previous picture. 1119.80s - 1127.64s | Assuming we already allocated four regions, the size of the first region is 0x1000. 1127.64s - 1135.72s | So the starting offset of the second region essentially will be 0x1000. 1135.72s - 1141.28s | Based on the info in the picture, we can know the starting offset of the region three is 1141.28s - 1147.56s | 0x4000, which is pretty easy to understand and calculate. 1147.56s - 1155.48s | So based on this info we know, we can see how unchecked section size we can do in the 1155.48s - 1158.16s | following. 1158.16s - 1169.40s | If we allocate the region with extremely big size, 0x002 is actually minus 0xFFFFE. 1169.40s - 1175.56s | Based on the region and the view granularity, the final offset of region two is actually 1175.56s - 1177.16s | will be zero. 1177.16s - 1180.44s | So the allocation size will be still zero. 1180.44s - 1184.00s | So what does this mean? 1184.00s - 1188.88s | This means that


chunk_id: 201_chunk_15
chunk_text:
So what about this small security flaw? 1111.00s - 1116.40s | What is small undiscovered issue can cause afterwards? 1116.40s - 1118.80s | But you still remember the previous picture. 1119.80s - 1127.64s | Assuming we already allocated four regions, the size of the first region is 0x1000. 1127.64s - 1135.72s | So the starting offset of the second region essentially will be 0x1000. 1135.72s - 1141.28s | Based on the info in the picture, we can know the starting offset of the region three is 1141.28s - 1147.56s | 0x4000, which is pretty easy to understand and calculate. 1147.56s - 1155.48s | So based on this info we know, we can see how unchecked section size we can do in the 1155.48s - 1158.16s | following. 1158.16s - 1169.40s | If we allocate the region with extremely big size, 0x002 is actually minus 0xFFFFE. 1169.40s - 1175.56s | Based on the region and the view granularity, the final offset of region two is actually 1175.56s - 1177.16s | will be zero. 1177.16s - 1180.44s | So the allocation size will be still zero. 1180.44s - 1184.00s | So what does this mean? 1184.00s - 1188.88s | This means that the region two will overlap with the region one, and they will be mapping 1188.88s - 1192.88s | to the same physical address. 1192.88s - 1198.64s | We can use the view one to send and receive the LLPC message, and this view will be protected 1198.64s - 1203.64s | by the LLPC kernel by using secure view against the write function. 1203.64s - 1207.72s | The second view will be left, and the kernel will do nothing on it. 1207.72s - 1214.32s | So because we don't even use it, so we can use the address of the second region to actually 1214.32s - 1217.60s | change the content. 1217.60s - 1221.16s | It's writable, so the double fish will happen again. 1221.16s - 1227.32s | The secure view write against the write function can't protect you anymore. 1227.32s - 1232.72s | So there will be still many questions for you. 1232.72s - 1237.04s | As you see in the previous page, the region allocation size is zero. 1237.04s - 1243.36s | So while you still can change the content of the shared memory, because the map view 1243.36s - 1249.96s | function support mapping size of zero, you


chunk_id: 201_chunk_16
chunk_text:
the region two will overlap with the region one, and they will be mapping 1188.88s - 1192.88s | to the same physical address. 1192.88s - 1198.64s | We can use the view one to send and receive the LLPC message, and this view will be protected 1198.64s - 1203.64s | by the LLPC kernel by using secure view against the write function. 1203.64s - 1207.72s | The second view will be left, and the kernel will do nothing on it. 1207.72s - 1214.32s | So because we don't even use it, so we can use the address of the second region to actually 1214.32s - 1217.60s | change the content. 1217.60s - 1221.16s | It's writable, so the double fish will happen again. 1221.16s - 1227.32s | The secure view write against the write function can't protect you anymore. 1227.32s - 1232.72s | So there will be still many questions for you. 1232.72s - 1237.04s | As you see in the previous page, the region allocation size is zero. 1237.04s - 1243.36s | So while you still can change the content of the shared memory, because the map view 1243.36s - 1249.96s | function support mapping size of zero, you allocate a page with size one page by default, 1249.96s - 1252.44s | so we don't need to worry about it. 1252.44s - 1260.68s | And the second, if you set the map view function, it can accept zero size? 1260.68s - 1262.96s | Why don't you pass zero size? 1262.96s - 1263.96s | Because it's unacceptable. 1263.96s - 1273.00s | There's a check before the allocation, allocate the view, create section view function. 1273.00s - 1280.24s | It's also the region object can use it in more than two views, but the situation I never 1280.24s - 1283.92s | encountered until now. 1283.92s - 1288.04s | So let's rest again on the Windows 11 again. 1288.04s - 1295.16s | Based on the custom LLPC service, we created two views with the same section offset. 1295.16s - 1300.08s | So the overlap happened, and the kernel only secured the first view, leaving the second 1300.08s - 1301.40s | view address writable. 1301.40s - 1306.88s | So you can see we successfully changed the content of the service parameter without changing 1306.88s - 1310.56s | the protection of the first view. 1310.56s - 1313.60s | The LLPC services will be vulnerable


chunk_id: 201_chunk_17
chunk_text:
allocate a page with size one page by default, 1249.96s - 1252.44s | so we don't need to worry about it. 1252.44s - 1260.68s | And the second, if you set the map view function, it can accept zero size? 1260.68s - 1262.96s | Why don't you pass zero size? 1262.96s - 1263.96s | Because it's unacceptable. 1263.96s - 1273.00s | There's a check before the allocation, allocate the view, create section view function. 1273.00s - 1280.24s | It's also the region object can use it in more than two views, but the situation I never 1280.24s - 1283.92s | encountered until now. 1283.92s - 1288.04s | So let's rest again on the Windows 11 again. 1288.04s - 1295.16s | Based on the custom LLPC service, we created two views with the same section offset. 1295.16s - 1300.08s | So the overlap happened, and the kernel only secured the first view, leaving the second 1300.08s - 1301.40s | view address writable. 1301.40s - 1306.88s | So you can see we successfully changed the content of the service parameter without changing 1306.88s - 1310.56s | the protection of the first view. 1310.56s - 1313.60s | The LLPC services will be vulnerable again. 1313.60s - 1316.96s | So we have already won the race. 1316.96s - 1323.92s | So from the page table entry, from the win debug, I can see two address pointed to same 1323.92s - 1326.36s | pages from a page frame number. 1326.36s - 1330.96s | It means that it pointed to the same physical memory. 1330.96s - 1335.68s | And we can see from the protection, we built into the debug when server trying to print 1335.68s - 1336.72s | the stream from client. 1336.72s - 1344.76s | So the first page is read only, and it's writable, but the second page is writable on the same 1344.76s - 1352.29s | physical memory, which resulted from our ideas, and the result is the result from the terminal. 1352.29s - 1358.95s | So from the exploitation analyze. 1358.95s - 1362.43s | So let's discuss some possible exploitation. 1362.43s - 1367.75s | From the assessment before, there's two ways to export. 1367.75s - 1374.91s | One is you can use Windows services or third-party services using file operations and for exploitation 1374.91s - 1384.79s | techniques created by James Fosho, a change to write system DLL and get any


chunk_id: 201_chunk_18
chunk_text:
again. 1313.60s - 1316.96s | So we have already won the race. 1316.96s - 1323.92s | So from the page table entry, from the win debug, I can see two address pointed to same 1323.92s - 1326.36s | pages from a page frame number. 1326.36s - 1330.96s | It means that it pointed to the same physical memory. 1330.96s - 1335.68s | And we can see from the protection, we built into the debug when server trying to print 1335.68s - 1336.72s | the stream from client. 1336.72s - 1344.76s | So the first page is read only, and it's writable, but the second page is writable on the same 1344.76s - 1352.29s | physical memory, which resulted from our ideas, and the result is the result from the terminal. 1352.29s - 1358.95s | So from the exploitation analyze. 1358.95s - 1362.43s | So let's discuss some possible exploitation. 1362.43s - 1367.75s | From the assessment before, there's two ways to export. 1367.75s - 1374.91s | One is you can use Windows services or third-party services using file operations and for exploitation 1374.91s - 1384.79s | techniques created by James Fosho, a change to write system DLL and get any system privilege, 1384.79s - 1391.87s | or bypass some security check and access some functions which admin user can access, or 1391.87s - 1398.43s | bypass UAC on the Windows 11. 1398.43s - 1404.95s | On the other side, we can also use memory corruption exploitation techniques. 1404.95s - 1413.51s | Firstly, I can almost crush any RPG services or ARPC services, and even can get system shell. 1413.51s - 1420.71s | So I must admit that I'm lazy sometimes, just want to make the exploitation as easy as possible. 1420.75s - 1425.39s | So unfortunately, Microsoft is not stupid. 1425.39s - 1432.75s | They were deleted the services code, which several years ago that Thomas used to exploit them, 1432.75s - 1435.11s | to exploit this type of issue. 1435.11s - 1438.23s | We need to find another possible way. 1438.23s - 1443.31s | But however, it's actually possible to find the RPC services meet these conditions. 1443.31s - 1445.31s | It's impossible, I think. 1445.31s - 1450.31s | First, the service need to use the shell memory without copying it to another address. 1450.31s - 1454.55s | And also need to have some sensitive operations on the file.


chunk_id: 201_chunk_19
chunk_text:
system privilege, 1384.79s - 1391.87s | or bypass some security check and access some functions which admin user can access, or 1391.87s - 1398.43s | bypass UAC on the Windows 11. 1398.43s - 1404.95s | On the other side, we can also use memory corruption exploitation techniques. 1404.95s - 1413.51s | Firstly, I can almost crush any RPG services or ARPC services, and even can get system shell. 1413.51s - 1420.71s | So I must admit that I'm lazy sometimes, just want to make the exploitation as easy as possible. 1420.75s - 1425.39s | So unfortunately, Microsoft is not stupid. 1425.39s - 1432.75s | They were deleted the services code, which several years ago that Thomas used to exploit them, 1432.75s - 1435.11s | to exploit this type of issue. 1435.11s - 1438.23s | We need to find another possible way. 1438.23s - 1443.31s | But however, it's actually possible to find the RPC services meet these conditions. 1443.31s - 1445.31s | It's impossible, I think. 1445.31s - 1450.31s | First, the service need to use the shell memory without copying it to another address. 1450.31s - 1454.55s | And also need to have some sensitive operations on the file. 1454.55s - 1459.91s | So consider this situation, it's almost impossible to find this kind of service. 1459.91s - 1462.75s | At least, I didn't find one. 1462.75s - 1464.19s | You can try it. 1464.19s - 1472.13s | But I think it's possible on some third-party services. 1472.13s - 1476.61s | Next, we should know what kind of argument we use to double fish. 1476.65s - 1481.97s | A simple structure, or a pointer, like an integer, a pointer, a string, or a double string, 1481.97s - 1483.97s | use shell memory. 1483.97s - 1490.73s | The context structure, which also you may know is called the longest structure, 1490.73s - 1493.09s | when copying to heap buffer. 1493.09s - 1498.21s | You may be confused about what is the complex or simple structure. 1498.21s - 1502.69s | To put it simple, you just remember, if a structure contains a pointer, 1506.86s - 1510.86s | this is an example of the simple complex structure we've seen. 1510.86s - 1514.86s | And they are treated differently when RPC unmatches them. 1514.86s - 1521.86s | And above is the bombi structure, which was never used in the shell memory, 1521.86s -


chunk_id: 201_chunk_20
chunk_text:
1454.55s - 1459.91s | So consider this situation, it's almost impossible to find this kind of service. 1459.91s - 1462.75s | At least, I didn't find one. 1462.75s - 1464.19s | You can try it. 1464.19s - 1472.13s | But I think it's possible on some third-party services. 1472.13s - 1476.61s | Next, we should know what kind of argument we use to double fish. 1476.65s - 1481.97s | A simple structure, or a pointer, like an integer, a pointer, a string, or a double string, 1481.97s - 1483.97s | use shell memory. 1483.97s - 1490.73s | The context structure, which also you may know is called the longest structure, 1490.73s - 1493.09s | when copying to heap buffer. 1493.09s - 1498.21s | You may be confused about what is the complex or simple structure. 1498.21s - 1502.69s | To put it simple, you just remember, if a structure contains a pointer, 1506.86s - 1510.86s | this is an example of the simple complex structure we've seen. 1510.86s - 1514.86s | And they are treated differently when RPC unmatches them. 1514.86s - 1521.86s | And above is the bombi structure, which was never used in the shell memory, 1521.86s - 1525.86s | which below is an example of the simple structure. 1525.86s - 1532.30s | We need to understand RPC format and the type format first. 1532.30s - 1536.30s | And the proc format is one server function in force, 1536.30s - 1542.30s | parameter type, and it's stored offset inside the parameter. 1542.30s - 1547.30s | For example, if we have an output one function in server side, 1547.30s - 1553.30s | the proc format will generate an IDL compiler from the compiler, 1553.30s - 1556.30s | storing the parameter into the parameter type offset, 1556.30s - 1559.30s | and the location info of the parameter. 1559.30s - 1562.30s | And the IDL compiler also generates the comment for every... 1677.71s - 1681.31s | Oh, it's okay now? 1681.31s - 1685.31s | And we can see the difference between the simple and the complex structure 1685.31s - 1689.97s | in the type format. 1689.97s - 1693.97s | Okay, the proc mark gives us where the parameter type definition 1693.97s - 1695.97s | located in the type format string, 1695.97s - 1700.97s | so we can see difference between the simple and the complex structure. 1700.97s - 1703.97s | In


chunk_id: 201_chunk_21
chunk_text:
1525.86s | which below is an example of the simple structure. 1525.86s - 1532.30s | We need to understand RPC format and the type format first. 1532.30s - 1536.30s | And the proc format is one server function in force, 1536.30s - 1542.30s | parameter type, and it's stored offset inside the parameter. 1542.30s - 1547.30s | For example, if we have an output one function in server side, 1547.30s - 1553.30s | the proc format will generate an IDL compiler from the compiler, 1553.30s - 1556.30s | storing the parameter into the parameter type offset, 1556.30s - 1559.30s | and the location info of the parameter. 1559.30s - 1562.30s | And the IDL compiler also generates the comment for every... 1677.71s - 1681.31s | Oh, it's okay now? 1681.31s - 1685.31s | And we can see the difference between the simple and the complex structure 1685.31s - 1689.97s | in the type format. 1689.97s - 1693.97s | Okay, the proc mark gives us where the parameter type definition 1693.97s - 1695.97s | located in the type format string, 1695.97s - 1700.97s | so we can see difference between the simple and the complex structure. 1700.97s - 1703.97s | In the header flag, you can see them in the comment. 1706.97s - 1710.97s | There's three situation buffer flow I can cause. 1710.97s - 1714.97s | I tried to find the exportation services by code auditing 1714.97s - 1716.97s | or faster contents, 1716.97s - 1722.97s | but one condition is inside the RPC string Marshall function. 1722.97s - 1724.97s | The pre-memory content we can control, 1724.97s - 1728.97s | so one service has multiple output string result sending to the client, 1728.97s - 1732.97s | so it also will use the shell memory to send to the client 1732.97s - 1734.97s | so we can fill the whole shell memory 1734.97s - 1736.97s | and the argument gap. 1736.97s - 1740.97s | Assuming the first string is 0x50 lens, 1740.97s - 1743.97s | and the second is 0x500 lens, 1743.97s - 1747.97s | so we can fill the argument gap in the memory 1747.97s - 1749.97s | after the server finishes the subcode 1749.97s - 1752.97s | and returns to the RPC-84, 1752.97s - 1756.97s | and the client size will be over 0x1000, 1756.97s - 1759.97s | so it's the maximum size in shell memory 1759.97s -


chunk_id: 201_chunk_22
chunk_text:
the header flag, you can see them in the comment. 1706.97s - 1710.97s | There's three situation buffer flow I can cause. 1710.97s - 1714.97s | I tried to find the exportation services by code auditing 1714.97s - 1716.97s | or faster contents, 1716.97s - 1722.97s | but one condition is inside the RPC string Marshall function. 1722.97s - 1724.97s | The pre-memory content we can control, 1724.97s - 1728.97s | so one service has multiple output string result sending to the client, 1728.97s - 1732.97s | so it also will use the shell memory to send to the client 1732.97s - 1734.97s | so we can fill the whole shell memory 1734.97s - 1736.97s | and the argument gap. 1736.97s - 1740.97s | Assuming the first string is 0x50 lens, 1740.97s - 1743.97s | and the second is 0x500 lens, 1743.97s - 1747.97s | so we can fill the argument gap in the memory 1747.97s - 1749.97s | after the server finishes the subcode 1749.97s - 1752.97s | and returns to the RPC-84, 1752.97s - 1756.97s | and the client size will be over 0x1000, 1756.97s - 1759.97s | so it's the maximum size in shell memory 1759.97s - 1764.31s | will cause the crash of the service. 1764.31s - 1768.31s | And also another heap operation, 1768.31s - 1773.31s | which means the size of the string store inside a pointer, 1773.31s - 1776.31s | so it's not easy to find this part of the server, 1776.31s - 1778.31s | so we can change the size of the string 1778.31s - 1779.31s | when the server on Marshall, 1779.31s - 1784.31s | the server resulting the string sending to the client. 1784.31s - 1788.31s | However, it's still possible, not possible to exploit. 1788.31s - 1792.31s | You can only cause the shell memory output out on the read, 1792.31s - 1794.31s | so when calling the P memory function, 1794.31s - 1796.31s | so it's a pity. 1796.31s - 1802.31s | And the third exploitation is spool service, 1802.31s - 1803.31s | spool server service. 1803.31s - 1805.31s | When it open a printer, 1805.31s - 1808.31s | it will double-check access the name of the printer, 1808.31s - 1812.31s | and the first time the server will cause WCs, 1812.31s - 1816.31s | a string result offset can be a large offset, 1816.31s - 1819.31s |


chunk_id: 201_chunk_23
chunk_text:
1764.31s | will cause the crash of the service. 1764.31s - 1768.31s | And also another heap operation, 1768.31s - 1773.31s | which means the size of the string store inside a pointer, 1773.31s - 1776.31s | so it's not easy to find this part of the server, 1776.31s - 1778.31s | so we can change the size of the string 1778.31s - 1779.31s | when the server on Marshall, 1779.31s - 1784.31s | the server resulting the string sending to the client. 1784.31s - 1788.31s | However, it's still possible, not possible to exploit. 1788.31s - 1792.31s | You can only cause the shell memory output out on the read, 1792.31s - 1794.31s | so when calling the P memory function, 1794.31s - 1796.31s | so it's a pity. 1796.31s - 1802.31s | And the third exploitation is spool service, 1802.31s - 1803.31s | spool server service. 1803.31s - 1805.31s | When it open a printer, 1805.31s - 1808.31s | it will double-check access the name of the printer, 1808.31s - 1812.31s | and the first time the server will cause WCs, 1812.31s - 1816.31s | a string result offset can be a large offset, 1816.31s - 1819.31s | and then allocate a string again, 1819.31s - 1821.31s | and recalculate the string length, 1821.31s - 1824.31s | so this time the string can be small size, 1824.31s - 1826.31s | so you will cause out of a bound write, 1826.31s - 1829.31s | a null pointer, a null byte, 1829.31s - 1831.31s | but this issue is hard to exploit, 1831.31s - 1834.31s | so we also need to win the race, 1834.31s - 1839.31s | and doing heap function to construct some useful target, 1839.31s - 1840.31s | so it's really a huge challenge, 1840.31s - 1843.31s | so what should I do? 1843.31s - 1847.31s | So I decide to try to do some easy stuff first. 1847.31s - 1850.31s | Let's see. 1850.31s - 1852.31s | Bypassing UIC. 1852.31s - 1854.31s | How this works, 1854.31s - 1858.31s | the key function inside application information service, 1858.31s - 1862.31s | in UIC service, 1862.31s - 1864.31s | luckily the service access the command line argument 1864.31s - 1866.31s | from the shell memory, 1866.31s - 1868.31s | without copying it to the heap buffer, 1868.31s - 1873.31s | so we can have a chance to


chunk_id: 201_chunk_24
chunk_text:
and then allocate a string again, 1819.31s - 1821.31s | and recalculate the string length, 1821.31s - 1824.31s | so this time the string can be small size, 1824.31s - 1826.31s | so you will cause out of a bound write, 1826.31s - 1829.31s | a null pointer, a null byte, 1829.31s - 1831.31s | but this issue is hard to exploit, 1831.31s - 1834.31s | so we also need to win the race, 1834.31s - 1839.31s | and doing heap function to construct some useful target, 1839.31s - 1840.31s | so it's really a huge challenge, 1840.31s - 1843.31s | so what should I do? 1843.31s - 1847.31s | So I decide to try to do some easy stuff first. 1847.31s - 1850.31s | Let's see. 1850.31s - 1852.31s | Bypassing UIC. 1852.31s - 1854.31s | How this works, 1854.31s - 1858.31s | the key function inside application information service, 1858.31s - 1862.31s | in UIC service, 1862.31s - 1864.31s | luckily the service access the command line argument 1864.31s - 1866.31s | from the shell memory, 1866.31s - 1868.31s | without copying it to the heap buffer, 1868.31s - 1873.31s | so we can have a chance to use this, 1873.31s - 1877.31s | and also the program name and the cmd line argument 1877.31s - 1880.31s | are also stored in the shell memory. 1880.31s - 1882.31s | The UIC has a special feature, 1882.31s - 1885.31s | when the client executes some special program, 1885.31s - 1887.31s | it will not launch the save confirm window, 1887.31s - 1891.31s | so we can use the feature to launch the arbitrary program, 1891.31s - 1893.31s | without any launch any confirm window, 1893.31s - 1895.31s | from app info service, 1895.31s - 1898.31s | so we can bypass it. 1898.31s - 1901.31s | It's also not that easy as we analyzed, 1902.31s - 1905.31s | there's a whitelist inside the service, 1905.31s - 1908.31s | you should know that there's also argument whitelist, 1908.31s - 1911.31s | for some special program, 1911.31s - 1918.31s | which not need to launch the confirm window, 1918.31s - 1920.31s | so also the new process, 1920.31s - 1922.31s | launched by app info service, 1922.31s - 1924.31s | will suspend first, 1924.31s - 1927.31s | that means we still cannot execute our payload, 1927.31s - 1929.31s | so server will


chunk_id: 201_chunk_25
chunk_text:
use this, 1873.31s - 1877.31s | and also the program name and the cmd line argument 1877.31s - 1880.31s | are also stored in the shell memory. 1880.31s - 1882.31s | The UIC has a special feature, 1882.31s - 1885.31s | when the client executes some special program, 1885.31s - 1887.31s | it will not launch the save confirm window, 1887.31s - 1891.31s | so we can use the feature to launch the arbitrary program, 1891.31s - 1893.31s | without any launch any confirm window, 1893.31s - 1895.31s | from app info service, 1895.31s - 1898.31s | so we can bypass it. 1898.31s - 1901.31s | It's also not that easy as we analyzed, 1902.31s - 1905.31s | there's a whitelist inside the service, 1905.31s - 1908.31s | you should know that there's also argument whitelist, 1908.31s - 1911.31s | for some special program, 1911.31s - 1918.31s | which not need to launch the confirm window, 1918.31s - 1920.31s | so also the new process, 1920.31s - 1922.31s | launched by app info service, 1922.31s - 1924.31s | will suspend first, 1924.31s - 1927.31s | that means we still cannot execute our payload, 1927.31s - 1929.31s | so server will check the process image section, 1929.31s - 1931.31s | with the program file section, 1931.31s - 1934.31s | means although we have a launch malicious program, 1934.31s - 1935.31s | without confirm window, 1935.31s - 1937.31s | the app info service, 1937.31s - 1941.31s | will also launch the confirm window, 1941.31s - 1944.31s | because the two image are not the same, 1944.31s - 1947.31s | so Microsoft is not stupid, 1947.31s - 1949.31s | really a good solution to prevent, 1949.31s - 1952.31s | a launching from any malicious program, 1952.31s - 1953.31s | but unfortunately, 1953.31s - 1956.31s | they doesn't check the argument program, 1957.31s - 1959.31s | after the launching the program, 1959.31s - 1962.31s | it doesn't check the argument, 1962.31s - 1965.31s | so we still have to change, 1965.31s - 1967.31s | the good thing is, 1967.31s - 1970.31s | we can create a malicious mscc file, 1970.31s - 1972.31s | and there's a research on mscc file, 1972.31s - 1976.31s | when mscc open and auto-launch the CMD shell, 1976.31s - 1978.31s | with a malicious strip, 1978.31s - 1981.31s | you know service.msc is in there, 1981.31s - 1985.31s |


chunk_id: 201_chunk_26
chunk_text:
check the process image section, 1929.31s - 1931.31s | with the program file section, 1931.31s - 1934.31s | means although we have a launch malicious program, 1934.31s - 1935.31s | without confirm window, 1935.31s - 1937.31s | the app info service, 1937.31s - 1941.31s | will also launch the confirm window, 1941.31s - 1944.31s | because the two image are not the same, 1944.31s - 1947.31s | so Microsoft is not stupid, 1947.31s - 1949.31s | really a good solution to prevent, 1949.31s - 1952.31s | a launching from any malicious program, 1952.31s - 1953.31s | but unfortunately, 1953.31s - 1956.31s | they doesn't check the argument program, 1957.31s - 1959.31s | after the launching the program, 1959.31s - 1962.31s | it doesn't check the argument, 1962.31s - 1965.31s | so we still have to change, 1965.31s - 1967.31s | the good thing is, 1967.31s - 1970.31s | we can create a malicious mscc file, 1970.31s - 1972.31s | and there's a research on mscc file, 1972.31s - 1976.31s | when mscc open and auto-launch the CMD shell, 1976.31s - 1978.31s | with a malicious strip, 1978.31s - 1981.31s | you know service.msc is in there, 1981.31s - 1985.31s | whitelist of the USC services, 1985.31s - 1988.31s | so we can see, 1988.31s - 1991.31s | we can launch a high integrated command line shell, 1991.31s - 1993.31s | without any other problem, 1993.31s - 1997.31s | but I'm not satisfied in doing this, 1997.31s - 1999.31s | it's even not a vulnerability to Microsoft, 1999.31s - 2003.31s | so you should be an administrator first, 2003.31s - 2005.31s | and I mean system to the system, 2005.31s - 2006.31s | it's not a security boundary, 2006.31s - 2009.31s | as we seen from the Microsoft, 2009.31s - 2014.30s | so last is get system privilege, 2014.30s - 2016.30s | another good thing is, 2016.30s - 2019.30s | it's truly exploitable, 2019.30s - 2022.30s | I found a service in DCOM launch, 2022.30s - 2025.30s | the key is a key service in Windows system, 2025.30s - 2026.30s | interface, 2026.30s - 2028.30s | normal user can access, 2028.30s - 2030.30s | I have a list, 2030.30s - 2031.30s | the service dual ID, 2031.30s - 2033.30s | service pass, 2033.30s - 2036.30s | so and the service function, 2036.30s - 2038.30s | I used to exploit, 2038.30s -


chunk_id: 201_chunk_27
chunk_text:
whitelist of the USC services, 1985.31s - 1988.31s | so we can see, 1988.31s - 1991.31s | we can launch a high integrated command line shell, 1991.31s - 1993.31s | without any other problem, 1993.31s - 1997.31s | but I'm not satisfied in doing this, 1997.31s - 1999.31s | it's even not a vulnerability to Microsoft, 1999.31s - 2003.31s | so you should be an administrator first, 2003.31s - 2005.31s | and I mean system to the system, 2005.31s - 2006.31s | it's not a security boundary, 2006.31s - 2009.31s | as we seen from the Microsoft, 2009.31s - 2014.30s | so last is get system privilege, 2014.30s - 2016.30s | another good thing is, 2016.30s - 2019.30s | it's truly exploitable, 2019.30s - 2022.30s | I found a service in DCOM launch, 2022.30s - 2025.30s | the key is a key service in Windows system, 2025.30s - 2026.30s | interface, 2026.30s - 2028.30s | normal user can access, 2028.30s - 2030.30s | I have a list, 2030.30s - 2031.30s | the service dual ID, 2031.30s - 2033.30s | service pass, 2033.30s - 2036.30s | so and the service function, 2036.30s - 2038.30s | I used to exploit, 2038.30s - 2039.30s | it's a game, 2039.30s - 2041.30s | get game name config, 2041.30s - 2042.30s | yeah, 2042.30s - 2043.30s | it's truly, 2043.30s - 2044.30s | and it's true, 2044.30s - 2046.30s | three parameter with simple structure, 2046.30s - 2048.30s | means the service can use the shell memory, 2048.30s - 2052.30s | you will obviously get the execution from the start point, 2052.30s - 2057.22s | and the first parameter is a dual ID stream, 2057.22s - 2059.22s | it's come from the registry, 2059.22s - 2062.22s | representing a game as you know, 2062.22s - 2064.22s | dual ID in the picture, 2064.22s - 2066.22s | this dual ID represent the battlefield, 2066.22s - 2070.22s | I think some of you might played it before, 2070.22s - 2072.22s | but most importantly, 2072.22s - 2074.22s | the key is fully controlled by the current user, 2075.22s - 2077.22s | because every user in the system, 2077.22s - 2081.22s | have the independent game store configuration, 2081.22s - 2082.22s | in the user hive, 2082.22s - 2084.22s | so you can just traverse the key, 2084.22s - 2087.22s | current key and the final one, 2087.22s


chunk_id: 201_chunk_28
chunk_text:
2039.30s | it's a game, 2039.30s - 2041.30s | get game name config, 2041.30s - 2042.30s | yeah, 2042.30s - 2043.30s | it's truly, 2043.30s - 2044.30s | and it's true, 2044.30s - 2046.30s | three parameter with simple structure, 2046.30s - 2048.30s | means the service can use the shell memory, 2048.30s - 2052.30s | you will obviously get the execution from the start point, 2052.30s - 2057.22s | and the first parameter is a dual ID stream, 2057.22s - 2059.22s | it's come from the registry, 2059.22s - 2062.22s | representing a game as you know, 2062.22s - 2064.22s | dual ID in the picture, 2064.22s - 2066.22s | this dual ID represent the battlefield, 2066.22s - 2070.22s | I think some of you might played it before, 2070.22s - 2072.22s | but most importantly, 2072.22s - 2074.22s | the key is fully controlled by the current user, 2075.22s - 2077.22s | because every user in the system, 2077.22s - 2081.22s | have the independent game store configuration, 2081.22s - 2082.22s | in the user hive, 2082.22s - 2084.22s | so you can just traverse the key, 2084.22s - 2087.22s | current key and the final one, 2087.22s - 2088.22s | next we may thought, 2088.22s - 2090.22s | what can we do in the service, 2090.22s - 2094.22s | because we can now pass in the parameters, 2094.22s - 2095.22s | through the shell memory, 2095.22s - 2097.22s | so we can pretty lucky, 2097.22s - 2099.22s | we can do memory leak, 2099.22s - 2102.22s | and array overflow in this function, 2102.22s - 2105.22s | so first the function directly write the stream, 2105.22s - 2106.22s | pointer to the shell memory, 2106.22s - 2108.22s | which means we can leak the shell memory address, 2108.22s - 2110.22s | mapped in the server side, 2110.22s - 2112.22s | although the memory is unmapped, 2112.22s - 2114.22s | after the request, 2114.22s - 2116.22s | but the address will never change, 2116.22s - 2118.22s | so we can use the shell memory, 2118.22s - 2121.22s | to construct our fake object, 2121.22s - 2122.22s | and the V tables, 2122.22s - 2125.22s | and plus this stack array buffer floor, 2125.22s - 2126.22s | upon access, 2126.22s - 2128.22s | and after the information leak, 2128.22s - 2129.22s | on the shell memory, 2129.22s - 2131.22s


chunk_id: 201_chunk_29
chunk_text:
- 2088.22s | next we may thought, 2088.22s - 2090.22s | what can we do in the service, 2090.22s - 2094.22s | because we can now pass in the parameters, 2094.22s - 2095.22s | through the shell memory, 2095.22s - 2097.22s | so we can pretty lucky, 2097.22s - 2099.22s | we can do memory leak, 2099.22s - 2102.22s | and array overflow in this function, 2102.22s - 2105.22s | so first the function directly write the stream, 2105.22s - 2106.22s | pointer to the shell memory, 2106.22s - 2108.22s | which means we can leak the shell memory address, 2108.22s - 2110.22s | mapped in the server side, 2110.22s - 2112.22s | although the memory is unmapped, 2112.22s - 2114.22s | after the request, 2114.22s - 2116.22s | but the address will never change, 2116.22s - 2118.22s | so we can use the shell memory, 2118.22s - 2121.22s | to construct our fake object, 2121.22s - 2122.22s | and the V tables, 2122.22s - 2125.22s | and plus this stack array buffer floor, 2125.22s - 2126.22s | upon access, 2126.22s - 2128.22s | and after the information leak, 2128.22s - 2129.22s | on the shell memory, 2129.22s - 2131.22s | you can see the function directly, 2131.22s - 2133.22s | use the index from the shell memory, 2133.22s - 2135.22s | and write a shell memory address, 2135.22s - 2137.22s | a pointer out of a bound on the stack, 2137.22s - 2139.22s | this means that we can do info leak, 2139.22s - 2141.22s | and stack buffer overflow, 2141.22s - 2143.22s | just in one function, 2143.22s - 2145.22s | and it's a good and really, 2145.22s - 2149.69s | and a good primitive, 2149.69s - 2152.69s | this is a strategy I use, 2152.69s - 2155.69s | first I need to leak the shell memory address, 2155.69s - 2159.69s | and we just call the server function, 2160.69s - 2163.69s | to repeatedly read the shell memory, 2163.69s - 2165.69s | so we can get the pointer, 2165.69s - 2167.69s | and when we get the shell memory, 2167.69s - 2168.69s | we can create a fake object, 2168.69s - 2169.69s | the V table, 2169.69s - 2171.69s | based on the leaked information, 2171.69s - 2172.69s | in step one, 2172.69s - 2173.69s | and finally, 2173.69s - 2175.69s | we can try to change


chunk_id: 201_chunk_30
chunk_text:
| you can see the function directly, 2131.22s - 2133.22s | use the index from the shell memory, 2133.22s - 2135.22s | and write a shell memory address, 2135.22s - 2137.22s | a pointer out of a bound on the stack, 2137.22s - 2139.22s | this means that we can do info leak, 2139.22s - 2141.22s | and stack buffer overflow, 2141.22s - 2143.22s | just in one function, 2143.22s - 2145.22s | and it's a good and really, 2145.22s - 2149.69s | and a good primitive, 2149.69s - 2152.69s | this is a strategy I use, 2152.69s - 2155.69s | first I need to leak the shell memory address, 2155.69s - 2159.69s | and we just call the server function, 2160.69s - 2163.69s | to repeatedly read the shell memory, 2163.69s - 2165.69s | so we can get the pointer, 2165.69s - 2167.69s | and when we get the shell memory, 2167.69s - 2168.69s | we can create a fake object, 2168.69s - 2169.69s | the V table, 2169.69s - 2171.69s | based on the leaked information, 2171.69s - 2172.69s | in step one, 2172.69s - 2173.69s | and finally, 2173.69s - 2175.69s | we can try to change index of the shell memory, 2175.69s - 2177.69s | to trick the stack array, 2177.69s - 2179.69s | buffer overflow, 2179.69s - 2181.69s | to load our evil DLL to the service, 2181.69s - 2184.69s | and get system shell, 2184.69s - 2186.69s | I'll show you one step by step, 2186.69s - 2190.69s | and this is output from the win debug window, 2190.69s - 2192.69s | we can see server write the shell memory pointer, 2192.69s - 2193.69s | on the shell memory, 2193.69s - 2195.69s | we just read it repeatedly from the kind, 2195.69s - 2199.69s | until we read the pointer, 2199.69s - 2201.69s | shell pointer, 2201.69s - 2202.69s | and next the real problem came, 2202.69s - 2204.69s | so we can get a stack array, 2204.69s - 2205.69s | buffer overflow, 2205.69s - 2208.69s | but how and where to write, 2208.69s - 2210.69s | and what to write, 2210.69s - 2212.69s | I choose to write the RPC message object, 2212.69s - 2214.69s | on the stack, 2214.69s - 2215.69s | so first, 2215.69s - 2217.69s | RPC message is a member in MID, 2217.69s - 2218.69s | or stack message,


chunk_id: 201_chunk_31
chunk_text:
index of the shell memory, 2175.69s - 2177.69s | to trick the stack array, 2177.69s - 2179.69s | buffer overflow, 2179.69s - 2181.69s | to load our evil DLL to the service, 2181.69s - 2184.69s | and get system shell, 2184.69s - 2186.69s | I'll show you one step by step, 2186.69s - 2190.69s | and this is output from the win debug window, 2190.69s - 2192.69s | we can see server write the shell memory pointer, 2192.69s - 2193.69s | on the shell memory, 2193.69s - 2195.69s | we just read it repeatedly from the kind, 2195.69s - 2199.69s | until we read the pointer, 2199.69s - 2201.69s | shell pointer, 2201.69s - 2202.69s | and next the real problem came, 2202.69s - 2204.69s | so we can get a stack array, 2204.69s - 2205.69s | buffer overflow, 2205.69s - 2208.69s | but how and where to write, 2208.69s - 2210.69s | and what to write, 2210.69s - 2212.69s | I choose to write the RPC message object, 2212.69s - 2214.69s | on the stack, 2214.69s - 2215.69s | so first, 2215.69s - 2217.69s | RPC message is a member in MID, 2217.69s - 2218.69s | or stack message, 2218.69s - 2220.69s | and the object is allocated on the stack, 2220.69s - 2222.69s | so before RPC call the server, 2222.69s - 2224.69s | it's easy to override it, 2224.69s - 2227.69s | and the shell memory is not executable, 2227.69s - 2229.69s | so we can just override, 2229.69s - 2233.69s | and if we choose to override the return address, 2233.69s - 2238.69s | we cannot directly do the ROP, 2238.69s - 2239.69s | let's see what we write, 2239.69s - 2241.69s | from the view of the win debug, 2241.69s - 2243.69s | RCX is the array index, 2243.69s - 2244.69s | we can fully control it, 2244.69s - 2247.69s | RCX is shell memory address, 2247.69s - 2249.69s | and we also can fully control it, 2249.69s - 2251.69s | so you can see, 2251.69s - 2253.69s | we easily override RPC message pointer, 2253.69s - 2254.69s | on the stack, 2254.69s - 2256.69s | so when the server return to RPC core engine, 2256.69s - 2260.69s | it will be operated on the fake object, 2260.69s - 2263.69s | so we can see from the engine call, 2263.69s - 2264.69s | NDR get


chunk_id: 201_chunk_32
chunk_text:
2218.69s - 2220.69s | and the object is allocated on the stack, 2220.69s - 2222.69s | so before RPC call the server, 2222.69s - 2224.69s | it's easy to override it, 2224.69s - 2227.69s | and the shell memory is not executable, 2227.69s - 2229.69s | so we can just override, 2229.69s - 2233.69s | and if we choose to override the return address, 2233.69s - 2238.69s | we cannot directly do the ROP, 2238.69s - 2239.69s | let's see what we write, 2239.69s - 2241.69s | from the view of the win debug, 2241.69s - 2243.69s | RCX is the array index, 2243.69s - 2244.69s | we can fully control it, 2244.69s - 2247.69s | RCX is shell memory address, 2247.69s - 2249.69s | and we also can fully control it, 2249.69s - 2251.69s | so you can see, 2251.69s - 2253.69s | we easily override RPC message pointer, 2253.69s - 2254.69s | on the stack, 2254.69s - 2256.69s | so when the server return to RPC core engine, 2256.69s - 2260.69s | it will be operated on the fake object, 2260.69s - 2263.69s | so we can see from the engine call, 2263.69s - 2264.69s | NDR get buffer, 2264.69s - 2267.69s | RCX already been the shell memory address, 2267.69s - 2270.69s | and this is a layout of the shell memory, 2270.69s - 2272.69s | there's also some type check, 2272.69s - 2274.69s | because we can fully control it, 2274.69s - 2275.69s | so it's not a problem, 2275.69s - 2279.69s | I choose to construct the fake RPC binding handle, 2279.69s - 2282.69s | in the shell memory, 2282.69s - 2284.69s | real problem came, 2284.69s - 2286.69s | you can see finally, 2286.69s - 2288.69s | you arrive to the virtual function calling, 2288.69s - 2290.69s | so it is XFG check, 2290.69s - 2295.69s | the first available, 2295.69s - 2298.69s | and I want to actually, 2298.69s - 2300.69s | directly call to the load library, 2301.69s - 2303.69s | but you can see the V table, 2303.69s - 2305.69s | and the first parameter is overlapped, 2305.69s - 2310.69s | so we cannot directly call the load library, 2310.69s - 2315.69s | so we can always find a way, 2315.69s - 2317.69s | if I can directly call load library, 2317.69s - 2319.69s | I can find a legal callable


chunk_id: 201_chunk_33
chunk_text:
buffer, 2264.69s - 2267.69s | RCX already been the shell memory address, 2267.69s - 2270.69s | and this is a layout of the shell memory, 2270.69s - 2272.69s | there's also some type check, 2272.69s - 2274.69s | because we can fully control it, 2274.69s - 2275.69s | so it's not a problem, 2275.69s - 2279.69s | I choose to construct the fake RPC binding handle, 2279.69s - 2282.69s | in the shell memory, 2282.69s - 2284.69s | real problem came, 2284.69s - 2286.69s | you can see finally, 2286.69s - 2288.69s | you arrive to the virtual function calling, 2288.69s - 2290.69s | so it is XFG check, 2290.69s - 2295.69s | the first available, 2295.69s - 2298.69s | and I want to actually, 2298.69s - 2300.69s | directly call to the load library, 2301.69s - 2303.69s | but you can see the V table, 2303.69s - 2305.69s | and the first parameter is overlapped, 2305.69s - 2310.69s | so we cannot directly call the load library, 2310.69s - 2315.69s | so we can always find a way, 2315.69s - 2317.69s | if I can directly call load library, 2317.69s - 2319.69s | I can find a legal callable function, 2319.69s - 2321.69s | to reduce the pivoting, 2321.69s - 2324.69s | so we know there's a technique, 2324.69s - 2326.69s | called stack pivoting, 2326.69s - 2328.69s | in CTF exportation techniques, 2328.69s - 2331.69s | where you can directly RP on the current stack, 2331.69s - 2333.69s | so for the register pivoting, 2333.69s - 2334.69s | I just need to find a function, 2334.69s - 2338.69s | which can exchange the content of the register RCX, 2338.69s - 2342.69s | and then the register will point you to the DLL path, 2342.69s - 2345.69s | and luckily I found this kind of a function, 2345.69s - 2349.69s | which can exchange the register, 2349.69s - 2351.69s | it's inside the com-based DLL, 2351.69s - 2354.69s | I can directly call bypass the XFG check, 2354.69s - 2356.69s | it's a callback function, 2356.69s - 2359.69s | and this is a layout, 2359.69s - 2362.69s | RCX is before we call into the callback, 2362.69s - 2364.69s | it's pointing to bind handle object, 2364.69s - 2366.69s | and the value in the purple color, 2366.69s - 2368.69s | is the type of information, 2368.69s - 2370.69s


chunk_id: 201_chunk_34
chunk_text:
function, 2319.69s - 2321.69s | to reduce the pivoting, 2321.69s - 2324.69s | so we know there's a technique, 2324.69s - 2326.69s | called stack pivoting, 2326.69s - 2328.69s | in CTF exportation techniques, 2328.69s - 2331.69s | where you can directly RP on the current stack, 2331.69s - 2333.69s | so for the register pivoting, 2333.69s - 2334.69s | I just need to find a function, 2334.69s - 2338.69s | which can exchange the content of the register RCX, 2338.69s - 2342.69s | and then the register will point you to the DLL path, 2342.69s - 2345.69s | and luckily I found this kind of a function, 2345.69s - 2349.69s | which can exchange the register, 2349.69s - 2351.69s | it's inside the com-based DLL, 2351.69s - 2354.69s | I can directly call bypass the XFG check, 2354.69s - 2356.69s | it's a callback function, 2356.69s - 2359.69s | and this is a layout, 2359.69s - 2362.69s | RCX is before we call into the callback, 2362.69s - 2364.69s | it's pointing to bind handle object, 2364.69s - 2366.69s | and the value in the purple color, 2366.69s - 2368.69s | is the type of information, 2368.69s - 2370.69s | and the callback function, 2370.69s - 2373.69s | we can call load libraries with login function, 2373.69s - 2376.69s | to with the DLL path in the second parameter, 2376.69s - 2378.69s | so luckily before the control flow check, 2378.69s - 2380.69s | the validity of the callback function, 2380.69s - 2382.69s | the function is not first member of the V table, 2382.69s - 2384.69s | it's at the 0x70, 2384.69s - 2386.69s | so the start location of the V table, 2386.69s - 2388.69s | we can use to put our DLL paths, 2388.69s - 2391.69s | so without worrying about the function validity, 2391.69s - 2394.69s | because it was never used, 2394.69s - 2396.69s | so then we can load our custom DLL, 2396.69s - 2399.69s | without any resistance, 2399.69s - 2402.69s | and I will show you the demo, 2402.69s - 2411.14s | I use a normal user, 2411.14s - 2413.14s | it's in user group, 2413.14s - 2419.31s | and I write it in all the POC in the person, 2419.31s - 2424.01s | and you can see it's a normal user, 2424.01s - 2426.01s | with medium privilege, 2426.01s -


chunk_id: 201_chunk_35
chunk_text:
| and the callback function, 2370.69s - 2373.69s | we can call load libraries with login function, 2373.69s - 2376.69s | to with the DLL path in the second parameter, 2376.69s - 2378.69s | so luckily before the control flow check, 2378.69s - 2380.69s | the validity of the callback function, 2380.69s - 2382.69s | the function is not first member of the V table, 2382.69s - 2384.69s | it's at the 0x70, 2384.69s - 2386.69s | so the start location of the V table, 2386.69s - 2388.69s | we can use to put our DLL paths, 2388.69s - 2391.69s | so without worrying about the function validity, 2391.69s - 2394.69s | because it was never used, 2394.69s - 2396.69s | so then we can load our custom DLL, 2396.69s - 2399.69s | without any resistance, 2399.69s - 2402.69s | and I will show you the demo, 2402.69s - 2411.14s | I use a normal user, 2411.14s - 2413.14s | it's in user group, 2413.14s - 2419.31s | and I write it in all the POC in the person, 2419.31s - 2424.01s | and you can see it's a normal user, 2424.01s - 2426.01s | with medium privilege, 2426.01s - 2428.01s | it's not in administrator group, 2428.01s - 2433.34s | and then we check the d.com service, 2433.34s - 2437.34s | to see if we can load our malicious DLL, 2437.34s - 2443.29s | okay we can see the shared memory, 2443.29s - 2445.29s | and the compass, 2445.29s - 2448.29s | and we see we already loaded our evil DLL, 2448.29s - 2451.29s | and there's the shell coming, 2451.29s - 2453.29s | and we type who am I, 2453.29s - 2455.29s | and we get a system privilege, 2455.29s - 2457.29s | with all the privilege, 2457.29s - 2462.93s | thank you, 2462.93s - 2463.93s | thank you, 2463.93s - 2472.26s | thank you, 2472.26s - 2479.15s | and a conclusion, 2479.15s - 2482.15s | so to be continue, 2482.15s - 2488.46s | I think there's still some research, 2488.46s - 2490.46s | I need to do in the future, 2490.46s - 2492.46s | I like the automation, 2492.46s - 2496.46s | info extract from the RPC interface, 2496.46s - 2499.46s | I need to find this exportation service, 2499.46s - 2502.46s | and the argument which made the exportation bar, 2503.46s - 2505.46s | if you


chunk_id: 201_chunk_36
chunk_text:
2428.01s | it's not in administrator group, 2428.01s - 2433.34s | and then we check the d.com service, 2433.34s - 2437.34s | to see if we can load our malicious DLL, 2437.34s - 2443.29s | okay we can see the shared memory, 2443.29s - 2445.29s | and the compass, 2445.29s - 2448.29s | and we see we already loaded our evil DLL, 2448.29s - 2451.29s | and there's the shell coming, 2451.29s - 2453.29s | and we type who am I, 2453.29s - 2455.29s | and we get a system privilege, 2455.29s - 2457.29s | with all the privilege, 2457.29s - 2462.93s | thank you, 2462.93s - 2463.93s | thank you, 2463.93s - 2472.26s | thank you, 2472.26s - 2479.15s | and a conclusion, 2479.15s - 2482.15s | so to be continue, 2482.15s - 2488.46s | I think there's still some research, 2488.46s - 2490.46s | I need to do in the future, 2490.46s - 2492.46s | I like the automation, 2492.46s - 2496.46s | info extract from the RPC interface, 2496.46s - 2499.46s | I need to find this exportation service, 2499.46s - 2502.46s | and the argument which made the exportation bar, 2503.46s - 2505.46s | if you have any good ideas, 2505.46s - 2507.46s | and you can please share it to me, 2507.46s - 2509.46s | I also want to know some good ideas, 2509.46s - 2512.46s | for the tool developing, 2512.46s - 2514.46s | and there's a much special more, 2514.46s - 2516.46s | special features in RPC, 2516.46s - 2519.46s | and the need to be examined, 2519.46s - 2522.46s | and the more effective exportation techniques, 2522.46s - 2524.46s | if you have any other any good ideas, 2524.46s - 2526.46s | feel free to contact me, 2526.46s - 2529.32s | yeah, 2529.32s - 2530.32s | and the right Bob, 2530.32s - 2532.32s | this is our bank hunting experience, 2532.32s - 2534.32s | I want to share with you, 2534.32s - 2535.32s | and the first don't trust, 2535.32s - 2537.32s | any patches from the render, 2537.32s - 2538.32s | it may still not patch, 2538.32s - 2540.32s | the vulnerability effectively, 2540.32s - 2542.32s | and also the patch analyze, 2542.32s - 2545.32s | is still more effect in bug hunting, 2545.32s - 2547.32s | you should be more creative, 2547.32s - 2550.32s | and the criticism when bug


chunk_id: 201_chunk_37
chunk_text:
have any good ideas, 2505.46s - 2507.46s | and you can please share it to me, 2507.46s - 2509.46s | I also want to know some good ideas, 2509.46s - 2512.46s | for the tool developing, 2512.46s - 2514.46s | and there's a much special more, 2514.46s - 2516.46s | special features in RPC, 2516.46s - 2519.46s | and the need to be examined, 2519.46s - 2522.46s | and the more effective exportation techniques, 2522.46s - 2524.46s | if you have any other any good ideas, 2524.46s - 2526.46s | feel free to contact me, 2526.46s - 2529.32s | yeah, 2529.32s - 2530.32s | and the right Bob, 2530.32s - 2532.32s | this is our bank hunting experience, 2532.32s - 2534.32s | I want to share with you, 2534.32s - 2535.32s | and the first don't trust, 2535.32s - 2537.32s | any patches from the render, 2537.32s - 2538.32s | it may still not patch, 2538.32s - 2540.32s | the vulnerability effectively, 2540.32s - 2542.32s | and also the patch analyze, 2542.32s - 2545.32s | is still more effect in bug hunting, 2545.32s - 2547.32s | you should be more creative, 2547.32s - 2550.32s | and the criticism when bug hunting, 2550.32s - 2551.32s | yeah, 2551.32s - 2553.32s | you should dare to do it, 2553.32s - 2555.32s | and we should be patient, 2555.32s - 2559.32s | but bug hunting is a long way marathon, 2559.32s - 2560.32s | and at last, 2560.32s - 2562.32s | don't meet any miss, 2562.32s - 2564.32s | any other, 2564.32s - 2565.32s | any side effect, 2565.32s - 2568.32s | this effect may cause security flaw, 2568.32s - 2571.60s | afterwards, 2571.60s - 2572.60s | yeah, 2572.60s - 2575.60s | and for this type of service, 2575.60s - 2577.60s | we mentioned in the talk, 2577.60s - 2580.60s | there's still much special feature in the RPC, 2580.60s - 2582.60s | we need to examine, 2582.60s - 2584.60s | and the security of RPC, 2584.60s - 2587.60s | is actually affect the security of the RPC, 2587.60s - 2589.60s | for Microsoft we can see, 2589.60s - 2592.60s | it's really done a great tireless work, 2592.60s - 2594.60s | on the security of the RPC services, 2594.60s - 2596.60s | although we cause the double fish, 2596.60s - 2597.60s | in the RPC services, 2597.60s - 2599.60s | we need


chunk_id: 201_chunk_38
chunk_text:
hunting, 2550.32s - 2551.32s | yeah, 2551.32s - 2553.32s | you should dare to do it, 2553.32s - 2555.32s | and we should be patient, 2555.32s - 2559.32s | but bug hunting is a long way marathon, 2559.32s - 2560.32s | and at last, 2560.32s - 2562.32s | don't meet any miss, 2562.32s - 2564.32s | any other, 2564.32s - 2565.32s | any side effect, 2565.32s - 2568.32s | this effect may cause security flaw, 2568.32s - 2571.60s | afterwards, 2571.60s - 2572.60s | yeah, 2572.60s - 2575.60s | and for this type of service, 2575.60s - 2577.60s | we mentioned in the talk, 2577.60s - 2580.60s | there's still much special feature in the RPC, 2580.60s - 2582.60s | we need to examine, 2582.60s - 2584.60s | and the security of RPC, 2584.60s - 2587.60s | is actually affect the security of the RPC, 2587.60s - 2589.60s | for Microsoft we can see, 2589.60s - 2592.60s | it's really done a great tireless work, 2592.60s - 2594.60s | on the security of the RPC services, 2594.60s - 2596.60s | although we cause the double fish, 2596.60s - 2597.60s | in the RPC services, 2597.60s - 2599.60s | we need to still find, 2599.60s - 2601.60s | export both service, 2601.60s - 2603.60s | and the parameters still meet, 2603.60s - 2607.60s | very strict bars, 2607.60s - 2610.60s | and this is a reference of our talk, 2610.60s - 2612.60s | and thank you, 2612.60s - 2613.60s | is there another questions, 2613.60s - 2614.60s | because there is a microphone, 2614.60s - 2615.60s | has any problems, 2615.60s - 2616.60s | and sorry for that, 2616.60s - 2617.60s | yeah, 2617.60s - 2631.53s | thank you.


chunk_id: 201_chunk_39
chunk_text:
to still find, 2599.60s - 2601.60s | export both service, 2601.60s - 2603.60s | and the parameters still meet, 2603.60s - 2607.60s | very strict bars, 2607.60s - 2610.60s | and this is a reference of our talk, 2610.60s - 2612.60s | and thank you, 2612.60s - 2613.60s | is there another questions, 2613.60s - 2614.60s | because there is a microphone, 2614.60s - 2615.60s | has any problems, 2615.60s - 2616.60s | and sorry for that, 2616.60s - 2617.60s | yeah, 2617.60s - 2631.53s | thank you.


chunk_id: 202_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=GwwxeY11xMI", "title": "DEF CON 32 - Outlook Unleashing RCE Chaos CVE 2024 30103 - Michael Gorelik, Arnold Osipov", "description": "Did you ever receive an empty email and immediately think it might be a reconnaissance attack? What if opening such an email in your Outlook client could trigger remote code execution through an invisible form? Yes, all forms are COM objects, and CVE-2024-21378 has flung open the gates to Outlook RCE chaos.\n\nIn our session, \"Outlook Unleashing RCE Chaos: CVE-2024-30103\" we'll dive into how this seemingly innocuous vulnerability can lead to mayhem. This vulnerability paved the way for us to discover a series of new remote code execution vulnerabilities in Outlook, including CVE-2024-30103. But we\u2019re not stopping there.\n\nAdditionally, we'll uncover other vulnerabilities that can cause NTLM leaks from your domain-joined devices.\n\nSo, how did we get here? Join us as we construct an evolution timeline of this attack surface. From the origins of these exploits to their current incarnations, we'll cover it all. And because we believe in building a safer digital world, we'll conclude with specific, actionable recommendations on how to minimize these threats.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2470, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.74s - 3.74s | This text was transcribed using whisper model: large-v2 Hey, good evening to everyone 4.98s - 6.98s | Okay 10.61s - 12.61s | Thank you, thank you, thank you 13.25s - 15.25s | okay, so 15.65s - 17.65s | What do you expect from patches? 17.99s - 19.55s | security updates 19.55s - 26.13s | You expect them to be a fort knox security update right that solves fully the vulnerability all the control flows 26.81s - 31.98s | Is it really in reality? This is what we usually get 33.96s - 36.40s | Yep, so we all been there 37.08s - 42.16s | Expecting that one patch solves it all right, but essentially it's kind of a bullet 43.16s - 46.18s | Patch to a bullet or there's a better phrase to that 46.82s - 48.44s | we will be 48.44s - 53.72s | sharing insights about what happens when the patch not quite do the trick and 55.32s - 57.32s | Sometimes you also find new vulnerabilities 57.56s - 64.60s | So this talk will be sharing new details about vulnerabilities that we discovered and we're patched during June and July 65.48s - 67.48s | those are two out of


chunk_id: 203_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=KnCp5K51IEA", "title": "DEF CON 32 - Cultivating M4D SK1LLZ In the DEF CON Community - Yan Shoshitaishvili, Perri Adams", "description": "DEF CON is a siren song for the hacker mind. Clever people around the world hear it and are pulled, every year, to Las Vegas. They mass by the tens of thousands, streaming through the halls of DEF CON to watch talks given by absolute legends about incredible escapades, to gaze in wonder as true wizards bend bytes to their will in the CTF room, and to dream about one day reaching to those heights themselves.\n\nSome have the critical combination of grit, perseverance, raw talent, and (let's face it) privilege to push through to those dreams of greatness. But among even the clever and the motivated, it is rare for n00bs to rise to l33tness without support. Some find this support in inspiring classes in college. Others, among friends or mentors. But many don't find it at all, and remain in the hallways, dreaming.\n\nDo you want to leave the hallways and hack the planet? We are hackers, educators, and learners who are creating DEF CON Academy, a concerted effort to maximize hacker potential by providing open, clear, approachable, and inclusive practical resources for budding hackers to transcend and rule cyberspace. Through extensive DEF CON event presence and year-round hacking resources, we will pro up the noobs of the world and bring the community, at scale, to the next level of skill.\n\nCome, listen, and learn how we can help!", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2565, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.02s - 6.50s | This text was transcribed using whisper model: large-v2 Alright. Welcome to the sneak peek for uh something you're super excited about. Barry and I 6.50s - 13.50s | have been working on this for a little while now. Um along with the amazing people you see 13.50s - 18.50s | on stage here. We'll talk about everybody in turn. But first we'll talk about Defcon Academy. 21.18s - 26.18s | So. Uh is there a can people see the slides somewhere? Oh they can. Oh great perfect. Alright. 27.18s - 32.18s | So first things first. On the slide there's a URL. CTF dot Defcon Academy. While we talk go 37.62s - 42.62s | there. CTF dot Defcon Academy. On the bottom there's a link to get started with a little 46.00s - 52.80s |


chunk_id: 203_chunk_1
chunk_text:
and inclusive practical resources for budding hackers to transcend and rule cyberspace. Through extensive DEF CON event presence and year-round hacking resources, we will pro up the noobs of the world and bring the community, at scale, to the next level of skill.\n\nCome, listen, and learn how we can help!", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2565, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.02s - 6.50s | This text was transcribed using whisper model: large-v2 Alright. Welcome to the sneak peek for uh something you're super excited about. Barry and I 6.50s - 13.50s | have been working on this for a little while now. Um along with the amazing people you see 13.50s - 18.50s | on stage here. We'll talk about everybody in turn. But first we'll talk about Defcon Academy. 21.18s - 26.18s | So. Uh is there a can people see the slides somewhere? Oh they can. Oh great perfect. Alright. 27.18s - 32.18s | So first things first. On the slide there's a URL. CTF dot Defcon Academy. While we talk go 37.62s - 42.62s | there. CTF dot Defcon Academy. On the bottom there's a link to get started with a little 46.00s - 52.80s | challenge race. It's not extraordinarily hard stuff. It's it's test your Linux knowledge. How 52.80s - 59.26s | much Linux do you know? At the end we're gonna do a little award ceremony for the people 59.26s - 63.34s | farthest ahead in that race. We'll just see how many people we have time to give challenge 63.34s - 68.24s | points to. It's gonna be awesome. And we'll check in throughout the the talk if we have time. 68.24s - 73.24s | Awesome. Okay. Welcome. Let's talk about us. Yes. I think that's a great idea. Uh Barry take it 75.62s - 82.26s | away. I don't know why I'm first. But. Hi. My name is Perry Adams. I'm currently a uh special 82.28s - 87.62s | assistant to the director at DARPA. But before that I was as you can see on the screen a uh 87.62s - 93.96s | CTF player. That picture in the middle is proof that at one point in time I did know how to use a 93.96s - 98.96s | computer. Uh the jury's still out on if that's still the case. Uh oh. Uh case in point. 103.00s - 108.00s |


chunk_id: 203_chunk_2
chunk_text:
challenge race. It's not extraordinarily hard stuff. It's it's test your Linux knowledge. How 52.80s - 59.26s | much Linux do you know? At the end we're gonna do a little award ceremony for the people 59.26s - 63.34s | farthest ahead in that race. We'll just see how many people we have time to give challenge 63.34s - 68.24s | points to. It's gonna be awesome. And we'll check in throughout the the talk if we have time. 68.24s - 73.24s | Awesome. Okay. Welcome. Let's talk about us. Yes. I think that's a great idea. Uh Barry take it 75.62s - 82.26s | away. I don't know why I'm first. But. Hi. My name is Perry Adams. I'm currently a uh special 82.28s - 87.62s | assistant to the director at DARPA. But before that I was as you can see on the screen a uh 87.62s - 93.96s | CTF player. That picture in the middle is proof that at one point in time I did know how to use a 93.96s - 98.96s | computer. Uh the jury's still out on if that's still the case. Uh oh. Uh case in point. 103.00s - 108.00s | Computers. How do they even work? Uh but I played for uh the CTF team RPI sec and that picture 108.96s - 113.96s | is of us playing at DEF CON finals uh in 2018. And uh RPI sec and CTF was really how I got 118.96s - 124.34s | started playing uh I got started in computer security. And that's really what we're gonna be 124.34s - 129.74s | talking about today. The kind of uh education that that provided me and how we want to give 129.74s - 135.12s | that to the rest of you. As I was putting together these slides uh what was next to all those 135.14s - 140.18s | pictures was a picture of my cat and because it's DEF CON I thought it was appropriate to at 140.18s - 145.72s | least have one of those in the slides. Uh after I played CTF for a while I ran DEF CON CTF 145.72s - 151.46s | for a little bit. Uh that is uh from one of the years where we were writing challenges. That 151.46s - 158.26s | picture is of uh three uh two of my uh uh fellow challenge


chunk_id: 203_chunk_3
chunk_text:
Computers. How do they even work? Uh but I played for uh the CTF team RPI sec and that picture 108.96s - 113.96s | is of us playing at DEF CON finals uh in 2018. And uh RPI sec and CTF was really how I got 118.96s - 124.34s | started playing uh I got started in computer security. And that's really what we're gonna be 124.34s - 129.74s | talking about today. The kind of uh education that that provided me and how we want to give 129.74s - 135.12s | that to the rest of you. As I was putting together these slides uh what was next to all those 135.14s - 140.18s | pictures was a picture of my cat and because it's DEF CON I thought it was appropriate to at 140.18s - 145.72s | least have one of those in the slides. Uh after I played CTF for a while I ran DEF CON CTF 145.72s - 151.46s | for a little bit. Uh that is uh from one of the years where we were writing challenges. That 151.46s - 158.26s | picture is of uh three uh two of my uh uh fellow challenge authors the year that our challenge 158.26s - 163.20s | melted the infrastructure just a little bit which goes to show that computers are hard and 163.22s - 168.92s | I'm not sure if I know how to use them correctly. And now in my day job I am at DARPA where 168.92s - 174.80s | one of the things that I have done is create AICC which if you haven't seen yet I really 174.80s - 180.56s | encourage you to go check it out over there. We're very proud of what we've been able to do. 180.56s - 187.08s | And the kind of software security challenges that AICC is working to address is exactly what 187.12s - 193.96s | we hope to educate people about with DEF CON Academy. And uh finally I have this picture up 193.96s - 200.70s | here because I talked about how I learned about computer security by playing CTF but what was 200.70s - 207.08s | so formative for me was having my teammates on RPISEC to help me learn. When I first got 207.08s - 213.08s | started they told me that I could not have hypothetically let's say they


chunk_id: 203_chunk_4
chunk_text:
authors the year that our challenge 158.26s - 163.20s | melted the infrastructure just a little bit which goes to show that computers are hard and 163.22s - 168.92s | I'm not sure if I know how to use them correctly. And now in my day job I am at DARPA where 168.92s - 174.80s | one of the things that I have done is create AICC which if you haven't seen yet I really 174.80s - 180.56s | encourage you to go check it out over there. We're very proud of what we've been able to do. 180.56s - 187.08s | And the kind of software security challenges that AICC is working to address is exactly what 187.12s - 193.96s | we hope to educate people about with DEF CON Academy. And uh finally I have this picture up 193.96s - 200.70s | here because I talked about how I learned about computer security by playing CTF but what was 200.70s - 207.08s | so formative for me was having my teammates on RPISEC to help me learn. When I first got 207.08s - 213.08s | started they told me that I could not have hypothetically let's say they told me I could not 213.08s - 218.10s | have IDA until I had learned how to solve a CTF challenge using OBJDUMP. And if you haven't 221.10s - 227.20s | seen the output of OBJDUMP that's what a binary looks like. It's much less pretty than IDA and 227.20s - 233.28s | this was of course before we had Ghidra. But when I was doing this I had people I could call 233.28s - 238.18s | I had uh I could phone a friend I could get help and that's really what we're trying to do. 238.18s - 242.46s | What they've been trying to do with DEF CON Academy. 242.46s - 248.50s | Thanks Mary. So before I talk about myself which I love doing I want to uh check on one 248.50s - 254.20s | terrifying thing. Oh this is counting upwards. Okay thank God. Alright. Awesome. So then we can 254.20s - 264.20s | just calmly continue. Alright. I'm Zardis and I am uh I can say with some trepidation that I'm 265.08s - 273.80s | that I'm way too loud. Um that I've been coming to DEF CON since DEF CON 9. This is super


chunk_id: 203_chunk_5
chunk_text:
told me I could not 213.08s - 218.10s | have IDA until I had learned how to solve a CTF challenge using OBJDUMP. And if you haven't 221.10s - 227.20s | seen the output of OBJDUMP that's what a binary looks like. It's much less pretty than IDA and 227.20s - 233.28s | this was of course before we had Ghidra. But when I was doing this I had people I could call 233.28s - 238.18s | I had uh I could phone a friend I could get help and that's really what we're trying to do. 238.18s - 242.46s | What they've been trying to do with DEF CON Academy. 242.46s - 248.50s | Thanks Mary. So before I talk about myself which I love doing I want to uh check on one 248.50s - 254.20s | terrifying thing. Oh this is counting upwards. Okay thank God. Alright. Awesome. So then we can 254.20s - 264.20s | just calmly continue. Alright. I'm Zardis and I am uh I can say with some trepidation that I'm 265.08s - 273.80s | that I'm way too loud. Um that I've been coming to DEF CON since DEF CON 9. This is super cool 273.80s - 285.84s | DEF CON 9. Is that my feedback? You gotta keep them separated. DEF CON 9 was it's this guy. 286.72s - 311.43s | That's what it's like working with Jan. Every day. Alright. You wanna. Every time. 317.22s - 327.30s | Ladies and gentlemen the Dark Tangent. Honorary AV uh maestro. Okay cool. So um I've been coming 327.30s - 336.50s | to DEF CON since DEF CON 9. Right. This was a long long time ago. Um and uh from DEF CON 9 up 336.50s - 342.58s | until DEF CON 17 I would come to DEF CON. I'd wander the halls. I'd look around at all this 342.58s - 349.78s | incredible hacking. I'd get really amped up but I wasn't really making progress. I was slowly 349.78s - 354.50s | very very slowly building up my skills over the course of eight years and then after eight years 354.50s - 362.26s | an eternity in cyber security time I finally got into CTF. I started playing CTF with team 362.26s - 371.22s | Shellfish and then my life as a hacker ah my life as a hacker accelerated rapidly. Uh within 371.22s


chunk_id: 203_chunk_6
chunk_text:
cool 273.80s - 285.84s | DEF CON 9. Is that my feedback? You gotta keep them separated. DEF CON 9 was it's this guy. 286.72s - 311.43s | That's what it's like working with Jan. Every day. Alright. You wanna. Every time. 317.22s - 327.30s | Ladies and gentlemen the Dark Tangent. Honorary AV uh maestro. Okay cool. So um I've been coming 327.30s - 336.50s | to DEF CON since DEF CON 9. Right. This was a long long time ago. Um and uh from DEF CON 9 up 336.50s - 342.58s | until DEF CON 17 I would come to DEF CON. I'd wander the halls. I'd look around at all this 342.58s - 349.78s | incredible hacking. I'd get really amped up but I wasn't really making progress. I was slowly 349.78s - 354.50s | very very slowly building up my skills over the course of eight years and then after eight years 354.50s - 362.26s | an eternity in cyber security time I finally got into CTF. I started playing CTF with team 362.26s - 371.22s | Shellfish and then my life as a hacker ah my life as a hacker accelerated rapidly. Uh within 371.22s - 378.02s | a couple years from that I'd created with uh my uh colleagues one of the uh most powerful 378.02s - 388.02s | binary analysis tools on the planet. Later with uh also amazing colleagues we started hosting 388.02s - 393.54s | DEF CON CTF. We went from running it uh from playing in it to hosting it. Then I became a 393.54s - 402.98s | professor. That's still us? I gotta get to my alright. Uh later we went from uh 403.54s - 407.54s | playing to hosting and then I became professor at Arizona State University. 409.99s - 417.64s | Dude I feel like I'm at a sci-fi. This is awesome. This is great. We can probably just turn this one 417.64s - 432.45s | off. Awesome. Okay. So um and all of this happened relatively quickly once I started playing CTF and 432.45s - 440.45s | once my security knowledge started getting ramped up very rapidly and there was this inflection point 440.45s - 448.21s | in DEF CON 17 but that took eight years to get there right and what I've been thinking for a 448.21s - 454.21s | long long time is how


chunk_id: 203_chunk_7
chunk_text:
- 378.02s | a couple years from that I'd created with uh my uh colleagues one of the uh most powerful 378.02s - 388.02s | binary analysis tools on the planet. Later with uh also amazing colleagues we started hosting 388.02s - 393.54s | DEF CON CTF. We went from running it uh from playing in it to hosting it. Then I became a 393.54s - 402.98s | professor. That's still us? I gotta get to my alright. Uh later we went from uh 403.54s - 407.54s | playing to hosting and then I became professor at Arizona State University. 409.99s - 417.64s | Dude I feel like I'm at a sci-fi. This is awesome. This is great. We can probably just turn this one 417.64s - 432.45s | off. Awesome. Okay. So um and all of this happened relatively quickly once I started playing CTF and 432.45s - 440.45s | once my security knowledge started getting ramped up very rapidly and there was this inflection point 440.45s - 448.21s | in DEF CON 17 but that took eight years to get there right and what I've been thinking for a 448.21s - 454.21s | long long time is how do we accelerate that? What was missing here? And Perry alluded to it. 455.17s - 466.13s | When I started I didn't have a group that could mentor. I was a high schooler but that doesn't 466.13s - 471.81s | stop people. I've seen high schoolers accelerate rapidly in cyber security skill when they have 471.81s - 481.51s | the right environment to enable them right and so our question was our question was how do we 482.15s - 488.95s | actually make this possible for the DEF CON community? Alright. Preview. It looks like a belt. 489.83s - 501.67s | Alright. So DEF CON 17. Shellfish. DEF CON CTF. This is my view into what the difference was from 501.67s - 506.87s | before I was a pro to after I was a pro and and spoiler alert I'm still not a pro but I would 506.87s - 513.91s | tell all of my students if you want to get really great at cyber security you have to go play CTF 513.91s - 521.83s | right and this is a picture for example of my students playing one of the CTFs that I hosted 521.83s - 531.59s | with


chunk_id: 203_chunk_8
chunk_text:
do we accelerate that? What was missing here? And Perry alluded to it. 455.17s - 466.13s | When I started I didn't have a group that could mentor. I was a high schooler but that doesn't 466.13s - 471.81s | stop people. I've seen high schoolers accelerate rapidly in cyber security skill when they have 471.81s - 481.51s | the right environment to enable them right and so our question was our question was how do we 482.15s - 488.95s | actually make this possible for the DEF CON community? Alright. Preview. It looks like a belt. 489.83s - 501.67s | Alright. So DEF CON 17. Shellfish. DEF CON CTF. This is my view into what the difference was from 501.67s - 506.87s | before I was a pro to after I was a pro and and spoiler alert I'm still not a pro but I would 506.87s - 513.91s | tell all of my students if you want to get really great at cyber security you have to go play CTF 513.91s - 521.83s | right and this is a picture for example of my students playing one of the CTFs that I hosted 521.83s - 531.59s | with Adam who's sitting right here and they show up and they do awesome but this is the success 531.59s - 538.39s | stories that you see what you don't see in the CTF community is the hundreds and hundreds of 538.39s - 547.27s | students for every one that play CTF that try to play CTF and face the reality that 547.27s - 554.47s | capture the flag competitions are not designed for education they're designed to test your skills 555.43s - 567.86s | so this is intentional in CTF. A CTF competition is created by hackers for hackers to challenge 567.86s - 575.86s | hackers specifically and no one wants to play a CTF where the answers are all obvious and the 575.86s - 582.74s | challenges are easy and so on and and so CTFs basically by definition become a very boring 582.74s - 587.62s | teaching tool. And when I got started playing CTF the thing that was fun about it was that I had a 588.26s - 594.10s | team who I'd play with and we'd go and we'd spend 48 hours in a lecture hall that we certainly did 594.10s - 600.74s | not we


chunk_id: 203_chunk_9
chunk_text:
Adam who's sitting right here and they show up and they do awesome but this is the success 531.59s - 538.39s | stories that you see what you don't see in the CTF community is the hundreds and hundreds of 538.39s - 547.27s | students for every one that play CTF that try to play CTF and face the reality that 547.27s - 554.47s | capture the flag competitions are not designed for education they're designed to test your skills 555.43s - 567.86s | so this is intentional in CTF. A CTF competition is created by hackers for hackers to challenge 567.86s - 575.86s | hackers specifically and no one wants to play a CTF where the answers are all obvious and the 575.86s - 582.74s | challenges are easy and so on and and so CTFs basically by definition become a very boring 582.74s - 587.62s | teaching tool. And when I got started playing CTF the thing that was fun about it was that I had a 588.26s - 594.10s | team who I'd play with and we'd go and we'd spend 48 hours in a lecture hall that we certainly did 594.10s - 600.74s | not we weren't allowed to actually be in overnight but that's what we would do and it felt very 600.74s - 605.70s | collaborative and we could learn from each other but for many people they don't have that resource. 606.58s - 613.46s | Yeah and so figuring out what a replacement resource is for that that's one of the challenges 613.46s - 620.66s | that we kind of set to ourselves that resulted in DEFCON Academy. That's DEFCON Academy's first 620.66s - 628.50s | goal. Our first goal is getting people from DEFCON 9 to DEFCON 17. Getting them to the point where 628.50s - 635.78s | they can start have the skills to start playing CTF to start contributing actively in cyber 635.78s - 644.42s | security and then we have a second question. Something that I've seen recently as I've 644.42s - 649.94s | trained up more and more students with cyber security knowledge is that people learn this 649.94s - 656.26s | knowledge they have the technical skills to dive into CTF competitions to really start accelerating 656.26s - 662.42s | more and more and more but they there's still something missing. The competition part of a CTF


chunk_id: 203_chunk_10
chunk_text:
weren't allowed to actually be in overnight but that's what we would do and it felt very 600.74s - 605.70s | collaborative and we could learn from each other but for many people they don't have that resource. 606.58s - 613.46s | Yeah and so figuring out what a replacement resource is for that that's one of the challenges 613.46s - 620.66s | that we kind of set to ourselves that resulted in DEFCON Academy. That's DEFCON Academy's first 620.66s - 628.50s | goal. Our first goal is getting people from DEFCON 9 to DEFCON 17. Getting them to the point where 628.50s - 635.78s | they can start have the skills to start playing CTF to start contributing actively in cyber 635.78s - 644.42s | security and then we have a second question. Something that I've seen recently as I've 644.42s - 649.94s | trained up more and more students with cyber security knowledge is that people learn this 649.94s - 656.26s | knowledge they have the technical skills to dive into CTF competitions to really start accelerating 656.26s - 662.42s | more and more and more but they there's still something missing. The competition part of a CTF 662.42s - 670.66s | competition the chaotic environment the lack of educational resources specific to do with 670.66s - 677.22s | cutting-edge CTF challenges that makes things hard and that is where the mentorship that Barry 677.22s - 684.18s | mentioned comes in. So how do we streamline that process? Get people once they have technical skills 684.18s - 689.54s | to actually engage with a community where they can test these skills and and interact with others 689.54s - 700.34s | that are doing so. Then how do we keep pulling that talent back into DEFCON so that we can have a 701.94s - 707.30s | kind of self-reinforcing loop that'll continue with the community continue building the community 707.30s - 720.60s | more and more. A little louder? Then I get the if I do this hold on test all right we're still good 720.60s - 730.60s | okay no uh you know tone of god over here okay so um and then of course once people go and they 730.60s - 734.76s | they they learn all the cyber security stuff and they're cyber security master hackers how do we 734.76s - 741.64s | get people to


chunk_id: 203_chunk_11
chunk_text:
662.42s - 670.66s | competition the chaotic environment the lack of educational resources specific to do with 670.66s - 677.22s | cutting-edge CTF challenges that makes things hard and that is where the mentorship that Barry 677.22s - 684.18s | mentioned comes in. So how do we streamline that process? Get people once they have technical skills 684.18s - 689.54s | to actually engage with a community where they can test these skills and and interact with others 689.54s - 700.34s | that are doing so. Then how do we keep pulling that talent back into DEFCON so that we can have a 701.94s - 707.30s | kind of self-reinforcing loop that'll continue with the community continue building the community 707.30s - 720.60s | more and more. A little louder? Then I get the if I do this hold on test all right we're still good 720.60s - 730.60s | okay no uh you know tone of god over here okay so um and then of course once people go and they 730.60s - 734.76s | they they learn all the cyber security stuff and they're cyber security master hackers how do we 734.76s - 741.64s | get people to actually be able to use this as a living? How many of you make a living doing 741.64s - 751.72s | cyber security? Awesome. How many don't but would like to? All right so how do we get you 752.84s - 758.60s | to the place where you can make that living? And then how many of you are cyber security pros 759.24s - 767.83s | master hackers? I see my students trying to raise their hands over there uh one day well we'll get 767.83s - 774.95s | you there as well. All right so the answer of course DEFCON Academy and DEFCON Academy is going 774.95s - 781.75s | to at least take steps to solve all of these problems. So Perry what do you hope to see out 781.75s - 789.35s | of DEFCON Academy? Well so DARPA has a history of funding work in uh cyber security education but 789.35s - 797.03s | specifically in things like binary exploitation vulnerability research etc uh things like DARPA 797.03s - 803.43s | chess uh focus on uh improving computer human interactions that was something that you all 803.43s - 809.43s | worked on. We actually have some other


chunk_id: 203_chunk_12
chunk_text:
actually be able to use this as a living? How many of you make a living doing 741.64s - 751.72s | cyber security? Awesome. How many don't but would like to? All right so how do we get you 752.84s - 758.60s | to the place where you can make that living? And then how many of you are cyber security pros 759.24s - 767.83s | master hackers? I see my students trying to raise their hands over there uh one day well we'll get 767.83s - 774.95s | you there as well. All right so the answer of course DEFCON Academy and DEFCON Academy is going 774.95s - 781.75s | to at least take steps to solve all of these problems. So Perry what do you hope to see out 781.75s - 789.35s | of DEFCON Academy? Well so DARPA has a history of funding work in uh cyber security education but 789.35s - 797.03s | specifically in things like binary exploitation vulnerability research etc uh things like DARPA 797.03s - 803.43s | chess uh focus on uh improving computer human interactions that was something that you all 803.43s - 809.43s | worked on. We actually have some other PMs in the office or in the audience who are leading some of 809.43s - 816.07s | these efforts and so that was really what DEFCON Academy came out of for for DARPA was how can we 816.07s - 822.23s | bring the cyber security education resources that we've been developing and open sourcing 822.23s - 828.15s | uh with uh the many groups that DARPA works with including ASU and how do we bring them to the 828.15s - 835.51s | community? And so what I really hope to get out of this is uh we've spent a decade more than that 835.51s - 841.67s | uh researching how to best educate people in this space uh that combined with all of the expertise 841.67s - 847.91s | that running DEFCON CTF playing DEFCON CTF and other kinds of CTFs have built up I I think there's 847.91s - 853.11s | a huge amount of potential to revolutionize how we do cyber security education especially in 853.11s - 859.51s | the vulnerability research binary exploitation memory safety space which is so fundamentally 859.51s - 867.35s | important today. I agree and you know what I would build on that


chunk_id: 203_chunk_13
chunk_text:
PMs in the office or in the audience who are leading some of 809.43s - 816.07s | these efforts and so that was really what DEFCON Academy came out of for for DARPA was how can we 816.07s - 822.23s | bring the cyber security education resources that we've been developing and open sourcing 822.23s - 828.15s | uh with uh the many groups that DARPA works with including ASU and how do we bring them to the 828.15s - 835.51s | community? And so what I really hope to get out of this is uh we've spent a decade more than that 835.51s - 841.67s | uh researching how to best educate people in this space uh that combined with all of the expertise 841.67s - 847.91s | that running DEFCON CTF playing DEFCON CTF and other kinds of CTFs have built up I I think there's 847.91s - 853.11s | a huge amount of potential to revolutionize how we do cyber security education especially in 853.11s - 859.51s | the vulnerability research binary exploitation memory safety space which is so fundamentally 859.51s - 867.35s | important today. I agree and you know what I would build on that with is that whatever specific 868.31s - 877.43s | first uh goal you set for students binary exploitation memory safety etc the if you can get 877.43s - 884.47s | a hacker to skill up to that you can get them to skill up to web security you can get them to skill 884.47s - 893.43s | up to network operations to threat hunting it all folds together and use a common uh process of 893.91s - 903.03s | process of learning and thinking about our own experiences talking long long hours with 903.03s - 911.51s | dark tangent we came up with this idea that hey let's actually make a part of DEFCON that is 912.07s - 917.99s | hyper optimized to make this happen for students. So but I want to add one other thing too the other 917.99s - 922.79s | part of this is is uh set up and the pain and suffering that goes into actually creating an 922.79s - 927.67s | environment in which you can learn uh and the infrastructure part is boring and sometimes we 927.67s - 931.91s | don't think about that as research but having played a lot of CTF


chunk_id: 203_chunk_14
chunk_text:
with is that whatever specific 868.31s - 877.43s | first uh goal you set for students binary exploitation memory safety etc the if you can get 877.43s - 884.47s | a hacker to skill up to that you can get them to skill up to web security you can get them to skill 884.47s - 893.43s | up to network operations to threat hunting it all folds together and use a common uh process of 893.91s - 903.03s | process of learning and thinking about our own experiences talking long long hours with 903.03s - 911.51s | dark tangent we came up with this idea that hey let's actually make a part of DEFCON that is 912.07s - 917.99s | hyper optimized to make this happen for students. So but I want to add one other thing too the other 917.99s - 922.79s | part of this is is uh set up and the pain and suffering that goes into actually creating an 922.79s - 927.67s | environment in which you can learn uh and the infrastructure part is boring and sometimes we 927.67s - 931.91s | don't think about that as research but having played a lot of CTF I know that setting up an 931.91s - 936.55s | environment is very annoying very painful and when I first started out that was the last thing I 936.55s - 941.75s | wanted to learn how to do. I didn't know how to boot Linux when I joined RPISec that's very 941.75s - 947.83s | embarrassing uh so I'm sharing it here today and we're not gonna spread that uh and so I think one 947.83s - 955.35s | of the best aspects of this and one of the uh other pillars is that it removes the initial uh 955.35s - 961.03s | pain from learning and it puts you into the fun environment immediately. So how can we 962.55s - 968.95s | take a random DEFCON attendee grab them out of the hallway and once they start stop screaming and 968.95s - 977.51s | hitting us actually give them an opportunity to just start learning immediately. No startup costs 978.23s - 986.39s | no confusion just go and in other words how can we take this DEFCON 9 to DEFCON 17 eight years 987.27s - 993.99s | and we narrow them down well. I actually think the best way


chunk_id: 203_chunk_15
chunk_text:
I know that setting up an 931.91s - 936.55s | environment is very annoying very painful and when I first started out that was the last thing I 936.55s - 941.75s | wanted to learn how to do. I didn't know how to boot Linux when I joined RPISec that's very 941.75s - 947.83s | embarrassing uh so I'm sharing it here today and we're not gonna spread that uh and so I think one 947.83s - 955.35s | of the best aspects of this and one of the uh other pillars is that it removes the initial uh 955.35s - 961.03s | pain from learning and it puts you into the fun environment immediately. So how can we 962.55s - 968.95s | take a random DEFCON attendee grab them out of the hallway and once they start stop screaming and 968.95s - 977.51s | hitting us actually give them an opportunity to just start learning immediately. No startup costs 978.23s - 986.39s | no confusion just go and in other words how can we take this DEFCON 9 to DEFCON 17 eight years 987.27s - 993.99s | and we narrow them down well. I actually think the best way to put it is how can we make Connor 993.99s - 1000.79s | do all of the infrastructure set up for uh DEFCON attendees. Exactly it's uh basically uh 1001.19s - 1007.99s | uh tasking all the way down um because the answer to that is Connor will find his own students. 1009.27s - 1015.27s | All right so there's two parts to learning there's a lot of learning research learning 1015.27s - 1021.67s | learning is is a thing that humans have done maybe for years maybe even decades. So 1022.55s - 1028.79s | there's theory and practice right you might say well okay let's have a DEFCON academy that that 1028.79s - 1035.99s | runs courses we'll like have uh you know our powerpoint slides we'll pull in hackers off the 1035.99s - 1041.59s | out of the hallway and we'll uh have them viewing the powerpoint slides and I did this I do this a 1041.59s - 1046.31s | lot this is a picture of my students from last semester. No I'm just kidding I pulled this off 1046.31s - 1052.47s | the internet but because my students are all riveted in class but just like you


chunk_id: 203_chunk_16
chunk_text:
to put it is how can we make Connor 993.99s - 1000.79s | do all of the infrastructure set up for uh DEFCON attendees. Exactly it's uh basically uh 1001.19s - 1007.99s | uh tasking all the way down um because the answer to that is Connor will find his own students. 1009.27s - 1015.27s | All right so there's two parts to learning there's a lot of learning research learning 1015.27s - 1021.67s | learning is is a thing that humans have done maybe for years maybe even decades. So 1022.55s - 1028.79s | there's theory and practice right you might say well okay let's have a DEFCON academy that that 1028.79s - 1035.99s | runs courses we'll like have uh you know our powerpoint slides we'll pull in hackers off the 1035.99s - 1041.59s | out of the hallway and we'll uh have them viewing the powerpoint slides and I did this I do this a 1041.59s - 1046.31s | lot this is a picture of my students from last semester. No I'm just kidding I pulled this off 1046.31s - 1052.47s | the internet but because my students are all riveted in class but just like you all exactly 1053.27s - 1059.51s | you have all been in classes throughout your life where things are boring people are rambling on 1059.51s - 1067.35s | about the stack gets subtracted from when a function starts and you get a lot of information 1067.35s - 1072.79s | and not a lot of it sticks right you might have like one or two practice problems but 1073.91s - 1079.27s | the modern state unfortunately of cyber security education is actually pretty poor 1079.67s - 1085.59s | and this is uh really interesting because it's understandable academically there's this thing 1085.59s - 1090.95s | called the learning pyramid full of really awesome made-up numbers where you know you can say hey if 1090.95s - 1096.47s | I go and I lecture to you you will learn like five percent of the material or retain five percent of 1096.47s - 1101.99s | the material but if I you know have you read about it uh yourself you'll you'll learn more 1102.95s - 1109.67s | and if I uh have you practice actually practice the stuff you will learn a majority you'll learn 1109.67s - 1115.75s | 75 percent of it and then


chunk_id: 203_chunk_17
chunk_text:
all exactly 1053.27s - 1059.51s | you have all been in classes throughout your life where things are boring people are rambling on 1059.51s - 1067.35s | about the stack gets subtracted from when a function starts and you get a lot of information 1067.35s - 1072.79s | and not a lot of it sticks right you might have like one or two practice problems but 1073.91s - 1079.27s | the modern state unfortunately of cyber security education is actually pretty poor 1079.67s - 1085.59s | and this is uh really interesting because it's understandable academically there's this thing 1085.59s - 1090.95s | called the learning pyramid full of really awesome made-up numbers where you know you can say hey if 1090.95s - 1096.47s | I go and I lecture to you you will learn like five percent of the material or retain five percent of 1096.47s - 1101.99s | the material but if I you know have you read about it uh yourself you'll you'll learn more 1102.95s - 1109.67s | and if I uh have you practice actually practice the stuff you will learn a majority you'll learn 1109.67s - 1115.75s | 75 percent of it and then of course this whole thing the bottom you got to teach someone to 1115.75s - 1121.91s | learn it all but this is called the learning pyramid it's like all um a lot of actual 1122.47s - 1130.47s | education research that has come into gone into building this and it really um showcases kind of 1130.47s - 1138.71s | what's wrong with a lot of modern cyber security education and what you end up with most modern 1138.71s - 1145.51s | coursework is you get an enormous amount of information you pump up your brain you get the 1145.51s - 1153.43s | theoretical info but you can't really apply it in practice and it's like if in karate kid 1153.43s - 1159.91s | mr miyagi made uh explained to the karate kid how to wash a car and they never actually did 1159.91s - 1164.39s | the wax on wax off and then he throws him into the ring and the kid gets beat up and we don't 1164.39s - 1174.07s | have our awesome uh ending all right so can't quite do existing coursework all right well that's 1174.07s - 1180.31s | not a problem because there's a


chunk_id: 203_chunk_18
chunk_text:
of course this whole thing the bottom you got to teach someone to 1115.75s - 1121.91s | learn it all but this is called the learning pyramid it's like all um a lot of actual 1122.47s - 1130.47s | education research that has come into gone into building this and it really um showcases kind of 1130.47s - 1138.71s | what's wrong with a lot of modern cyber security education and what you end up with most modern 1138.71s - 1145.51s | coursework is you get an enormous amount of information you pump up your brain you get the 1145.51s - 1153.43s | theoretical info but you can't really apply it in practice and it's like if in karate kid 1153.43s - 1159.91s | mr miyagi made uh explained to the karate kid how to wash a car and they never actually did 1159.91s - 1164.39s | the wax on wax off and then he throws him into the ring and the kid gets beat up and we don't 1164.39s - 1174.07s | have our awesome uh ending all right so can't quite do existing coursework all right well that's 1174.07s - 1180.31s | not a problem because there's a whole conference where every year for an entire weekend people 1180.31s - 1188.79s | descend into las vegas and learn and and and and celebrate hacking and party which conference is 1188.79s - 1196.07s | that yawn i forget the name escapes me at the moment jeff do you know sorry i'm unplugged 1198.23s - 1205.75s | everyone has uh yeah i've heard rumors yeah exactly i i think it might be um penny arcade expo 1205.75s - 1215.57s | no of course we're talking about you all about defcon but i went to a defcons it's very easy 1215.57s - 1219.89s | to go to a defcon and wander around aimlessly who here has aimlessly wandered through defcon 1220.85s - 1227.01s | yeah yeah me too and and and it's an incredible experience you have to of course aimlessly 1227.01s - 1234.29s | wander through defcon for some amount of time but we also want to have a much more streamlined 1234.29s - 1242.05s | optimized and guided path to learning available to the people that want it all right so then 1242.05s - 1249.33s | when i started the professor i said okay i understand all this stuff


chunk_id: 203_chunk_19
chunk_text:
whole conference where every year for an entire weekend people 1180.31s - 1188.79s | descend into las vegas and learn and and and and celebrate hacking and party which conference is 1188.79s - 1196.07s | that yawn i forget the name escapes me at the moment jeff do you know sorry i'm unplugged 1198.23s - 1205.75s | everyone has uh yeah i've heard rumors yeah exactly i i think it might be um penny arcade expo 1205.75s - 1215.57s | no of course we're talking about you all about defcon but i went to a defcons it's very easy 1215.57s - 1219.89s | to go to a defcon and wander around aimlessly who here has aimlessly wandered through defcon 1220.85s - 1227.01s | yeah yeah me too and and and it's an incredible experience you have to of course aimlessly 1227.01s - 1234.29s | wander through defcon for some amount of time but we also want to have a much more streamlined 1234.29s - 1242.05s | optimized and guided path to learning available to the people that want it all right so then 1242.05s - 1249.33s | when i started the professor i said okay i understand all this stuff now i see that ctf 1249.33s - 1254.29s | is a problem because i keep sending my students to ctf and they keep you know just disappearing 1258.40s - 1269.12s | yeah but there are these things called war games war games are these incredible collections of 1269.12s - 1276.64s | challenges online i maintain a list at wargame.nexus if you're interested hundreds thousands 1276.64s - 1282.24s | of hacking challenges available to anyone that wants them you can go and and and and start right 1282.24s - 1291.84s | the problem is it's very similar to what plagues ctf from an educational perspective right perry 1291.84s - 1298.32s | you've done war games i have and actually i think rpi sacks modern binary exploitation one of the 1298.32s - 1304.16s | first uh online courses uh in this uh in this stuff is on that list and that was how i learned 1304.80s - 1310.40s | it is and modern binary exploitation is an excellent example of a war game created 1310.40s - 1316.80s | educationally because it has educational materials and it has challenges to reinforce this but the 1316.80s - 1324.08s | majority of war games out


chunk_id: 203_chunk_20
chunk_text:
now i see that ctf 1249.33s - 1254.29s | is a problem because i keep sending my students to ctf and they keep you know just disappearing 1258.40s - 1269.12s | yeah but there are these things called war games war games are these incredible collections of 1269.12s - 1276.64s | challenges online i maintain a list at wargame.nexus if you're interested hundreds thousands 1276.64s - 1282.24s | of hacking challenges available to anyone that wants them you can go and and and and start right 1282.24s - 1291.84s | the problem is it's very similar to what plagues ctf from an educational perspective right perry 1291.84s - 1298.32s | you've done war games i have and actually i think rpi sacks modern binary exploitation one of the 1298.32s - 1304.16s | first uh online courses uh in this uh in this stuff is on that list and that was how i learned 1304.80s - 1310.40s | it is and modern binary exploitation is an excellent example of a war game created 1310.40s - 1316.80s | educationally because it has educational materials and it has challenges to reinforce this but the 1316.80s - 1324.08s | majority of war games out on the internet are also made to show off the challenge writing skill of 1324.08s - 1332.64s | the author which is awesome and test and and and challenge the people solving which it makes it 1332.64s - 1337.92s | very difficult to actually learn with i'll say that i could not have done the course material i 1337.92s - 1342.80s | did i could not have done the war games i did without having friends who could help me when i 1342.80s - 1348.24s | got when i got stuck that was that was the defining factor and so what what i found when i would push 1348.24s - 1354.00s | this war game idea is that it worked as long as i was there to mentor the students about once a week 1354.48s - 1362.32s | the moment i disappeared the war game attempt broke down as a learning uh route at scale 1363.04s - 1369.84s | right and you know you can't really blame people for this there you can only sit so long at a 1369.84s - 1374.72s | computer confused and and lost look at this picture this guy's even thinking of going to 1374.72s


chunk_id: 203_chunk_21
chunk_text:
on the internet are also made to show off the challenge writing skill of 1324.08s - 1332.64s | the author which is awesome and test and and and challenge the people solving which it makes it 1332.64s - 1337.92s | very difficult to actually learn with i'll say that i could not have done the course material i 1337.92s - 1342.80s | did i could not have done the war games i did without having friends who could help me when i 1342.80s - 1348.24s | got when i got stuck that was that was the defining factor and so what what i found when i would push 1348.24s - 1354.00s | this war game idea is that it worked as long as i was there to mentor the students about once a week 1354.48s - 1362.32s | the moment i disappeared the war game attempt broke down as a learning uh route at scale 1363.04s - 1369.84s | right and you know you can't really blame people for this there you can only sit so long at a 1369.84s - 1374.72s | computer confused and and lost look at this picture this guy's even thinking of going to 1374.72s - 1379.60s | the beach down there on the top left for some reason um before it gets too old but 1379.92s - 1384.64s | but as barry said there are good educational style 1386.24s - 1391.76s | materials out there and we kind of ran with this and this is something we're bringing into 1391.76s - 1401.12s | Defcon Academy we created Pwn College. Yon, what is Pwn College? Well Barry, I'm glad you asked. 1402.08s - 1410.80s | Pwn College is a revolution in online security education but it's only one it's a paradigm shift 1410.80s - 1416.16s | it's a paradigm shift Jeff understands the uh DoD language that i'm trying to bring to the talk 1416.16s - 1422.00s | today exactly but the talk isn't necessarily about Pwn College we're using Pwn College 1422.00s - 1430.32s | as an example here as one part of Defcon Academy uh Pwn College is an online teaching tool first 1431.44s - 1438.64s | and challenge tool second and I'll show you what I mean the way that we teach in Pwn College is we 1438.64s - 1446.80s | take a topic over here we have this this this guided


chunk_id: 203_chunk_22
chunk_text:
- 1379.60s | the beach down there on the top left for some reason um before it gets too old but 1379.92s - 1384.64s | but as barry said there are good educational style 1386.24s - 1391.76s | materials out there and we kind of ran with this and this is something we're bringing into 1391.76s - 1401.12s | Defcon Academy we created Pwn College. Yon, what is Pwn College? Well Barry, I'm glad you asked. 1402.08s - 1410.80s | Pwn College is a revolution in online security education but it's only one it's a paradigm shift 1410.80s - 1416.16s | it's a paradigm shift Jeff understands the uh DoD language that i'm trying to bring to the talk 1416.16s - 1422.00s | today exactly but the talk isn't necessarily about Pwn College we're using Pwn College 1422.00s - 1430.32s | as an example here as one part of Defcon Academy uh Pwn College is an online teaching tool first 1431.44s - 1438.64s | and challenge tool second and I'll show you what I mean the way that we teach in Pwn College is we 1438.64s - 1446.80s | take a topic over here we have this this this guided path carefully curated through for real 1446.80s - 1452.56s | we're 10 minutes late 10 minutes left I'm just starting to to talk 10 minutes until 1453.28s - 1459.52s | till belting okay okay and I'd encourage you to visit uh Pwn.college uh right now Yon claims that 1459.52s - 1468.72s | you can even do it on your phone yeah you can so quick thing Pwn.college guided materials it has 1470.24s - 1478.80s | lectures that introduce the core of a topic that five percent and then to explore the edge cases 1478.80s - 1484.40s | that you will be confused about if you only retain that five percent we have challenge problems 1485.36s - 1491.92s | hundreds of challenge problems that will pull your knowledge wider and wider and wider and 1491.92s - 1497.92s | let you understand the concept it's as if we took Mr. Miyagi and we put him in your web browser 1499.88s - 1504.60s | Pwn.college starts at the very beginning which some of you are doing right now the Linux Luminarium 1504.60s - 1511.08s | goes through incredibly advanced material where by the time you finish Pwn.college you will have 1511.16s - 1520.68s


chunk_id: 203_chunk_23
chunk_text:
path carefully curated through for real 1446.80s - 1452.56s | we're 10 minutes late 10 minutes left I'm just starting to to talk 10 minutes until 1453.28s - 1459.52s | till belting okay okay and I'd encourage you to visit uh Pwn.college uh right now Yon claims that 1459.52s - 1468.72s | you can even do it on your phone yeah you can so quick thing Pwn.college guided materials it has 1470.24s - 1478.80s | lectures that introduce the core of a topic that five percent and then to explore the edge cases 1478.80s - 1484.40s | that you will be confused about if you only retain that five percent we have challenge problems 1485.36s - 1491.92s | hundreds of challenge problems that will pull your knowledge wider and wider and wider and 1491.92s - 1497.92s | let you understand the concept it's as if we took Mr. Miyagi and we put him in your web browser 1499.88s - 1504.60s | Pwn.college starts at the very beginning which some of you are doing right now the Linux Luminarium 1504.60s - 1511.08s | goes through incredibly advanced material where by the time you finish Pwn.college you will have 1511.16s - 1520.68s | exploited uh JIT vulnerabilities in Chrome's v8 etc etc yeah and I want to interject and say that 1520.68s - 1525.88s | this is all in your web browser like you just said and that is a fundamentally important concept 1525.88s - 1532.76s | here uh when I uh showed that uh objjump earlier I was on my iPad and I needed a Linux terminal 1532.76s - 1537.32s | and I just pulled up Pwn.college and I booted into it but when you say there's v8 challenges 1537.32s - 1543.08s | when you say there's Linux kernel challenges that is the truly impactful thing students don't have 1543.08s - 1546.76s | to stand up their Linux kernel they can go to the browser students don't have to stand up a Linux 1546.76s - 1552.60s | environment they can go to the browser and it's an Ubuntu uh instance with Ghidra and Idafree 1552.60s - 1560.28s | and all of the resources they might need that is very powerful. And in fact we can well let's see 1560.28s - 1566.92s | if we have time to demo it we were going to demo it on stage but that's fine um


chunk_id: 203_chunk_24
chunk_text:
| exploited uh JIT vulnerabilities in Chrome's v8 etc etc yeah and I want to interject and say that 1520.68s - 1525.88s | this is all in your web browser like you just said and that is a fundamentally important concept 1525.88s - 1532.76s | here uh when I uh showed that uh objjump earlier I was on my iPad and I needed a Linux terminal 1532.76s - 1537.32s | and I just pulled up Pwn.college and I booted into it but when you say there's v8 challenges 1537.32s - 1543.08s | when you say there's Linux kernel challenges that is the truly impactful thing students don't have 1543.08s - 1546.76s | to stand up their Linux kernel they can go to the browser students don't have to stand up a Linux 1546.76s - 1552.60s | environment they can go to the browser and it's an Ubuntu uh instance with Ghidra and Idafree 1552.60s - 1560.28s | and all of the resources they might need that is very powerful. And in fact we can well let's see 1560.28s - 1566.92s | if we have time to demo it we were going to demo it on stage but that's fine um there is an 1566.92s - 1572.44s | enormous amount of material already we're building out more to pull DEF CON hackers 1573.24s - 1580.92s | kicking and screaming through into having uh practical demonstrable skills that they can 1580.92s - 1592.20s | then build up on we have uh let's uh actually talk about one thing here we have a set of material 1592.20s - 1598.60s | where at every stage of your cyber security journey you get a reward you've gamified learning 1598.60s - 1604.60s | and we've done it with belts over here in about 10 minutes we'll have a belting ceremony 1605.96s - 1609.64s | where people that have gone through the material before will earn their belts 1611.08s - 1617.64s | and walk out of here belted. Who uh. The first uh the first of a yearly ceremony something we'll 1617.64s - 1624.12s | talk about very soon. Who uh who here is gonna get belted? Awesome you guys start lining up 1625.00s - 1633.16s | and we'll give you all a hand in a second all right so uh and and and this is a uh 1633.16s - 1638.60s | tradition now in Pwn College


chunk_id: 203_chunk_25
chunk_text:
there is an 1566.92s - 1572.44s | enormous amount of material already we're building out more to pull DEF CON hackers 1573.24s - 1580.92s | kicking and screaming through into having uh practical demonstrable skills that they can 1580.92s - 1592.20s | then build up on we have uh let's uh actually talk about one thing here we have a set of material 1592.20s - 1598.60s | where at every stage of your cyber security journey you get a reward you've gamified learning 1598.60s - 1604.60s | and we've done it with belts over here in about 10 minutes we'll have a belting ceremony 1605.96s - 1609.64s | where people that have gone through the material before will earn their belts 1611.08s - 1617.64s | and walk out of here belted. Who uh. The first uh the first of a yearly ceremony something we'll 1617.64s - 1624.12s | talk about very soon. Who uh who here is gonna get belted? Awesome you guys start lining up 1625.00s - 1633.16s | and we'll give you all a hand in a second all right so uh and and and this is a uh 1633.16s - 1638.60s | tradition now in Pwn College that goes back a long way this is uh me with with Connor and his PhD 1638.60s - 1644.12s | defense um and he's uh. Sign up on the uh on this side of the stage. A bunch of belts here we send 1644.12s - 1652.92s | them out all over the world and we drive you into these crazy experiences with Pwn College where 1652.92s - 1657.96s | like we said earlier you're exploiting v8 you're exploiting the Linux kernel you understand all of 1657.96s - 1664.92s | this ideally understand it well on a practical perspective when where you can demonstrably 1664.92s - 1670.52s | carry out these exploits even though you might have come to Pwn College without knowing what 1670.52s - 1678.44s | Linux is right. As Perry says this is all doable on the internet turnkey you just go to Pwn.college 1678.44s - 1685.08s | and you start up. All right so that's Pwn College that's not Defcon Academy. What is Defcon Academy? 1686.04s - 1693.24s | Defcon Academy will use Pwn College and other resources like Pwn College another amazing one 1693.24s - 1699.88s | is CryptoHack. Who here has heard of CryptoHack? Awesome


chunk_id: 203_chunk_26
chunk_text:
that goes back a long way this is uh me with with Connor and his PhD 1638.60s - 1644.12s | defense um and he's uh. Sign up on the uh on this side of the stage. A bunch of belts here we send 1644.12s - 1652.92s | them out all over the world and we drive you into these crazy experiences with Pwn College where 1652.92s - 1657.96s | like we said earlier you're exploiting v8 you're exploiting the Linux kernel you understand all of 1657.96s - 1664.92s | this ideally understand it well on a practical perspective when where you can demonstrably 1664.92s - 1670.52s | carry out these exploits even though you might have come to Pwn College without knowing what 1670.52s - 1678.44s | Linux is right. As Perry says this is all doable on the internet turnkey you just go to Pwn.college 1678.44s - 1685.08s | and you start up. All right so that's Pwn College that's not Defcon Academy. What is Defcon Academy? 1686.04s - 1693.24s | Defcon Academy will use Pwn College and other resources like Pwn College another amazing one 1693.24s - 1699.88s | is CryptoHack. Who here has heard of CryptoHack? Awesome if you like Pwn College also check out 1699.88s - 1706.28s | CryptoHack it is in a lot of ways extremely similar in philosophy but for cryptography 1706.28s - 1718.04s | right. During the Defcon party event during this weekend we're going to have a dedicated space 1718.04s - 1725.88s | where you can go and you can start Pwn College you can continue Pwn College you can earn belts 1726.60s - 1736.76s | for your uh progress in Pwn College where we'll have dedicated tutors like Perry Adams 1737.48s - 1746.53s | who will sit down and remember when she was doing her first buffer overflow. And Connor Nelson 1747.17s - 1749.57s | and Adam Dupay. I don't know if you want me as your tutor. 1750.13s - 1759.09s | Um we'll have skill demonstrations we'll have uh exploitation races between people that have 1759.09s - 1764.85s | just learned the material we'll have a lot of hype it's going to be really really awesome right and 1764.85s - 1769.65s | it's going to be a place at Defcon specifically created specifically dedicated toward learning 1771.25s - 1778.05s | specifically dedicated toward taking people that don't have the skills


chunk_id: 203_chunk_27
chunk_text:
if you like Pwn College also check out 1699.88s - 1706.28s | CryptoHack it is in a lot of ways extremely similar in philosophy but for cryptography 1706.28s - 1718.04s | right. During the Defcon party event during this weekend we're going to have a dedicated space 1718.04s - 1725.88s | where you can go and you can start Pwn College you can continue Pwn College you can earn belts 1726.60s - 1736.76s | for your uh progress in Pwn College where we'll have dedicated tutors like Perry Adams 1737.48s - 1746.53s | who will sit down and remember when she was doing her first buffer overflow. And Connor Nelson 1747.17s - 1749.57s | and Adam Dupay. I don't know if you want me as your tutor. 1750.13s - 1759.09s | Um we'll have skill demonstrations we'll have uh exploitation races between people that have 1759.09s - 1764.85s | just learned the material we'll have a lot of hype it's going to be really really awesome right and 1764.85s - 1769.65s | it's going to be a place at Defcon specifically created specifically dedicated toward learning 1771.25s - 1778.05s | specifically dedicated toward taking people that don't have the skills but want them and turning 1778.05s - 1783.81s | them into people who do have the skills and are ready to apply them and we'll have something going 1783.81s - 1791.41s | year round year round we will have regular help sessions live on twitch or discord where we will 1791.97s - 1798.93s | help people learn four minutes and these these guys so all right we've covered the first third 1798.93s - 1805.89s | of the talk so far yeah don't worry it's our fault that's how we we start in but as I mentioned after 1805.89s - 1811.65s | people build the skills there's still a bit of a gap in applying them in practice whether it's a 1811.65s - 1822.05s | chaotic environment of a CTF or a um or a you know the real world of of cyber security and so for the 1822.05s - 1829.01s | chaotic environment of the CTF we have a solution with Defcon Academy sorry with Defcon Academy 1829.01s - 1835.73s | we are working with some of the top CTF teams in the world the people that you see most years 1836.69s - 1844.45s | up there on the the


chunk_id: 203_chunk_28
chunk_text:
but want them and turning 1778.05s - 1783.81s | them into people who do have the skills and are ready to apply them and we'll have something going 1783.81s - 1791.41s | year round year round we will have regular help sessions live on twitch or discord where we will 1791.97s - 1798.93s | help people learn four minutes and these these guys so all right we've covered the first third 1798.93s - 1805.89s | of the talk so far yeah don't worry it's our fault that's how we we start in but as I mentioned after 1805.89s - 1811.65s | people build the skills there's still a bit of a gap in applying them in practice whether it's a 1811.65s - 1822.05s | chaotic environment of a CTF or a um or a you know the real world of of cyber security and so for the 1822.05s - 1829.01s | chaotic environment of the CTF we have a solution with Defcon Academy sorry with Defcon Academy 1829.01s - 1835.73s | we are working with some of the top CTF teams in the world the people that you see most years 1836.69s - 1844.45s | up there on the the Defcon CTF contest area hacking away their entire Defcon with crazy 1844.45s - 1852.21s | difficult cutting edge challenges and we're working with them to create a CTF Academy 1852.21s - 1858.77s | where as you graduate from those first eight years track which hopefully will be compressed a 1858.77s - 1866.29s | lot as you graduate from Pwn College and similar platforms you will be apprenticed in CTF teams 1866.29s - 1871.01s | with top hackers such as Clasm over there who lead you through 1873.09s - 1879.65s | who will lead you through learning to actually dive into real security all right how will we 1879.65s - 1885.41s | help Defcon itself with Defcon Academy not just the attendees but the the community well 1886.05s - 1893.41s | we'll skip to one specific thing a couple days ago or yesterday I guess uh um 1895.41s - 1905.81s | Jake Braun announced uh Defcon Franklin. Defcon Franklin is an initiative to help change the world 1905.81s - 1913.65s | by facilitating the volunteering of Defcon resident expertise in places in the public world 1913.65s - 1918.77s | where they're needed well they need the expertise and Defcon Academy will


chunk_id: 203_chunk_29
chunk_text:
Defcon CTF contest area hacking away their entire Defcon with crazy 1844.45s - 1852.21s | difficult cutting edge challenges and we're working with them to create a CTF Academy 1852.21s - 1858.77s | where as you graduate from those first eight years track which hopefully will be compressed a 1858.77s - 1866.29s | lot as you graduate from Pwn College and similar platforms you will be apprenticed in CTF teams 1866.29s - 1871.01s | with top hackers such as Clasm over there who lead you through 1873.09s - 1879.65s | who will lead you through learning to actually dive into real security all right how will we 1879.65s - 1885.41s | help Defcon itself with Defcon Academy not just the attendees but the the community well 1886.05s - 1893.41s | we'll skip to one specific thing a couple days ago or yesterday I guess uh um 1895.41s - 1905.81s | Jake Braun announced uh Defcon Franklin. Defcon Franklin is an initiative to help change the world 1905.81s - 1913.65s | by facilitating the volunteering of Defcon resident expertise in places in the public world 1913.65s - 1918.77s | where they're needed well they need the expertise and Defcon Academy will be creating a lot of 1918.77s - 1927.17s | expertise we'll work to create a channel from Defcon Academy to Defcon Franklin to make this 1927.17s - 1933.73s | a reality and give you who goes through Defcon Academy the output to show off those skills 1934.69s - 1944.61s | all right um let's talk about who is part of Defcon Academy who is Defcon Academy 1944.61s - 1950.61s | could you say that for a second first the Chancellor we have the Chancellor of Defcon 1950.61s - 1959.25s | Academy the one and only the Dark Tangent then I forgot which order I have this in the Vice Chancellor 1960.21s - 1967.41s | the Paribas the Provost of Defcon Academy yours truly 1968.21s - 1976.45s | this is Artis we have the Dean of Binary Exploitation Adam Dupay elbow elbow wrist wrist 1977.73s - 1985.97s | Adam Dupay is a uh uh master hacker who has hosted Defcon CTF right by my side you've seen 1986.85s - 1994.13s | him with me uh at the closing ceremonies very very very lucky to have him supporting our binary 1994.13s - 2001.33s | exploitation route the Dean of Reverse Engineering Fish


chunk_id: 203_chunk_30
chunk_text:
be creating a lot of 1918.77s - 1927.17s | expertise we'll work to create a channel from Defcon Academy to Defcon Franklin to make this 1927.17s - 1933.73s | a reality and give you who goes through Defcon Academy the output to show off those skills 1934.69s - 1944.61s | all right um let's talk about who is part of Defcon Academy who is Defcon Academy 1944.61s - 1950.61s | could you say that for a second first the Chancellor we have the Chancellor of Defcon 1950.61s - 1959.25s | Academy the one and only the Dark Tangent then I forgot which order I have this in the Vice Chancellor 1960.21s - 1967.41s | the Paribas the Provost of Defcon Academy yours truly 1968.21s - 1976.45s | this is Artis we have the Dean of Binary Exploitation Adam Dupay elbow elbow wrist wrist 1977.73s - 1985.97s | Adam Dupay is a uh uh master hacker who has hosted Defcon CTF right by my side you've seen 1986.85s - 1994.13s | him with me uh at the closing ceremonies very very very lucky to have him supporting our binary 1994.13s - 2001.33s | exploitation route the Dean of Reverse Engineering Fish if you know CTF you know this legend uh 2001.33s - 2008.61s | probably one of the top reverse engineers in the world now teaching you how to be like him 2008.61s - 2014.05s | which is a terrifying thought he can read straight assembly code like it's uh like 2014.05s - 2020.53s | it's source code it's scary all right we got the Dean of Student Advocacy Rob Waas where are you 2020.53s - 2027.33s | Rob Waas Rob Waas is advocating for uh students to get belts off stage over here and the Dean 2027.33s - 2036.29s | of Educational Technologies Connor Nelson he is the reason that Pond College is usable over a browser 2036.29s - 2042.21s | or usable at all really I wasn't joking when I said he's the one doing the infrastructure 2042.21s - 2047.49s | all right that being said this is just what we're starting with the goal right now is to get a 2047.49s - 2053.81s | minimum viable product of Defcon Academy because we're launching in full next year next year we'll 2053.81s - 2062.93s | have in-person uh amazing uh area where you'll be able to learn etc etc


chunk_id: 203_chunk_31
chunk_text:
if you know CTF you know this legend uh 2001.33s - 2008.61s | probably one of the top reverse engineers in the world now teaching you how to be like him 2008.61s - 2014.05s | which is a terrifying thought he can read straight assembly code like it's uh like 2014.05s - 2020.53s | it's source code it's scary all right we got the Dean of Student Advocacy Rob Waas where are you 2020.53s - 2027.33s | Rob Waas Rob Waas is advocating for uh students to get belts off stage over here and the Dean 2027.33s - 2036.29s | of Educational Technologies Connor Nelson he is the reason that Pond College is usable over a browser 2036.29s - 2042.21s | or usable at all really I wasn't joking when I said he's the one doing the infrastructure 2042.21s - 2047.49s | all right that being said this is just what we're starting with the goal right now is to get a 2047.49s - 2053.81s | minimum viable product of Defcon Academy because we're launching in full next year next year we'll 2053.81s - 2062.93s | have in-person uh amazing uh area where you'll be able to learn etc etc etc and we'll have 2062.93s - 2067.49s | kind of a proof of concept of all of it we'll have a proof of concept at least one CTF team 2068.45s - 2073.73s | already shall we just sign up maybe at least two CTF teams that are ready to take and apprentice 2073.73s - 2081.17s | awesome people we'll have multiple uh platforms like Pond College ready to go and we'll have 2081.81s - 2089.41s | a couple of ways that you can go and help Defcon but as we extend we need more deans so if you 2089.41s - 2095.89s | are interested in being a dean of Defcon Academy and are interested in spreading your knowledge 2096.53s - 2107.65s | to budding hackers talk to us all right let's do the belts okay so Pond College has a set of 2107.65s - 2114.45s | different steps and materials first students come in knowing nothing and they learn and they learn 2114.45s - 2120.85s | introductory concepts in cyber security command injection in simple websites uh 2121.81s - 2127.73s | uh file permission issues these sort of things after they learn that they earn the orange belt 2128.69s -


chunk_id: 203_chunk_32
chunk_text:
etc and we'll have 2062.93s - 2067.49s | kind of a proof of concept of all of it we'll have a proof of concept at least one CTF team 2068.45s - 2073.73s | already shall we just sign up maybe at least two CTF teams that are ready to take and apprentice 2073.73s - 2081.17s | awesome people we'll have multiple uh platforms like Pond College ready to go and we'll have 2081.81s - 2089.41s | a couple of ways that you can go and help Defcon but as we extend we need more deans so if you 2089.41s - 2095.89s | are interested in being a dean of Defcon Academy and are interested in spreading your knowledge 2096.53s - 2107.65s | to budding hackers talk to us all right let's do the belts okay so Pond College has a set of 2107.65s - 2114.45s | different steps and materials first students come in knowing nothing and they learn and they learn 2114.45s - 2120.85s | introductory concepts in cyber security command injection in simple websites uh 2121.81s - 2127.73s | uh file permission issues these sort of things after they learn that they earn the orange belt 2128.69s - 2135.97s | they move on to learn about how the security of programs fail things like buffer overflows 2138.61s - 2144.93s | things like how to reverse engineer programs to find issues etc they earned a yellow belt at that 2144.93s - 2150.93s | stage they move on to system security talking about going from user space to kernel space 2152.21s - 2161.33s | through a race condition uh uh vulnerability inside a kernel driver for example then they 2161.33s - 2169.25s | earn the green belt and finally they go through crazy esoteric and advanced concepts in software 2169.25s - 2177.01s | exploitation stuff like micro architectural uh side channel attacks and other just absolutely 2177.01s - 2182.85s | wild things and they earn their blue belt so we'll be belting uh do we have blue belts today 2184.37s - 2191.33s | wow three blue belts today all right awesome so we'll be belting all sorts of people right now 2191.33s - 2197.73s | we'll go through them and dark tangent and the rest of the Defcon Academy team will confer 2198.21s - 2206.53s | their new hacker ranks let's start with the orange okay awesome all right come


chunk_id: 203_chunk_33
chunk_text:
2135.97s | they move on to learn about how the security of programs fail things like buffer overflows 2138.61s - 2144.93s | things like how to reverse engineer programs to find issues etc they earned a yellow belt at that 2144.93s - 2150.93s | stage they move on to system security talking about going from user space to kernel space 2152.21s - 2161.33s | through a race condition uh uh vulnerability inside a kernel driver for example then they 2161.33s - 2169.25s | earn the green belt and finally they go through crazy esoteric and advanced concepts in software 2169.25s - 2177.01s | exploitation stuff like micro architectural uh side channel attacks and other just absolutely 2177.01s - 2182.85s | wild things and they earn their blue belt so we'll be belting uh do we have blue belts today 2184.37s - 2191.33s | wow three blue belts today all right awesome so we'll be belting all sorts of people right now 2191.33s - 2197.73s | we'll go through them and dark tangent and the rest of the Defcon Academy team will confer 2198.21s - 2206.53s | their new hacker ranks let's start with the orange okay awesome all right come on up 2208.85s - 2215.57s | all right you can say your handle if you want uh gordon all right well congratulations 2218.05s - 2226.45s | congrats and uh over here oh we'll get a picture all right and you are just john john just john 2226.45s - 2236.61s | okay welcome yeah no all right up next we have i'm chloe chloe welcome congrats 2241.59s - 2253.16s | jonathan jonathan welcome spicy dll spicy dll congratulations 2257.40s - 2261.96s | oh dirac delta you're getting your blue belt no i'm giving yellow your yellow belt okay well 2261.96s - 2278.02s | i recognize you anyways all right i'm such a noob sasha noobs josh l josh l josh l welcome 2287.48s - 2297.09s | wherever i'm eddie eddie welcome all right these hackers have pushed through 2297.97s - 2308.69s | increasingly insane material like material that really is is almost insane to have 2308.69s - 2314.05s | in some educational contexts uh material where at the end of it these blue belts out there 2316.69s - 2322.13s | yeah we'll do a picture we'll stand forever all right so the blue belts over here we're afraid 2322.13s - 2328.05s


chunk_id: 203_chunk_34
chunk_text:
on up 2208.85s - 2215.57s | all right you can say your handle if you want uh gordon all right well congratulations 2218.05s - 2226.45s | congrats and uh over here oh we'll get a picture all right and you are just john john just john 2226.45s - 2236.61s | okay welcome yeah no all right up next we have i'm chloe chloe welcome congrats 2241.59s - 2253.16s | jonathan jonathan welcome spicy dll spicy dll congratulations 2257.40s - 2261.96s | oh dirac delta you're getting your blue belt no i'm giving yellow your yellow belt okay well 2261.96s - 2278.02s | i recognize you anyways all right i'm such a noob sasha noobs josh l josh l josh l welcome 2287.48s - 2297.09s | wherever i'm eddie eddie welcome all right these hackers have pushed through 2297.97s - 2308.69s | increasingly insane material like material that really is is almost insane to have 2308.69s - 2314.05s | in some educational contexts uh material where at the end of it these blue belts out there 2316.69s - 2322.13s | yeah we'll do a picture we'll stand forever all right so the blue belts over here we're afraid 2322.13s - 2328.05s | of them because i am a thousand percent sure that with their knowledge they're like one step away 2328.05s - 2341.04s | from exploiting the punk college server itself all right let's honor these amazing hackers with 2341.04s - 2356.12s | their achievement awesome all right good job guys so five minute mark okay so this is an event that 2356.12s - 2362.52s | we're gonna get increasingly crazy about um in the in person now let's do the uh 2364.04s - 2368.68s | yon is very sane he would never get crazy about anything yeah let's check out one more thing 2369.56s - 2387.08s | ctf.defcon.academy we'll see the scoreboard oh oh it's not that's interesting yeah it's not one 2387.08s - 2395.56s | sec i have to uh for us let me load out this up i think i have to hit escape nope 2398.04s - 2406.92s | hit escape here yes perfect okay what's your password well the username is demo 2409.32s - 2416.76s | all right actually right 404 file not found you gotta join that seems bad connor you gotta join 2417.72s - 2422.12s | i don't want to join i just want to


chunk_id: 203_chunk_35
chunk_text:
| of them because i am a thousand percent sure that with their knowledge they're like one step away 2328.05s - 2341.04s | from exploiting the punk college server itself all right let's honor these amazing hackers with 2341.04s - 2356.12s | their achievement awesome all right good job guys so five minute mark okay so this is an event that 2356.12s - 2362.52s | we're gonna get increasingly crazy about um in the in person now let's do the uh 2364.04s - 2368.68s | yon is very sane he would never get crazy about anything yeah let's check out one more thing 2369.56s - 2387.08s | ctf.defcon.academy we'll see the scoreboard oh oh it's not that's interesting yeah it's not one 2387.08s - 2395.56s | sec i have to uh for us let me load out this up i think i have to hit escape nope 2398.04s - 2406.92s | hit escape here yes perfect okay what's your password well the username is demo 2409.32s - 2416.76s | all right actually right 404 file not found you gotta join that seems bad connor you gotta join 2417.72s - 2422.12s | i don't want to join i just want to look at a scoreboard well you gotta join it's private okay 2424.90s - 2433.14s | nice come on all right 20 people hacking now in the audience 24 people have solved things there's 2433.14s - 2443.30s | 603 total solves let's look at the rankings is our server melting absolutely not it's definitely 2443.38s - 2449.22s | the defcon wi-fi it's not a live demo all right while while uh that's loading we'll just pull 2449.22s - 2455.94s | this up on my phone have you tried refreshing it's spinning it's got i tried turning it on 2455.94s - 2464.42s | and off again ctf oh this is this is probably it's loading it says loading there we go 2465.62s - 2472.02s | okay awesome we have someone that solved the whole thing who is chi chesum right there 2472.98s - 2477.94s | all right oh nice well you can come back up and get uh a challenge coin 2478.66s - 2481.78s | do you have one who's oh where's knob knob goose knob knob goose is here 2482.34s - 2489.06s | another name i recognize knob knob goose isn't here is are they just hacked in all right 2489.06s


chunk_id: 203_chunk_36
chunk_text:
look at a scoreboard well you gotta join it's private okay 2424.90s - 2433.14s | nice come on all right 20 people hacking now in the audience 24 people have solved things there's 2433.14s - 2443.30s | 603 total solves let's look at the rankings is our server melting absolutely not it's definitely 2443.38s - 2449.22s | the defcon wi-fi it's not a live demo all right while while uh that's loading we'll just pull 2449.22s - 2455.94s | this up on my phone have you tried refreshing it's spinning it's got i tried turning it on 2455.94s - 2464.42s | and off again ctf oh this is this is probably it's loading it says loading there we go 2465.62s - 2472.02s | okay awesome we have someone that solved the whole thing who is chi chesum right there 2472.98s - 2477.94s | all right oh nice well you can come back up and get uh a challenge coin 2478.66s - 2481.78s | do you have one who's oh where's knob knob goose knob knob goose is here 2482.34s - 2489.06s | another name i recognize knob knob goose isn't here is are they just hacked in all right 2489.06s - 2493.86s | knob knob goose you can come get a challenge called santa montes shunt derek delta if you 2493.86s - 2499.86s | have solves on defcon academy run up get a challenge coin in the meantime 2500.66s - 2506.74s | thank you for uh coming to this soft launch preview of defcon academy um 2508.02s - 2517.30s | that started from the beginning we'll just fast forward here two minutes that's two more minutes 2517.30s - 2526.90s | than we need my friend all right awesome so defcon academy wouldn't exist if it wasn't for 2527.78s - 2534.34s | the awesome efforts of you all who dive into this educational stuff and make it worth it 2534.34s - 2539.86s | and it wouldn't exist if it wasn't for the awesome efforts of the dark tangent 2539.86s - 2546.58s | who supports these awesome sort of things and perry thank you because you your vision 2546.58s - 2555.94s | made this actually possible you're welcome all right and all of these guys awesome thank you 2556.26s - 2558.82s | and connor nelson and connor nelson 2561.38s - 2564.66s | thank you hey you finished early


chunk_id: 203_chunk_37
chunk_text:
- 2493.86s | knob knob goose you can come get a challenge called santa montes shunt derek delta if you 2493.86s - 2499.86s | have solves on defcon academy run up get a challenge coin in the meantime 2500.66s - 2506.74s | thank you for uh coming to this soft launch preview of defcon academy um 2508.02s - 2517.30s | that started from the beginning we'll just fast forward here two minutes that's two more minutes 2517.30s - 2526.90s | than we need my friend all right awesome so defcon academy wouldn't exist if it wasn't for 2527.78s - 2534.34s | the awesome efforts of you all who dive into this educational stuff and make it worth it 2534.34s - 2539.86s | and it wouldn't exist if it wasn't for the awesome efforts of the dark tangent 2539.86s - 2546.58s | who supports these awesome sort of things and perry thank you because you your vision 2546.58s - 2555.94s | made this actually possible you're welcome all right and all of these guys awesome thank you 2556.26s - 2558.82s | and connor nelson and connor nelson 2561.38s - 2564.66s | thank you hey you finished early


chunk_id: 204_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=KqKj_VY-AHY", "title": "DEF CON 32 - MobileMesh RF Network Exploitation Getting the Tea from goTenna - Erwin Karincic, Woody", "description": "False sense of security in devices that guarantee security is worse than no security at all. One device used by personnel who require communication security is goTenna Pro radio that creates an \"off-the-grid\" encrypted mobile mesh network.This network does not require any traditional cellular or satellite infrastructure and they may be found locally in your community. The datasheet says it is using AES-256 encryption. Has anyone bothered to verify that it is being implemented in the most secure manner? We examined this device and found that it was possible to fingerprint and track every off-the-grid message regardless of encryption. We also identified vulnerabilities that result in interception and decryption of the most secure encryption algorithm AES-256 as well as injection of messages into the existing mesh network. We don\u2019t just trust what datasheets say, we verify it for you. We will explain our testing methodologies and demonstrate exploitation in a live demo. We will discuss the operational implications of these vulnerabilities and safe ways of using these devices that decrease the chance of a compromise. The tools developed as part of this research will be released open-source to inform what was possible to inspire future research against similar devices. We will discuss how we worked with goTenna to remedy these issues.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2599, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.05s - 4.05s | This text was transcribed using whisper model: large-v2 Welcome to DEF CON. First speaker's up. Let's give him a big hand. 4.05s - 16.14s | Thank all of you for being here. Really appreciate it. 16.14s - 20.14s | So, the first thing we want to talk about is, 20.14s - 24.14s | this whole talk has really been pushed because of how much 24.14s - 27.14s | the technology out there is moving to mesh technology. 27.14s - 31.14s | Everything's mesh. From cellular, we have mesh-tastic, 31.14s - 34.14s | LoRa, all these different creations. 34.14s - 37.14s | But one of the creations that has been around for quite a while 37.14s - 40.14s | that we're going to talk about is Gotenna. 40.14s - 44.14s | And we're going to talk about all three stages that we've seen it go through. 44.14s - 47.14s | My name's Woody.


chunk_id: 204_chunk_1
chunk_text:
as part of this research will be released open-source to inform what was possible to inspire future research against similar devices. We will discuss how we worked with goTenna to remedy these issues.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2599, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.05s - 4.05s | This text was transcribed using whisper model: large-v2 Welcome to DEF CON. First speaker's up. Let's give him a big hand. 4.05s - 16.14s | Thank all of you for being here. Really appreciate it. 16.14s - 20.14s | So, the first thing we want to talk about is, 20.14s - 24.14s | this whole talk has really been pushed because of how much 24.14s - 27.14s | the technology out there is moving to mesh technology. 27.14s - 31.14s | Everything's mesh. From cellular, we have mesh-tastic, 31.14s - 34.14s | LoRa, all these different creations. 34.14s - 37.14s | But one of the creations that has been around for quite a while 37.14s - 40.14s | that we're going to talk about is Gotenna. 40.14s - 44.14s | And we're going to talk about all three stages that we've seen it go through. 44.14s - 47.14s | My name's Woody. This is Erwin. 47.14s - 50.14s | Yeah, I'm Erwin Korenczyk. I go by Dollar Hyde. 50.14s - 53.14s | And we also want to make sure that we give credit to Clayton Smith, 53.14s - 57.14s | who really did a ton of work on the second generation 57.14s - 61.14s | and made this talk possible. So, thank you very much for that. 61.14s - 68.26s | Awesome. Yeah, thank you, Clayton. 68.26s - 71.26s | Multiple mesh networks, the way that they typically work is, 71.26s - 74.26s | one device will talk to another. You're able to go through and pivot. 74.26s - 77.26s | And that way, you can get extended range. 77.26s - 80.26s | You can have multiple people communicate at the same time. 80.26s - 82.26s | There's a lot of things that you can do. 82.26s - 85.26s | Now, one of the things with a traditional network is the way that your data 85.26s - 89.26s | and your controls are handled versus the way that Gotenna mesh does it. 89.26s - 93.26s | So, the Gotenna's capability of meshing is actually really efficient. 93.26s - 97.26s | And that's


chunk_id: 204_chunk_2
chunk_text:
This is Erwin. 47.14s - 50.14s | Yeah, I'm Erwin Korenczyk. I go by Dollar Hyde. 50.14s - 53.14s | And we also want to make sure that we give credit to Clayton Smith, 53.14s - 57.14s | who really did a ton of work on the second generation 57.14s - 61.14s | and made this talk possible. So, thank you very much for that. 61.14s - 68.26s | Awesome. Yeah, thank you, Clayton. 68.26s - 71.26s | Multiple mesh networks, the way that they typically work is, 71.26s - 74.26s | one device will talk to another. You're able to go through and pivot. 74.26s - 77.26s | And that way, you can get extended range. 77.26s - 80.26s | You can have multiple people communicate at the same time. 80.26s - 82.26s | There's a lot of things that you can do. 82.26s - 85.26s | Now, one of the things with a traditional network is the way that your data 85.26s - 89.26s | and your controls are handled versus the way that Gotenna mesh does it. 89.26s - 93.26s | So, the Gotenna's capability of meshing is actually really efficient. 93.26s - 97.26s | And that's one of the things that makes it fairly unique 97.26s - 101.26s | is because they've combined that and made it pretty controllable. 101.26s - 106.82s | So, some of you seven years ago may have seen the talk that I did 106.82s - 113.66s | in the RF Hacker Sanctuary. 113.66s - 118.94s | It was on Gotenna version 1, this one right here. 118.94s - 121.94s | So, what you're seeing on the screen right now is as he goes through 121.94s - 126.94s | and does the Gotenna or his script, this was our original exploit. 126.94s - 131.94s | And what we figured out was the Gotenna is designed over Bluetooth 131.94s - 134.94s | to communicate with a phone, at least the Gen 1 and 2 were. 134.94s - 139.94s | Once that happens, then you can send a message that can be either open 139.94s - 144.94s | in a broadcast or person-to-person or in a group, but you can encrypt it. 144.94s - 147.94s | And that's what you're seeing here on the screen. 147.94s - 152.94s | But we were able to see seven years ago that it was broadcasting 152.94s -


chunk_id: 204_chunk_3
chunk_text:
one of the things that makes it fairly unique 97.26s - 101.26s | is because they've combined that and made it pretty controllable. 101.26s - 106.82s | So, some of you seven years ago may have seen the talk that I did 106.82s - 113.66s | in the RF Hacker Sanctuary. 113.66s - 118.94s | It was on Gotenna version 1, this one right here. 118.94s - 121.94s | So, what you're seeing on the screen right now is as he goes through 121.94s - 126.94s | and does the Gotenna or his script, this was our original exploit. 126.94s - 131.94s | And what we figured out was the Gotenna is designed over Bluetooth 131.94s - 134.94s | to communicate with a phone, at least the Gen 1 and 2 were. 134.94s - 139.94s | Once that happens, then you can send a message that can be either open 139.94s - 144.94s | in a broadcast or person-to-person or in a group, but you can encrypt it. 144.94s - 147.94s | And that's what you're seeing here on the screen. 147.94s - 152.94s | But we were able to see seven years ago that it was broadcasting 152.94s - 154.94s | some things plain text. 154.94s - 158.94s | And when it broadcasted things plain text, the things that you could see, 158.94s - 162.94s | even in encrypted mode, were the unique identifier, 162.94s - 165.94s | which for the unique identifier for the Gen 1 and 2 by default, 165.94s - 167.94s | can anyone tell me what it was? 167.94s - 169.94s | Your cell phone number. 169.94s - 174.94s | So, this script is demonstrating how we could run against a Gotenna version 1 174.94s - 177.94s | and pull your phone number out of the air, 177.94s - 179.94s | even if you were using encrypted mode. 179.94s - 184.94s | Now, they fixed that since, well, they've evolved since then. 184.94s - 188.94s | And the new management has really made an effort to try to fix 188.94s - 190.94s | some of the issues that have happened in the past. 190.94s - 193.94s | But this on the screen is actually what it looks like 193.94s - 195.94s | when we're able to come in here and pull this data. 195.94s - 198.94s | Yeah, and you can see the phone number,


chunk_id: 204_chunk_4
chunk_text:
154.94s | some things plain text. 154.94s - 158.94s | And when it broadcasted things plain text, the things that you could see, 158.94s - 162.94s | even in encrypted mode, were the unique identifier, 162.94s - 165.94s | which for the unique identifier for the Gen 1 and 2 by default, 165.94s - 167.94s | can anyone tell me what it was? 167.94s - 169.94s | Your cell phone number. 169.94s - 174.94s | So, this script is demonstrating how we could run against a Gotenna version 1 174.94s - 177.94s | and pull your phone number out of the air, 177.94s - 179.94s | even if you were using encrypted mode. 179.94s - 184.94s | Now, they fixed that since, well, they've evolved since then. 184.94s - 188.94s | And the new management has really made an effort to try to fix 188.94s - 190.94s | some of the issues that have happened in the past. 190.94s - 193.94s | But this on the screen is actually what it looks like 193.94s - 195.94s | when we're able to come in here and pull this data. 195.94s - 198.94s | Yeah, and you can see the phone number, call sign, and the message 198.94s - 200.94s | in unencrypted mode. 200.94s - 203.94s | In encrypted mode, payload is not visible, but the phone number still is. 203.94s - 205.94s | So, this was Gen 1. 205.94s - 207.94s | And if you want to see a live demo of this, come to RFHackers. 207.94s - 209.94s | We're showing just the video here. 209.94s - 214.26s | So, Gen 1, we see how it communicates. 214.26s - 218.26s | Now, Gen 2, they changed some things. 218.26s - 221.26s | Instead of using 2FSK, they moved to 4FSK. 221.26s - 224.26s | But by default, there were still a couple things that were the same 224.26s - 227.26s | that we were able to start exploiting. 227.26s - 230.26s | Clayton specifically found some really great things 230.26s - 232.26s | that were vulnerable here. 232.26s - 234.26s | A lot of them were similar to version 1, 234.26s - 238.26s | but you needed a 4FSK demodulator to do it. 238.26s - 240.26s | But you could still find the phone number. 240.26s - 244.26s | You could still find some of those unique identifiers. 244.26s


chunk_id: 204_chunk_5
chunk_text:
call sign, and the message 198.94s - 200.94s | in unencrypted mode. 200.94s - 203.94s | In encrypted mode, payload is not visible, but the phone number still is. 203.94s - 205.94s | So, this was Gen 1. 205.94s - 207.94s | And if you want to see a live demo of this, come to RFHackers. 207.94s - 209.94s | We're showing just the video here. 209.94s - 214.26s | So, Gen 1, we see how it communicates. 214.26s - 218.26s | Now, Gen 2, they changed some things. 218.26s - 221.26s | Instead of using 2FSK, they moved to 4FSK. 221.26s - 224.26s | But by default, there were still a couple things that were the same 224.26s - 227.26s | that we were able to start exploiting. 227.26s - 230.26s | Clayton specifically found some really great things 230.26s - 232.26s | that were vulnerable here. 232.26s - 234.26s | A lot of them were similar to version 1, 234.26s - 238.26s | but you needed a 4FSK demodulator to do it. 238.26s - 240.26s | But you could still find the phone number. 240.26s - 244.26s | You could still find some of those unique identifiers. 244.26s - 246.26s | And as we're going to discuss, those unique identifiers, 246.26s - 249.26s | even if they're not your phone number, can be a bad day. 249.26s - 252.26s | So, this is an example of exactly what we could pull 252.26s - 255.26s | while you think you're doing encrypted messages. 255.26s - 257.26s | And we start getting your phone number. 257.26s - 259.26s | We can start seeing some of your messages, 259.26s - 262.26s | depending how you're using it. 262.26s - 265.26s | And we're going to talk how that can be effective 265.26s - 271.64s | for other things as well. 271.64s - 276.64s | Now, the current version of Gotenna, the Gotenna Pro, 276.64s - 278.64s | we started working with. 278.64s - 281.64s | One of the things that I do is I'm staffed in the RF Hacker Sanctuary, 281.64s - 285.64s | the RF Village, so please come and try some of our challenges out later. 285.64s - 287.64s | That's actually how a lot of these things get discovered, 287.64s - 290.64s | is people trying them in challenges. 290.64s - 292.64s | Some things that were fixed.


chunk_id: 204_chunk_6
chunk_text:
- 246.26s | And as we're going to discuss, those unique identifiers, 246.26s - 249.26s | even if they're not your phone number, can be a bad day. 249.26s - 252.26s | So, this is an example of exactly what we could pull 252.26s - 255.26s | while you think you're doing encrypted messages. 255.26s - 257.26s | And we start getting your phone number. 257.26s - 259.26s | We can start seeing some of your messages, 259.26s - 262.26s | depending how you're using it. 262.26s - 265.26s | And we're going to talk how that can be effective 265.26s - 271.64s | for other things as well. 271.64s - 276.64s | Now, the current version of Gotenna, the Gotenna Pro, 276.64s - 278.64s | we started working with. 278.64s - 281.64s | One of the things that I do is I'm staffed in the RF Hacker Sanctuary, 281.64s - 285.64s | the RF Village, so please come and try some of our challenges out later. 285.64s - 287.64s | That's actually how a lot of these things get discovered, 287.64s - 290.64s | is people trying them in challenges. 290.64s - 292.64s | Some things that were fixed. 292.64s - 294.64s | You did not have to connect via Bluetooth, 294.64s - 297.64s | because we all know that Bluetooth by itself can be a unique identifier 297.64s - 300.64s | that can be used to find somebody or come after them. 300.64s - 303.64s | They improved it so you could use either Bluetooth 303.64s - 307.64s | or you could actually hard line to your phone with the device. 307.64s - 310.64s | And then the only thing that was communicating was either at, you know, 310.64s - 316.64s | the 140 to 170 megahertz band or 445 to 480. 316.64s - 319.64s | They also improved the channels you could use. 319.64s - 321.64s | You had some bandwidth things you could control. 321.64s - 325.64s | So, on initial viewing of this, 325.64s - 328.64s | it looked like it was a much more secure device. 328.64s - 331.64s | But this is what we're going to be talking about. 331.64s - 342.01s | This is basically the Gen 3. 342.01s - 346.01s | Why is it important for us to worry about what we give out? 346.01s - 349.01s | Well, we have


chunk_id: 204_chunk_7
chunk_text:
292.64s - 294.64s | You did not have to connect via Bluetooth, 294.64s - 297.64s | because we all know that Bluetooth by itself can be a unique identifier 297.64s - 300.64s | that can be used to find somebody or come after them. 300.64s - 303.64s | They improved it so you could use either Bluetooth 303.64s - 307.64s | or you could actually hard line to your phone with the device. 307.64s - 310.64s | And then the only thing that was communicating was either at, you know, 310.64s - 316.64s | the 140 to 170 megahertz band or 445 to 480. 316.64s - 319.64s | They also improved the channels you could use. 319.64s - 321.64s | You had some bandwidth things you could control. 321.64s - 325.64s | So, on initial viewing of this, 325.64s - 328.64s | it looked like it was a much more secure device. 328.64s - 331.64s | But this is what we're going to be talking about. 331.64s - 342.01s | This is basically the Gen 3. 342.01s - 346.01s | Why is it important for us to worry about what we give out? 346.01s - 349.01s | Well, we have some representatives from Wiggle here, 349.01s - 352.01s | and I'm sure that they can tell you how important it is 352.01s - 354.01s | to protect your MAC addresses. 354.01s - 356.01s | In fact, the industry has already started making sure 356.01s - 358.01s | that unique identifiers start rolling 358.01s - 360.01s | and that it's much more difficult to track them 360.01s - 363.01s | because you can be tracked over space and time, 363.01s - 366.01s | geographical location, and it can be used to fingerprint. 366.01s - 368.01s | So that's why we're worried about this. 368.01s - 371.01s | It also gives out unique identifiers about you. 371.01s - 375.01s | What if I couldn't just tell that you were using that MacBook, 375.01s - 377.01s | but I could tell you whether Tim was using it 377.01s - 380.01s | or whether Jeff was using it, right? 380.01s - 382.01s | That's even more refined, 382.01s - 384.01s | and that's what we're going to start getting into in here. 384.01s - 386.01s | And that is why, to us, it was so important. 386.01s - 389.01s | Both of us, our


chunk_id: 204_chunk_8
chunk_text:
some representatives from Wiggle here, 349.01s - 352.01s | and I'm sure that they can tell you how important it is 352.01s - 354.01s | to protect your MAC addresses. 354.01s - 356.01s | In fact, the industry has already started making sure 356.01s - 358.01s | that unique identifiers start rolling 358.01s - 360.01s | and that it's much more difficult to track them 360.01s - 363.01s | because you can be tracked over space and time, 363.01s - 366.01s | geographical location, and it can be used to fingerprint. 366.01s - 368.01s | So that's why we're worried about this. 368.01s - 371.01s | It also gives out unique identifiers about you. 371.01s - 375.01s | What if I couldn't just tell that you were using that MacBook, 375.01s - 377.01s | but I could tell you whether Tim was using it 377.01s - 380.01s | or whether Jeff was using it, right? 380.01s - 382.01s | That's even more refined, 382.01s - 384.01s | and that's what we're going to start getting into in here. 384.01s - 386.01s | And that is why, to us, it was so important. 386.01s - 389.01s | Both of us, our primary jobs, 389.01s - 391.01s | when we're not doing this stuff for fun, 391.01s - 394.01s | is to actually help people protect their RF signature 394.01s - 397.01s | and to help people have good cybersecurity 397.01s - 400.01s | in vehicles, in equipment that they use, 400.01s - 402.01s | and global travels. 402.01s - 409.79s | So some of the problems that we started wondering about. 409.79s - 411.79s | Is there any chance that we can find 411.79s - 413.79s | some of the same vulnerabilities in a Gen 3 413.79s - 415.79s | that we find in a Gen 1? 415.79s - 417.79s | Yeah, so basically we're looking for those GIDs 417.79s - 418.79s | for the call signs. 418.79s - 420.79s | We're looking, are they present? 420.79s - 421.79s | Have they fixed it? 421.79s - 422.79s | Yeah. 422.79s - 424.79s | Because it's been seven years, 424.79s - 425.79s | we wanted to see whether or not 425.79s - 427.79s | all those things had been fixed or not. 427.79s - 430.79s | And some things had, and some things we found 430.79s - 432.79s | were still somewhat


chunk_id: 204_chunk_9
chunk_text:
primary jobs, 389.01s - 391.01s | when we're not doing this stuff for fun, 391.01s - 394.01s | is to actually help people protect their RF signature 394.01s - 397.01s | and to help people have good cybersecurity 397.01s - 400.01s | in vehicles, in equipment that they use, 400.01s - 402.01s | and global travels. 402.01s - 409.79s | So some of the problems that we started wondering about. 409.79s - 411.79s | Is there any chance that we can find 411.79s - 413.79s | some of the same vulnerabilities in a Gen 3 413.79s - 415.79s | that we find in a Gen 1? 415.79s - 417.79s | Yeah, so basically we're looking for those GIDs 417.79s - 418.79s | for the call signs. 418.79s - 420.79s | We're looking, are they present? 420.79s - 421.79s | Have they fixed it? 421.79s - 422.79s | Yeah. 422.79s - 424.79s | Because it's been seven years, 424.79s - 425.79s | we wanted to see whether or not 425.79s - 427.79s | all those things had been fixed or not. 427.79s - 430.79s | And some things had, and some things we found 430.79s - 432.79s | were still somewhat vulnerable. 432.79s - 435.79s | But having that base is what we moved from 435.79s - 437.79s | to be able to do all the rest of this. 437.79s - 439.79s | So having a good foothold, 439.79s - 442.79s | and then from there, pushing out and finding new things. 442.79s - 448.73s | So who are we? Erwin? 448.73s - 449.73s | Yeah, so I'm Erwin. 449.73s - 451.73s | I'm a security researcher. 451.73s - 453.73s | I'm experienced in hardware and software reverse engineering 453.73s - 455.73s | as well as RF exploitation. 455.73s - 458.73s | My mission is essentially what's shown on the screen 458.73s - 460.73s | as well as the overall mission 460.73s - 462.73s | to protect this nation and its citizens 462.73s - 464.73s | by identifying and mitigating threats 464.73s - 466.73s | before those threats are even known to these people. 466.73s - 469.73s | So this is one example of that mission 469.73s - 472.73s | to protect the people that serve us. 472.73s - 473.73s | My name's Woody. 473.73s - 475.73s | I'm staff for the RF Hacker Sanctuary, 475.73s - 480.73s | or the


chunk_id: 204_chunk_10
chunk_text:
vulnerable. 432.79s - 435.79s | But having that base is what we moved from 435.79s - 437.79s | to be able to do all the rest of this. 437.79s - 439.79s | So having a good foothold, 439.79s - 442.79s | and then from there, pushing out and finding new things. 442.79s - 448.73s | So who are we? Erwin? 448.73s - 449.73s | Yeah, so I'm Erwin. 449.73s - 451.73s | I'm a security researcher. 451.73s - 453.73s | I'm experienced in hardware and software reverse engineering 453.73s - 455.73s | as well as RF exploitation. 455.73s - 458.73s | My mission is essentially what's shown on the screen 458.73s - 460.73s | as well as the overall mission 460.73s - 462.73s | to protect this nation and its citizens 462.73s - 464.73s | by identifying and mitigating threats 464.73s - 466.73s | before those threats are even known to these people. 466.73s - 469.73s | So this is one example of that mission 469.73s - 472.73s | to protect the people that serve us. 472.73s - 473.73s | My name's Woody. 473.73s - 475.73s | I'm staff for the RF Hacker Sanctuary, 475.73s - 480.73s | or the RF Village. 480.73s - 481.73s | I was one of the co-authors 481.73s - 484.73s | of the original Gotenna attack, Raptor Captor, 484.73s - 487.73s | some other vehicle exploits, and some things like that. 487.73s - 489.73s | I spent 20 years in special operations 489.73s - 492.73s | before I started playing in this world. 492.73s - 495.73s | And the reason that this is so important to both of us 495.73s - 498.73s | is we work with law enforcement. 498.73s - 499.73s | We work with government. 499.73s - 502.73s | We work with corporations. 502.73s - 505.73s | And we educate them on how to control 505.73s - 507.73s | and understand all the different aspects, 507.73s - 509.73s | not just the physical, but also the digital 509.73s - 512.73s | and even the light aspects of what happens in your life 512.73s - 514.73s | and why it's important. 514.73s - 517.73s | So that's what got us to this point. 517.73s - 524.86s | So just having encryption is not enough. 524.86s - 525.86s | Configurations matter. 525.86s - 529.86s | Imagine having an amazing router with WPA3, 529.86s - 533.86s


chunk_id: 204_chunk_11
chunk_text:
RF Village. 480.73s - 481.73s | I was one of the co-authors 481.73s - 484.73s | of the original Gotenna attack, Raptor Captor, 484.73s - 487.73s | some other vehicle exploits, and some things like that. 487.73s - 489.73s | I spent 20 years in special operations 489.73s - 492.73s | before I started playing in this world. 492.73s - 495.73s | And the reason that this is so important to both of us 495.73s - 498.73s | is we work with law enforcement. 498.73s - 499.73s | We work with government. 499.73s - 502.73s | We work with corporations. 502.73s - 505.73s | And we educate them on how to control 505.73s - 507.73s | and understand all the different aspects, 507.73s - 509.73s | not just the physical, but also the digital 509.73s - 512.73s | and even the light aspects of what happens in your life 512.73s - 514.73s | and why it's important. 514.73s - 517.73s | So that's what got us to this point. 517.73s - 524.86s | So just having encryption is not enough. 524.86s - 525.86s | Configurations matter. 525.86s - 529.86s | Imagine having an amazing router with WPA3, 529.86s - 533.86s | an incredible password, and everything's good to go, 533.86s - 535.86s | but you just leave it as an open network. 535.86s - 539.86s | You still have encryption, but does it matter? 539.86s - 541.86s | Not at that point. 541.86s - 544.86s | Configurations, and that's what we're going to talk about. 544.86s - 546.86s | Yeah, so this was our testing setup. 546.86s - 549.86s | So we were testing in an anechoic chamber at the university 549.86s - 552.86s | where I'm pursuing my PhD in electrical and computer engineering. 552.86s - 555.86s | We used a representative sample of both iPhones and Androids 555.86s - 557.86s | connected with Gotenna Pros. 557.86s - 559.86s | And then we used just open-source hardware and software, 559.86s - 562.86s | so HackRF1 connected with open-source software 562.86s - 564.86s | running on an Ubuntu laptop. 564.86s - 567.86s | So very simple. 567.86s - 569.86s | So the first step of any sort of RF analysis 569.86s - 572.86s | starts by identifying the frequency and capturing the signal. 572.86s - 575.86s | This can be done either by analyzing FCC documentation, 575.86s - 576.86s |


chunk_id: 204_chunk_12
chunk_text:
| an incredible password, and everything's good to go, 533.86s - 535.86s | but you just leave it as an open network. 535.86s - 539.86s | You still have encryption, but does it matter? 539.86s - 541.86s | Not at that point. 541.86s - 544.86s | Configurations, and that's what we're going to talk about. 544.86s - 546.86s | Yeah, so this was our testing setup. 546.86s - 549.86s | So we were testing in an anechoic chamber at the university 549.86s - 552.86s | where I'm pursuing my PhD in electrical and computer engineering. 552.86s - 555.86s | We used a representative sample of both iPhones and Androids 555.86s - 557.86s | connected with Gotenna Pros. 557.86s - 559.86s | And then we used just open-source hardware and software, 559.86s - 562.86s | so HackRF1 connected with open-source software 562.86s - 564.86s | running on an Ubuntu laptop. 564.86s - 567.86s | So very simple. 567.86s - 569.86s | So the first step of any sort of RF analysis 569.86s - 572.86s | starts by identifying the frequency and capturing the signal. 572.86s - 575.86s | This can be done either by analyzing FCC documentation, 575.86s - 576.86s | by scanning the whole spectrum. 576.86s - 578.86s | In this case, it was configurable. 578.86s - 579.86s | We figured out where it was configurable, 579.86s - 581.86s | so we set those frequencies, 581.86s - 583.86s | and then we appropriately captured it in GQRX 583.86s - 585.86s | as seen on the waterfall on the right. 585.86s - 587.86s | And this doesn't take expensive equipment. 587.86s - 591.86s | $30 TV dongle, some $100 radios. 591.86s - 594.86s | You can really start moving along very quickly. 594.86s - 596.86s | 100%. 596.86s - 598.86s | So then we started analyzing the signal 598.86s - 601.86s | and figured out that Gotenna Pro was using 4FSK. 601.86s - 603.86s | That is four-level frequency shift keying. 603.86s - 607.86s | That's where the carrier shifted between four discrete frequencies. 607.86s - 608.86s | As we can see on the screen, 608.86s - 612.86s | it goes between negative 1.5 and positive 1.5. 612.86s - 614.86s | We implemented a custom GNU radio flow graph 614.86s - 620.86s | that can decode this exact type of 4FSK that Gotenna was using. 620.86s - 623.86s | Once we


chunk_id: 204_chunk_13
chunk_text:
by scanning the whole spectrum. 576.86s - 578.86s | In this case, it was configurable. 578.86s - 579.86s | We figured out where it was configurable, 579.86s - 581.86s | so we set those frequencies, 581.86s - 583.86s | and then we appropriately captured it in GQRX 583.86s - 585.86s | as seen on the waterfall on the right. 585.86s - 587.86s | And this doesn't take expensive equipment. 587.86s - 591.86s | $30 TV dongle, some $100 radios. 591.86s - 594.86s | You can really start moving along very quickly. 594.86s - 596.86s | 100%. 596.86s - 598.86s | So then we started analyzing the signal 598.86s - 601.86s | and figured out that Gotenna Pro was using 4FSK. 601.86s - 603.86s | That is four-level frequency shift keying. 603.86s - 607.86s | That's where the carrier shifted between four discrete frequencies. 607.86s - 608.86s | As we can see on the screen, 608.86s - 612.86s | it goes between negative 1.5 and positive 1.5. 612.86s - 614.86s | We implemented a custom GNU radio flow graph 614.86s - 620.86s | that can decode this exact type of 4FSK that Gotenna was using. 620.86s - 623.86s | Once we were confident that our demodulation was successful, 623.86s - 626.86s | we started analyzing raw bytes, 626.86s - 628.86s | and their ASCII representation. 628.86s - 630.86s | In this case, in Gen 1 and Gen 2, 630.86s - 634.86s | we were able to see the GID, the call sign, and the payload 634.86s - 636.86s | all unencrypted. 636.86s - 639.86s | So this was sort of like we're seeing here. 639.86s - 643.86s | It is encrypted somehow because we cannot see any of the data. 643.86s - 646.86s | It's more of an obfuscation, really. 646.86s - 651.86s | So then we sent two identical messages, and we compared them. 651.86s - 655.86s | So we see that in yellow color, they're mostly the same. 655.86s - 657.86s | They only differ in the red color, 657.86s - 660.86s | and red only is the one that changes 660.86s - 662.86s | if the same packet is being sent. 662.86s - 667.86s | So this is very commonly some form of static encryption in use. 667.86s - 670.86s | This observation is actually data whitening, 670.86s - 673.86s | not to be confused with white shadowing.


chunk_id: 204_chunk_14
chunk_text:
were confident that our demodulation was successful, 623.86s - 626.86s | we started analyzing raw bytes, 626.86s - 628.86s | and their ASCII representation. 628.86s - 630.86s | In this case, in Gen 1 and Gen 2, 630.86s - 634.86s | we were able to see the GID, the call sign, and the payload 634.86s - 636.86s | all unencrypted. 636.86s - 639.86s | So this was sort of like we're seeing here. 639.86s - 643.86s | It is encrypted somehow because we cannot see any of the data. 643.86s - 646.86s | It's more of an obfuscation, really. 646.86s - 651.86s | So then we sent two identical messages, and we compared them. 651.86s - 655.86s | So we see that in yellow color, they're mostly the same. 655.86s - 657.86s | They only differ in the red color, 657.86s - 660.86s | and red only is the one that changes 660.86s - 662.86s | if the same packet is being sent. 662.86s - 667.86s | So this is very commonly some form of static encryption in use. 667.86s - 670.86s | This observation is actually data whitening, 670.86s - 673.86s | not to be confused with white shadowing. 673.86s - 679.36s | Mainly because white shadows rarely work. 679.36s - 680.36s | Yeah. 680.36s - 682.36s | So data whitening is a technique that ensures 682.36s - 684.36s | that there are no long sequences of zeros 684.36s - 687.36s | that can cause drops in communication. 687.36s - 691.36s | It uses XOR with a static set of bytes. 691.36s - 693.36s | Those bytes are typically generated by something 693.36s - 695.36s | called linear feedback shift register, 695.36s - 697.36s | and we're going to talk about it later. 697.36s - 699.36s | It's important to note that while this is similar 699.36s - 701.36s | to XOR encryption, it is not cryptographically secure, 701.36s - 705.77s | as we will demonstrate in the next few slides. 705.77s - 708.77s | So our de-whitening process is shown in this algorithm. 708.77s - 711.77s | We transmit a handful of As followed by a handful of Bs. 711.77s - 713.77s | So for those who are not familiar with 713.77s - 716.77s | ASCII representation in hex, capital A is 41, 716.77s - 718.77s | so you'll see that a lot through our presentation, 718.77s -


chunk_id: 204_chunk_15
chunk_text:
673.86s - 679.36s | Mainly because white shadows rarely work. 679.36s - 680.36s | Yeah. 680.36s - 682.36s | So data whitening is a technique that ensures 682.36s - 684.36s | that there are no long sequences of zeros 684.36s - 687.36s | that can cause drops in communication. 687.36s - 691.36s | It uses XOR with a static set of bytes. 691.36s - 693.36s | Those bytes are typically generated by something 693.36s - 695.36s | called linear feedback shift register, 695.36s - 697.36s | and we're going to talk about it later. 697.36s - 699.36s | It's important to note that while this is similar 699.36s - 701.36s | to XOR encryption, it is not cryptographically secure, 701.36s - 705.77s | as we will demonstrate in the next few slides. 705.77s - 708.77s | So our de-whitening process is shown in this algorithm. 708.77s - 711.77s | We transmit a handful of As followed by a handful of Bs. 711.77s - 713.77s | So for those who are not familiar with 713.77s - 716.77s | ASCII representation in hex, capital A is 41, 716.77s - 718.77s | so you'll see that a lot through our presentation, 718.77s - 720.77s | and B will be 42. 720.77s - 723.77s | So we transmit a handful of number of As, 723.77s - 726.77s | we extract a byte from that transmission, 726.77s - 730.77s | and we XOR it with 0x41, which is capital A, 730.77s - 733.77s | and then that will give us our potential key stream. 733.77s - 736.77s | We then use that key stream against the second message, 736.77s - 738.77s | which is with Bs, and then we repeat that 738.77s - 740.77s | for the length of the entire message. 740.77s - 742.77s | And then we only keep the bytes that produce 742.77s - 745.77s | the accurate result, i.e., we receive the Bs. 745.77s - 751.69s | At that point, we found our offset at 42. 751.69s - 755.69s | This means that Gotenna is offsetting this 755.69s - 757.69s | like the entire, probably the header, 757.69s - 759.69s | because we've seen in the beginning 759.69s - 761.69s | that the header and data are combined. 761.69s - 764.69s | So in this case, the payload will start off at 42, 764.69s - 767.69s | and we found all


chunk_id: 204_chunk_16
chunk_text:
720.77s | and B will be 42. 720.77s - 723.77s | So we transmit a handful of number of As, 723.77s - 726.77s | we extract a byte from that transmission, 726.77s - 730.77s | and we XOR it with 0x41, which is capital A, 730.77s - 733.77s | and then that will give us our potential key stream. 733.77s - 736.77s | We then use that key stream against the second message, 736.77s - 738.77s | which is with Bs, and then we repeat that 738.77s - 740.77s | for the length of the entire message. 740.77s - 742.77s | And then we only keep the bytes that produce 742.77s - 745.77s | the accurate result, i.e., we receive the Bs. 745.77s - 751.69s | At that point, we found our offset at 42. 751.69s - 755.69s | This means that Gotenna is offsetting this 755.69s - 757.69s | like the entire, probably the header, 757.69s - 759.69s | because we've seen in the beginning 759.69s - 761.69s | that the header and data are combined. 761.69s - 764.69s | So in this case, the payload will start off at 42, 764.69s - 767.69s | and we found all of the green bytes in the first green line. 767.69s - 769.69s | And when we apply that against the message, 769.69s - 772.69s | we get 42s, and we translate that to ASCII. 772.69s - 773.69s | Those are Bs. 773.69s - 776.69s | So we have a partial whitening key. 776.69s - 778.69s | Then we can use this against a different message. 778.69s - 781.69s | So here we have the payload between 0 and 71. 781.69s - 784.69s | We can de-whiten everything after 42, 784.69s - 786.69s | so all part in orange, we de-whiten, 786.69s - 789.69s | and then we can receive that, okay, we have seen 10As. 789.69s - 792.69s | So we have 1041s and also the 0A 792.69s - 794.69s | that's also represented as the lengths. 794.69s - 798.69s | However, Gotenna is using a custom header, 798.69s - 801.69s | so we do not know what the 0 to 41 is. 801.69s - 805.69s | And the only way to find a whitening key for something 805.69s - 807.69s | is you have to know what's there. 807.69s - 809.69s | So we keep looking. 809.69s - 811.69s


chunk_id: 204_chunk_17
chunk_text:
of the green bytes in the first green line. 767.69s - 769.69s | And when we apply that against the message, 769.69s - 772.69s | we get 42s, and we translate that to ASCII. 772.69s - 773.69s | Those are Bs. 773.69s - 776.69s | So we have a partial whitening key. 776.69s - 778.69s | Then we can use this against a different message. 778.69s - 781.69s | So here we have the payload between 0 and 71. 781.69s - 784.69s | We can de-whiten everything after 42, 784.69s - 786.69s | so all part in orange, we de-whiten, 786.69s - 789.69s | and then we can receive that, okay, we have seen 10As. 789.69s - 792.69s | So we have 1041s and also the 0A 792.69s - 794.69s | that's also represented as the lengths. 794.69s - 798.69s | However, Gotenna is using a custom header, 798.69s - 801.69s | so we do not know what the 0 to 41 is. 801.69s - 805.69s | And the only way to find a whitening key for something 805.69s - 807.69s | is you have to know what's there. 807.69s - 809.69s | So we keep looking. 809.69s - 811.69s | So we're investigating special conditions, 811.69s - 813.69s | so we reiterate that we cannot, 813.69s - 816.69s | we don't know what's below 42. 816.69s - 819.69s | So we observe a special condition 819.69s - 821.69s | when we set 100As. 821.69s - 823.69s | What happens there is that the message splits. 823.69s - 825.69s | As you can see here, our capture 825.69s - 827.69s | received two different messages. 827.69s - 830.69s | So then let's investigate that. 831.69s - 833.69s | So we run the same exact strip 833.69s - 835.69s | that was shown in that algorithm 835.69s - 836.69s | against the second message, 836.69s - 839.69s | and we see a potential XOR starting at byte 2 839.69s - 841.69s | instead of 42. 841.69s - 843.69s | So this means this is a fragment split, 843.69s - 844.69s | the message split, 844.69s - 847.69s | and the payload started at offset 42. 847.69s - 850.69s | So we now have extra 40 bytes shown in green. 850.69s - 852.69s | We combine them with the already existing key 852.69s - 856.69s | that we found earlier between 42


chunk_id: 204_chunk_18
chunk_text:
| So we're investigating special conditions, 811.69s - 813.69s | so we reiterate that we cannot, 813.69s - 816.69s | we don't know what's below 42. 816.69s - 819.69s | So we observe a special condition 819.69s - 821.69s | when we set 100As. 821.69s - 823.69s | What happens there is that the message splits. 823.69s - 825.69s | As you can see here, our capture 825.69s - 827.69s | received two different messages. 827.69s - 830.69s | So then let's investigate that. 831.69s - 833.69s | So we run the same exact strip 833.69s - 835.69s | that was shown in that algorithm 835.69s - 836.69s | against the second message, 836.69s - 839.69s | and we see a potential XOR starting at byte 2 839.69s - 841.69s | instead of 42. 841.69s - 843.69s | So this means this is a fragment split, 843.69s - 844.69s | the message split, 844.69s - 847.69s | and the payload started at offset 42. 847.69s - 850.69s | So we now have extra 40 bytes shown in green. 850.69s - 852.69s | We combine them with the already existing key 852.69s - 856.69s | that we found earlier between 42 and 96. 856.69s - 860.69s | And then that gives us a key between 2 and 96. 860.69s - 862.69s | Now we use that, we use that key, 862.69s - 864.69s | so we take our packet, 864.69s - 866.69s | we apply the key between 2 and 96, 866.69s - 867.69s | and now we're seeing the payload, 867.69s - 869.69s | but we're not only seeing the payload. 869.69s - 870.69s | We're also seeing the call sign. 870.69s - 872.69s | So my call sign is $hide, 872.69s - 874.69s | and we can see that in blue. 874.69s - 876.69s | That is very critical. 876.69s - 878.69s | So another part that Gotenna was using 878.69s - 881.69s | was Gotenna Identifier, or GID. 881.69s - 883.69s | So in this case, we could not easily identify there. 883.69s - 885.69s | It was not, like, easily seen. 885.69s - 887.69s | So, but we do have a known value, 887.69s - 889.69s | and this is very important against known values. 889.69s - 891.69s | If we have a known value, i.e. in the app, 891.69s - 894.69s | it told us the


chunk_id: 204_chunk_19
chunk_text:
and 96. 856.69s - 860.69s | And then that gives us a key between 2 and 96. 860.69s - 862.69s | Now we use that, we use that key, 862.69s - 864.69s | so we take our packet, 864.69s - 866.69s | we apply the key between 2 and 96, 866.69s - 867.69s | and now we're seeing the payload, 867.69s - 869.69s | but we're not only seeing the payload. 869.69s - 870.69s | We're also seeing the call sign. 870.69s - 872.69s | So my call sign is $hide, 872.69s - 874.69s | and we can see that in blue. 874.69s - 876.69s | That is very critical. 876.69s - 878.69s | So another part that Gotenna was using 878.69s - 881.69s | was Gotenna Identifier, or GID. 881.69s - 883.69s | So in this case, we could not easily identify there. 883.69s - 885.69s | It was not, like, easily seen. 885.69s - 887.69s | So, but we do have a known value, 887.69s - 889.69s | and this is very important against known values. 889.69s - 891.69s | If we have a known value, i.e. in the app, 891.69s - 894.69s | it told us the very bottom part at 1029, 894.69s - 895.69s | that's our GID. 895.69s - 896.69s | So we're looking for that. 896.69s - 898.69s | So eventually, we discover it in the green, 898.69s - 901.69s | in the orange part in the packet. 901.69s - 904.69s | It is encoded in a very special way. 904.69s - 907.69s | So first, the seven bits 907.69s - 909.69s | that are containing the actual number, 909.69s - 910.69s | and then the most significant bit 910.69s - 912.69s | indicates where another byte is following. 912.69s - 915.69s | So that's how they avoid the use of, essentially, 915.69s - 916.69s | for example, as you can see, 916.69s - 919.69s | the 0A in both the payload and the call sign, 919.69s - 920.69s | that's the length. 920.69s - 922.69s | That's how they can sort of avoid, like, 922.69s - 924.69s | be more efficient of the use of the data stream 924.69s - 926.69s | within the radio. 926.69s - 927.69s | So that's simple enough. 927.69s - 929.69s | We can write this Python decode script 929.69s - 930.69s | to decode the GID, 930.69s


chunk_id: 204_chunk_20
chunk_text:
very bottom part at 1029, 894.69s - 895.69s | that's our GID. 895.69s - 896.69s | So we're looking for that. 896.69s - 898.69s | So eventually, we discover it in the green, 898.69s - 901.69s | in the orange part in the packet. 901.69s - 904.69s | It is encoded in a very special way. 904.69s - 907.69s | So first, the seven bits 907.69s - 909.69s | that are containing the actual number, 909.69s - 910.69s | and then the most significant bit 910.69s - 912.69s | indicates where another byte is following. 912.69s - 915.69s | So that's how they avoid the use of, essentially, 915.69s - 916.69s | for example, as you can see, 916.69s - 919.69s | the 0A in both the payload and the call sign, 919.69s - 920.69s | that's the length. 920.69s - 922.69s | That's how they can sort of avoid, like, 922.69s - 924.69s | be more efficient of the use of the data stream 924.69s - 926.69s | within the radio. 926.69s - 927.69s | So that's simple enough. 927.69s - 929.69s | We can write this Python decode script 929.69s - 930.69s | to decode the GID, 930.69s - 932.69s | and then we can take the orange bytes at the top 932.69s - 934.69s | and get the orange bytes at the bottom. 934.69s - 936.69s | Relatively simple. 936.69s - 938.69s | So now, our next part was, like, 938.69s - 940.69s | okay, let's discover the byte zero. 940.69s - 942.69s | So FCC comes to the rescue. 942.69s - 944.69s | They have a lot of useful information. 944.69s - 946.69s | I highly recommend FCC documentation. 946.69s - 949.69s | So that says, the FCC essentially says 949.69s - 952.69s | that GOTEN is using SI4460 radio, 952.69s - 954.69s | and that radio, based on its documentation, 954.69s - 957.69s | adds length as byte zero. 957.69s - 958.69s | So that means that we can find our node. 958.69s - 959.69s | We take our packet. 959.69s - 960.69s | We take the length. 960.69s - 962.69s | We get that 69. 962.69s - 964.69s | So then we have to subtract 1 964.69s - 965.69s | because that is the length byte. 965.69s - 966.69s | So we get 68. 966.69s - 969.69s | We convert decimal 68 to hex,


chunk_id: 204_chunk_21
chunk_text:
- 932.69s | and then we can take the orange bytes at the top 932.69s - 934.69s | and get the orange bytes at the bottom. 934.69s - 936.69s | Relatively simple. 936.69s - 938.69s | So now, our next part was, like, 938.69s - 940.69s | okay, let's discover the byte zero. 940.69s - 942.69s | So FCC comes to the rescue. 942.69s - 944.69s | They have a lot of useful information. 944.69s - 946.69s | I highly recommend FCC documentation. 946.69s - 949.69s | So that says, the FCC essentially says 949.69s - 952.69s | that GOTEN is using SI4460 radio, 952.69s - 954.69s | and that radio, based on its documentation, 954.69s - 957.69s | adds length as byte zero. 957.69s - 958.69s | So that means that we can find our node. 958.69s - 959.69s | We take our packet. 959.69s - 960.69s | We take the length. 960.69s - 962.69s | We get that 69. 962.69s - 964.69s | So then we have to subtract 1 964.69s - 965.69s | because that is the length byte. 965.69s - 966.69s | So we get 68. 966.69s - 969.69s | We convert decimal 68 to hex, 969.69s - 970.69s | and we get 44. 970.69s - 972.69s | And then the ciphertext was 47. 972.69s - 974.69s | We extort a 2, and we get 3. 974.69s - 979.69s | So that is our widening byte at byte zero. 979.69s - 981.69s | For byte one, we did a lot of testing, 981.69s - 983.69s | and eventually we figured out it was 96. 983.69s - 985.69s | So we'll kind of skip all the detail there 985.69s - 987.69s | because it's a short presentation. 987.69s - 989.69s | So in our current de-widening status, 989.69s - 991.69s | we have pretty much everything from byte zero to 96. 991.69s - 994.69s | We do not, unfortunately, know what last 10 are. 994.69s - 998.69s | So, of course, we do more investigation. 998.69s - 1001.69s | We find that the 2 bytes immediately following the message 1001.69s - 1005.69s | are a result of CRC16 CCITT variant. 1005.69s - 1008.69s | CRC16 stands for Cycle Redundancy Check. 1008.69s - 1011.69s | It's used as error-correcting code 1011.69s - 1013.69s | that is capable of determining 1013.69s - 1016.69s | whether or not the payload


chunk_id: 204_chunk_22
chunk_text:
969.69s - 970.69s | and we get 44. 970.69s - 972.69s | And then the ciphertext was 47. 972.69s - 974.69s | We extort a 2, and we get 3. 974.69s - 979.69s | So that is our widening byte at byte zero. 979.69s - 981.69s | For byte one, we did a lot of testing, 981.69s - 983.69s | and eventually we figured out it was 96. 983.69s - 985.69s | So we'll kind of skip all the detail there 985.69s - 987.69s | because it's a short presentation. 987.69s - 989.69s | So in our current de-widening status, 989.69s - 991.69s | we have pretty much everything from byte zero to 96. 991.69s - 994.69s | We do not, unfortunately, know what last 10 are. 994.69s - 998.69s | So, of course, we do more investigation. 998.69s - 1001.69s | We find that the 2 bytes immediately following the message 1001.69s - 1005.69s | are a result of CRC16 CCITT variant. 1005.69s - 1008.69s | CRC16 stands for Cycle Redundancy Check. 1008.69s - 1011.69s | It's used as error-correcting code 1011.69s - 1013.69s | that is capable of determining 1013.69s - 1016.69s | whether or not the payload has been corrupted in the transmission. 1016.69s - 1018.69s | So that's a very quick way to determine that. 1018.69s - 1020.69s | So we also do more analysis. 1020.69s - 1023.69s | We figure out that this CRC is initialized with zeros, 1023.69s - 1025.69s | and it uses 1021 as the polynomial. 1025.69s - 1028.69s | So then we take the entire packet up to those 10 bytes, 1028.69s - 1030.69s | and we compute the CRC16. 1030.69s - 1033.69s | So here on this slide, you can see the Python script that we implemented. 1033.69s - 1037.69s | So it's using zeros, and 1021 is the polynomial. 1037.69s - 1039.69s | So then we run it through that function. 1039.69s - 1042.69s | We put the packet that we saw earlier through that function, 1042.69s - 1046.69s | and then we get the CRC16 value is DCD2. 1046.69s - 1049.69s | And then our widened message, the ciphertext, was BCAA. 1049.69s - 1051.69s | So then we take, we XOR the two, 1051.69s - 1055.69s | and we get that the key at that offset is 6078. 1055.69s - 1056.69s | Okay, pretty great. 1056.69s - 1058.69s


chunk_id: 204_chunk_23
chunk_text:
has been corrupted in the transmission. 1016.69s - 1018.69s | So that's a very quick way to determine that. 1018.69s - 1020.69s | So we also do more analysis. 1020.69s - 1023.69s | We figure out that this CRC is initialized with zeros, 1023.69s - 1025.69s | and it uses 1021 as the polynomial. 1025.69s - 1028.69s | So then we take the entire packet up to those 10 bytes, 1028.69s - 1030.69s | and we compute the CRC16. 1030.69s - 1033.69s | So here on this slide, you can see the Python script that we implemented. 1033.69s - 1037.69s | So it's using zeros, and 1021 is the polynomial. 1037.69s - 1039.69s | So then we run it through that function. 1039.69s - 1042.69s | We put the packet that we saw earlier through that function, 1042.69s - 1046.69s | and then we get the CRC16 value is DCD2. 1046.69s - 1049.69s | And then our widened message, the ciphertext, was BCAA. 1049.69s - 1051.69s | So then we take, we XOR the two, 1051.69s - 1055.69s | and we get that the key at that offset is 6078. 1055.69s - 1056.69s | Okay, pretty great. 1056.69s - 1058.69s | So then the last eight bytes 1058.69s - 1061.69s | are a result of Reed-Solomon error-correcting scheme. 1061.69s - 1064.69s | So Gotenna is using both CRC and Reed-Solomon 1064.69s - 1066.69s | for error detection and correction. 1066.69s - 1069.69s | So a very powerful part about Reed-Solomon 1069.69s - 1072.69s | is that it can not only detect the errors, 1072.69s - 1074.69s | it can also correct them. 1074.69s - 1076.69s | So they are using eight error-correction symbols 1076.69s - 1078.69s | and first consecutive root set to one. 1078.69s - 1080.69s | Using Reed-Solomon library and these four lines 1080.69s - 1082.69s | to essentially compute the Reed-Solomon 1082.69s - 1084.69s | against the packet we found earlier. 1084.69s - 1089.69s | Once we do that, we get the line in the first bullet. 1089.69s - 1091.69s | So those are those eight bytes. 1091.69s - 1093.69s | We get the widened message, the ciphertext. 1093.69s - 1095.69s | We XOR the two, and we have the entire key. 1095.69s - 1099.69s | We have now the entire sequence from zero to the end. 1099.69s - 1101.69s | So that's pretty awesome, right? 1101.69s


chunk_id: 204_chunk_24
chunk_text:
| So then the last eight bytes 1058.69s - 1061.69s | are a result of Reed-Solomon error-correcting scheme. 1061.69s - 1064.69s | So Gotenna is using both CRC and Reed-Solomon 1064.69s - 1066.69s | for error detection and correction. 1066.69s - 1069.69s | So a very powerful part about Reed-Solomon 1069.69s - 1072.69s | is that it can not only detect the errors, 1072.69s - 1074.69s | it can also correct them. 1074.69s - 1076.69s | So they are using eight error-correction symbols 1076.69s - 1078.69s | and first consecutive root set to one. 1078.69s - 1080.69s | Using Reed-Solomon library and these four lines 1080.69s - 1082.69s | to essentially compute the Reed-Solomon 1082.69s - 1084.69s | against the packet we found earlier. 1084.69s - 1089.69s | Once we do that, we get the line in the first bullet. 1089.69s - 1091.69s | So those are those eight bytes. 1091.69s - 1093.69s | We get the widened message, the ciphertext. 1093.69s - 1095.69s | We XOR the two, and we have the entire key. 1095.69s - 1099.69s | We have now the entire sequence from zero to the end. 1099.69s - 1101.69s | So that's pretty awesome, right? 1101.69s - 1109.74s | So now a big part here that we want to note 1109.74s - 1111.74s | is that this entire sequence has been generated 1111.74s - 1113.74s | by something called linear feedback shift register 1113.74s - 1115.74s | or LFSR polynomial. 1115.74s - 1117.74s | A very powerful thing about this algorithm 1117.74s - 1118.74s | called Berlikamp-Massey. 1118.74s - 1121.74s | So we can use this sequence within Berlikamp-Massey 1121.74s - 1122.74s | to retrieve this polynomial. 1122.74s - 1125.74s | The polynomial is shown at the bottom. 1125.74s - 1127.74s | But there is more to here. 1127.74s - 1129.74s | So in case that we could not determine something, 1129.74s - 1131.74s | like byte one or any other part, 1131.74s - 1133.74s | like we could have a very partial sequence, 1133.74s - 1136.74s | we could use Berlikamp-Massey and mathematical techniques 1136.74s - 1140.74s | to determine this polynomial and the associated sequence 1140.74s - 1141.74s | even if we don't know things. 1141.74s - 1143.74s | So we could technically, with enough time 1143.74s - 1145.74s | and enough brute force, using Berlikamp-Massey, 1145.74s - 1148.74s | only knowing the payload,


chunk_id: 204_chunk_25
chunk_text:
- 1109.74s | So now a big part here that we want to note 1109.74s - 1111.74s | is that this entire sequence has been generated 1111.74s - 1113.74s | by something called linear feedback shift register 1113.74s - 1115.74s | or LFSR polynomial. 1115.74s - 1117.74s | A very powerful thing about this algorithm 1117.74s - 1118.74s | called Berlikamp-Massey. 1118.74s - 1121.74s | So we can use this sequence within Berlikamp-Massey 1121.74s - 1122.74s | to retrieve this polynomial. 1122.74s - 1125.74s | The polynomial is shown at the bottom. 1125.74s - 1127.74s | But there is more to here. 1127.74s - 1129.74s | So in case that we could not determine something, 1129.74s - 1131.74s | like byte one or any other part, 1131.74s - 1133.74s | like we could have a very partial sequence, 1133.74s - 1136.74s | we could use Berlikamp-Massey and mathematical techniques 1136.74s - 1140.74s | to determine this polynomial and the associated sequence 1140.74s - 1141.74s | even if we don't know things. 1141.74s - 1143.74s | So we could technically, with enough time 1143.74s - 1145.74s | and enough brute force, using Berlikamp-Massey, 1145.74s - 1148.74s | only knowing the payload, figure out the header, 1148.74s - 1150.74s | even if they were not being split. 1150.74s - 1152.74s | So math is a pretty awesome thing. 1152.74s - 1155.74s | So we can do that. 1155.74s - 1157.74s | So, yeah, so this is the polynomial. 1157.74s - 1158.74s | So they're using X to the 23. 1158.74s - 1161.74s | So, you know, and this is not, 1161.74s - 1164.74s | this is just meant to ensure that the receiver 1164.74s - 1166.74s | and the transmitter do not lose connection. 1166.74s - 1168.74s | So this is not meant as encryption. 1168.74s - 1171.74s | Yeah, this is really acting almost like a form 1171.74s - 1173.74s | of two-party authentication to make sure, 1173.74s - 1174.74s | yes, they received the message, 1174.74s - 1176.74s | yes, I've received the message, 1176.74s - 1180.74s | and using that as a way to almost have a packet count. 1180.74s - 1184.79s | So in our current decoding process, 1184.79s - 1185.79s | so this is done in Green Radio, 1185.79s - 1187.79s | and we're doing this essentially live, 1187.79s - 1190.79s | and this is just a


chunk_id: 204_chunk_26
chunk_text:
figure out the header, 1148.74s - 1150.74s | even if they were not being split. 1150.74s - 1152.74s | So math is a pretty awesome thing. 1152.74s - 1155.74s | So we can do that. 1155.74s - 1157.74s | So, yeah, so this is the polynomial. 1157.74s - 1158.74s | So they're using X to the 23. 1158.74s - 1161.74s | So, you know, and this is not, 1161.74s - 1164.74s | this is just meant to ensure that the receiver 1164.74s - 1166.74s | and the transmitter do not lose connection. 1166.74s - 1168.74s | So this is not meant as encryption. 1168.74s - 1171.74s | Yeah, this is really acting almost like a form 1171.74s - 1173.74s | of two-party authentication to make sure, 1173.74s - 1174.74s | yes, they received the message, 1174.74s - 1176.74s | yes, I've received the message, 1176.74s - 1180.74s | and using that as a way to almost have a packet count. 1180.74s - 1184.79s | So in our current decoding process, 1184.79s - 1185.79s | so this is done in Green Radio, 1185.79s - 1187.79s | and we're doing this essentially live, 1187.79s - 1190.79s | and this is just a screen capture of my console. 1190.79s - 1192.79s | So we get the raw bytes, 1192.79s - 1193.79s | and we automatically extract the GID. 1193.79s - 1194.79s | We apply the function. 1194.79s - 1196.79s | We can translate that to ASCII. 1196.79s - 1198.79s | We get the call sign, the payload, 1198.79s - 1200.79s | including multi-fragmented messages. 1200.79s - 1201.79s | So even in multi-fragmented, 1201.79s - 1204.79s | we can still extract the payload. 1204.79s - 1205.79s | So what GoTenor chose to encrypt. 1205.79s - 1208.79s | So we played a bit with encryption, 1208.79s - 1209.79s | and we see that it's only the payload. 1209.79s - 1211.79s | So what does it mean, essentially, 1211.79s - 1213.79s | once we can read all of the other signs? 1213.79s - 1215.79s | Because in encrypted, unencrypted mode, 1215.79s - 1217.79s | all of these are visible. 1217.79s - 1218.79s | So everything you see in red here 1218.79s - 1222.79s | means that at this point, where we currently are, 1222.79s - 1225.79s | we are able to see the message length. 1225.79s - 1226.79s | That can be pretty valuable. 1226.79s -


chunk_id: 204_chunk_27
chunk_text:
screen capture of my console. 1190.79s - 1192.79s | So we get the raw bytes, 1192.79s - 1193.79s | and we automatically extract the GID. 1193.79s - 1194.79s | We apply the function. 1194.79s - 1196.79s | We can translate that to ASCII. 1196.79s - 1198.79s | We get the call sign, the payload, 1198.79s - 1200.79s | including multi-fragmented messages. 1200.79s - 1201.79s | So even in multi-fragmented, 1201.79s - 1204.79s | we can still extract the payload. 1204.79s - 1205.79s | So what GoTenor chose to encrypt. 1205.79s - 1208.79s | So we played a bit with encryption, 1208.79s - 1209.79s | and we see that it's only the payload. 1209.79s - 1211.79s | So what does it mean, essentially, 1211.79s - 1213.79s | once we can read all of the other signs? 1213.79s - 1215.79s | Because in encrypted, unencrypted mode, 1215.79s - 1217.79s | all of these are visible. 1217.79s - 1218.79s | So everything you see in red here 1218.79s - 1222.79s | means that at this point, where we currently are, 1222.79s - 1225.79s | we are able to see the message length. 1225.79s - 1226.79s | That can be pretty valuable. 1226.79s - 1228.79s | That can definitely add up to things in the future, 1228.79s - 1232.79s | especially with long-term collection techniques. 1232.79s - 1233.79s | The GID. 1233.79s - 1235.79s | The GID is gonna be your unique identifier, 1235.79s - 1237.79s | which used to be your cell phone number, 1237.79s - 1239.79s | and you had to pick for it to be a randomized one, 1239.79s - 1242.79s | which we found out was just actually epoch. 1242.79s - 1245.79s | But you now can still, with this, 1245.79s - 1246.79s | they don't do the phone number. 1246.79s - 1248.79s | So that's a much better improvement there. 1248.79s - 1251.79s | But that GID tells me that is that exact same device. 1251.79s - 1253.79s | And you can change it, 1253.79s - 1256.79s | but understand that that GID is a unique identifier 1256.79s - 1258.79s | like a MAC address that follows you. 1258.79s - 1260.79s | Now, the call sign's a little bit different. 1260.79s - 1263.79s | This goes back to my former community. 1263.79s - 1264.79s | When you have call signs involved 1264.79s - 1266.79s | that can be read


chunk_id: 204_chunk_28
chunk_text:
1228.79s | That can definitely add up to things in the future, 1228.79s - 1232.79s | especially with long-term collection techniques. 1232.79s - 1233.79s | The GID. 1233.79s - 1235.79s | The GID is gonna be your unique identifier, 1235.79s - 1237.79s | which used to be your cell phone number, 1237.79s - 1239.79s | and you had to pick for it to be a randomized one, 1239.79s - 1242.79s | which we found out was just actually epoch. 1242.79s - 1245.79s | But you now can still, with this, 1245.79s - 1246.79s | they don't do the phone number. 1246.79s - 1248.79s | So that's a much better improvement there. 1248.79s - 1251.79s | But that GID tells me that is that exact same device. 1251.79s - 1253.79s | And you can change it, 1253.79s - 1256.79s | but understand that that GID is a unique identifier 1256.79s - 1258.79s | like a MAC address that follows you. 1258.79s - 1260.79s | Now, the call sign's a little bit different. 1260.79s - 1263.79s | This goes back to my former community. 1263.79s - 1264.79s | When you have call signs involved 1264.79s - 1266.79s | that can be read in the clear, 1266.79s - 1270.79s | now I possibly know how many people are in an organization 1270.79s - 1273.79s | because typically they have a numerical sequence after it, 1273.79s - 1274.79s | and I can start telling more 1274.79s - 1276.79s | about that individual organization. 1276.79s - 1280.79s | So by having the equipment and the call sign, 1280.79s - 1282.79s | I can now start linking equipment 1282.79s - 1284.79s | to not only organizations but individuals 1284.79s - 1287.79s | to who was using the equipment at what time. 1287.79s - 1290.79s | Payload length, again, much like message length, 1290.79s - 1292.79s | that gives us really valuable things 1292.79s - 1295.79s | to know what is it that we need to focus on 1295.79s - 1296.79s | and what are they saying. 1296.79s - 1297.79s | Is it short messages, long messages? 1297.79s - 1300.79s | Are they using brevity? 1300.79s - 1302.79s | And the CRC and the Reed-Solomon, 1302.79s - 1303.79s | we're going to look and see 1303.79s - 1306.79s | that those become fairly valuable in the end. 1306.79s - 1308.79s | But these are the reasons this


chunk_id: 204_chunk_29
chunk_text:
in the clear, 1266.79s - 1270.79s | now I possibly know how many people are in an organization 1270.79s - 1273.79s | because typically they have a numerical sequence after it, 1273.79s - 1274.79s | and I can start telling more 1274.79s - 1276.79s | about that individual organization. 1276.79s - 1280.79s | So by having the equipment and the call sign, 1280.79s - 1282.79s | I can now start linking equipment 1282.79s - 1284.79s | to not only organizations but individuals 1284.79s - 1287.79s | to who was using the equipment at what time. 1287.79s - 1290.79s | Payload length, again, much like message length, 1290.79s - 1292.79s | that gives us really valuable things 1292.79s - 1295.79s | to know what is it that we need to focus on 1295.79s - 1296.79s | and what are they saying. 1296.79s - 1297.79s | Is it short messages, long messages? 1297.79s - 1300.79s | Are they using brevity? 1300.79s - 1302.79s | And the CRC and the Reed-Solomon, 1302.79s - 1303.79s | we're going to look and see 1303.79s - 1306.79s | that those become fairly valuable in the end. 1306.79s - 1308.79s | But these are the reasons this really concerned me. 1308.79s - 1310.79s | 100%. 1310.79s - 1311.79s | So now, in this case, 1311.79s - 1313.79s | we've shown what we've discovered so far, 1313.79s - 1315.79s | so we go more in our analysis, right? 1315.79s - 1316.79s | So that's what happens, right? 1316.79s - 1318.79s | So we analyze the remaining fields. 1318.79s - 1319.79s | We see the highlighted in blue. 1319.79s - 1321.79s | We decode that and figure out that's the timestamp. 1321.79s - 1322.79s | So you see here January 12th, 1322.79s - 1325.79s | that's when we did the very initial capture, 1325.79s - 1326.79s | so that's pretty awesome. 1326.79s - 1332.79s | So we also discovered these tags. 1332.79s - 1339.54s | So... 1339.54s - 1340.54s | There we go. 1340.54s - 1341.54s | And we knew we were on our way 1341.54s - 1344.54s | to something great at this point. 1344.54s - 1346.54s | So an additional thing with this presentation 1346.54s - 1348.54s | that we want to do is we want to teach you 1348.54s - 1349.54s | how we do reverse engineering. 1349.54s - 1352.54s | So we discovered that this


chunk_id: 204_chunk_30
chunk_text:
really concerned me. 1308.79s - 1310.79s | 100%. 1310.79s - 1311.79s | So now, in this case, 1311.79s - 1313.79s | we've shown what we've discovered so far, 1313.79s - 1315.79s | so we go more in our analysis, right? 1315.79s - 1316.79s | So that's what happens, right? 1316.79s - 1318.79s | So we analyze the remaining fields. 1318.79s - 1319.79s | We see the highlighted in blue. 1319.79s - 1321.79s | We decode that and figure out that's the timestamp. 1321.79s - 1322.79s | So you see here January 12th, 1322.79s - 1325.79s | that's when we did the very initial capture, 1325.79s - 1326.79s | so that's pretty awesome. 1326.79s - 1332.79s | So we also discovered these tags. 1332.79s - 1339.54s | So... 1339.54s - 1340.54s | There we go. 1340.54s - 1341.54s | And we knew we were on our way 1341.54s - 1344.54s | to something great at this point. 1344.54s - 1346.54s | So an additional thing with this presentation 1346.54s - 1348.54s | that we want to do is we want to teach you 1348.54s - 1349.54s | how we do reverse engineering. 1349.54s - 1352.54s | So we discovered that this protocol is using tags. 1352.54s - 1355.54s | So they're using tag 57, tag 24, and others. 1355.54s - 1357.54s | So this is important to note. 1357.54s - 1359.54s | So we'll use this in the rest of the presentation, 1359.54s - 1361.54s | but it's important to note how we discovered that, 1361.54s - 1364.54s | okay, so 57 or 39 hex, 1364.54s - 1369.54s | after that, there is the UTC timestamp. 1369.54s - 1371.54s | So then we use this in tag-based identification 1371.54s - 1372.54s | in our script. 1372.54s - 1376.54s | So we take the tag is equal to 57, 1376.54s - 1378.54s | and then we appropriately apply the Python code 1378.54s - 1380.54s | to decode that. 1380.54s - 1381.54s | So that's what we're doing. 1381.54s - 1383.54s | So at this point, we're a bit stuck, right? 1383.54s - 1385.54s | So we could keep going the same things 1385.54s - 1386.54s | over and over again, 1386.54s - 1388.54s | and, like, eventually we'll get everything. 1388.54s - 1389.54s | Maybe we won't. 1389.54s - 1391.54s | But, you know, what happened in the V1 here? 1391.54s -


chunk_id: 204_chunk_31
chunk_text:
protocol is using tags. 1352.54s - 1355.54s | So they're using tag 57, tag 24, and others. 1355.54s - 1357.54s | So this is important to note. 1357.54s - 1359.54s | So we'll use this in the rest of the presentation, 1359.54s - 1361.54s | but it's important to note how we discovered that, 1361.54s - 1364.54s | okay, so 57 or 39 hex, 1364.54s - 1369.54s | after that, there is the UTC timestamp. 1369.54s - 1371.54s | So then we use this in tag-based identification 1371.54s - 1372.54s | in our script. 1372.54s - 1376.54s | So we take the tag is equal to 57, 1376.54s - 1378.54s | and then we appropriately apply the Python code 1378.54s - 1380.54s | to decode that. 1380.54s - 1381.54s | So that's what we're doing. 1381.54s - 1383.54s | So at this point, we're a bit stuck, right? 1383.54s - 1385.54s | So we could keep going the same things 1385.54s - 1386.54s | over and over again, 1386.54s - 1388.54s | and, like, eventually we'll get everything. 1388.54s - 1389.54s | Maybe we won't. 1389.54s - 1391.54s | But, you know, what happened in the V1 here? 1391.54s - 1394.54s | So this is where I kind of fell back to the version 1 1394.54s - 1398.54s | when I worked with Tim Kerster on that. 1398.54s - 1400.54s | And he and I had kind of a light bulb moment. 1400.54s - 1401.54s | He's an engineer. 1401.54s - 1402.54s | I'm a knuckle dragger. 1402.54s - 1404.54s | So we looked at it two totally different ways. 1404.54s - 1407.54s | So he went home that night to start working on 1407.54s - 1411.54s | an automatic demodulator for the FSK, 1411.54s - 1413.54s | and I started seeing what I could find 1413.54s - 1415.54s | so we could try to compare knowledge, 1415.54s - 1416.54s | and he comes back the next day and goes, 1416.54s - 1419.54s | Woody, I really hope that, you know, 1419.54s - 1421.54s | this demodulator that I made is working. 1421.54s - 1422.54s | I wish there was some way that I could check 1422.54s - 1425.54s | against what the actual code that's coming out is 1425.54s - 1427.54s | to make sure that everything's correct. 1427.54s - 1429.54s | And I said, well, hey, we can


chunk_id: 204_chunk_32
chunk_text:
1394.54s | So this is where I kind of fell back to the version 1 1394.54s - 1398.54s | when I worked with Tim Kerster on that. 1398.54s - 1400.54s | And he and I had kind of a light bulb moment. 1400.54s - 1401.54s | He's an engineer. 1401.54s - 1402.54s | I'm a knuckle dragger. 1402.54s - 1404.54s | So we looked at it two totally different ways. 1404.54s - 1407.54s | So he went home that night to start working on 1407.54s - 1411.54s | an automatic demodulator for the FSK, 1411.54s - 1413.54s | and I started seeing what I could find 1413.54s - 1415.54s | so we could try to compare knowledge, 1415.54s - 1416.54s | and he comes back the next day and goes, 1416.54s - 1419.54s | Woody, I really hope that, you know, 1419.54s - 1421.54s | this demodulator that I made is working. 1421.54s - 1422.54s | I wish there was some way that I could check 1422.54s - 1425.54s | against what the actual code that's coming out is 1425.54s - 1427.54s | to make sure that everything's correct. 1427.54s - 1429.54s | And I said, well, hey, we can just compare it 1429.54s - 1430.54s | to the stuff that I've been looking at 1430.54s - 1433.54s | through the UART, and then we'll just know, right? 1433.54s - 1434.54s | At which point he said, 1434.54s - 1436.54s | what do you mean you have UART? 1436.54s - 1439.54s | I just assumed he'd check. 1439.54s - 1441.54s | Yeah, so we don't have UART in this case 1441.54s - 1443.54s | with Gotenna Pro, but we have something better. 1443.54s - 1445.54s | So Clayton just casually mentions, 1445.54s - 1446.54s | why don't you read from the app? 1446.54s - 1448.54s | It was useful when I did Mesh. 1448.54s - 1449.54s | Wait, what? 1449.54s - 1450.54s | We had code the entire time? 1450.54s - 1451.54s | Like, what? 1451.54s - 1452.54s | I go online, and, like, I'm supposedly 1452.54s - 1454.54s | this, like, reverse engineer, right? 1454.54s - 1455.54s | And, like, I didn't look at the app. 1455.54s - 1456.54s | What? 1456.54s - 1460.54s | So everything in the app is plain text. 1460.54s - 1461.54s | Yeah. 1461.54s - 1462.54s | Look at this. 1462.54s - 1463.54s |


chunk_id: 204_chunk_33
chunk_text:
just compare it 1429.54s - 1430.54s | to the stuff that I've been looking at 1430.54s - 1433.54s | through the UART, and then we'll just know, right? 1433.54s - 1434.54s | At which point he said, 1434.54s - 1436.54s | what do you mean you have UART? 1436.54s - 1439.54s | I just assumed he'd check. 1439.54s - 1441.54s | Yeah, so we don't have UART in this case 1441.54s - 1443.54s | with Gotenna Pro, but we have something better. 1443.54s - 1445.54s | So Clayton just casually mentions, 1445.54s - 1446.54s | why don't you read from the app? 1446.54s - 1448.54s | It was useful when I did Mesh. 1448.54s - 1449.54s | Wait, what? 1449.54s - 1450.54s | We had code the entire time? 1450.54s - 1451.54s | Like, what? 1451.54s - 1452.54s | I go online, and, like, I'm supposedly 1452.54s - 1454.54s | this, like, reverse engineer, right? 1454.54s - 1455.54s | And, like, I didn't look at the app. 1455.54s - 1456.54s | What? 1456.54s - 1460.54s | So everything in the app is plain text. 1460.54s - 1461.54s | Yeah. 1461.54s - 1462.54s | Look at this. 1462.54s - 1463.54s | So we go in, decompile it. 1463.54s - 1464.54s | Boom. 1464.54s - 1465.54s | We can see the firmware in there. 1465.54s - 1466.54s | We can see the source code. 1466.54s - 1467.54s | Like, I was looking for this, 1467.54s - 1470.54s | but, like, it's right there. 1470.54s - 1471.54s | Wow. 1471.54s - 1473.54s | Yeah, so companies really don't think like hackers. 1473.54s - 1475.54s | So, like, hackers, like the guys in these pictures, 1475.54s - 1477.54s | they can find full source code and firmware available 1477.54s - 1479.54s | completely unencrypted and obfuscated. 1479.54s - 1481.54s | It exists. 1481.54s - 1482.54s | Yeah. 1482.54s - 1483.54s | And this is where we said, 1483.54s - 1486.54s | oh, I think things are going to be a little bit better now. 1486.54s - 1488.54s | Because in version 1, 1488.54s - 1490.54s | we just had to kind of bare knuckle through it 1490.54s - 1491.54s | and hope we were close. 1491.54s - 1493.54s | We just knew that our demodulation was working. 1493.54s - 1494.54s | We didn't have tags yet, 1494.54s - 1496.54s | which I think we're


chunk_id: 204_chunk_34
chunk_text:
So we go in, decompile it. 1463.54s - 1464.54s | Boom. 1464.54s - 1465.54s | We can see the firmware in there. 1465.54s - 1466.54s | We can see the source code. 1466.54s - 1467.54s | Like, I was looking for this, 1467.54s - 1470.54s | but, like, it's right there. 1470.54s - 1471.54s | Wow. 1471.54s - 1473.54s | Yeah, so companies really don't think like hackers. 1473.54s - 1475.54s | So, like, hackers, like the guys in these pictures, 1475.54s - 1477.54s | they can find full source code and firmware available 1477.54s - 1479.54s | completely unencrypted and obfuscated. 1479.54s - 1481.54s | It exists. 1481.54s - 1482.54s | Yeah. 1482.54s - 1483.54s | And this is where we said, 1483.54s - 1486.54s | oh, I think things are going to be a little bit better now. 1486.54s - 1488.54s | Because in version 1, 1488.54s - 1490.54s | we just had to kind of bare knuckle through it 1490.54s - 1491.54s | and hope we were close. 1491.54s - 1493.54s | We just knew that our demodulation was working. 1493.54s - 1494.54s | We didn't have tags yet, 1494.54s - 1496.54s | which I think we're going to get to. 1496.54s - 1498.54s | Yeah, so we go back, and we look through the source code. 1498.54s - 1499.54s | We find these tags. 1499.54s - 1501.54s | Remember that we were talking about reverse engineering tags? 1501.54s - 1502.54s | We see 57 right here. 1502.54s - 1503.54s | So we were spot on. 1503.54s - 1506.54s | Our reverse engineering, like, methodology was very spot on. 1506.54s - 1508.54s | So that's what we wanted to show you. 1508.54s - 1509.54s | We find more tags, right? 1509.54s - 1510.54s | PB broadcast. 1510.54s - 1512.54s | We see key data coordinates. 1512.54s - 1514.54s | So, you know, we have a bunch of tags, right? 1514.54s - 1517.54s | So you're assuming that we use this Java source code 1517.54s - 1519.54s | and essentially slowly update our script. 1519.54s - 1521.54s | This may take, like, a couple months, 1521.54s - 1523.54s | and eventually we'll have a better product. 1523.54s - 1524.54s | Well, not quite. 1524.54s - 1527.54s | Ain't nobody got time for that. 1527.54s - 1529.54s | So we find an interesting observation. 1529.54s - 1531.54s | There's


chunk_id: 204_chunk_35
chunk_text:
going to get to. 1496.54s - 1498.54s | Yeah, so we go back, and we look through the source code. 1498.54s - 1499.54s | We find these tags. 1499.54s - 1501.54s | Remember that we were talking about reverse engineering tags? 1501.54s - 1502.54s | We see 57 right here. 1502.54s - 1503.54s | So we were spot on. 1503.54s - 1506.54s | Our reverse engineering, like, methodology was very spot on. 1506.54s - 1508.54s | So that's what we wanted to show you. 1508.54s - 1509.54s | We find more tags, right? 1509.54s - 1510.54s | PB broadcast. 1510.54s - 1512.54s | We see key data coordinates. 1512.54s - 1514.54s | So, you know, we have a bunch of tags, right? 1514.54s - 1517.54s | So you're assuming that we use this Java source code 1517.54s - 1519.54s | and essentially slowly update our script. 1519.54s - 1521.54s | This may take, like, a couple months, 1521.54s - 1523.54s | and eventually we'll have a better product. 1523.54s - 1524.54s | Well, not quite. 1524.54s - 1527.54s | Ain't nobody got time for that. 1527.54s - 1529.54s | So we find an interesting observation. 1529.54s - 1531.54s | There's a file descriptor, 1531.54s - 1533.54s | and we find something called Proto 3. 1533.54s - 1535.54s | Some of you are familiar with that already, 1535.54s - 1537.54s | but we weren't, right? 1537.54s - 1539.54s | So we looked this up, and it's a protocol buffers. 1539.54s - 1541.54s | It's used as an open source library 1541.54s - 1544.54s | developed by Google to help companies and other people 1544.54s - 1546.54s | to develop custom protocols, 1546.54s - 1548.54s | and they're supported by all kinds of languages, 1548.54s - 1552.54s | Python, Java, C, like, all kinds of things, right? 1552.54s - 1556.54s | So we go online, and we kind of take the string, 1556.54s - 1559.54s | the binary string, and we kind of figure out, 1559.54s - 1561.54s | okay, these may be the fields, right, 1561.54s - 1563.54s | the sender, the call sign, and then let's try it, right? 1563.54s - 1565.54s | So we put in the hex at the bottom, 1565.54s - 1568.54s | and then, wow, the whole thing is there. 1568.54s - 1571.54s | But literally, you just put it in the program on one side,


chunk_id: 204_chunk_36
chunk_text:
a file descriptor, 1531.54s - 1533.54s | and we find something called Proto 3. 1533.54s - 1535.54s | Some of you are familiar with that already, 1535.54s - 1537.54s | but we weren't, right? 1537.54s - 1539.54s | So we looked this up, and it's a protocol buffers. 1539.54s - 1541.54s | It's used as an open source library 1541.54s - 1544.54s | developed by Google to help companies and other people 1544.54s - 1546.54s | to develop custom protocols, 1546.54s - 1548.54s | and they're supported by all kinds of languages, 1548.54s - 1552.54s | Python, Java, C, like, all kinds of things, right? 1552.54s - 1556.54s | So we go online, and we kind of take the string, 1556.54s - 1559.54s | the binary string, and we kind of figure out, 1559.54s - 1561.54s | okay, these may be the fields, right, 1561.54s - 1563.54s | the sender, the call sign, and then let's try it, right? 1563.54s - 1565.54s | So we put in the hex at the bottom, 1565.54s - 1568.54s | and then, wow, the whole thing is there. 1568.54s - 1571.54s | But literally, you just put it in the program on one side, 1571.54s - 1573.54s | push a button, and it gives you everything on the other. 1573.54s - 1575.54s | Like, it's automatic. 1575.54s - 1577.54s | Like, this did not happen in V1 or Mesh. 1577.54s - 1580.54s | Like, this is, like, way easier. 1580.54s - 1582.54s | So, yeah, so we then go in, 1582.54s - 1584.54s | and then let's do this for real. 1584.54s - 1587.54s | So we go to all of the decompiled stuff. 1587.54s - 1589.54s | We take the file extractors. 1589.54s - 1592.54s | We put in our own custom file called Proto extraction, 1592.54s - 1594.54s | and then we run, that will generate a binary file, 1594.54s - 1596.54s | and then we use PBTK. 1596.54s - 1598.54s | This is an open-source tool. 1598.54s - 1600.54s | We use this against this binary file, 1600.54s - 1603.54s | and that gives us all of these things at the bottom, 1603.54s - 1604.54s | like all the proto files. 1604.54s - 1607.54s | So the base header essentially sets up the message. 1607.54s - 1609.54s | This imports the header protobuf. 1609.54s - 1611.54s | The header protobuf was


chunk_id: 204_chunk_37
chunk_text:
1571.54s - 1573.54s | push a button, and it gives you everything on the other. 1573.54s - 1575.54s | Like, it's automatic. 1575.54s - 1577.54s | Like, this did not happen in V1 or Mesh. 1577.54s - 1580.54s | Like, this is, like, way easier. 1580.54s - 1582.54s | So, yeah, so we then go in, 1582.54s - 1584.54s | and then let's do this for real. 1584.54s - 1587.54s | So we go to all of the decompiled stuff. 1587.54s - 1589.54s | We take the file extractors. 1589.54s - 1592.54s | We put in our own custom file called Proto extraction, 1592.54s - 1594.54s | and then we run, that will generate a binary file, 1594.54s - 1596.54s | and then we use PBTK. 1596.54s - 1598.54s | This is an open-source tool. 1598.54s - 1600.54s | We use this against this binary file, 1600.54s - 1603.54s | and that gives us all of these things at the bottom, 1603.54s - 1604.54s | like all the proto files. 1604.54s - 1607.54s | So the base header essentially sets up the message. 1607.54s - 1609.54s | This imports the header protobuf. 1609.54s - 1611.54s | The header protobuf was what we were doing 1611.54s - 1612.54s | in reverse engineering in BlackboxRF, right? 1612.54s - 1614.54s | So, like, it shows us all the things. 1614.54s - 1617.54s | What's important here is this data type, right? 1617.54s - 1620.54s | This enum would be very difficult to reverse engineer. 1620.54s - 1622.54s | Like, we would have to take so many samples 1622.54s - 1624.54s | and then hope that we can maybe figure out 1624.54s - 1626.54s | the text is 3 and then ping is 5. 1626.54s - 1628.54s | That would be very difficult. 1628.54s - 1630.54s | So let's go back full circle. 1630.54s - 1631.54s | What were those tags, right? 1631.54s - 1633.54s | So if we compile this protobuf in Java, 1633.54s - 1635.54s | because that's what Gotenna is using, 1635.54s - 1636.54s | we can see these cases. 1636.54s - 1638.54s | So these cases are used as different parts 1638.54s - 1641.54s | of the protocol to essentially define different things. 1641.54s - 1643.54s | So we were spot-on, right? 1643.54s - 1644.54s | These tags were cases. 1644.54s - 1645.54s | That's pretty awesome. 1645.54s - 1647.54s


chunk_id: 204_chunk_38
chunk_text:
what we were doing 1611.54s - 1612.54s | in reverse engineering in BlackboxRF, right? 1612.54s - 1614.54s | So, like, it shows us all the things. 1614.54s - 1617.54s | What's important here is this data type, right? 1617.54s - 1620.54s | This enum would be very difficult to reverse engineer. 1620.54s - 1622.54s | Like, we would have to take so many samples 1622.54s - 1624.54s | and then hope that we can maybe figure out 1624.54s - 1626.54s | the text is 3 and then ping is 5. 1626.54s - 1628.54s | That would be very difficult. 1628.54s - 1630.54s | So let's go back full circle. 1630.54s - 1631.54s | What were those tags, right? 1631.54s - 1633.54s | So if we compile this protobuf in Java, 1633.54s - 1635.54s | because that's what Gotenna is using, 1635.54s - 1636.54s | we can see these cases. 1636.54s - 1638.54s | So these cases are used as different parts 1638.54s - 1641.54s | of the protocol to essentially define different things. 1641.54s - 1643.54s | So we were spot-on, right? 1643.54s - 1644.54s | These tags were cases. 1644.54s - 1645.54s | That's pretty awesome. 1645.54s - 1647.54s | And we got 57 and the rest of them. 1647.54s - 1650.54s | And you also noticed that you could see things 1650.54s - 1652.54s | like when they requested, I don't know, keys. 1653.54s - 1655.54s | You could see the code of how to request a key. 1655.54s - 1656.54s | 100%. 1656.54s - 1657.54s | So, yeah. 1657.54s - 1659.54s | So a cool part about protobuf 1659.54s - 1661.54s | is they can be compiled for Python. 1661.54s - 1663.54s | What else is using Python? 1663.54s - 1666.54s | I believe there's a little thing called GNU radio. 1666.54s - 1667.54s | Yeah, that might be cool. 1667.54s - 1669.54s | It's so easy, even I can do it. 1669.54s - 1670.54s | Yeah. 1670.54s - 1672.54s | So we go in and we import a base message data type 1672.54s - 1674.54s | and we make a blueprint statements 1674.54s - 1675.54s | to associate everything. 1675.54s - 1678.54s | And perfect decode. 1678.54s - 1683.07s | Victory. 1683.07s - 1685.07s | But wait, we haven't found a single vulnerability yet. 1685.07s - 1686.07s | We just decoded the thing. 1686.07s - 1688.07s


chunk_id: 204_chunk_39
chunk_text:
| And we got 57 and the rest of them. 1647.54s - 1650.54s | And you also noticed that you could see things 1650.54s - 1652.54s | like when they requested, I don't know, keys. 1653.54s - 1655.54s | You could see the code of how to request a key. 1655.54s - 1656.54s | 100%. 1656.54s - 1657.54s | So, yeah. 1657.54s - 1659.54s | So a cool part about protobuf 1659.54s - 1661.54s | is they can be compiled for Python. 1661.54s - 1663.54s | What else is using Python? 1663.54s - 1666.54s | I believe there's a little thing called GNU radio. 1666.54s - 1667.54s | Yeah, that might be cool. 1667.54s - 1669.54s | It's so easy, even I can do it. 1669.54s - 1670.54s | Yeah. 1670.54s - 1672.54s | So we go in and we import a base message data type 1672.54s - 1674.54s | and we make a blueprint statements 1674.54s - 1675.54s | to associate everything. 1675.54s - 1678.54s | And perfect decode. 1678.54s - 1683.07s | Victory. 1683.07s - 1685.07s | But wait, we haven't found a single vulnerability yet. 1685.07s - 1686.07s | We just decoded the thing. 1686.07s - 1688.07s | Like, there's 30 more slides of actual vulnerabilities. 1688.07s - 1691.07s | So, you know, stay seated. 1691.07s - 1694.07s | So with this decode, now that we can read things, 1694.07s - 1699.07s | we can do frequency decoding, shared location. 1699.07s - 1702.07s | We can do emergency messages, all kinds of things. 1702.07s - 1704.07s | The only thing where we received the challenge 1704.07s - 1706.07s | was in coordinate decoding. 1706.07s - 1709.07s | So in the app, we can make, for example, 1709.07s - 1711.07s | like around this island, we can make coordinates. 1711.07s - 1713.07s | And then when we're capturing it, 1713.07s - 1716.07s | we see binary data represented as Base64 and JSON. 1716.07s - 1719.07s | And in this case, there isn't much, right? 1719.07s - 1721.07s | So, like, we can't see here. 1721.07s - 1722.07s | So we go back to proto. 1722.07s - 1723.07s | They're defined as bytes. 1723.07s - 1726.07s | So that means that decoding on our side has not been added. 1726.07s - 1727.07s | So that's very simple. 1727.07s - 1730.07s | We just use decode as little n, the


chunk_id: 204_chunk_40
chunk_text:
| Like, there's 30 more slides of actual vulnerabilities. 1688.07s - 1691.07s | So, you know, stay seated. 1691.07s - 1694.07s | So with this decode, now that we can read things, 1694.07s - 1699.07s | we can do frequency decoding, shared location. 1699.07s - 1702.07s | We can do emergency messages, all kinds of things. 1702.07s - 1704.07s | The only thing where we received the challenge 1704.07s - 1706.07s | was in coordinate decoding. 1706.07s - 1709.07s | So in the app, we can make, for example, 1709.07s - 1711.07s | like around this island, we can make coordinates. 1711.07s - 1713.07s | And then when we're capturing it, 1713.07s - 1716.07s | we see binary data represented as Base64 and JSON. 1716.07s - 1719.07s | And in this case, there isn't much, right? 1719.07s - 1721.07s | So, like, we can't see here. 1721.07s - 1722.07s | So we go back to proto. 1722.07s - 1723.07s | They're defined as bytes. 1723.07s - 1726.07s | So that means that decoding on our side has not been added. 1726.07s - 1727.07s | So that's very simple. 1727.07s - 1730.07s | We just use decode as little n, the n double double, 1730.07s - 1732.07s | and then boom, we get the coordinates. 1732.07s - 1733.07s | So that's fixed. 1733.07s - 1736.07s | So now we found our true first vulnerability, right? 1736.07s - 1737.07s | So, like, we encrypt the message 1737.07s - 1739.07s | and we're just kind of looking at things. 1739.07s - 1742.07s | So what can you do when somebody can capture yes or no 1742.07s - 1743.07s | and tell the differences? 1743.07s - 1745.07s | When you start dealing with organizations 1745.07s - 1747.07s | that are using brevity for communication, 1747.07s - 1749.07s | simple things like the length of a message 1749.07s - 1752.07s | become very easy even without going into advanced steps 1752.07s - 1754.07s | to be able to tell what kind of communication may be happening. 1754.07s - 1756.07s | Are they only sending coordinates? 1756.07s - 1757.07s | Are they sending commands? 1757.07s - 1759.07s | Are they just sending comms checks? 1759.07s - 1761.07s | So this starts becoming really important, 1761.07s - 1764.07s | being able to understand these message lengths. 1764.07s - 1765.07s | Yeah, so it's crucial. 1765.07s - 1768.07s


chunk_id: 204_chunk_41
chunk_text:
n double double, 1730.07s - 1732.07s | and then boom, we get the coordinates. 1732.07s - 1733.07s | So that's fixed. 1733.07s - 1736.07s | So now we found our true first vulnerability, right? 1736.07s - 1737.07s | So, like, we encrypt the message 1737.07s - 1739.07s | and we're just kind of looking at things. 1739.07s - 1742.07s | So what can you do when somebody can capture yes or no 1742.07s - 1743.07s | and tell the differences? 1743.07s - 1745.07s | When you start dealing with organizations 1745.07s - 1747.07s | that are using brevity for communication, 1747.07s - 1749.07s | simple things like the length of a message 1749.07s - 1752.07s | become very easy even without going into advanced steps 1752.07s - 1754.07s | to be able to tell what kind of communication may be happening. 1754.07s - 1756.07s | Are they only sending coordinates? 1756.07s - 1757.07s | Are they sending commands? 1757.07s - 1759.07s | Are they just sending comms checks? 1759.07s - 1761.07s | So this starts becoming really important, 1761.07s - 1764.07s | being able to understand these message lengths. 1764.07s - 1765.07s | Yeah, so it's crucial. 1765.07s - 1768.07s | So then let's go look at how they're doing encryption. 1768.07s - 1771.07s | So one form of encryption is encrypting the broadcast. 1771.07s - 1773.07s | So this is the process how it works in the app. 1773.07s - 1774.07s | So we generate the new key. 1774.07s - 1775.07s | We put in the name. 1775.07s - 1777.07s | It can be either broadcast or QR code, 1777.07s - 1778.07s | and we're going to get to that, right? 1778.07s - 1779.07s | That's not important. 1779.07s - 1782.07s | But what we go in is the validation thing. 1782.07s - 1783.07s | It's kind of interesting, right? 1783.07s - 1784.07s | We do this a bunch of times. 1784.07s - 1787.07s | Like, they're kind of short. 1787.07s - 1792.07s | So, and it's all lowercase or numbers, and that's it. 1792.07s - 1793.07s | But there is a space. 1793.07s - 1796.07s | So I guess we have nine, but the space is consistent. 1796.07s - 1798.07s | So, nope, really just eight. 1798.07s - 1801.07s | So you have lowercase numbers, or I'm sorry, 1801.07s - 1802.07s | lowercase letters and numbers, 1802.07s -


chunk_id: 204_chunk_42
chunk_text:
| So then let's go look at how they're doing encryption. 1768.07s - 1771.07s | So one form of encryption is encrypting the broadcast. 1771.07s - 1773.07s | So this is the process how it works in the app. 1773.07s - 1774.07s | So we generate the new key. 1774.07s - 1775.07s | We put in the name. 1775.07s - 1777.07s | It can be either broadcast or QR code, 1777.07s - 1778.07s | and we're going to get to that, right? 1778.07s - 1779.07s | That's not important. 1779.07s - 1782.07s | But what we go in is the validation thing. 1782.07s - 1783.07s | It's kind of interesting, right? 1783.07s - 1784.07s | We do this a bunch of times. 1784.07s - 1787.07s | Like, they're kind of short. 1787.07s - 1792.07s | So, and it's all lowercase or numbers, and that's it. 1792.07s - 1793.07s | But there is a space. 1793.07s - 1796.07s | So I guess we have nine, but the space is consistent. 1796.07s - 1798.07s | So, nope, really just eight. 1798.07s - 1801.07s | So you have lowercase numbers, or I'm sorry, 1801.07s - 1802.07s | lowercase letters and numbers, 1802.07s - 1804.07s | and that's all you have to figure out, 1804.07s - 1805.07s | and you only have to figure out eight of them 1805.07s - 1808.07s | and put a space in the middle for your dictionary. 1808.07s - 1809.07s | Yeah, so very interesting. 1809.07s - 1810.07s | So then we go in. 1810.07s - 1812.07s | Okay, we capture this QR broadcast, right? 1812.07s - 1815.07s | QR broadcast gets sent unencrypted over the air. 1815.07s - 1817.07s | So this key data is actually encrypted, right? 1817.07s - 1819.07s | So what we have here is encrypted. 1819.07s - 1821.07s | But, you know, we do some of our analysis, 1821.07s - 1822.07s | and then long story short, 1822.07s - 1824.07s | to make the fit in the presentation, 1824.07s - 1826.07s | we were able to decrypt it. 1826.07s - 1827.07s | And the nice thing, too, 1827.07s - 1829.07s | is it told us where the IV and the salt was 1829.07s - 1831.07s | because we were able to find where they were. 1831.07s - 1835.07s | So it made it much easier because we knew which was which. 1835.07s - 1839.07s


chunk_id: 204_chunk_43
chunk_text:
1804.07s | and that's all you have to figure out, 1804.07s - 1805.07s | and you only have to figure out eight of them 1805.07s - 1808.07s | and put a space in the middle for your dictionary. 1808.07s - 1809.07s | Yeah, so very interesting. 1809.07s - 1810.07s | So then we go in. 1810.07s - 1812.07s | Okay, we capture this QR broadcast, right? 1812.07s - 1815.07s | QR broadcast gets sent unencrypted over the air. 1815.07s - 1817.07s | So this key data is actually encrypted, right? 1817.07s - 1819.07s | So what we have here is encrypted. 1819.07s - 1821.07s | But, you know, we do some of our analysis, 1821.07s - 1822.07s | and then long story short, 1822.07s - 1824.07s | to make the fit in the presentation, 1824.07s - 1826.07s | we were able to decrypt it. 1826.07s - 1827.07s | And the nice thing, too, 1827.07s - 1829.07s | is it told us where the IV and the salt was 1829.07s - 1831.07s | because we were able to find where they were. 1831.07s - 1835.07s | So it made it much easier because we knew which was which. 1835.07s - 1839.07s | So then, essentially, the key data is fed into the PBKDFHMAC 1839.07s - 1840.07s | with 10,000 iterations. 1840.07s - 1841.07s | This is a very good hashing, 1841.07s - 1844.07s | but it's protected by a state character password. 1844.07s - 1846.07s | So let's say password is known. 1846.07s - 1848.07s | It's going to give us the encryption key. 1848.07s - 1851.07s | And encryption key, along with the IV and the GID, 1851.07s - 1853.07s | can decrypt the ciphertext. 1853.07s - 1856.07s | GID as GCM will give us the plain text and HMAC. 1856.07s - 1859.07s | We also, you know, to be good communications people, 1859.07s - 1860.07s | we can compute our own HMAC 1860.07s - 1862.07s | and verify that message was correct, right? 1862.07s - 1864.07s | So now one may ask, like, 1864.07s - 1867.07s | how complicated is it to get this password? 1867.07s - 1870.07s | So in MD5, this will be very quick. 1870.07s - 1872.07s | PBKDF2 is pretty strong. 1872.07s - 1876.07s | So we do hashcat, and we essentially analyze. 1876.07s - 1878.07s | This is an actual engineering analysis. 1878.07s -


chunk_id: 204_chunk_44
chunk_text:
| So then, essentially, the key data is fed into the PBKDFHMAC 1839.07s - 1840.07s | with 10,000 iterations. 1840.07s - 1841.07s | This is a very good hashing, 1841.07s - 1844.07s | but it's protected by a state character password. 1844.07s - 1846.07s | So let's say password is known. 1846.07s - 1848.07s | It's going to give us the encryption key. 1848.07s - 1851.07s | And encryption key, along with the IV and the GID, 1851.07s - 1853.07s | can decrypt the ciphertext. 1853.07s - 1856.07s | GID as GCM will give us the plain text and HMAC. 1856.07s - 1859.07s | We also, you know, to be good communications people, 1859.07s - 1860.07s | we can compute our own HMAC 1860.07s - 1862.07s | and verify that message was correct, right? 1862.07s - 1864.07s | So now one may ask, like, 1864.07s - 1867.07s | how complicated is it to get this password? 1867.07s - 1870.07s | So in MD5, this will be very quick. 1870.07s - 1872.07s | PBKDF2 is pretty strong. 1872.07s - 1876.07s | So we do hashcat, and we essentially analyze. 1876.07s - 1878.07s | This is an actual engineering analysis. 1878.07s - 1881.07s | So with RTX4090, one card, 1881.07s - 1883.07s | one can figure this out in 15.33 days. 1883.07s - 1886.07s | A very common commercial cracking rig can have 12 of these. 1886.07s - 1889.07s | So in 1.27 days, one can determine this password. 1889.07s - 1892.07s | Now we look at more well-funded adversaries. 1892.07s - 1895.07s | A100 is used by chat GPT, neural nets, AI. 1895.07s - 1897.07s | That's the whole thing now, right? 1897.07s - 1899.07s | This one card is actually worse, right? 1899.07s - 1901.07s | But if you have 10,000 of them, 1901.07s - 1903.07s | you can figure it out in 5.31 seconds. 1903.07s - 1905.07s | It's important to know that all of these times here... 1905.07s - 1907.07s | Minutes. 5.31 minutes. 1907.07s - 1908.07s | It's important to know that all of these 1908.07s - 1910.07s | are kind of worst-case scenarios. 1910.07s - 1912.07s | That means that your script found the password 1912.07s - 1913.07s | the very last time. 1913.07s - 1916.07s | So it's likely it's going to be, like, about half the time. 1916.07s - 1919.07s | So we go


chunk_id: 204_chunk_45
chunk_text:
1881.07s | So with RTX4090, one card, 1881.07s - 1883.07s | one can figure this out in 15.33 days. 1883.07s - 1886.07s | A very common commercial cracking rig can have 12 of these. 1886.07s - 1889.07s | So in 1.27 days, one can determine this password. 1889.07s - 1892.07s | Now we look at more well-funded adversaries. 1892.07s - 1895.07s | A100 is used by chat GPT, neural nets, AI. 1895.07s - 1897.07s | That's the whole thing now, right? 1897.07s - 1899.07s | This one card is actually worse, right? 1899.07s - 1901.07s | But if you have 10,000 of them, 1901.07s - 1903.07s | you can figure it out in 5.31 seconds. 1903.07s - 1905.07s | It's important to know that all of these times here... 1905.07s - 1907.07s | Minutes. 5.31 minutes. 1907.07s - 1908.07s | It's important to know that all of these 1908.07s - 1910.07s | are kind of worst-case scenarios. 1910.07s - 1912.07s | That means that your script found the password 1912.07s - 1913.07s | the very last time. 1913.07s - 1916.07s | So it's likely it's going to be, like, about half the time. 1916.07s - 1919.07s | So we go in, and we can essentially... 1919.07s - 1922.07s | If we know the key, we wrote our little script, 1922.07s - 1923.07s | and then we can decode it. 1923.07s - 1924.07s | We can get the hex key, 1924.07s - 1927.07s | and now we can add this to our automatic decoding script, 1927.07s - 1929.07s | and now we can decrypt live. 1929.07s - 1930.07s | Awesome. 1930.07s - 1931.07s | And we can also decrypt everything 1931.07s - 1932.07s | that happened in the past, so... 1932.07s - 1934.07s | So now we have it all. 1934.07s - 1936.07s | Yeah, but there's more. 1936.07s - 1939.07s | So another form of communication 1939.07s - 1940.07s | is point-to-point, 1940.07s - 1941.07s | and that uses public-key encryption. 1941.07s - 1943.07s | So public-key encryption on its own 1943.07s - 1944.07s | is a lot more secure. 1944.07s - 1947.07s | It uses PKI, or public-key encryption, 1947.07s - 1948.07s | to share the symmetric key. 1948.07s - 1951.07s | It doesn't require any of this manual key sharing. 1951.07s - 1953.07s | However, in our code, 1953.07s - 1956.07s | the message receiver class did not


chunk_id: 204_chunk_46
chunk_text:
in, and we can essentially... 1919.07s - 1922.07s | If we know the key, we wrote our little script, 1922.07s - 1923.07s | and then we can decode it. 1923.07s - 1924.07s | We can get the hex key, 1924.07s - 1927.07s | and now we can add this to our automatic decoding script, 1927.07s - 1929.07s | and now we can decrypt live. 1929.07s - 1930.07s | Awesome. 1930.07s - 1931.07s | And we can also decrypt everything 1931.07s - 1932.07s | that happened in the past, so... 1932.07s - 1934.07s | So now we have it all. 1934.07s - 1936.07s | Yeah, but there's more. 1936.07s - 1939.07s | So another form of communication 1939.07s - 1940.07s | is point-to-point, 1940.07s - 1941.07s | and that uses public-key encryption. 1941.07s - 1943.07s | So public-key encryption on its own 1943.07s - 1944.07s | is a lot more secure. 1944.07s - 1947.07s | It uses PKI, or public-key encryption, 1947.07s - 1948.07s | to share the symmetric key. 1948.07s - 1951.07s | It doesn't require any of this manual key sharing. 1951.07s - 1953.07s | However, in our code, 1953.07s - 1956.07s | the message receiver class did not cleanly decompile, 1956.07s - 1958.07s | so we could spend some time, do that, 1958.07s - 1961.07s | but in help with some Craigslist, eBay, and Freedom, 1961.07s - 1963.07s | maybe we can figure it out without it. 1963.07s - 1966.07s | So initial conversation starts with public-key sharing. 1966.07s - 1968.07s | So here we get the GIDs and the public keys. 1968.07s - 1970.07s | Pretty cool. 1970.07s - 1972.07s | So then we get to the source code. 1972.07s - 1976.07s | We figure out that the public key and the private key 1976.07s - 1979.07s | are generated using ECDH384R1 curve 1979.07s - 1981.07s | to generate the shared key. 1981.07s - 1983.07s | The shared key is used as first input 1983.07s - 1985.07s | to HMAC SHA-256. 1985.07s - 1987.07s | The second input is not known here, 1987.07s - 1989.07s | so we could not figure out what are the parameters here. 1989.07s - 1991.07s | So using Freedom, 1991.07s - 1994.07s | we can essentially intercept this crypto-MACDU final. 1995.07s - 1999.07s | So we essentially instrument this phone right here, 1999.07s - 2001.07s | which is an Android phone. 2001.07s


chunk_id: 204_chunk_47
chunk_text:
cleanly decompile, 1956.07s - 1958.07s | so we could spend some time, do that, 1958.07s - 1961.07s | but in help with some Craigslist, eBay, and Freedom, 1961.07s - 1963.07s | maybe we can figure it out without it. 1963.07s - 1966.07s | So initial conversation starts with public-key sharing. 1966.07s - 1968.07s | So here we get the GIDs and the public keys. 1968.07s - 1970.07s | Pretty cool. 1970.07s - 1972.07s | So then we get to the source code. 1972.07s - 1976.07s | We figure out that the public key and the private key 1976.07s - 1979.07s | are generated using ECDH384R1 curve 1979.07s - 1981.07s | to generate the shared key. 1981.07s - 1983.07s | The shared key is used as first input 1983.07s - 1985.07s | to HMAC SHA-256. 1985.07s - 1987.07s | The second input is not known here, 1987.07s - 1989.07s | so we could not figure out what are the parameters here. 1989.07s - 1991.07s | So using Freedom, 1991.07s - 1994.07s | we can essentially intercept this crypto-MACDU final. 1995.07s - 1999.07s | So we essentially instrument this phone right here, 1999.07s - 2001.07s | which is an Android phone. 2001.07s - 2003.07s | This is connected with Gotenna, 2003.07s - 2005.07s | and then we send a P2P, 2005.07s - 2007.07s | and then we capture this. 2007.07s - 2009.07s | And then from this kind of hex string, 2009.07s - 2011.07s | we can figure out, okay, the second parameter 2011.07s - 2013.07s | is actually concatenated GID, public key, 2013.07s - 2015.07s | and the shared key. 2015.07s - 2017.07s | We do know the public key and the GID. 2017.07s - 2019.07s | We just found that in the slide earlier. 2019.07s - 2021.07s | We don't know the shared key, so let's look for that. 2021.07s - 2023.07s | So we go in the device, and we find the Gotenna folder 2023.07s - 2025.07s | in that same phone, 2025.07s - 2028.07s | and we find something called Gotenna Key Encryption. 2028.07s - 2031.07s | I wonder if that's used for encryption. 2031.07s - 2033.07s | So we go in, and, okay, 2033.07s - 2035.07s | it's using private keys, shared keys, 2035.07s - 2037.07s | but now, to, you know, the best of luck, 2037.07s - 2039.07s | all of this is encrypted, right? 2039.07s


chunk_id: 204_chunk_48
chunk_text:
- 2003.07s | This is connected with Gotenna, 2003.07s - 2005.07s | and then we send a P2P, 2005.07s - 2007.07s | and then we capture this. 2007.07s - 2009.07s | And then from this kind of hex string, 2009.07s - 2011.07s | we can figure out, okay, the second parameter 2011.07s - 2013.07s | is actually concatenated GID, public key, 2013.07s - 2015.07s | and the shared key. 2015.07s - 2017.07s | We do know the public key and the GID. 2017.07s - 2019.07s | We just found that in the slide earlier. 2019.07s - 2021.07s | We don't know the shared key, so let's look for that. 2021.07s - 2023.07s | So we go in the device, and we find the Gotenna folder 2023.07s - 2025.07s | in that same phone, 2025.07s - 2028.07s | and we find something called Gotenna Key Encryption. 2028.07s - 2031.07s | I wonder if that's used for encryption. 2031.07s - 2033.07s | So we go in, and, okay, 2033.07s - 2035.07s | it's using private keys, shared keys, 2035.07s - 2037.07s | but now, to, you know, the best of luck, 2037.07s - 2039.07s | all of this is encrypted, right? 2039.07s - 2041.07s | Fully encrypted. We can't read it. 2041.07s - 2043.07s | But let's verify. 2043.07s - 2045.07s | Okay. 2045.07s - 2047.07s | So we go in, and we find the file that's using 2047.07s - 2049.07s | Gotenna Key Encryption. 2049.07s - 2051.07s | It's encrypted as an IV. 2051.07s - 2053.07s | But we can't tell from that function, 2053.07s - 2055.07s | so we track this over two different functions 2055.07s - 2057.07s | and figure out it's not only used as a static, 2057.07s - 2060.07s | as an IV, it's used as a static IV to AES-GCM. 2060.07s - 2063.07s | So keys are AES-GCM encrypted, 2063.07s - 2066.07s | but static IV allows complete encryption bypass. 2066.07s - 2068.07s | This is when AES is doing what not, 2068.07s - 2070.07s | what AES is not meant to do, right? 2070.07s - 2073.07s | And then using the public key as a known plain text 2073.07s - 2075.07s | and the encrypted public key, 2075.07s - 2077.07s | we can XOR them to get the key stream, 2077.07s - 2079.07s | and we can decrypt essentially everything else. 2079.07s - 2081.07s |


chunk_id: 204_chunk_49
chunk_text:
- 2041.07s | Fully encrypted. We can't read it. 2041.07s - 2043.07s | But let's verify. 2043.07s - 2045.07s | Okay. 2045.07s - 2047.07s | So we go in, and we find the file that's using 2047.07s - 2049.07s | Gotenna Key Encryption. 2049.07s - 2051.07s | It's encrypted as an IV. 2051.07s - 2053.07s | But we can't tell from that function, 2053.07s - 2055.07s | so we track this over two different functions 2055.07s - 2057.07s | and figure out it's not only used as a static, 2057.07s - 2060.07s | as an IV, it's used as a static IV to AES-GCM. 2060.07s - 2063.07s | So keys are AES-GCM encrypted, 2063.07s - 2066.07s | but static IV allows complete encryption bypass. 2066.07s - 2068.07s | This is when AES is doing what not, 2068.07s - 2070.07s | what AES is not meant to do, right? 2070.07s - 2073.07s | And then using the public key as a known plain text 2073.07s - 2075.07s | and the encrypted public key, 2075.07s - 2077.07s | we can XOR them to get the key stream, 2077.07s - 2079.07s | and we can decrypt essentially everything else. 2079.07s - 2081.07s | And what's stored in a database are public keys, 2081.07s - 2083.07s | shared keys, broadcast keys, 2083.07s - 2086.07s | the top two, the pin, pretty much everything. 2086.07s - 2088.07s | So we have a lot of stuff here. 2088.07s - 2091.07s | So then, yeah, there is AES. 2091.07s - 2095.07s | There is. However, there's also 2095.07s - 2098.07s | AES sitting here, and then implementation 2098.07s - 2100.07s | or configuration sitting here. 2100.07s - 2102.07s | This is kind of like having a really nice 2102.07s - 2105.07s | blast-proof, bulletproof door at your house, 2105.07s - 2107.07s | and then realizing that when the bad guys come, 2107.07s - 2109.07s | they just cut a hole through the siding 2109.07s - 2111.07s | and the drywall right next to it. 2111.07s - 2114.07s | Yeah. So let's now summarize this 2114.07s - 2116.07s | just so kind of everybody can be on the same page. 2116.07s - 2118.07s | We get the public key and the public key ciphertext 2118.07s - 2121.07s | in the XML. We XOR them to get the key stream, 2121.07s - 2123.07s | and then we take the


chunk_id: 204_chunk_50
chunk_text:
And what's stored in a database are public keys, 2081.07s - 2083.07s | shared keys, broadcast keys, 2083.07s - 2086.07s | the top two, the pin, pretty much everything. 2086.07s - 2088.07s | So we have a lot of stuff here. 2088.07s - 2091.07s | So then, yeah, there is AES. 2091.07s - 2095.07s | There is. However, there's also 2095.07s - 2098.07s | AES sitting here, and then implementation 2098.07s - 2100.07s | or configuration sitting here. 2100.07s - 2102.07s | This is kind of like having a really nice 2102.07s - 2105.07s | blast-proof, bulletproof door at your house, 2105.07s - 2107.07s | and then realizing that when the bad guys come, 2107.07s - 2109.07s | they just cut a hole through the siding 2109.07s - 2111.07s | and the drywall right next to it. 2111.07s - 2114.07s | Yeah. So let's now summarize this 2114.07s - 2116.07s | just so kind of everybody can be on the same page. 2116.07s - 2118.07s | We get the public key and the public key ciphertext 2118.07s - 2121.07s | in the XML. We XOR them to get the key stream, 2121.07s - 2123.07s | and then we take the key stream and XOR that 2123.07s - 2125.07s | with the private key ciphertext to get the private key. 2125.07s - 2128.07s | Then when we have the public key and the private key, 2128.07s - 2130.07s | we use ECDH to get the shared key. 2130.07s - 2133.07s | Shared key is used within HMAC SHA-256 2133.07s - 2135.07s | along with GID public key and the shared key 2135.07s - 2136.07s | to get the encryption key. 2136.07s - 2138.07s | That, along with the IV and the GID, 2138.07s - 2141.07s | can decrypt the ciphertext of P2P encryption. 2141.07s - 2143.07s | Group encryption is another form of encryption. 2143.07s - 2146.07s | It's the last one that we'll talk about, 2146.07s - 2148.07s | or the last one supported, really. 2148.07s - 2149.07s | So it's using the very same method, 2149.07s - 2152.07s | so same exact attack against P2P works against this, 2152.07s - 2154.07s | and we can show here that we have done it. 2154.07s - 2157.07s | So this is our true vulnerability summary, right, 2157.07s - 2158.07s | of encryption summary finding. 2158.07s - 2160.07s | So broadcast is


chunk_id: 204_chunk_51
chunk_text:
key stream and XOR that 2123.07s - 2125.07s | with the private key ciphertext to get the private key. 2125.07s - 2128.07s | Then when we have the public key and the private key, 2128.07s - 2130.07s | we use ECDH to get the shared key. 2130.07s - 2133.07s | Shared key is used within HMAC SHA-256 2133.07s - 2135.07s | along with GID public key and the shared key 2135.07s - 2136.07s | to get the encryption key. 2136.07s - 2138.07s | That, along with the IV and the GID, 2138.07s - 2141.07s | can decrypt the ciphertext of P2P encryption. 2141.07s - 2143.07s | Group encryption is another form of encryption. 2143.07s - 2146.07s | It's the last one that we'll talk about, 2146.07s - 2148.07s | or the last one supported, really. 2148.07s - 2149.07s | So it's using the very same method, 2149.07s - 2152.07s | so same exact attack against P2P works against this, 2152.07s - 2154.07s | and we can show here that we have done it. 2154.07s - 2157.07s | So this is our true vulnerability summary, right, 2157.07s - 2158.07s | of encryption summary finding. 2158.07s - 2160.07s | So broadcast is vulnerable and allows unauthorized decryption. 2160.07s - 2163.07s | Using setup QR message, which is captured over the air, 2163.07s - 2165.07s | and brute force password, we can decrypt it. 2165.07s - 2167.07s | We can also get it if the phone is compromised 2167.07s - 2169.07s | and we get the key from there. 2169.07s - 2172.07s | P2P and group are both vulnerable to unauthorized decryption 2172.07s - 2174.07s | if, again, the phone is compromised 2174.07s - 2175.07s | and we get some of these. 2175.07s - 2177.07s | So if you want to know the feasibility, 2177.07s - 2179.07s | you can check out our DEF CON talks and things like that 2179.07s - 2181.07s | to sort of really know that. 2181.07s - 2182.07s | There's no authentication public key, 2182.07s - 2184.07s | so man-in-the-middling is possible. 2184.07s - 2185.07s | Short messages, less than one fragment, 2185.07s - 2187.07s | use less secure AES CTR, 2187.07s - 2189.07s | so less than 35, 45 characters 2189.07s - 2191.07s | depending on the message, 2191.07s - 2193.07s | are using CTR, so that has integrity concerns 2193.07s - 2195.07s | even though it


chunk_id: 204_chunk_52
chunk_text:
vulnerable and allows unauthorized decryption. 2160.07s - 2163.07s | Using setup QR message, which is captured over the air, 2163.07s - 2165.07s | and brute force password, we can decrypt it. 2165.07s - 2167.07s | We can also get it if the phone is compromised 2167.07s - 2169.07s | and we get the key from there. 2169.07s - 2172.07s | P2P and group are both vulnerable to unauthorized decryption 2172.07s - 2174.07s | if, again, the phone is compromised 2174.07s - 2175.07s | and we get some of these. 2175.07s - 2177.07s | So if you want to know the feasibility, 2177.07s - 2179.07s | you can check out our DEF CON talks and things like that 2179.07s - 2181.07s | to sort of really know that. 2181.07s - 2182.07s | There's no authentication public key, 2182.07s - 2184.07s | so man-in-the-middling is possible. 2184.07s - 2185.07s | Short messages, less than one fragment, 2185.07s - 2187.07s | use less secure AES CTR, 2187.07s - 2189.07s | so less than 35, 45 characters 2189.07s - 2191.07s | depending on the message, 2191.07s - 2193.07s | are using CTR, so that has integrity concerns 2193.07s - 2195.07s | even though it is encrypted. 2195.07s - 2198.07s | And then longer messages use more secure GCM, 2198.07s - 2201.07s | but you need to be sending, like, 50 characters to get to that. 2201.07s - 2203.07s | So we also, you know, 2203.07s - 2207.07s | we could also transmit directly from our GNU radio. 2207.07s - 2209.07s | We can spoof GID call sign, the message. 2209.07s - 2211.07s | We can get into the existing... 2211.07s - 2216.07s | So I could take a HackRF or an NS or a Blade 2216.07s - 2220.07s | and I can actually make my own Gotenna out of it. 2220.07s - 2221.07s | Yeah. 2221.07s - 2222.07s | And just start using my computer. 2222.07s - 2225.07s | We also added support for Wireshark, 2225.07s - 2228.07s | so we have essentially that, 2228.07s - 2230.07s | so all the messages are fed into Wireshark. 2230.07s - 2231.07s | We don't have the decode there currently, 2231.07s - 2234.07s | but we'll add it eventually. 2234.07s - 2236.07s | So now let's get to live demos. 2236.07s - 2238.07s | So if you have a Gotenna Pro, 2238.07s - 2240.07s | then you


chunk_id: 204_chunk_53
chunk_text:
is encrypted. 2195.07s - 2198.07s | And then longer messages use more secure GCM, 2198.07s - 2201.07s | but you need to be sending, like, 50 characters to get to that. 2201.07s - 2203.07s | So we also, you know, 2203.07s - 2207.07s | we could also transmit directly from our GNU radio. 2207.07s - 2209.07s | We can spoof GID call sign, the message. 2209.07s - 2211.07s | We can get into the existing... 2211.07s - 2216.07s | So I could take a HackRF or an NS or a Blade 2216.07s - 2220.07s | and I can actually make my own Gotenna out of it. 2220.07s - 2221.07s | Yeah. 2221.07s - 2222.07s | And just start using my computer. 2222.07s - 2225.07s | We also added support for Wireshark, 2225.07s - 2228.07s | so we have essentially that, 2228.07s - 2230.07s | so all the messages are fed into Wireshark. 2230.07s - 2231.07s | We don't have the decode there currently, 2231.07s - 2234.07s | but we'll add it eventually. 2234.07s - 2236.07s | So now let's get to live demos. 2236.07s - 2238.07s | So if you have a Gotenna Pro, 2238.07s - 2240.07s | then you can get the frequency on the left 2240.07s - 2242.07s | and the encryption in the middle 2242.07s - 2243.07s | and validation on the right. 2243.07s - 2246.07s | So we have six minutes, so let's be quick. 2248.07s - 2249.07s | I wouldn't scan it, 2249.07s - 2257.86s | because we're both sketchy guys, but still. 2257.86s - 2258.86s | So it's firing up live right now. 2258.86s - 2260.86s | He's just turning the program on. 2260.86s - 2263.86s | You can see it's already starting to sniff and listen. 2263.86s - 2265.86s | We like to have a little waterfall 2265.86s - 2267.86s | so we can see when we are or are not capturing. 2267.86s - 2269.86s | Now he's going to send a message, 2269.86s - 2271.86s | and there you go. 2271.86s - 2281.09s | There we go. 2283.09s - 2284.09s | We have enough time, 2284.09s - 2286.09s | so let's see if we can decrypt something. 2287.09s - 2290.09s | So now being able to do the same type of process 2290.09s - 2292.09s | for an encrypted message. 2292.09s - 2293.09s | So that was a broadcast. 2293.09s - 2294.09s


chunk_id: 204_chunk_54
chunk_text:
can get the frequency on the left 2240.07s - 2242.07s | and the encryption in the middle 2242.07s - 2243.07s | and validation on the right. 2243.07s - 2246.07s | So we have six minutes, so let's be quick. 2248.07s - 2249.07s | I wouldn't scan it, 2249.07s - 2257.86s | because we're both sketchy guys, but still. 2257.86s - 2258.86s | So it's firing up live right now. 2258.86s - 2260.86s | He's just turning the program on. 2260.86s - 2263.86s | You can see it's already starting to sniff and listen. 2263.86s - 2265.86s | We like to have a little waterfall 2265.86s - 2267.86s | so we can see when we are or are not capturing. 2267.86s - 2269.86s | Now he's going to send a message, 2269.86s - 2271.86s | and there you go. 2271.86s - 2281.09s | There we go. 2283.09s - 2284.09s | We have enough time, 2284.09s - 2286.09s | so let's see if we can decrypt something. 2287.09s - 2290.09s | So now being able to do the same type of process 2290.09s - 2292.09s | for an encrypted message. 2292.09s - 2293.09s | So that was a broadcast. 2293.09s - 2294.09s | Now broadcast means it's sent out 2294.09s - 2296.09s | so that anyone that has one of these devices 2296.09s - 2298.09s | is able to catch it. 2298.09s - 2300.09s | It's meant for an emergency situation 2300.09s - 2302.09s | or you're just looking for other people around you, 2302.09s - 2305.09s | but the next step is 2305.09s - 2307.09s | all those things we talked about 2307.09s - 2308.09s | by combining that information, 2308.09s - 2311.09s | can you take an encrypted message 2311.09s - 2313.09s | for a group or a person-to-person 2313.09s - 2316.09s | and actually decrypt and see it? 2316.09s - 2318.09s | So when you think about this, 2318.09s - 2320.09s | this is where everyone feels safe. 2320.09s - 2321.09s | Oh, yeah. 2321.09s - 2324.14s | One second here. 2324.14s - 2344.22s | So while we're going through this, 2344.22s - 2345.22s | he's going to set the demo up. 2345.22s - 2348.22s | You're going to be able to see it. 2348.22s - 2353.84s | And we'll go ahead. 2353.84s - 2355.84s | Are there any questions right now 2355.84s - 2357.84s | while he's setting


chunk_id: 204_chunk_55
chunk_text:
| Now broadcast means it's sent out 2294.09s - 2296.09s | so that anyone that has one of these devices 2296.09s - 2298.09s | is able to catch it. 2298.09s - 2300.09s | It's meant for an emergency situation 2300.09s - 2302.09s | or you're just looking for other people around you, 2302.09s - 2305.09s | but the next step is 2305.09s - 2307.09s | all those things we talked about 2307.09s - 2308.09s | by combining that information, 2308.09s - 2311.09s | can you take an encrypted message 2311.09s - 2313.09s | for a group or a person-to-person 2313.09s - 2316.09s | and actually decrypt and see it? 2316.09s - 2318.09s | So when you think about this, 2318.09s - 2320.09s | this is where everyone feels safe. 2320.09s - 2321.09s | Oh, yeah. 2321.09s - 2324.14s | One second here. 2324.14s - 2344.22s | So while we're going through this, 2344.22s - 2345.22s | he's going to set the demo up. 2345.22s - 2348.22s | You're going to be able to see it. 2348.22s - 2353.84s | And we'll go ahead. 2353.84s - 2355.84s | Are there any questions right now 2355.84s - 2357.84s | while he's setting this up? 2357.84s - 2358.84s | We have a minute or so. 2358.84s - 2363.84s | Any questions over anything that we've seen so far? 2363.84s - 2365.84s | Okay. 2365.84s - 2369.22s | Here we go. 2369.22s - 2371.22s | Now one of the things that I want to make sure 2371.22s - 2372.22s | that we cover in this is that 2372.22s - 2374.22s | when we reached out to Gotenna 2374.22s - 2376.22s | for the version 1 exploit, 2376.22s - 2379.22s | they had zero response 2379.22s - 2380.22s | other than the fact they said, 2380.22s - 2382.22s | that's fine, we don't care. 2382.22s - 2383.22s | Under the new management, 2383.22s - 2385.22s | Gotenna was extremely receptive. 2385.22s - 2387.22s | We got a call back within one day. 2387.22s - 2390.22s | They were happy to take the advice 2390.22s - 2391.22s | that we gave them 2391.22s - 2393.22s | and they are actively working 2393.22s - 2395.22s | to try to fix these issues. 2395.22s - 2397.22s | That's why we are going to make sure 2397.22s - 2399.22s | we wait at least two months from today 2399.22s


chunk_id: 204_chunk_56
chunk_text:
this up? 2357.84s - 2358.84s | We have a minute or so. 2358.84s - 2363.84s | Any questions over anything that we've seen so far? 2363.84s - 2365.84s | Okay. 2365.84s - 2369.22s | Here we go. 2369.22s - 2371.22s | Now one of the things that I want to make sure 2371.22s - 2372.22s | that we cover in this is that 2372.22s - 2374.22s | when we reached out to Gotenna 2374.22s - 2376.22s | for the version 1 exploit, 2376.22s - 2379.22s | they had zero response 2379.22s - 2380.22s | other than the fact they said, 2380.22s - 2382.22s | that's fine, we don't care. 2382.22s - 2383.22s | Under the new management, 2383.22s - 2385.22s | Gotenna was extremely receptive. 2385.22s - 2387.22s | We got a call back within one day. 2387.22s - 2390.22s | They were happy to take the advice 2390.22s - 2391.22s | that we gave them 2391.22s - 2393.22s | and they are actively working 2393.22s - 2395.22s | to try to fix these issues. 2395.22s - 2397.22s | That's why we are going to make sure 2397.22s - 2399.22s | we wait at least two months from today 2399.22s - 2401.22s | before we release the full code publicly, 2401.22s - 2403.22s | but then we will. 2403.22s - 2404.22s | Now for Gen 1 and 2, 2404.22s - 2407.22s | the code's already out there. 2407.22s - 2408.22s | Okay, so now we're ready. 2408.22s - 2410.22s | So I'm going to send something encrypted 2410.22s - 2411.22s | just so we can see that messages 2411.22s - 2412.22s | are indeed encrypted. 2412.22s - 2415.22s | So we can see they're encrypted now. 2415.22s - 2431.46s | Now this part here decrypted. 2431.46s - 2434.46s | So this was added to our local database. 2434.46s - 2436.46s | So we're going to run our script again. 2436.46s - 2437.46s | So this is going to now 2437.46s - 2440.46s | pull the keys from there immediately. 2440.46s - 2442.46s | And then we will transmit again. 2442.46s - 2449.74s | Boom, this was encrypted. 2449.74s - 2453.05s | So now it's full circle. 2453.05s - 2461.74s | So, you know, live demos are something 2461.74s - 2463.74s | that I'm a big fan of. 2463.74s - 2466.74s | So Erwin did an amazing job 2466.74s - 2468.74s


chunk_id: 204_chunk_57
chunk_text:
- 2401.22s | before we release the full code publicly, 2401.22s - 2403.22s | but then we will. 2403.22s - 2404.22s | Now for Gen 1 and 2, 2404.22s - 2407.22s | the code's already out there. 2407.22s - 2408.22s | Okay, so now we're ready. 2408.22s - 2410.22s | So I'm going to send something encrypted 2410.22s - 2411.22s | just so we can see that messages 2411.22s - 2412.22s | are indeed encrypted. 2412.22s - 2415.22s | So we can see they're encrypted now. 2415.22s - 2431.46s | Now this part here decrypted. 2431.46s - 2434.46s | So this was added to our local database. 2434.46s - 2436.46s | So we're going to run our script again. 2436.46s - 2437.46s | So this is going to now 2437.46s - 2440.46s | pull the keys from there immediately. 2440.46s - 2442.46s | And then we will transmit again. 2442.46s - 2449.74s | Boom, this was encrypted. 2449.74s - 2453.05s | So now it's full circle. 2453.05s - 2461.74s | So, you know, live demos are something 2461.74s - 2463.74s | that I'm a big fan of. 2463.74s - 2466.74s | So Erwin did an amazing job 2466.74s - 2468.74s | of writing all this crazy code. 2468.74s - 2471.74s | I don't want anyone to misconstrue that. 2471.74s - 2473.74s | The big thing that we want to make sure 2473.74s - 2475.74s | that everyone takes away from this 2475.74s - 2479.74s | is it is up to everyone in this community 2479.74s - 2481.74s | to test equipment. 2481.74s - 2483.74s | Just because something says it's secure, 2483.74s - 2484.74s | don't believe it. 2484.74s - 2485.74s | Challenge it. 2485.74s - 2486.74s | And when you find it, 2486.74s - 2488.74s | see if the manufacturer's willing to listen. 2488.74s - 2489.74s | Occasionally they are. 2489.74s - 2490.74s | Gotenna was. 2490.74s - 2492.74s | Most of the ones I've dealt with aren't. 2492.74s - 2495.74s | So if something's been done in the past, 2495.74s - 2497.74s | don't be afraid to try to recreate it 2497.74s - 2498.74s | when something new comes out. 2498.74s - 2500.74s | You might find that they didn't change 2500.74s - 2501.74s | a lot of the things 2501.74s - 2502.74s | and then you can move forward 2502.74s - 2504.74s | and do well with


chunk_id: 204_chunk_58
chunk_text:
| of writing all this crazy code. 2468.74s - 2471.74s | I don't want anyone to misconstrue that. 2471.74s - 2473.74s | The big thing that we want to make sure 2473.74s - 2475.74s | that everyone takes away from this 2475.74s - 2479.74s | is it is up to everyone in this community 2479.74s - 2481.74s | to test equipment. 2481.74s - 2483.74s | Just because something says it's secure, 2483.74s - 2484.74s | don't believe it. 2484.74s - 2485.74s | Challenge it. 2485.74s - 2486.74s | And when you find it, 2486.74s - 2488.74s | see if the manufacturer's willing to listen. 2488.74s - 2489.74s | Occasionally they are. 2489.74s - 2490.74s | Gotenna was. 2490.74s - 2492.74s | Most of the ones I've dealt with aren't. 2492.74s - 2495.74s | So if something's been done in the past, 2495.74s - 2497.74s | don't be afraid to try to recreate it 2497.74s - 2498.74s | when something new comes out. 2498.74s - 2500.74s | You might find that they didn't change 2500.74s - 2501.74s | a lot of the things 2501.74s - 2502.74s | and then you can move forward 2502.74s - 2504.74s | and do well with it. 2504.74s - 2507.74s | Yep, so let's talk about join. 2507.74s - 2508.74s | I mean, you already mentioned this, 2508.74s - 2510.74s | so they were very receptive. 2510.74s - 2514.89s | And yeah, the conclusion. 2514.89s - 2518.89s | Yeah, so the big things we wanted to say about this is, 2518.89s - 2520.89s | you know, we reached out to industry. 2520.89s - 2522.89s | We were able to have a good relationship 2522.89s - 2523.89s | with them doing this. 2523.89s - 2525.89s | They took away key points, 2525.89s - 2527.89s | acknowledgments of what we want to make sure 2527.89s - 2528.89s | we talk about here. 2528.89s - 2530.89s | So we want to reach out to White Shadow 2530.89s - 2531.89s | who unfortunately couldn't be here 2531.89s - 2534.89s | because he's actually doing some responsible things 2534.89s - 2535.89s | for his family, 2535.89s - 2536.89s | but he is going to be here later. 2536.89s - 2538.89s | But don't tell him I said anything nice. 2538.89s - 2539.89s | What the Freak, 2539.89s - 2541.89s | which is the wireless CTF team 2541.89s - 2542.89s | that-


chunk_id: 204_chunk_59
chunk_text:
it. 2504.74s - 2507.74s | Yep, so let's talk about join. 2507.74s - 2508.74s | I mean, you already mentioned this, 2508.74s - 2510.74s | so they were very receptive. 2510.74s - 2514.89s | And yeah, the conclusion. 2514.89s - 2518.89s | Yeah, so the big things we wanted to say about this is, 2518.89s - 2520.89s | you know, we reached out to industry. 2520.89s - 2522.89s | We were able to have a good relationship 2522.89s - 2523.89s | with them doing this. 2523.89s - 2525.89s | They took away key points, 2525.89s - 2527.89s | acknowledgments of what we want to make sure 2527.89s - 2528.89s | we talk about here. 2528.89s - 2530.89s | So we want to reach out to White Shadow 2530.89s - 2531.89s | who unfortunately couldn't be here 2531.89s - 2534.89s | because he's actually doing some responsible things 2534.89s - 2535.89s | for his family, 2535.89s - 2536.89s | but he is going to be here later. 2536.89s - 2538.89s | But don't tell him I said anything nice. 2538.89s - 2539.89s | What the Freak, 2539.89s - 2541.89s | which is the wireless CTF team 2541.89s - 2542.89s | that- 2542.89s - 2543.89s | Let's do a shout. 2543.89s - 2544.89s | We got a win today. 2544.89s - 2546.89s | Which I'm glad they're here 2546.89s - 2547.89s | because now all the other teams 2547.89s - 2548.89s | are jumping ahead of them. 2548.89s - 2549.89s | Yep. 2549.89s - 2551.89s | So we also want to thank EFF and CISA. 2551.89s - 2554.89s | Both of them were amazing organizations 2554.89s - 2555.89s | and very easy to work with. 2555.89s - 2557.89s | The RF Hacker Sanctuary, 2557.89s - 2558.89s | please go there. 2558.89s - 2559.89s | Try some challenges. 2559.89s - 2561.89s | It's everything from Wi-Fi, 2561.89s - 2562.89s | Bluetooth, 2562.89s - 2563.89s | tire pressure sensors, 2563.89s - 2564.89s | Go Tennis. 2564.89s - 2566.89s | All of these challenges will be there as well 2566.89s - 2567.89s | for you to solve 2567.89s - 2568.89s | for all the Go Tennis stuff. 2569.89s - 2570.89s | We want to make sure that, 2570.89s - 2571.89s | you know- 2571.89s - 2572.89s | Yeah. 2572.89s - 2573.89s | Jason Rojas and Cisco Systems. 2573.89s - 2574.89s | I want to thank


chunk_id: 204_chunk_60
chunk_text:
2542.89s - 2543.89s | Let's do a shout. 2543.89s - 2544.89s | We got a win today. 2544.89s - 2546.89s | Which I'm glad they're here 2546.89s - 2547.89s | because now all the other teams 2547.89s - 2548.89s | are jumping ahead of them. 2548.89s - 2549.89s | Yep. 2549.89s - 2551.89s | So we also want to thank EFF and CISA. 2551.89s - 2554.89s | Both of them were amazing organizations 2554.89s - 2555.89s | and very easy to work with. 2555.89s - 2557.89s | The RF Hacker Sanctuary, 2557.89s - 2558.89s | please go there. 2558.89s - 2559.89s | Try some challenges. 2559.89s - 2561.89s | It's everything from Wi-Fi, 2561.89s - 2562.89s | Bluetooth, 2562.89s - 2563.89s | tire pressure sensors, 2563.89s - 2564.89s | Go Tennis. 2564.89s - 2566.89s | All of these challenges will be there as well 2566.89s - 2567.89s | for you to solve 2567.89s - 2568.89s | for all the Go Tennis stuff. 2569.89s - 2570.89s | We want to make sure that, 2570.89s - 2571.89s | you know- 2571.89s - 2572.89s | Yeah. 2572.89s - 2573.89s | Jason Rojas and Cisco Systems. 2573.89s - 2574.89s | I want to thank them 2574.89s - 2576.89s | for making my trip here possible 2576.89s - 2577.89s | and Potify Media 2577.89s - 2578.89s | for making this team 2578.89s - 2579.89s | for this presentation. 2579.89s - 2580.89s | And Buffalo Trace 2580.89s - 2581.89s | because without them 2581.89s - 2582.89s | I probably wouldn't get done 2582.89s - 2583.89s | as much work as I do. 2584.89s - 2588.10s | Thank you for your time. 2588.10s - 2589.10s | Are there any questions? 2590.10s - 2595.10s | Well, thank you and enjoy the con.


chunk_id: 204_chunk_61
chunk_text:
them 2574.89s - 2576.89s | for making my trip here possible 2576.89s - 2577.89s | and Potify Media 2577.89s - 2578.89s | for making this team 2578.89s - 2579.89s | for this presentation. 2579.89s - 2580.89s | And Buffalo Trace 2580.89s - 2581.89s | because without them 2581.89s - 2582.89s | I probably wouldn't get done 2582.89s - 2583.89s | as much work as I do. 2584.89s - 2588.10s | Thank you for your time. 2588.10s - 2589.10s | Are there any questions? 2590.10s - 2595.10s | Well, thank you and enjoy the con.


chunk_id: 205_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=IUEjbuiAX18", "title": "DEF CON 32 - Fireside Chat - The Dark Tangent and National Cyber Director Harry Coker, Jr", "description": "The world increasingly appreciates how much we rely on space systems for our personal, economic, and national security needs. However, the nation-state cyber threat to government and commercial systems continues to grow at a time when the current landscape of cybersecurity policies and frameworks aren\u2019t readily applicable for space systems.\n\nIn this fireside chat, ONCD will have the opportunity to introduce our 2nd National Cyber Director to the research community and discuss some of his priorities, such as space cybersecurity. We will discuss how the White House has been working to tackle hard problems and challenges. In the instance of space cybersecurity, ONCD has been collaborating with federal space operators and the space industry to develop policy solutions, including by answering a tasking from the Vice President to develop minimum cybersecurity requirements for U.S. space systems.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2702, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 7.04s | This text was transcribed using whisper model: large-v2 great to see everyone. Um, DEF CON noobs, keep drinking water, take care of yourself. Um, I'm 7.04s - 13.42s | Jason Healy. I was asked to moderate this far side chat with the director of your United 13.42s - 18.32s | States, um, Office of the National Cyber Director. So today we have, um, Director Harry 18.32s - 22.52s | Coker, who we're going to be having a far side chat with. My name is Jason Healy. I get 22.52s - 27.96s | asked to do this. Um, I've been on the DEF CON review board for about ten years. So we're 27.96s - 32.06s | CFP and review all of the talks that come through. I've also been at the White House twice, 32.06s - 38.80s | 2003, 2005, and also to help set up the, um, the Office of the National Cyber Director. Um, 38.80s - 43.64s | so Harry's gonna come out. He's got some, um, uh, some initial remarks and then we'll just 43.64s - 47.88s | dive right into the comments. So, um, he's got an amazing bio we're not gonna cover, but 47.88s - 51.62s | to, please do be checking it out. Um, and with that, Harry. 59.72s - 79.62s | Thanks, Jerry. First things first, as I tell all the bartenders


chunk_id: 205_chunk_1
chunk_text:
| Jason Healy. I was asked to moderate this far side chat with the director of your United 13.42s - 18.32s | States, um, Office of the National Cyber Director. So today we have, um, Director Harry 18.32s - 22.52s | Coker, who we're going to be having a far side chat with. My name is Jason Healy. I get 22.52s - 27.96s | asked to do this. Um, I've been on the DEF CON review board for about ten years. So we're 27.96s - 32.06s | CFP and review all of the talks that come through. I've also been at the White House twice, 32.06s - 38.80s | 2003, 2005, and also to help set up the, um, the Office of the National Cyber Director. Um, 38.80s - 43.64s | so Harry's gonna come out. He's got some, um, uh, some initial remarks and then we'll just 43.64s - 47.88s | dive right into the comments. So, um, he's got an amazing bio we're not gonna cover, but 47.88s - 51.62s | to, please do be checking it out. Um, and with that, Harry. 59.72s - 79.62s | Thanks, Jerry. First things first, as I tell all the bartenders I work with, pour it like 79.62s - 85.22s | you don't own it. So that's what I did. But that actually came from, uh, the military 85.22s - 93.14s | cyber, uh, professional association. So that is cyber bourbon. Um, I have somewhere around 93.14s - 101.18s | 70. Uh, bought a barrel, but on to why we're here. Sorry. Uh, thanks, Jay. Um, it's a pleasure 101.18s - 106.50s | to be here and actually it's my first time at DEF CON as you, um, you've noticed. Uh, 106.50s - 111.50s | but as a scotch drinker myself, I'm a bit disappointed that all of my speeches don't 111.50s - 116.26s | start this way. Um, but perhaps this will be another tradition that we, uh, bring forth 116.26s - 122.30s | at, uh, ONCD. All right. Looking forward to our conversation, Jay, uh, where we'll dig 122.34s - 128.70s | into memory safety, uh, BGP security, firmware, vulnerability, and open source software. All 128.70s - 135.14s | of the nuanced and technical topics that make Hacker Summer Camp such a draw, even in this 135.14s - 140.54s | new venue. Uh, but before we get into the


chunk_id: 205_chunk_2
chunk_text:
I work with, pour it like 79.62s - 85.22s | you don't own it. So that's what I did. But that actually came from, uh, the military 85.22s - 93.14s | cyber, uh, professional association. So that is cyber bourbon. Um, I have somewhere around 93.14s - 101.18s | 70. Uh, bought a barrel, but on to why we're here. Sorry. Uh, thanks, Jay. Um, it's a pleasure 101.18s - 106.50s | to be here and actually it's my first time at DEF CON as you, um, you've noticed. Uh, 106.50s - 111.50s | but as a scotch drinker myself, I'm a bit disappointed that all of my speeches don't 111.50s - 116.26s | start this way. Um, but perhaps this will be another tradition that we, uh, bring forth 116.26s - 122.30s | at, uh, ONCD. All right. Looking forward to our conversation, Jay, uh, where we'll dig 122.34s - 128.70s | into memory safety, uh, BGP security, firmware, vulnerability, and open source software. All 128.70s - 135.14s | of the nuanced and technical topics that make Hacker Summer Camp such a draw, even in this 135.14s - 140.54s | new venue. Uh, but before we get into the hard problems that really define our work 140.54s - 144.30s | at the, uh, White House Office of National Cyber Director, I want to say a few words 144.30s - 150.54s | about the importance of this community to our effort to make our nation safer, um, more 151.18s - 157.62s | innovative, and prosperous. Uh, this is my first DEF CON. Again, as you noticed, uh, by my 157.62s - 163.70s | baptism, uh, by this bourbon. And actually it shouldn't be a tradition just for first timers. 163.70s - 168.54s | Um, but while I have been thoroughly impressed by the people, the presentations, and 168.54s - 173.50s | actually, uh, some policy proposals that I've seen over the past couple of days, uh, I 173.50s - 179.30s | cannot say that I'm surprised. Uh, from my early exposure to coding as a computer science 179.30s - 186.10s | graduate student, um, to my time collaborating with reverse engineers, uh, and colleagues 186.10s - 191.54s | in the intelligence community, to arriving at the White House, I've known how special, uh, 191.54s - 198.46s | the security research community is. Special, but often misunderstood. Uh, as a society,


chunk_id: 205_chunk_3
chunk_text:
hard problems that really define our work 140.54s - 144.30s | at the, uh, White House Office of National Cyber Director, I want to say a few words 144.30s - 150.54s | about the importance of this community to our effort to make our nation safer, um, more 151.18s - 157.62s | innovative, and prosperous. Uh, this is my first DEF CON. Again, as you noticed, uh, by my 157.62s - 163.70s | baptism, uh, by this bourbon. And actually it shouldn't be a tradition just for first timers. 163.70s - 168.54s | Um, but while I have been thoroughly impressed by the people, the presentations, and 168.54s - 173.50s | actually, uh, some policy proposals that I've seen over the past couple of days, uh, I 173.50s - 179.30s | cannot say that I'm surprised. Uh, from my early exposure to coding as a computer science 179.30s - 186.10s | graduate student, um, to my time collaborating with reverse engineers, uh, and colleagues 186.10s - 191.54s | in the intelligence community, to arriving at the White House, I've known how special, uh, 191.54s - 198.46s | the security research community is. Special, but often misunderstood. Uh, as a society, we 198.46s - 204.74s | are predisposed to celebrate builders, uh, inventors, engineers, the titans of industries. 204.74s - 210.90s | All are lauded for what they've designed and constructed. So it can be quite jarring to hear 210.90s - 217.98s | about a culture where tinkering is turned to, to brick, turn toward breaking things, albeit to 217.98s - 224.58s | make them stronger. Where rather than synthesis and cohesion, we talk about decompiling code 224.58s - 230.46s | to find its weaknesses. Where manipulating people in the form of social engineering is 230.50s - 235.86s | venerated as a way of finding the weak points in a system. And if there's one place in the 235.86s - 242.34s | world where these concepts are particularly foreign, it's Washington, D.C. Our elected 242.34s - 248.34s | officials and our civil servants swear an oath to protect and defend the Constitution, and 248.34s - 255.18s | it is far from intuitive, uh, to how hacking could possibly be in that interest. I can see 255.18s - 260.90s | where they're coming from, uh, but my personal experiences urge me to challenge them to think a 260.90s - 267.82s | bit


chunk_id: 205_chunk_4
chunk_text:
we 198.46s - 204.74s | are predisposed to celebrate builders, uh, inventors, engineers, the titans of industries. 204.74s - 210.90s | All are lauded for what they've designed and constructed. So it can be quite jarring to hear 210.90s - 217.98s | about a culture where tinkering is turned to, to brick, turn toward breaking things, albeit to 217.98s - 224.58s | make them stronger. Where rather than synthesis and cohesion, we talk about decompiling code 224.58s - 230.46s | to find its weaknesses. Where manipulating people in the form of social engineering is 230.50s - 235.86s | venerated as a way of finding the weak points in a system. And if there's one place in the 235.86s - 242.34s | world where these concepts are particularly foreign, it's Washington, D.C. Our elected 242.34s - 248.34s | officials and our civil servants swear an oath to protect and defend the Constitution, and 248.34s - 255.18s | it is far from intuitive, uh, to how hacking could possibly be in that interest. I can see 255.18s - 260.90s | where they're coming from, uh, but my personal experiences urge me to challenge them to think a 260.90s - 267.82s | bit deeper. Uh, to understand that for folks in this community, the desire to make things, to 267.82s - 273.26s | take things apart, is rooted in a hope that they will be made stronger. Uh, to recognize that the 273.26s - 280.26s | internet, decentralized, governed largely by a simple set of rules written decades ago, is a 280.26s - 287.66s | miracle of human ingenuity. And that miraculous, as it may be, the internet also needs 287.66s - 293.90s | protecting. That ethos of trying to make the internet a safer place is what makes this 293.90s - 299.42s | community so important and vital to our way of life. It's why it's so important for me to have 299.42s - 305.14s | made this pilgrimage out to the desert, along with so many of our cyber colleagues. And I've got 305.14s - 311.34s | good news for you. My voice is not alone in Washington. The chorus is growing. Jay, I know 311.34s - 316.70s | that when you were actually serving on the National Security Council staff decades ago, uh, you 316.70s - 323.58s | weren't even allowed to come to DEF CON. Today, not only are


chunk_id: 205_chunk_5
chunk_text:
deeper. Uh, to understand that for folks in this community, the desire to make things, to 267.82s - 273.26s | take things apart, is rooted in a hope that they will be made stronger. Uh, to recognize that the 273.26s - 280.26s | internet, decentralized, governed largely by a simple set of rules written decades ago, is a 280.26s - 287.66s | miracle of human ingenuity. And that miraculous, as it may be, the internet also needs 287.66s - 293.90s | protecting. That ethos of trying to make the internet a safer place is what makes this 293.90s - 299.42s | community so important and vital to our way of life. It's why it's so important for me to have 299.42s - 305.14s | made this pilgrimage out to the desert, along with so many of our cyber colleagues. And I've got 305.14s - 311.34s | good news for you. My voice is not alone in Washington. The chorus is growing. Jay, I know 311.34s - 316.70s | that when you were actually serving on the National Security Council staff decades ago, uh, you 316.70s - 323.58s | weren't even allowed to come to DEF CON. Today, not only are the feds here in force to learn and 323.58s - 330.52s | to celebrate the work of this community, we are recruiting. One of the key projects that we 330.52s - 335.16s | launched at the Office of the National Cyber Director, uh, was a white paper focused on memory 335.16s - 342.28s | safety titled, Back to the Building Blocks. I will admit to being a, a bit surprised to see such a 342.28s - 347.32s | technical product come out of the White House. Yet after reviewing the report and learning about 347.32s - 353.96s | the research and consultation underlying it, I was completely convinced that it was vital that the 353.96s - 358.56s | White House shine a spotlight on the need to adopt solutions on the most critical 358.56s - 365.54s | vulnerabilities. The White House endorsing formal mess methods is now a bit of a meme, and I could 365.54s - 372.00s | not be happier. These are outward signs of progress. At least as important, though, is a 372.00s - 377.84s | cultural change happening in Washington. For the first time, we are seeing policymakers consider 377.84s - 383.36s | how to leverage


chunk_id: 205_chunk_6
chunk_text:
the feds here in force to learn and 323.58s - 330.52s | to celebrate the work of this community, we are recruiting. One of the key projects that we 330.52s - 335.16s | launched at the Office of the National Cyber Director, uh, was a white paper focused on memory 335.16s - 342.28s | safety titled, Back to the Building Blocks. I will admit to being a, a bit surprised to see such a 342.28s - 347.32s | technical product come out of the White House. Yet after reviewing the report and learning about 347.32s - 353.96s | the research and consultation underlying it, I was completely convinced that it was vital that the 353.96s - 358.56s | White House shine a spotlight on the need to adopt solutions on the most critical 358.56s - 365.54s | vulnerabilities. The White House endorsing formal mess methods is now a bit of a meme, and I could 365.54s - 372.00s | not be happier. These are outward signs of progress. At least as important, though, is a 372.00s - 377.84s | cultural change happening in Washington. For the first time, we are seeing policymakers consider 377.84s - 383.36s | how to leverage unique aspects of the security research community to solve some of the very 383.36s - 390.36s | hardest problems in cyber security. Some of that is manifesting at the operational level as 390.36s - 397.96s | collaboration, not simply information sharing. And that has been increasingly the norm at NSA's 397.96s - 404.80s | Cyber Security Collaboration Center and CISA's Joint Cyber Defense Collaborative. And it does 404.80s - 411.94s | extend to more strategic proposals, too. Just yesterday, ONCD and our partners in the 411.94s - 418.22s | government's Open Source Software Security Initiative released a report summarizing key 418.22s - 424.38s | findings from a request for information that we announced right here at last year's DEF CON. 424.38s - 430.74s | Importantly, that summary also describes actions that we are taking in response to the feedback from 430.74s - 438.30s | this community. Some of those actions are inherently governmental. For instance, we are proud to 438.30s - 444.82s | announce that the Department of Homeland Security has committed $11 million from the bipartisan 444.82s - 451.42s | infrastructure law to launch the Open Source Software Prevalence Initiative. Along with partners 451.42s - 456.70s | at our


chunk_id: 205_chunk_7
chunk_text:
unique aspects of the security research community to solve some of the very 383.36s - 390.36s | hardest problems in cyber security. Some of that is manifesting at the operational level as 390.36s - 397.96s | collaboration, not simply information sharing. And that has been increasingly the norm at NSA's 397.96s - 404.80s | Cyber Security Collaboration Center and CISA's Joint Cyber Defense Collaborative. And it does 404.80s - 411.94s | extend to more strategic proposals, too. Just yesterday, ONCD and our partners in the 411.94s - 418.22s | government's Open Source Software Security Initiative released a report summarizing key 418.22s - 424.38s | findings from a request for information that we announced right here at last year's DEF CON. 424.38s - 430.74s | Importantly, that summary also describes actions that we are taking in response to the feedback from 430.74s - 438.30s | this community. Some of those actions are inherently governmental. For instance, we are proud to 438.30s - 444.82s | announce that the Department of Homeland Security has committed $11 million from the bipartisan 444.82s - 451.42s | infrastructure law to launch the Open Source Software Prevalence Initiative. Along with partners 451.42s - 456.70s | at our national labs, the initiative will assess the prevalence of open source software in 456.70s - 462.58s | operational technology used by critical infrastructure owners and operators. We know that 462.58s - 468.58s | open source underlies our digital infrastructure, and it's vital that, as a government, we 468.58s - 475.22s | contribute back to the community as part of our broader infrastructure efforts. But many more of the 475.22s - 481.38s | recommendations go beyond what the government can do alone. And that's where you all come in. 481.38s - 487.30s | These policy proposals rely on the dedication of security researchers and their willingness to 487.30s - 492.94s | freely share their findings in order to work. In our conversations, we are developing a software 492.94s - 500.14s | liability regime, too. We are increasingly aiming to leverage this unique community as part of 500.14s - 507.70s | novel policy solutions. Our reliance on all of you does, however, come with a commensurate increase 507.70s - 514.02s | in responsibility. In the President's National Cybersecurity Strategy, we call for more of the 514.02s - 521.14s | responsibility for defending cyberspace to fall upon the more capable actors in the


chunk_id: 205_chunk_8
chunk_text:
national labs, the initiative will assess the prevalence of open source software in 456.70s - 462.58s | operational technology used by critical infrastructure owners and operators. We know that 462.58s - 468.58s | open source underlies our digital infrastructure, and it's vital that, as a government, we 468.58s - 475.22s | contribute back to the community as part of our broader infrastructure efforts. But many more of the 475.22s - 481.38s | recommendations go beyond what the government can do alone. And that's where you all come in. 481.38s - 487.30s | These policy proposals rely on the dedication of security researchers and their willingness to 487.30s - 492.94s | freely share their findings in order to work. In our conversations, we are developing a software 492.94s - 500.14s | liability regime, too. We are increasingly aiming to leverage this unique community as part of 500.14s - 507.70s | novel policy solutions. Our reliance on all of you does, however, come with a commensurate increase 507.70s - 514.02s | in responsibility. In the President's National Cybersecurity Strategy, we call for more of the 514.02s - 521.14s | responsibility for defending cyberspace to fall upon the more capable actors in the ecosystem. 521.14s - 527.34s | That means technology producers, yes, and certainly the federal government, but it also means all of 527.34s - 535.10s | you. I know that you all are up to it. And I know that the same value set that drives responsible 535.10s - 541.94s | vulnerability disclosure will lead you to continue to step up for the protection of the Internet. I 541.94s - 547.94s | know the Internet is a safer place today because of all of your efforts. But I hope you can 547.94s - 555.94s | appreciate the magnitude and impact of the hard problems defending cyberspace. They may seem easy to 555.94s - 561.98s | some of you, but the President can't simply issue an order and solve those problems. We've known 561.98s - 568.18s | about vulnerabilities in the Border Gateway Protocol for decades. Still, much of the U.S. 568.18s - 573.90s | Internet traffic is subject to hijacking. Memory-safe programming languages have similarly been 573.90s - 581.82s | around for years. Still, critical software that underlies our society is written in C simply 581.82s - 588.14s | because that's what's convenient. The tragedy of the commons around open-source software


