Jumping the Goldfish: IoT insecurity Eight Years Later.

The fish will die

Picture the meeting where somebody designs an internet-connected thermometer for a fish tank. Someone asks what the risk is, and the answer is pretty simple: if this thing fails, the fish die. So you put a warning on the box (we’re in California, so there’s going to be a warning on the box anyway), you change “may die” to “will die” so legal is happy, and you’re done. Attack surface considered, liability covered, ship it.

And honestly, if you’d walked up to your IT team and said “I want to put a thermometer on the network so I can make sure the fish don’t die,” a lot of them would have said yes. You won’t admit it now, but you might have.

In 2017 the security firm Darktrace described an incident at a North American casino where attackers got in through exactly that kind of fish tank. The tank had sensors connected to a PC that handled temperature, feeding and cleaning, and according to Darktrace, somebody got into the fish tank, used it to move around into other parts of the network, and sent data out. The next year Darktrace’s CEO told the story at a Wall Street Journal conference in London with the detail that makes it hurt: what went out through the thermometer was the casino’s high-roller database. (The casino has never been named, and everything we know comes from Darktrace, which sells the kind of monitoring that caught it, so take the details with the appropriate grain of salt.)

So if you’re a high roller, think about the fact that the casino has your data and not just your money, and the data may be worth more than whatever you left on the table. The part that still gets me is that the data went out through the thermometer. A thermometer should send a tiny bit of data, on a schedule, to one place. According to Darktrace’s 2017 threat report, this one sent about 10GB to a device in Finland, over a protocol normally used for audio and video, and that’s exactly what gave it away. Their monitoring flagged the fish tank because it was suddenly moving unusual amounts of data to a destination it had never talked to before. Nobody had thought of the thermometer as a security problem, but its traffic made the problem obvious to anyone who was watching.

Jumping the goldfish

I told a version of that story in 2018 at Cybersecure LA, a conference where local business leaders work with Pepperdine and government security people. I called the talk “jumping the goldfish,” and I opened by putting a slide full of devices up and asking which of them had been hacked. The answer was all of the above. At the time I kept a running list called the IoT Hall of Shame, and I couldn’t keep up with it, because it was a daily thing. (It’s not current anymore. Keeping up turned out to be a full-time job, and I already have one.)

The question I heard over and over back then was “why does it matter? It’s just a stupid little light bulb.” And that’s the problem, because the risk analysis for these things almost always asks what the device can do. A light bulb can turn a light off. A thermometer can report the wrong temperature. Who cares? The better question is what the device can reach, and a thermometer on the casino network can reach the casino network.

Eight years on, some of those stories have aged, some of my predictions came true, and a few details needed fixing, which is what happens when you fact-check something you said live with a microphone in your hand. So here are a few of the stories across different markets, the tactics they have in common, and what to do about it, both if you build these things and if you buy them.

Who cares about my X-ray?

A family member used to work for a company that did red team work (they attacked people for money, and for a while it ran in the family). We got talking about hospitals once, and the way it was described to me, hospitals think about security like a castle. The bad guys are outside the walls trying to figure out how to get in.

Around the same time my dad had a heart attack, and I walked into his room and counted four devices with USB ports on them. How often is a nurse in that room? Could somebody get a few minutes alone with one of those devices? Absolutely. I work with the safety-critical software industry, which includes medical device makers, so I knew enough about the infusion pump brands to have an opinion. When the nurse asked what I was doing poking at the pump, I told her that if it had been a particular other brand I’d have asked her to take it out of the room. (I’m not going to tell you which one.)

The pumps were what I worried about, because they’re right there with the patient and a bad dose is obviously a safety problem. But the data from the time said I was worrying about the wrong box. A 2018 report from ZingBox, a security vendor focused on connected devices, looked at tens of thousands of devices across more than 50 hospitals and found that imaging systems made up 19 percent of the connected medical devices but accounted for 51 percent of the security issues, while infusion pumps accounted for about 2 percent. Imaging machines run lots of network applications, they’re often built on commercial operating systems, and they tend to outlive their support agreements. Nobody thinks of the X-ray machine as the dangerous one. Someone gets a copy of my X-ray, who cares?

