In the footsteps of Mirai. Understanding how Trojans infect the IoT, using the example of the most evil of them.

[Brother]

It's time to send an old anecdote to the archives of history that malware for Linux must first be compiled from source, make sure that the system has all the necessary libraries, and only after that try to start it, having given it root rights. There are a lot of smart Linux devices on the market right now, and they have become one of the favorite targets of web makers. What is this interest based on and how do such malware work?

Elementary logic dictates that in order for a modern Trojan to successfully perform its functions, it must easily penetrate the system, have a stable Internet connection, and, if possible, remain unnoticed for as long as possible. All these criteria are perfectly matched by various devices of the "Internet of Things" category - routers, set-top boxes, network drives, media centers, as well as devices assembled on the basis of single-board computers. As a rule, they all sit on a thick Internet channel, which turns such equipment into a convenient tool for organizing DDoS attacks.

With penetration, too, often there are no serious problems. According to statistics, the majority of owners of smart devices are ordinary users who do not suffer from an excess of knowledge in the field of high technologies. They treat IoT devices like ordinary household appliances like a juicer or a toaster, often not even suspecting that they have any settings at all that can be changed if desired. Turned on, it works, and okay. Therefore, the default logins and passwords installed at the factory on such devices turn brute into a task that any schoolchild can do.

Finally, stealth. With this, everything is quite simple: who, pray tell, would think of looking for a Trojan in a set-top box or in the bowels of a router, especially since antiviruses for most of such devices are practically not found in the wild, and checking them remotely is another task for a simple user. And many difficult users sometimes by inertia are sure that malware for Linux does not exist in principle. Therefore, Trojans for IoT can feel completely at ease in the system: they are unlikely to be looked for there, and if they are, it is not a fact that they will be found.

The manufacturer is often at least as much to blame as the user: many smart devices with known vulnerabilities in the firmware do not receive updates from the manufacturer that could close the holes. This greatly improves the efficiency of using even outdated exploits. The probability of such devices "breaking through" is, on average, much higher than even computers with regularly updated Windows, not to mention servers or workstations with up-to-date "Linux" on board.

Motivating virus writers​

Why do malware creators install malware on smart devices? Traditionally, most of these Trojans have three "professions". First of all, these are the DDoS bots already mentioned above, which begin to flood to the specified address with network packets upon a command from the command and control server. Of course, one grandmother with a TV set-top box will not help you to overwhelm the enemy's server, but a dozen old women, as folk wisdom says, is already a ruble.

Secondly, a SOCKS proxy server is often set up on IoT devices, which can be used in various ways, primarily to ensure anonymity.

And finally, Trojans periodically start up in routers that change the addresses of DNS servers in the settings in order to display advertisements on client machines. At the same time, the computer itself, on which banners with ads for taxis, online casinos and girls of easy virtue suddenly appear out of nowhere, remains pristine, which any antivirus will confirm to the user.

Changing the DNS settings manually will not help anything: after restarting the router, everything will return to normal. Only resetting the device to factory settings or flashing it can save the situation, which for most ordinary people looks like a secret magic of the highest level. Sometimes miners come across on Linux devices, but recently, interest in them against the background of the general decline in the cryptocurrency market has been gradually decreasing.

Materiel​

The study of honeypot logs, with the help of which information security experts analyze the distribution of Trojans for the "Internet of Things" in nature, shows the next way of their delivery to the target device.

Typically, attackers connect to the device that attracted their attention via SSH or Telnet, guess the password using a dictionary, and, in case of successful authorization, disable the iptables utility to block the firewall. Then they just have to find the folder open for writing, save the desired application in it, corresponding to the device architecture, and launch it.

Attackers usually have ready-made builds of malware for various architectures: ARM, MIPS, SPARC, M68K, SuperH, PowerPC, SH-4 and other types of hardware. On some devices, you can arrange for the Trojan to automatically load by simply editing the file /etc/rc.local. You can periodically check whether the required process is running and, if necessary, restart it, for example, using /etc/cron.minutely.

