传真机漏洞攻击深入解析

  • A+
所属分类:网络安全文章

传真机漏洞攻击深入解析

介绍

传真机虽然让人联想到过去的不久,但仍然存在于许多办公空间中,并且经常用于商业和法律通信。它的大多数技术是在几十年前开发的,并且很可能多年来基本保持不变。

传统盒子,可通过电话线拨打电话,并经常通过以太网连接到本地网络。这听起来像夏季时间研究的好计划!

说实话,我们不知道传真通信是如何运作的。一堆描述标准的文件并没有让事情变得更容易,我们还没有准备好进入硬件逆转。幸运的是,许多免费软件项目实现了传真机通常所做的事情以及一系列附加功能,并且可以完全访问源代码。

有了我们的代码审核帽子,少量的模糊器和足够的咖啡(以防万一意外骚乱中断了我们的咖啡因供应),我们已准备好进行夏季研究。我们去吧!

儿童软件传真

传真!它们看起来像带有电话线的怪异打印机,发出有趣的噪音,可以通过电话线以低速传输页面扫描,还有什么人需要?

虽然传真机仍然可以在世界各地的任何随机办公空间中被发现,但软件传真可能是他们不受欢迎的朋友。围绕互联网的快速搜索确实揭示了一些已经存在很长时间的项目。HylaFAX及其更频繁更新的分支:HylaFAX +似乎是企业级软件传真的交易工具。eFAX和mgetty + sendFAX将成为命令行传真的更轻量级替代品,而其他一系列项目将有助于软件传真生态系统:ICTFAX作为基于网络的解决方案,IAXmodem作为桥接支持IAX的PBX的软件调制解调器(如Asterisk )和您的传真客户端,或spandsp作为电话的DSP函数库。

粗略地说,我们可以识别三个通信层:

  • 数据层,调制解调器发出噪声并在两方之间建立数据通道,允许它们交换符号,
  • 会话层,传真协商通信参数(如页面格式,页面传输速度,图像压缩),
  • 图像/页面层,传真对页面信息进行编码/解码,压缩/解压缩,应用并检查纠错并组合生成的文档。

根据调制解调器处理这些层的数量(物理或模拟),我们可以识别不同类别的设备:

  • 1类调制解调器处理数据层,同时依靠传真软件进行所有会话和页面处理,
  • 2类调制解调器处理数据和会话层,并将图像处理留给软件端。

还有其他类可以带来额外的功能(如不同的速度)。当我们专注于Class 1设备时,我们将它们排除在此介绍之外。

因此,配备传真软件(如HylaFAX)和传真调制解调器可以访问电话线(物理或软件模拟),任何人都可以从他们的命令行发送和接收传真。

发送传真时,所需的只是输入文档(作为图像或pdf文件)和目标电话号码,而您选择的软件将负责拨打远程方,编码和传输数据。接收传真时,进程通常会侦听通过调制解调器串行端口发出的来电,接收所有信息并将其丢弃到本地文件系统或将其邮寄给用户。

我们的设置

我们已经准备好揭开每一层软件传真中隐藏的秘密。为此,我们将几个组件打包在一起:

  • 90年代的2x老式传真机,
  • 2个USB传真调制解调器,
  • 思科SPA112,
  • 星号,
  • IAXmodem,
  • HylaFAX,eFAX和mgetty,
  • GDB,
  • VIM,
  • AFL

我们的设置允许我们部署一堆不同的配置。Asterisk将成为主要的PBX并将负责路由呼叫,提供一个私人电话网络,让我们的不同组件可以相互拨号,而无需前往公共电话网络(PSTN)。Cisco SPA使我们能够将FAX机器和USB调制解调器物理连接到我们的Asterisk网络,而IAXmodem调制解调器仿真非常适合全软件设置。最后,gdb和vim让我们花了无数个小时阅读源代码并逐步完成汇编。

与此同时,在我们研究的大部分时间里,一堆afl模糊器正在运行,试图滥用我们正在研究的组件的不同代码块。我们的模糊器特别适用于测试代码中那些复杂且可疑的代码,同时我们可以继续阅读代码。尽管如此,他们能够快速有效地找到需要我们注意的崩溃和弱代码路径。

MGETTY中存在多个漏洞

这是发现和报告的漏洞列表:

  • CVE-2018-16741:通过Mgetty中的工作描述进行外壳注入
  • CVE-2018-16742:基于堆栈的缓冲区溢出通过Mgetty中的cli参数
  • CVE-2018-16743:基于堆栈的缓冲区溢出通过Mgetty中的cli参数
  • CVE-2018-16744:基于堆栈的缓冲区溢出通过Mgetty中的config参数
  • CVE-2018-16745:Mgetty中通过config参数缓冲区溢出

