WEBVTT 00:00:00.383 --> 00:00:05.920 JACK: Sometimes I think I’m just one click away from a total catastrophe. 00:00:05.920 --> 00:00:12.720 The perfectly-crafted e-mail at the perfect time can cause major damage. Just look at 00:00:12.720 --> 00:00:17.280 what happened to Barbara Corcoran. She’s the judge on the TV show Shark Tank. Here’s 00:00:17.280 --> 00:00:20.720 a clip from CBS this morning. HOST: I’ve got a very important 00:00:20.720 --> 00:00:26.400 warning of a financial scam here. One of the stars of the reality show Shark Tank says she 00:00:26.400 --> 00:00:30.960 was a victim of – they’re calling it a phishing scam, but really it’s a digital con job. Barbara 00:00:30.960 --> 00:00:36.080 Corcoran; this is what happened. Last week her bookkeeper received an e-mail about an invoice, 00:00:36.080 --> 00:00:40.000 and it appeared to be from Corcoran’s assistant, a trusted source, a proving 00:00:40.000 --> 00:00:45.840 payment for a real estate renovation. JACK: So, her bookkeeper was told to send about 00:00:45.840 --> 00:00:52.000 $400,000 to someone regarding some real estate expense. The e-mail looked like it came from 00:00:52.000 --> 00:00:57.040 Barbara’s assistant, a trusted person, and since Barbara was a real estate investor, 00:00:57.040 --> 00:01:03.760 this looked like a typical money transfer. So, her bookkeeper wired the money to this person, 00:01:03.760 --> 00:01:10.160 and it turns out it was all just a phishing e-mail. Barbara lost $400,000 because of a 00:01:10.160 --> 00:01:16.480 single spoofed e-mail. This hack wasn’t technical. It was manipulating a person, not a machine or 00:01:16.480 --> 00:01:21.600 a computer. [INTRO MUSIC] I fear that we may always be vulnerable to this type of attack. 00:01:21.600 --> 00:01:27.840 We can’t update the firmware in our brain. Yes, we can be educated on how to spot this type of thing 00:01:27.840 --> 00:01:33.440 and avoid it, but even some of the most educated people on phishing attacks and social engineering 00:01:33.440 --> 00:01:40.000 have fallen victim to phishing e-mails. I think people may have bigger vulnerabilities 00:01:40.000 --> 00:01:45.440 than computers. (INTRO): 00:01:45.440 --> 00:01:52.240 These are true stories from the dark side of the internet. 00:01:52.240 --> 00:01:56.160 I’m Jack Rhysider. This is Darknet 00:01:56.160 --> 00:02:11.440 Diaries. [INTRO MUSIC ENDS] JACK: 00:02:11.440 --> 00:02:17.920 My guest in this episode is Ed Skoudis. ED: So, I am Ed Skoudis. I am an instructor 00:02:17.920 --> 00:02:24.720 with the SANS Institute. I am a penetration tester and founder of Counter Hack, which is a security 00:02:24.720 --> 00:02:30.240 consulting firm focused on penetration testing, vulnerability assessment, and red teaming. 00:02:30.240 --> 00:02:38.000 I actually started as a kid. I remember I had – my first computer was a VIC-20. My second computer 00:02:38.000 --> 00:02:45.840 was a Commodore 64, and I was on the BBS scene, bulletin board systems, with dial-up back in 00:02:45.840 --> 00:02:52.240 the day. That’s when I kinda started hacking as a kid. I never imagined that there could be a career 00:02:52.240 --> 00:02:58.320 associated with this. I ended up going to college and studied electrical engineering undergraduate 00:02:58.320 --> 00:03:04.880 and information networking as a graduate degree. I got a masters in that, and while I was in school, 00:03:04.880 --> 00:03:10.080 we did hacking. We had – we were on the internet, we had a bunch of UNIX computers at the time and 00:03:10.080 --> 00:03:16.880 some very, very early Windows machines, and we would hack them in the computer centers, 00:03:16.880 --> 00:03:25.120 kind of having fun, not doing anything explicitly evil or malicious. It was more prank kinda stuff. 00:03:25.120 --> 00:03:27.440 But again, I never realized there was a career out of that. 00:03:27.440 --> 00:03:32.720 JACK: After college, he went to work at Bell Labs which was a bit of a magical place for him. 00:03:32.720 --> 00:03:38.800 This put him on a path to work in IT and security. [MUSIC] Early on, he was doing penetration testing 00:03:38.800 --> 00:03:43.200 in his career, which is where they wanted to see if he could find a security flaw somewhere 00:03:43.200 --> 00:03:48.160 that would give him unauthorized access into something. This was going well, in fact, 00:03:48.160 --> 00:03:52.400 so well that other companies started asking him to do penetration tests for them. 00:03:52.400 --> 00:03:56.720 ED: So, some of the banks came to us and said can you start doing this for us? So, 00:03:56.720 --> 00:04:01.760 I started working with a lot of the banks, especially big New York City banks. I was 00:04:01.760 --> 00:04:05.200 doing penetration testing for them. JACK: He moved around, working for a few 00:04:05.200 --> 00:04:08.240 different companies, all while doing security assessments. 00:04:08.240 --> 00:04:15.920 ED: Ultimately, I started doing talks in the cyber-security industry at various 00:04:15.920 --> 00:04:22.800 events. I spoke at Defcon, I spoke at some of the other conferences, and 00:04:22.800 --> 00:04:27.040 I always wanted to teach for SANS. JACK: The SANS Institute is one of the 00:04:27.040 --> 00:04:30.960 earliest places you could go to get cyber-security training, and it’s known 00:04:30.960 --> 00:04:36.880 for having great instructors and courses. ED: Finally – this was in 1999 – I got an e-mail 00:04:36.880 --> 00:04:42.880 from the folks at SANS. They had seen my talk somewhere. It was May of 1999 in Baltimore Inner 00:04:42.880 --> 00:04:49.840 Harbor; I got my first opportunity to speak for SANS, and I was nervous, I was excited. 00:04:49.840 --> 00:04:54.880 I was presented in this room with 300 people in the room, so this was a big audience for 00:04:54.880 --> 00:05:00.800 me at the time. The guy who ran SANS was Stephen Northcutt. He was in the room, 00:05:00.800 --> 00:05:07.200 Alan Paller, the guy who founded SANS was in the room and it’s like, I gotta give it my all. So, 00:05:07.200 --> 00:05:12.880 that was my first presentation for SANS. It was about a two-hour talk on hacking in 1999. 00:05:12.880 --> 00:05:20.080 JACK: This went great. Just after that, SANS brought him on board and for the next two decades, 00:05:20.080 --> 00:05:26.000 he was a full-time SANS instructor. ED: I was teaching for SANS six days at a time 00:05:26.000 --> 00:05:32.880 between twelve and fifteen times a year. Now, SANS has a policy that you can’t be just a SANS 00:05:32.880 --> 00:05:38.160 instructor. It’s this instructor-practitioner model. So, they want to take people who are 00:05:38.160 --> 00:05:44.480 practitioners. You have to be active in doing the cyber-security work. I was doing penetration 00:05:44.480 --> 00:05:50.160 testing and still am, but then also teach, because they don’t want to have people who are merely book 00:05:50.160 --> 00:05:57.040 smart. So, from that point that I became a SANS instructor, I was still working at this offshoot 00:05:57.040 --> 00:06:02.320 of the Baby Bells doing consulting. JACK: The Baby Bells; that’s when AT&T got 00:06:02.320 --> 00:06:06.480 too big and the government forced them to break up into nine different companies. These nine smaller 00:06:06.480 --> 00:06:11.760 companies were called Baby Bells. So, for the past twenty-six years, Ed has been doing penetration 00:06:11.760 --> 00:06:16.720 testing, hacking into networks and buildings, to demonstrate where the security weak points are. 00:06:16.720 --> 00:06:20.800 Today, he’s going to share with us some of these stories that he’s experienced over the years. 00:06:20.800 --> 00:06:24.640 So come on, let’s tag along as he tells us about one of the penetration tests he was 00:06:24.640 --> 00:06:27.120 involved with. ED: [MUSIC] 00:06:27.120 --> 00:06:33.200 It was a penetration test that was my team was doing several years ago, and it was of a hospital. 00:06:33.200 --> 00:06:37.840 Hospital environment, and we had our defined scope. It’s very important for 00:06:37.840 --> 00:06:42.320 you to have a good, defined scope. JACK: A hospital; okay. With these sorts of 00:06:42.320 --> 00:06:48.240 things, you’ve got to be careful and define your scope very precisely. The hospital wanted him to 00:06:48.240 --> 00:06:53.200 test their network only. There was no physical component to this, which means he didn’t need 00:06:53.200 --> 00:06:58.640 to come onsite at all or try to sneak into any unauthorized parts of the hospital. 00:06:58.640 --> 00:07:04.240 Now, he broke down this penetration test into two phases. The first phase was to test the outside 00:07:04.240 --> 00:07:09.120 security of the network from the internet as if you were an attacker on the other side of 00:07:09.120 --> 00:07:14.400 the world. Clearly, this hospital has a large front gate to their network, which should prevent 00:07:14.400 --> 00:07:19.840 any unauthorized connections from getting in. But a penetration test will determine whether or not 00:07:19.840 --> 00:07:25.520 there are any holes in this gate. The second phase was that they’d be given access to a computer 00:07:25.520 --> 00:07:30.240 inside the hospital’s network to test what kind of stuff someone could do if they got it. 00:07:30.240 --> 00:07:33.360 ED: So, it’s a hospital environment. They gave us a set of IP addresses that 00:07:33.360 --> 00:07:37.040 were internet-accessible that we should test, they gave us a set of addresses on 00:07:37.040 --> 00:07:41.840 the internal network that we were to test. JACK: It’s important that they stay within scope. 00:07:41.840 --> 00:07:48.800 These IPs and only these IPs were allowed to be attacked. They surely didn’t want to attack any 00:07:48.800 --> 00:07:55.520 IP that could cause actual harm to a patient. But this is always a tricky balance when it comes to 00:07:55.520 --> 00:08:02.240 doing penetration tests like this. Do you include your most critical resources, the ones that could 00:08:02.240 --> 00:08:07.920 cause loss of life if they were to be damaged? Yeah, of course include those. It’s imperative 00:08:07.920 --> 00:08:14.560 that those are very secure systems. But sometimes these aren’t tested because they could cause loss 00:08:14.560 --> 00:08:21.040 of life if something went wrong. It’s tricky, and what about backup or development systems? I mean, 00:08:21.040 --> 00:08:27.040 by definition, a dev server is a work in progress, so do you run a security assessment on systems 00:08:27.040 --> 00:08:31.680 that are works in progress or systems that you know haven’t been updated for a while? Heck yeah; 00:08:31.680 --> 00:08:37.280 if it’s exposed to the internet, you must. Any and every door or window into your network should be 00:08:37.280 --> 00:08:44.480 tested, right? If it’s a potential attack surface, then someone with malicious intent may find it 00:08:44.480 --> 00:08:52.000 and exploit it. But companies and hospitals aren’t always so open to having everything attacked. So, 00:08:52.000 --> 00:08:57.440 Ed had to listen to the client on what was allowed to be attacked and what wasn’t. The hospital gave 00:08:57.440 --> 00:09:04.080 him a range of IP addresses and said see if you can find any vulnerabilities within this range 00:09:04.080 --> 00:09:08.080 and stick only to that. [MUSIC] So, the first thing he wanted to do was figure 00:09:08.080 --> 00:09:12.400 out what computers were in that range. ED: You’re mapping your attack surface at this 00:09:12.400 --> 00:09:18.480 point, right? So, you’re using various tools, NMAP is a very popular one just to find out which 00:09:18.480 --> 00:09:26.000 systems are available, what is their set of ports that are open, and then ultimately moving on to 00:09:26.000 --> 00:09:30.800 finding a list of potential vulnerabilities with them. Now, some of the ports that are 00:09:30.800 --> 00:09:36.880 most interesting of course to us are associated with HTTP and HTTPS, right? Those web interfaces 00:09:36.880 --> 00:09:43.040 often have a lot of complexity behind them, and with complexity often comes vulnerabilities. So, 00:09:43.040 --> 00:09:50.640 we enumerated that attack surface, found the set of ports that were open, started interacting with 00:09:50.640 --> 00:09:58.080 systems, and I gotta tell you, Jack, the external web-based presence and internet presence of this 00:09:58.080 --> 00:10:02.720 hospital was pretty darn solid. JACK: Hm, this is also a tricky spot 00:10:02.720 --> 00:10:09.360 for penetration testers to be in. If you try hacking into a network but come up empty-handed, 00:10:09.360 --> 00:10:15.280 it’s hard to know if you tried hard enough. Maybe there’s some big, glaring vulnerability that you 00:10:15.280 --> 00:10:20.320 just didn’t see, and if you tell the hospital we tested everything and it’s all good but then a 00:10:20.320 --> 00:10:27.440 week later someone exploits something easy, then yeah, your reputation suffers for sure. So, Ed and 00:10:27.440 --> 00:10:34.080 his team had to be very thorough and go through the entire outside attack surface more carefully. 00:10:34.080 --> 00:10:38.880 So, they did things like figure out what applications are accessible from the internet, 00:10:38.880 --> 00:10:43.680 then looking up what the default passwords are for those applications and trying to log in with them, 00:10:43.680 --> 00:10:48.320 but that didn’t work. Then they’re trying to manipulate the websites to see if those 00:10:48.320 --> 00:10:52.560 websites were vulnerable to cross-site scripting attacks or SQL injection attacks. 00:10:52.560 --> 00:10:57.920 Basically, Ed has a checklist of things to test on every system or computer they encounter, 00:10:57.920 --> 00:11:03.040 testing to make sure that none of the servers he’s found are vulnerable to the most well-known 00:11:03.040 --> 00:11:08.960 type of attacks. But even after going through the systems one by one, checking them all, he wasn’t 00:11:08.960 --> 00:11:13.200 able to find any problems on the public-facing parts of the hospital’s network. 00:11:13.200 --> 00:11:17.520 ED: Well, there were some low-level vulnerabilities, but nothing exploitable. 00:11:17.520 --> 00:11:24.320 I’ve never had a pen test where we found nothing, but nothing big. Now, so we found 00:11:24.320 --> 00:11:28.800 nothing big on the external side. JACK: Which meant the hospital did well at 00:11:28.800 --> 00:11:33.520 securing their outer digital perimeter. ED: But we also, as a second phase of the 00:11:33.520 --> 00:11:38.320 test, [MUSIC] they gave us access to an internal system and from there, 00:11:38.320 --> 00:11:44.560 they wanted us to map the inside of the hospital. So there, we were posing as one of many potential 00:11:44.560 --> 00:11:49.840 attacker types. One is somebody who physically breaks into the hospital and connects into, 00:11:49.840 --> 00:11:53.680 say, an Ethernet jack. Another one is somebody who is in the hospital 00:11:53.680 --> 00:11:58.400 and actually just accesses the Wi-Fi of the hospital, so we could start looking around. 00:11:58.400 --> 00:12:04.800 Another one, another attacker that we’re posing as, is maybe there’s a user in the hospital who 00:12:04.800 --> 00:12:09.520 carried in a laptop that had malware on it, so we are the controllers of that malware. 00:12:09.520 --> 00:12:18.000 Or maybe it’s somebody in the hospital who surfed the internet with a vulnerable browser and got 00:12:18.000 --> 00:12:23.840 hacked on their system so the browser itself is now where the attacker has got control. Or 00:12:23.840 --> 00:12:28.000 maybe they clicked on a spear-phishing e-mail and got compromised. The point is, the second phase 00:12:28.000 --> 00:12:33.680 of this test was the really important one, ‘cause it’s saying okay, the attacker has gotten malware 00:12:33.680 --> 00:12:38.880 in the environment either by walking through the hospital doors or compromising something inside 00:12:38.880 --> 00:12:43.280 the hospital. What can you find now? JACK: What they did was they gave him a 00:12:43.280 --> 00:12:48.400 remote connection into their network, a VPN connection into the hospital which makes it 00:12:48.400 --> 00:12:53.360 seem as if he’s actually inside the hospital. They wanted to know what could a hacker do 00:12:53.360 --> 00:12:56.960 if they got into the network? ED: The way we structure these tests is 00:12:56.960 --> 00:13:02.240 we want to look like a brand-new employee in your environment. We want the access of a low-level 00:13:02.240 --> 00:13:06.640 rank-and-file employee. Don’t give us admin access, don’t give us anything special. We just 00:13:06.640 --> 00:13:13.280 want to be on the internal network, VPN’d in. So, we log in. There’s multi-factor authentication. 00:13:13.280 --> 00:13:20.080 Sometimes we’ll even have the customer send us an image of their standard corporate laptop so 00:13:20.080 --> 00:13:25.200 we can log in using exactly the same software mix, exactly everything that a rank-and-file employee 00:13:25.200 --> 00:13:31.280 would be issued. So, we’re remotely accessing that environment, and then [MUSIC] we move back into 00:13:31.280 --> 00:13:34.960 the stages we talked about for the remote test. You start enumerating the environment according 00:13:34.960 --> 00:13:40.320 to your scope, you’re scanning to see which systems are available on the internal network, 00:13:40.320 --> 00:13:44.400 then you’re looking at their attack surface. What ports do they have open? What operating 00:13:44.400 --> 00:13:49.600 systems do they have? What vulnerabilities might they have? You’re trying to do that 00:13:49.600 --> 00:13:55.920 usually on a low-and-slow basis at first. You’re not going in there with guns blazing. You’re kinda 00:13:55.920 --> 00:14:00.240 throttling your scans, going slow and methodically to see if you can evade 00:14:00.240 --> 00:14:06.320 detection. What we usually do is we try to go slow at first, but then we ramp it up over time 00:14:06.320 --> 00:14:13.200 to see where we get noticed. What is your tolerance for activity on your network 00:14:13.200 --> 00:14:17.840 where people are probing you that you don’t notice it yet, and what’s that tolerance bar 00:14:17.840 --> 00:14:22.320 where oh, now we see you? Because if we can fly under that radar screen, 00:14:22.320 --> 00:14:29.680 so could an actual malicious attacker. JACK: The head of the hospital’s security 00:14:29.680 --> 00:14:34.160 team knew that they were doing a penetration test, and part of this test was to see if the 00:14:34.160 --> 00:14:38.800 internal security team to the hospital would pick up on someone doing something they shouldn’t be 00:14:38.800 --> 00:14:44.160 doing. If someone tried to log in to the domain controller and failed a hundred times in a row, 00:14:44.160 --> 00:14:49.200 would anyone see? If someone tried enumerating and looking for vulnerabilities on computers, 00:14:49.200 --> 00:14:54.400 would that trigger any alerts? Ed knew the security team would be keeping a lookout and 00:14:54.400 --> 00:15:01.440 wanted to fly below the radar to not trip any alarms. So, they map out the attack surface and 00:15:01.440 --> 00:15:07.440 see what computers look live and what ports are open, and start looking at those computers to see 00:15:07.440 --> 00:15:14.240 if they are vulnerable. At the same time, they’re also running a slow and quiet vulnerability scan, 00:15:14.240 --> 00:15:19.840 slow and quiet to avoid tripping any alarms the security team might see. What a vulnerability scan 00:15:19.840 --> 00:15:25.600 will do is it’ll send packets to each system to try to request information from that computer. So, 00:15:25.600 --> 00:15:30.560 if you point a vulnerability scanner at a website, it’ll try real hard to figure out what operating 00:15:30.560 --> 00:15:34.720 system that website is using, what version of software it’s running, and then from there, 00:15:34.720 --> 00:15:39.840 the vulnerability scanner will look up to see if those versions have any known vulnerabilities in 00:15:39.840 --> 00:15:46.080 them. After letting the vulnerability scanner run for a few hours, it found something, [MUSIC] a 00:15:46.080 --> 00:15:51.920 vulnerability on one of their computers. ED: Big one; big, honking vulnerability. It was 00:15:51.920 --> 00:15:57.440 a system that was missing a common patch. It was a patch from Microsoft that they had released 00:15:57.440 --> 00:16:03.760 about two years earlier, but here’s the deal; on medical systems, oftentimes it can be hard 00:16:03.760 --> 00:16:10.720 to get them patched because they’re so feeble and so sensitive, they don’t want to break anything. 00:16:10.720 --> 00:16:15.280 Some vendors do not alert their customers to say hey, there’s a patch necessary for this system. 00:16:15.280 --> 00:16:23.040 ‘Cause you brought – as a hospital, you bought XYZ brain scanner or whatever it happens to be, 00:16:23.040 --> 00:16:28.080 and that’s what you have. It says ‘XYZ brain scanner’ on the side of the machine. 00:16:28.080 --> 00:16:33.040 You don’t know that inside there it’s a Windows 2016 server. 00:16:33.040 --> 00:16:40.080 That’s not what you bought, but it is. Your vendor who sold you the brain scanner has to tell you 00:16:40.080 --> 00:16:43.920 that now it’s time to patch or to set something up, some sort of service contract or something 00:16:43.920 --> 00:16:48.720 like that where that patch gets deployed. So, it was two years out of patch and we found this 00:16:48.720 --> 00:16:53.520 significantly exploitable flaw on it. JACK: This is something that always drives me 00:16:53.520 --> 00:16:58.560 nuts. So many of the systems we buy, we don’t do anything to keep them updated. 00:16:58.560 --> 00:17:02.880 Printers, for example; when’s the last time you’ve updated your printer’s operating system? 00:17:02.880 --> 00:17:06.480 They’ve gotta have some kind of operating system or software on them in order for them to work, 00:17:06.480 --> 00:17:11.760 right? Especially the ones that are online that you can send a print job to over the network. 00:17:11.760 --> 00:17:17.200 Some of these even run Windows or Linux operating systems. Now, in big companies, printers might be 00:17:17.200 --> 00:17:22.240 installed by some outside contractors. But even in those cases, contractors aren’t coming back 00:17:22.240 --> 00:17:27.120 every few months to update the software on them, and this is the case with many of the computers 00:17:27.120 --> 00:17:33.040 in our network; webcams, routers, smart TVs, and you can just imagine all the network-connected 00:17:33.040 --> 00:17:37.920 tools and instruments and computers that are in a hospital’s environment. 00:17:37.920 --> 00:17:43.200 Ed and his team found this vulnerability on some computer, but they didn’t know what this 00:17:43.200 --> 00:17:48.080 computer did. All they knew is that they found this computer to have a very high severity 00:17:48.080 --> 00:17:52.800 vulnerability. See, not all vulnerabilities are the same. Some are low-level; like, 00:17:52.800 --> 00:17:58.000 your system might have the wrong time or date on its internal clock. That could be a problem, 00:17:58.000 --> 00:18:04.560 but it’s not one that’s easily exploitable. But the vulnerability they found was a really bad one, 00:18:04.560 --> 00:18:10.240 one that they could easily exploit if they wanted to and get full control over that system. But they 00:18:10.240 --> 00:18:15.840 knew to be careful. This was a hospital, and at this point, they only found the vulnerability. The 00:18:15.840 --> 00:18:21.200 next step for them was going to be to exploit that vulnerability and get into that system. 00:18:21.200 --> 00:18:26.240 There’s a possibility that when you exploit a vulnerability, it causes the computer to crash 00:18:26.240 --> 00:18:31.120 or become unstable, and maybe even reboot. ED: We had a call with a customer saying hey, 00:18:31.120 --> 00:18:34.080 we’re scanning the environment, we found this on the internal network, 00:18:34.080 --> 00:18:39.920 we found a pretty critical vulnerability; can we exploit it? They said sure, that was 00:18:39.920 --> 00:18:44.480 included within the scope of our test. JACK: Okay, green light to exploit it. So, 00:18:44.480 --> 00:18:49.920 Ed’s team loaded up the exploit and aimed it at the system, and bingo. [MUSIC] Right away, 00:18:49.920 --> 00:18:54.880 they were able to get in and have full command line control over that system. 00:18:54.880 --> 00:19:00.160 Clearly this is a problem, and a penetration tester will call this a finding and document 00:19:00.160 --> 00:19:05.360 it and put it in the report. This is a problem because having command line access on another 00:19:05.360 --> 00:19:10.720 computer gives you all kinds of new capabilities. They can of course look around on that system to 00:19:10.720 --> 00:19:15.760 see if it has any sensitive information on it. They could look around for any cached passwords 00:19:15.760 --> 00:19:21.680 or patient records, and maybe they could use the trust of this computer to access another computer, 00:19:21.680 --> 00:19:25.840 because sometimes there are trust relationships built into a network which allow you to get 00:19:25.840 --> 00:19:30.640 somewhere that you couldn’t from your own laptop. While Ed’s looking around on this computer, 00:19:30.640 --> 00:19:34.480 he sees something and calls the customer. ED: So, we exploited it and we got shell on the 00:19:34.480 --> 00:19:40.960 system. The customer’s like okay, fine, fine. Then I said we’re looking around on the machine and we 00:19:40.960 --> 00:19:47.360 found some software on that system that controls a surgical laser. It’s the nature of the software 00:19:47.360 --> 00:19:53.200 package. They said oh, what kind of surgical laser? We told them what kind of surgical laser 00:19:53.200 --> 00:19:58.000 and they said what was that IP address again? So, we told them the IP address again. [MUSIC] 00:19:58.000 --> 00:20:03.840 This is our status call, right? They put us on mute for a second, so they muted their side; 00:20:03.840 --> 00:20:05.920 said we’ll get back to you in just one second, just hold on, let’s mute. 00:20:05.920 --> 00:20:11.680 So they muted it and we’re all sitting there thinking hm, wonder what’s going on there now. 00:20:11.680 --> 00:20:16.880 After about a minute and a half which felt like an hour, they un-muted and said hey guys, 00:20:16.880 --> 00:20:22.720 we’re gonna have to get back to you maybe later today or tomorrow, so 00:20:22.720 --> 00:20:28.000 we’ll call you back. Alright, so we finished the call. It’s like, that was abrupt. We didn’t even 00:20:28.000 --> 00:20:36.480 finish our status discussion and suddenly they are gonna call us back? So, they called us back 00:20:36.480 --> 00:20:41.920 maybe three, four hours later and said hey, you know that system that you were on? Yeah. 00:20:41.920 --> 00:20:46.080 Well, turns out that system was used to control a surgical laser. We said well, 00:20:46.080 --> 00:20:52.720 we figured that ‘cause it was – the software was installed on it to do that. 00:20:52.720 --> 00:20:55.680 They said yeah, and we looked it up and it turns out it was actually being used 00:20:55.680 --> 00:21:06.000 in surgery when you guys were on it. [MUSIC] Then we’re like oh, everything turn out okay? 00:21:06.000 --> 00:21:14.000 Yes, everything is fine. No one got hurt. That’s good. But you gotta be super careful on this kinda 00:21:14.000 --> 00:21:17.600 thing. I mean, that system probably should not have been in scope, but it was in scope. 00:21:17.600 --> 00:21:23.040 Right after I finished that call, I called my lawyer, right? My lawyer, he’s pretty interesting 00:21:23.040 --> 00:21:28.960 in this business. His name is Mark Rasch. He was one of the chief prosecutors of Kevin Mitnick 00:21:28.960 --> 00:21:33.760 back in the day from the Department of Justice. Anyway, I’ve known Mark for twenty-some years, 00:21:33.760 --> 00:21:37.760 and I called Mark and I explained the whole thing to him. He’s like, did anybody get hurt? 00:21:37.760 --> 00:21:42.400 No, no one got hurt. Were you operating in your scope? Yes, we were operating in our scope. Was 00:21:42.400 --> 00:21:47.440 your scope written down and defined very clearly? Yes, it was. Was exploitation of these systems 00:21:47.440 --> 00:21:52.240 included in the scope? Yes, it was explicitly said that we can exploit these systems. He’s like okay, 00:21:52.240 --> 00:21:56.560 thank goodness no one got hurt. Oh, and is your insurance up to date? Right, so Mark goes through 00:21:56.560 --> 00:22:02.720 this whole list of – yeah, and we were fine, but I bring this story up because you gotta 00:22:02.720 --> 00:22:09.680 be careful. There are real-world implications to the systems that we’re touching as cyber-security 00:22:09.680 --> 00:22:14.800 professionals. Certainly in pen-testing, but even as defenders or forensics experts, 00:22:14.800 --> 00:22:19.360 be careful, be careful, be careful. Operate within your scope, follow the rules 00:22:19.360 --> 00:22:27.120 of engagement, be careful that you don’t cause really bad things to happen. Surgical lasers 00:22:27.120 --> 00:22:35.360 are used for all kinds of things. Actually, about six months after this event happened, I had to go 00:22:35.360 --> 00:22:41.920 in for surgery on my eye, and I’m sitting in the surgical chair and they got this thing holding my 00:22:41.920 --> 00:22:46.240 eye open. It felt like Clockwork Orange, I’m telling you. So, they’re holding my eye open; 00:22:46.240 --> 00:22:52.800 they put this little laser over my eye, and the laser was controlled by a Windows 00:22:52.800 --> 00:22:58.000 7 machine and it had an Ethernet jack on the back. I’m looking at that thinking – wondering who’s got 00:22:58.000 --> 00:23:01.840 shell on this system? It wasn’t the same kind of thing that we had tested in the hospital earlier; 00:23:01.840 --> 00:23:06.720 it was a different hospital, different system, but it made me – it made it so much more real for me. 00:23:06.720 --> 00:23:12.240 There’s a reality that underlies the systems that we’re interacting with and touching, and we need 00:23:12.240 --> 00:23:19.840 to approach them carefully and with due diligence. It is fun to be a pen tester. It’s fun to hack, 00:23:19.840 --> 00:23:28.560 but we do have to be aware and careful and exercise our due diligence in doing our work 00:23:28.560 --> 00:23:32.560 right and professionally. JACK: It’s amazing to me that companies 00:23:32.560 --> 00:23:36.720 struggle to keep track of what’s in their network. You would think that companies would 00:23:36.720 --> 00:23:42.880 know exactly what systems are there and what they do, but once a company or a network gets so big, 00:23:42.880 --> 00:23:48.400 it becomes a real problem to keep track of all the stuff that’s in it. Systems come and go all the 00:23:48.400 --> 00:23:53.360 time, and documentation doesn’t always reflect what’s out there. Luckily for everyone in this 00:23:53.360 --> 00:23:59.440 scenario, nobody got hurt from this pen test. But it gives you pause to think, doesn’t it? 00:23:59.440 --> 00:24:05.520 Who’s testing these medical devices to make sure they’re hack-proof? A few years ago, I found 00:24:05.520 --> 00:24:11.840 someone who is hacking on medical devices. BEAU: Yeah, my name is Beau Woods. I’m a volunteer 00:24:11.840 --> 00:24:15.840 with a grassroots initiative called I Am The Cavalry, 00:24:15.840 --> 00:24:19.280 and our problem statement is our dependence on connected technology 00:24:19.280 --> 00:24:25.440 is growing faster than our ability to secure it in areas impacting human life and public safety, 00:24:25.440 --> 00:24:29.680 and what that means is that we want to work together in a positive, pro-active manner 00:24:29.680 --> 00:24:35.920 with medical device makers, with the automotive industry, with aviation, and in other places where 00:24:35.920 --> 00:24:40.160 bits and bytes meet flesh and blood. JACK: Defcon is the annual hacker conference 00:24:40.160 --> 00:24:43.040 in Las Vegas. This interview is actually from a few years back. 00:24:43.040 --> 00:24:48.720 What Beau helps organize is the Biohacking Village Device Lab. Now, the Biohacking Village at Defcon 00:24:48.720 --> 00:24:54.000 is a place where you can get a computer chip implanted inside you if you wanted, and do other 00:24:54.000 --> 00:24:59.520 things to augment the human body. But Beau is involved with the Device Lab. This is where Defcon 00:24:59.520 --> 00:25:04.960 attendees can get their hands on medical devices that are used in places like hospitals. 00:25:04.960 --> 00:25:10.080 BEAU: This year at Defcon at the Biohacking Village, we have a Device Lab. 00:25:10.080 --> 00:25:13.920 We have four medical device makers that came to the Device Lab, brought 00:25:13.920 --> 00:25:19.200 devices for researchers to test with. JACK: So they donated to you to test these. 00:25:19.200 --> 00:25:24.160 BEAU: They’re bringing their own devices and asking researchers to engage. So, they see 00:25:24.160 --> 00:25:33.360 it – so, they way we’re – the way we built the Device Lab is we want it to be a safe space, an 00:25:33.360 --> 00:25:39.040 educational forum to build trust, understanding, and empathy with all of the other different 00:25:39.040 --> 00:25:44.640 ecosystem stakeholders. So, we’ve got four medical device makers who are bringing devices formally 00:25:44.640 --> 00:25:50.240 and officially in the room. Their executives know about it, and they’re engaging with the security 00:25:50.240 --> 00:25:55.200 research community to say let’s teach you, let’s learn. Here are some devices; see if you can get 00:25:55.200 --> 00:26:00.080 something that we couldn’t. Let’s help you figure out where to look. Let’s do the right thing so 00:26:00.080 --> 00:26:05.680 that we can learn and you can learn. We’ll learn what you find and you learn how we go about making 00:26:05.680 --> 00:26:11.200 these devices. We’ve also got a Capture the Flag that the Mayo Clinic built, for instance. We’ve 00:26:11.200 --> 00:26:18.160 got – the FDA is participating. Suzanne Schwartz and Seth Carmody from the FDA are in there 00:26:18.160 --> 00:26:24.800 giving their time to go around, to meet people, to do the outreach. We’ve got patients, researchers, 00:26:24.800 --> 00:26:29.440 and really everybody in the ecosystem. JACK: You can guess it wasn’t easy for Beau 00:26:29.440 --> 00:26:34.240 to convince medical companies to bring their equipment to a conference with 25,000 hackers 00:26:34.240 --> 00:26:39.760 in attendance. To start out with, security is hard. Do these companies want to put all the 00:26:39.760 --> 00:26:44.560 measures in place to make sure their device isn’t hackable, or is their priority to make a useful 00:26:44.560 --> 00:26:50.320 tool for doctors that has extreme precision and reliability? [MUSIC] Well, on top of that, 00:26:50.320 --> 00:26:54.400 if you put your device in the hands of hackers, who knows what malicious things they’ll do with 00:26:54.400 --> 00:27:00.960 it? So, I can see why some medical device makers are hesitant. In fact, at first, medical device 00:27:00.960 --> 00:27:06.000 makers were even fighting with hackers, not wanting to work with them at all. For instance, 00:27:06.000 --> 00:27:10.960 some people would give talks at Defcon on how to hack things like insulin pumps and cause a patient 00:27:10.960 --> 00:27:16.320 to overdose. This was actually going to be one of Barnaby Jack’s talks, but medical device makers 00:27:16.320 --> 00:27:22.560 were vocal about how bad of an idea this was to give a talk like this. Medical device makers were 00:27:22.560 --> 00:27:27.840 starting to make enemies with hackers. BEAU: They had had a number of issues; security 00:27:27.840 --> 00:27:32.400 researchers reporting things to medical device makers who really didn’t do much, 00:27:32.400 --> 00:27:37.360 who sent threatening letters and who did other things. The FDA recognized that 00:27:37.360 --> 00:27:43.440 that’s no longer sufficient in our connected healthcare environment to say these things don’t 00:27:43.440 --> 00:27:48.240 matter. So, they stood up and led the charge. I think without the FDA’s leadership in that, 00:27:48.240 --> 00:27:55.520 we wouldn’t be as far as we are. Because we found willing allies and willing teammates in 00:27:55.520 --> 00:28:00.720 the healthcare community really quickly, there was a lot of uptake fast. So we started working 00:28:00.720 --> 00:28:09.040 with people, we got probably half-a-dozen to ten medical device companies that I’m 00:28:09.040 --> 00:28:13.840 on a first-name basis with their product security teams, right? Which is a really cool thing. 00:28:13.840 --> 00:28:19.200 JACK: So, this was a long way to go for Beau and the organization he works with called I Am 00:28:19.200 --> 00:28:25.280 The Cavalry to get device makers and hackers to work together. Clearly, they both have a common 00:28:25.280 --> 00:28:31.120 goal of securing medical devices, and this seems to have resulted in a positive impact. 00:28:31.120 --> 00:28:35.120 Medical device makers have found a real benefit working with hackers. 00:28:35.120 --> 00:28:42.000 BEAU: Yeah, I went up yesterday after day one and asked everybody; day one, I know it’s a scary 00:28:42.000 --> 00:28:52.640 thing to come into 25,000 hackers, right? What did you think? I got a lot of very happy laughs. 00:28:52.640 --> 00:28:58.640 They seem overjoyed with the results, you know? [MUSIC] Being able to get into the room and talk 00:28:58.640 --> 00:29:04.000 to people, understand them, and have other people understand them, right? I think they 00:29:04.000 --> 00:29:12.000 probably changed a lot of perceptions about what medical devices are. The elephant in the room 00:29:12.000 --> 00:29:17.280 in the Device Lab is that medical devices have a bad reputation for security. 00:29:17.280 --> 00:29:22.480 What I think they showed is that actually, you can build a medical device in a way that is safe 00:29:22.480 --> 00:29:29.440 and effective for the patients and also secure. A couple of the choice quotes that I heard yesterday 00:29:29.440 --> 00:29:35.040 from the security researchers was – one was man, I can’t even tell this thing is on the network; 00:29:35.040 --> 00:29:39.360 are you sure it’s plugged in? They had been working on it for two hours trying to find some 00:29:39.360 --> 00:29:45.760 vulnerabilities or some issues or even some way to start attaching to it, and they couldn’t attack it 00:29:45.760 --> 00:29:52.960 and couldn’t hear it talking, even. Another quote was man, if I was a bad guy, I would have given 00:29:52.960 --> 00:29:59.360 up by now. So, I think that’s a testament to the shifting perceptions to hopefully snap more 00:29:59.360 --> 00:30:05.680 into place with reality on both sides. JACK: When a vulnerability is discovered in one of 00:30:05.680 --> 00:30:11.120 these devices, does the IT staff at the hospital patch it or is it sent back to the manufacturer, 00:30:11.120 --> 00:30:16.080 or how – what goes on there? BEAU: Yeah, so there’s a relay race in 00:30:16.080 --> 00:30:21.360 getting vulnerabilities fixed. So, when a vulnerability is discovered, 00:30:21.360 --> 00:30:26.400 the manufacturer often issues a patch, whether it’s for their custom software or some of the 00:30:26.400 --> 00:30:32.320 software components like the operating systems. They issue an update or they 00:30:32.320 --> 00:30:38.320 communicate the need to do an update on those systems. Then it’s sometimes up to 00:30:38.320 --> 00:30:43.920 the hospital, sometimes up to a bio-medical contractor to come and apply the updates 00:30:43.920 --> 00:30:50.320 that exist. But that’s – it’s a lot of hand-offs involved in that, 00:30:50.320 --> 00:30:54.880 and what we find is that in a lot of cases, the medical device makers may have fixed something, 00:30:54.880 --> 00:31:02.880 but the hospitals have not applied the fixes. So, that’s kinda the – one of the reasons why we have 00:31:02.880 --> 00:31:08.960 so many vulnerabilities in our healthcare, [MUSIC] is not that there aren’t more secure versions 00:31:08.960 --> 00:31:12.640 of the operating – of the medical devices available, but that they haven’t been 00:31:12.640 --> 00:31:17.360 taken up by the hospitals themselves. JACK: Huh. Well, this year at Defcon, which 00:31:17.360 --> 00:31:22.400 is in August, the Medical Device Hacking Village will be bigger than ever, with more manufacturers 00:31:22.400 --> 00:31:27.040 bringing devices and talking with hackers on how to improve the security on them. On top of that, 00:31:27.040 --> 00:31:31.600 there will be other manufacturers attending simply to sit down and learn from hackers on how they 00:31:31.600 --> 00:31:36.160 can make their products more secure. To learn more about all this, you can visit the website 00:31:36.160 --> 00:31:43.760 iamthecavalry.org or to learn more about the Device Lab, go to villageb.io. We’re gonna take a 00:31:43.760 --> 00:32:02.000 quick break here, but stay with us because when we get back, we hear another pen test story from Ed. 00:32:02.000 --> 00:32:06.880 Ed Skoudis, SANS instructor and penetration tester, has done a lot of security assessments, 00:32:06.880 --> 00:32:11.760 and there was one where he was hired by a toy company to do a security assessment on a toy. 00:32:11.760 --> 00:32:16.000 This toy company had a new talking doll that had some electronics in it, and they wanted to 00:32:16.000 --> 00:32:20.640 put this toy on the shelves and in the hands of kids, and wanted Ed to test it to make sure there 00:32:20.640 --> 00:32:25.440 was no serious security problems. ED: This specific toy had an interface 00:32:25.440 --> 00:32:30.080 that was Bluetooth Low Energy, so BLE, it had a Wi-Fi interface on the toy, 00:32:30.080 --> 00:32:35.440 it also had an infrared interface on this toy. It’s for children, right? Now of course, 00:32:35.440 --> 00:32:40.000 that’s communicating with some little controller somewhere in the house, so that’s another device 00:32:40.000 --> 00:32:45.600 that you get to test. Of course, the controller itself and maybe even the toy has a mobile 00:32:45.600 --> 00:32:49.520 application that’s on your phone or tablet, so that’s another thing you get to test. So, 00:32:49.520 --> 00:32:55.280 you’ve got the devices, you’ve got the wireless communications protocol, you got the mobile app, 00:32:55.280 --> 00:33:01.120 you’ve got – usually there’s a Cloud-based service on the other side with an API and a web interface. 00:33:01.120 --> 00:33:06.160 Oh my gosh, all these technologies. It’s fantastic. Even on the devices themselves, they’ve 00:33:06.160 --> 00:33:12.320 got chips with firmware that you can analyze. This is a cornucopia of stuff to look at. 00:33:12.320 --> 00:33:17.040 JACK: So, what was your task here? ED: Our task was to hack it all and to see 00:33:17.040 --> 00:33:25.280 if there were significant security risks to privacy, safety, confidentiality, 00:33:25.280 --> 00:33:31.520 and so forth in the whole infrastructure. So, all the way from child’s toy device up 00:33:31.520 --> 00:33:38.240 to Cloud-based service with various APIs. JACK: [MUSIC] So, Ed and his team got an early 00:33:38.240 --> 00:33:42.720 version of this toy in their hands to test it thoroughly, and they just walked through 00:33:42.720 --> 00:33:48.160 it like a normal penetration test, hitting the toy on all its communication ports to see what 00:33:48.160 --> 00:33:52.480 it would respond to. They were gonna watch the traffic coming in and out of the toy to make 00:33:52.480 --> 00:33:57.040 sure it was all encrypted and secure. ED: So, we’re doing this test and it’s fun. 00:33:57.040 --> 00:34:02.720 We’re loving it, we’re – and we found a replay vulnerability. 00:34:02.720 --> 00:34:08.480 So, from a cryptographic perspective, a replay vulnerability is when you have information going 00:34:08.480 --> 00:34:14.160 from one system to another system and you can – so, it’s being sent in a packet that in this case 00:34:14.160 --> 00:34:22.160 was wireless. So, we could sniff that packet and capture it. In a replay attack, you simply replay 00:34:22.160 --> 00:34:26.320 the packet that you capture. JACK: A replay attack is when an attacker 00:34:26.320 --> 00:34:31.680 captures a packet and then is able to send that packet again themselves whenever they wanted. 00:34:31.680 --> 00:34:35.840 I’ve seen this in action when people tried to hack a car remote. You know those little 00:34:35.840 --> 00:34:40.000 devices on the car keys that when you push the button, it locks or unlocks the doors? 00:34:40.000 --> 00:34:46.640 Well, when you push Unlock, that sends a wireless signal to the car which says unlock the doors. 00:34:46.640 --> 00:34:54.080 It’s sometimes possible to use another radio to capture that wireless signal that the remote sent. 00:34:54.080 --> 00:34:59.200 So, you’ve eventually captured the unlock code that’s used to unlock the car. So, 00:34:59.200 --> 00:35:05.040 now that you have that, you can just replay that packet back, sending it to the car and unlock the 00:35:05.040 --> 00:35:11.760 car doors whenever you want. That’s how a replay attack works, and Ed found this toy was vulnerable 00:35:11.760 --> 00:35:17.040 to something like that. In this case, there was a way to get the doll to talk remotely through the 00:35:17.040 --> 00:35:21.680 phone app or something. He captured the packet using his computer and he could just replay it 00:35:21.680 --> 00:35:26.800 whenever he wanted to make the doll talk. Kind of cool. Ed writes this finding up in a report and 00:35:26.800 --> 00:35:32.320 tells the toy company. The report read… ED: Finding; high-risk vulnerability. 00:35:32.320 --> 00:35:39.120 No replay prevention on this type of message sent across this protocol to the toy. 00:35:39.120 --> 00:35:44.080 The customer came back to us and said we don’t care; we’re gonna ship. Look, 00:35:44.080 --> 00:35:49.920 Santa Claus is coming to town. We gotta hit this deadline for production or else we’re 00:35:49.920 --> 00:35:54.960 not gonna have enough toys on the shelves for Christmastime, so we’re gonna ship with it. So, 00:35:54.960 --> 00:35:58.000 our team was pretty concerned about that ‘cause this is a pretty significant vulnerability. 00:35:58.000 --> 00:36:02.000 You could replay this message. We got on a phone call with the customer and said 00:36:02.000 --> 00:36:07.440 look, somebody could replay this. The customer said to us – ‘cause this was a doll, okay? The 00:36:07.440 --> 00:36:16.400 doll could say things and do things and interact with the child. We said somebody could capture a 00:36:16.400 --> 00:36:21.920 message going from the controller to the doll and then replay it. The customer said so, look, the 00:36:21.920 --> 00:36:27.680 doll can say goo-goo-ga-ga. So, somebody captures that and replays it and it says goo-goo-ga-ga 00:36:27.680 --> 00:36:34.080 again. We don’t care, honestly. We’re gonna ship with that. So, a little bit dejected, 00:36:34.080 --> 00:36:38.560 we got together, me and the folks on my team, and said you know, we gotta show that this thing 00:36:38.560 --> 00:36:42.400 could cause a bigger issue. [MUSIC] So, we said okay, let’s think about 00:36:42.400 --> 00:36:48.480 messages that you could replay again and again that might be more interesting than goo-goo-ga-ga. 00:36:48.480 --> 00:36:52.640 So, now, the messages are all encrypted, so you can’t really see what’s in the message. 00:36:52.640 --> 00:36:58.320 But based on message length and also when it’s sent in the protocol, 00:36:58.320 --> 00:37:02.000 we could get a sense of what each message was doing. In other words, goo-goo-ga-ga is usually 00:37:02.000 --> 00:37:08.080 gonna be about 400 bytes long and it’s usually sent in this context, so we can’t look inside 00:37:08.080 --> 00:37:12.400 the message; it’s encrypted, so we can’t see that it says goo-goo-ga-ga, but we can infer 00:37:12.400 --> 00:37:19.600 that. So we looked at it some more and said okay, let’s think about messages that cause 00:37:19.600 --> 00:37:25.600 the toy to burn a lot of CPU. So, we’re just playing messages again and again and again, 00:37:25.600 --> 00:37:30.960 and we found this one particular message set that would make it use a lot of CPU on the doll. 00:37:30.960 --> 00:37:35.440 Now, what happens if you use a lot of CPU on the doll? Well, first off, I guess the battery will 00:37:35.440 --> 00:37:39.520 die faster, but who cares about that? Again, the customer would say I don’t care, right? 00:37:39.520 --> 00:37:45.840 But if you play enough of these messages quickly enough, the doll starts to heat up. 00:37:45.840 --> 00:37:50.240 So now, I wish I could tell you we had the doll catch on fire, but that was not the case. The 00:37:50.240 --> 00:37:56.240 doll did not catch on fire. But our initial report said there is a significant chance that someone 00:37:56.240 --> 00:38:02.400 could scald a child. Now remember, the customer said goo-goo-ga-ga; I don’t care. When they saw 00:38:02.400 --> 00:38:09.600 ‘scald a child’ in the report, their lawyers said thank you for finding this significant 00:38:09.600 --> 00:38:17.120 issue which we will absolutely resolve. Please remove the phrase scald a child from the report. 00:38:17.120 --> 00:38:23.200 So we did, and they did fix it before they shipped it, but the point there is you need 00:38:23.200 --> 00:38:30.880 to communicate as a security professional risks in terms that a customer understands and it maps 00:38:30.880 --> 00:38:36.160 to their business model. ‘Cause if you’re not, if you say replay attack, they’re like well, 00:38:36.160 --> 00:38:39.920 I don’t think I’m getting evaluated on whether I have a replay attack or not. 00:38:39.920 --> 00:38:44.320 But you are getting evaluated as to whether your toy’s any safe in the hands of a child. 00:38:44.320 --> 00:38:48.320 So, I’m not saying you want to spread fear, uncertainty, and doubt or anything like that, 00:38:48.320 --> 00:38:55.760 but be careful to not focus on just the technical aspect of a finding in a pen test, 00:38:55.760 --> 00:39:04.160 but think of the implications to the business, to safety, to the reality of people, 00:39:04.160 --> 00:39:07.840 you know? That’s what’s important. JACK: It’s always interesting how far you 00:39:07.840 --> 00:39:13.360 need to go as a penetration tester to prove your point. Sometimes just finding a vulnerability and 00:39:13.360 --> 00:39:18.400 reporting it is not enough. Sometimes you need to demonstrate how the vulnerability can cause the 00:39:18.400 --> 00:39:25.200 company serious pain, and I never know where that line is. Sometimes I’ve seen bug bounty 00:39:25.200 --> 00:39:30.000 hunters report a vulnerability to a company and they say oh, well, that’s a non-issue for us. 00:39:30.000 --> 00:39:34.560 Then the bug hunter says okay, if it’s a non-issue, then I’m gonna publish this publicly. 00:39:34.560 --> 00:39:38.480 Now suddenly the company does care about it, or maybe they still don’t care and the bug 00:39:38.480 --> 00:39:43.440 gets published publicly, and then people start exploiting it and it becomes a big problem. 00:39:43.440 --> 00:39:48.960 It sometimes takes that sort of public pressure to get a company to move and fix the problems. 00:39:48.960 --> 00:39:53.840 The visionary companies are the ones that recognize the significance of a security problem 00:39:53.840 --> 00:39:57.200 with the first report and resolves it right away. 00:39:57.200 --> 00:40:02.480 ED: You don’t want to be too hyperbolic in your reports, but you want to explain the risk 00:40:02.480 --> 00:40:08.960 in an appropriate way. So, it’s exciting. It’s fun to do what we do. It really is cool. 00:40:08.960 --> 00:40:14.800 If we go back to that story I told you when I was a little kid, I never imagined that hacking 00:40:14.800 --> 00:40:19.840 and penetration testing was a job. Sometimes I think back and I almost want to pinch myself and 00:40:19.840 --> 00:40:25.360 say this is what I get to do for a living. That’s amazing. If you were to tell ten-year-old Eddie 00:40:25.360 --> 00:40:30.160 Skoudis – ‘cause I went by Eddie back then when I was ten – that someday you would do this for a 00:40:30.160 --> 00:40:36.240 living, it would have blown my ten-year-old mind. That’s a thing? That’s what you do in the future? 00:40:36.240 --> 00:40:42.080 How cool is that? (OUTRO): [OUTRO MUSIC] 00:40:42.080 --> 00:40:46.000 A big thank-you to Ed Skoudis for coming on the show and sharing these stories with us. 00:40:46.000 --> 00:40:50.160 Ed is still working with SANS, bringing up the next generation of instructors there and also 00:40:50.160 --> 00:40:54.720 focusing on his own company called Counter Hack. Also thanks to Beau Woods for telling us about 00:40:54.720 --> 00:41:00.720 medical device hacking. You can learn more about what he’s working on by going to iamthecavalry.org 00:41:00.720 --> 00:41:06.320 or visiting villageb.io. Hey, if you didn’t know, I’ve been publishing episodes of this 00:41:06.320 --> 00:41:10.800 show to YouTube and I’ve added some animations to each episode, and it’s kinda cool to check out. 00:41:10.800 --> 00:41:15.200 Just search for Darknet Diaries or Jack Rhysider on YouTube and you’ll find it. Check out what 00:41:15.200 --> 00:41:18.800 I’ve been posting there and tell me what you think. I always love hearing from listeners. 00:41:18.800 --> 00:41:24.160 This show is made by me, the ear-piercing Jack Rhysider. Sound design by the downbeat Andrew 00:41:24.160 --> 00:41:29.120 Meriwether, editing help this episode by the snipper, Damienne, and our theme music is by 00:41:29.120 --> 00:41:34.320 the paper tiger, Breakmaster Cylinder. One time I got hired to work somewhere and they told me 00:41:34.320 --> 00:41:39.840 what the starting pay was, but then they said in ninety days, the pay gets increased by 20%. 00:41:39.840 --> 00:41:47.840 So I said okay, great; then I’d like to start in ninety days. This is Darknet Diaries.