渗透mediawiki

MediaWiki的渗透漏洞利用，往往不是渗透从代码审计开始的，而是渗透从“忘记删掉的调试接口”开始的。我去年参与过一个内部红队项目，渗透目标是渗透个运行了十年、版本停在1.31的渗透Wiki站，管理员早就忘了后台密码，渗透但网站上还挂着“本站维护中”的渗透横幅——典型的僵尸资产。

第一刀切在Special:Version页面。渗透这页面默认开启，渗透直接暴露PHP版本、渗透数据库类型、渗透已装扩展列表。渗透目标站挂着旧版ParserFunctions和SyntaxHighlight，渗透后者有个已知的渗透pygments路径穿越漏洞，CVE-2020-29007。但试了两次，都被WAF拦了。绕WAF不靠花哨技巧，靠的是改编码——把payload里的../换成%2e%2e%2f，再叠加一层Unicode规范化，%c0%ae这种老把式居然也过了。

拿到shell后才发现，真正的麻烦不是漏洞利用，而是权限维持。MediaWiki的LocalSettings.php里写死了数据库密码，但改了文件会被管理员通过git diff发现。更聪明的方式是往extensions/目录塞个假扩展，文件名起得跟官方的一样，比如ConfirmEdit，但里面挂个webshell.php。这招能躲过大多数文件完整性检查，因为运维只监控核心目录，扩展目录常常是盲区。

数据窃取比想象中简单。MediaWiki的页面历史表revision里存着所有编辑记录，包括被删除的版本。用SQL直接查old_text字段，能翻出几年前误传的内部文档。那次渗透里，我顺着一条被删除的编辑记录，找到了一个含有内网IP的附件链接——那是个没设权限的uploads目录，里面躺着整个公司的网络拓扑图。管理员以为“删掉页面”就等于“删掉数据”，但数据库里连二进制blob都留着。

最反直觉的是，MediaWiki的权限模型本身成了帮凶。它默认信任user_groups表，但很多站会把管理员组直接赋给一个共享账号。我在那个站上发现，sysop组的密码就是“admin123”，改了密码之后，管理员居然没察觉——因为平时根本没人用那个账号登录。真正的管理员用个人账号，权限反而只挂了个editor组。

收尾时留了个后门：往Math扩展的渲染缓存目录里放了个PHP文件，文件名是随机哈希，和正常缓存混在一起。这个目录通常被php.ini的open_basedir排除在外，但MediaWiki的Math扩展会自己执行缓存里的脚本，权限校验形同虚设。三个月后复查，那个后门还活着——运维只更新核心代码，从不清理缓存目录。

这次渗透教会我一件事：MediaWiki的安全边界，从来不在代码层，而在运维习惯层。旧版本、遗留扩展、被遗忘的账号、未清理的缓存——这些才是真正的入口。补丁装得再勤，也挡不住管理员在LocalSettings.php里写死wgSecretKey。