Since many users of smart devices do not bother changing the default usernames and passwords, the dictionary for brute in most cases looks very trivial. Here are the most popular logins and passwords for hacking devices using the SSH protocol.

Also, the the when the Brutus to Via the SSH is often the the Used logins such as with the with the ubnt, user, oracle, bin, support, postgres.

The most popular combinations of usernames and passwords for hacking devices using the Telnet protocol.

LOGINPASSWORDrootxc3511rootvizxvrootankoroot5uprootXA1bac0MX In addition, to brute-force passwords using this protocol, widely used logins like admin, test and are very often taken telnet.

However, technologies do not stand still, and from a certain moment virus writers began to automate the hacking procedure. For example, if a Trojan succeeds in running on a compromised system, it can try to extract from various sources, such as a file ssh/known_hosts or bash_history information about hosts that the device previously accessed, and try to brute force them.

Other Trojans do it much easier: they generate a range of IP addresses and, in a loop, try to knock on the ports that are standard for SSH and Telnet. The advantage of this approach is its relative simplicity, the disadvantage is the significant amount of spurious traffic generated.

About three years ago, the range of malware for smart devices included at least a dozen different modifications of Fgt, Mrblack, Mirai, various flooders and DDoS bots. However, after the source code of Mirai was freely available on hackforums.com in September 2016, countless clones of this Trojan practically pushed other competitors out of the market. BrickBot, Sora, Wicked, Omni, Owari - all these are variations on the Mirai theme with the additions of more and more collaborators.

How Mirai works​

According to researchers Sam Edwards and Ioannis Prophetis of Rapidity Networks, in 2016, Linux.Mirai infected more than 380,000 smart devices around the world, causing many high-profile DDoS attacks. After the source code of this Trojan was released to the public, not only information security specialists, but also thousands of anonymous virus writers immediately became interested in studying the principles of its operation.

The Mirai source code itself also has a number of borrowings from other sources and is largely based on the architecture of one of the DDoS bots that were distributed in the spring of 2016. This bot, in turn, has similar features to the Trojans of the Fgt family, known since 2014 - the flood function and the pseudo-random data generator were explicitly copied from there to fill packets sent to the attacked hosts. This "cross-pollination", which is generally typical for developers of open source software for Linux, seems to have taken root in the environment of virus-makers oriented to this platform.

All early versions of Mirai for different hardware architectures were statically compiled and used the uClibc.so standard library for uCLinux-based embedded systems. When launched, the Trojan allocated a memory area into which it loaded the config necessary for its operation.

Some configuration lines were stored encrypted in the ELF file itself and were decrypted before being loaded into memory. In particular, in this way the address and port of the management server, User-Agent and other parameters of HTTP requests were transmitted. This explains the way in which the researchers determined the address of the command center of this botnet.

Another notable feature of earlier versions of Mirai is the ability of the Trojan in a separate thread to kill the running processes of other competing bots by reading the contents of a folder in a continuous loop /proc/. The list of process names was stored in the config. But in the config handler, the authors of Mirai made a small bug: the list of processes was read in blocks of 2048 bytes, after which the name search was performed inside this buffer. If the desired value was located on the border of the block, it was ignored, and such a process avoided the common sad fate.

To prevent accidental unloading of its own process, the Trojan placed a file in its folder .shinigami - when a file with this name was found, the process was automatically excluded from the "firing list". However, in the malware code itself, the life limit on the infected device was wired: after a week of continuous operation, the Mirai process is automatically terminated.

The earlier version of Mirai described here was able to execute a dozen commands, including commands to set up and end a TCP connection with a specified host and various types of flooding via HTTP, UDP and UDP over GRE. Also, using this trojan, it was possible to organize DNS flood and TSource Query Flood, that is, a whole range of denial of service attacks.

