{"id":11170,"date":"2016-11-30T00:01:07","date_gmt":"2016-11-30T00:01:07","guid":{"rendered":"https:\/\/evosec.eu\/?p=11170"},"modified":"2016-12-08T05:13:54","modified_gmt":"2016-12-08T05:13:54","slug":"mirai-botnet-hard-coded-passwords","status":"publish","type":"post","link":"https:\/\/evosec.eu\/fr\/mirai-botnet-hard-coded-passwords\/","title":{"rendered":"MIRAI Botnet and hard-coded passwords"},"content":{"rendered":"

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<\/a> ).<\/p>\n

Some of the CERTs out there and other security experts and consultants are suggesting to \u00ab\u00a0change passwords\u00a0\u00bb. 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).<\/p>\n

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 \u00ab\u00a0base\u00a0\u00bb 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?<\/p>\n

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.<\/p>\n

Ok, but what can we do to really change the passwords? What can someone do? There are several approaches:
\n-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
\n-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
\n-get the filesystem, find the firmware update procedure, \u00ab\u00a0patch\u00a0\u00bb 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<\/em>; 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<\/p>\n

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?<\/p>\n","protected":false},"excerpt":{"rendered":"

Can you change hard-encoded passwords? Yes, sometimes you can. But that’s not a simple task. Here are some thoughts on this.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[98,932,947,99],"tags":[508,983,981],"class_list":["post-11170","post","type-post","status-publish","format-standard","hentry","category-iot-newsupdates","category-iot-security","category-it-security","category-it-security-newsupdates","tag-ddos","tag-hardencoded","tag-mirai"],"translation":{"provider":"WPGlobus","version":"3.0.2","language":"fr","enabled_languages":["en","da","de","es","fi","fr","it","hu","nl","no","pl","pt","ru","sv"],"languages":{"en":{"title":true,"content":true,"excerpt":true},"da":{"title":false,"content":false,"excerpt":false},"de":{"title":false,"content":false,"excerpt":false},"es":{"title":false,"content":false,"excerpt":false},"fi":{"title":false,"content":false,"excerpt":false},"fr":{"title":false,"content":false,"excerpt":false},"it":{"title":false,"content":false,"excerpt":false},"hu":{"title":false,"content":false,"excerpt":false},"nl":{"title":false,"content":false,"excerpt":false},"no":{"title":false,"content":false,"excerpt":false},"pl":{"title":false,"content":false,"excerpt":false},"pt":{"title":false,"content":false,"excerpt":false},"ru":{"title":false,"content":false,"excerpt":false},"sv":{"title":false,"content":false,"excerpt":false}}},"_links":{"self":[{"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/posts\/11170","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/comments?post=11170"}],"version-history":[{"count":3,"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/posts\/11170\/revisions"}],"predecessor-version":[{"id":11186,"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/posts\/11170\/revisions\/11186"}],"wp:attachment":[{"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/media?parent=11170"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/categories?post=11170"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/evosec.eu\/fr\/wp-json\/wp\/v2\/tags?post=11170"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}