重复使用开放的 TCP/UDP 端口来处理两个同时运行的应用程序

重复使用开放的 TCP/UDP 端口来处理两个同时运行的应用程序

寻找正确方向的指针,已经看到多个漏洞代码的例子,允许在任何“正在使用”的端口上进行 shell 连接,而该端口上的原始应用程序继续正常运行。

我对从程序/系统层面如何实现这一点很感兴趣。

我绝望地在这里询问,因为我所能想到的只有 tcpmux(它使用 TCP#1 并且会破坏端口上的现有应用程序,因为每个客户端都需要在指定的应用程序响应之前发送服务名称)。

我能描述的最好方式是,如果端口敲击对监听端口的原始应用程序失败,则使用回退方案。

我的 google-foo 似乎对这个不太擅长。另外,我只在 windows 主机上见过这种情况,想进一步研究一下在 Linux 系统上是否也会出现同样的情况。

答案1

我可能误解了你在这里问的问题,但通常它的工作方式是:

  1. 存在漏洞的应用程序正在监听端口
  2. 攻击进入应用程序,应用程序使用“accept()”调用来处理它。这将返回 accept() 套接字的文件描述符。
  3. 您的攻击在应用程序内执行了一些 shellcode,它调用“dup()”,其中第一个参数是 accept() 调用返回的 fd,并复制描述符 0、1 和 2(stdin、stdout 和 stderr)。
  4. 然后你的 shellcode exec()'sa shell,它将具有与套接字关联的 stdin、stdout 和 stderr。

这真的只是:

//figure out which fd to use (we'll call this "n")
dup(n,0);
dup(n,1);
dup(n,2);
execve("/bin/sh",0,0);

现在,您的漏洞利用程序(在您的终端)有一个可以与之通信的网络 shell。在多进程/多线程应用程序中,目标应用程序应该在这种情况下继续运行 - 新连接将由 accept() 正常处理,但您在目标进程中有一个运行的 shell。一个例子是针对 apache 的漏洞利用 - 您最初连接到的子 apache 进程本质上将成为您的 shell,但父进程和其他子进程将继续正常运行。

相关内容