Hacking pacemakers? Spying on Tesla? Let's talk IoT again.
Site: https://whattheshellpod.com
Discord: https://discord.gg/mBPbWcVRYR
Happy New Year everybody. I hope you're all enjoying the holidays and settling in after what I'm sure was a very busy time in your life. Maybe you're finally getting around to unpacking those holiday gifts, setting up that new Alexa or Google home device. Maybe you finally got that pet camera so you can go away without having to worry about. Or, hell, maybe you went all out and got that new smart fridge you've seen so many commercials for on TV. Well, what if I told you that these little treats come with a price? What if I told you that some of your things, might not be as safe as you'd expected?
My name is John Kordis, and this week we're going back to a familiar topic that we've covered in the past. We'll switch it up just a little bit and Instead of telling just one story, I'm going to tell you a story of many things. More specifically we're going to talk about that Internet of things and What the Shell else we might not have covered on the last episode.
So join me this week so I can talk to you a bit about some major breaches in privacy, some interesting stories, and how your fridge might be moonlighting as a hacker without your knowledge.
Now, before we get into the hacks and craziness, I feel like I should do a bit of a refresher for anyone that might not be super familiar with IoT devices. And when I say IoT I mean the "Internet of Things". Broadly speaking, the internet of things is any kind of piece of technology that has to communicate across the internet in order to function. In the past few years that term has largely become associated with things like home security systems, personal assistants, and a myriad of other app controlled life assistance bots. But really, it goes beyond that. I said it in the intro, maybe it's a fridge that lets you peak in it remotely or has a built in android tablet that lets you order food. It could be your smart lights or your home router. Or more seriously, it could be you medical alert system, your car, or your home heating control…
All of these things that reach out to the internet for operation and control make up the Internet of Things. If you've ever had to sync it to your home wifi, it's probably part of it. For any of my newer listeners, this isn't the first time we've had this discussion. If you want, you can go back and check out episode 12 for stories about how even things like sex toys can get hacked.
So let's start with this concept and go to something that I think it's possible a lot of people that listen might have or that I think a lot of people that listen to the show might, a digital assistant. Specifically in this case I'm talking about the google home device, you know google's answer to siri and alexa.
This hack comes pretty hot off the press from the last days of 2022. On December 29th it was reported that a security researcher named Matt Kunze had found a way to effectively make a google home device near him into his own personal wire tap. Moreover, it turned out the process was relatively easy to do. Let's cover how it works so you get the picture. We'll take this step by step and I'll explain what's happening, then we'll circle back at the end.
First, the attacker just needs to be close enough to your google home that it can pick up with signals it sends over Wifi. I want to really stress this, there's no missing step. If I'm the attacker here I don't need your email. I don't need to know your wifi network password. I don't need to know anything other than the fact that there's a google home nearby. You might be sitting in the car or at the gym thinking to yourself "But John, how do they even know that?". Well, the answer is pretty straight forward. Everything that communicates over wifi produces a signal right? Your router just receives that and gives you the functionality to get to the internet safely. But, there's no magic wrapper around that signal hiding it. If I'm close enough I can use a wireless adapter capable of monitoring for those signals to start searching for all the devices connecting via wifi.
The next thing to do would be narrow that list down. Well, part of what is transmitted here is the MAC address of the device that's connecting and the thing about MAC addresses is that the starting few characters all identify the manufacturer. I could see stuff from Apple, Nest, Google, HP, and any other company you can think of. So what do I do? I look specifically for googles prefix and then make a note of it.
The next part is pretty neat, and something that I've done personally in my own test environment before. Using these monitor devices you can also send packets and force a device to de-authenticate from it's wireless network. If this happened to your laptop it would look like you just dropped off the wifi but for many personal assistance this triggers it to enter setup mode to reconnect.
Now, I'm the attacker and I'm going to connect to the google home setup network. The set up network is that initial wifi you've got to connect to so that you don't need to connect a cable in to get your assistant up and running. You'll recall there's no real security here. So the attacker logs in to that piece of the google home and now I can get the three bits of info I need. In this case it's the name of the device, it's certificate, and the cloud ID.
What I can do with this is actually go back out and actually link my own account to that device as well as the users using the google homes built in API to send a request out to the google server. Once it comes back, I'm also technically an owner of the device and I can operate it remotely once it reconnects to the home network.
That includes doing everything that it can do, all relying on what's configured in the house. I can see the history of commands run, drop in on the audio, blast my own music of message, maybe even try to order stuff. After all, it's my device now too.
It should be noted that many google homes are set to update automatically so this has already been patched, but this is a great example of how much we allow these devices to control in our lives and what the compromising of one of them could actually do. Thankfully this was a security researcher that found out about it and reported it but it's also entirely possible that this has been known about before and already used maliciously.
The next hack I want to talk about is a bit out of date but a good exercise in talking about unnecessary features. We're going to talk about Webcams. Specifically, we're going to talk about Trendnet webcams.
Back in the early 2010s, trendNet webcams were pretty popular, especially for security cameras. They're still around today and you can go buy one if you'd like. The specific camera we're talking about was the model IP110.
In January of 2012, a research blog called console cowboys published an article Titled "Trendnet cameras, I always feel like somebody is watching me." The goal was to find anything interesting about the cameras. The site downloaded the latest firmware and applied it to the camera, then spent a bit of time breaking down the firmware file itself to see what they might be able to find. Using a bug that let him make a copy of part of the firmware and decompress it, the researchers found that there this was a compressed file system. So, similar to how you have all your directories in Apple, Linux, and Windows they were able to look around and see what the system that operated these cameras looked like.
After spending some time navigating around there was one directory that they really honed in on. This was titled /server/cig-bin/anony/. In that directory was something called mjpg.cgi. Hmm, mjpg….maybe it was something to do with image output? Well, they decided to go to their camera and try connecting to it via the web interface, but appending the link so that it looked like the ip address of their camera /anony/mjpg.cgi.
What they found floored them. It was a straight live stream from the camera.
Ok, so with access to the camera they were able to get a live stream now. But the researchers gave Trendnet the benefit of the doubt. According to the blog post they figured well Anony must mean anonymous and that must mean that it's an anonymous user setting that can be disabled. Well guess what. Even after setting up users the method worked and there didn't appear to be any way to disable that kind of access. And now some of you might have been thinking about the question "Well if it's the private network then what is there to worry about?" and to that I would refer you to a site we've talked about several times in the past, shodan.
Shodan.io is a site that essentially operates as a search engine for any device connected to the internet. Right now, if I go in there I can see around 8,000 trendnet devices publically accessible to the internet. How many were there accessible on shodan in 2012? 9,500. Now keep in mind this is a vulnerability found specific to this version of firmware so that doesn't mean that there are 9500 exposed devices. Just a potential pool of that much. To really figure it out, console cowboys made a tool to automate looking vulnerable cameras and came back with about 350 devices they can and did snoop in on. Some were businesses, some were homes. All were insecure.
I've got a screenshot of two of the camera outputs from the initial breach in the episode transcript on whattheshellpod.com.
It got worse too, some of the vulnerable devices were being used as baby monitors, or as patient cameras in hospital.
Later in the year, due to this breach the FTC to action against Trendnet. According to CNET "Under the terms of the settlement, TrendNet cannot misrepresent its software as "secure" and must get an independent assessment of its security programs once a year for 20 years, according to Reuters".
These days an annual independent security assessment is pretty commonplace but this was a big blow to it at the time.
For their part TrendNet did take action once this was made public. In a statement they made in September of 2013 they detailed their response.
Part of that statement read quote
Upon awareness of a TRENDnet IP camera hack in 2012, TRENDnet immediately initiated every effort to respond to and resolve the hack. TRENDnet immediately released updated firmware which eliminated the published hack for related product models. Product shipments were stopped and corrective firmware updates were performed for all affected models. Substantive resources were dedicated towards the goal of bringing awareness of this hack to consumers.
You might think that great, they've got their stuff together. Let's move on and move out. But instead of going to the next subject I'm just going to fast forward a few years to 2017 when, you guessed it, it happened again.
It was at this time that Refirm labs, a startup based around ex-NSA workers found that there were still vulnerabilities that allowed snooping of surveillance cameras by even rookie hackers.
Stop me if you've heard this one before but this is was Terry Dunlap said in an interview with Fortune.
“I wouldn’t even call this a hack because it doesn’t take any sophistication,” the vulnerability, which affects TRENDnet’s TV-IP344PI camera model. Tuning into these cameras’ video feeds requires neither authorization nor authentication, but merely the knowledge of a device’s IP address, an easily obtained bit of identifying information. "
You know, that identifying information we just said was found on basically hacker google. This called into question two major factors.
First. Did TrendNet actually care? Second, what happened to that security audit? Shouldn't it have caught this?
For those, I'm going to put my cyber nihilism hat on and give my honest take on it. To answer question number one, no they probably did not care. It's more likely that they patched the hole, did the required amount to move on, and kept producing cameras. Putting a higher amount of effort in to try and find similar security issues would require time and money, perhaps more time and money than another slap on the wrist. It's a balancing game where if the cost of penalty is less than the cost to fix it, why would they bother?
The second part? Well I don't know the exact details on the independent security review, but what I do know is the field for that is huge. There are cheap ones, there are expensive audits. There are audits that do the bare minimum and there are audits that find the smallest nooks and crannies. That's all to say that they could have fished for the lowest cost that technically satisfied their needs and called it at that.
I don't know if that's what happened, but it's happened at other companies and will continue to happen as a way to get around restrictions. The last piece I'll offer is that at the very least it took a team of ex-NSA researchers to find the vulnerability. So while it might have been easy to exploit, the discovery could have taken some time.
The Verkada hack
We're going to stay on webcams again for this next one, but instead of vulnerable firmware we're going to talk a little bit about how poor security controls lead to hackers being able to spy on an insane amount of high profile targets.
Let's talk about the attacker first. In this case, the hacker named in Tillie Kottmann. Kottman is a swiss hacker that, according to threat intelligence deals less in disruption and more around exploratory efforts. Long and short of it is that Kottman pokes and prods at stuff not to sell it or stay on the network but more because she could. Kottman, who is a swiss native born in 1999, had a habit of doing this and even before the breach that we're about to talk about had a history. On March 18, 2021, the U.S. Department of Justice announced that a federal grand jury had indicted Kottmann for conspiracy to commit computer fraud and abuse, conspiracy to commit wire fraud, and aggravated identity theft.
So at, what 22 years old at this point? She had a cyber rap sheet that was already pretty long. Honestly, depending on how much I can find about her story I might even try to do an episode about her major efforts. Anyways back to March of 2021 because that's when Kottmann set her sights on a security company called Verkada. Verkada, much like Trendnet, supplied security cameras and webcams that were attached to internet and so this made it a bit of a juicy target.
What Kottman did was what I think many hackers and nation states would have done, she searched for and in this case found user credentials from a breach impacting a verkada account. According to Tillie it was found publically and didn't need to be purchased or bartered for, it was already well available to anyone looking. Using that account the hackers involved were able to gain access to the verkada network, which as a result it turned out meant that they had admin access to all Verkada cameras.
But how does one account lead to all that? Let's look at Incident report that verkada put out. I'll start by giving you the juicy details from their summary. They said quote:
From March 8-9, 2021, attackers compromised Verkada’s platform and accessed customer data,
including video, for a subset of Verkada customers. In all, 97 customers had their cameras accessed
and video or image data viewed. Eight of those customers had Access Control product data
accessed, including badge credentials. Separately, eight customers had their wifi credentials
accessed. In total, this represents less than two percent of Verkada’s approximately 6,000 customer
population. Finally, the attackers downloaded a list of Command users (including names and email
addresses but no passwords) and a list of Verkada sales orders.
The way it turned out that the attackers got in was because a misconfigured customer support server was exposed directly to the internet. It turned out the account they had credentials for was a support administrator which meant they were able to log into the customer support server and then use that admin account to create valid support sessions and begin looking at customer data and cameras.
But who were the customers? Well let's look at the verkada website and see who they're touting as big customers. I'm just going to read them off as I see them.
We've got the city of Las Vegas. Tesla factories. Prism Healthcare. Petroc College, The Chartwell School, Liverpool heart and chest hospital, the Oakland Chinatown chamber of commerce, Virgin hyperloop, the dairy farmers of America, CITRIX, I could go on and on. The list is massive and naturally they chose just the juicy ones to look at and all in all were able to access over 150,000 of the cameras across these customers. A MASSIVE breach.
Kottmann and crew did end up taking some data too, according to the network logs they managed to exfiltrate about 4 gigs of data ranging from "a list of client account users, including names and email addresses" to "A list of Verkada sales orders."
They do know that no camera was viewed for more than ninety minutes and estimated an average 11 minutes of view time each time one was hijacked. To add on to the fact that Kottmann and crew aren't a disruption based group they did affirm that there was no evidence of tampering or video deletion either.
At the end of this all we're left with a twofold problem, the IoT devices having so much easy access by the customer server and a lax security practice that doesn't monitor for data breaches of internal accounts. If this account was as easily found as they made it out to be, there are many tools in the industry that could have alerted Verkada and triggered an immediate password change so that this very problem never would have occurred.
It was a perfect storm of problems that resulted in an insane view into many different companies. Verkada would go on to disable accounts while they fixed it and communicate to the companies what cameras were accessed but by then the damage had been done.
The next one we're going to had no real world damage done to it but was insanely scary to think about. I'm going to move us to August 29th 2017 because on that day the Food and Drug Administration issued a recall. But this recall wasn't just for a pill or some food, it was for St Jude Medical implantable cardiac pacemakers. These devices are implanted under the skin and have lead wires that travel to the heart. They can be used to help correct irregular heart rhytms or give pacing to weak hearts that need it.
That's to say that for many people, discomfort is on the bottom order of consequences here with the top being potentially fatal.
According to the FDA, they had received information about potential vulnerabilities that impacted the pacemakers and described what could occur in the release they put out. They said if an exploit occurred it could quote "could allow an unauthorized user" in this case a non-doctor, "to access a patient's device using commercially available equipment. This access could be used to modify programming commands to the implanted pacemaker, which could result in patient harm from rapid battery depletion or administration of inappropriate pacing."
So they're saying that someone in signal range could modify the settings of a pacemaker. The recall in this case wasn't a recall as you'd think. They didn't need to yank 465,000 devices out and replace them, they simply needed a firmware update that would make it so authentication and authorization had to occur before changes were made from then on out. There wasn't any known instance of an actual attack occurring here but it's something I wanted to make you aware of and that's the fact that IoT devices are not always just home life equipment. There is an entire field dedicated to the security of healthcare devices like these pacemakers because that's just the tip of the iceberg. Some people need to temporarily wear internet connected monitors in order for doctors to get data that will result in prescriptions and medical advice. What if some of this data was falsified? Could it be possible to give someone medication based around a lie? What about internet connected insulin pumps? A very real danger to many people who are diabetic where someone else might be able to control how much insulin they get without their knowledge.
The point I'm trying to make here, is that if you look. Really look closely. The amount of things we connect to the internet and the damage that can be caused through them is like a fractal shape. You can keep going deeper and unlocking new smaller branches, but it never seems to really stop.
Alright I've got one last one for you. This time we're going to talk about something I think tends to get forgotten about as a part of the internet of things. Your router. It's at the edge of the internet and your home, and it's technically accessible from outside the internet.
I'm going to take you back to 2016 when a bit of a culmination of everything we've talked about happened. We talked about how internet devices are constantly being scanned and about how bad account and password management was a constant problem as hackers had an easy in. Well, mid 2016 a college student named Paras Jha and his colleague Josiah White wrote the source code for something called the Mirai botnet. You might have heard the term botnet before but if you haven't you can think of it kind of like a hive mind. That is to say, many many difference bodies all acting under one central brain or from one command system.
But what does that have to do with your routers? Well, the way the botnet worked was that it scanned internet connected devices looking for a Linux operating system known as ARC. Once one was found, a combination of a security vulnerability and default credentials being used meant that mirai was able to log in and zombify the router, adding it to the hive mind. From there, that router or device could also perform scanning and attacking functions. Once a certain number of devices were infected they could be used in what was called a distributed denial of service attack. I'm going to take a step back so I can explain this concept to anyone that doesn't know what that is.
Let's start by placing you in a room with say 100 people and you're trying to give a speech. A regular denial of service attack would be one guy standing up and shouting "HEY. HEY. HEY. HEY. STOP TALKING. STOP TALKING.". He's effectively ruining your speech because of how he's nonstop shouting. But that can be rectified pretty easily by having security escort him from the premises. That would be a regular denial of service attack.
Now imagine the same scenario, except every time the person shouting might switch. Or multiple people might be shouting at the same time. The security guard might be able to help but he couldn't get everyone because they're spread out and coming from different places. That's a distributed denial of service attack, and that's what the Mirai botnet was created to do.
Now, allegedly it started as just a way to grief individually hosted minecraft servers and the companies that protected those servers, but things snowballed real quick. In an effort hide their own activity as a part of this they leaked their own code online. If it was out in the wild and people used it, then they might have just gotten it from somewhere online right? Not been designated the creators. But once it hit the wild people started to see what it could really do. In fact, in October of 2016 Mirai was used to take down some of the biggest internet platforms there are. That included Netflix, Twitter, Spotify, Reddit, and many news outlets. The attack, which targeted the service that runs the domain name resolution for many of these platforms, even took down much Amazon's AWS environment.
Many people would try to get online that day to go about their normal browsing habits, only to find nothing was loading. What some of them didn't know was that it was their own router participating in the attack that brought down their favorite sites.
This attack was one of the largest DDOS attacks in recorded internet history. The creators were eventually rounded up by the FBI but that didn't mean the malware was gone. There are variants out there still searching for devices with default credentials that can be added to the hive mind, and while there are better pieces in play for detection and protection, ultimately it can still be a major concern if put to the right use. So, I have to ask, did you change your routers default password? I'm just kidding. Most routers these days are starting to veer away from one standard username and password, but that doesn't mean all of them.
I'm gonna close with the same ending I had last time. Because some of you might be asking yourself "So what do you do to help kind of mitigate this risk?" Well it's nothing you probably haven't heard from me and whatever other podcasts you listen to on the topic.
To start, you use a bit more of a complex password. And I know there are gonna be some of you out there rolling your eyes at this, but just get a password manager. They'll take care of the complexity for you and as long as you remember that single password to get in, the rest is on them. That's how many of these kinds of hacks work. You might also want to go a step beyond that and figure out a rotation on when you should be changing your password. There's a reason your company makes you do it every once in a while, and it's not to mess with your routine. It's to avoid a Verkada incident and accidentally leave you password laying around where someone can find it and use it on your stuff.
The other thing you can do is enable that two factor authentication. That's the tool that either texts you, emails you, or relies on a pre-generated code from a separate application to get you in in addition to your password. It's that concept of something you have, the code, and something you know, the password, working together to make it a bit harder for someone to take control of your account without you knowing.
If you want to go a bit more nuclear with it you can always run everything yourself. There are security systems that operate on a bit more of a closed loop network, out of your own home, that you can use for example. In that case you can have a system that you control and doesn't ever need to touch the internet. That's not super cost or time effective and comes with the responsibilities of maintaining your own uptime and equipment though. Like I said, it's about the price of convenience vs privacy when you do stuff like this, so you've got to consider that too.
The last option really? Just don't do it. At the end of the day these aren't really neccessities are they? You don't need an alexa or google home. You don't necessarily need the smart tv or appliance. They just make things easier. And if you want them, who am I to knock you for it? After all, I've accepted some of this risk into my own life, but I've taken the precautions where I could to make sure it doesn't come back and bite me. As can you. At the end of the day, we have the responsibility to secure ourselves just as much as the manufacturer in some cases. So where do you draw the line?
That's this weeks episode, thanks for listening to me explain What the Shell is going on with IoT and letting me talk through some of the crazy breaches around it.
Before you go, I have some stuff you might be interested in. First, for anyone that's new to the show or might now know about this, you can join us in the discord to talk about the show and hang out! Now that we've started back up I'm going to try and be a bit more active there so you can reach out, talk to me or anyone else online and offer up any suggestions you might have for the show because I'd love to hear them. You can find the link to join on my website whattheshellpod.com or in the description below. On that site you'll also find the transcript of the episode and should you be interested my other socials like instagram and twitter both of which are @shell_pod.
And then I do want to ask that if you liked this episode maybe leave a review or rating on your platform of choice. It goes a little bit of a ways in terms of getting me up there in the charts so other people can find the show. If that's not your thing maybe just recommend your favorite episode to someone you think might like it, word of mouth is honestly my favorite way the show has spread. Alright, I think I'm good for now, so I'll see you all in two weeks for the next episode.