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?