Darknet Diaries - 121: Ed

Episode Date: July 26, 2022

In this episode we hear some penetration test stories from Ed Skoudis (twitter.com/edskoudis). We also catch up with Beau Woods (twitter.com/beauwoods) from I am The Cavalry (iamthecavalry.org).SponsorsSupport for this show comes from Axonius. Securing assets — whether managed, unmanaged, ephemeral, or in the cloud — is a tricky task. The Axonius Cybersecurity Asset Management Platform correlates asset data from existing solutions to provide an always up-to-date inventory, uncover gaps, and automate action. Axonius gives IT and security teams the confidence to control complexity by mitigating threats, navigating risk, decreasing incidents, and informing business-level strategy — all while eliminating manual, repetitive tasks. Visit axonius.com/darknet to learn more and try it free.Support for this show comes from Zscalar. Zscalar zero trust exchange will scrutinize the traffic and permit or deny traffic based on a set of rules. This is so much more secure than letting data flow freely internally. And it really does mitigate ransomware outbreaks. The Zscaler Zero Trust Exchange gives YOU confidence in your security to feel empowered to focus on other parts of your business, like digital transformation, growth, and innovation. Check out the product at zscaler.com/darknet.Support for this podcast comes from Cybereason. Cybereason reverses the attacker’s advantage and puts the power back in the defender’s hands. End cyber attacks. From endpoints to everywhere. Learn more at Cybereason.com/darknet.View all active sponsors.AttributionDarknet Diaries is created by Jack Rhysider.Editing by Damienne. Assembled by Tristan Ledger. Sound designed by Andrew Meriwether.Episode artwork by odibagas.Audio cleanup by Proximity Sound.Theme music created by Breakmaster Cylinder. 

sometimes I think I'm just like one click away from a total catastrophe. The perfectly crafted email at the perfect time can cause major damage. Just look at what happened to Barbara Kukorin. She's the judge on the TV show Shark Tank. Here's a clip from CBS This Morning. I've got a very important warning of a financial scam here. One of the stars of the reality show Shark Tank says she was a victim of, they're calling it a phishing scam, but really

it's a digital con job. Barbara Corcoran, this is what happened. Last week her bookkeeper received an email about an invoice and it appeared to be from Corcoran's assistant, a trusted source, approving payment for a real estate renovation. So her bookkeeper was told to send

about $400,000 to someone regarding some real estate expense. The email looked like it came from Barbara's assistant, a trusted person. And since Barbara was a real estate investor, this looked like a typical money transfer. So her bookkeeper wired the money to this person. And it turns out it was all just a phishing email. Barbara lost $400,000 because of a single spoofed email. This hack wasn't technical. It was manipulating a person, not a machine or a computer. And I fear that we may always be vulnerable to this type of attack. We can't update the firmware in our brain. And yes, we can be educated on how to spot this type of thing and avoid it,

but even some of the most educated people on phishing attacks and social engineering have fallen victim to phishing emails. I think people may have bigger vulnerabilities than computers. These are true stories from the dark side of the internet.

I'm Jack Recider. This is Dark by Delete Me. I know a bit too much about how scam callers work. They'll use anything they can find about you online to try to get at your money. And our personal information is all over the place online. Phone numbers, addresses, family members, where you work, what kind of car you drive. It's endless and it's not a fair fight. But I realized I don't need to be fighting this alone anymore. Now I use the help of Delete.me. Delete.me is a subscription service that finds and removes

personal information from hundreds of data brokers' websites and continuously works to keep it off. Data brokers hate them because Delete.me makes sure your personal profile is no longer theirs to sell. I tried it and they immediately got busy scouring the internet for my name and gave me reports on what they found. And then they got busy deleting things. It was great to have someone on my team when it comes to my privacy. Take control of your data and keep your private life private by signing up for Delete Me. Now at a special discount for Darknet Diaries listeners. Today, get 20% off your Delete Me plan when you go to joindeleteme.com slash darknetdiaries and use promo code darknet at checkout.

The only way to get 20% off is to go to joindeleteme.com slash darknetdiaries and enter code darknet at checkout. That's joindeleteme.com slash darknetdiaries. Use code Darknet. Support for this show comes from Black Hills Information Security. This is a company that does penetration testing, incident response, and active monitoring to help keep businesses secure. I know a few people

