攻击Roku棍子是为了好玩和获利

这真的有一段时间了，但我又回来了，这次我们将探索Roku和视频广告。

对于那些不熟悉的人来说，Roku是一系列流行的媒体流媒体，允许来自不同来源的媒体流，即“频道”，如Netflix，Apple TV等。频道由3D派对开发者开发，可以在“频道商店”找到。它们不仅仅是播放媒体，就功能而言，它们实际上具有丰富的应用程序(很像移动应用程序)：它们可以响应用户交互和来自传感器的输入，所以你可以找到游戏、Reddit客户端等。

Roku向渠道开发商提供订阅和广告两种盈利机制。Roku设备能够使用各种行业标准格式显示视频广告，最引人注目的是大量。在开发者方面，他们提供了Roku Advertising Framework(Roku Advertising Framework，RAF)，这是一个用于请求和呈现视频广告的SDK，以及一个用于推广频道和增加受众的自助式平台。对于广告主方面，他们提供OneView，这是基于他们收购的DataXu。为了有资格获得广告货币化，渠道必须根据其内容和参与度标准获得Roku的批准。

根据业内传言，Roku上的CPM明显高于传统的网络展示，价格在几十美元左右，这取决于频道的内容类型和广告类型(前滚/中滚)和设备的IP地理位置。有趣的是，正如AdExchange提出的那样，有时ADS CPM实际上可能比Roku设备本身的成本更高，这完全符合他们的战略：

Roku的入市战略很简单：让尽可能多的流媒体设备以尽可能低的价格进入更多的家庭，并通过广告将其货币化。

艾莉森·魏斯布罗特。

广告界的每个人都知道，高CPM会吸引欺诈者，Roku的情况也不例外。在过去，发现并披露了几个计划。

但这不仅仅是高CPM。Roku(和一般的联网电视)的威胁模型较弱，更容易操纵，而不会被抓到。由于Roku广告不是在任何类型的浏览器或Webview中呈现，而是在平台的本地播放器中呈现，因此传统的基于JavasScript的验证标记根本无关紧要。

此外，RAF只支持Vavast 2和Vast 3，它甚至不包含AdVerify元素，甚至不包含服务器端广告插入验证头。一般说来，验证供应商要做的就是将他们的像素填充到大量Impression和TrackingEvents元素中，这只允许他们针对请求时间和设备IP执行基本检查，类似于我过去在投标前过滤解决方案概述中所描述的。所有其他值都已声明，并且云很容易被恶意攻击者欺骗。

频道欺骗(也就是假冒库存)：没有相当于Ads.txt的广告，所以没有办法验证竞标请求中的参数，这意味着深奥的频道可以伪装成Netflix、NBA或任何人，以吸引更高的出价。

设备欺骗：可以使用Roku用户代理从其他代理(应用程序/浏览器)发起广告请求。虽然Roku可以通过TCP/HTTP指纹检测到，但Roku支持服务器端广告插入，这是欺诈的理想选择：只需要一个IP，因为请求和跟踪事件(例如播放广告的四分之一)都是从发行商的服务器设计发起的。

印象欺骗：由于CTV缺乏可看性测量，从技术上讲，可以发起广告请求并激发印象和事件像素，甚至可以在屏幕上绘制任何内容。您所需要的只是一个HTTP和XML解析器库。

上面详述的所有广告欺诈风险并不是Roku所特有的，而是适用于一般的有线电视广告。然而，我给自己买了一根Roku棒来专门分析它，我发现了相当有趣的发现：Roku在本地网络上暴露了“外部控制协议”，如他们的文档中所述：

外部控制协议(ECP)通过提供多个外部控制服务使Roku设备能够在局域网上被控制。可以使用SSDP(简单服务发现协议)发现提供这些外部控制服务的Roku设备。ECP是一个简单的RESTful API，几乎可以由任何编程环境中的程序访问。

虽然对于用户来说非常方便，他们可以安装移动Roku远程应用程序，但他们只是工作，但这种机制不包括任何身份验证机制，这意味着LAN内的任何人都可以使用它向Roku设备发出ECP命令。

因此，至少在理论上，可以通过在同一LAN上运行的浏览器上执行JavaScript代码来控制Roku设备。听起来不错，不是吗？幸运的是，默认的ECP端口8060没有被浏览器阻止(其他一些端口被阻止，例如SSH的22端口，因为完全相同的攻击可能在其他敏感服务上使用)。

例如，这意味着攻击者可以通过广告网络(即恶意广告活动)运行恶意JavaScript代码，并向Roku设备发送ECP命令(如果浏览器后面的用户有ECP命令的话)(并且攻击者能够找到其IP地址，稍后将详细介绍)。我之所以将重点放在这个特定的攻击上，是因为通过(Ab)使用广告网络，很容易让您的JS大量廉价运行，这一点很重要，因为相对于其货币化潜力而言，拥有合理的“用户获取”成本，才能使攻击变得实用和经济可行。