Here’s why you should care anyway, and it has nothing to do with somebody seeing your X-ray. Put a commercial operating system together with a support agreement that ran out years ago, and a lot of those imaging machines are really just old, unpatched Windows PCs with a very expensive peripheral attached. Nobody has to target them. When WannaCry hit in May 2017, it was a worm looking for unpatched Windows anywhere it could find it, and inside hospitals it found plenty, including the imaging gear. The UK’s National Audit Office found that at least 81 of the 236 hospital trusts in England’s National Health Service were affected and an estimated 19,000 appointments were cancelled, and besides the office computers it locked up equipment like MRI scanners and machines for testing blood and tissue samples. The scanners weren’t the target, they were collateral damage, and that’s worse, because it means a device can take a hospital down without anyone ever thinking about it at all. Castle walls are great at keeping out the big things, like armies and wolves and the neighbor’s dog. They don’t do a thing about cockroaches. Cockroaches are small and nasty, they get in through cracks nobody is watching, and once they’re in, they’re everywhere. WannaCry was a cockroach infestation, and those old imaging machines were the cracks. (The Audit Office also noted that the device vendors often weren’t much help with the extermination.) They also got lucky, because a researcher found a kill switch that stopped it from spreading further.

And my worry about the pumps? It didn’t go away, it just took a while. In 2022, researchers at Palo Alto Networks (who, as it happens, bought ZingBox) looked at 200,000 network-connected infusion pumps and found that 75 percent of them had known security issues. More than half of them were exposed to the same pair of 2019 flaws in VxWorks, an operating system used in a huge number of embedded devices, and one of the two was a buffer overflow. Remember that when we get to the part about how we build software.

The tricks are older than the devices

The devices change every year, but the ways in keep repeating. Here are the ones that show up over and over in these stories.

Chatty devices that trust everybody

When I gave the talk I asked how many people in the room had Philips Hue bulbs, and a good quarter of them did. Fewer had ever updated the software inside them. Smart bulbs talk to each other, and in 2017 a group of researchers showed they could put malicious software on a Hue bulb and have it spread to neighboring bulbs, and not just the ones in your house but the ones in your neighbor’s house too, because the bulbs didn’t do much to check who they were talking to. I could pretend to be a bulb and the others would listen to me. Philips fixed the spreading problem, but you could still take over an individual bulb.

Then in 2020 Check Point took the next step and went after the Hue bridge. That’s the little hub plugged into your router that the bulbs in your house talk to (or at least are supposed to talk to, instead of chatting over the fence with the neighbor’s bulbs). They took over a bulb, made it act glitchy so the owner would remove it from the app and then pair it all over again, and when the bridge found it again the bulb hit the bridge with one of the oldest tricks in the book, a heap-based buffer overflow (publicly catalogued as CVE-2020-6007, the ID number known vulnerabilities get), and used it to install malware on the bridge.

If nobody’s ever explained a buffer overflow to you, think of pouring a 16-ounce drink into a 12-ounce cup. The program set aside room for a certain amount of data, the bulb sent more than that, and nothing checked. With a real cup, the extra just makes a mess on the table. In a computer, the extra spills into the memory next door, and if the attacker gets to choose what spills over, they can get the program to run their instructions instead of its own. (The “heap” part just tells you which area of memory the cup was sitting in.) This isn’t some exotic new technique. Writing past the end of a buffer has been one of the most common software weaknesses for decades, and it’s not going away. About a quarter of MITRE’s 2025 Top 25 list of the most dangerous software weaknesses is buffer overflows and their memory-handling cousins.

Back to the light bulb. Once they owned the bridge, they were on your home or office network, so from there they went after the computers using EternalBlue, the same exploit WannaCry used. A light bulb took over your network. Newer bulbs don’t have the problem, but if you’ve got old ones, update them, and if they’re too old to update, throw them away. I’m serious about that.

