Introduction

This is the first post. I will summarize what I learned as a hobby for learning. This time is WriteUp of Retired Machine [Mirai] of HackTheBox.

Self-introduction

It's Kashiwaba. We provide technical support in Tokyo.

I am interested in my own OS and security and am studying. I'm doing HackTheBox as a hobby. The rank of HackTheBox is Hacker. Remarks are personal. (I wanted to say it once!)

Machine overview

--Platform: Linux --Difficulty: Easy (Easy, a fairly simple category) --Necessary technique / knowledge --Search using nmap / gobuster etc. --IoT malware attack method --Internal search method for privilege promotion --About Linux device management

Newly learned items in the capture of this machine

--Overview of IoT malware and attack methods --About Linux device files --How to salvage data deleted from flash memory

Machine capture

search

I will start to capture the machine at once. First, try port scanning as usual.

`console`


TARGET=10.10.10.48 && expose TARGET
nmap -sV -sC -T4 $TARGET| tee nmap1.txt

With this command, I got the following output.

Since port 80 is open, I will try to access it with a browser for the time being.

Now that you have a 404 returned, it's time to search for this web page. Before trying to search with gobuster, I tried to make it accessible with a common file path for the time being.

/robots.txt /admin /login

Apparently it was a hit with / admin, and the management console screen of the application called Pi-hole opened.

What is Pi-hole?

This is the first time I've seen this application called Pi-hole, so let's take a look at the documentation for now.

The Pi-hole® is a DNS sinkhole that protects your devices from unwanted content, without installing any client-side software. Overview of Pi-hole - Pi-hole documentation

As mentioned above, Pi-hole seems to be an application that can be used as a DNS sinkhole to protect your device from unwanted content. (A DNS sinkhole is a DSN that intentionally returns the wrong response to a query.)

It's called Pi-hole, but it seems that it can be deployed not only on Rasberry-pi but also on various platforms such as Debian and Docker containers.

Also from the documentation, I was able to identify the technology used in Pi-hole.

Pi-hole being a advertising-aware DNS/Web server, makes use of the following technologies:

dnsmasq - a lightweight DNS and DHCP server
curl - A command-line tool for transferring data with URL syntax
lighttpd - web server designed and optimized for high performance
php - a popular general-purpose web scripting language
AdminLTE Dashboard - premium admin control panel based on Bootstrap 3.x
sqlite3 - SQL Database engine Pi-hole Origins - Pi-hole documentation

There were some concerns, but it seems that the number of reported vulnerabilities is implemented in PHP, which is known as the top class, so I will try to find a hole that can break into the starting point.

Invasion

Vulnerability investigation

Now, let's look for a route that can break into the machine starting from the Pi-hole vulnerability. First, I confirmed from the management console that the Pi-hole version is Pi-hole Version v3.1.4.