我想看看ECP能做些什么，并浏览了文档中的“一般命令”(上面链接)，其中两个命令立即跳过：install/<；APP_ID>；和keypress/<；key>；(安装/<；APP_ID>；和KEYPRESS/<；键>；)。顾名思义，前者可以让你启动任意app(Channel)id的安装屏幕，而后者可以让你随心所欲地按任何键，就像你手里拿着Roku的遥控器一样。总而言之，它们是一个强大的组合，因为你可以在受害者的设备上安装(和启动)任何应用程序。

现在，让我们假设我们已经开发了一个应用程序并将其上传到Roku频道商店，并且我们希望在尽可能多的用户上安装它。我们这样做是因为我们可以：

创建付费频道并向受害者收取款项。记住，他们没有选择安装任何东西，我们将强制他们的设备使用ECP安装我们的应用程序。很简单，但被认为是CC诈骗，联邦调查局会找到你的🙂。

创建免费频道，并通过广告将其货币化。挑战在于，为了展示广告，必须推出该频道。虽然可以用ECP发射，但它不是隐形的。用户将注意到一个不需要的通道正在运行，并将关闭该通道并可能将其移除。这个问题的一个解决方案是找到BrightScript(Roku的应用程序编程语言)或其他系统组件中的错误，并利用它进行权限提升，然后直接在操作系统(Roku OS是Linux)上安装一个守护程序，但这很困难。一个更简单的解决方案是安装一个屏幕保护程序，根据文档的说法，它“是一个在系统空闲一段时间后自动运行的通道。”

现在我们有两个可行的货币化选项，我们可以使用ECP通过(Ab)执行，下一个缺失的步骤是查找Roku的IP地址。通常我们会使用ssdp搜索请求，但不幸的是，在我们的恶意广告场景中，由于浏览器的同源策略，我们无法读取ssdp响应，因此需要另一种方法-我们必须在浏览器🙂中使用javascript进行本地网络扫描。

第一步是找到我们需要扫描的地址范围，因此会立即想到WebRTC对等连接，因为它使用ICE进行NAT穿越，并通过SDP暴露客户端的内部IP。这一功能过去曾被指纹识别供应商滥用，甚至在纽约时报网站上被WhiteOps滥用也是出了名的。不幸的是(或者幸运的是，这取决于您是如何看待这个问题的)，就在不久之前，相对于撰写本文时，浏览器开始实施一项建议，在公开ICE候选者时使用mDNS来保护用户隐私，这意味着您将得到一个类似于1f528c83-551f-4f34-ad3a-67524d2fed83.local的地址，而不是192.168.1.4。

为了简化我们的PoC，我们将只暴力扫描最后一个(192.168/16)，这是家庭路由器最常用的，并且它们通常在同一子网中为新客户端分配IP(使用DHCP)。

对于每个IP地址，使用Roku的ECP端口(8060)发起HTTP GET请求，并使用Roku特定的URL路径(例如，192.168.0.1：8060/query/apps)。对于%1，将在浏览器超时后激发错误事件，因为无法访问该地址。对于%2，将激发错误事件，因为它不是有效的URL。对于2，将激发Load事件，我们可以使用它来识别Roku的IP地址。

请注意，请求必须是HTTP而不是HTTPS，因为Roku ECP不支持HTTPS。直到最近，这还不是问题，因为通过使用被动的混合内容，我们可以从HTTPS发起HTTP请求，这样我们就可以直接在恶意广告的创造性代码中运行这个网络扫描逻辑。

然而，Chrome最近开始在默认情况下屏蔽混合内容(HTTPS网站上的HTTP内容)，当内容不能通过HTTPS访问时，不会退回到HTTP。由于现在大多数网站/广告都是通过HTTPS提供服务的，因此不可能在广告中直接使用此方法，但仍然可以从攻击者控制的HTTP网页执行此操作，方法是将其设置为广告登录页面的目的地(并购买PPC)，或者仅通过编程强制用户重定向到此类页面，这是一种常用的恶意行为。

编辑：在重新考虑之后，我不会公开分享PoC代码。虽然实现它所需的所有细节都可以在本文中找到，但我不想帮助孩子们编写脚本来发动攻击🙂。

因此，在我们找到IP地址之后，剩下的就是发送ECP命令来安装我们的通道：

让之前用扫描仪找到的rokuAddress='；http://192.168.1.8:8060'；；//只用于演示，替换为我们的恶意通道id let install='；/install/'；+appid；let keypress='；/keypress/'；let select=keypress+#39；select'；let home=keypress+#39；Home'；函数postToRoku(Cmd){return Fetch(rokuAddress+cmd，{method：'；post'；，mode：'；no-cors'；})；}//启动postToRoku(安装)屏幕。然后(res=>；{//按安装按钮postToRoku(Select)。然后(res=>；{//返回主屏幕postToRoku(Home)；})；})；

我真的认为这次攻击不仅是理论上的，而且是真正的实践。有可能在初始SSDP响应中包括ECP请求中必须包括的令牌，这样Roku设备就可以验证EXP请求是否来自能够读取响应的一方，例如远程控制移动应用程序，而不是来自浏览器。不幸的是，这不是向后兼容的，可能会破坏构建在ECP之上的现有应用程序。

如果你喜欢这篇文章，如果你对广告安全感兴趣并想聊天-请不要犹豫与我联系！我目前也在寻找新的项目。