Devices should be seen and not heard. I don’t mean a light that says “welcome home” when you walk in. I mean how much it talks on the network: how many conversations it has, with whom, and how often. A light bulb really only needs to hear “on” and “off” from one controller. Plenty of devices do a lot more than that. They announce themselves to everything on the network, answer anybody who asks, listen for connections nobody uses, and check in with servers out on the internet. Chatter inside your network means that if anything else on it gets compromised, it can easily find your device and talk to it. Chatter outside your network, heaven forbid, means your device is regularly sending data out of the building to somebody else’s servers, and if that’s normal for it, a little extra data going out is much harder to notice. The more a thing talks, and the less it checks who it’s talking to, the more ways there are in.

And for the people who think an unusual wireless protocol is protection (the radio signals your bulbs, sensors and gadgets use to talk to each other without wires): security through obscurity doesn’t work, and radio isn’t even obscurity. People have been listening in on radio for as long as there’s been radio, and today an inexpensive receiver plugged into a laptop will do it. You can hide a wire inside a wall, but a radio signal goes right through the wall and out into the street.

Something already inside the walls

The fish tank, the imaging machines and the Hue bridge all have this in common. Nobody broke through the firewall. They used something that was already trusted and already inside, and then moved around from there. If your security model is a castle, these are the things somebody carried in through the front gate because they looked harmless.

Devices pretending to be something else

There’s a classic attack where a tiny computer is built to look just like a USB drive. You plug it in, and it tells the computer it’s a keyboard, and then a mouse, and it starts typing and clicking. Walk away from your unlocked laptop for a couple of minutes before the screen saver kicks in, and somebody can plug that in and own your machine. When I plug in a keyboard, I expect it to be a keyboard. If I bought some very cheap thing from somewhere I’ve never heard of, maybe it’s more than a keyboard. Think about where your stuff comes from.

Which brings me to my favorite phone call. A while back I got a voicemail from someone claiming to be from a government law enforcement agency. I don’t expect a call from law enforcement. That’s just not how they operate, so a voicemail like that has “scam” written all over it. Being the kind of guy I am, I didn’t call the number back. I called the agency’s main line and asked whether that number and that person were real. They were, and the agency told me exactly how to make him authenticate himself, which I did, and he put up with it. (He was asking about a former employee I couldn’t remember, so he went through all that for nothing.)

While we were chatting about security, he mentioned he’d found a USB drive in the agency’s parking lot that morning, carried it into the building, and plugged it into his computer to see what was on it. A law enforcement officer, in a big government office with an IT department. I asked him if he knew not to do that, and he said he wanted to see if there was something bad on it. Well, that’s one way to find out. Don’t pick up USB drives. I had planned to leave one lying around at the conference that would phone home if anybody plugged it in, just to see, but I decided that was evil. The odds were pretty good, though.

Setting up the click

A white hat hacker I work with has a favorite spear phishing trick (a scam aimed at one specific person rather than everybody). He sends his target an email with a PDF attachment that’s deliberately broken. There’s no malware in it, so it passes every scanner, it just won’t open. Then he calls and says “hey, I just sent you that invoice, did you get it?” No, it wouldn’t open. “Oh, what version of Acrobat are you using?” Now he sends a second email with an attack built for that exact version, and you’re expecting it, so of course you open it. Notice what happened there. The usual advice is not to open attachments you weren’t expecting, and that’s good advice, but this trick is built to get around it. The first email carries nothing. Its only job is to make the phone call sound reasonable, and the phone call turns the second email from unexpected into expected.

That’s social engineering, which is about the oldest security attack in the world: talk a person into opening the door for you. No device fixes it, and it’s the same pattern as the parking lot USB drive, where you get somebody inside to carry it in for you. The defense is the one I used on my mysterious law enforcement caller. If somebody contacts you about a file, an invoice or anything else, check them out through a channel you already trust, not the one they handed you.

It’s just a tire sensor

At the talk I asked who owned a Chrysler product newer than 2014. One guy admitted it. That was the Jeep that Charlie Miller and Chris Valasek took over remotely in 2015, which ended in a recall of 1.4 million vehicles, so the idea that a car can be hacked wasn’t news even then. What interests me more is the little stuff in the car that nobody thinks of as a computer on a network.

