如何搭建TCP代理（一）

Burp如何路由请求？

我提到过，Burp和其他HTTP/S代理使用HTTP协议的特殊功能来路由请求。为了让我们知道我们遗漏了什么，让我们看一下这些特殊功能，以及它们如何帮助代理同时路由HTTP和HTTPS流量。

HTTP代理

未加密的HTTP代理很容易做到，HTTP/1.x 请求包含一个主机标头，该标头明确指定了请求应发送到的主机名。 HTTP/2.x 请求包含一个包含相同信息的授权伪标头。 HTTP代理可以轻松地从未加密的请求中解析出该值，然后相应地重新发送该请求。这类似于在发送给助手的短信中包含“发送至”字段。

HTTPS

HTTPS代理更难，目前HTTPS代理有两种主要类型：转发代理和中间人代理。 “转发代理”非常无聊，它代理HTTPS数据，而无需解密。但是，它无法重用HTTP代理所采用的方法，因为它只会将通过它的数据视为不可读的、TLS加密的废话。这意味着它无法读取HTTP 主机标头，因此无法使用它来重定向通过它的数据。因此，它需要一个替代解决方案。如果你的私人助理不能解密你的朋友的名字，那么即便把你的朋友的名字发给你的私人助理是没有用的。

HTTPS协议通过向代理发送额外的特定于代理的连接请求来解决此问题，如果客户端知道其HTTPS请求将通过代理传递，则它在每个客户端之前都有一个单独的HTTP 连接请求。该请求以未加密的明文形式明确地告诉代理服务器，它应该向其发送稍后将发送的加密请求的主机名。这意味着代理无需解密主有效载荷即可正确路由。这就像给你的私人助理发送一条事先没有加密的文本信息，内容都是一些教助理应该如何处理即将发送的加密信息的废话。

第二种类型的HTTPS代理，也是我们本文讲解的要构建的类型，是“中间人”(MITM) 类型。正如我们已经讨论过的，MITM不同于转发代理，因为它能够解密和读取通过它的数据。这意味着它可以读取HTTP请求的明文内容，因此也可以读取存储在其HTTP主机标头中的目标。HTTPS MITM可以将请求转发到此位置，其方式与HTTP代理完全相同。

MITM通常仍然倾向于模拟转发代理，并在可能的地方使用连接请求。他们唯一使用主机标头的时间是在“不支持代理”的客户端不知道或不在乎他们是否连接到代理，并且不发送初步的连接请求时。在这种情况下，主机标头是一个有用的后备。

现在，我们知道了如何说服你的智能手机将其数据发送给伪造的代理，以及如何确保伪造的代理安全地接收这些数据。接下来要做的就是如何处理你的智能手机和虚假的代理之间的TLS加密。

伪造证书颁发机构

希望你尝试检查的基于TCP的协议使用TLS加密，在2018年，互联网仍然是一个非常危险的地方，没有任何理由不对所有内容进行绝对加密。

TLS（有时称为SSL）是HTTPS用来保护你的网上银行详细信息安全的一种加密形式。但是，TLS可以用于任何基于TCP的协议，而不仅仅是HTTPS。这是因为TLS不在乎它加密的数据形式。它可以是HTTP、FTP、XML或完全是非结构化的，这意味着我们的TCP代理可以重用HTTPS代理通常记录和使用的所有相同TLS技术。

我们需要解决的主要TLS问题是，说服你的智能手机信任我们的代理。完成此操作后，解密智能手机发送的数据的任务将非常简单，因为我们可以将其委派给已知的，经过良好测试的库。

TLS证书和证书颁发机构

常情况下，你的智能手机对外界持怀疑和不信任的态度，知道声称代表api.targetapp.com的服务器真正属于谁，这意味着什么？如果智能手机将数据发送给错误的人，那么你就没有必要仔细地保护和加密你的数据。

TLS加密可缓解智能手机的偏执狂，同时使我们的工作更加困难。 TLS不仅在发送数据之前对其进行了加密，它还会验证它是否将加密的数据发送到正确的位置。

TLS连接通过称为TLS握手的过程进行同意和验证，在TLS握手期间，客户端和服务器将彼此介绍自己。客户端验证服务器的身份（有时反之亦然），并且双方同意使用加密密钥来保护其流量。这意味着，他们通过TCP连接交换所有这些信息。

