前言

​ 利用内存马达到命令执行/文件下载等操作已经是老生常谈的,在现在的红蓝对抗中,很多时候拿到权限,但却在内网无法伸展,这种情况已经越来越常见了。

​ 近月,内存马的技术也产生新的变化,如利用websocket进行通信,Executor内存马进行socket通信。可以看到内存马开始寻找新的载体。本文介绍利用Poller(Executor的上层类)内存马实现全流量监控,这样,攻击方可以实时监控经过系统的每一个请求,或者增加了钓鱼等信息利用的便利。先贴出项目https://github.com/Kyo-w/trojan-eye

原理

这里借用深蓝师傅的图片,Poller作为TCP连接最前置的处理类,此类能够直接处理socket上完整的原始数据。我尝试过Acceptor,但是由于Acceptor只是做监听8080端口把请求的socket连接转发给Poller来处理,所以不太可能实现自定义的Acceptor来完成内存马注入。至于实现为什么不采用Executor,我从以下几点考虑:

  1. Poller能够决定是否提交给web业务处理,Executor是要经过web业务处理,Poller能灵活地决定web业务流程
  2. Executor的流程是要经过Poller的,所以意味着性能上要比Poller多几道判断与注册
  3. Poller存在的问题,Executor也存在,所以复杂度基本差不多