who work over there, and I can vouch they do very good work. If you want to improve the security of your organization, give them a call. I'm sure they can help. But the founder of the company, John Strand, is a teacher, and he's made it a mission to make Black Hills Information Security world-class in security training. You can learn things like penetration testing, securing the cloud, breaching the cloud, digital forensics, and so much more. But get this, the whole thing is pay what you can. Black Hills believes that great intro security classes do not need to be expensive, and they are trying to break down barriers to get more people into the security field. And if you decide to pay over $195, you get six months access to the MetaCTF Cyber Range,

which is great for practicing your skills and showing them off to potential employers. Head on over to BlackHillsInfosec.com to learn more about what services they offer and find links to their webcasts to get some world-class training. That's BlackHillsInfosec.com. BlackHillsInfosec.com. My guest in this episode is Ed Skodas. So I am Ed Skodas. I am an instructor with the SANS Institute. I am a penetration tester and founder of CounterHack, which is a security consulting firm focused on penetration testing, vulnerability assessment, and red teaming. I actually started as a kid. I remember I had

my first computer was a VIC-20. My second computer was a Commodore 64. And I was on the BBS scene, the bulletin board systems, with dial-up back in the day. And that's when I kind of started hacking as a kid. I never imagined that there could be a career associated with this. I ended up going to college and studied electrical engineering undergraduate and information networking as a graduate degree. I got a master's in that. And while I was in school, we did hacking. I mean, we were on the internet. We had a bunch of Unix computers at the time and some very, very early Windows machines. And we would hack them in the computer centers, kind of having fun, not doing anything explicitly evil or malicious.

It was more prank kind of stuff. But again, I never realized there was a career out of that. After college, he went to work at Bell Labs, which was a bit of a magical place for him. And this put him on a path to work in IT and security. Early on, he was doing penetration testing in his career, which is where they wanted to see if he could find a security flaw somewhere that would give him unauthorized access into something. And this one was going well, in fact, so well that other companies started asking him to do penetration tests for them. So some of the banks came to us and said, can you start doing this for us? So I started working with

a lot of the banks, especially big New York City banks. And I was doing penetration testing for them. He moved around working for a few different companies, all while doing security assessments. And ultimately, I started doing talks in the cybersecurity industry at various events. I spoke at DEF CON. I spoke at some of the other conferences. And I always wanted to teach for SANS. The SANS Institute is one of the earliest places you can go to get cybersecurity training,

and it's known for having great instructors and courses. And finally, this was in 1999, I got an email from the folks at SANS. They had seen my talk somewhere, and it was May of 1999 in Baltimore Inner Harbor. I got my first opportunity to speak for SANS. And I was nervous. I was excited. I presented in this room with 300 people in the room. So this was a big audience for me at the time. The guy who ran SANS was Stephen Northcutt.

He was in the room. Alan Paller, the guy who founded SANS, was in the room. And it's like, I got to give him my all. So that was my first presentation for SANS. It was about a two-hour talk on hacking in 1999. This went great. Just after that, SANS brought him on board. And for the next two decades, he was a full-time SANS instructor.

And I was teaching for SANS six days at a time, between 12 and 15 times a year. Now, SANS has a policy that you can't be just a SANS instructor. It's this instructor practitioner model. So they want to take people who are practitioners, you have to be active in doing, you know, the cybersecurity work, like I was doing penetration testing and still am, but then also teach because they don't want to have people who are merely book smart. So from that point that I became a SANS instructor, I was still working at this offshoot of the baby bells doing consulting. The baby bells. That's when AT&T got too big and the government forced them to break up into nine

different companies. These nine smaller companies were called Baby Bells. So for the past 26 years, Ed has been doing penetration testing, hacking into networks and buildings to demonstrate where the security weak points are. And today, he's going to share with us some of these stories that he's experienced over the years. So come on, let's tag along as he tells us about one of the penetration tests he was involved with. It was a penetration test that my team was doing several years ago, and it was of a hospital. Hospital environment, and we had our defined scope. It's very important for you to have a good defined scope. A hospital. Okay. With these sorts of things, you've got to be careful and define your scope very precisely. The hospital

wanted him to test their network only. There was no physical component to this, which means he didn't need to come on site at all or try to sneak into any unauthorized parts of the hospital. Now, he broke down this penetration test into two phases. The first phase was to test the outside security of the network from the internet, as if you were an attacker on the other side of the world. And clearly this hospital has a large front gate to their network, which should prevent any unauthorized connections from getting in. But a penetration test will determine whether or not there are any holes in this gate.

