By now, most of us (and you) interested in our and your security have already heard about MIRAI – a botnet / botnet piece of code (that is now public – so anyone can use it) used in some very large-scale attacks ( starting with the attack on some of DYN’s servers ).
Some of the CERTs out there and other security experts and consultants are suggesting to “change passwords”. Well, easily said, hard to be done. Hard-coded we mean. As in: some (most) of the passwords used by the MIRAI botnet’s telnet attack (usually by port 23) are written in a read-only way (usually in a read-only partition of the troubling device).
A quick background on this: most of the devices than can be affected by MIRAI are usually embedded devices, running a base Linux distribution and, on top of that distribution, a vendor-specific application, a collection of applications or a mix of applications and services. Usually, this “base” Linux subsystem is provided by the manufacturer of the hardware / main SoC (SystemOnChip). And, usually, the manufacturers don’t want to or don’t know how to tackle too much with it – a simple customization, an application on top and here you go – you got a new product on the market. With default credentials in the base system, but who cares? Or what can go wrong?
Ok, back to the main problem: hard-encoded passwords. For device-stability reasons, the Linux subsystem (that has been explained above) is usually read-only. Better said, it’s mainly read-only and fully-writable during updates (take a look at the CRAMFS file system, for example, that’s used in most of these devices). But fully-writable comes with a drawback: you have to rewrite the whole partition/file system at once – you cannot write individual files.
Ok, but what can we do to really change the passwords? What can someone do? There are several approaches:
-wait for the manufacturer to issue a patch to close telnet or to change default passwords; if they change them with other non-user changeable ones, sooner or later it will also fall into problems
-talk to the manufacturer to issue a piece of software/code that allows firmware-level change of passwords – a little bit of more work, but you’ll get a product that has your own passwords hard-encoded
-get the filesystem, find the firmware update procedure, “patch” the firmware and reupload it to the device, without the need for help from the manufacturer – and here is where we can help you, if needed; of course, this can be done if the upgrade system has a low protection mechanism – but usually on these devices it doesn’t have any protection at all
A few thoughts: Since most of the manufacturers of these type of devices use GPL/OpenSource code, they should publish it under the license they agreed to. Do they do it?