Tag Archives: ken munro

The Mirai Botnet Attack and Revenge of the Internet of Things

The Mirai Botnet Attack and Revenge of the Internet of Things

Once upon a time in early 2016, we were talking with pen tester Ken Munro about the security of IoT gadgetry — everything from wireless doorbells to coffee makers and other household appliances. I remember his answer when I asked about basic security in these devices. His reply: “You’re making a big step there, which is assuming that the manufacturer gave any thought to an attack from a hacker at all.”

Privacy by Design is not part of the vocabulary of the makers of these IoT gadgets

If you take a look at Ken Munro’s blog at Pen Test Partners, the security testing company he founded, it’s filled with examples of vendor’s PbD negligence. In fact he has a few hacking scenarios worked out for IP cameras, just the kind of IoT devices which were implicated in last week’s Mirai attack.

Once you understand some of his techniques, you come away with what I’m calling Munro’s golden rule when dealing with consumer-grade IoT: change the bleepin’ defaults if you want to prevent hackers from owning your IoT thing.

When hackers get control of, say, an Internet connected coffee maker — because an easy-to-guess admin default password that wasn’t changed — they then often also find the WiFi’s PSK in plain-text stored on the device as well. It gets pretty serious very quickly from there.

And Then Along Came Mirai

These types of attacks, though, require the hacker to be within range of the WiFi signal, then deauthenticate the IoT gadget with, say, aireplay-ng, and force it to reconnect to the hacker’s own access point. So you have more to worry about from neighborhood kids or the occasional wardriving attacker.

I came away from our interview with Munro thinking the baseline security of consumer IoT is, well, not very high, but also relatively benign, and involving security weakness known by a few security pros.

The Mirai attack last week changed all that.  The Internet of Insecure Things became a topic for coverage in even the non-technical media.  I was reading a good description in, of all places, Forbes of how cameras like the ones Munro tested were taken over by bots in the Mirai-based DDoS assault against DNS provider Dyn.

There’s still much we don’t know about the Dyn incident, but it’s clear that WiFi cameras were involved — perhaps up to 30,000.

So how were the hackers able to scale up the camera attack that I referenced above to take over thousands of WiFi cameras worldwide?

Certainly they weren’t sending scores of self-driving cars equipped with Yagi antennas to roam the roads.

At least, not yet.

Doomed by Default

Instead they realized that consumers, like their counterparts in IT organizations, are bad at changing default settings. I mean if security admins and other super users can’t update default passwords to other than ‘123456’, then how can ordinary humans do any better?

What I thought would be the hardest part for hackers to pull off — discovering the  address of the cameras — became relatively easy for them because of a default setting in WiFi routers that non-tech consumers never bother to reset.

Does anyone know what UPnP or Universal Plug and Play is?

I thought so.

UPnP is a protocol that let’s networked devices automatically open a port on the router to let you communicate with your gadget remotely.

The UPnP idea makes some sense in the context of WiFi cameras:  you might want to remotely view what’s going on in your kitchen or the kid’s room over a browser, or perhaps do some remote admin work using telnet. In that case, you would need a public port that’s mapped by your router to the device. UPnP does the mapping for you.

UPnP is convenient, but can lead to a less secure environment if you’re not careful about strengthening admin passwords to the device.

The hackers behind the recent Mirai attack exploited the consumer’s default-itis. Specifically, they took a brute force approach, scanning tens or even hundreds of thousands of routers worldwide searching for exposed telnet ports, which were likely added by UPnP.

They then gained shell access by trying a short series of typical default passwords —“12345”, “admin”, etc. —  until they succeeded in logging in. If not, they moved on to the next router.

Once on the gadget, which was in many cases a specific brand of wireless camera, they loaded the Mirai software, transforming the device into a bot spewing out UDP packets targeted at Dyn.

Do The Right Thing Right Now

Like many consumers, I was unaware of the UPnP capabilities of my router. After checking my own home router, I discovered that my UPnP was (long excruciating sigh) enabled. I’m fairly sure I never touched this setting, so this must have been the default from the vendor— Linksys in my case.

As a public service, I worked out the following list to help you avoid becoming an unwilling participant in the next IoT-based DDoS attack:

