On the 10-th of December, 2019 the 14-th penetration testing laboratory Test lab was launched by us. On the 9-th day 3 participants managed to compromise laboratory nodes in a non-stop mode having determined the winners of this season. For all the rest who tried, tries and will try to Test lab 14, we decided to publish its passing.
The Test lab is a free platform for checking up and enhancement of testing skills on penetration presenting a corporative virtual company network consisting of vulnerable and invulnerable components of (servers, network equipment and working stations).
So it’s high time to consider all Test lab 14 tasks in order to give an opportunity for those who do not succeed to penetrate deeper into information security world and to learn something new for themselves. The content turned out to be quite huge, description — concise, but we hope it will be interesting.
All the information is provided for reference only. Do not use the received knowledge for illegal purposes.
Access to laboratories
For connection to the laboratory, we use a login/password received in your personal account. Instruction for setting up OpenVPN connection for Linux and Windows platforms is also there. At the moment of writing an article there were registered more than 30.000 participants on Test lab web site.
After getting a connection gateways 192.168.101.14 and 192.168.101.15 become available, after which there are situated the rest laboratory gateways.
Through gateway 192.168.101.15 you can interact with server Git web interface, but it is not clear what to do with it, because we do not have account data for authorization and automatic scanning instruments did not give expected results. Having decided not to lose time for enumeration, go on further.
Let’s start network’s survey with gate’s scanning 192.168.101.14 with the help of Nmap. While scanning we find out open ports 80, 143 and 8080.
Try to connect to 192.168.101.14:80. Attempting to appeal to a web application we get a redirect on site.test.lab, but a web browser can’t find it (ERR_NAME_NOT_RESOLVED). We get an access to a web site having added a record in /etc/hosts:
Having observed a virtual company site we save employees emails:
Uselessly we try to use WPScan:
Attempting to find vulnerabilities we get a customer’s page, containing one more email and save it. Probably a web site is secured by WAF. We’ll use it later.
There is Roundcube Webmail on port 8080, on port 143 — there is service IMAP. Let’s use a list of saved emails, trying to pick up a password:
hydra -L email.txt -P /usr/share/john/password.lst imap://192.168.101.14
We pick up email password successfully — firstname.lastname@example.org: PASSWORD. Having observed user’s e-mail, we find token and several files: client.jar, certificate.zip and vpn.zip.
Open jar-file as a zip archive and see, that it consists of one Main class. Open Main.class in IDE:
Having observed a decompiled code, we find out the information for connection to SSH and as a result perform the following command:
df -h | grep /dev/sda1
Whereas we pay attention to the following: a password changes. We add several lines to a class in order to output IP-address of a server, login and password using which connection becomes possible:
Сompile a changed class and change it by an original class in a jar-file. Run the file:
java -jar client.jar
A password introduced to a screen is a token.
Having found a configuration file, login and a password connect to VPN through a gateway 192.168.101.15:
We find a new route an addition on a subnet 172.16.0.0/16 in a connection log.
Having scanned a found network, we find a hosting accessible 172.16.0.11 with an open port 80:
It is a standard webpage, and we failed to find out something interesting in its code. A search for directions with the help of DirBuster turned out to be useless. As the tasks themselves presuppose Tokens’ search, we‘ll try to use a word «token» in a request. As a result you will download a file.
Scanning a network we find there one more host with an open port 53, on which DNS (BIND9) is available:
Using web site domen name, let’s compile a command for AXFR:
dig @172.16.0.10 test.lab axfr
We get records of DNS-server zone. Add those which were found А-records in a file /etc/hosts. In one of А-records we find an initial token:
Now we will scan domen’s controller found in NS task:
We try to get AD users’ list:
enum4linux -U 172.16.0.20
Save a conclusion. One user data contain a token:
While performing a task Java became known as a host 172.16.20.2 and one user’s account data. Having connected to a server by SSH in a folder /opt, find a token. If to continue a search, one can find a catalogue .crt and the following files in it: dev.key and dev.crt. Save the received information:
Having scanned a network 172.16.0.0/24, find one more server available with an open port 80:
Having taken port from terminal-2, start to analyze WIKI:
ssh -L 80:172.16.0.12:80 email@example.com
There is a search line on a web page, having texted there, we reassure, that it is reflected on a page:
For defining a template engine we’ll try to enter it in a search line
the information texted is displayed on page without changes, consequently, they are not Jinga nor Twig. Further to save the time let’s use Tplmap tool, though it could not clear up which template engine is used:
Using WhatWeb we learnt, that a website is written on Ruby-on-Rails:
Let’s try to use payload for a popular Ruby-on-Rails template engine on Haml:
On a website 49 is displayed, consequently, a template engine is found correctly. Know a template engine, compile a request, allowing to get a token:
On file basis in a catalogue .crt on terminal-2 edit found in email a configuration file VPN for connection to VPN-1:
Earlier, performing a task with DNS, we saw, that part of А-records is in networks 172.16.50.0/24 and 172.16.40.0/24. Similar situation is with VPN-2 task, examine a browser by the following route 172.16.50.11/token:
Download a file containing a token.
Now go to the site, which was not accessible for us earlier. Scan it by WPScan, but now our request is not blocked. We found an interesting plugin:
Having searched information, we find out vulnerability in plugin. Let’s use the found payload, on output page a file /etc/passwd is displayed, which contains a token.
This token could be received earlier, but it could be more difficult, passing WAF by. After several attempts to get an access to LFI, attacker‘s address is blocked. Nevertheless token file could be received this, for example:
Having scanned IP-address 172.16.50.21, we find an open 80 port, on which website News is available. On authorization page use an earlier found user account dev:
Search Field fuzzing failed. Dirbuster found nothing again. Manually we analyze files structure and find a file lenta.php.save, the contents of which allows to develop an attack:
Using the received data, compile a request for performing a command on a server. We get an access to the token file through RCE:
Except for found in /opt token, in a site directory we find a file DB.php. Coming from its contents, we understand using what kind of equipment a connection to a server data base appears to be possible 172.16.40.5. Having connected, we find a table, containing a token and output its contents using a command:
We still have a hosting 172.16.50.50, but TCP-scanning ended without results. Let’s scan UDP. We found an open SNMP port (161 UDP). Using the tool Onesixtyone we get community-lines:
onesixtyone -c /usr/share/john/password.lst 172.16.50.50
Further with the help of such an instrument as Snmpwalk we try to get information about server:
Analyzing a command output, we notice a strange system name, it is probably token. We also find a reference about network 172.16.60.0/24, proposing, that it is accessible through this server:
Prescribe found routes. An access is opening to a network 172.16.60.0/24. We find several systems (172.16.60.2–172.16.60.5) in it, on which port 22 is open:
Found earlier account data did not match, that’s why let’s realize an attack using a method of enumeration for users’ logins. We found account records — sidorov, petrov:
Connect to hosts with found account records and study them. On a server 172.16.60.4 we find dump in a file /opt, copy it for further analysis. On a server 172.16.60.3 find a file .ssh, containing a file id_rsa, save it. On a server 172.16.60.5 in a file /opt find a file with a token.
Study a found dump using a tool Tcpdump:
tcpdump -r /root/dump -A | grep token
Outputting a command we find a token and an account record leonov for server 172.16.0.21 (Git).
Add found account records to those ones which we already have.
Pass an authorization through a web interface:
Look commits through and find a token among them.
Find a repository certificate:
Clone a project and start it. Starting up we get an offer to enter a password. We see a project is the same as a certificate.so, received in Mail task. Having examined certificate.py, we find out, that it requests for a password and uses it probably for a certificate recoding. Modifying an initial code, add to it an output of a model password and a certificate while entering any page except for a correct password:
Save a file and start a program. Request for a password once again, but thanks to some edits made, get a token and a private key.
A task could be performed earlier, decompiling a file — certificate.so.
To scan a network 172.16.40.0/24, find an open port 22 on a server 172.16.40.2. Try to connect to well-known account data. We failed to enter from any account record, but earlier we found out that a user sidorov has a private key, that’s why we will try to connect using it:
ssh -i /root/id_rsa firstname.lastname@example.org
In /opt we find a hidden file with a token:
Further an access to new servers is opened in this subnet. On 172.16.40.3 we find ports 80 and 9000 open. Having connected to port 80, we see, that technical works are carried out on a website.
Further we start to fuzz it a service on port 9000 (FPM). Using a script on Python we get an access FPM to a server:
python fpm.py 172.16.40.3 /var/www/admin.test.lab/index.php -c «<?php system(‘cat /opt/token’); ?>»
In output we found out a token.
We find out a host 172.16.40.6, on which port 22 is available. Pass authorization, using an user’s sidorov account record, PIN is required:
In order not to waste time on a search, let’s proceed to other tasks. Unfortunately, other hosts from this network are not accessible from a terminal. Suppose, that an access to them can be received through a machine from GH. But even in spite of PIN-code checking up it is possible to perform a ports forwarding:
ssh -L 2222:172.16.40.4:22 email@example.com -i /tmp/id_rsa
In the process of connection to a server no one account record matched, even sidorov with his private key failed. Let’s try to use «Certificate» received from a task:
ssh -p 2222 firstname.lastname@example.org -i /tmp/id_rsa_cert
On server 172.16.40.4 in a folder/opt we find a file «revers», download it to a local PC and start it up. Starting up we get an offer to enter a password. Let’s try to decompile a file, finding out in the process, that the entered password is being compared with a line:
Suppose, that it is a password hash, let’s try to to guess it. In order not to waste much time let’s use online services:
Starting up a program we enter a password and get a token.
This task is for huge date analysis. Thus forward a port:
ssh -L 2222:172.16.40.6:22 email@example.com -i id_rsa
ssh -p2222 -L 9200:172.16.40.7:9200 firstname.lastname@example.org -i id_rsa
Open through a browser and undergo an authorization using account data petrov:P@ssw0rd, found on 172.16.60.0/24:
Having analyzed contents of a field Text in all messages, we found out, that symbol «|» is used only twice. A line between them is a token.
So on this stage passing Test lab 14 is finished. Thank you to read the information by the end.
That’s all. See you in the Test lab!