你的智能手机将不会完成与我们的代理的TLS握手，除非我们能够通过出示有效的TLS证书来证明我们的代理的身份。为此，我们需要将这个TLS证书的公共名称(证书中的一个字段)设置为你的智能手机认为正在与之通信的主机名，这将很容易。另外，我们还需要使用智能手机信任的根证书颁发机构（CA）对TLS证书进行签名，这个过程将是困难的。

主机名（如google.com）的真实TLS证书（由Digicert等真实的CA签署）将是世界历史上最有价值的几千个字节之一，因为它会允许恶意攻击者解密由任何人都可以访问google.com。如果你拥有此类证书，请立即停止阅读。

由于我们没有任何真实的，由CA签名的TLS证书，因此我们将制作自己的虚假CA，我们将之称为“罗伯特的信任证书颁发机构（Robert 's trusted Certificate Authority）”。我们将为我们的CA生成一个签名证书，并将此证书作为根CA安装在你的智能手机上。这将使你的智能手机信任我们的CA，更重要的是，信任我们的CA签署的所有其他证书。每当你的智能手机要求我们的代理执行TLS握手时，我们都会检查你的智能手机认为与之对话的主机名。我们将快速为该主机名生成一个证书（例如api.targapp.com），并用我们的伪造CA对其进行签名，最后将其返回给你的智能手机。此时你的智能手机将看到api.targapp.com的此证书已由“罗伯特的信任证书颁发机构”签名，看到此信誉良好的组织位于其受信任的CA列表中，并很高兴与我们的代理完成TLS握手。

随着你的智能手机和我们的代理之间的TLS连接成功构建，我们的系统的其余部分将完全按照计划工作。此时，TCP代理就已经完成。

TCP代理的详细过程

该过程分为3个步骤：

1. 伪造的DNS服务器，在笔记本电脑上运行的DNS服务器，欺骗你的智能手机将其TCP流量发送到笔记本电脑

2. 代理服务器，在笔记本电脑上运行的服务器，可以处理智能手机和远程服务器之间的流量；

3. 伪造的证书颁发机构，一种生成智能手机将信任的TLS证书的工具。

完成以上3个步骤后，你将拥有一个可以正常工作的TCP代理，可用于检查和分析任何基于TCP的协议。我已经使用Python3为每个部分编写了示例代码。虽然这也意味着你最好使用Python3，但是用另一种语言实现TCP代理也是完全可行的。

伪造DNS服务器

伪造DNS服务器的代理将能够处理任何基于TCP的协议，而不仅仅是HTTP。

接下来，我们将构建一个在笔记本电脑上运行的虚假DNS服务器。我们将配置你的智能手机，使其在需要使用DNS将主机名解析为IP地址时使用该服务器。当你的智能手机向我们的服务器询问目标应用程序的主机名的IP地址（例如api.targetapp.com）时，我们的服务器将处于说谎状态。它会返回你笔记本电脑的本地IP地址，而不是返回目标应用程序的真实IP地址。

此时，你的智能手机将信任我们服务器的响应，并误认为你的笔记本电脑的本地IP实际上是api.targetapp.com的正确IP地址。现在，只要你的智能手机希望向api.targetapp.com发送一些数据，它就会将其发送到你的笔记本电脑，而不是真正的TargetApp服务器。这将完成你的智能手机数据必须通过我们的代理系统进行的第一跳。在接下来，我们将构建一个代理服务器，以监听并利用此重新路由的数据。

深入了解DNS

在开始使用我们的虚拟DNS服务器之前，我们将使用一些现有的工具来详细研究一些真实的DNS请求。我们还将手工制作和欺骗一些DNS响应，证明你的手机确实会信任并响应包含笔记本电脑发送的虚假的DNS响应。尽管我们的代理经过明确设计，能够处理非HTTP TCP流量，但我们将首先使用HTTP请求对其进行测试，不过，这纯粹是为了简单起见。通常，让智能手机发出HTTP请求要比其他任何类型的TCP请求都容易，因为触发一个网站所需要做的就是访问网站。不过我们的代理不是“non-HTTP”，而是“non-HTTP-specific”。

如果你尚未下载，请下载Wireshark和netcat（nmap的一部分）。Wireshark（前称Ethereal）是一个网络封包分析软件。网络封包分析软件的功能是撷取网络封包，并尽可能显示出最为详细的网络封包资料。Netcat被称为网络安全界的瑞士军刀，netcat可以用于监控/扫描网络端口，它应用最多的情况是后门程序。