The second phase was that they'd be given access to a computer inside the hospital's network to test what kind of stuff someone could do if they got in. So it's a hospital environment. They gave us a set of IP addresses that were internet accessible that we should test. They gave us a set of addresses on the internal network that we were to test. It's important that they stay within scope. These IPs, and only these IPs, were allowed to be attacked. They surely didn't want to attack any IP thats, were allowed to be attacked. They surely didn't want to attack any IP that could cause actual harm to a patient. But this is always a tricky balance when it comes to doing penetration tests like this.

Do you include your most critical resources? The ones that could cause loss of life if they were to be damaged? Yeah, of course include those. It's imperative that those are very secure systems. But sometimes these aren't tested because they could cause loss of life if something went wrong. It's tricky. And what about backup or development systems? I mean, by definition, a dev server is a work in progress.

So do you run a security assessment on systems that are works in progress or systems that you know haven't been updated for a while? Heck yeah, if it's exposed to the internet, you must. Any and every door or window into your network should be tested, right? If it's a potential attack surface, then someone with malicious intent may find it and exploit it. But companies and hospitals aren't always so open to having everything attacked. And so Ed had to listen to the clients on what was allowed to be

attacked and what wasn't. The hospital gave him a range of IP addresses and said, see if you can find any vulnerabilities within this range and stick only to that. And so the first thing you wanted to do was figure out what computers were in that range. You're mapping your attack surface at this point, right? So you're using various tools, and map is a very popular one, just to find out which systems are available, what is their set of ports that are open, and then ultimately moving on to finding a list of potential vulnerabilities with them. Now, some of the ports that are open, and then ultimately moving on to finding a list of potential vulnerabilities with them. Now, some of the ports that are most interesting, of course, to us are associated with HTTP and HTTPS, right? Those web interfaces often have a lot of complexity behind them, and with complexity often comes vulnerabilities.

So we enumerated that attack surface, found the set of ports that were open, started interacting with systems. And I got to tell you, Jack, the external web-based presence and internet presence of this hospital was pretty darn solid. Hmm. This is also a tricky spot for penetration testers to be in. If you try hacking into a network but come up empty-handed, it's hard to know if you tried hard enough. Maybe there's some big glaring vulnerability that you just didn't see. And if you tell the hospital, we tested everything and it's all good, but then a week later someone exploits something easy, then, yeah, your reputation suffers, for sure.

So Ed and his team had to be very thorough and go through the entire outside attack surface more carefully. So they did things like figure out what applications are accessible from the internet, then looking up what the default passwords are for those applications and trying to log in with them. But that didn't work. Then they're trying to manipulate the websites to see if those websites are vulnerable to cross-site scripting attacks or SQL injection attacks. Basically, Ed has a checklist of things to test on every system or computer they encounter,

testing to make sure that none of the servers he's found are vulnerable to the most well-known type of attacks. But even after going through the systems one by one, checking them all, he wasn't able to find any problems on the public-facing parts of the hospital's network. Well, I mean, there were some low-level vulnerabilities, but nothing exploitable. I've never had a pen test where we found nothing,

but nothing big. So we found nothing big on the external side. Which meant the hospital did well at securing their outer digital perimeter. But we also, as a second phase of the test, they gave us access to an internal system. And from there, they wanted us to map the inside of the hospital. So there we were posing as one of many potential attacker types. One is somebody who physically breaks into the hospital and connects into, say, an Ethernet jack. Another one is somebody who is in the hospital

and actually just accesses the Wi-Fi of the hospital so we could start looking around. Another one, another attacker that we're posing as is maybe there's a user in the hospital who carried in a laptop that had malware on it. So we are the controllers of that malware. Or maybe it's somebody in the hospital who surfed the internet with a vulnerable browser and got hacked on their system. So the browser itself is now where the attackers got control. Or maybe they clicked on a spear phishing email and got compromised. The point is the second phase of this test was the really important one because it's saying, okay, the attacker has gotten malware in the environment, either by walking through the hospital doors or compromising

something inside the hospital. What can you find now? What they did was they gave him a remote connection into their network, a VPN connection into the hospital, which makes it seem as if he's actually inside the hospital. And they wanted to know what could a hacker do if they got into the network. And the way we structure these tests is we want to look like a brand new employee in your environment. We want the access of a low-level rank-and-file employee. Don't give us admin access. Don't give us anything special. We just want to be on the internal network, VPNed in.

So we log in, you know, there's multi-factor authentication. Sometimes we'll even have the customer send us an image of their standard corporate laptop. So we can log in using exactly the same software mix, exactly everything that a rank and file employee would be issued. So we're remotely accessing that environment. And then we move back into the stages we talked about for the remote test. You start enumerating the environment according to your scope. You're scanning to see which systems are available on the internal network.

