如何搭建TCP代理的项目还是源于我的一次有趣的尝试,有天下午,我打算攻击流行约会应用程序的用户定位功能。我想看看它们是否容易受到攻击,这些攻击可以逆转受害者用户的位置。我的计划是欺骗每个目标应用程序的数千个请求,假装每个请求都是从不同的位置发送的,并且每次询问应用程序我的目标与我当前的虚假位置有多远。接下来,我会结合使用数学和独创性得出的结果来尝试找出确切的位置。
项目一开始开始进展顺利,通过使用Burp Suite(一种流行的HTTP代理),我可以检查、编辑和重播手机与各种约会应用程序的远程服务器之间发送的所有HTTP通信。但是,当我开始探索一个非常成功的应用程序时,我立即遇到了麻烦。我发现它的通信没有出现在Burp或我的其他任何其他基于HTTP的标准工具中。我花了很长时间检查并再次检查我的设置和配置。最后我发现,他们根本不用HTTP。他们使用了其他一些神秘的但仍基于TCP的协议,而我的常规工具(如Burp)无法使用。
出于好奇,我花了一些时间来构建一个通用的TCP代理,它可以处理任何基于TCP的协议,而不仅仅是HTTP。一旦完成,我的代理允许我检查不合作的应用程序与服务器的通信。这意味着,我可以继续伪造个人资料,并获得一些希望的结果。
在接下来的文章中,我将向你展示如何构建自己的TCP代理。在本文结束时,你将能够使用代理来拦截、记录、编辑和重播智能手机的所有TCP流量,而不仅仅是HTTP。在本文中,你将学到很多基础互联网的关键技术,包括DNS,TLS和TCP。
什么是代理?
所谓代理,就是代表客户将消息发送到服务器的中介。
代理广泛用于隐私浏览、内容过滤、绕过审查、缓存和安全渗透测试。
本文,我们将构建一种称为“中间人”(MITM)的特殊类型的代理。安全渗透测试人员通常使用MITM代理来读取、记录和修改客户端(如智能手机)与远程服务器(如约会应用程序)交换的数据。
假设你想使用MITM代理(在你自己的笔记本电脑上运行)来检查与你喜欢的约会应用程序之间的通信流量。你将指示智能手机将其流量发送到MITM代理,而不是直接将其发送到约会应用程序的服务器。此时,你的智能手机将不再询问约会应用程序的服务器“Alex距离多远?”。相反,它会让你的MITM代理询问约会应用程序Alex离你有多远。
你的MITM代理将发出此请求,并将收到的任何响应发送回你的智能手机。它还会将请求和响应的内容记录到文件中,使你可以查看其中包含的内容。这就是使代理成为中间人的原因。你可以使用这些日志中的信息来修改智能手机发出时的请求,甚至可以从一开始就伪造你自己的请求。
代理设计
在本文中,我们的代理将包括3个组件,每个组件负责解决一个不同的问题:
1. 一个假冒的DNS服务器,诱骗你的智能手机,将其TCP流量发送到伪造的代理;
2. 代理服务器,用于管理智能手机和远程服务器之间的数据流;
3. 伪造的证书颁发机构,用于处理智能手机和我们的代理之间的TLS加密。
本项目计划分为4部分,第一部分会概述代理设计,并介绍了我们将使用的协议和技术。最后三部分分别描述了如何构建上述组件,并为所涉及的技术做一些额外的说明。
构建伪造的DNS服务器
我们将首先构建一个伪造的DNS服务器,并使用伪造的DNS服务器诱骗你的智能手机将其流量发送到伪造的代理。
用户会考虑使用主机名(例如robertheaton.com)将数据发送到网络上。但是,互联网使用IP地址(例如104.18.33.191)将数据路由到其目的地。这两个地址系统是完全不同的,IP地址对人类来说很不方便(“访问我的网站104.18.33.191”不是很方便),但主机名对互联网主干来说绝对没有任何意义。
诸如智能手机之类的设备使用域名系统(DNS)协议在主机名和IP地址之间进行转换,大约有20台免费的和公共的DNS服务器,每台服务器(大致而言)都保留一个数据库,其中包含从主机名到IP地址的所有映射。 Google有一个IP地址为8.8.8.8的DNS服务器,Verisign有一个是64.6.64.6。
假设你浏览到网站robertheaton.com,在你的设备向我的服务器发送请求之前,它需要将此主机名转换为互联网主干可以理解的IP地址。它向DNS服务器发出DNS A记录请求(以下简称为“DNS请求”),要求其将robertheaton.com转换为IP地址。一旦DNS服务器以104.18.33.191响应,你的浏览器就会向互联网发送一个HTTP请求,地址是这个IP地址。
你可以通过在智能手机的系统设置中输入服务器的IP地址,来选择智能手机用于进行这些DNS转换的DNS服务器。所有主要的DNS服务器都应给出相同的正确答案,因此通常这种选择实际上并没有多大意义。
什么是虚假DNS服务器?
DNS服务器没有什么特别的,它只是一台监听并响应UDP端口53上的DNS请求的服务器。实际上,我们可以在笔记本电脑上运行我们自己的DNS服务器,并且可以将你的智能手机配置为使用此虚假DNS服务器,而不是Google或Verizon的DNS服务器。
这样,我们就可以对虚假DNS服务器进行编程,以发送回我们喜欢的任何DNS响应。我们甚至可以让它返回的消息全部都是虚假的。假设我们的DNS服务器收到了一个主机名的DNS请求,我们希望通过我们的代理(例如api.targetapp.com)路由该主机名的请求。我们将对服务器进行编程,使其不响应api.targetapp.com的真实IP地址,而是响应你笔记本电脑的本地IP地址。
你的智能手机不会知道我们响应了虚假信息,也不会看到这些回复有任何问题。它将接受api.targetapp.com解析为笔记本电脑的本地IP地址,并将它希望发送到api.targetapp.com的任何数据发送到你的笔记本电脑。
要利用此行为并接收重新路由的数据,我们将需要在笔记本电脑上设置第二台服务器。这将是实际的代理服务器,它将负责从你的手机接收数据,阅读并打印数据,以便我们进行检查;最后将其转发给预定的收件人。
为什么我们不能只进行Burp操作?
实际上,像Burp这样的HTTP/S代理不需要做任何DNS欺骗来让你的智能手机向他们发送数据,但为什么我们还要进行TCP代理?
因为,像Burp这样的HTTP/S代理使我们广泛使用了HTTP协议的一些高级功能,这些功能的存在只是为了帮助代理,其中包括连接请求和HTTP 主机标头,稍后我会详细介绍。
现在所有的智能手机都利用了这些功能,因此可以很好地与HTTP/S代理一起工作。你的智能手机有一个系统设置,允许你指定一个代理,它应该使用所有的HTTP请求。为了使用像Burp这样的HTTP MITM代理,你首先要将笔记本电脑和智能手机连接到同一网络,然后告诉你的智能手机将笔记本电脑的本地IP地址用作HTTP代理。你在笔记本电脑上打开Burp代理,智能手机就会乖乖地把所有的HTTP/S流量转发到笔记本电脑上。此时,Burp立即启动并运行。
但是,由于我们希望代理能够处理所有基于TCP的协议,而不仅仅是HTTP,因此我们无法利用任何特定于HTTP的功能,这就是为什么我们不得不求助于我们的DNS hijinks的原因。你遇到的其他基于TCP的协议可能具有其等效的代理友好功能,但同样也可能没有。此时你将无法知道正在检查的特定协议是否具有任何此类功能,直到你能够使用代理检查其请求,并且在检查了其请求之前,你将不知道如何代理其请求。
现在,我们知道了如何诱骗智能手机将TCP数据发送到笔记本电脑,现在,让我们看看如何使用它来做些事情。
代理服务器
现在要讲的是代理服务器本身,本文要讲的是一台在笔记本电脑上运行的服务器。它会接受来自你的智能手机的流量(但前提是在我们伪造的DNS服务器的帮助下),将其转发到目标应用的远程服务器,并将它得到的任何响应发送回你的智能手机。
本文,我们将要解决的主要问题是确保我们的代理知道将智能手机流量转发到哪个远程服务器。像所有计算机程序一样,代理程序并不是很聪明。它们不知道如何处理收到的数据,而唯一知道这些数据的方法是明确地告诉他们。
比如,当你想和朋友共进晚餐时,你会给他们的手机号码发短信,说“今晚想去吃晚餐吗?”
现在,假设你有一位私人助理,你将雇用该助理来转发所有文本。过程如下:首先你将所有文本发送给该助理,然后它们代表你转发给你的朋友。如果你仅向该助理发送短信,说“今天晚上想吃晚饭吗?”他们是不知道将其转发给谁。有很多方法可以解决以上出现的代理问题。比如,你可以在消息后面附加一个标题“Send-To: 415-123-1234”,或者你可以提前制定一个规则,将所有晚餐建议始终发送给你的母亲。
同样,HTTP/S代理可以使用HTTP协议的特殊、特定于代理的特性轻松地解决这个路由挑战。不过,我们不能使用它们,因为我们希望我们的TCP代理完全与应用程序协议无关。
因此,我们要稍微作弊一下。我们将把一个主机名硬编码到我们的代理中,并告诉我们的代理将它接收到的所有数据转发给这个主机。这就好比告诉你的私人助理,把你今天发送的所有消息信都转发给你的一个好友或信任的人。
以上只是我的一个简单比喻,通常,你将使用代理检查每个应用发送的数据。此应用可能会将其所有有趣的数据发送到一个主机名,例如api.targetapp.com。
我们可以查看前一节中的虚假DNS服务器的日志,并查看你的智能手机尝试联系的主机列表。我们可以使用直觉和猜测来找出最有趣的主机名。例如,api.targetapp.com可能比stats.mobileanalytics.com更有趣。然后,我们可以将该主机名硬编码到我们的代理中,并指示我们的代理将它从你的智能手机接收到的所有数据发送到这个主机。
请注意,我们将需要配置伪造的DNS服务器,使其仅发送与代理程序将所有数据发送到的主机名相同的代理流量。对于所有其他主机名,我们的虚假DNS服务器应向真实DNS服务器发出真实DNS请求,并将此真实响应转发到你的智能手机。这将导致你的智能手机绕过我们的代理,将这些主机名的所有流量直接发送到正确的位置。如果我们不这样做,我们的代理最终可能会将敏感数据转发到错误的服务器。
本文翻译自:https://robertheaton.com/2018/08/31/how-to-build-a-tcp-proxy-1/如若转载,请注明原文地址: