然而，技术发展到今天，就通信手段而言，我们有电子邮件、社交聊天、移动通信渠道、网络服务和高大上的量子卫星通信等等，但在这种喜新厌旧的信息时代中，传真技术仍然没被淘汰，且依旧被广泛使用。根据简单的谷歌搜索可以发现，网上出现了超过3亿个的在用传真号码，看来，传真技术还是我们常用的办公通信方式之一。
为此，CheckPoint 决定深入研究一下这种“老派”的通信方式，看看它除了具备嘈杂的传呼机功能和官僚主义负担之外，是否存在着严重的网络安全风险。以下为CheckPoint 的相关研究：
研究背景传真通信是利用扫描和光电变换技术，从发端将文字、图像、照片等静态图像通过有线或无线信道传送到接收端，并在接收端以记录的形式重显原静止的图像的通信方式。传真是基于传统电信线路电话交换网（PSTN）与软交换技术（NGN）的融合。
如今的传真技术被广泛集成于多功能一体打印机设备中，之后，家庭或企业通过以太网、WiFi、蓝牙等接口把这些一体机接入内网使用。当然，为了支持传真功能，这些一体机还连接了传统话务（PSTN）的电话线。
我们在研究一开始就定下了这种假设，攻击者能否仅仅通过电话线和相应的传真号码，就能向多功能一体打印机发送恶意传真来实现入侵呢？如果答案是“能”，那么通过这台受控打印机，就有可能深入向企业内网渗透。终于，经过漫长而乏味的研究，我们有了突破。
事实上，我们在多功能一体打印机中发现了几个关键漏洞，利用这些漏洞，通过向其发送构造的恶意传真，就能实现对其完全的入侵控制。这样一来，打开了企业内网之门，也就什么可能都存在了，攻击者可以潜伏在多功能一体机中，向脆弱的企业内网电脑发起“永恒之蓝”漏洞攻击，或通过传真方式窃取内网电脑数据并向外回传。
首先，在固件逆向分析过程中，我们使用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值：
#p#分页标题#e#
当我们逆向T.30状态机和之后处理HDLC的传真猫（“tFaxModem”）时，发现缺少了多个函数指针表。之后我们还发现，有两种常规的代码模式貌似和 allocation/deallocation路径有些相似。每个模块中采用的方法，是为了接收来自其它模块的消息，或者，也可能是把缓存发送到下一模块中，如下图使用某个功能表从另一个任务接收数据帧：
首先，我们分析了一体机的主板，想找到上面的串行调试端口，不一会，我们就有了发现。下图为连接JTAGULATOR到打印机的串行调试器：
当你要exploit一种特定固件时，首先的方法就是去看看它使用了哪些开源代码，对比不同版本，尽可能地找到能用的CVE。这项工作1天已经足够了，对于调试目的来说也是绰绰有余。有两种方法来判断使用的开源代码：
在固件逆向代码中使用字符串查找，从中找出关键字符串
从厂商网站中查找一些产品的开源代码认证信息
另外，要发现这些开源代码漏洞有几种方法：
在CVE库中查找与其代码库相匹配的漏洞
用熟悉的漏洞进行验证
关注US-CERT每周发布的CVE更新消息
gSOAP工具包调试漏洞 – CVE-2017-9765在开源代码分析中，我们发现其中使用了gSOAP库，经分析确认，gSOAP库曾存在“魔鬼绿萝”（Devil’s Ivy）的CVE-2017-9765漏洞，是早前在监控摄像头开源软件中爆出的0-day漏洞，曾影响了全球大量IoT设备。以下为该漏洞代码段的反编译代码：
但是，该漏洞的利用存在两个前提限制：
漏洞利用代码的传输需要耗费大量时间，优化后，传输时间还是在7分钟左右
只能在IDA和每次尝试失败时产生的基本串行转储环境下来开发这个漏洞
对Devil’s Ivy的CVE-2017-9765漏洞利用该漏洞可以触发栈缓冲区溢出，但存在一些限制型字符。这种字符如下：
不可打印的: 0×00 – 0×19
‘?’对应的: 0x3F
该漏洞的一个好处是溢出无限制，也就是说，我们可以把整个漏洞利用链发送到目标设备的栈区中进行攻击。
#p#分页标题#e#但在嵌入式环境中，我们需要注意的是其CPU的各种缓存可能会对漏洞触发造成影响。CPU中接收到的数据包会存放在数据存储区 Data Cache (D-Cache)，而执行指令则会在Instruction Cache (I-Cache)中进行。也就是说，即使没有NX位支持，由于CPU会通过 I-Cache 执行代码，那么我们也不能直接在栈缓冲区中实现漏洞Payload的触发。
如何才能绕过以上这些各种限制呢？我们需要用到一种包含以下部分的Bootstrapping算法利用：
可以刷新D-Cache 和 I-Cache 的基本的ROP（面向返回的编程）控制
加载到调试器网络加载端的解码shellcode
整个调试器可以通过网络发送到加载端
在此，我们就不展开详谈漏洞利用链构造过程，如果你感兴趣请自己尝试测试。接下来，我们来说说漏洞利用的各种载体。
Scout调试器我们构建的调试器是一个基于指令的网络调试器，它支持基本的内存读写请求，还能扩展支持特定固件指令。我们使用调试器从多功能打印机中提取了其内存，然后对它进行了一些扩展测试。
一旦调试器被配置了附带固件API函数，如memcpy、sleep和send等地址后，由于它是位置无关的，所以调试器就可以加载任意地址。Scout Debugger下载地址：https://github.com/CheckPointSW/Scout
ITU T.30 – Fax协议多功能一体机如果支持传真功能，那么也一定能支持涉及传真设备的ITU-T G3协议标准，该标准定义了传真发送端和接收端的基本功能，以及协议的不同实现阶段，如下图所示：
存在一种误解，也就是传真只是一种简单地TIFF报文发送手段。实际上，T.30协议能发送页面，且Phase B阶段协商的参数中就已经包括了页面长度和宽度，而且，Phase C阶段则主要是传输页面的数据行。也就是说，传真最终的输出是一个包含IFD标签的TIFF文件，IFD标签在该过程中用于构建协商用的元数据，.TIFF文件中包含有接收到的页面行。
尽管.tiff解析器存在很多漏洞，但很多都是在IFD标签的解析代码漏洞，而且我们这里的研究用例中，这些IFD标签都是由多功能打印一体机自己创建的，这里唯一会对我们的页面内容执行的处理过程就是，打印过程中打开其压缩内容。
TIFF压缩不幸的是，.tiff格式使用的压缩机制有多个名字，因此首先需要把它们找出来。以下是它们的一个基本映射关系：
TIFF Compression Type 2 = G3 without End-Of-Line (EOL) markers
TIFF Compression Type 3 = G3 = ITU T.30 Compression T.4 = CCITT 1-D
TIFF Compression Type 4 = G4 = ITU T.30 Compression T.6 = CCITT 2-D
#p#分页标题#e#由于传真基本是黑白颜色的，所以，压缩机制实际上是一种使用了固定霍夫曼表的黑白代码行程编码方式（RLE）。因此，我们再对T.4 和 T.6 的代码压缩机制进行分析，没发现什么可以利用的漏洞。
T.30扩展在Pahse B阶段，传真猫会进行功能交换，所以它可以找出能支持的最佳传输方式。为此，我们编写了一个简单脚本对这些使用ITU T.30标准的消息进行了语法分析，下图为对数字识别信号（DIS）的解析结果：
我们基于标准对这种传真行为进行了检查后发现，由于JPEG格式非常复杂，其标头Header（也称为标记maker）确实是通过电话线发送的，接收端负责处理它们并决定保留下什么。一些标头可能不受接收端支持，会被丢弃，如COM的其它标头则会被忽略。在我们对固件和开源代码的测试检查中，接收内容总会被无过滤地转储到一个文件中保存，这也就成了攻击者的一个很好的“猎物”。
打印彩色传真概括来说，当目标打印机接收到一个彩色传真，它就会简单地无安全过滤地，把其内容转储到一个.jpg文件中，通常来说，这个文件位于%s/jfxp_temp%d_%d.jpg。然而，接收传真只是第一步，接下来还需要打印传真，为此打印模块需要首先确认接收文件的长度和宽度，所以，还要进行一个基本的语法分析。
JPEG解析器存在一些说不清的原因，这种特定固件的开发者倾向于把主流开源项目中实现的模块功能进行重新编写，改善优化，也就是说，他们不会用开源的libjpeg标准库，转而是用自己的 JPEG 解析器。从攻击者角度来说，这就是一个可以利用的点，在开发者自己开发的复杂文件格式解析器中来发现可利用的漏洞，似乎也不是没有可能。JPEG解析器原理非常简单：
先检查图像开始SOI标记：0xFFD8
循环分析各个支持标记
完成以上步骤后向调用者返回相关数据
这不，我们就以此为突破口，发现了以下两个漏洞。
CVE-2018-5925 – COM标记解析缓冲区溢出漏洞根据ITU T.30 standard标准，COM标记 (0xFFFE)是一种大小可变的文本字段，这种文本字段一般用来代表文本类型的注释说明。从这个点上，我们希望发现某种解析漏洞。比较搞笑的是，根据ITU T.30 标准来看，这种COM标记应该要被传真接收端丢弃才是。然而，我们却在其中发现了以下漏洞：
由于上一个漏洞的发现是标准实现中不应支持的标记所导致的，所以，我们继续把关注点扩展到了其它标记身上。在解码文件的数据帧时，DHT标记(Difine Huffman Table) 定义了一个特定的霍夫曼表来使用。而且，这个DHT标记漏洞涉及到的函数比上个漏洞函数还简单容易一些：
#p#分页标题#e#
可以看到存在一个读取16字节的初始解析循环，这是因为每个字节代表了一个长度字段，所有这些字节最后累积成为一个总的长度变量
存在一个全0填充的256字节本地备用堆栈
第二个解析循环会使用之前的长度字段，从传真文件中拷贝数据到本地堆栈缓冲区中
一个简单的计算就能知晓具体的漏洞成因：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具备以下功能特点：
可以控制多功能一体机的LCD显示屏 – 这是一种打印机完全控制权的体现
检查多功能一体机的网络是否为连通状态
使用NSA“永恒之蓝”（ Eternal Blue）和“双脉冲星”（Double Pulsar）武器，攻击目标内网受害主机，实现入侵控制。
由此，我们通过传真漏洞远程实现企业内网的多功能一体机入侵控制，并以此为据点，可向企业内网深入进行横向渗透。
总结我们测试用的多功能一体机为 HP Officejet Pro 6830，研究测试表明，这种当前的传真实现协议存在安全隐患，其它啥都不用，仅需要向目标一体机发送一份传真就能完全控制设备，可以此为潜伏据点，用已知的NSA漏洞exploit深入向企业内网渗透。
从现在起，传真机也能成为渗透入侵企业内网的途径之一。我们认为，这种传真技术存在的安全风险应该被重视，因为它延伸了现代企业网络的安全边界，网络打印机和传真机都有能成为网络架构中的一个入侵风险点。
漏洞披露进程在与惠普公司（HP）进行协商之后，有了以下的漏洞披露进程：
2018.5.1 向HP公司上报漏洞
2018.5.1 HP公司感谢提交并着手处理漏洞
2018.5-2018.6 不停的重现PoC场景，修补漏洞
2018.6.2/3 与HP公司面对面沟通
2018.7.23 发现的两个漏洞被标记为高危
2018.8.1 HP公司公布固件升级补丁
2018.8.12 在 DEFCON 26 会议中首次公开