1. If you’re a consumer or small business person, I would disable the UPnP feature now! To inspire and help you, below is a snapshot of my Linksys router’s admin screen with the UPnP switch.


Don’t be like me. Disable the UPnP.

2. Take the time now to also update the admin password of your router and the WiFi PSK. And make these high-entropy – 8 or more characters of the battery-horse-staple variety. This would involve resetting the PSK on any other computers or devices already connected to the WiFi network.

3. With UPnP disabled, going forward when you add new devices, you would have to expose the relevant ports manually. That is, if you decide that you absolutely need remote access.

To do this, open up the port forwarding panel on the router and explicitly add a mapping entry. Refer to the manual for your device – camera, coffee maker, refrigerator, etc. – for details  It’s more work with this approach, but now you’ll be forced to really think about what you’re doing when adding IoT gadgetry.


Get to know your router’s port forwarding table. You may need to manually add entries. And remember to set strong passwords for exposed devices!


4. For any IoT devices already on the network, change their admin passwords, making them longer and more complex! Sure, you’ve disabled outside access to these gadgets by disabling UPnP. But you still have to worry about the local attacks I first wrote about in the beginning of this post.

5. Finally, download and run nmap on your WiFi network. It’s the port scanning tool I wrote about a few months back. You’ll get a report showing what ports are publicly exposed on your WiFi network. I’d then study the results to see if it matches your understanding of the apps or devices that have access to the great wide world.

If you’re like me, it’s just one or (more likely) zero ports.  If not, then you’ll have to do more investigation.


One more point to note: nmap requires the public IP address of your router, not its fake internal IP address — i.e., 198.x.x.1 To find out what the address is for your network, enter “what is my IP address” into the Google search bar on your browser.


Google knows everything, including your true public IP address.

Enter the IP address that Google returns into nmap for its deep-dive scan.

Designed to Fail

There’s enough blame in the Mirai incident to spread around to everyone involved: vendors, the public, and the government as well.

First, vendors need to up their game before releasing IoT devices. In Munro’s blog, he presents so many basic authentication and password problems withthe  IoT devices he’s tested as to almost make it seem as if they were ‘designed to be hacked.’

It’s that bad.

One step vendors can take is to encrypt and sign the downloadable firmware that’s available on their sites, thereby making it harder for hackers to work out their exploits by scanning the binaries for certain strings.  Or at least store WiFi passwords in encrypted form on the device.

Sheeple! We as consumers also need to cultivate a security mindset as well. Don’t assume that the IoT gadgets you install take care of everything. Ask questions! If you’re not being directed to update an admin password during installation, something is wrong. If that happens, put the gadget back in its box.

Finally, when we buy electronic devices, we know it has passed some basic tests and received approvals — Underwriters Laboratories, FCC, etc.

What about a privacy and security certification?

Some of the cameras that were hacked in the Mirai should never have been released on the market. Currently, there’s no data security equivalent of the FCC’s electronic compliance standard.

Perhaps there should be.  Or at least the IoT industry should set up their own security standards and enforce them.

In the near future, we can expect more incidents in which the default settings of IoT devices will continue to be exploited.  Want to get a better handle on the IoT environment?  Listen to the first part of our interview with Ken Munro.

[Podcast] IoT Pen Tester Ken Munro, Part I: Security Holes

[Podcast] IoT Pen Tester Ken Munro, Part I: Security Holes

This article is part of the series "[Podcast] IoT Pen Tester Ken Munro". Check out the rest:

Leave a review for our podcast & we'll send you a pack of infosec cards.

If you want to understand the ways of a pen tester, Ken Munro is a good person to listen to. An info security veteran for over 15 years and founder of UK-based Pen Test Partners, his work in hacking into consumer devices — particularly coffee makers — has earned lots of respect from vendors. He’s also been featured on the BBC News.

You quickly learn from Ken that pen testers, besides having amazing technical skills, are at heart excellent researchers.

They thoroughly read the device documentation and examine firmware and coding like a good QA tester. You begin to wonder why tech companies, particularly the ones making  IoT gadgets, don’t run their devices past him first!

There is a reason.

According to Ken, when you’re small company under pressure to get product out, especially IoT things, you end up sacrificing security. It’s just the current economics of startups. This approach may not have been a problem in the past, but in the age of hacker ecosystems, and public tools such as wigle.net, you’re asking for trouble.