Take tire pressure sensors. They’re required on new cars in the US and Europe because low tires cause accidents, so regulators decided a sensor in every wheel, chattering away over the radio, was worth it. They’re low-power radios, meant to reach only from the wheel to the dashboard, so the thinking was that nobody else could really hear them. And even if somebody did, every brand, and sometimes every model year, spoke a different protocol (its own little radio language), so good luck making sense of it.

Back in 2010 researchers from Rutgers and the University of South Carolina showed that the sensors didn’t check who was talking and didn’t scramble their signals, that you could pick up those signals from 40 meters away, and that you could fake them well enough to trigger the low-tire warning in a car moving next to yours on the road. In one case they confused the system so badly the dealer had to replace it. So much for nobody being able to hear them. And it didn’t get better with time. In 2021, researchers at the University of Colorado Colorado Springs went back and found tire sensors on cars from 2013 through 2019 still broadcasting in the clear and readable from 35 meters away, this time with under $50 of radio gear instead of the original team’s $1,500. (That also means your tires can be used to track your car.)

As for all those different languages, that was never much protection, because an attacker only needs to learn the one your car speaks. And it’s far less true than it used to be. The same 2021 team found that tire sensors across vehicle models use just nine data formats on two radio frequencies, and car makers have been consolidating on common protocols across the rest of the vehicle too. The fallback argument was that the worst case is either a false warning (annoying) or a missed one (maybe dangerous). Who cares?

A couple of years before the talk I was at an IQPC conference in Berlin and got into a conversation with an engineer from a car maker I won’t name. They’d been advertising a self-inflating tire system, so I asked him whether it worked while the car was moving. Yes. And how fast and how hard could it pump? Pretty fast, with a lot of pressure, because tires heat up when you drive and the pressure changes, and the system has to keep up. So I asked what his system would do if a sensor suddenly reported that a full tire was dropping toward zero. He thought about it for a second and said, well, it would try to fix it, and you could blow the tire right off the car.

Then I asked whether that was in his hazard analysis, the safety review the car industry’s ISO 26262 standard requires, and what risk level he’d given it. It wasn’t in there. And I want to be fair to him. This wasn’t a lazy engineer or an unserious company. He was a dedicated guy at a company that builds good vehicles, and he saw the problem the moment I asked. Their analysis assumed the sensor was telling the truth, because the sensor is just a sensor. Safety engineering trains you to ask what happens when something breaks. Asking what happens when somebody makes it break on purpose takes a more devious mind. To be clear, I don’t know of anybody who has actually done this, and I’m not saying it would be easy. But faking the sensor had already been demonstrated, and when they thought about what could go wrong, nobody had connected the sensor to the pump.

That’s the fish tank again, only with more sophisticated people missing it and much higher stakes. And here’s the part that aged well. In 2018, automotive cybersecurity was guidance, not a requirement. SAE had published a recommended practice in 2016, and the US National Highway Traffic Safety Administration had issued voluntary best practices the same year, but nothing made a carmaker do any of it. Since then ISO/SAE 21434 was published in 2021 as the cybersecurity engineering standard for road vehicles, and a United Nations vehicle regulation, UN Regulation 155, made an audited cybersecurity management system mandatory for new vehicle types starting in July 2022, and for all new vehicles starting in July 2024, in the countries that adopted it, including the whole EU. The industry eventually had to be told, by rule, to ask the question I was asking in that hallway.

If you build these things

I spend my days on security from the inside out, at the code level, and I’ve been on the same soapbox since long before this talk. It’s an old adage that you can’t test quality into a product. Somehow we still think we can test security into one. You can’t. By the time the penetration testers (the people you pay to break in) find the buffer overflow, it’s already in the code, and probably in a few other places they didn’t look.

Look back at what actually broke in these stories. The Hue bridge fell to a heap-based buffer overflow. More than half of those infusion pumps were exposed to a buffer overflow in their operating system. The tire sensors accepted any data from anybody without checking it. None of that is exotic. It’s the stuff we’ve known how to prevent for decades, which is the frustrating part.

Think about the little UL mark on almost every electrical thing you own. It means the device was built to engineering standards and isn’t going to shock you under normal conditions. There are standards and lists that do the same job for security, and the point of them is to keep the problem from getting into the code in the first place rather than hunting for it afterward:

