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.