One crucial part of being a penetration tester, it is to make a readable, high level and technical reports. Another interesting side to sharing this online is to help others break into those machines, see how the author went ahead and broke in and finally get feedback and meet new people. With that in mind here is my Moria write up!
Moria is said to be an intermediate machine and it stays true to that, if you don't have a certain process to follow or refer to, you won't get the entry point.
You can get the machine from Vulnhub.
We first begin with a
netdiscover -i eth0 -r 192.168.156.0/24 in order to identify the location of the machine on the network. The vulnerable machine comes out to be on
192.168.156.130 and the attacking machine is on
After identifying its location, we proceed to
NMAP the box in a fast manner, using
-F which provides us with the ports 21, 22 and 80. In order to cover the whole machine, another scan is run using
-p- while discovering the service on port 80. On the landing page, we get an image with no other directions to go from. We run a
dirbuster in the background as well and go check the
The scan results prove that the only ports open are 21, 22 and 80. Knowing the services open, a heavier scan is conducted to try and get a point of injection using:
nmap -sC -sV -O -p 21,22,80 192.168.156.130
Nmap scan report for 192.168.156.130 Host is up (0.00030s latency). Not shown: 997 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 2.0.8 or later 22/tcp open ssh OpenSSH 6.6.1 (protocol 2.0) | ssh-hostkey: | 2048 47:b5:ed:e3:f9:ad:96:88:c0:f2:83:23:7f:a3:d3:4f (RSA) | 256 85:cd:a2:d8:bb:85:f6:0f:4e:ae:8c:aa:73:52:ec:63 (ECDSA) |_ 256 b1:77:7e:08:b3:a0:84:f8:f4:5d:f9:8e:d5:85:b9:34 (ED25519) 80/tcp open http Apache httpd 2.4.6 ((CentOS) PHP/5.4.16) |_http-server-header: Apache/2.4.6 (CentOS) PHP/5.4.16 |_http-title: Gates of Moria MAC Address: 00:0C:29:0D:EE:A8 (VMware) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.9
In general, finding out that
FTP is open always results in juicy results. Trying to connect to that service, a greeting message for user Balrog gets displayed. Access wasn't possible since a password was needed. It looks apparent that the web service should point us somewhere in the right direction.
Looking at the
dirbuster results, a directory under 5-6 layers is discovered with the following URL
http://192.168.156.130/w/h/i/s/p/e/r/the_abyss/ where random messages between prisoners are shown. A special message is
knock . Talking geeky, whispering happens on the network. Combining that with that message,
port knocking seems like a nice place to look at. The concept of
port knocking describes that in order to get access to a certain
closed port, a certain sequence needs to be done for it to open for the user.
To detect that knocking,
Wireshark is used. Following an intuition, and not doubting my senses, I thought of checking what would happen when refreshing that page. To my luck, some knocking occurs:
It's a repeating sequence! It goes from 77 to 57 and then repeats. Considering that this is more CTFy than any real life scenario, it hits me that those numbers can be an ASCII sequence. The numbers are in a very reasonable range for ASCII characters. After checking what those numbers were, the word
Mellon69 is found out.
Trying that password out in the
FTP service, access is granted!
Discovering the service, the only place where an upload can occur is on an ftp directory. That isn't much of a help if execution can't be triggered somehow. Knowing that, generally web directories are badly configured. Going to
/var/www/html allows us to see the files and directories on that server. A hidden directory is found!
Hashes .. Who doesn't like those. Trying to check those using online web services for hash cracking, 0 results are returned.
No wonder those hashes returned nothing! In order to get back the original password, I went ahead and created the following python script: https://github.com/ThunderSon/Moria1.1/blob/master/md5_cracker.py. It was the perfect opportunity to practice my python skills.
Passwords can be inter-used, meaning that multiple users have the same password. You can use `patator` to test out the users with the password. In the end, Ori with the corresponding password was able to give us access.
patator ssh_login host=192.168.156.130 user=FILE0 0=users.txt password=FILE1 1=pass.txt -x ignore:mesg='Authentication failed.'
/etc/passwd, it is apparent that Ori is the only existing user.
Checking out the home directory of Ori, a
.ssh folder pops out. That is a gem most of the times. This directory gets created by the SSH agent on the system while creating keys to access the system, or when someone authenticates using ssh with an unknown key to the host.
Checking the known hosts, we see the location of
127.0.0.1. Reading the public file to see if a user and a machine are appended at the end, we get
Ori@Prison which is not very helpful.
To avoid going down rabbit holes, the privilege checker is ran in order to try and identify weaknesses in the system. After having a quick look on the results, I mapped out the prison quickly. Normally, the master which is Balrog have keys to the chambers of the prisoners. Prisoners have no keys.
The story isn't the same, but it surely tells that one has access to the other. In this case, Ori is able to access root. Simply trying to ssh as root gives us access!
ssh -i id_rsa email@example.com
Root is down!
The author really showcased a prison in this machine. It was really fun to dive in and stepping into it. That final poem is a real gem as well. Abatchy has other write-ups for machines as well as an OSCP write up.
If you enjoyed my writing you can find me on Twitter as @7hunderson.