长时间未存活的client无法执行命令

riijj commented 2 years ago

由于使用了CloudFlare的CDN，CF默认启用了缓存，由于缓存的作用，就导致client可以正常的请求并有回包，但是teamserver这边就一直收不到client发送的心跳包，这样teamserver端该client的last时间就会相当的长如图: 在输入命令后，不会发送该命令：正常应该是这样：

windows上线的client使用同样的CF则不存在这样的问题使用IP直接上线也不存在这样的问题。

gloxec commented 2 years ago

建议CF控制台中配置页面规则为缓存级别：绕过
以及最重要的是编写rebind.c在自定义HTTP 请求体时，注意header配置
```
GET / POST ..... HTTP/1.1
...
Cache-Control: no-cache
Connection: close
...
```

riijj commented 2 years ago

师傅你可能没有理解我的意思，其实我的意思是，CrossC2是否发送payload,也就是控制台出现"host called host, sent 12 bytes",这个似乎和当前client的last正相关，如果当前client的last值很大，那么就永远不会向teamserver发送payload，不晓得是否算是一个bug

gloxec commented 2 years ago

teamserver & client(GUI客户端) & beacon(你issue描述的client) 三者的关系是这样的:

当teamserver收到beacon心跳时，teamserver会记录last值，并同步到client client提交的任务，首先同步到teamserver，teamserver被beacon连接后，teamserver通知client消息"host called host, sent 12 bytes"

现在因为teamserver与beacon中间多了一层CF CDN

beacon第一次发送心跳到CF，第一次请求CF将内容转发到teamserver
teamserver返回数据包到CF，CF继续返回到beacon (第一次会话上线)
beacon第二次发送心跳到CF，CF直接将缓存中的（2请求）结果返回beacon，后续所有流程同3

因为这里第3步，CF并未将数据发送到teamserver，所以这里client从teamserver收到的数据也是会话已长时间离线(last值)，以及client下发的任务因为CF的原因实际并未被接收。

主要问题出在CF的缓存屏蔽了向teamserver转发数据，所以解决方案就是在编写rebind库时，更改HTTP请求内容，避免CF认为是静态资源而被忽略teamserver

riijj commented 2 years ago

哦哦，懂了，感谢师傅的详细讲解。非常感谢

gloxec / CrossC2

长时间未存活的client无法执行命令 #154