php-cgi参数注入攻击经历浅谈

起因：
阿里云服务器再次警告出现挖矿程序。上一次服务器被攻击后，怕有恶意程序残留，第一时间重装了系统，也没有详查攻击入口。不外事后还是做了一些防范，这台留作公网访问的服务器上并未保存业务数据，只作为中转使用。因而这次也就没什么担心的，准备具体研究一下攻击入口在哪里。

过程：
1. 查看检测出的挖矿程序php_cci.exe。几乎是第一眼就看到下边这个cn.php文件。exe文件干了啥我不清晰，但是php是脚本文件，可以放心大胆地打开看看。
    

脚本内容就不贴出来了，以下是deepseek对脚本的部门分析：
    

2. 推测攻击方式。根据两个文件的修改时间，我大概判定php_cci.exe是通过cn.php下载至当地的。那么cn.php是怎样来的呢？这台服务器只对公网开放了长途连接及web端口，前次被攻击时阿里云有短信提示长途连接在异地登录，这次没有，而且可疑文件是php脚本，所以几乎可以断定就是web毛病了。
3. 锁定攻击入口。确定是web毛病后，便直接查看apache目录下的access.log，查抄可疑哀求，重点是cn.php文件创建时间左右的POST哀求。果不其然，有一条对php-cgi.exe的访问哀求，一看就不是什么端庄哀求。

完整哀求如下：

1. POST /php-cgi/php-cgi.exe?%ADd+cgi.force_redirect%3D0+%ADd+disable_functions%3D%22%22+%ADd+allow_url_include%3D1+%ADd+auto_prepend_file%3Dphp://input HTTP/1.1" 500 638 "-" "python-requests/2.27.1

复制代码

这是一条典范的php-cgi参数注入攻击。虽然服务器返回了500，但仍然可能被感染了。
4. 当地构造哀求复现攻击。我用python构造哀求，POST内容为将当前时间写入桌面上一个文件中：

1. <?php
3. file_put_contents("C:/Users/Administrator/Desktop/error.txt", date('Y-m-d H:i:s'));
5. ?>

复制代码

当然，中间是经历了一些波折的，但最终确实攻击成功了。
5. 修改设置防范此类攻击。查询了资料也问了AI，实验了几种方案效果不是很好。最终还是简单粗暴地对php-cgi.exe的访问举行了限制，既能防范攻击也不影响正常业务哀求：

结论：
我们每每只关注本身了解的范畴或者知识，将工作重心放在业务层面。然而，“后勤保障团队”虽不光鲜亮丽，仍然不可忽略，就像有些程序员不屑于写注释和文档，迟早有一天会为本身的高傲买单，这时的耗费可能远超组建“后勤保障团队”。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。