一、前言
为了充分利用待评估的硬件，您应该熟悉多种安全测试领域——基础设施、网络、移动应用程序——因为这些现代设备都为我们提供了丰富的攻击面。硬件黑客技术可以极大扩展我们的渗透能力，不仅能够带来一些新的攻击方式，同时，还能增加我们的攻击深度。
二、动机
1. 持久性的问题
目前，漏洞的“半衰期”(用户为其服务/软件中已识别的漏洞安装安全补丁所需的时间的一半)已经非常短暂了;对于托管的Web服务来说，可能只有几分钟，即使是维护可执行文件和各种服务所需的时间，也只有几个小时;就算是对于具有严格的回滚测试要求的客户来说，这个时间也只有几周而已。但是，对于硬件的安全漏洞来说，这个半衰期可能是几年时间，并且，如果开发人员不能正确使用相应的固件更新程序的话，那么这个半衰期就是直到该设备报废为止了。设备一旦安装，它就呆在那里长期运行，即使购买设备的人参加了相关的培训课程，常常也是三分钟热度，很少会记下如何更新它——当他真的需要动手更新的时候，就傻眼了。这就是硬件安全的真实写照。
2. 仅得到shell还远远不够
在网络上面，确实有大量的“硬件黑客技术”指南，但是它们大多停留在“...现在你连接...”的阶段，让读者自己进行相关的攻击、测试和实验。它们根本不会指出真正的风险在哪里，以及如何处置。
是的，我明白(大多数)硬件黑客技术指南的价值仅限于通过UART获得设备上的r00t shell，但坦白来说，这不是一个可行的攻击向量!当您通过UART访问受害者的设备的时候，难道不会引起受害者的警觉吗?或者，为了安装和审计开发用的头文件，还得随身携带该设备吗?
之前，我曾经写过一篇如何获取廉价UART的文章(大概只需要10英镑)，不过，即使拥有了UART，这也只是万里长征的第一步而已!话说回来，如果能够对设备硬件进行这种低层的访问的话，许多原先无法进行的许多事情，现在也能够顺利完成了。
我稍后会提供UART的详细信息，但现在我只想解释一下，在安全人员的眼里，“硬件黑客技术”到底是什么意思，以及为什么该技术是有用的。
三、什么是硬件黑客技术
首先，我们来聊聊“硬件黑客技术”到底啥意思。这是一个非常宽泛的话题——它涵盖了电路改装、回收再利用技术、破坏游戏机上的DRM、访问内置于产品PCB中的IC的调试功能，设计并获得了一个arduino/RasPi/(通用微控制器)来完成手头项目中的某项任务、访问/写入受保护的ROM区域、逆向没有公开的数据表的IC，等等。
由于硬件黑客技术是一个很广的话题，所以我不想陷入定义的泥潭——这些都可以称之为“黑客技术”。
对于我来说，作为一名渗透测试人员和安全研究人员，硬件黑客就是从攻击者的角度分析IoT/硬件，以期找到恶意利用系统的途径。所以，我对“如果我可以使用芯片访问调试/终端界面的话，我会做些什么?”的回答是，使用这种深层次的权限来测试系统的弱点和安全漏洞。这就是我的兴趣之所在，并且一开始就明确表示过了。
因此，以下是我面对设备会想到的各种问题：
- 除了(产品说明书中)的功能之外，我还能做什么?
- 我真的拿微控制器来控制灯光吗?
- 我有固件控制的收音机可以回收利用吗?
- 如果硬件具有许多高级功能，并且这些功能已经超出你的任务所需，那么是否可以将其用于其他方面吗?
- 我可以把它变成一个恶意敲诈设备吗?例如用来完成窃听、录像、泄露敏感的用户数据或个人身份信息(PII)等。
我可以从硬件中获得其所有者的相关数据吗?例如PII、用户名、密码、2FA密钥、密码私钥等。
我可以把设备变为僵尸网络/BTC矿机吗?这是利用黑掉的设备赚钱的最简单的方法——让它们将挖到的BTC发到自己的钱包，或将其添加到僵尸网络，然后出售DDoS服务。
还能想到通过这个设备和其他设备来受益的其他恶意活动吗?
四、一些攻击场景和常见的漏洞
假设你是一名渗透测试人员，在测试的过程中需要黑掉一部设备——那么，现在该怎么办?事实上，从安全角度来看，与硬件黑客有关的攻击对象和攻击手法有很多，特别是：
1. 过时的软件
对于物联网来说，供应链是一个重大的问题。英国最近的一次大规模的黑客攻击表明，设备的通用底层软件中存在许多严重的安全漏洞。但这些缺陷到底是怎么来的?在某种程度上，这是一个供应链问题。
这里的软件通常(不正确地)指的是ZyXEL(Allegrosoft为嵌入式系统制造的软件)，包括非常受欢迎的RomPager服务器软件。很明显，在这次黑客攻击之后，人们才发现这个软件存在安全问题。不过据消息人士透露，Allegro早在2005年就修复了这个漏洞，根据checkpoint披露的“misfortune cookie”漏洞来看，它们在本质上是相似的。
那么，究竟是什么地方出了问题?嗯，像任何其他公司一样，Allegro公司也是要赚钱的，所以他们直接向IC厂商出售其软件。反过来，这些制造商开发出一款芯片后，会随芯片销售/赠送一套相应的SDK，这样公司就能迅速将产品推向市场。所以，问题就出在制造商从未进行升级，所以产品设计师也从未升级过，但是年复一年，这些这些设备一直在生产、销售和应用中——所以这个漏洞从2005年开始就存在了，直到2017年攻击事件发生才引起人们的注意，所以问题主要出在供应链的延迟线效应上面。
有时候，您会见到一些从未听说过的网络服务器(因为早在2003年它们就已经停产了，如D-Link的Boa webserver)，而且有些DNS服务器比您内衣品牌的历史都要悠久，许多内核版本都是属于博物馆级别的，更不要说它们正在运行的busybox的版本了。
2. Wi-Fi之痛
在已经发现的攻击中，许多都是针对商业Wi-Fi环境的。但从这点来看，你从少年时起的Wi-Fi经验倒是没有浪费。
3. 远程命令执行(RCE)
许多情况下，您可以通过互联网发送命令，并在本地设备上以r00t身份来运行各种命令。这显然是非常糟糕的——这种漏洞是许多攻击的源头。许多设备也通过BASH脚本运行所有的东西(甚至网页)，因为可以省去PHP服务的开销。不过，这样做也会带来安全方面的风险：通过注入RCE字符串，攻击者就可能从管理设备的Web应用程序的某处找到某些有用的东西。
4. 远程执行代码
同样，攻击者可以连接外部设备公开的一些的服务，并向其发送精心构造的payload，以便利用其BOF、格式化字符串漏洞等发动攻击。此外，对于这些服务来说，只需通过类似shodan这样的搜索引擎就可以轻松将其找出。
5. 跨站请求伪造(CSRF)
CSRF漏洞可以在用户的浏览器中连接用于管理设备的基于Web的apps/API(这些apps/API几乎无处不在)，然后执行RCE或直接修改设置——这是在基于固件的设备上的一种常见漏洞。为了缓解这种攻击，需要进行CSRF-Token检查，不过完成该项检查需要大量代码，这对于固件芯片来说代价太大了(别忘了，大多数固件芯片的最大存储空间为16Mb)。所以，这个漏洞将来还会非常常见。
6. 跨站脚本攻击(XSS)
XSS也是一种糟糕的漏洞，如果能够利用存储式或反射式XSS攻陷设备的话，用户的浏览器以及设备就会随之沦陷。关于XSS的危害，这里就不多做介绍了，因为网上随处可见!并且这种漏洞本身，也是非常常见的!
7. 文件上传
各种设备上不仅有噩梦般的CSRF漏洞，并且几乎所有的文件解析也很糟糕;如果新的上市设备提供了文件上传功能的话，那么它很可能含有与本地文件包含、目录遍历有关的漏洞，或含有可以直接黑掉它的漏洞(曾经见到过这样的设备，它允许攻击者以root身份将文件直接解压缩到/目录，包括恶意的/ bin / evil-ELF文件)。
8. 基于XML/SOAP的攻击
越来越多的设备正在使用基于移动设备的Android/iOS应用进行设备管理。这些设备虽然听起来很酷，不过，由于开放了基于SOAP/XML/JSON的API来与应用程序通信(很少实现任何身份验证)，因此诸如UPnP攻击、枚举、TR069之类的攻击也会随之而来了。
9. 认证/会话管理问题
默认登陆凭证无处不在! 并且，在许多使用了某些嵌入式平台的设备上面，类似admin:admin这样可笑的用户名和密码也很常见。更可笑的是，大多数用户甚至可以将密码更改为这些设备名(许多人已经不再使用这些设备——请参阅“云”)，因此这也值得注意。同时，验证信息(用户名/电子邮件)枚举攻击也很猖獗，此外还有身份验证绕过漏洞——我记得在一个设备上进行测试时，只需要有一个有效的cookie(您可以通过猜测或暴力方式获取)就可以绕过用户名/密码认证。
10. 信息泄露
如果用户的大部分数据都经由某设备(如客户终端设备)，万一该设备存在漏洞的话，那么这些数据也会处于风险之中。并且，这些设备还可以为进一步的恶意活动做好准备(转储CC数据，通过网络摄像头查看家里是否有人等)。不要忘了，客户终端一旦沦陷，在上面设置恶意的DNS服务器是非常非常简单的事情——但是，大多数用户(甚至技术精湛的IT人员)是不会注意到这个方面的，从来都不会。
此外，如果设备提供其管辖范围下的服务(SIP/VOIP，FemtoCell或IPTV接入)的访问权限的话，则这些设备上的内部机制一旦公开，就会外泄用于加密的私钥、通用共享密钥或凭证(通常是未加密/未经哈希处理的)、认证和加密访问证书、DRM信息和访问方法，等等。
11. “云端”
除了所有上面介绍的问题(它可能比其他地方处理得更好)外，云服务还面临另一个问题。在这种一夜未眠直到凌晨四点写完，并赶在西弗吉尼亚州最后一个公民投票给民主党时完成更新(与美国有关的笑话......我多么国际化)的混乱情况下，引进现代化的时髦服务也是一件非常糟糕的事情。
我可以说的是，即使用户从地球的另一边(通过互联网)修改了他们的路由器上的防火墙设置，但无法阻止厂商努力“解决”人们未知的问题，从而引入更多的问题。
五、硬件方面的问题
还有一些与硬件设备本身有关的具体问题：
1. 更多的供应链困扰
例如，U-Boot就不支持安全引导。早在2005年的时候，ARM处理器就开始支持安全引导模式了，但是直到现有，最常见的引导加载程序也不支持安全引导。这意味着您的引导程序可能无法检查固件是否是恶意的。因此，如果与CSRF漏洞相结合的话，你可以上传一个恶意的固件文件(这一点我会专门写一篇文章加以介绍)。
我们知道，ARM是在许可证模式下销售的，因此许多最便宜的芯片使用的都是旧芯片的设计许可证。所以这个问题跟之前的完全相同——Jazelle模式是一种历史悠久的ARM exec模式，它支持本机Java字节码执行(是的，你没看错)。后来，它被ARMv7中称为“ThumbEE”的新模式所“替换”，但是在全球范围内，您仍然可以看到数十万颗支持Jazelle的芯片。
2. 开发用的头文件
这个问题从一开始就是显而易见的，之所以悬而未决，是因为制作确保“消费者安全”的电路板的成本是非常高昂的。原型设计本身可能就需要几周的时间，而如果再加上创建PCB布局的“安全”版本的耗时，那整体时间就要翻倍了，因此，大多数项目经理都会以成本为由搁置这样的想法。
此外，如果从开发板到生产板只是“省略”了一个连接电阻的话，也算不上欺骗任何人...
3. Bootlog神谕
Bootlog简直是太棒了，其内容之丰富，从便利贴式的注释，到作为默认Wi-Fi密码的MAC地址，应有尽有。它不仅会告诉我们处理器的版本、芯片ID(它们通常被散热器覆盖)、内核版本、精确的软件版本，同时还会告诉我们在/at/on中运行的代码的所有模式。我将来会对bootlog做一些详细的解释，以说明其工作机制。
六、看一个简单的实例
我们来看一个简单的例子——许多CPE(消费者设备，对于家用设备来说，包括路由器、机顶盒、无线中继器等)都使用一些基于Linux的操作系统。假设我们已经在该类设备上连接了一个UART shell。
假设我们知道用于管理设备的Web应用程序的参数列表(借助于Burp Suite的话，这并非难事)，并且有一个python脚本，可以用来遍历它们并注入一个自定义的payload(这很难吗?你可以用google搜啊)——那么，接下来呢?
现在，我们可以使用这个payload：
- ";echo -n "PWNED!" > /dev/ttyS0
它是做什么的?实际上，它会将短语“PWNED!”打印到串行端口(虽然该端口并非总是/dev/ttyS0，但对于Allegrosoft RomPager-esque固件来说通常如此)。也许还应该添加一个计数器，以便让它打印“PWNED! 1”，“PWNED! 2”等等，并打印到屏幕上，从而指出将其输出到哪里了。
去吃午饭吧。
吃完午饭后，你(也许)会从串口发现一些美味的漏洞——有BASH脚本远程命令执行(RCE)漏洞的任何东西都会向串口打印输出PWNED! X。你刚才发现了一个严重的漏洞。
七、那么下一步呢?
我想知道的是，如果该RCE具有CSRF能力的话，您多久才能将这个“相邻网络RCE”变成“互联网RCE”。果真如此的话，那么可以将其嵌入到一个javascript payload中，并利用一个非常简单的javascript代码来启动它。
八、那么，接下来怎么办?
从我的角度来看，不停的追问，正是从事硬件黑客的乐趣所在。更多精彩内容，敬请期待。
原文发布时间为：2017-11-06
本文作者：shan66
本文来自云栖社区合作伙伴51CTO，了解相关信息可以关注51CTO。
