Transcription performed by LeahTranscribes[START OF RECORDING]
JACK: Sometimes I think I’m just one click away from a total catastrophe. The perfectly-crafted e-mail at the perfect time can cause major damage. Just look at what happened to Barbara Corcoran. She’s the judge on the TV show Shark Tank. Here’s a clip from CBS this morning. HOST: 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 e-mail about an invoice, and it appeared to be from Corcoran’s assistant, a trusted source, a proving payment for a real estate renovation.
JACK: So, her bookkeeper was told to send about $400,000 to someone regarding some real estate expense. The e-mail 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 e-mail. Barbara lost $400,000 because of a single spoofed e-mail. This hack wasn’t technical. It was manipulating a person, not a machine or a computer. [INTRO MUSIC] I fear that we may always be vulnerable to this type of attack. We can’t update the firmware in our brain. 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 e-mails. I think people may have bigger vulnerabilities than computers.
(INTRO): These are true stories from the dark side of the internet. I’m Jack Rhysider. This is Darknet Diaries. [INTRO MUSIC ENDS]
JACK: My guest in this episode is Ed Skoudis.
ED: So, I am Ed Skoudis. I am an instructor with the SANS Institute. I am a penetration tester and founder of Counter Hack, 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, bulletin board systems, with dial-up back in the day. That’s when I kinda 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 masters in that, and while I was in school, we did hacking. We had – 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 kinda stuff. But again, I never realized there was a career out of that.
JACK: After college, he went to work at Bell Labs which was a bit of a magical place for him. This put him on a path to work in IT and security. [MUSIC] 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. This was going well, in fact, so well that other companies started asking him to do penetration tests for them.
ED: 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. I was doing penetration testing for them.
JACK: He moved around, working for a few different companies, all while doing security assessments.
ED: Ultimately, I started doing talks in the cyber-security industry at various events. I spoke at Defcon, I spoke at some of the other conferences, and I always wanted to teach for SANS.
JACK: The SANS Institute is one of the earliest places you could go to get cyber-security training, and it’s known for having great instructors and courses.
ED: Finally – this was in 1999 – I got an e-mail from the folks at SANS. They had seen my talk somewhere. 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 was 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 gotta give it my all. So, that was my first presentation for SANS. It was about a two-hour talk on hacking in 1999.
JACK: This went great. Just after that, SANS brought him on board and for the next two decades, he was a full-time SANS instructor.
ED: I was teaching for SANS six days at a time between twelve and fifteen 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 the cyber-security work. 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.
JACK: 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 twenty-six years, Ed has been doing penetration testing, hacking into networks and buildings, to demonstrate where the security weak points are. 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.
ED: [MUSIC] It was a penetration test that was 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.
JACK: 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 onsite 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. 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 it.
ED: 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.
JACK: 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 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. So, Ed had to listen to the client 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. [MUSIC] So, the first thing he wanted to do was figure out what computers were in that range.
ED: You’re mapping your attack surface at this point, right? So, you’re using various tools, NMAP 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 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 gotta tell you, Jack, the external web-based presence and internet presence of this hospital was pretty darn solid.
JACK: Hm, 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 were 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.
ED: Well, there were some low-level vulnerabilities, but nothing exploitable. I’ve never had a pen test where we found nothing, but nothing big. Now, so we found nothing big on the external side.
JACK: Which meant the hospital did well at securing their outer digital perimeter.
ED: But we also, as a second phase of the test, [MUSIC] 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 attacker has got control. Or maybe they clicked on a spear-phishing e-mail and got compromised. The point is, the second phase of this test was the really important one, ‘cause 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?
JACK: 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. They wanted to know what could a hacker do if they got into the network?
ED: 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, VPN’d in. So, we log in. 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 [MUSIC] 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? 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 kinda throttling your scans, going slow and methodically to see if you can evade detection. What we usually do is we try to go slow at first, but 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 tolerance bar where oh, now we see you? Because if we can fly under that radar screen, so could an actual malicious attacker.
JACK: 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 in to 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 live 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. 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, [MUSIC] a vulnerability on one of their computers.
ED: Big one; big, honking vulnerability. It was 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. Some vendors do not alert their customers to say hey, there’s a patch necessary for this system. ‘Cause you brought – as a hospital, you bought XYZ brain scanner or whatever it happens to be, and that’s what you have. It says ‘XYZ brain scanner’ on the side of the machine. You don’t know that inside there it’s a Windows 2016 server. That’s not what you bought, but it is. 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.
JACK: 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 gotta have some kind of operating system or software on them in order for them to work, right? 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. 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. There’s a possibility that when you exploit a vulnerability, it causes the computer to crash or become unstable, and maybe even reboot.
ED: 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? They said sure, that was included within the scope of our test.
JACK: Okay, green light to exploit it. So, Ed’s team loaded up the exploit and aimed it at the system, and bingo. [MUSIC] 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. 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.
ED: So, we exploited it and we got shell on the system. The customer’s like okay, fine, fine. Then I said we’re looking around on the machine and we found some software on that system that controls a surgical laser. It’s the nature of the software package. They said oh, what kind of surgical laser? 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. [MUSIC] 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 it and we’re all sitting there thinking hm, wonder what’s going on there now. After about a minute and a half which felt like an hour, they un-muted and said hey guys, we’re gonna have to get back to you maybe later today or tomorrow, so we’ll call you back. Alright, so we finished the call. It’s like, that was abrupt. We didn’t even finish our status discussion and suddenly they are gonna 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, turns out that system was used to control a surgical laser. We said well, we figured that ‘cause it was – the software was installed on it to do that.
They said yeah, and we looked it up and it turns out it was actually being used in surgery when you guys were on it. [MUSIC] Then we’re like oh, everything turn out okay? Yes, everything is fine. No one got hurt. That’s good. But you gotta be super careful on this kinda 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 Rasch. 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 twenty-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? Right, so Mark goes through this whole list of – yeah, and we were fine, but I bring this story up because you gotta be careful. There are real-world implications to the systems that we’re touching as cyber-security 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. Surgical lasers are used for all kinds of things. 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. I’m looking at that thinking – wondering who’s got shell on this system? It wasn’t the same kind of thing that we had tested in the hospital earlier; it was a different hospital, different system, but it made me – 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.
JACK: 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 a 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? A few years ago, I found someone who is hacking on medical devices.
BEAU: 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, pro-active manner with medical device makers, with the automotive industry, with aviation, and in other places where bits and bytes meet flesh and blood.
JACK: Defcon is the annual hacker conference in Las Vegas. This interview is actually from a few years back. What Beau helps organize is the Biohacking Village Device Lab. Now, the Biohacking Village at Defcon 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 Beau is involved with the Device Lab. This is where Defcon attendees can get their hands on medical devices that are used in places like hospitals.
BEAU: This year at Defcon 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.
JACK: So they donated to you to test these.
BEAU: They’re bringing their own devices and asking researchers to engage. So, they see it – so, they way we’re – 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 a Capture the Flag that the Mayo Clinic built, for instance. We’ve got – the FDA is participating. 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.
JACK: You can guess it wasn’t easy for Beau 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? [MUSIC] 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. For instance, some people would give talks at Defcon on how to hack things like insulin pumps and cause a patient to overdose. 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.
BEAU: 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. 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 willing allies and willing teammates in the healthcare community really quickly, there was a lot of uptake fast. So we started working with people, we got probably half-a-dozen to ten medical device companies that I’m on a first-name basis with their product security teams, right? Which is a really cool thing.
JACK: So, this was a long way to go for Beau 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.
BEAU: Yeah, I went up yesterday after day one and asked everybody; day one, I know it’s a scary thing to come into 25,000 hackers, right? What did you think? I got a lot of very happy laughs. They seem overjoyed with the results, you know? [MUSIC] 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 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 had 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 man, if I was a bad guy, I would have given up by now. So, I think that’s a testament to the shifting perceptions to hopefully snap more into place with reality on both sides.
JACK: 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, or how – what goes on there?
BEAU: 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 bio-medical contractor to come and apply the updates that exist. But that’s – it’s a lot of hand-offs 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 kinda the – one of the reasons why we have so many vulnerabilities in our healthcare, [MUSIC] is not that there aren’t more secure versions of the operating – of the medical devices available, but that they haven’t been taken up by the hospitals themselves.
JACK: Huh. Well, this year at Defcon, 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 will 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 gonna take a quick break here, but stay with us because when we get back, we hear another pen test story from Ed. Ed Skoudis, 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.
ED: 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. 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 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.
JACK: So, what was your task here?
ED: 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.
JACK: [MUSIC] 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. They were gonna watch the traffic coming in and out of the toy to make sure it was all encrypted and secure.
ED: So, we’re doing this test and it’s fun. We’re loving it, we’re – and we found a replay vulnerability. So, 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 being sent in a packet that in this case was wireless. So, we could sniff that packet and capture it. In a replay attack, you simply replay the packet that you capture.
JACK: 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. 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…
ED: Finding; high-risk vulnerability. No replay prevention on this type of message sent across this protocol to the toy. The customer came back to us and said we don’t care; we’re gonna ship. Look, Santa Claus is coming to town. We gotta hit this deadline for production or else we’re not gonna have enough toys on the shelves for Christmastime, so we’re gonna ship with it. So, our team was pretty concerned about that ‘cause this is a pretty significant vulnerability. You could replay this message. We got on a phone call with the customer and said look, somebody could replay this. The customer said to us – ‘cause this was a doll, okay? The doll could say things and do things and interact with the child. We said somebody could capture a message going from the controller to the doll and then replay it. 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 gonna ship with that. So, a little bit dejected, we got together, me and the folks on my team, and said you know, we gotta show that this thing could cause a bigger issue.
[MUSIC] So, we said okay, let’s think about messages that you could replay again and again that might be more interesting than goo-goo-ga-ga. So, 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-ga-ga is usually gonna 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-ga-ga, 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, 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 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, the customer said goo-goo-ga-ga; I don’t care. When they saw ‘scald a child’ in the report, their lawyers said 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 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. ‘Cause 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’s 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 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.
JACK: 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. 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. Then the bug hunter says okay, if it’s a non-issue, then I’m gonna 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. 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.
ED: 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. It’s fun to do what we do. It really is cool. 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 ten-year-old Eddie Skoudis – ‘cause I went by Eddie back then when I was ten – that someday you would do this for a living, it would have blown my ten-year-old mind. That’s a thing? That’s what you do in the future? How cool is that?
(OUTRO): [OUTRO MUSIC] A big thank-you to Ed Skoudis 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 Counter Hack. 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 kinda cool to check out. Just search for Darknet Diaries or Jack Rhysider on YouTube and you’ll find it. 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 Rhysider. Sound design by the downbeat Andrew Meriwether, editing help this episode by the snipper, Damienne, 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 ninety days, the pay gets increased by 20%. So I said okay, great; then I’d like to start in ninety days. This is Darknet Diaries.
[END OF RECORDING]