Then you're looking at their attack surface. What ports do they have open? What operating systems do they have? What vulnerabilities might they have? And you're trying to do that usually on a low and slow basis at first. You're not going in there with guns blazing. You're kind of throttling your then we ramp it up over time to see where we get noticed. What is your tolerance for activity on your network where people are probing you that you don't notice it yet? And what's that sort of tolerance bar where, oh, now we see you? Because if we can fly under that radar screen, so could an actual malicious attacker. The head of the hospital's security team knew that they were doing a penetration test. And part of this test was to see if the internal security team to the hospital would pick up on someone doing something they shouldn't be doing. If someone tried to log into the domain controller and failed a hundred times in a row, would anyone

see? If someone tried enumerating and looking for vulnerabilities on computers, would that trigger any alerts? Ed knew the security team would be keeping a lookout and wanted to fly below the radar to not trip any alarms. So they map out the attack surface and see what computers look alive and what ports are open and start looking at those computers to see if they are vulnerable. At the same time, they're also running a slow and quiet vulnerability scan.

Slow and quiet to avoid tripping any alarms the security team might see. And what a vulnerability scan will do is it'll send packets to each system to try to request information from that computer. So if you point a vulnerability scanner at a website, it'll try real hard to figure out what operating system that website is using, what version of software it's running. And then from there, the vulnerability scanner will look up to see if those versions have any known vulnerabilities in them. After letting the vulnerability scanner run for a few hours, it found something. Vulnerability on one of their computers. Big one. Big honking vulnerability. It was, you know, a system that was missing a common

patch. It was a patch from Microsoft that they had released about two years earlier. But here's the deal. On medical systems, oftentimes it can be hard to get them patched because they're so feeble and so sensitive. They don't want to break anything. And some vendors do not alert their customers to say, hey, there's a patch necessary for this system because, you know, you brought, you know, as a hospital, you bought XYZ, you know, brain scanner or whatever it happens to be. And that's what you have. And it says XYZ brain scanner on the side of the machine.

You don't know that inside there, you know, it's a Windows 2016 server. That's not what you bought, but it is. And, you know, your vendor who sold you the brain scanner has to tell you that now it's time to patch or to set something up, some sort of service contract or something like that, where that patch gets deployed. So it was two years out of patch, and we found this significantly exploitable flaw on it. This is something that always drives me nuts. So many of the systems we buy, we don't do anything to keep them updated. Printers, for example. When's the last time you've updated your printer's operating system? They've got to have some kind of operating system or software on them in order for them to work, right? And especially the ones that are online that you can send a print job to over

the network. Some of these even run Windows or Linux operating systems. Now, in big companies, printers might be installed by some outside contractors. But even in those cases, contractors aren't coming back every few months to update the software on them. And this is the case with many of the computers in our network. Webcams, routers, smart TVs. And you can just imagine all the network-connected tools and instruments and computers that are in a hospital's environment. Ed and his team found this vulnerability on some computer.

But they didn't know what this computer did. All they knew is that they found this computer to have a very high severity vulnerability. See, not all vulnerabilities are the same. Some are low level, like your system might have the wrong time or date on its internal clock. And that could be a problem, but it's not one that's easily exploitable. But the vulnerability they found was a really bad one. One that they could easily exploit if they wanted to and get full control over that system. But they knew to be careful. This was a hospital. And at

this point, they only found the vulnerability. The next step for them was going to be to exploit that vulnerability and get into that system. And there's a possibility that when you exploit a vulnerability, it causes the computer to crash or become unstable, maybe even reboot. We had a call with a customer saying, hey, we're scanning the environment. We found this on the internal network. We found a pretty critical vulnerability. Can we exploit it? And they said, sure. I mean, that was included within the scope of our test. Okay. Green light to exploit it. So Ed's team loaded up the exploit and aimed it at the system, and bingo. Right away, they were able to get in and have full command line control over that system.

Clearly, this is a problem. And a penetration tester will call this a finding and document it and put it in the report. And this is a problem because having command line access on another computer gives you all kinds of new capabilities. They can, of course, look around on that system to see if it has any sensitive information on it. They could look around for any cached passwords or patient records, and maybe they could use the trust of this computer to access another computer

because sometimes there are trust relationships built into a network which allow you to get somewhere that you couldn't from your own laptop. While Ed's looking around on this computer, he sees something and calls the customer. So we exploited it, and we got Shell on the system. And the customer's like, okay, fine, fine. And then I said, we're looking around on the machine, and we found some software on that system