When connecting to the command and control server, the Trojan gave it the IP address and MAC address of the network interface, as well as the architecture identifier of the infected device. In response, he waited for commands to arrive, for each of which he created a fork of his own process, which had a life span specified in a special variable.

If several commands were received in one cycle, they were executed in turn. At the same time, the commands to initiate a DDoS attack could contain several targets listed in the array. The contents of the command were parsed by a special parser, then the malware formed packet headers and their contents in a certain order (or, if necessary, took them from the config), sent these packets to the specified host, and after calculating the checksum, proceeded to the next target.

This entire procedure continued in a continuous loop until the process executing the command was terminated by a timer. In the event of a DNS flood, Mirai sent a hundred random domain name requests per cycle to the attacked DNS server, which, in the presence of at least a hundred active bots, was guaranteed to put the server on its blades.

Using a special set of commands, the operator could very flexibly configure the attack parameters: define the values of TCP flags, specify such characteristics of packets as maximum segment size and timestamp, send empty packets, packets with random values or information from the Trojan's configuration, set the target port and size sent data, as well as manage other TCP parameters.

Among other things, Mirai allowed to flood to a given node with encapsulated GRE packets using Transparent Ethernet Bridging. In this case, the embedded packet included a full Ethernet frame, in which the MAC addresses of both the receiver and the sender were randomly generated by Mirai.

In general, the developers have developed a rather powerful DDoS harvester that allows them to implement different attack scenarios and combine infected smart devices with almost any hardware architecture into full-fledged botnets.

One of the important functional modules of Mirai is a scanner of vulnerable hosts, with which you can connect using the Telnet protocol. This scanner was almost entirely borrowed from the source code of the Linux Trojan Fgt.

In general terms, the module operation algorithm consists of four stages: searching for vulnerable hosts on the network, enumerating logins and passwords using a dictionary, after a successful connection, sending an sh-script to the compromised device, which, as a final chord, downloads a Trojan binary for the required architecture from the control server ...

And now, in order. To begin with, the scanner creates 256 data structures containing a random IP address, socket parameters, and other useful information. All local and private ranges are excluded from the list of generated addresses. Then the Trojan tries to establish a connection with each of them, sending a message to its own command and control server when an error occurs.

The responses of the attacked host scanner looks for strings user, login, pass, dvrdvs or nameindicating a login request transmission, which he sends, using the vocabulary of the config.

If the login is successfully guessed, a login prompt found message is sent to the command server with the structure number and the task sequence number; otherwise, the Trojan will report an error or timeout.

It then looks for strings in the host's response to indicate that it is prompted for a password. If they are detected, the host sends a string from the dictionary, and the resulting response is checked for the values invalid, incorrect, fail, again, wrong, accessdenied, error, bad, success, busybox, shell or dvrdvs. They indicate the success or failure of the authorization.

The corresponding report is also sent to the C&C server. After that, the brute procedure is repeated in a loop for all 256 structures. Thus, for each pass of the cycle, the scanner can "spud" up to 256 random IP addresses.

If authorization is successful, the wget command is sent to the compromised host, which downloads the /tmp/ sh script from the command server and saves it to the folder . It, in turn, downloads a Trojan binary file corresponding to the device architecture from the network. With the help of this simple algorithm, the automatic distribution of Mirai and the infection of new smart devices, from which a botnet is subsequently formed, is organized.

Show must go on​

Any software product evolves over time: its creators eliminate identified errors and gradually add new functions. This fully applies to Mirai as well.

In the next version, which was distributed in the summer of 2016, the creators of the Trojan abandoned dynamic memory allocation for storing the config in favor of a static area, apparently to increase the stability of the program as a whole. The poxored lines in the config, after decryption and reading, were encrypted back directly in memory. Finally, a bug was fixed with the omission of the names of the killed processes, if they were on the border of the data block - now the parser has learned to access them by the index, which coincides with the position of the string in the array.

