Happily I´ve had enough time to do another Vulnhub’s boot2root challange, in this case a medium level machine originally created for HackTheBox platform called Node 1. One of the things to choose this machine was that this machine could let me improve my knowledge in NodeJS platform, unfortunately this goal only was able to get partially. But, let´s go with the assessment!

Information Gathering and Penetration Steps

In the port scanning only two services was listening in the host, a SSH service listening in 22/TCP port and a web app in 3000/TCP. I didn´t retrieve any result with the UDP port scanning.

Seemingly this two services didn´t have known vulnerabilities which could be exploitable to gain access on the system, so probably the explotation should be achieved with some application bug. The web application had only two dynamic services, one of them to recover some public information of three users (“tom”, “mark” and “rastating”) and the login form to access to a private zone. First of all I tried unsuccessfully to fuzz the login with dictionary and SQL injection attacks. In the other hand, the variables used in the profile zone didn´t be in client web browser so I was not able to abuse them. Also, I was not able to perform a web directory brute forcing due to a error messages (as will be shown later, server filtered Dirbuster through its specific User-Agent). Checking the web app in deep detail, I was able to see that when I do a request to retrieve information of some user, a request to an API is executed which responses to me with the SHA-256 hash of their passwords:

Cracking the hashes with online services and them using it in the login form didn´t be enough, I only got a message. As it could be shown before, this three users didn´t have admin rights (“is_admin:false”) so probably I needed to get an additional user with this privilege. Neither using this pair of user and credentials didn´t work in the SSH panel. Doing a GET request to the previous path of the API request let me obtain the admin user which I needed, “myP14ce4dm1nAcc0uNT”:

With the same online service which I used before, I got the admin credentials, “manchester”:

As it is shown below, the admin account has the possibility to download a Backup (probably a copy of MyPlace web app):

The file was a raw ASCII text file, but if the content is analyzed the binary structure seems to be a base64 coded file (the last characters had two “=” symbol). I confirmed this theory decoding the file as base64 coded file and checking again the file type, which was a protected zip file:

In order to get the password of zip file, I used “fcrackzip” tool which is within Kali distro. In this case, the password was “magicword” (I used first of all a crafted password dictionary but password was within rockyou dictionary):

fcrackzip -D -p rockyou.txt myplace.backup.b64

Inside of it, there was a “Var” Linux folder with the files of MyPlace project. I tried to retrieve useful information using data carving techniques such as the use of bulk-extractor tool, but I didn´t find nothing interesting. In the manual review of the folder the first thing that called my attention was the file dubbed “app.js”, which seemly to be the main Javascript file of the project. Within, I found a MongoDB user (“mark”) and password in conjunction with amount additional information.

As I said at the beginning of this post, the application executes a black list control in order to avoid the use of automatic discovering web directories tools, such as “DirBuster”:

I expended a lot of time trying to use this credentials with MongoDB, but I was unsuccessful (the TCP/Port didn´t seem to response to requests). Several checks after, I decided to use others methods, and I checked these credentials with the SSH service and…bingo! I got local access to the machine:

Privilege Escalation Step

The elevation process was very easy and I only expended 5 minutes. The first four minutes I tried to find some vulnerable services running locally, for example SUID bit scripts in which a shell could be executed with root rights, but all the apps or services with this bit enable not seemed to be vulnerable. So, my strategy to be root was the execution of known kernel exploits for the server version, and I got it in my second attempt the root flag (exploit: Linux Kernel < 4.4.0-116 (Ubuntu 16.04.4) - Local Privilege Escalation):