that controls a surgical laser. You know, it's the nature of the software package. And they said, oh, you know, what kind of surgical laser? And we told them what kind of surgical laser. And they said, what was that IP address again? So we told them the IP address again. This is our status call, right? They put us on mute for a second.

So they muted their side. Said, we'll get back to you in just one second. Just hold on, let's mute. So they muted. And we're all sitting there thinking, hmm, wonder what's going on there now. After about a minute and a half, which felt like an hour, they unmuted and said, hey guys, we're going to have to get back to you, you know, maybe later today or tomorrow. So we'll call you back. All right. So we finished the call. And it's like, that was abrupt.

We didn't even finish our status discussion. And suddenly they're going to call us back. So they called us back maybe three, four hours later and said, hey, you know that system that you were on? Yeah. Well, it turns out that system was used to control a surgical laser. And we said, well, we figured that because, you know, it was, the software was installed on it to do that. And they said, yeah. And we looked it up and turns out it was actually being used in surgery when you guys were on it.

And then we're like, oh, everything turned out okay? Yes, everything is fine. No one got hurt. That's good. But you got to be super careful on this kind of thing. I mean, that system probably should not have been in scope, but it was in scope. Right after I finished that call, I called my lawyer, right? My lawyer, he's pretty interesting in this business. His name is Mark Rash. He was one of the chief prosecutors of Kevin Mitnick back in the day from the Department of Justice. Anyway, I've known Mark for 20-some years. And I called Mark and I explained the whole thing to him. He's like, did anybody get hurt?

No, no one got hurt. Were you operating in your scope? Yes, we were operating in our scope. Was your scope written down and defined very clearly? Yes, it was. Was exploitation of these systems included in the scope? Yes, it was explicitly said that we can exploit these systems. He's like, okay, thank goodness no one got hurt.

Oh, and is your insurance up to date? So Mark goes through this whole list of, yeah. And we were fine, but I bring this story up because you got to be careful. There are real world implications to the systems that we're touching as cybersecurity professionals, certainly in pen testing, but even as defenders or forensics experts. Be careful, be careful, be careful. Operate within your scope. Follow the rules of engagement.

Be careful that you don't cause really bad things to happen. I mean, surgical lasers are used for all kinds of things. I actually, about six months after this event happened, I had to go in for surgery on my eye. And I'm sitting in the surgical chair and they got this thing holding my eye open. It felt like clockwork orange, I'm telling you. So they're holding my eye open.

They put this little laser over my eye. And the laser was controlled by a Windows 7 machine. And it had an Ethernet jack on the back. And I'm looking at that thing and wondering who's got shell on this system. It wasn't the same kind of thing that we had tested in a hospital earlier. It was a different hospital, different system, but it made it so much more real for me. There's a reality that underlies the systems that we're interacting with and touching, and we need to approach them carefully and with due diligence. It is fun to be a pen tester. It's fun to hack, but we do have to be aware and careful and exercise our due diligence

in doing our work right and professionally. It's amazing to me that companies struggle to keep track of what's in their network. You would think that companies would know exactly what systems are there and what they do. But once a company or network gets so big, it becomes a real problem to keep track of all the stuff that's in it. Systems come and go all the time, and documentation doesn't always reflect what's out there. Luckily for everyone in this scenario, nobody got hurt from this pen test. But it gives you pause to think, doesn't it? Who's testing these medical devices to make sure they're hack-proof?

And a few years ago, I found someone who is hacking on medical devices. Yeah, my name is Beau Woods. I'm a volunteer with a grassroots initiative called I Am the Cavalry. And our problem statement is our dependence on connected technology is growing faster than our ability to secure it in areas impacting human life and public safety. And what that means is that we want to work together in a positive, proactive manner with medical device makers,

with the automotive industry, with aviation, and other places where bits and bytes meet flesh and blood. DEF CON is the annual hacker conference in Las Vegas. This interview is actually from a few years back. And what Bo helps organize is the Biohacking Village device lab. Now, the Biohacking Village Device Lab. Now, the Biohacking Village at DEF CON is a place where you can get a computer chip implanted inside you, if you wanted, and do other things to augment the human body. But Bo is involved with the Device Lab. This is where DEF CON attendees can get their hands on medical devices that are used

in places like hospitals. This year at DEF CON, at the biohacking village, we have a device lab. We have four medical device makers that came to the device lab, brought devices for researchers to test with. So they donated to you to test these? They're bringing their own devices and asking researchers to engage. So they see it. So the way we built the device lab is we want it to be a safe space, an educational forum to build trust, understanding, and empathy