将智能手机的DNS请求发送到笔记本电脑

首先，让你的智能手机将DNS请求发送到你的笔记本电脑，而不是将当前配置为使用的任何真实DNS服务器（例如Verisign，Google或OpenDNS）发送给你。

首先，请确保你的笔记本电脑和智能手机连接到同一无线网络。

接下来，通过运行一个类似 ifconfig | grep 'en0' -A 2 | grep netmask的终端命令来查找你的笔记本电脑的本地IP地址，如果你使用的是Windows系统，请尝试ipconfig。该命令应将笔记本电脑的本地IP地址打印到终端上，这可能看起来像192.168.x.y。

现在找到你的智能手机的DNS设置页面，此时你可以更改你的智能手机向其发送DNS请求的DNS服务器。将DNS服务器IP地址更新为你刚刚发现的笔记本电脑的本地IP地址，尝试访问一些网站并使用一些应用程序，但最终你会发现这些网站和程序都无法工作。

此时，你的智能手机已停止运行，因为它已开始将其所有DNS请求发送到你的笔记本电脑。由于你的笔记本电脑不知道如何处理这些请求，所以它会将它们丢弃而不产生响应。这意味着你的智能手机无法将主机名解析为IP地址。尽管它在技术上仍可以连接到互联网，但我们已经打破了它的一个主要机制来解决如何使用它。互联网上的路由是使用IP地址而不是主机名完成的。互联网主干网不知道怎么去targetapp.com，就像你的出租车司机不知道怎么去你的约会对象的家一样。

探测DNS请求

使用Wireshark探测DNS请求

我们已经成功断开了你的手机与网络的连接，我觉得这是个好消息，因为它表明你的手机已开始向笔记本电脑发送DNS请求。现在，让我们使用数据包嗅探器Wireshark来检查你的笔记本电脑的网络流量，并查找你的手机命中注定的DNS请求，看看我的判断是否正确。我们可以确认它们确实被发送到你的笔记本电脑，并且你的笔记本电脑目前没有向你的手机发送任何DNS响应。

在诱骗你的智能手机之前，让我们先进行一次基本检查以确保Wireshark正常运行。首先，在笔记本电脑上打开Wireshark，并使用udp端口53来运行它。DNS请求通过端口53上的UDP协议发送，这将屏蔽掉我们不感兴趣的网络流量。现在，在笔记本电脑上，可以访问任何网站。你应该在Wireshark中看到该网站的主机名的DNS请求和响应，这是你的笔记本电脑向真正的DNS服务器发出自己的DNS请求，以便它可以将浏览器（例如robertheaton.com）的HTTP请求从你的浏览器发送到正确的IP地址。

DNS请求

DNS响应

如果这不起作用，那么也可以尝试其他一些网站。你的笔记本电脑可能最近向robertheaton.com发出了DNS请求，并且可能已缓存收到的响应。

现在，让我们查看手机中的一些DNS请求。首先，让我们调整Wireshark过滤器。 udp端口53过滤器同时显示发送到笔记本电脑和由笔记本电脑发送的DNS请求。。通过处理，我们只显示通过你的手机发送到你的笔记本电脑的请求。将Wireshark过滤器更新为udp端口53 && dst $ YOUR_LAPTOPS_IP。在你的智能手机（其DNS服务器仍设置在笔记本电脑上）上，访问另一个网站。不过，由于DNS缓存，你可能不得不多尝试几次。你应该在Wireshark中看到针对此网站主机名的DNS请求，并将其UDP数据包的“目标IP”字段设置为你的笔记本电脑。如果你这样做，则可以确认你的手机正在与笔记本电脑通话，这是一个巨大的诱骗方法的突破！

但是，Wireshark不会显示相应的DNS响应。这是因为我们尚未告知你的笔记本电脑，当它在端口53上收到UDP数据包时，会发生什么？

在开始对笔记本电脑进行设置之前，让我们使用Netcat从另一个角度来看一下DNS流量。

本文如翻译自：https://robertheaton.com/2018/08/31/how-to-build-a-tcp-proxy-2/ https://robertheaton.com/2018/08/31/how-to-build-a-tcp-proxy-3/若转载，请注明原文地址：