The audio suffered a little from the delay in our UK-NYC connection, and let’s just say my Skype conferencing skills need work.

Anyway, we join Ken as he discusses how he found major security holes in wireless doorbells and coffee makers that allowed him to get the PSK (pre-shared keys) of the WiFi network that’s connected to them.

Continue reading the next post in "[Podcast] IoT Pen Tester Ken Munro"

[Podcast] IoT Pen Tester Ken Munro, Transcript

[Podcast] IoT Pen Tester Ken Munro, Transcript

This article is part of the series "[Podcast] IoT Pen Tester Ken Munro". Check out the rest:

I had a load of fun chatting with Ken Munro of Pen Test Partners. The transcript I’m releasing below of the podcast is a good read, and well worth your time. One of the underlying themes that Ken makes is that security features are not a priority in consumer IoT devices.

If you’d like to read more about the details of how he broke into the iKettle wireless coffee maker, you can check out this post or watch this entertaining video. In short: using an antenna a hacker can unlink the coffee maker from its current network and then relink to his own special mobile access point. He’s then able to pull out the WiFi or PSK key of the home or business owner’s network from the coffee gadget!

Another attack that I allude to in the interview is based on the fact that some IoT devices Ken tests are actually access points when they’re in an unconfigured state. That was the case with the Ring wireless doorbell. So a hacker can take advantage of this by surfing into the device and then, yet again, grabbing the plaintext PSK of the owner’s network stored on the gadget.

One bit of advice Ken gives on dealing with IoT security weaknesses (and this should sound very familiar) is to change the defaults: always update the manufacturer’s settings for pins, admin passwords, and SSIDs (the wireless access point name) of the device!  Hackers count on these to be in their original state, thereby allowing them to more easily enter the gadget.


Inside Out Security: You’ve focused mostly on testing the IoT — coffee makers, doorbells, cameas –and it’s kind of stunning that there’s so much consumer stuff connected to the internet.  The Ring Doorbell and iKettle, were examples I think, where you obtained the WiFi PSKs (pre-shared keys).

Could you talk more your work with these gadgets?

Ken: Yeah, so where they’re interesting to us is that in the past to get hold of decent research equipment to investigate, it used to be very expensive. But now that the Internet of Things has emerged. We’re starting to see low-cost consumer goods with low-cost chip sets, with low-cost hardware, and low-cost software starting to emerge at a price point that the average Joe can go and buy and put into their house.

A large company, if they buy technologies, has probably got the resources to think about assessing their security … And put some basic security measures around.  But average Joe hasn’t.

So what we wanted to do was try and look to see how good the security of these devices was, and almost without exception, the devices we’ve been looking at have all had significant security flaws!

The other side of it as well, actually, it kind of worries me. Why would one need a wireless tea kettle?

IOS: Right. I was going to ask you that. I was afraid to. Why do you think people are buying these things? The advantage is that you can, I guess, get your coffee while you’re in the car and it’ll be there when you get home?

Ken: No. It doesn’t work like that …Yeah, that’s the crazy bit. In the case of the WiFi kettle, it only works over WiFi. So you’ve got to be in your house!


IOS: Okay. It’s even stranger.

Ken: Yeah, I don’t know about you but my kitchen isn’t very far away from the rest of my house. I’ll just walk there, thanks.


IOS: Yeah. It seems that they were just so lacking in some basic security measures … they left some really key information unencrypted. What was the assumption? That it would be just used in your house and that it would be just impossible to someone to hack into it?

Ken: You’re making a big step there, which is assuming that the manufacturer gave any thought to an attack from a hacker at all. I think that’s one of the biggest issues right now is there are a lot of manufacturers here and they’re rushing new product to market, which is great. I love the innovation.

I’m a geek. I like new tech. I like seeing the boundaries being pushed. But those companies that are rushing technologies to market with not really understanding the security risk. Otherwise, you’re completely exposing people’s homes, people’s online lives by getting it wrong.


IOS: Right. I guess I was a little surprised. You mentioned in your blog something called wigle.net?

Ken: Yeah, wigle is ….  awesome and that’s why WiFi’s such a dangerous place to go.


IOS: Right.