• CWE. The Common Weakness Enumeration, a shared list of software weakness types, which is the language most vulnerability reports and tools speak. The CWE Top 25 is a reasonable place to start if you don’t know where to start.
• CERT C and CERT C++. Carnegie Mellon Software Engineering Institute’s secure coding standards, built directly around how code gets exploited.
• OWASP. The Open Worldwide Application Security Project, best known for its Top 10 lists. The one that matters here is the OWASP IoT Top 10, the top things to avoid when building, deploying or managing connected devices. Number one is weak, guessable or hardcoded passwords. It’s still the 2018 edition, and most of it still reads like this week’s news.
• UL 2900. The UL 2900 series covers software cybersecurity for network-connectable products, with parts specific to areas like medical devices. I sat on the UL 2900 board, so I’m biased, but it’s the closest thing to that UL sticker for connected software.
• MISRA C and MISRA C++. MISRA’s coding guidelines started in the car industry and are now used in embedded software everywhere. People think of MISRA as a safety standard, and MISRA themselves complained about that perception. In 2016 they published Amendment 1 to MISRA C:2012, which added 14 security guidelines (a number of them about tainted data, meaning input you shouldn’t trust), along with guides showing how MISRA lines up with other secure coding rules, including CERT C. That security material is now folded into the consolidated MISRA C:2023 and the current MISRA C:2025, and MISRA C++:2023 picked up the security work too. If you’re writing embedded C or C++ and you’re already doing MISRA for safety, you’re closer to secure code than you think, as long as you’re using the current editions.

Beyond coding standards, two things would have stopped a lot of these stories. First, devices should check who they’re talking to before they believe anything. A bulb shouldn’t take firmware from another bulb because it asked nicely, and a tire pump controller shouldn’t believe any radio message that claims to be a tire. Second, when you think through how your device could be attacked, don’t stop at what the device does. Ask what it can reach, and what else trusts it. If your sensor feeds something that can blow a tire off a car, the sensor isn’t “just a sensor” anymore, and your hazard analysis should say so.

(And yes, memory-safe languages take a whole class of these bugs off the table, but that’s a tale for another day.)

If you buy these things

Most of us aren’t building light bulbs or fish tank thermometers. We’re buying them, plugging them in, and forgetting about them, and that’s where most of the risk actually lives. Here’s what I’d do.

Keep strangers off your network. When I asked the room how many people let a visiting friend or relative onto their home Wi-Fi, nearly everybody raised a hand. You’re all so nice. Practically every router sold in the last several years supports a guest network, so use it, for guests and for the gadgets you don’t fully trust. My plan for the lizard’s tank (more on the lizard below) was to put the whole contraption on the guest network, because I didn’t trust it either. At work, segment your network so the cheap stuff can only reach what it needs. Just don’t assume that’s the end of it. The casino actually did this: according to Darktrace, the fish tank had its own private, separate connection, isolated from the rest of the network, and the attackers got through anyway. That’s not a reason to skip it. People can still steal your car, but you should still lock the doors.

Watch what your devices are saying. Back in 2011 the Wall Street Journal reported that Chinese hackers had been inside the U.S. Chamber of Commerce network for months, and after the Chamber cleaned up, it kept seeing strange things. A thermostat in a Chamber-owned townhouse on Capitol Hill was communicating with an internet address in China, and a printer started spitting out pages of Chinese characters. So the Chamber thought it had the problem shut down, and then, by the way, the thermostat is talking to China. Maybe they’d shut it down and maybe they hadn’t. I don’t expect my thermostat to send packets anywhere interesting, and if it starts sending big ones somewhere I’ve never heard of, I want to know. How many of you have ever checked what your thermostat talks to? At the talk, two people raised their hands. Good on them.

Monitoring is what caught the fish tank, but look at the timing. It caught it after about 10GB had already left the building. Monitoring tells you something is wrong. It doesn’t stop the first gigabytes from going out the door, and it only limits the damage if somebody is watching the alerts and acts on them fast. A high-roller database that’s halfway to Finland is still in Finland.