The generator of pseudo-random values was completely rewritten, and when Mirai was launched, it determined the IP address of the infected device by knocking on the Google DNS server (previously it used its own command and control server for this). The Trojan learned to interact with signal handlers and ignore them SIGINT via sigprocmask with the obvious goal of preventing the user from forcibly stopping the malicious process.

In the new version of Mirai, the function of changing the address of the control server was implemented using SIGTRAP, and incoming commands were processed strictly one at a time in order to avoid the formation of a queue.

For the convenience of working with sockets, the Trojan now has its own local server. So, the Berkeley socket created by the three was PF_INET bound to port 48101 of the local host and went into the waiting mode for an incoming connection.

If the malware was unable to create a socket and connect to it, the Trojan found the process that owned the socket and killed it: this way, the program would not hang when cyclic attempts to establish a connection through a function bind with a busy socket. That is why, in order to protect against Mirai, some information security experts recommended blocking TCP port 48101 on the device if it is not in use - this disrupted the normal operation of the server built into the Trojan.

In the updated version, self-defense was completely revised: instead of a crutch with a file, the .shinigami Trojan learned to determine the PID and did not kill the process whose identifier coincided with the current one. The already rich functions of Mirai were supplemented by the ability to arrange attacks like DNS Amplification, but the flood over the HTTP protocol disappeared from the list - however, in one of the following versions it returned to its rightful place.

The modification of the Trojan that the creators published on hackforums was somewhat different from the previous editions of Mirai. First of all, the program gained the ability to disable the watchdog timer so that if the system freezes, it does not automatically reboot. To make it difficult to find the Trojan on the device, the name of its process was chosen at random in the form of a sequence of Latin characters and numbers.

Another interesting point: immediately after launching Mirai, it deleted its own executable file from the disk. Finally, when a process named was found, the .anime Trojan not only unloaded it from memory, but also destroyed the corresponding executable file - something the creators of this bot clearly annoyed the developers with.

Among other things, a noteworthy bug was found in the source code of the September version of Mirai for the x86 architecture: due to the incorrectly specified name of the binary file, the configuration structure for it was not filled out correctly, but then the Trojan attempted to read from the config. But, despite this error, the Trojan was quite workable, and its rich arsenal of functions covered almost all the needs of bot bots.

Heirs to the empire​

Based on the Mirai source codes posted on the Web, a huge number of clones were created, supplementing the basic development with other useful functions.

Shortly after the leak to the public, a version of Mirai was born, equipped with a management server name generation (DGA) mechanism borrowed from the Ranbyus Trojan. This is a very significant innovation. If the address of the command and control server is hard-coded in the body of a malicious program or in its config, shutting down the server will lead to the loss of the entire botnet. In the case of using DGA, the addresses of the control servers are generated by the Trojan automatically according to a special algorithm, and when one of them falls, the botnet simply connects to the next, which increases the survivability of the network.

In one of the subsequent versions of Mirai, a local proxy server appeared, working in a separate process, in others, a self-updating function was added, and messages transmitted to the control center were encrypted using a four-byte key received earlier from the same server.

The ports used by Mirai were changed to ensure the further operation of the Trojan if the owner of the device blocks the previously known ones. Then Mirai began using exploits for known vulnerabilities in the Linux firmware of IoT devices: the "hacker" already wrote about this.

Based on the Mirai code, some enthusiasts have tried to develop their own versions of Trojans for Linux, such as the BrickBot, widely known in narrow circles by Mexican programmers, which carried exploits for the CVE-2018-10561 and CVE-2018-10562 vulnerabilities. This Trojan gained well-deserved popularity by downloading and running a shell script on the infected device, which sometimes successfully "corrupted" the device.

The availability of source code makes it very difficult for other IoT Trojans to compete with Mirai in popularity. Only a unique development by virus writers called Hajime can compete with this family of malware. But this is a completely different story, which I will tell next time.