Ken: Well, there’s other challenges. It’s just the model of WiFi — which is great, don’t get me wrong — when you go home with your cell phone, your phone connects to your WiFi network automatically, right?

Now, the reason I can do that is by sending what are called client probe requests. And that’s your phone going, “Hey, WiFi router, are you there? Are you there? Are you there?”

Of course, when you’re out and about and your WiFi’s on, it doesn’t see your home WiFi router. But when you get home, it goes, “Are you there?” “Yeah, I’m here,” and it does the encryption and all your traffic’s nice and safe.

What wigle does — I think it stands for wireless integrated geographic location engine, which is crazy …  security researchers have been out with wireless sniffers, scanners, and mapped all the GPS coordinates of all the wireless devices they see.

And then they collate that onto wigle.net, which is a database of these which you can basically query a wireless network name … and work out where they are.

So it’s really easy. You can track people using the WiFi on their phones using wigle.net. You can find WiFi devices. A great example of that was how we find the iKettle, that you can search wigle.net for kettles. It’s crazy!


IOS: Yeah, I know. I was stunned. I had not seen this before. I suspect some of the manufacturers would be surprised if they saw this. We see the same thing in the enterprise space or IT. I’m just sort of surprised that’s just so many tools and hacking tools out there.

But in any case, I think you mentioned that some of these devices start up as an access point and that, in that case, you know the default access name of the iKettle or whatever the device is, and then you could spot it.

Is this the way the hackers work?

Ken: No, that’s right. The issue with an IoT WiFi device is that when you first put it up, you need to get through a process of connecting to it and connecting it to your home WiFi network.

And that is usually a two-stage process. Usually. It depends. Some devices don’t do this but most devices, say, the iKettle, will set itself up as an access point first or a client-to-client device, and then once you go in and configure it with your cell phone, it then switches into becoming a client on your WiFi network. And it’s going through that set of processes where we also found issues and that’s where you can have some real fun.


IOS: Right. I think you took the firmware of one of these devices and then was able to figure out, let’s say, like a default password.

Ken: Yeah. That’s another way. It’s a completely different attack. So that’s not what we’ll do in the iKettle. We didn’t need to go near the firmware.

But a real game changer with IoT devices is that the manufacturer is putting their hardware in the hands of their customers … Let’s say you’re a big online retailer. Usually you bring them in with application and you buy stuff.

With the Internet of Things, you’re actually putting your technology — your kit, your hardware, your firmware, your software — into the hands of your consumers.

If you know what you’re doing, there’s great things you can do to analyze the firmware. You can extract off from devices, and going through that process, you can see lots of useful data. It’s a real game changer, unlike a web application where you can protect it with a firewall … But the Internet of Things, you put your chips into the hands of your customers and they can do stuff with that potentially, if they have got security right.


IOS: Right. Did you talk about they should have encrypted the firmware or protected it in some way? Is that right?

Ken: Yeah. Again, that’s good practice. In security, we talk about having layers of defense, what we call defense in depth so that if any one layer of the security chain is broken, it doesn’t compromise the whole device.

And a great example for getting that right would be to make sure you protect the firmware. So you can digitally sign the code so that only valid code can be loaded onto your device. That’s a very common problem in design where manufacturers haven’t looked at code signing and therefore we can upload rogue code.

A good example of that was the Ring doorbell. Something that’s attached to the outside of your house. You can unscrew it. You can walk off with it. And we found one bug whereby you can easily extract the WiFi key from the doorbell!

Again, the manufacturer fixed that really quickly, which is great, exactly what we want to see, but our next step is looking at it and seeing if we can take the doorbell, upload a rogue code to it, and then put it back on your door.

So we’ve actually got a back door on your network.


IOS: Right, I know. Very scary. Looking through your blog posts and there were a lot of consumer devices, but then there was one that was in a, I think, more of a borderline area and it was ironically a camera. It could potentially be a security camera. Was that the one where you got the firmware?

Ken: Yeah, that was an interesting one. We’ve been looking at some consumer grade CCTV cameras, although we see these in businesses as well. And we’ve particularly been looking at the cameras themselves and also the digital video recorders, the DVRs where they record their content onto.

So many times we find someone has accidentally put a CCTV camera on the public Internet. You’ve got a spy cam into somebody’s organization! The DVR that records all the content, sometimes they put those on the Internet by mistake as well. Or you find the manufacturers built it so badly that ..  it goes on by itself, which is just crazy.