with all of the other different ecosystem stakeholders. So we've got four medical device makers who are bringing devices formally and officially in the room. Their executives know about it, and they're engaging with the security research community to say, let's teach you, let's learn. Here are some devices.

See if you can get something that we couldn't. Let's help you figure out where to look. Let's do the right thing so that we can learn and you can learn. We'll learn what you find, and you learn how we go about making these devices. We've also got to capture the flag learn how we go about making these devices. We've also got to capture the flag that the Mayo Clinic built, for instance. We've got the FDA is participating. There's Suzanne Schwartz and Seth Carmody from the FDA are in there giving their time to go around to meet people to do the outreach. We've got patients, researchers,

and really everybody in the ecosystem. You can guess it wasn't easy for Bo to convince medical companies to bring their equipment to a conference with 25,000 hackers in attendance. To start out with, security is hard. Do these companies want to put all the measures in place to make sure their device isn't hackable? Or is their priority to make a useful tool for doctors that has extreme precision and reliability? Well, on top of that, if you put your device in the hands of hackers, who knows what malicious things they'll do with it. So I can see why some medical device makers are hesitant.

In fact, at first, medical device makers were even fighting with hackers, not wanting to work with them at all. Like for instance, some people would give talks at DEF CON on how to hack things like insulin pumps and cause a patient to overdose. And this was actually going to be one of Barnaby Jack's talks, but medical device makers were vocal about how bad of an idea this was to give a talk like this.

Medical device makers were starting to make enemies with hackers. They had had a number of issues, security researchers reporting things to medical device makers who really didn't do much, who sent threatening letters and who did other things. And the FDA recognized that that's no longer sufficient in our connected healthcare environment to say these things don't matter.

So they stood up and led the charge. I think without the FDA's leadership in that, we wouldn't be as far as we are. Because we found kind of willing allies and willing teammates in the healthcare community really quickly, there was a lot of uptake fast, right? So we started working with people.

We've got probably a half a dozen to 10 medical device companies that I'm on a first name basis with their product security teams, right? Which is a really cool thing. And so this was a long way to go for Bo and the organization he works with called I Am The Cavalry to get device makers and hackers to work together. Clearly, they both have a common goal of securing medical devices, and this seems to have resulted in a positive impact. Medical device makers have found a real

benefit working with hackers. Yeah, I went up yesterday after day one and asked everybody, day one, I know it's a scary thing to come in to 25,000 hackers, right? What did you think? And I got a lot of very happy laughs. They seem overjoyed with the results, you know, being able to get into the room and talk to people, understand them and have other people understand them, right? I think they probably changed a lot of perceptions about what medical devices are. The kind of elephant in the room in the device lab is that medical devices have a bad reputation for security. What I think they showed is that actually you can build a medical device in a way that is safe and effective for the patients and also secure. A couple of the choice quotes that I heard yesterday from the security researchers was, one was, man, I can't even tell this thing is on the network.

Are you sure it's plugged in? They've been working on it for two hours, trying to find some vulnerabilities or some issues or even some way to start attaching to it. And they couldn't attack it and couldn't hear it talking even. Another quote was, oh man, if I was a bad guy, I would have given up by now, right? So I think that's a testament to the shifting perceptions to hopefully snap more into place with reality on both sides. And when a vulnerability is discovered in one of these devices,

does the IT staff at the hospital patch it or is it sent back to the manufacturer? What goes on there? Yeah, so there's a relay race in getting vulnerabilities fixed. So when a vulnerability is discovered, the manufacturer often issues a patch, whether it's for their custom software or some of the software components like the operating systems.

They issue an update or they communicate the need to do an update on those systems. Then it's sometimes up to the hospital, sometimes up to a biomedical contractor to come and apply the updates that exist. But that's a lot of handoffs involved in that. And what we find is that in a lot of cases, the medical device makers may have fixed something, but the hospitals have not applied the fixes. So that's kind of one of the reasons why we have so many vulnerabilities in our health care is not that there aren't more secure versions of the medical devices available, but that they haven't been taken up by the hospitals themselves. Well, this year at DEF CON, which is in August, the medical device hacking village will be bigger than ever, with more manufacturers bringing devices and talking

