 You did a great job. Thanks, jurist. You're amazing. Well, hello, everybody. It's so awesome to be here today. I'm excited to bring you one of my passion projects called Private Keys in Public Places. Before we get started, I'll let you know who I am. My name is Tom Pohl. I'm the Penetration Testing Team Manager for LMG Security out of Missoula, Montana. I like to do things like play CTFs. I'm a penetration tester by day, dream crusher at night. I've won a few CTFs. I've won Black Badge here at DEF CON. I've won Gold Badge at .con and a couple at Wild West Hack and Fest three times at Circle CityCamp. But I am an evil twin. I'd like to point out, hi, Andy. My twin brother, this is his first DEF CON. He is here in the audience tonight. So if you see me around the con and I look like I don't know what I'm doing, it's probably him. Ah. Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, anyway. And this is me hard at work. My wife took a picture that just doesn't exist of me in a hacker hoodie. I don't think I've ever worn a hoodie besides this picture in my life. And anyway, I want to give a shout out. Greetings to Set KC and Set DSM. As Juris said, you know, in Des Moines, we like to call ourselves Set KC's little brother because we kick them in the shins. The last time I saw Juris, I was giving a talk at Set KC and we had just deprived him of being able to mine cryptocurrency of the Set KC coin. And they used it to buy swag and I gave him a paper wallet with 500 Set KC coin in it so he could buy himself a little patch of swag at the Set KC store. And then I gave paper wallets to everybody in the room because they were taped under their seats. It was great. Anyways, love those guys. Greetings to Set KC. And I want to give special thanks to my buddy, Nick Stark, my partner in crime, Thought Crimes. And he's really the reason why I started looking for private keys. We'll get into that in a little bit. And also, Sherry David off. She couldn't be here today. My wife, she's amazing. This talk would not have existed without her because she's been urging me to create this for years, literally years, because I've been at this for quite some time. Thank you so much, my love. I hope you're watching. So the roadmap. So we're gonna talk a little bit of background and then we're gonna get into three different examples of how I find private keys in public places. And then we'll get at the very end into some recommendations. So first of all, why do we care about private keys? It's not the hot, sexy, new vulnerability out there. In fact, there's some really great projects out there that are extracting private keys and doing things. But I don't think it gets as much airtime and publicity as it needs, because this is a systemic problem. And it's happening in the real world, right? As attackers get into your networks, they're looking for easy ways to gain more and more access. And this is in using keys, especially in cloud environments is definitely a way that the bad guys are doing it, right? So we really need to raise awareness for this. So once upon a time, back in January, 2020, imagine this is pre-COVID, right? Nobody knew what COVID was back then. I was at a conference and my buddy, Nick Stark, he's over there in the audience. Hi, Nick, I love you. He texted, I think he texted me. I think we were texting, we weren't talking that day. And he was angry at Netgear because he found a bunch of vulnerabilities. If you don't know Nick Stark, look him up. He's like the hacker's hacker. Like he is amazing. And he found a bunch of problems on Netgear and they're trying to like bundle them all into one. Even they're like totally different problems. And so he called me being angry about it. And I'm like trying to console him. I'm like, you know what? Here's how we're gonna do it. Let's just go hack some shit. And I'm like, no idea. I'm like, he's like, what should we hack on? Hint, hint, Netgear. Since he was angry at Netgear, I'm like, let's just go start pulling random firmware and let's start exploring it and see if we can find anything. And we were about three firmwares in probably before looking and we found two different certificates that were publicly CA Blast certificates with their associated private keys, both for routerlogin.net and miniapp funjsq.com. Both from reputable certificate authorities like the certificate's there. It's not expired and the private keys with it. And just to show you, I actually took those keys, put them on my own server. I controlled the DNS for an environment, went to it. Sure enough, you get a happy lock icon. The certificate's a valid the whole deal because I controlled the DNS. And it's like, okay, well, a lot of people are like, well, that's not a big deal, is it? And actually there's a couple of guys that went out there and wrote some really good articles about like, actually, this is a pretty big deal. And I am a professional bad guy. Well, we're a good guy. I'm out there helping people find vulnerabilities on their network, right? But I was kind of thinking about like, if I was to be a bad guy, what would I do, right? Like, say I was targeting an individual and I went to the same coffee shop they were in, right? I could set up my fake routerlogin.net and if I knew they were running this Netgear product, I could fake the DNS, force their computer to come to my fake website. And then if they save their password when they log into the router, I can get that password, right? I can have them auto fill that password and then do a auto submit and then I'll get their password and then if they have a remote administration at home then I could go log into their home router and play with them all day long. Or if they have the same password, say we're gonna do a credential stuffing attack, I could go then maybe log into some of their other services across the internet. All right. By the way, I wanted to say if anybody's got questions while I'm talking through this, feel free to jump up. I think there's a mic in the middle in the back and interrupt me because I love interaction. In fact, I brought with me some Montana hacker shot glasses. So if you've got a good question, I will chuck these at you for a good question. So there's a bounty on good questions here. All right, so we tried to tell Netgear, right? It was what, January 14th, so really early in January was when we found it and we went, we tried to contact Netgear, actually in a couple of different ways. The most we had gotten was through their direct message on Twitter or X or whatever it's called now. And then so we decided that was like kind of a no go. They weren't really wanting to talk to us. So we reached out to Bug Crowd who ran their Bug Bounty Program to try to establish communications. And they came back and they would not accept information about our vulnerability outside of their program, which was really frustrating because here's why. They require what's called responsible disclosure. So anybody that's familiar with Bug Bounty Programs, there's a couple of different ways you can disclose, right? There's responsible disclosure and then there's coordinated disclosure, right? They didn't, they're in, I've got people that are very familiar with this where basically you go to the Bug Bounty Program, you have report the vulnerability, they pay you the money and then they never fix it. And guess what? You can't ever talk about it, you can't force the issue, you're bound by their terms and they never have to do anything about it. Basically you report it and you have to walk away. And so we didn't want to go that route. We wanted to do coordinated disclosure. We're basically like, hey, we're gonna talk about this, we wanna set up a timeline, we wanna talk with you and make sure it works with you and they weren't having it. So we went ahead and publicly disclosed within a few days and they fixed it within like a week. And actually April of 2020, even Bruce Schneider came out and said that Bug Bounty Programs were being used to buy silence. So sorry if this impacted you, but I think this is an important issue. I think more and more programs should do coordinated disclosure instead of responsible disclosure just so that we're forcing these vendors to fix their products. All right, so what did we learn from Netgear? Number one, private keys can be trivially found. Literally we just did grep on the file, we extracted the file system into folders and we like recursively grep for the word private in all caps and out came some keys. So we started to wonder, was this a fluke? Was this like, this is the one product out there that's got private keys in it? And the answer, oddly enough, is no. This is not an isolated incident. So we started to ask, what else might have private keys? So let's take a look. At the time I was working for a software, as a service company, I had actually been, spent most of my career on the blue team side building software as a service platform. And I was a Fortinet customer and I'm like, you know what, let me go download the latest version of the software that runs all of my firewalls just to take a look to see what I can find. Guess what I found? Well, first of all, I was able to download the software and it was a VMDK right off their website and I extracted the file system and I found that most of the stuff were, most of the software is in these tar.xz files on the firmware and I'm like, okay, cool. So it's an xz, normally people don't use xz compression but that's cool, I'll go with it. And even if you ran file on it, it says there xz compressed data. So what happens when we go ahead and try to decompress it, right? Oh, xz, sorry, compressed data is corrupt. Like, that's interesting. So it's, I mean, it's a brand new firmware I just downloaded from their website. I extracted it through very solid techniques. I knew this stuff wasn't corrupted and actually I intentionally downloaded the x86 64 bit version of the software because I knew I wouldn't have any weird file system issues and things of that nature. And so when I started exploring this file system more, I saw that they had a couple of utilities outside of those xz files and a bunch of libraries. They had one called ftar, they had another utility called xz. Like, this is interesting. You couldn't just run the xz binaries or the ftar binaries because they had their own libraries associated with it but if I ran a chroot, if I ran their firmware in a chroot environment, mind you, I had my virtual machine I'm running this on is the same architecture as the version I downloaded. That's really important if you're gonna do this at home. And so I ran their xz binaries and their ftar binaries, guess what happened? I was able to decompress and extract the rest of the file system into files. For a shot class, why do you think they did that? Anybody? Security by security. Security by security. Rick's in. Yes. All right, that's exactly right. All right, so now that we've extracted all these files out in the file system, we're like, there's gotta be something good here because they've hidden it. They made it a little bit hard. So I play a lot of CTFs so far where it may be a level 100 challenge, right? This stuff is not hard. So I wanna encourage everyone that if you do CTFs and hacking in the real world is generally easier than some of these CTF challenges. And I'm not joking. I'm not doing anything that is really hard or complex, but I think it's overlooked. I think there's things that people don't realize that if you even remotely try to go look at, you're gonna find some pretty terrifying things. All right, so we're gonna use the same technique before. Strings on a fine, maybe? A little bit of grep-dash-r, yeah. And guess what we find? Two publicly blessed CA, or certificates blessed by CAs. This time, one was published by Apple. The other one from Google. Any idea what these were used for? Push notifications. Hey, here's a shot glass for the guy in the back. Oh, wait, that's my buddy Nick. Oh, overshot. My NFL career is not gonna take off. Yes, we found some push notification certificates in everyone's Fortinet firewall. Is that exciting or scary? It's pretty excitingly scary, yeah, I know. So just to show you, so I'm like, really? These are really Apple certificates. And sure enough, so here's the output right here from looking at the PEM certificate, the public part of the key, or public part of the certificate, and it's the end from Apple Worldwide Developer Relations Certificate, Relations Certificate, right there, Apple. And then, so you can cryptographically check to make sure that like, okay, I've got a public certificate and a private key. You can actually use OpenSSL in order to look at the values from it. And sure enough, the certificate matched the private key. So it's a match. This is legit, I've got a private key to a certificate that was issued by Apple that I extracted from my Fortinet firewall software. Pretty exciting. All right, so what if I was an attacker, right? So in their final response that they came out with, they acknowledged that these certificates are actually used for both their Apple and Google Cloud messaging services. So does this mean I could send push notifications to people's phones from as Fortinet? You know, when I figured this out pretty early on, that's why at the point that I'm like, this is bad, I went ahead and reported it to Fortinet. I'd actually never worked with Fortinet and didn't know of anybody that had. So I gave them the benefit of it out. And so what this is probably two weeks, it was literally two weeks after we had the Net the Year thing go on, is when I first reported this incident, or this issue to Fortinet. And I also reached out to Apple. I mean, I'm like, hey Apple, I've got the private key to a certificate you guys issued. I felt that they should know also. And actually it was interesting, Apple like responded back, be like, we need to know whose key you've got access to. I mean, they were like, tell us what you know, tell me who your daddy is and what does he do, right? And I was a little, luckily after I told Fortinet that I had reached out to Apple as well, they self reported themselves to Apple and it was all in a merry way. And then actually I was issued a CVE in February 2020, 6.6.45, anybody ever heard that one? No, if you still look it's still actually not even allocated. But they told me in April, April 2020 that they're coming with a fix in 6.4.1 and actually I think it ended up in 6.4.2. But they wanted me to wait. What's really interesting is this is more than just like I found a problem that firmware update can kind of fix. This is like an architectural issue in their infrastructure, right? So no longer should your firewall be able to talk directly to Apple and Google and send a push notification? No, and so this is actually an architectural issue. So we had discussions around they need to come up with a solution then they had to push it out and then they wanted me to wait until a sufficient enough time had passed that enough customers had updated their firmware. I was like totally cool, I'm right on board with you. I was afforded that customer at the time, I'm like totally on board with that. And then I waited. This was April 2020 when I kind of last talked with them. And then I waited and I waited and I waited. And three years later, April of 2023, or sorry, February of 2023, they finally issued the advisory. It wasn't without, I was poking and prodding them probably every, every, I don't know, three or four months, something like that. And they never, they kept being like, oh yeah, I actually went through three P cert representatives. Like I ended up, you know, every time, you know, every few months a new person was running the program. But they finally acknowledged it in February 2023. I think they actually, it took them at least two, two and a half years to fix it. But to acknowledge it, it was February 16th, 2023. And you see, it's got a different CVE number. So what they actually, they were like internal, first internal reasons that are, I don't understand. They had to renumber the CVE to 2022, 22302, even though I reported it back in 2020. So that's an interesting story that I'm sure I'll never hear about. You know, maybe it was too long between when it was reported and when they reported the fix. I don't know, and they could only go back so far. But wait, that's not all. So fast forward, I think it was actually January or February of this year. I was on, I was helping one of my penetration testers on his external penetration test. So we found a Fortinet firewall on the public internet that was acting as a VPN server. Very common in a lot of people's organizations. But we did a password guessing attack and we found a username and password that worked that let us kind of get past that first door. But they had MFA each or none good for them. And so we didn't have a good way of bypassing their MFA. So I thought, hey, we're four to friends. I reached out and got the latest version of the software, the same software that I used to run. And I got the latest version of like, because it was the software the version our client was running, and I decided to look through the firmware to see if I could find some kind of MFA bypass, right? What's great is since I managed the team, I don't get my own engagements. So I get to jump into all my coworkers engagements to kind of help them. And I'll like sometimes swing for the fences and sometimes it'll hit a home run. Sometimes I'll just do some interesting things. In this particular case, I got sidetracked because as I was looking through the firmware, looking at all the code, I found the fix for the issue that I reported three years ago, which is actually the preface to why they finally published their advisory is because I poked them. I'm like, hey, I see you've got the fix in the software. I don't know exactly when it came out, but hopefully it's been long enough since it's been three years to go ahead and talk about it. And that's when, but then the fix was really super interesting. So I go, most of the firmware on Fortinet is in a giant init file, right? So it's kind of like busybox where you've got like a massive binary and then you link to it with LSE, you link to it with RM and CP. And bending on the file name that you're running it as, it'll hit that executable differently in a run on a little bit different version of the program. Well, that's how Fortinet's firmware is mostly set up. And inside of that, that init file, I found a URL, productAPI.fortinet.com. And it's right there highlighted in black and right above it says iOS push data. And then above that, you see FGT.CRT and FGT.KEY. Guess what those are? Any ideas? Organizational private key in the green shirt. Oh, back there. Still not gonna be an NFL player, sorry. Nice work. Yeah, so this time I discovered that they have another private key. And so I went ahead and tried to talk to this productAPI.fortinet.com. And it gave me a handshake failure, right? So I just tried to curl against it and it's like, no, not gonna be able to talk to me. So then I'm like, well, this is probably a client certificate to do client authentication against URL. So sure enough, do the curl again, pass it in the Fortinet issued certificate and private key. And yep, I can talk to the URL. So I didn't dig any deeper than this. So I don't have anything more to report here, but let's just hope that the authentication between your firewall and their push notification proxy server has more authentication than just a private key that's on their firmware. I don't know. So that's where I left that. All right, so what do we learn from Fortinet? Now that, as for this example, I'm convinced private keys are everywhere. And I'm only showing you three different examples today. I've got so many more in my library, it's ridiculous. And I've also found that manufacturers may not prioritize this type of an issue, right? Especially when they're hard problems, right? This is in particular an architectural issue. They had to now stand up an entire site on the internet that all of their customers are now going to hit. I mean, this is kind of a big change for them, and it can take some time, a really long time in this case to actually address it. So we need to be careful. But then we kept finding private keys. So in my line of business, we go kind of extra mile to find all the weaknesses in your organization, and private keys are very useful on penetration tests, right? So let's fast forward a little bit more to April of this year. My team was conducting an internal penetration test. Basically what happens on our internal penetration tests is we'll take a box, a server box that we run our own Linux distribution on, and we'll send it to the customer, and we'll have them plug it into the network and get us either on a user subnet or as if it's like plugged into a conference room, basically no level of access. And this thing will find its way out of their network, connect back to our infrastructure, and allow us to pivot in to do our work to find vulnerabilities. And so one of the first things that we do is part of discovery on your network and an internal penetration test is looked for low hanging fruit, looked for vulnerabilities, right? We'll use a vulnerability scanner and my co-worker who is running this internal penetration test, he's like the next day, he's like after he ran scans for a day, he's like, hey, I found, I got access to what was reported as a Palo Alto firewall with default credentials, but I got into it and it does not look like a Palo Alto firewall. I guess what credentials he used to get into it with. Hey, he said admin, admin, that guy, here we go. Sorry, that was the one I drank out of, you might wanna wash that one. My bad, that was the last one. Yeah, admin, admin. So that's how we got into this thing and he didn't know what it was, I didn't know what it was. It was kind of a mysterious device. It looked like it was running some version of maybe a CentOS, looking through process lists, looking through file systems. We found that this is an interesting thing. So first of all, we started looking through process lists and you'll see here that we found the directory that was labeled Dell Compellent. I'm like, Dell Compellent, that's a storage platform. Am I in a Compellent? I've never seen a Compellent before, but I've heard about them, but it wasn't a Compellent. I'm like, I'm looking like, there's gotta be a giant ass hard drive around here that's hosting their domain controller. Like that's what I was looking for, right? Like I'm hunting for a way that I can forensically grab all your passwords or other user credentials. But it wasn't, but I did have some directories I can start looking at. And so in one of these directories, I found a properties file that was called VSP.properties. I had, and then at the top it gave me a hint. It says Dell Compellent VMware vSphere plugin for VMware vCenter configuration parameters. Like that sounds very fancy. And they had a password and a username and the username was vSphere.local administrator. So this seemed like a high value target to me. But that password looked real odd, right? It was all hex, uppercase and numbers. And I'm like, that couldn't possibly be the password to their vCenter, could it? No, it wasn't. I went into the vCenter, I tried to log in with it. And sure enough, it was not the, I got invalid credentials. I'm like, okay, that's cool. So that means that that password has to be able to be read by the components. So it was like, so this turns out it's a, it appears to be some kind of a connector between Dell Compellent Storage Platform and vCenter. So this kind of sits in between, I don't know what it does. It probably creates snapshots or provisions, volumes. I have no idea, but for some reason, in the documentation, it says, you must give it administrator level credentials to the Compellent connector in order to be the connector to your vSphere. Or your vCenter. And so I needed to figure out, like, something's gotta read and write that config. Let's figure this out. And so sure enough, I found the install script that was sitting on the box that referenced a vspconfigutil.jar and they had a class name, reference Dell, com.del.compellentvspconfigutil. You know, there, I enlarged it so you can see it a little bit. So there's a jar file that we found and then there's the class file that gets run with that jar file. And I'm like, well, that sounds like something that, you know, get configuration data. That thing's gotta be able to somehow read that encrypted value and decrypt it, right? So I've actually been a Java developer for most of my career. I probably coded Java for about 25 years. I'm like, I'm not shied away by this at all. And I've, you know, played a few CTS. I'm like, you know, understanding a jar file, all it is is a zip file. You can use a jar util or in this particular case you just use, I just used unzip, unzip the jar file and it takes every, so in Java, everything's compiled into different classes. So in those classes are put into packages. All that is is fancy words for files and directories. And I decided I just start going down the list. I started with confutil.class. I'm like, I can decompile that because it's an interpreted language or well, it's a compiled language as interpreted by the Java interpreter. So you can get decompilers. And I actually use, so in a few different steps, like I use the benef.org decompiler. It's pretty lightweight, easy to use and it gives you some pretty nice looking output. So all I did was download the benef.org decompiler and I fed it that confutil.class and guess what I got? Private key, who said that? I wish I had another shot glass for you, man. I would throw it right at you. I got a whiskey bottle, but it's empty. All right, so sure enough, it's even commented, like right above where it says encryption to key, it says encrypted type AES. I'm like, they're even giving me hints as to what I need to do here. This is great. And so sure enough, there's a static AES key. So since this is in the compiled jar file, that means this isn't a unique key by customer, right? Anybody that's got this product, their vCenter passwords are stored in this VSP properties file encrypted with the same key as any other customer. So it didn't matter. So as long as you can get access to that VSP properties file, I'm gonna be able to get your password out of that, right? Well, maybe. Well, so let's step through how I got it, right? So I knew it was AES of some sort. I've got a key. I've got it out of the properties file. So what I did was I used a very common CTF tool. Any idea what tool I might have used? Cyberchef, that's right. So I just went to Cyberchef. I took the AES key. I have it redacted here. I'm not that much of an asshole. If you guys want the key, you can go get it yourselves. But so I put the AES key into the AES decrypt method of Cyberchef, and then I put the encrypted password in the input, and then I'm like, wait, I was digging the resource code. What did they use for initialization factor? In fact, I was like, maybe this is the secret sauce to their private key, because they didn't actually have it in there. I was trying to figure out like, okay. So I just put in enough zeros until Cyberchef was happy with it, and guess what popped out? Clear text password. So now I'm armed with a clear text user. I go back to the password. I go back to the vCenter, and I'm in, right? So at this point, you do the happy dance. You're like, oh my God, I've got access to their vCenter. Why is this important? Why is it important that I have full admin access to your vCenter? You fucked it up, yeah. You're running all this stuff, right? This is where your domain controllers live, and your servers, and all the important infrastructure that runs your organization is generally accessed through vCenter. That's how vCenter works. So normally at this point, like my go-to move when I get vCenter access, so I've exploited vCenter in a lot of different ways. Thank you, Log4j, you're the gift that keeps on giving. But normally what I'll do is I will snapshot your domain controller, and then I'll download the first 10 to 20 gigs of the hard drive of your domain controller, or whatever hard drive is that you're storing the NTDS I did, because it doesn't have to be your C drive. And then I will forensically recover all the NTLM hashes from the NTDS.dit using the system registry hives and that file in order to get all the hashes. And it's cool, actually, if people are interested, I actually have a really cool technique how I can use a partial hard drive download to then convert it to QtCow2, and then be able to mount it and access it, because often when I'm doing these things, you're not getting clean images, right? Sometimes you're doing a read-only mount of an ice guzzie or MFAS or something like that, and even the registry hives, they're not gonna be clean, but some of them are like the last known good boot. So I have manually patched impact it so I can go after the last known good boot to get the boot key from the previous boot, and it's likely still the same key to decrypt your boot key. At any rate, but that's not what we did here. So we took it a step farther. So in this particular case, just people always love a good pent-up story, right? I went ahead and I passed on the access to my co-worker who's working the IPT, and I decided I was gonna fuck around with some of their other stuff. They had a certificate authority on the network. And so I was working with, we had another low-level user on their network at this point, and I was messing with their certificate authority. And I definitely set off some alarms, but my co-worker was in the console of vCenter, and he's checking out the consoles. He's checking out what servers he had access to, and apparently I must have set off an alert because their domain administrator went to the CA box and opened up through vCenter the console that my buddy was sitting on. And so he logged into the console and he was looking around at the logs and seeing what was going on, because I was messing with the certificate authority. My co-worker was on the console of the same certificate authority when the domain administrator logged in, and then it stopped moving. He stopped typing stuff, and it looked like he walked away. So guess what my co-worker did? Popped a PowerShell, created his own domain admin account, and then closed it. So then we got domain administrator without even downloading the domain controller. We had open access to a console, and then from there then we went ahead and we dumped the NTDS that did across the network, and then we won the day. That was the game over for that organization. They learned a valuable lesson about managing consoles for sure. Anyways, so in this attack, there's definitely multiple ways to exploit the issue. So getting back to the Dell issue, they actually have a couple different user accounts. In fact, Dell even came out and said, oh, well you need to change the credentials. Well, there's actually two credentials on that box, and they only talk about the root credentials. They had actually any level of access to their Dell Compellent connector will actually let you go and get everything that I did here today. And as well as if you ever, if any company was doing any segregation to duties, like maybe the administrator had access to upgrade the software and do this, but they didn't have access to the vCenter password and they had somebody else put that in, well, the administrator then could then go retrieve that. So if you're trying to do any kind of segregation to duties with this connector piece, it's a failed attempt. At any rate, so that was that. So then we reported it to Dell, right? So in April, it's about the 11th of April, I emailed Dell, actually I think it was at this point that Sherry's like, you need to talk about this. And I'm like, you know, she's like, Def Con and Black Hat are coming up. She's like, you need to submit. And it's more than 90 days. So you need to report it. And then you're gonna talk about it. I'm like, okay, I'll do it, finally talk about it. And so I emailed with Dell and my first response back from Dell was like, oh, well, you need to open a support ticket with your customer number. And this is actually a configuration issue on your part and have a nice day. And I'm like, so does that mean you're cool with me talking about this in August? And they're like, whoa, whoa, whoa, sorry. We didn't mean to send you that. Yeah, we take security seriously. And we're going to look into this and get back to you. And you know, and I gave them some more details in May, you know, a little bit more back and forth. And finally, in the end of June, I got an email update saying that they're going to fix it in November. And I'm like, but I'm gonna talk about it in August. I told you in April, I'm gonna talk about it in August. And they've actually been pretty decent to work with. But that's why, other reason why I have a release key. But you can go get it. I think I've given you enough of the road map that you can go do this. If you've got this in your organization. But yeah, they're coming out with a fix. I think actually that whole storage platform is being deprecated. But how many people in here run storage platforms as long as humanly possible, right? Because how hard is it to move storage platforms? It sucks. So I imagine this is going to be not, you know, the last time, you know, oh, they deprecated, it's going away. Well, they'll probably, you know, you will probably get five, six more years out of it until the thing is not usable anymore. Because so many people will use their storage platforms forever and ever. I know this because I used to be you. And, you know, there's a lot more things out here. Like I just gave you today, these are just three examples of private keys in public places, right? I mean, I've found private keys in remote login apps and routers, cameras. My favorite, I'm not ready to talk about this one yet. There's a camera out there that it doesn't have a private key. It's got all the components to make a private key, that they make the private key on the fly, and then use that to do the communication with their cloud service. So if that's you guys, I'm coming for you. And also printers. I get, you know, you can get keys out of printers. I actually have other ways, other than just going through firmware to get keys out of primers. I gave a talk actually in Wednesday at B-Sides on how I met your printer. Go ahead and look that one up if you're interested in how I can elicit your printer just to give me its password instead of doing it forensically. But this is a systemic problem, right? Private keys in these public places like firmware is a big problem. And I recommend, you know, firmware, the software developers, private keys don't belong in the binaries of your software, right? This is a bad practice. You know, if anything, you know, uniquely generated per device or whatever. And also, you know, regular security audits and testing should be done to look for these secrets, right? There's tools out there that will look at your source code and stop the build in your CICD process if you've got a private key hidden there, because developers will do it. I've seen it. I've done, I've audited code. I've been in software development for most of my career. I know how you guys think. And also coordinated disclosure programs should be adopted, right? No more hush money programs where it's like, oh yeah, we totally took care of that problem. We paid off the guy that found it, right? Like no, you should fix your problems and come clean about it in public releases. So any more questions? Any more comments? If you wanna find me on the internet, I'm creatively, Tom Pohl, actually it's funny. I think my first DEF CON was DEF CON 20. And I came in, I think fourth place in a competition that year, and that's when Dark Tangent called me out in front of 25,000 hackers for being the only guy that goes to a hacker conference and uses his real name. But you can find me very creatively on social media as Tom Pohl. I'm on both X or Twitter, whatever it is now, as well as on Mastodon. And you can find me on LinkedIn as well. Thank you much for your time today. If you wanna, if anybody wants to talk afterwards, I'm totally cool. Like if you wanna go to like the Chill Out Lounge or something and we, you know, sit and have some beers and talk more. I'd love to talk with you guys.