IOS: Yeah, there’s some stunning implications, just having an outsider look into your security camera. But you showed you were able to, from looking at the…it was either the firmware or once you got into the device, you could then get into network. Was that right?

Ken: Yeah, that’s quite ironic really, isn’t it? CCTV cams, you consider to be a security device. And what we found is not just the camera but also the DVR, if you put it on your network and ,,, it can create a backdoor onto your network as well. So you put on a security device that makes you less secure.


IOS: One of things you do in your assessments is wireless scanning and you use something, if I’m not mistaken, called Kismet?

Ken: Kismet’s a bit old now … There are lots of tools around but the Aircrack suites is probably where it’s at right now And that’s a really good suite for wireless scanning and wireless g cracking.


IOS: Right. So I was wondering if you could just describe how you do a risk assessment. What would be the procedure using that particular tool?

Ken: Sure. At its most basic, what you’d be looking to do, let’s say you’re looking at your home WiFi network. Basically, we need to make sure your WiFi is nice and safe. And security of a WiFi key  is how long and complex it is.

It’s very easy to grab an encrypted hash of your WiFi key by sitting outside with a WiFi antenna and a tool like Aircrack, which allows you to grab the key. What we then want to do is try and crack that offline. So once I’ve got your WiFi key, I’m on your network, and we find in a lot of cases that ISP WiFi routers, the default passwords just aren’t complicated enough.

And we looked at some of the ISPs in the U.K. and discovered that some of the preset keys, we could crack them on relatively straight-forward equipment in as little as a couple of days.


IOS: Okay. That is kind of mind-blowing because I was under the impression that those keys were encrypted in a way that would make it really difficult to crack.

Ken: Yeah, you hope so but, again, it comes down to the length and complexity of the key. If you WiFi network key is  only say — I don’t know — eight characters long and it’s not really going to stand up to a concerted attack for very long. So again, length and complexity is really important.


IOS: Yeah, actually we do see the same thing in the enterprise world and one of the first recommendations security pros make is the keys have to be longer and the passwords have to be longer than at least 8.

Ken: We’ve been looking at some … there’s also the character set as well. We often find … the WiFi router often might only have lower case characters and maybe some numbers, and those numbers and characters are always in the same place in the key. And if you know where they are and you know they’re always going to be lower case, you’ve reduced the complexity.


IOS: Right.

Ken: So I’d really like to be seeing 12-, 15-, 20-character passwords.

It’s not a difficult thing. Every time you get a new smartphone or a new tablet, you have to go and get it from the router then but really I think people can cope with longer passwords that they don’t use very often, don’t you think?


IOS: No, I absolutely agree. We sort of recommend, and we’ve written about this, that you can…as an easy way to remember longer passwords, you can make up a mnemonic where each letter becomes part of a story. I don’t know if you’ve heard of that technique.

You can get a 10-character password that’s easy to remember and therefore becomes a lot harder to decrypt. We’ve also written a little bit about some of the decrypting tool that are just easily available, and I think you mentioned one of them.

Was it John the Ripper?


Ken: John is a password brute force tool and that’s really useful. That’s great for certain types of passwords. There are other tools for doing different types of password hashes but John is great. Yeah, it’s been around for years.

IOS: It’s still free.

Ken: But there are lots of other different types of tools that crack different types of password.


IOS: Okay. Do you get the sense that, just going back to some of these vendors who are making these devices, I think you said that they just probably are not even thinking about it and perhaps just not even aware of what’s out there?

Ken: Yeah, let’s think about it. The majority of start-up entrepreneur organizations that are trying to bring a new IoT device to market, they’ve probably got some funding. And if they’re building something, it’s probably going to be going into production nine months ahead.

Imagine you’ve got some funding from some investors, and just as you’re about to start shipping, somebody finds a security bug in your product!

What do you do? Do you stop shipping and your company goes bust? Or do you carry on and trying to deal with the fallout?

I do sympathize with these organization, particularly if they had no one giving them any advice along the way to say, “Look, have you thought about security?” Because then they’re backed into a corner. They’ve got no choice but to ship or their business goes bankrupt, and they’ve got no ability to fix the problem.