When I searched for vulnerabilities corresponding to the above versions, I felt that these two could be used, but unfortunately both of them first needed to obtain credentials to log in to the management console. (* It's a meta story, but since this machine was made in 2017, CVE-2020-xxx is definitely not an assumed solution.)

CVE-2020-11108 --Authentication required --RCE vulnerabilities that exploit block list vulnerabilities
CVE-2020-8816 --Authentication required --RCE vulnerabilities through a specially crafted DHCP static lease

Get credentials

For the time being, I tried Google search with words such as Pi-hole Password. Then I found that I could reset the Pi-hole password by logging in to my local environment and running the following command:

`bash`


sudo pihole -a -p

Also, when I read some articles on how to set up a Pi-hole, it said that I should log in to the Rasberry-pi that installs the Pi-hole with the initial password raspberry.

At this point, I finally realized that the title of this machine was Mirai lol

What is Mirai

Mirai is malware that infects IoT devices and forms a huge botnet. It scans the network and breaks into the discovered IoT.

Mirai is also a variant due to various factors such as the ease of infection that pierces the hole that the authentication information is left in the default setting on many IoT devices, the source code was easily available, and so on. It was very popular including. One of the known threats to Mirai is that multiple DDoS attacks over 100 Gbps in 2016 stopped DNS services in the United States, affecting services such as Twitter.

When an IoT device is infected by misusing the default authentication information, it may be used as a bot to spread malware or used for DDoS attacks by remote control from the attacker's C & C server.

-IPA: IoT Security Threats and Countermeasures -Why is the worst DDoS attack in history "Mirai" spread? (1/4) --ITmedia NEWS -Mirai trend background, mainly due to "initial settings of IoT devices" | "iot security" for IoT security information -Thorough dissection of "Mirai" source code-Exploring its mechanism and countermeasures (1/4): IoT botnet that caused a large-scale DDoS attack-@IT

Also, if you read the source code of Mirai's scanner, it's very interesting because the default credentials of the IoT device are hard-coded. It also contains credentials that may be aimed at Toshiba network cameras and Panasonic printers.

In addition, although it is not Mirai, multiple IoT malware targeting Rasberry-pi has been confirmed. Linux.MulDrop.14 is one example, targeting the default credentials of Rasbian, the OS for Rasberry-pi.

Immediately after setting up "Rasbian", which is the official distribution of Raspberry Pi, you can connect by SSH with the user name "pi" and password "raspberry". A new IoT virus "Linux.MulDrop.14" that targets the vulnerable "Raspberry Pi" that has not changed the initial password has appeared! Cryptocurrency mining after infection-Livedoor News

Countermeasures against IoT malware such as Mirai

By the way, from the standpoint of the cyber security defender, I am trying to capture the machine in order to know the thoughts of the attacker, so I will briefly consider countermeasures against these IoT malware. (* Please note that this is an individual idea)

The first thing that comes to mind is that don't leave the factory password for your IoT device is useful. In fact, Rasberry-pi has also officially announced that it will change its default credentials.

However, it is doubtful how many people actually set passwords strong enough. So I think it's okay to design the OS to set credentials at boot time from the beginning. When you actually install Ubuntu for Rasberry-pi, you need to set the credentials at startup.

After that, I think it is of course necessary to say Do not expose unnecessary devices to the network / Do not expose unnecessary ports. I feel that many malware such as Mirai are aimed at network camera devices.

It seems that there are quite a few cases where ports are opened even in ordinary households in order to monitor images from outside, such as security cameras. The free internet is scary, so I don't want to be able to connect to my home network from the outside, though not very much ...

In addition to the above, you can think of IoT devices are properly updated to take countermeasures against vulnerabilities, or` exit countermeasures are set so that information is not sent to anyone other than a specific destination. However, depending on the manufacturer, such as IoT camera devices, we have seen cases where patches are not provided at all even if the vulnerability is announced, so it is a little doubtful whether the version upgrade will be a sufficient countermeasure against the vulnerability.

This time invasion

Well, I derailed a little, but I will return to the machine capture.

Since Pi-hole is running, the operating environment may be Rasberry-pi. (And the challenge name of the machine is Mirai ...)

So, try SSH with the Rasbian initial password.

`bash`


ssh [email protected] #Enter "raspberry" in the password

I was able to log in! After all it was Rasberry-pi!

When I checked it, I got the following output.

`console`


pi@raspberrypi:~ $ uname -a
Linux raspberrypi 3.16.0-4-686-pae #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) i686 GNU/Linux

Anyway, you now have a user.

Internal search

Next, in order to get root, we will look for holes that can be elevated. First, SCP will transfer the Linpeas file for exploration to the machine and obtain the execution result file locally.

`bash(local)`


scp /home/kali/Hacking/Knowledge/Exploits/linPEAS/linpeas.sh  pi@$TARGET:~/

`bash(Machine)`


sh linpeas.sh | tee linpeas_result.txt

`bash(local)`


scp pi@$TARGET:~/linpeas_result.txt ./

Looking at the output results, the following output was confirmed.

Gabagaba authority. If the result of sudo -l is similar to the output above, the user can executesudo <command>without a password. --To use sudo password without entering --Qiita

When I looked it up, it seems that Rasbian does not have a password set for sudo by default. In other words, Rasbian, which is the default setting, has unlimited SSH connection and privilege escalation.

If you use Rasbian for server purposes, you need to be careful. -Initial setting memo when using Raspberry Pi with Raspbian (add user) --Qiita

Authority promotion

So, I was able to get root privileges quickly.

`bash`


sudo su

Clear with this! I think, it continues a little more.

When I opened root.txt, I found the following text instead of the flag: Apparently the real root.txt has been lost.

root@raspberrypi:~# cd /root/
root@raspberrypi:~# cat root.txt 
I lost my original root.txt! I think I may have a backup on my USB stick...

But don't worry. Apparently the backup is stored on USB.

Internal search again

From here, do another search to get the backed up data.

However, looking for a USB is an easy win. If you've ever connected a USB to Linux, you'll find that it's often mounted under / media.

Looking at the contents, it was still there. However, it seems that I accidentally deleted the data ...

James is an inadvertent shop.

root@raspberrypi:~# cd /media
root@raspberrypi:/media# ls
usbstick
root@raspberrypi:/media# cd usbstick/
root@raspberrypi:/media/usbstick# ls
damnit.txt  lost+found
root@raspberrypi:/media/usbstick# cat damnit.txt 
Damnit! Sorry man I accidentally deleted your files off the USB stick.
Do you know if there is any way to get them back?
-James

I'd like to salvage the flag in root.txt that was somehow lost for the careless follow-up of James's ass wipe.

But what should we look for?

What you should think about here is "How Linux device mount works". As an aside, this book is an introductory and very informative way to see how the Linux kernel works.

Linux kernel textbook to learn from scratch while running

Linux device mount mechanism

Linux (or Unix-like) manages all connected devices by abstracting them as "device files". Reference: [What is a device file? | An IT terminology dictionary that makes you feel like "I understand" even if you "I don't understand" (https://wa3.i-3-i.info/word11689.html)

Device drivers are abstracted by the Linux kernel as "device files", given their customary names (sda, sdb, etc.) and then stored under / dev. Applications on the OS operate devices such as hard disks, USB, and mice by referring to this "device file".

Device files are mainly classified into "character type" and "block type", and fixed-length data such as hard disks are saved as "block type". Reference: Linux file type --Qiita

Get root flag

The target USB of this time should also be saved as this "block type" device file. Block devices that can be used by the OS can be output with lsblk.

`python`


root@raspberrypi:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   10G  0 disk 
├─sda1   8:1    0  1.3G  0 part /lib/live/mount/persistence/sda1
└─sda2   8:2    0  8.7G  0 part /lib/live/mount/persistence/sda2
sdb      8:16   0   10M  0 disk /media/usbstick
sr0     11:0    1 1024M  0 rom  
loop0    7:0    0  1.2G  1 loop /lib/live/mount/rootfs/filesystem.squashfs

It turns out that the / media/usbstick where the flag is stored is treated as a device file called sdb. Finally, we will retrieve the data from here.

The HackTheBox flags are stored as text, so honestly you can easily get them with just strings/dev/sdb. That's not too interesting, though, so I'd like to take a look at the contents of / dev/sdb.

From the result of lsblk, we know that the size of/dev/sdb is 10MB, so the trailing address is 0xa00000. I will output it with hexdump.

`bash`


root@raspberrypi:~# hexdump -C /dev/sdb 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0005b800  02 00 00 00 0c 00 01 02  2e 00 00 00 02 00 00 00  |................|
0005b810  0c 00 02 02 2e 2e 00 00  0b 00 00 00 24 00 0a 02  |............$...|
0005b820  6c 6f 73 74 2b 66 6f 75  6e 64 00 00 0c 00 00 00  |lost+found......|
0005b830  10 00 08 01 72 6f 6f 74  2e 74 78 74 0d 00 00 00  |....root.txt....|
0005b840  c4 03 0a 01 64 61 6d 6e  69 74 2e 74 78 74 00 00  |....damnit.txt..|
0005b850  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
* 
*Flag is around here
*
0080a820  0a 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0080a830  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0080ac00  44 61 6d 6e 69 74 21 20  53 6f 72 72 79 20 6d 61  |Damnit! Sorry ma|
0080ac10  6e 20 49 20 61 63 63 69  64 65 6e 74 61 6c 6c 79  |n I accidentally|
0080ac20  20 64 65 6c 65 74 65 64  20 79 6f 75 72 20 66 69  | deleted your fi|
0080ac30  6c 65 73 20 6f 66 66 20  74 68 65 20 55 53 42 20  |les off the USB |
0080ac40  73 74 69 63 6b 2e 0a 44  6f 20 79 6f 75 20 6b 6e  |stick..Do you kn|
0080ac50  6f 77 20 69 66 20 74 68  65 72 65 20 69 73 20 61  |ow if there is a|
0080ac60  6e 79 20 77 61 79 20 74  6f 20 67 65 74 20 74 68  |ny way to get th|
0080ac70  65 6d 20 62 61 63 6b 3f  0a 0a 2d 4a 61 6d 65 73  |em back?..-James|
0080ac80  0a 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0080ac90  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00a00000

To be honest, I'm not sure about the address map of a flash disk such as a USB memory due to lack of study, but I understand that the actual data is likely to be stored in the latter block.

In other words, when James removes root.txt from the USB stick, only the information to refer to root.txt is deleted, and the actual data remains until another data is overwritten at that address. That's probably the way to get the root for this machine.

Summary

Well, you have succeeded in capturing Mirai! I think that the following are the knowledge of the defender gained through this machine capture.

--The default authentication information is targeted --Sudo Let's narrow down the authority --Do not allow external SSH connection (use private key instead of PW authentication when publishing SSH) --If you want to delete the data when destroying the media device, overwrite it.

WriteUp is useful for organizing what I have learned, so I would like to write it again. Well then.

[LINUX] [HTB: Mirai] Write-Up + memorandum

Introduction

Self-introduction

Machine overview

Newly learned items in the capture of this machine

Machine capture

search

console

What is Pi-hole?

Invasion

Vulnerability investigation

Get credentials

bash

What is Mirai

Countermeasures against IoT malware such as Mirai

This time invasion

bash

console

Internal search

bash(local)

bash(Machine)

bash(local)

Authority promotion

bash

Internal search again

Linux device mount mechanism

Get root flag

python

bash

Summary

`console`

`bash`

`bash`

`console`

`bash(local)`

`bash(Machine)`

`bash(local)`

`bash`

`python`

`bash`