with hackers on how to improve the security on them. On top of that, there'll be other manufacturers attending simply to sit down and learn from hackers on how they can make their products more secure. To learn more about all this, you can visit the website, Iamthecavalry.org, or to learn more about the device lab, go to villageb.io. We're going to take a quick break here, but stay with us because when we get back, we hear another pen test story from Ed. This episode is sponsored by Shopify. The new year is a great time to ask yourself, what if? When I was thinking, what if I start a podcast? My focus was on finding a catchy name, some cool stories, and working out the best way to record. But oh, so much more goes into making a podcast than that.

If you're thinking, what if I start my own business? Don't be scared off, because with Shopify, you can make it a reality. Shopify makes it simple to create your brand, open for business, and get your first sale. Get your store online easily with thousands of customizable drag-and-drop templates. And Shopify helps you manage your growing business. Shipping, taxes, and payments are all visible from one dashboard, allowing you to focus on the important stuff. So what happens if you don't act now and someone beats you to the idea? The best time to start your new business is now with Shopify. Your first sale is closer than you

think. Established in 2025. That has a nice ring to it, doesn't it? Sign up for your $1 per month trial period at shopify.com slash darknet. Go to shopify.com slash darknet and start selling with Shopify today. Shopify.com slash darknet and start selling with Shopify today. Shopify.com slash darknet. Ed Skotis, SANS instructor and penetration tester has done a lot of security assessments. And there was one where he was hired by a toy company to do a security assessment on a toy. This toy company had a new talking doll that had some electronics in it, and they wanted to put this toy on the shelves and in the hands of kids and wanted Ed to test it to make sure there was no serious security problems.

This specific toy had an interface that was Bluetooth low energy, so BLE. It had a Wi-Fi interface on the toy. It also had an infrared interface on this toy. So it's for children, right? Now, of course, that's communicating with some little controller somewhere in the house. So that's another device that you get to test. Of course, the controller itself, and maybe even the toy, has a mobile application that's on your phone or tablet. So that's another thing you get to test. So you've got the devices, you've got the wireless communications protocol, you've got the mobile app, you've got, usually there's a cloud-based service on the other side with an API and a web interface.

Oh my gosh, all these technologies, it's fantastic. Even on the devices themselves, they've got chips with firmware that you can analyze. This is a cornucopia of stuff to look at. And so what was your task here? Our task was to hack it all and to see if there were significant security risks to privacy, safety, confidentiality, and so forth in the whole infrastructure. So all the way from child's toy device up to cloud-based service with various APIs. So Ed and his team got an early version of this toy in their hands to test it thoroughly.

And they just walked through it like a normal penetration test, hitting the toy on all its communication ports to see what it would respond to. And they were going to watch the traffic coming in and out of the toy to make sure it was all encrypted and secure. So, you know, we're doing this test and it's fun. We're loving it. And we found a replay vulnerability. So, you know, from a cryptographic perspective, a replay vulnerability is when you have information going from one system to another system.

And you can, so it's, you know, being sent in a packet that in this case was wireless. So we could, we could sniff that packet and capture it. And in a replay attack, you simply replay the packet that you captured. A replay attack is when an attacker captures a packet and then is able to send that packet again themselves whenever they wanted. I've seen this in action when people tried to hack a car remote. You know, those little devices on the car keys that when you push the button, it locks or unlocks the doors. Well, when you push unlock, that sends a wireless signal to the car, which says, unlock the doors. It's sometimes possible to use another radio to capture that wireless signal that the remote sent. And so you've eventually captured

the unlock code that's used to unlock the car. So now that you have that, you can just replay that packet back, sending it to the car and unlock the car doors whenever you want. That's how a replay attack works. And Ed found this toy was vulnerable to something like that. In this case, there was a way to get the doll to talk remotely through the phone app or something. He captured the packet using his computer, and he could just replay it whenever he wanted to make the doll talk. Kind of cool. Ed writes this finding up in a report and tells the toy company. The report read,

Finding. High-risk vulnerability. No replay prevention on this type of message sent across this protocol to the toy. And a customer came back to us and said, we don't care. We're going to ship. Look, Santa Claus is coming to town. We got to hit this deadline for production or else we're not going to have enough toys on the shelves for Christmas time. So we're going to ship with it. So, you know, and our team was pretty concerned about that because this is a pretty significant vulnerability. You could replay this message. And we got on a phone call with the customer and said,

look, somebody could replay this. And the customer said to us, because this was a doll, okay, and the doll, you know, could say things and do things and interact with the child. And we said, you know, if somebody could like capture a message going from the controller to the doll and then replay it. And the customer said,

