Filling in gaps in Mirai. It’s about DVRs, not cameras

We had an interesting morning with the BBC last week. On the back of the government cyber security initiative funding, we were asked to illustrate the broader problem with IoT etc.

Given the outages caused by Mirai-related DDoS, we went out to our local Screwfix to find a DVR / analogue camera package the night before.

We couldn’t find a Dahua device in time. The only alternative DVR in stock looked like it had potential. The device in question is no longer available at Screwfix, but still available at Argos, Amazon and several other online retailers

Less than 5 minutes after powering it up, we had root access using the same technique as used by Mirai. Unsurprising really, as it appeared to use similar components to the Dahua range.

What’s interesting is that this filled in a gap in knowledge about Mirai

Once the Mirai source code had been released, the default credentials it attempted were then known.

Brian Krebs and others put up a list with evidence to link the credentials to the vulnerable devices in nearly all cases. With a couple of exceptions…

And possibly a couple that weren’t attributed to the correct devices. That’s purely from the benefit of hindsight and further research, not a criticism of the awesome work that Brian and others have done on Mirai.

We of course attempted the default credential set against our shiny new DVR. And that’s where we filled in a gap

The default creds for the DVR device were root/zlxx. – including the full stop. So we now know why that credential set was in Mirai and that the possible attribution to an Electro Voice speaker wasn’t accurate.

That means that the Mirai authors knew about the default creds for this DVR, but no-one else seemed to. Even weirder – this credential issue has an old CVE for various Unix distros : CVE-1999-0502. Yes, that’s right, it’s from 1999.

Mirai is about the DVR, not the camera

Some of the attributed devices were CCTV cameras themselves. This seemed odd to us, as it’s the DVRs that had more functionality. On further digging, we found that all the cameras we looked at were running near-identical code to the DVRs and ran the ‘dvrHelper’ process, as did the DVRs we looked at.

So it strikes us that the reason the cameras were vulnerable is that they were running an uncustomised version of the DVR software, rather than being targeted specifically because they were cameras. Had the DVR functionality been removed from the code the cameras ran (which doesn’t appear necessary for them to function) then they may not have been vulnerable. Well, not to Mirai at least!

That said, there are some ‘all-in-one’ CCTV/DVRs on the market, but it’s the DVR functionality that creates the problem, not the camera

Other mis-attributed devices

We don’t think that RealTek Routers can actually be exploited by Mirai as it is currently. The same is probably true of the Panasonic printers – whilst the default creds are the same, it’s a coincidence

We think it’s more likely that the RealTek devices in question are from their DVR range, particularly as they are often rebadged and rebranded.

Similarly, the root/00000000 credentials are found in a number of DVRs, including Mezory devices http://www.mezory.com/support/faq.pdf.

And that Dreambox device? It’s a DVR/PVR

So, in conclusion…

Mirai is more to do with DVRs than CCTV cameras. We’ve thought this since writing this piece about MVPower DVRs back in February this year, but until we connected our new DVR with Mirai, we couldn’t substantiate this.

Some have claimed that they’ve seen Mirai traffic from devices that weren’t DVRs or cameras. We’ve been running a Mirai honeypot for some time. Whilst we’ve seen scans from routers and other devices attempting these same default credentials, none of them have then tried to exploit our honeypot in the same way as Mirai.

We think it’s more likely that there is code out there that is similar to Mirai doing this, but it’s not Mirai.