dpwwn:03

靶场下载

https://download.vulnhub.com/dpwwn/dpwwn-03.zip

信息收集

# nmap -sn 192.168.1.0/24 -oN live.nmap       
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-17 21:18 CST
Stats: 0:00:00 elapsed; 0 hosts completed (0 up), 255 undergoing ARP Ping Scan
ARP Ping Scan Timing: About 7.84% done; ETC: 21:18 (0:00:00 remaining)
Nmap scan report for 192.168.1.1 (192.168.1.1)
Host is up (0.00057s latency).
MAC Address: 00:50:56:C0:00:08 (VMware)
Nmap scan report for 0bcc61d9e6ea39148e78c7c68571e53 (192.168.1.2)
Host is up (0.00035s latency).
MAC Address: 00:50:56:FE:B1:6F (VMware)
Nmap scan report for 192.168.1.90 (192.168.1.90)
Host is up (0.00029s latency).
MAC Address: 00:0C:29:62:66:03 (VMware)
Nmap scan report for 192.168.1.254 (192.168.1.254)
Host is up (0.00021s latency).
MAC Address: 00:50:56:F2:47:CF (VMware)
Nmap scan report for 192.168.1.60 (192.168.1.60)
Host is up.

主机存活探测到目标靶机的IP地址为192.168.1.90

# nmap -sT --min-rate 10000 -p- 192.168.1.90 -oN port.nmap
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-17 21:20 CST
Nmap scan report for 192.168.1.90 (192.168.1.90)
Host is up (0.00055s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT    STATE  SERVICE
22/tcp  open   ssh
161/tcp closed snmp
MAC Address: 00:0C:29:62:66:03 (VMware)

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

探测到开放的端口为22端口，显示161端口closed~ 但是下面还是探测了其服务的版本等信息：

# nmap -sT -sC -sV -O -p22,161 192.168.1.90 -oN details.nmap
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-17 21:20 CST
Nmap scan report for 192.168.1.90 (192.168.1.90)
Host is up (0.0010s latency).

PORT    STATE  SERVICE VERSION
22/tcp  open   ssh     OpenSSH 7.9p1 Debian 10 (protocol 2.0)
| ssh-hostkey: 
|   2048 52:13:ac:ba:ef:86:74:8c:76:c4:47:fa:68:fd:fe:30 (RSA)
|   256 a4:ec:f3:10:8d:ec:41:e3:e7:e5:9e:0e:58:f5:ee:fb (ECDSA)
|_  256 e3:10:5e:f0:3e:b1:21:57:21:25:fd:27:d3:cc:fc:0b (ED25519)
161/tcp closed snmp
MAC Address: 00:0C:29:62:66:03 (VMware)
Aggressive OS guesses: Linux 5.1 (98%), Linux 3.10 - 4.11 (96%), Linux 3.2 - 4.9 (94%), Linux 3.16 - 4.6 (94%), Linux 5.0 - 5.4 (93%), Linux 2.6.32 - 3.13 (93%), Linux 2.6.39 (93%), Linux 4.10 (92%), Linux 2.6.22 - 2.6.36 (91%), Linux 3.10 (91%)
No exact OS matches for host (test conditions non-ideal).
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 9.32 seconds

可以看到openssh的版本为7.9 至于161端口还是显示关闭状态的！ 进行udp端口的探测：

# nmap -sU --min-rate 10000 -p- 192.168.1.90 -oN UDP.nmap 
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-17 21:21 CST
Nmap scan report for 192.168.1.90 (192.168.1.90)
Host is up (0.00044s latency).
Not shown: 65533 open|filtered udp ports (no-response)
PORT    STATE  SERVICE
22/udp  closed ssh
161/udp open   snmp
MAC Address: 00:0C:29:62:66:03 (VMware)

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

udp端口显示是开放了161端口的~

# nmap -sT --script=vuln -p22,161 192.168.1.90 -oN vuln.nmap
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-17 21:23 CST
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).
Nmap scan report for 192.168.1.90 (192.168.1.90)
Host is up (0.00053s latency).

PORT    STATE  SERVICE
22/tcp  open   ssh
161/tcp closed snmp
MAC Address: 00:0C:29:62:66:03 (VMware)

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

额~ 漏洞脚本是没什么信息的。一共就两个端口。肯定不是在22端口上直接突破，应该是在161端口上找到相关账号的信息，然后在22端口上立足！

渗透测试

至于161端口上存在什么样的漏洞，如何去测试161端口上的漏洞；只能是去Google一些资料，没有接触过161端口的漏洞；snmp默认团体名/弱口令漏洞及安全加固_snmp弱口令漏洞怎么解决-CSDN博客

找到了一篇文章里面提到了：在运行SNMP服务的设备上，如果管理员配置不当运行默认团体名/弱口令访问，将导致敏感信息泄露。其中还提到了SNMP默认弱口令是public/privicy

利用nmap进行弱口令的检测：

#找到snmp的弱口令
nmap -sU -p161 --script=snmp-brute 192.168.1.90      


Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-17 21:29 CST
Nmap scan report for 192.168.1.90 (192.168.1.90)
Host is up (0.0011s latency).

PORT    STATE SERVICE
161/udp open  snmp
| snmp-brute: 
|_  public - Valid credentials
MAC Address: 00:0C:29:62:66:03 (VMware

没问题，发现了“有效凭证！”public！ 尝试获取系统信息：

nmap -sU -p161 --script=snmp-sysdescr 192.168.1.90

发现了目标靶机的系统信息为Linux 4.19.0版本 主机名为dpwwn-03，之后又看到文章提到了两个工具，分别是snmp-check和snmpwalk：

发现了一个用户是john！这里可以先去爆破一下了，虽然不知道后面能不能拿到密码等信息！这两个工具我都用了一下，但是我不知道得到的信息有什么用处，除了拿到了一个john用户以外！

初次等到snmp的漏洞，还是显得手足无措~ （这里其实我已经拿着去爆破了~）

爆破了15分钟没结果；一直我手工直接尝试成功~

先尝试了123456，不对；然后就尝试了一下john~ 成功！

来到提权阶段！

提权

确定我们打的靶标没错！id命令查看所在的组等相关组：

先看看当前的用户是不是具有sudo特权：

哦~ 来了 ，无需密码以root身份执行 /bin/sh /home/ss.sh 那么我们如果能够更改这个文件的话，就可以写提权脚本到这个文件中；

但是这个文件我们是没法更改的~ 查看该文件中的内容：

设置了环境变量 运行了samshthestack文件~ 该文件是做什么的？

利用file strings命令查看了这个文件是否存在一些敏感的字符串信息，貌似没什么信息，网上搜索了这个文件名：

好像是堆栈溢出，之后看到了john家目录下面的flag文件，也确定了提权之路：

就是对这个二进制文件进行操作了，应该就是CTF中的pwn~ 这里我不太会，先尝试有没有其他的提权之路：

后面上传了linpeas进行提权的信息枚举，也没什么其他的发现了；

suid权限也没有什么发现，定时任务也看了

回来看这个程序：

32位的ELF可执行文件~ （这里的提权思路还是比较明确的，就是sudo 以root权限去运行ss文件的时候，运行了elf的可执行文件，呢么这个文件就是root权限，如果这个可执行文件在运行的时候，能调动其他的脚本或者程序，那么被调用的程序也同样是root权限）

这里自己就没有去做提权了，个人认为前置知识比较多，所以没有尝试。