so look, the doll can say goo-goo-ga-ga. So somebody captures that and replays it and it says goo-goo-ga-ga again. We don't care. Honestly, we're going to ship with that. So, you know, a little bit dejected, we got together, me and the folks on my team, and said, you know, we got going to ship with that. So a little bit dejected, we got together, me and the folks on my team, and said, we got to show that this thing could cause a bigger issue.

So we said, okay, let's think about messages that you could replay again and again that might be more interesting than Goo Goo Gaga. Now, the messages are all encrypted, so you can't really see what's in the message. But based on message length and also when it's sent in the protocol, we could get a sense of what each message was doing. In other words, Goo Goo Gaga is usually going to be about 400 bytes long, and it's usually sent in this context. So we can't look inside the message. It's encrypted. So we can't see that it says Goo Goo Gaga, but we can infer that. So we looked at it some more and said, okay, let's think about messages that cause the toy to burn a lot of CPU. So, you know, we're just playing messages again and again and again.

And we found this one particular message set that would make it use a lot of CPU on the doll. Now, what happens if you use a lot of CPU on the doll? Well, first off, I guess the battery will die faster, but who cares about that? Again, the customer would say, what happens if you use a lot of CPU on the doll? Well, first off, I guess the battery will die faster, but who cares about that? Again, the customer would say, I don't care, right? But if you play enough of these messages quickly enough, the doll starts to heat up. So now I wish I could tell you we had the doll catch on fire, but that was not the case. The doll did not catch on fire, but our initial report said there is a significant chance that someone could scald a child. Now, remember, a customer said, Goo Goo Gaga, I don't care.

When they saw scald a child in the report, their lawyers said, you know, thank you for finding this significant issue, which we will absolutely resolve. Please remove the phrase scald a child from the report. So we did, and they did fix it before they shipped it. But I mean, the point there is you need to communicate as a security professional risks in terms that a customer understands and it maps to their business model. Because if you're not, if you say replay attack, they're like, well, I don't think I'm getting evaluated on whether I have a replay attack or not. But you are getting evaluated as to whether your toy is any safe in the hands of a child. So I'm not saying you want to spread fear, uncertainty, and doubt or anything like that. But be careful to not focus on just sort of the technical aspect of a finding in a pen test,

but think of the implications to the business, to safety, to the reality of people, you know? That's what's important. It's always interesting how far you need to go as a penetration tester to prove your point. Sometimes just finding a vulnerability and reporting it is not enough. Sometimes you need to demonstrate how the vulnerability can cause the company serious pain.

And I never know where that line is. Like sometimes I've seen bug bounty hunters report a vulnerability to a company and they say, oh, well, that's a non-issue for us. And then the bug hunter says, okay, if it's a non-issue, then I'm going to publish this publicly. Now suddenly the company does care about it. Or maybe they still don't care and the bug gets published publicly and then people start exploiting it and it becomes a big problem. And it sometimes takes that sort of public pressure to get a company to move and fix the problems. The visionary companies are the ones that recognize the significance of a security problem with the first report and resolves it right away. And, you know, you don't want to be too hyperbolic in your reports, but you want to explain the risk in an appropriate way.

So it's exciting. I mean, it's fun to do what we do. It really is cool. You know, and if we go back to that story I told you when I was a little kid, I never imagined that hacking and penetration testing was a job. Sometimes I think back and I almost want to pinch myself and say, this is what I get to do for a living. That's amazing. If you were to tell 10-year-old Eddie Skotis, because I went by Eddie back then when I was 10, that someday you would do this for a living, it would have blown my 10-year-old mind. You know, that's a thing? That's what you do in the future? How cool is that? A big thank you to Ed Skotis for coming on the show and sharing these stories with us.

Ed is still working with SANS, bringing up the next generation of instructors there, and also focusing on his own company called CounterHack. Also, thanks to Beau Woods for telling us about medical device hacking. You can learn more about what he's working on by going to Iamthecavalry.org or visiting villageb.io. Hey, if you didn't know, I've been publishing episodes of this show to YouTube and I've added some animations to each episode and it's kind of cool to check out. Just search for Darknet Diaries or Jack Reciter on YouTube and you'll find it. And check out what I've been posting there and tell me what you think. I always love hearing from listeners. This show is made by me, the ear-piercing Jack Recider. Sound design by the downbeat Andrew Merriweather. Editing help this episode by the snipper Damien. And our theme music

is by the paper tiger, Breakmaster Cylinder. One time I got hired to work somewhere and they told me what the starting pay was, but then they said in 90 days, the pay gets increased by 20%. So I said, okay, great. Then I'd like to start in 90 days. This is Darknet Diaries.