In my previous post I’ve mentioned that my coworker Konstantin Agouros captured a malware which attacked one of his routers in a lab.
For a long time most of us, security researchers, have been warning about the risk that poses routers and other network devices that run embedded systems that usually are in pretty bad shape when it comes to security.
We all do a bunch of researches that commonly end with some interesting results. When we comunicate the concerns that raised in our minds because of those research outcomes to our customers or even the ventors affected it is very common to face the following response: that’s theoretical, there’s nothing like that in the wild!.
This post is dedicated to all these people, the ones who like us do the research (yeah, keep working we are doing the right thing) and the people who basically tell us we are wasting our time.
Konstantin gave me two files, an ELF binary and a shell script.
- getbinaries.sh: the shell script file
- arm: the ELF binary
Since the symbols were not stripped from the ELF binary, a quick callgraph gives us a pretty straight view of what the main functionalities of the malware.
The malware runs the following shell script in order to install itself.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
It downloads all the malware binaries which were compiled for a number of architectures, change the file permissions to make them executable and afterwards it tries to execute them.
Basically, it bruteforces the execution of the malware, not the most clever way to do it but it works of course.
Once it is successfully executed it follows the folloing steps:
- Forks the process so that it keeps running in the background (like a service).
- Deobfuscates a list of IRC servers it has harcoded in the binary, and then connects to them using a password which is also hardcoded and obfuscated.
- Waits for commands.
Beyond the command cmd_exec, which allows the malware to execute whatever console command is given to on the system where it is running, the malware is able to do a couple of things by itself, which are described in the cmd_help command.
When the cmd_help command is called it sends the following content as a private irc message to the attacker:
With a bit of clean up we get the following help menu:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
What the malware is able to do is self explanatory by reading the above help menu.
The malware abuses a D-Link routers vulnerability, as the help menu says: “d-link config reset bug”, but it could be used to abuse any other given vulnerability, it would be using also any exploit which is uploaded to the router and use it against any target the attack is willing to.
I clarify this because most vendors will say: “we are not vulnerable to these attack”, to dodge the issue.
The truth is that any device which runs Linux suffices for the malware to execute and do its thing.
The attacker only needs a vulnerability to exploit and deploy the malware. Aftewards he/she can attack the rest of the network, or use the embedded system to compromise other networks.
The source code
Within the strings found in the binary, there was one that lead us to the source code of the malware which is available in a github repo!
Go and check it for yourself: Lightaidra
Interesting Legal Aspects
In Germany, whenever p2p software is used to download content for example from BitTorrent, the owner of connection is made automatically reponsible for the content that was downloaded from his connection.
Now, what if the one downloading contents/attacking/etc is the router? Who is responsible for this activities? The ISP for providing an insecure device?
This is an interesting question, since it definitely isn’t the fault of the person who doesn’t even know what the router is doing. Maybe it is nobody’s fault, who knows.
I bet lawyers and people who care about their privacy would be eager to further research and answer it.
This particular version of the malware was compiled to target routers only, but anybody could modify it to target all soft of embedded devices which are networked connected and running Linux as operating system, since the source code is out there, available to everybody.
I’ve run it in the lab on a Surveillance camera and it ran just fine.
Long story short:
Source Code Available + Multi-Architecture out of the box + Evil people everywhere = What might go wrong? …Right?