HYLAFAX中的远程代码执行

虽然我们设法找到了一个可以远程利用的漏洞,但我们在搜索Hylafax中的漏洞时却不那么多产。

  • CVE-2018-17141:远程攻击者可以在Hylafax的传真接收会话期间写入单位指针

在我们的研究中,我们发现了HylaFAX和HylaFAX +非常有用且完整的FAX通信解决方案。他们感觉强大而流畅,并且几乎在我们决定投入使用的任何用例时都能毫无问题地进行通信。他们的源代码(大部分)易于阅读,并使我们能够更好地理解所有这些传真机的工作原理。它有时会显示复杂和疯狂,就像你到达ECM页面传输的点。

在阅读与页面数据传输相关的那些代码时,我们偶然发现了这些问题:

  1. memcpy(recvRow, (const char*) buf, cc);
  2. recvRow += cc;

一个漂亮的缓冲区溢出模式,对吧?这是一个很有希望的错误,我们试图隔离和触及。这行属于FaxModem :: recvPageDLEData(),它们用于在启用JPEG传输时处理传真接收。

在缓冲整个接收页面的同时没有边界检查。

  1. case JP_GREY+4:
  2. case JP_COLOR+4:
  3.     recvEOLCount = 0;
  4.     recvRow = (u_char*) malloc(1024*1000); // 1M should do it?

达到弱势代码

我们希望在向受害者发送传真时触发此错误,直到达到超出界限写入堆分配的缓冲区并最终获利。

说实话,我们做不到。

长话短说:

  • HylaFAX不正式支持JPEG接收,并且明确禁用此功能,同时在FAX sessiom开始时的握手期间宣布其功能,
  • 恶意攻击者可以选择不遵循协议并为会话参数启用JPEG位,无论接收方宣布其功能如何,
  • HylaFAX很乐意接受JPEG作为会话传输格式,并遵循它实现的那些代码路径来处理这个问题,
  • 但它也会启用ECM(错误纠正模式),遵循完全不同的执行流程,不包括调用FaxModem :: recvPageDLEData(),但转到FaxModem :: writeECMData()。

游民。

漏洞突变

有点失望,我们已经准备好打破我们的漏洞了。但是看看在ECM模式下处理JPEG接收的代码,它看起来像这样:

  1. memcpy(recvRow, (const char*) buf, cc);
  2. recvRow += cc;

它看起来很熟悉吗?让这件事爆炸!我们准备了我们的概念证明,它将启用JPEG标志,发送足够的数据来溢出缓冲区,并希望在旅途中覆盖一些不错的堆元数据。我们将目标锁定在受害者身上,钩住gdb并等待魔法发生。传真传输开始,受害者进程崩溃的速度比预期快得多,并且在尝试写入内存位置0时出现了段错误。

等等,什么?

有些东西不像我们预期的那样。最后,负责(m)为recvRow分配内存的开关块没有被执行,使得recvRow未初始化并指向对象构造之前的任何值。

未初始化的指针很有趣,因为它们在对象构造期间不会隐式地获取安全值,但是当实例化对象时,它们将从其存储器位置中存在的任何垃圾中获取它们的值。

可悲的是,我们的夏季研究时间已经到了尽头。是时候结束并向供应商报告了。

结论

传真软件领域的漏洞研究有助于我们更好地理解这项技术,并揭示了其中一些系统可以达到的复杂程度。使用免费软件项目是快速了解传真通信的每一层的一个很好的方法,同时也更容易搞乱有趣和怀疑的代码片段。作为我们寻求更好地理解这项技术的副作用,发现的那些漏洞将被报告并(希望)得到修复。

传真系统已存在数十年。它设计用于在不可靠和嘈杂的电话线上可靠地传输图像,并且几十年前就实现了这一目标。可能在此后的传统维护模式中,该领域不需要太多创新,而且行业已将重点和努力转移到其他领域。

自90年代以来没有受到太多关注的代码库中的漏洞很有趣,但也具有挑战性。虽然我们的研究范围和时间非常有限,但是拥有足够资源的更持久的攻击者肯定会找到他们的方法来实现这些无所不在的,连接的传统通信盒的可靠利用。

那么,你有没有检查过你的传真机是否在晚上窃窃私语?

CE安全网
网络安全宣传推广

发表评论

您必须登录才能发表评论!