kioptrix-4

简介

https://www.vulnhub.com/entry/kioptrix-level-13-4,25/
总结

  1. 此靶机存在防火墙,过滤特定端口流量。但此处我通过 python -m http.server 9999 进行传输,所以不影响

    image-20210416105344017

  2. 有些功能点可以进行多次尝试,尝试使其报错,获取出错信息。例如下文中的文件包含。

  3. php session 信息默认保存方式为 文件形式。详细信息请参考官方文档。而 python django 中 session 默认是保存到数据库中的。而 tomcat session 默认在内存中。

  4. 搜索到的内核 exp 太多,如何处理?

    不断缩小范围,排查。

  5. 即使拥有 suid 权限,但是不一定以 root 用户身份运行,可能只在必要时才会以 root 用户运行。

    有维持权限的 c 代码。此外 gtfobins 上关于 suid,指出了维持权限的方法。

信息收集

image-20210415145757743

服务漏洞验证

openssh

除用户名枚举外,无漏洞。

apache

没有值得利用得漏洞。

samba

用 nmap 的 smb-enum-users 脚本扫描一下 smb 用户

image-20210415150143017

尝试 smbclient 看有无共享文件夹。

若弹出协议错误,可以尝试这个解决方案

image-20210415150917861

发现支持匿名登录。但无共享的文件夹。

web 渗透

登录到网页,看到下面这个页面,在进行功能发掘之前,先跑下目录,看有无敏感文件。

image-20210403152357020

跑出来后台有一个 .sql 文件,其中有敏感信息

INSERT INTO `members` VALUES (1, 'john', '1234');

尝试用这个密码登录网页,结果还是提醒错误。用 ssh 登录也失败了。

sql 注入

尝试 sql 注入。sql 注入这块的话,先手工尝试几个,发现有时会报错。基本就存在注入,直接上工具。

image-20210403154047807

检测出来 mypassword 存在注入点。

看一下当前数据库用户,并且看是否为管理员。结果是mysql root 用户。

image-20210403154308623

收集一下数据库中有趣的信息。

mysql.user
+-----------+------------------+-------------------------------------------+
| Host      | User             | Password                                  |
+-----------+------------------+-------------------------------------------+
| 127.0.0.1 | root             | <blank>                                   |
| Kioptrix4 | <blank>          | <blank>                                   |
| Kioptrix4 | root             | <blank>                                   |
| localhost | <blank>          | <blank>                                   |
| localhost | debian-sys-maint | *3AC38ADE5482EA4DE628D0D43BF8F            |
| localhost | root             | *3AC38ADE5482EA4DE628D0D43BF8FA41E3CF3879 |
+-----------+------------------+-------------------------------------------+

上面的密码尝试解密,失败了。

image-20210403155535786

此处的两个账户都 ssh 登录成功。网页端也登录成功,但无功能。

image-20210403155658837

image-20210403160105546

两者的 shell 都是受限的。

image-20210413172044549

文件包含

后期看 writeup 才发现这点。当输入不存在的用户名时,会提醒 获取用户页面失败。可以根据这个提示,尝试文件包含。

image-20210416130633704

image-20210416102248987

可以看到其处理逻辑为 include(/var/www/username/username.php);

因为此处 php <= 5.3.4,存在 00 截断,可以利用这个特性去掉末尾添加的 php。

image-20210416102455787

可能被 replace 为 空,尝试 双写绕过。

image-20210416102820646

此处可以利用 linux /proc 目录,来获取更多信息。https://man7.org/linux/man-pages/man5/proc.5.html

image-20210416115055791

php 中 session 默认保存为文件,而 session 中存放的值是是存放于文件中。在这里注意到 session_register 函数,将对象以序列化方式保存到文件中。所以可以尝试,通过 /proc/self/fd/ 遍历获取到 session 中存放的内容。

image-20210417150250933

结合包含漏洞,可以获取 webshell 。下图是成功执行 phpinfo();

image-20210417151223949

提权

受限 shell 逃逸

通过 ssh 连接到靶机,发现是受限 shell 。

此处逃逸有多种方法,某些可行,某些不可行,下面是一个可行的例子。更多逃逸的方法见这篇文章

echo os.system('/bin/bash')

此外,由于这个 shell 是 lshell ,可以在 github 上搜到这个项目。尝试 searchsploit ,也可突破受限 shell 。

image-20210413173235243

修改源文件错误,导入 sys 包,设定目标后获取到正常 shell。

内核漏洞
searchsploit linux kernel 2.6.24 --exclude='dos'
searchsploit linux kernel 2.6 --exclude='dos'

可以通过 9641 来提权。

mysql udf 提权

image-20210415160905656

image-20210415151820822

通常 mysqld_safe 以 root 用户运行,而 mysqld 是以 mysql 用户运行。而此处 mysqld 也是以 root 运行。

我们之前已经得到 数据库 root 用户权限。故可以尝试 udf 提权。关于 udf 提权,这块有详尽的资料,exploit-db-44139

由于这块已经存在 udf 库,我们不需要再导入,直接利用就行。

登录到 mysql 中,看到 mysql.func 表中存在函数。

image-20210415170951155

通过 sqlmap 执行。

python3 sqlmap.py -r zzz --technique=B --sql-query="select sys_exec('echo xxxx > /home/john/weew')"

之后可以观察到出现特定文件,并且该文件所有者为 root 用户,说明命令是通过 root 用户执行的。

错误思想:

此处不能直接 通过 mysql -uroot 连接,然后执行 udf 函数。因为这样会创建新的一个低权限 mysql 进程。此时 通过 udf 无意义。

分析原因:

实际上通过 mysql -uroot 运行的只是 mysql 客户端,而实际执行操作的是 mysql 服务端。此时服务端以 root 用户运行。并且对这个 udf 动态库有读取的权限。所以执行的 sys_exec 就是以 root 身份执行。

image-20210417170015383

其它可能有用的信息

image-20210415151843840

第一次看到这几个 apache 服务,以为和 mysql 一样,是误以 root 运行,实际上这是正常情况。详见 这篇讨论

image-20210415161228626

image-20210415161540668

原文地址:https://www.cnblogs.com/starrys/p/14671225.html