So use monitoring to back up something stronger. A thermometer’s normal behavior is easy to describe: small readings, on a schedule, to one place you know. Write that down as the rule, and block everything else where your network meets the internet instead of just flagging it. If the fish tank had only been allowed to talk to its vendor’s server, 10GB to a stranger in Finland wouldn’t have been an alert. It would have been a dropped connection. Segmentation limits what a device can reach, outbound rules limit what it can send, and monitoring catches what slips past both. You want all three, because any one of them alone is how you end up in somebody’s conference talk.

Ask whether the connection is worth it. Right before the talk I downloaded a bell app, just to see. You open it, there’s a bell, you shake the phone, the bell rings. That’s the whole app. The top-rated one in the store wanted access to my photos, my files, and my call history. Why does a bell need my call history? No, thank you. For every connected thing, ask yourself whether what the connectivity gives you is worth more than the risk it brings. Sometimes it is. Your kids’ connected toys, though? Just say no. Researchers have found toys that were effectively listening devices, and it gets worse. In 2017 Germany’s telecom regulator banned a talking doll called My Friend Cayla and told parents to destroy the ones they had, because researchers showed that anyone within Bluetooth range could connect to it, listen to the child playing with it, and talk to that child through the doll. Ugh. I can’t think of a creepier thing to bring into the house.

Think about where it comes from. Be careful what you’re buying, where it’s built, how it’s assembled, and who’s standing behind it. The cheapest thing on the marketplace may be cheap for a reason.

Hold vendors accountable. Don’t buy devices whose makers won’t tell you how they handle security and updates. If you’ve got one that turns out to be junk, complain, ask for your money back, and tell people. If you buy at work, this is where you ask vendors what’s in their software, how long they’ll patch it, and how they’ll tell you when something’s wrong. Companies that make insecure devices only change when it costs them money, and you’re the one with the money.

About the lizard. A relative had a bearded dragon, and those need careful temperature control or they die. Naturally I wanted to wire up the tank with thermometers, day and night light cycles, an oxygen sensor, the works, with alerts to my phone. They said no, it’s just a lizard. So we did nothing, the heating element quietly broke during a cold snap, and the lizard died. So I’m not telling you to give up on connected stuff. I’m telling you to connect it on purpose, knowing what it can reach.

Regulation or insurance, pick one (they picked both)

I closed the 2018 talk by saying we were going to get regulation, and that the real argument was regulation versus insurance. Either you make it legally unviable to ship junk, or you make it financially unviable. Either one works.

The regulation showed up. California’s law requiring connected devices to ship without a universal default password took effect in 2020. The UK’s product security law banned default passwords on consumer connected products in 2024, along with requiring a way to report vulnerabilities and a stated minimum update period. The EU’s Cyber Resilience Act entered into force in December 2024, its vulnerability reporting obligations kicked in just this September, and full compliance, including security by design and the CE mark products need to be sold there, applies from December 2027. Add the UN rule for cars and that’s a lot of rules for something everybody told me was just a stupid little light bulb.

The insurance part was less of a guess than it sounded. Some of the people in the Cybersecure LA community were cyber insurers, and we’d had long conversations about where their policies were heading. On stage I said that if I were writing cyber insurance policies, I’d exclude anything with a vulnerability published in the National Vulnerability Database that you hadn’t patched, because insurers are in business to make money. Some insurers seem to be doing roughly that. Chubb’s Neglected Software Exploit endorsement gives policyholders 45 days to patch a vulnerability once it’s published in that database, after which more and more of the risk shifts to the policyholder at 45, 90, 180 and 365 days. It isn’t universal, and some insurers, Coalition for one, argue publicly that exclusions like this undermine the point of having insurance. But the idea that “you knew about it and didn’t patch it” will cost you at claim time is no longer hypothetical.

So the next time somebody tells you it’s just a thermometer, or just a light bulb, or just a tire sensor, don’t ask what it does. Ask what it can reach. Then make sure the answer is “not much.”

Stay secure out there.

Jumping the Goldfish: IoT insecurity Eight Years Later. originally appeared on Code Curmudgeon on October 1, 2026.

http://codecurmudgeon.com/wp Twitter: @codecurmudgeon

Source: https://codecurmudgeon.com/wp/2026/10/jumping-the-goldfish-iot-insecurity-eight-years-later/