And that’s probably what happened with the guys who made the WiFi kettle. Some clever guys had a good idea, got themselves into a position where they were committed, and then someone finds a bug and there’s no way of backing out of shipping.


IOS: Right, yeah. Absolutely all true.  Although we like to preach something called Privacy by Design — at least it’s getting a lot more press than it did a couple years ago — which is just the people at the C-level suite should just be aware that you have to start building some of these privacy and security ideas into the software.

Although it’s high-sounding language. And you’re right, when it comes to it, a lot of companies, especially start-ups, are really going to be forced to push these products out and then send out an update later, I guess is the idea. Or not. I don’t know.


Ken: That’s the chance, isn’t it?

So if you look at someone like Tesla, they’ve had some security bugs found last year and they have the ability to do over-the-Internet updates. So the cars can connect over WiFi and all their security bugs were fixed over the air in a two-week period!

I thought that was fantastic.

So they can update in the field … if you figured out that, brilliant. But they don’t have the ability to do updates once they’re in the field. So then you end up in a real stick because you’ve got products you can only fix by recalling, which is a huge cost and terrible PR. So hats off to Tesla for doing it right.

And the same goes for the Ring doorbell. The guys thought about it. They had a process whereby it got the updates really, really easy, it’s easy to fix, and they updated the bug that we found within about two weeks.

And that’s the way it should be. They completely thought about security. They knew they couldn’t be perfect from the beginning. “Let’s put a cable in place, a mechanism, so we can fix anything that gets found in the field.”


IOS: Yes. We’re sort of on the same page. Varonis just sees the world where there will always be a way for someone to get into especially newer products and you have to have secondary defenses. And you’ve talked about some good remediations with longer passwords, and another one we like is two-factor authentication.

Any thoughts on biometric authentication?

Ken: Yes. Given the majority of IoT devices have being controlled by a smartphone, I think it’s really key for organizations to think about how they’ve authenticated the customer to a smart device or, if they have a web app, the web interface as well, how they authenticate the customer to that.

I’m a big fan of two-factor authentication. People get their passwords stolen in breaches all the time. And because they will reuse their passwords across multiple different systems, passwords stolen from one place and you find another place gets compromised.

There was a great example, I think, some of the big data breaches … they got a password stolen in one breach and then someone got their account hacked. It wasn’t hacked. They just had reused the password!


IOS: Right.

Ken: So I’m a real fan of two-factor authentication to prevent that happening. Whether it’s a one-time SMS to your phone or a different way of doing it, I think two-factor authentication is fantastic for helping Average Joe deal with security more easily. No one’s going to have an issue with, “Look, you’ve sent me an SMS to my phone”.

That’s another layer of authentication. Great. Fantastic.” I’m not so much a fan of biometrics by themselves and the reason for that is my concern about revocation. Just in case the biometric data is actually breached, companies get breached all the time, we’ve not just lost passwords because passwords we throw them away, we get new ones, but if we lose your biometic, we’re in a bit more of a difficult position.

But I do biometrics work brilliantly when they’re combined with things like passwords. Biometric plus password is fantastic as a secure authentication.


IOS: Thanks for listening to the podcast. If you’re interested in following Ken on Twitter, his handle is TheKenMunroShow or you can follow his blog at PenTestPartners.com. Thanks again.

[Podcast] IoT Pen Tester Ken Munro, Part II: Probing Wireless Networks

[Podcast] IoT Pen Tester Ken Munro, Part II: Probing Wireless Networks

This article is part of the series "[Podcast] IoT Pen Tester Ken Munro". Check out the rest:

Leave a review for our podcast & we'll send you a pack of infosec cards.

We have more Ken Munro in this second part of our podcast.  In this segment, Ken tells us how he probes wireless networks for weaknesses and some of the tools he uses.

One takeaway for me is that the PSKs or passwords for WiFi networks should be quite complex, probably at least 12 characters. The hackers can crack  hashes of low-entropy WiFi keys, which they can scoop up with wireless scanners.

Ken also some thoughts on why consumer IoT devices will continue to be hackable.  Keep in mind that his comments on security and better authentication carry over quite nicely to the enterprise world.

Continue reading the next post in "[Podcast] IoT Pen Tester Ken Munro"