看我如何研究并发现了洛比机器人的漏洞

上个月末，我们的实验室迎来了一个非常重要的“人”：Robi机器人（他有一个摄像头和一个扬声器！）。我们有幸组装了它，然后让它跳起了舞。与此同时，我们对未知领域的探索也开始了，在通过软件发送命令控制机器人时，我不禁想知道它到底有多安全。

一开始我预测是某种蓝牙的连接，但后来发现机器人有自己的Wifi网络板，所以拥有加入现有网络的能力，默认情况下还自带一个有暗示性SSID的开放式接入点。开始时我也遇到了一个防御机制，具体被定义为仅允许与另一台机器建立单独的C&C连接。

经过进一步检查C&C移动软件，我看到了确认为网关/WiFi管理界面的IP地址，在快速扫描之后，确定开放的端口如下：

23：用于即将到来的C&C通信。 24：用于摄像头实时视频流。 80：用于web管理界面。 8080：用于CLI（命令行界面）。

所以，主要的范围就是访问底层结构（或OS级别）以查看其内部核心。幸运的是，我还没有完成这个目标：）

接入点分析

我首先分析了嵌入在机器人主板中的Wifi接入点。它配有一个开放的网络，默认情况下不受WPA/WPA2 PSK的保护。同时，在连接到Web管理界面即80端口时没有认证机制的防护。

这些特点极大地改善了用户体验，但同时减少了对机器人的防护。在更深层次的检查中，我发现它没有关于Web管理界面认证机制的任何可配置的设置。

研究过程中已经确认的漏洞列表：

1.Web管理界面的XSS持久性漏洞 2.无需身份验证访问CLI（或通过控制台移动机器人） 3.功能性逻辑绕过 4.反射型XSS（在IE兼容模式下有用） 5.开放重定向 6.用于Dos情况的跨站请求伪造

Web界面中的发现

我继续对这网络应用深入分析，然后遇到的第一个参数就是System name。正如所料，这个名字完全可以个性化，那么为什么不从XSS载荷开始做点事呢？

事实上，System name的值似乎没有被过滤，它被进一步存储在浏览器中。在我看来，这个特殊漏洞会威胁到用户/所有者的安全，因为它给予了攻击者机会来挂载钓鱼网络，以实施钓鱼攻击。

此外，只有通过访问网页，受害者才能部分/完全意识到攻击，因为SSID也是有漏洞的，但是这里需要了解一下：不同于System name，注入的有效载荷也会出现在扫描中的接入点列表中，这会触发警报。

使用Web界面，我也注意到参数变量“反射”在网页中，但是运气不好，因为Content-Type返回text/plain。但是，它确实意味着其对IE用户的兼容模式有一定威胁。

在某些时候，网页通过名为01的GET参数的值将用户重定向到一个网站的页面。我们可以滥用此参数并将用户重定向到任意选择的地址。所以这可以用于将目标重定向到钓鱼网站。

与CLI（命令行界面）进行交互

机器人的一个非常有趣的端口就是8080，当连接时，就会显示一个非常棒的命令行界面，其具有很长的功能列表。不过也有不好的地方，其中之一就是服务不提供任何形式的认证/授权。在这些功能中，我们可以注意memshow，memdump，memset和flash memory map这样的行为（这对于尝试访问OS层非常有用，但是我们还在继续研究，也请多多关注）。

定义为servo（伺服）的功能允许我们以给定的速度移动72个伺服电机中的一个，这个操作实际上绕过了整个系统的功能逻辑。这是为什么呢？因为用户需要在下载桌面/扩展移动应用程序之前创建帐户并登录才能与机器人交互。

另外，为了使用servo（伺服）命令，必须给出2个输入参数。第一个是伺服电机端口。组装机器人并连接转子时，主母板上显示3个总线电路，每个总线电路包含不同数量的端口。这些端口被命名为Dxy，其中第一个数是从0到23的数字。另一个是任意选择的转子的旋转功率或旋转角度。

访问摄像头

在与机器人电机成功互动之后，我把注意力转移到放置在机器人头上的嵌入式摄像头。我没能成功尝试并解释来自端口24的流式输入，不过还好看到了开发人员提供的SDK，因为SDK中包含了解释视频流的示例。现在想象一个可能发生的攻击情景：未经授权的攻击者能够捕获摄像头流媒体，并通过公共SDK，CLI或自行开发的程序成功地利用机器人。

在我看来，有几个攻击向量可以让攻击者与机器人进行交互：

机器人正在运行，默认情况下实现嵌入式开放式WiFi 机器人连接到攻击者可以访问的公共网络 假设WiFi设有密码，攻击者就要设法破解机器人的嵌入式WiFi密码。

所以，如果有人（比如隔壁老王）有一个容易出现上述攻击的机器人，就可能会导致不必要的隐私泄露。我们都可以想象到这会出什么问题。

拒绝“机器人”攻击

现在回到分析系统的Web部分，我想更多地了解机器人网络功能的信息。显然，从桌面的和移动的界面，用户都可以扫描接入点，并与机器人接入同一网络中（用户可以选择接入机器人的接入点，也可以将机器人接入现有网络）。

当用户错误地设置登录配置时，问题就出现了。所以从Web管理应用中，如果用户输入了一个不合适的SSID或密码，机器人就会登陆失败，然后发出错误提示。现在问题是用户不能连回机器人来修正错误，因为：

用户连接到机器人开放的WiFi，所以他可以访问机器人的Web应用来设置网络登录信息。 如果配置了网络登录，机器人将取消使用开放的WiFi，并尝试使用另一个指定的网络。 之后在每次启动时，他都会尝试加入网络，如果加入失败就会进入待机模式。

因此，如果用户现在卡在机器人无法加入网络的情况，那么只能硬重置了。这个缺陷也可以被具有网络访问机器人的攻击者所滥用，他可以利用跨站请求伪造攻击，以破坏机器人的可用性，导致拒绝服务状况。

总结

鉴于机器人通信在WiFi上进行，合理的攻击情况如下所示：

从WiFi中取消身份验证客户端以中断C＆C连接 如果机器人使用开放网络，那么可以访问Web应用程序并利用存储的XSS; 使用CLI控制机器人 使用摄像头监视机器人周围环境 发起拒绝服务攻击（强制拥有者重置机器人）

所有这些真的是一个有趣的经历，与机器人的整个互动很棒。在首次使用时，需要进行一些重新校准，但机器人和软件可以根据需要进行自定义。

就像其他新技术领域一样，它需要改进，特别是在像Robotics这样一个比较新的领域，并且在开发的早期阶段。我很高兴能够参与这个过程并提供帮助。我联系了提供商，他们同意就此发表研究博客。