但是Executor比Poller有个非常大的优势:Executor鲁棒性比Poller好。原因很简单,Poller是全局唯一的线程(tomcat8、9/springboot),如果线程处理逻辑的时候出现不可预测的异常,线程就会终止,一旦线程终止,整个tomcat的服务直接崩溃,因为缺少了接收与创建任务的执行线程。这也就是说注入Poller的内存马一定是不能出任何bug的,一旦出了,整个服务直接崩溃。在起初做试验时,经常因为木马报错,导致整个服务不能访问,只能重启服务解决,所以风险很高!反向,Executor是一个任务类,创建后就执行一个线程任务,如果这次业务异常,最多这次的请求无法正常执行罢了。那究竟怎么写一个Poller内存马呢?其实很简单:继承Poller+重写processKey方法。(可参考https://github.com/Kyo-w/trojan-eye/blob/master/theory/README.md)

@Override
protected void processKey(SelectionKey sk, NioEndpoint.NioSocketWrapper attachment) {
    //自定义:业务处理之前
    beforeHandler()

    super.processKey(sk, attachment);

    //自定义:业务处理之后
    afterHandler()
}

上面的代码中,super.processKey(sk, attachment)就是会创建SocketProcessor,然后执行web业务逻辑。所以如果你需要在web业务处理之前做些什么,你就在super.processKey(sk, attachment)之前写自己的业务。如果不想执行web业务,直接return即可。如果你需要在web业务处理之后做些什么,就在super.processKey(sk, attachment)之后添加。但是需要注意的是:super.processKey(sk,attachment)是一个“启动任务线程的函数”。在调用完super.processKey(sk,attachment)之后,程序并不会等待业务的响应结果,而是直接结束processKey函数(底层就是后台开线程执行web业务,所以是一个多线程的环境)。就是这个原因,导致我们无法完成这样一个功能:等待web业务执行结束,然后查看web业务的响应结果。因为两个线程之间如果没有通信等机制,我们无法预测线程之间的执行顺序的。这个问题让我受阻了挺长的时间,如果我们只能拿到每一个流量的请求而拿不到响应,显得有点无意义了。所以经过一番思考,我终于找到新的突破点:buffer缓存的利用。

buffer缓存+websocket实现实时流量获取

如果要实现读取业务所有的流量,我们要解决两个问题:

  1. 每次请求的request/response怎么获取
  2. 每次请求的请求/响应数据应该传输到哪里

针对第一个问题,其实很好解决。

每次请求到来,socket都会有一个bufHandler,而这个bufHandler存储的是上一个请求和响应。但是在高版本中,request的buffer并不记录数据。所以,这里只能通过深蓝师傅文章的unread函数去将本次请求的数据装载到缓存中。

ByteBuffer allocate = ByteBuffer.allocate(8192);
try {
    read = attachment.read(false, allocate);
} catch (IOException e) {}
    ByteBuffer allocate1 = ByteBuffer.allocate(read);
//        有多少数据就放多少数据
    allocate1.put(allocate.array(), 0, read);
    allocate1.position(0);
    attachment.unRead(allocate1);
    allocate.clear();

需要注意的是,unRead的数据大小不能随便设置,因为本人之前在测试中遇到了一个巨大的坑(https://github.com/Kyo-w/trojan-eye/blob/master/theory/websocktbug.md中描述了具体的原因)。现在每次请求时,请求的buffer都会携带上次请求的记录。这样我们相当于得到了所有的request/response,只是相比之下,我们永远得到的永远都是上一次的记录。最后在得到数据的时候,请求的数据如何进行传输?总需要一个标记好的连接进行传输,并且这个连接不能是客户端的短连接,原因如下:

  • 如果只是通过短连接,然后每次请求去读取buffer,显然我们获取的流量都是零散的,流量是不实时的
  • 短连接会造成大量的HTTP请求,容易出现流量异常问题
  • 由于发送大量的HTTP请求,我们可能获取的是自己的请求流量

​ 在https://github.com/Kyo-w/trojan-eye/blob/master/theory/buffersocket.md中详细的介绍了利用Keep-Alive持久一个毒化socket,然后进行数据传输。但是这个存在一个问题,遇到NGINX反向代理时,默认的NGINX并不支持一个请求的长连接,NGINX默认是端口轮询访问的,阻碍了socket毒化的过程。但是如果设置了对应的配置,那也是可以保证这种技术的可行性。

upstream  BACKEND {
        server   127.0.0.1:8080  weight=1 max_fails=2 fail_timeout=30s;
        keepalive 3000;
    }   
    map $http_upgrade $connection_upgrade{
        default upgrade;
        ''       close;
    }

既然我们控制的是socket,理论我们是可以构造传输层上的各种协议,但是还是不得不面对现实的情况:我们的业务依旧面对的是NGINX之类的反向代理,而NGINX默认支持的协议并不支持各种高层的应用层协议,换句话说,我们只能尽可能用业务中NGINX代理最常见的协议进行通信,但是原生的HTTP已经无法做到我们的需求了。Keep-Alive虽然可以,但是也会面对几个问题:

  1. 连接超时。这就需要客户端实时发送心跳以维持socket的通信。
  2. 我们需要响应适合的响应体,由于控制整个连接过程,所以导致响应体都是由我们自己封装返回客户端,而自己封装的响应,很容易导致出现统一的特征(涉及到响应的模板)。

当然在NGINX 1.9.0版本以后,已经支持对TCP协议代理的支持

stream{
    upstream test{
     #这里代理socket其端口是3307
    server 127.0.0.1:3307 weight=1;
      #server x.x.x.x:1111 weight=1;
    }
    server {
           #监听3306端口
           listen 3306;
           proxy_pass test;
     }
}

但是既然是做工具的,那必然要尽可能降低环境的需求。所以必须寻找其他更常见的协议。幸好在前段时间已经有师傅找到了新的内存马——websocket。看到websocket,让我顿时有了灵感,websocket本身就是会常见于一些web应用,这势必然增加了工具的适用范围,并且websocket在HTTP代理的日志中只能看到一条记录(由于websocket在做完一次协议升级后,就不再使用HTTP进行传输了)。所以立刻展开深入的研究,以下是整个内存马通信的核心。

下面是NGINX配置websocket的配置(供学习参考)

server {
      listen   80;
      #域名
      server_name localhost;
      location /sell {
        proxy_pass   http://127.0.0.1:8080/; // 代理转发地址
        proxy_http_version 1.1;
        proxy_read_timeout   3600s; // 超时设置
        // 启用支持websocket连接
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
      }
}

从图像中可以看到,每次代理的流量都会经过Poller,Poller会根据存在的websocket通信列表,把上一次请求的所有数据,发送给每一个websocket监听器。现在,整个基本骨架已经基本实现了,剩下的就只剩敲代码了。最后希望这些研究能在攻防起到作用吧!

点击收藏 | 2 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