看我利用传真功能漏洞渗透进入企业内网

发布日期:2018-09-21 点击次数:
  从远古时代的飞鸽传书到后来的邮政快递,写信人与收信人之间的物理消息传递方式逐渐在演变发展,之后,传真技术的出现从某种程度上说,帮助人们走出了信件传递的黑暗时代。
 
  然而,技术发展到今天,就通信手段而言,我们有电子邮件、社交聊天、移动通信渠道、网络服务和高大上的量子卫星通信等等,但在这种喜新厌旧的信息时代中,传真技术仍然没被淘汰,且依旧被广泛使用。根据简单的谷歌搜索可以发现,网上出现了超过3亿个的在用传真号码,看来,传真技术还是我们常用的办公通信方式之一。
  为此,CheckPoint 决定深入研究一下这种“老派”的通信方式,看看它除了具备嘈杂的传呼机功能和官僚主义负担之外,是否存在着严重的网络安全风险。以下为CheckPoint 的相关研究:
 
  研究背景
  如今的传真技术被广泛集成于多功能一体打印机设备中,之后,家庭或企业通过以太网、WiFi、蓝牙等接口把这些一体机接入内网使用。当然,为了支持传真功能,这些一体机还连接了传统话务(PSTN)的电话线。
  我们在研究一开始就定下了这种假设,攻击者能否仅仅通过电话线和相应的传真号码,就能向多功能一体打印机发送恶意传真来实现入侵呢?如果答案是“能”,那么通过这台受控打印机,就有可能深入向企业内网渗透。终于,经过漫长而乏味的研究,我们有了突破。
  事实上,我们在多功能一体打印机中发现了几个关键漏洞,利用这些漏洞,通过向其发送构造的恶意传真,就能实现对其完全的入侵控制。这样一来,打开了企业内网之门,也就什么可能都存在了,攻击者可以潜伏在多功能一体机中,向脆弱的企业内网电脑发起“永恒之蓝”漏洞攻击,或通过传真方式窃取内网电脑数据并向外回传。
  我们把这种攻击称之为“Faxploit”攻击。以下为实际网络环境中的PoC视频:
  演示视频:
  逆向固件
  首先,在固件逆向分析过程中,我们使用IDA来识别传真功能中实际的运行进程和环境,有了一些发现:
 
  架构
  我们测试的多功能一体机是基于ARM 32bit的CPU架构的大端存储模式(Big-Endian),主CPU使用共享存储区与控制LCD屏幕的MCU元件进行通信。
  操作系统
  操作系统是Green Hills的ThreadX式嵌入式实时操作系统,它使用平面内存架构,很多任务进程运行于内核模式下,使用同一个虚拟地址空间。也是由于这种平面内存架构的原因,我们认为任务进程的通信是通过消息队列方式进行的(FIFO),另外,其虚拟地址空间是固定的,未部署任何地址空间布局随机化(ASLR)保护机制。
 
  DSID值
  然而,当我们在分析T.30状态机任务(“tT30”)时,偶然发现了很多使用特别ID的追踪方法(trace),深入分析发现,这些ID也被用于一些以“DSID_”为前缀开头的字符串列表中。实际上,这些字符串看似是与那些使用ID的追踪方法(trace)逻辑相匹配,这也给了我们重要的逆向提示线索。于是乎,我们从所有不同的DSID列表中创建了一个枚举类型,形成了任务中的各种追踪方法文本描述。以下为trace追踪方法中使用的DSID值:
  T.30状态机中的DSID列表:
  追踪方法中应用DSID枚举:
  任务不一致性
  当我们逆向T.30状态机和之后处理HDLC的传真猫(“tFaxModem”)时,发现缺少了多个函数指针表。之后我们还发现,有两种常规的代码模式貌似和 allocation/deallocation路径有些相似。每个模块中采用的方法,是为了接收来自其它模块的消息,或者,也可能是把缓存发送到下一模块中,如下图使用某个功能表从另一个任务接收数据帧:
  如果我们不能定位这些模块中采用的具体方法,也就无法弄清固件中的数据流形式,会对固件的下一步分析造成阻碍。由于我们无法定位到大多数方法指针的初始化,所以,我们需要一种动态方法,也即调试器来进行调试。

  创建调试器
  串行调试接口
  首先,我们分析了一体机的主板,想找到上面的串行调试端口,不一会,我们就有了发现。下图为连接JTAGULATOR到打印机的串行调试器:
  但接入调试器之后,我们才发现其调试接口的默认权限是受限的,不能有效地执行我们的预设命令:
  这看起来是需要提权才行了,但提权就得需要漏洞啊,那就来找找看吧!
 
  匹配已知漏洞
  寻找已知漏洞
  当你要exploit一种特定固件时,首先的方法就是去看看它使用了哪些开源代码,对比不同版本,尽可能地找到能用的CVE。这项工作1天已经足够了,对于调试目的来说也是绰绰有余。有两种方法来判断使用的开源代码:
  另外,要发现这些开源代码漏洞有几种方法:
  gSOAP工具包调试漏洞 - CVE-2017-9765
  在开源代码分析中,我们发现其中使用了gSOAP库,经分析确认,gSOAP库曾存在“魔鬼绿萝”(Devil’s Ivy)的CVE-2017-9765漏洞,是早前在监控摄像头开源软件中爆出的0-day漏洞,曾影响了全球大量IoT设备。以下为该漏洞代码段的反编译代码:
  利用该漏洞,向多功能一体机发送超过2Gb的XML数据时,将造成整型下溢,最终会导致栈缓冲区溢出,可执行任意代码,能实现对目标多功能一体机的完全控制。
  但是,该漏洞的利用存在两个前提限制:
  对Devil’s Ivy的CVE-2017-9765漏洞利用
  该漏洞可以触发栈缓冲区溢出,但存在一些限制型字符。这种字符如下:
  该漏洞的一个好处是溢出无限制,也就是说,我们可以把整个漏洞利用链发送到目标设备的栈区中进行攻击。
  但在嵌入式环境中,我们需要注意的是其CPU的各种缓存可能会对漏洞触发造成影响。CPU中接收到的数据包会存放在数据存储区 Data Cache (D-Cache),而执行指令则会在Instruction Cache (I-Cache)中进行。也就是说,即使没有NX位支持,由于CPU会通过 I-Cache 执行代码,那么我们也不能直接在栈缓冲区中实现漏洞Payload的触发。
  如何才能绕过以上这些各种限制呢?我们需要用到一种包含以下部分的Bootstrapping算法利用:
  在此,我们就不展开详谈漏洞利用链构造过程,如果你感兴趣请自己尝试测试。接下来,我们来说说漏洞利用的各种载体。
  Scout调试器
  我们构建的调试器是一个基于指令的网络调试器,它支持基本的内存读写请求,还能扩展支持特定固件指令。我们使用调试器从多功能打印机中提取了其内存,然后对它进行了一些扩展测试。
  一旦调试器被配置了附带固件API函数,如memcpy、sleep和send等地址后,由于它是位置无关的,所以调试器就可以加载任意地址。Scout Debugger下载地址:https://github.com/CheckPointSW/Scout
 
  ITU T.30 - Fax协议
  多功能一体机如果支持传真功能,那么也一定能支持涉及传真设备的ITU-T G3协议标准,该标准定义了传真发送端和接收端的基本功能,以及协议的不同实现阶段,如下图所示:
  我们重点来看上图的Phase B和Phase C,Phase B负责发送端和接收端之间的协商(握手),而Phase C则根据协商规定进行数据帧传输。数据帧利用面向比特的高级数据链路控制协议(HDLC),通过电话线来进行传输,如下图所示:
  挖掘攻击向量
  发送TIFFs
  存在一种误解,也就是传真只是一种简单地TIFF报文发送手段。实际上,T.30协议能发送页面,且Phase B阶段协商的参数中就已经包括了页面长度和宽度,而且,Phase C阶段则主要是传输页面的数据行。也就是说,传真最终的输出是一个包含IFD标签的TIFF文件,IFD标签在该过程中用于构建协商用的元数据,.TIFF文件中包含有接收到的页面行。
  尽管.tiff解析器存在很多漏洞,但很多都是在IFD标签的解析代码漏洞,而且我们这里的研究用例中,这些IFD标签都是由多功能打印一体机自己创建的,这里唯一会对我们的页面内容执行的处理过程就是,打印过程中打开其压缩内容。
 
  TIFF压缩
  不幸的是,.tiff格式使用的压缩机制有多个名字,因此首先需要把它们找出来。以下是它们的一个基本映射关系:
  由于传真基本是黑白颜色的,所以,压缩机制实际上是一种使用了固定霍夫曼表的黑白代码行程编码方式(RLE)。因此,我们再对T.4 和 T.6 的代码压缩机制进行分析,没发现什么可以利用的漏洞。
 
  T.30扩展
  在Pahse B阶段,传真猫会进行功能交换,所以它可以找出能支持的最佳传输方式。为此,我们编写了一个简单脚本对这些使用ITU T.30标准的消息进行了语法分析,下图为对数字识别信号(DIS)的解析结果:
  看似我们测试的一体机支持ITU T.81 (JPEG) 格式,也就是说,它能发送彩色传真。而在分析彩色传真的处理代码过程中,我们有了另外的新发现:接收到的数据按原样存储到.jpg文件中,与.tiff文件中标头由接收端创建的不同,这里的.jpg我们可以对整个文件进行控制。
  我们基于标准对这种传真行为进行了检查后发现,由于JPEG格式非常复杂,其标头Header(也称为标记maker)确实是通过电话线发送的,接收端负责处理它们并决定保留下什么。一些标头可能不受接收端支持,会被丢弃,如COM的其它标头则会被忽略。在我们对固件和开源代码的测试检查中,接收内容总会被无过滤地转储到一个文件中保存,这也就成了攻击者的一个很好的“猎物”。
 
  打印彩色传真
  概括来说,当目标打印机接收到一个彩色传真,它就会简单地无安全过滤地,把其内容转储到一个.jpg文件中,通常来说,这个文件位于%s/jfxptemp%d%d.jpg。然而,接收传真只是第一步,接下来还需要打印传真,为此打印模块需要首先确认接收文件的长度和宽度,所以,还要进行一个基本的语法分析。
 
  JPEG解析器
  存在一些说不清的原因,这种特定固件的开发者倾向于把主流开源项目中实现的模块功能进行重新编写,改善优化,也就是说,他们不会用开源的libjpeg标准库,转而是用自己的 JPEG 解析器。从攻击者角度来说,这就是一个可以利用的点,在开发者自己开发的复杂文件格式解析器中来发现可利用的漏洞,似乎也不是没有可能。JPEG解析器原理非常简单:
  这不,我们就以此为突破口,发现了以下两个漏洞。
 
  CVE-2018-5925 – COM标记解析缓冲区溢出漏洞
  根据ITU T.30 standard标准,COM标记 (0xFFFE)是一种大小可变的文本字段,这种文本字段一般用来代表文本类型的注释说明。从这个点上,我们希望发现某种解析漏洞。比较搞笑的是,根据ITU T.30 标准来看,这种COM标记应该要被传真接收端丢弃才是。然而,我们却在其中发现了以下漏洞:
  解析模块会解析一个低字节序或小端模式的2字节长度字段,并反复执行从传真文件中复制数据到一些全局数组中的操作。貌似数组中的每个条目都有2100字节的大小,而我们的构造的长度字段可以高达64KB,这就给了我们一个大容量的可控缓冲区溢出区域。
 
  CVE-2018-5924 – 解析DHT标记时的堆栈缓冲区溢出漏洞
  由于上一个漏洞的发现是标准实现中不应支持的标记所导致的,所以,我们继续把关注点扩展到了其它标记身上。在解码文件的数据帧时,DHT标记(Difine Huffman Table) 定义了一个特定的霍夫曼表来使用。而且,这个DHT标记漏洞涉及到的函数比上个漏洞函数还简单容易一些:

  一个简单的计算就能知晓具体的漏洞成因:16 * 255 = 4080 > 256,也就是说,我们可以构造一个大容量可控且无限制的堆栈缓冲区溢出,这是多好的一个漏洞啊。
 
  创建漏洞利用代码
  对比以上两个漏洞,由于DHT标记解析漏洞相对容易实现。在Devil’s Ivy漏洞中,其中的调试exploit利用代码,也是利用了一个堆栈溢出漏洞,那么这里我们也是一样,仅只需要对调试exploit作出一些小修改即可。
 
  自动化Payload – 实现图灵机机制
  我们可以使用同样的网络加载器来构造调试exploit。然而,当前的攻击向量有一个主要的优势:完整的攻击Payload可以存储在传真发送的“JPEG”中,鉴于它不对传真内容执行任何安全过滤检查,因此我们可以把整个Payload都存储在发送文档中,不需要担心它是否会被转储为一个非法的JPEG文件。
  而且文件的fd文件描述符也存储在可访问的全局变量中,所以, 我们编写了一个基于文件的加载器,该加载器会从文件中读取Payload,然后把它加载到内存中去。之后,每次Payload想要用输入执行任务时,它就会从同一文件中读取输入并按照其中的指令实现任务操作。为此,我们构建了一个基本的图灵机机制来从发送传真中读取输入并实现操作。
 
  通过网络传播
  入侵控制一台企业打印机也不错,但是我们想做的远不只这些。实际上,如果能通过打印机来控制整个企业内网,那影响和威胁就就非常之大了。所以,我们利用我们漏洞分析团队之前的研究结果,综合了NSA武器 - “永恒之蓝”( Eternal Blue)和“双脉冲星”(Double Pulsar),应用于此次传真漏洞的基于文件的图灵机中来。
  我们的漏洞Payload具备以下功能特点:
  由此,我们通过传真漏洞远程实现企业内网的多功能一体机入侵控制,并以此为据点,可向企业内网深入进行横向渗透。
 
  总结
  我们测试用的多功能一体机为 HP Officejet Pro 6830,研究测试表明,这种当前的传真实现协议存在安全隐患,其它啥都不用,仅需要向目标一体机发送一份传真就能完全控制设备,可以此为潜伏据点,用已知的NSA漏洞exploit深入向企业内网渗透。
  从现在起,传真机也能成为渗透入侵企业内网的途径之一。我们认为,这种传真技术存在的安全风险应该被重视,因为它延伸了现代企业网络的安全边界,网络打印机和传真机都有能成为网络架构中的一个入侵风险点。
 
  漏洞披露进程
  在与惠普公司(HP)进行协商之后,有了以下的漏洞披露进程:

  转自:黑客技术与网络安全
分享到:
×

微信扫一扫分享