Asus Routers Expose 35 Million Networks to Root Takeover and TV Spying

华硕路由器漏洞致3500万个网络面临Root劫持与电视窃听风险 华硕移动端配对协议中的逻辑漏洞允许未经身份验证的本地攻击者使用空字符串伪造管理员令牌、获取root SSH访问权限，并以此为跳板攻入智能电视录制室内音频。 Gamers Nexus调查了现代华硕路由器的配套应用程序协议和NTP处理中存在的身份验证绕过及命令注入漏洞。通过将该路由器漏洞利用与LG智能电视中现有的未修补远程代码执行漏洞结合，该团队展示了拥有本地网络访问权限的攻击者如何攻破路由器并在子网内横向渗透，进而通过电视麦克风秘密串流实时音频。该报道剖析了允许空字符串令牌伪造的底层逻辑缺陷，详细列举了华硕繁琐的初始配置最终用户许可协议（EULA）和隐私暗模式，并审视了该厂商未能在标准的90天负责任披露期内发布补丁的情况。最后，Steve Burke及其团队提供了实用的加固建议，敦促用户避免使用移动端路由器应用、设置复杂的管理员凭据，并隔离局域网存储设备。 安全研究员Mr Bruh发现严重的身份验证绕过和命令注入漏洞，波及自2018年以来生产的估计2500万至3500万台华硕路由器。 (0:00) Gamers Nexus演示了一条漏洞利用链，将华硕路由器攻破与未修复的LG智能电视远程代码执行漏洞直接串联，把电视改造为环境窃听设备。 (12:13) 该路由器身份验证漏洞源于配套移动应用协议中的空字符串初始化逻辑错误，允许攻击者随意生成管理员令牌。 (19:50) 华硕申请了超出行业标准90天负责任披露期的延期来推送修复程序，导致数百万台已部署设备在数月内处于未修补状态。 (32:51)

Security researcher Mr Bruh uncovered critical flaws in an estimated 25 to 35 million ASUS routers that allow unauthenticated local attackers to bypass authentication, gain root access, and pivot across local networks to compromise connected devices. Authentication Bypass and Command Injection Mechanics (19:50) The primary exploit leverages a flaw in the companion mobile application authentication architecture. When handling mobile pairing, the router initializes its decryption variable with an empty placeholder string. If a request provides a recognized device identifier, the router loads the stored secret; however, if an unknown device ID is supplied, the router fails to update the variable and attempts decryption using the blank string. By submitting an unknown device ID alongside a payload encrypted with an empty string, an attacker causes the router to issue a valid administrative token. Researcher Mr Bruh noted that this vulnerability only functions if at least one mobile device has previously been paired with the router, as an empty paired device table triggers an unhandled error state. Once administrative privileges are obtained, attackers can exploit an unauthenticated command injection vulnerability in the Network Time Protocol (NTP) server configuration. Auditing calls to the internal function do_system revealed that the NTP address field accepts up to 31 characters of unsanitized input without proper shell escape filtering. Supplying a command payload—such as spawning a root Telnet server via telnetd—executes arbitrary code whenever the device boots or restarts NTP, functioning across both standard gateway and Access Point (AP) operational modes. Lateral Movement and Smart Device Hijacking (12:13) Gamers Nexus demonstrated how gaining administrative control of an ASUS router facilitates lateral movement across a local network. Using the forged authentication token, Patrick Lathan ran a Python script that injected an attacker's public SSH key into the router configuration and executed chpassword.sh to reset the administrator password. From the administration interface, attackers can view cleartext Wi-Fi passwords and query connected client MAC and IP addresses. To highlight the risk of exploit chaining, the team pivoted from the compromised gateway to an unpatched LG Smart TV located on the local subnet. Researcher Tannen Williams executed a remote code execution payload targeting the television at IP address 192.168.50.165, invoking the Linux arecord binary to hijack the TV's integrated microphone array. The audio feed was streamed over netcat to a local listener while displaying a deceptive system update notification on the screen, proving how an adversary can repurpose networked appliances into persistent ambient listening bugs. Espionage Risks and Physical Security Threats (25:08) The potential reach of the vulnerability covers virtually every Wi-Fi 6 and newer ASUS router released since 2018, representing between 25 and 35 million deployed units based on hardware shipments and over 5 million companion app downloads on Google Play. Gaining persistent footholds does not require defeating exterior firewalls; attackers can connect via guest Wi-Fi, open Ethernet wall ports in office lobbies, or directional wireless attacks. Beyond automated botnet recruitment, Mr Bruh emphasized targeted espionage risks against corporate targets or journalists. A compromised router acts as an internal intercept station capable of inspecting unencrypted traffic, logging DNS requests, and raiding local network-attached storage (NAS) devices that lack robust credentials. Furthermore, attackers can write automated scripts querying the router every 10 minutes for specific mobile device MAC addresses to detect when a target leaves home, translating digital compromise into physical vulnerability. Setup Dark Patterns, Disclosure Delays, and Hardening (27:02) During setup testing on an ASUS RT-AX1800S V2, Gamers Nexus identified aggressive onboarding terms, including a mandatory End User License Agreement asserting user consent simply upon powering up the device. The setup flow also exhibited a Catch-22 ordering issue where users were required to certify they were over 16 before accessing a privacy page that offered reduced telemetry for minors. Notably, actively rejecting the telemetry terms disabled the companion mobile app interface, inadvertently neutralizing the authentication bypass exploit. ASUS also faced criticism for handling disclosure poorly. After Mr Bruh reported the vulnerability on June 27, ASUS failed to deploy a stable fix across affected models before the standard 90-day responsible disclosure window lapsed on September 26. ASUS requested an extension into November citing financial and development timelines, which the researcher denied. Steve Burke advises ASUS owners to manage devices strictly via local offline browser sessions, avoid vendor cloud accounts or smartphone apps, update default administrative credentials, and password-protect local storage devices. While ASUS began silently deploying firmware updates to select routers in late September, the vendor has not published a comprehensive list of vulnerable models, leaving millions of legacy and unpatched devices open to compromise until owners manually update firmware and restrict companion app functionality.

根据 Gamers Nexus 与安全研究员 Mr Bruh 的调查，全球约 2500 万至 3500 万台华硕（ASUS）路由器存在严重的认证绕过与命令注入漏洞，攻击者无需既有权限即可在局域网内夺取路由器控制权，并借此向内网中的智能电视等未打补丁设备发起横向渗透。 认证绕过与系统命令注入机制 (19:50) 该安全漏洞的核心源于华硕路由器配套移动应用程序认证流程中的逻辑缺陷，以及固件底层对系统命令调用的缺乏过滤。研究员发现，路由器在校验移动端配对凭证时，初始解密密钥变量被预设为空字符串；当收到未配对的虚假设备标识时，系统未能成功匹配密钥，却依然默认使用空字符串解密传入的有效载荷，致使验证逻辑被直接穿透并签发合法的管理员令牌。此外，系统内置的 do_system 函数在处理网络时间协议（NTP）服务器设置时未对用户输入进行字符转义，攻击者利用获取的会话凭证可向时间服务器配置项中注入最多 31 个字符的任意 shell 指令，在设备启动或服务重启时强行启动未授权的 root 权限后台服务。 内网横向移动与智能设备劫持实测 (9:43) 在实机测试中，测试团队借助 Python 脚本向网关发送利用载荷，成功利用绕过漏洞注入攻击者的公钥并直接开启 SSH 服务，在无需输入原管理员账号密码的情况下重置管理权限并获取最高控制权。进入路由器后，攻击者可直接读取明文 Wi-Fi 密码并调取内网映射表，定位局域网内连接的全部客户端设备。Gamers Nexus 随后将路由器控制权与此前披露的 LG 智能电视本地远程代码执行（RCE）漏洞形成利用链，通过向局域网内的目标电视注入 arecord 录音指令，激活电视内置麦克风阵列并将音频实时串流回监听服务器，同时在屏幕上生成具有欺骗性的虚假系统更新弹窗，证实了局域网边界失守后外围设备被改造成物理监听节点的严峻风险。 设置暗模式与厂商责任披露争议 (32:51) 除了固件漏洞本身，华硕在设备初始化界面的设计也受到批评。路由器初始化流程中存在强制性的最终用户许可协议（EULA）与数据共享条款，用户被要求必须确认年满 16 岁方可进入下一步，而限制向第三方共享数据的选项却被置于该步骤之前，形成了无法实质拒绝遥测收集的逻辑陷阱；但若用户强行选择拒绝条款，则会意外阻断移动端配套服务的启用，从而在客观上规避该认证绕过漏洞。在漏洞处置方面，研究员依据业界通行的 90 天负责任披露期向华硕提交报告，但华硕在拥有测试补丁的情况下仍申请将发布延期数月，导致披露期限届满时仍未面向数千万存量设备完成全量修复推送，且官方至今未公布完整的受影响机型清单。 网络威胁建模与安全加固防御建议 (22:21) 调查指出，攻击者无需物理接触机房，仅凭咖啡厅公共网络、办公区开放式网线接口、访客无线网络或远距离定向连接即可接入局域网并实施攻击。路由器一旦沦陷，不仅可被用于监控用户的网络浏览记录、推断特定人员的外出时间规律以辅助现实侵害，还会使原本缺乏强密码保护的内部网络存储（NAS）和监控摄像头完全暴露。针对此类风险，防御建议包括避免将路由器绑定至厂商云端账户或移动配套应用程序，坚决摒弃出厂默认密码与常规管理员用户名，对局域网内部存储设备实施严格访问控制，并始终将局域网视为潜在不安全网络进行分段防护。 该漏洞揭示了现代物联网设备过度依赖移动端联动接口与云端绑定所带来的潜在攻击面扩张。尽管华硕已针对部分型号陆续推送更新，但由于缺乏详尽的受影响设备公开清单，全球仍有大量采用默认配置的家庭与企业网络设备暴露于未受修补的静默威胁之下。

[16:32] Steve Burke: ASUS has not publicly disclosed a full and complete list of which routers are affected by this vulnerability, which we have found to be irresponsible, but also not surprising of ASUS in particular, because that makes it hard for users to know if they're affected.

[0:00] Halloween's pretty close, so we've taken [0:01] the two scariest things we could think [0:03] of, ASUS and LG Electronics, and we've [0:06] combined them. We've managed to create a [0:08] nightmare scenario for possibly 35 [0:11] million ASUS routers, which have a [0:14] vulnerability that allows you to [0:16] tunnel through them and gain access [0:17] potentially to other device on the [0:18] network, such as possibly 216 million LG [0:22] Smart TVs using some of the exploits we [0:24] talked about previously, plus this new [0:27] ASUS router exploit that Mr. Bra has [0:29] discovered and we can disclose today, [0:31] where you're able to as an attacker [0:33] tunnel through that router once you've [0:35] compromised it or a lot of other [0:37] affected models we'll talk about, and [0:39] into other devices that may be on the [0:41] network. So, one example of such a [0:43] device could be an LG Smart TV. This TV [0:46] is connected to that ASUS router for its [0:49] network, and so by chaining these [0:52] exploits together, we can either turn [0:54] the TV into a command and control server [0:56] potentially or an active listening [0:58] device, [0:59] which we showed part of in the LG video, [1:02] but now we're able to go to any [1:05] cafe or small office that has one of [1:08] these signs on the wall, [1:10] connect to the ASUS router, or plug into [1:13] just an abandoned Ethernet port in the [1:14] wall that might be routed back to that [1:17] router, [1:18] and compromise it. [1:20] Then tunnel through to the TV and [1:22] compromise that, which is not updating [1:25] right now. [1:29] But that's what it says it's doing. [1:31] So, here's what I just hosted played [1:33] back by the TV. [1:35] >> This TV is connected to that ASUS router [1:38] for its network, and so by chaining [1:41] these exploits together, we can either [1:43] turn the TV into [1:45] >> Sounds pretty familiar. [1:48] Do not connect this ASUS router or [1:51] millions of other ones to the internet [1:53] without first checking with Patrick. [1:55] That's Does that [1:57] Does that [1:59] Windows 10 support has ended. Upgrade to [2:01] Windows 11. [2:03] No, I don't think I will. Where were we? [2:05] ASUS has found itself on an extensive [2:07] list of routers with vulnerabilities. [2:10] Again. [2:11] This is not the same as the last one we [2:13] talked about. In this one, [2:15] an attack would be able to use an ASUS [2:17] router to gain a persistent and [2:19] permanent point of access on your [2:21] network and then potentially move [2:23] laterally through it such as to other [2:24] vulnerable devices like connected TVs, [2:26] smart TVs as an example that we recently [2:29] went into. And at that point, the attack [2:31] would be able to basically do whatever [2:32] they want. An example might be accessing [2:36] a NAS that's connected to the LAN with [2:39] minimal password protection because it [2:41] was maybe never supposed to be online [2:42] anyway. Another example of an attack [2:44] could be using the vulnerabilities in [2:47] routers like this to chain them with [2:49] other vulnerabilities like with LG's [2:51] smart TVs that could allow an attacker [2:54] to stream microphone and camera inputs [2:58] from the TV [2:59] >> [music] [2:59] >> to their own remote server somewhere. [3:01] You could do that by chaining exploits. [3:04] This is a proof of concept of us gaining [3:06] unauthorized access to an ASUS router. [3:08] With the proof of concept code provided [3:09] by the finder of the vulnerability, [3:11] security researcher Mr. Brøt with whom [3:13] we've worked several times in the past. [3:15] In the proof of concept, we visited [3:17] 192.168.50.1 [3:19] to access the web user interface and [3:21] check the default settings. And we were [3:23] greeted by a multi-page EULA that [3:26] demanded us to agree that we were above [3:28] 16 years of age because 16-year-olds [3:30] aren't allowed to set up ASUS routers [3:32] apparently. I'm looking forward to the [3:33] future where they just put a camera [3:35] right in it so you [music] can [3:37] scan face to set up router. That's our [3:39] future. The EULA is a different problem [3:42] entirely, but it opens by saying that [3:44] {quote} by start using the product or by [3:47] installing and continuing to use the [3:49] software, [3:49] >> [music] [3:50] >> I'm going to read the caps as they're [3:51] written here. You expressly acknowledge [3:53] that you have read and understand and [3:55] agree to be bound by the terms of this [3:57] EULA and any new versions here of and [3:59] quote. Also, quote, ASUS reserves the [4:02] right to mandatory update the software [4:04] at any time without your consent, end [4:06] quote. That at least we know a human [4:08] wrote it. Maybe not [music] one in PR or [4:10] marketing, but but human definitely [4:13] wrote that. It's all great. Uh you're [4:15] agreeing to Schrödinger's EULA where it [4:18] says that you agreed to the EULA by [4:21] turning on the device, but you don't get [4:23] the EULA until you turn on the device. [4:26] It's It's actually a paradox. This would [4:28] do so well in a TNG episode. Picard [4:32] would be baffled. Anyway, the router was [4:34] already happily broadcasting the default [4:36] SSID and accepting wireless connections [4:39] even without us reading this magical [4:41] EULA that you already agreed to without [4:43] opening the EULA or even knowing that it [4:45] exists. That's already a lot of problems [4:47] before we even get to the [4:48] vulnerabilities today, but we're going [4:50] to talk about those primarily. So, these [4:52] vulnerabilities were discovered by Mr. [4:53] Brub. They were disclosed to ASUS in [4:56] advance following the responsible [4:58] disclosure timelines, which is a [5:00] security researcher process where they [5:02] typically give at most and normally 90 [5:05] days of advance notice to a company to [5:08] close the vulnerability. The reason for [5:09] this is because they want to basically [5:11] give the public the best chance at being [5:15] protected from that vulnerability before [5:17] it's disclosed out to the wild. Try [5:20] minimize how many people could be [5:21] affected by a an oversight or a security [5:24] vulnerability or risk. So, let's get [5:26] into the proof of concept, show how it [5:28] works, and we'll show you how this can [5:29] chain other things like TVs as well. [5:31] This video is brought to you by us and [5:33] our MicroSLA t-shirts on [5:35] store.gamersnexus.net. [5:37] We just restocked these after having [5:39] sold through all of our inventory again, [5:41] now the third time, because so many [5:43] people are such big fans of MicroSLA. [5:46] This is our most popular design we've [5:48] ever launched. Even just wearing it [5:49] around, I get compliments from people [5:51] who have absolutely no idea what a GN is [5:54] because I assume they like MicroSlop so [5:57] much. They must just be mega fans of [5:59] MicroSlop who love being reminded of its [6:02] existence. These directly support our [6:04] deep dives and research. You can grab [6:06] them on the store. They feature a [6:07] MicroSlopian logo with event viewer [6:09] icons, including a blue screen of death [6:12] frowny face, a Tux the penguin we've [6:14] made, and the classic red accent yellow [6:17] bane. You can grab these alongside [6:18] things like our GN wireframe V2 mouse [6:21] mats on the store. Perfect for both your [6:22] mouse and keyboard for a clean desk [6:25] space and fully designed in-house by [6:27] Andrew for the art with wireframe [6:29] components in a dystopian multi-level [6:32] city style layout connected by highways [6:34] of cables and tubes, which the internet [6:37] is still a series of. We use a custom [6:39] blue rubber underside matched to the [6:41] blue stitched border, and you can grab [6:42] these and more, like the MicroSlop [6:45] shirts on store.gamersnexus.net. [6:47] Back to it. All right, we'll start by [6:49] getting ahead of the deja vu, which is [6:50] that this is a separate vulnerability [6:51] from the ones in ASUS's routers last [6:53] year that turned them into a botnet. In [6:55] the story last year, GrayNoise uncovered [6:58] a possible attempt to build a botnet of [6:59] ASUS routers by exploiting [7:01] authentication bypasses to enable [7:03] command injection and permanently enable [7:05] remote SSH access. We covered that in a [7:08] separate video about ASUS being a [7:09] dumpster fire just in general. In that [7:11] instance, the news was more about the [7:13] coordinated attempt to take advantage of [7:15] the vulnerabilities than the [7:16] vulnerabilities themselves. This time, [7:18] courtesy of Mr. Bro, we have an example [7:20] of the type of authentication bypass and [7:22] the type of command injection attacks [7:24] that attackers can use on ASUS routers. [7:26] There are two things at play here. One [7:28] is the authentication bypass, and the [7:30] other is whatever the [ __ ] the attacker [7:33] wants to do with the router once they've [7:35] bypassed the authentication and on your [7:37] network as a result. Mr. Bro's first [7:39] step was to look through the firmware [7:41] for references to do system, which he'd [7:43] identified as a weak point for injecting [7:45] his own commands. And after a quote, [7:48] "Checking only seven of the 109 uses of [7:50] do system, I found a vulnerable [7:52] handler." End quote. He describes this [7:54] as low-hanging fruit. Quote, "I don't [7:56] think there's going to be a lot of [7:57] command injections left. I just got [7:59] lucky with the distribution and found [8:01] one early. Because they're quite an easy [8:03] one to do, and it's probably a good [8:05] thing to put on your CV to say, 'Oh, I [8:07] found something for ASUS.' Here's the [8:09] CVE." End quote. This particular handler [8:12] would pass along a string without [8:14] sanitizing it, meaning he could take an [8:16] instance where the code is expecting [8:18] words and pass it commands instead. The [8:20] responsible thing to do as a developer [8:22] is to strip out special characters, [8:24] which is called sanitization. If ASUS [8:27] had read their XKCD, they'd know that. [8:30] The specific value being replaced is the [8:32] NTP clock server. So, he could either [8:34] inject a command as described or just [8:37] point to his own server. As soon as the [8:39] NTP server tries to auto restart and [8:42] every time the router boots, either the [8:44] malicious server gets pinged instead or [8:47] the little block of injected code gets [8:48] executed. In an example, instead of the [8:51] name pool.ntp.org, [8:54] he passed telnetd p9999 as a command to [8:57] be executed, enabling telnet control. [9:00] This would be effective even if the [9:02] router was set to access point mode, [9:04] making it particularly damaging. So, to [9:06] do the demo for this, we're going to [9:08] have Patrick walk through the router [9:10] breach and Tanan walk through chaining [9:14] that into the TV. Okay, so Patrick's [9:15] just run the exploit and we have a [9:17] Python script here from Mr. Bra who [9:19] discovered the vulnerability. What does [9:21] the Python script do? [9:24] >> So, the Python script is doing two [9:25] things. Um it's identifying ourselves to [9:28] the router with a blank device ID, which [9:31] uh short circuits the code that's on the [9:33] router, and it shouldn't be handing us [9:35] an off token, but it does. [9:38] Uh [9:38] we're then taking that authentication [9:40] token and or the script as and it is [9:43] using it to insert our SSH public key [9:47] into the router settings. And again, [9:49] that's something you could do [9:50] legitimately. It's just a page in the [9:51] settings, um but we're doing it with an [9:54] illegitimate authentication token. So [9:57] now we are an authorized um SSH uh login [10:02] for the router. [10:03] >> Right. So then at this point, if we want [10:05] to get to the TV, [music] [10:08] uh we need to pull the IP address for [10:09] the TV, which since we're on the [10:11] network, we should be [music] able to [10:12] pull basically the IP address of every [10:13] device on the network. [10:15] So how would you go about that, step? [10:17] >> So the simplest way for me is um [10:20] >> [music] [10:20] >> now that [10:22] we have SSH access, I can use um [10:26] our private [music] key [10:28] uh and [10:31] I'll just change the password. [10:33] Yeah, this is our private key. So we're [10:36] specifying SSHN with our private key and [10:38] this is the router's username uh and now [10:40] we're in. So [10:41] >> Okay. [10:42] So then we can get a list of devices. [10:44] >> Yeah, so uh these are the commands [10:46] available to us. [10:48] Um so if I go over here, I see there's [10:52] um chpassword.sh. [10:54] Um [10:54] >> Yeah. [10:57] >> And it wants a username and a password, [11:00] so [11:01] I know that's our username. [11:03] >> 12345 is pretty No, password's way too [11:05] insecure. Watch 12345. [11:07] >> All right, I'll do 12345. [11:08] >> Maybe a six for flare next time. [11:10] >> [snorts] [11:11] >> So then I should be able to go to [11:16] here. [11:19] Um [11:20] >> So now you're logging into the router. [11:21] >> Yeah. [11:22] So now I'm in. Uh I changed the password [11:24] and I logged in. So now I can if I want [11:26] to um [11:27] >> Inspect the network. So if you're in a [11:29] cafe, you're at this point seeing [11:30] everyone's device. [11:31] >> Yeah, and if I if I want to I can go um [11:34] to our wireless settings um and I can [11:36] just see in plain text, you know, this [11:38] is the password for the um Wi-Fi [11:40] network. You know, if you're connected [11:41] to the Wi-Fi network, you don't have any [11:43] awareness that I'm doing this, but I I [11:44] see the password here. [11:46] Um if I go to the network map [11:49] uh [11:50] I can [11:52] see the list of clients here. So, yeah, [11:55] we've got our TV, we've got um looks [11:57] like Tanan's listening server. So, [11:59] everything that's connected to the [12:00] router right now is, you know, on the [12:01] network map and we've got our MAC [12:03] addresses here. [12:03] >> So, what's our TV IP address? [12:05] >> Uh looks like it's the local IP is uh [12:09] dot 50.165. [12:10] >> 192.168.50.165 [12:13] >> Yep. [12:13] >> Okay. [12:15] All right, so now we'll hand off to [12:16] Tanan to do the listening server. All [12:17] right, so for the next part of the [12:18] exploit, all this could happen on one [12:20] machine. We just did it on two to make [12:21] it easy. And at this point uh the [12:24] attacker has gotten access to the ASUS [12:27] router, has created their own password, [12:30] has access to the back end, and now can [12:31] see all the devices on the network. And [12:33] one of those happens to be this LG TV [12:36] >> [music] [12:36] >> uh which we already know to be [12:38] vulnerable from our past expedition with [12:40] Wendell. So, Tanan, you worked on the TV [12:42] side of this. So, walk me through the [12:45] setup. [12:46] >> Um so, we'll start with the listening [12:48] server. [12:49] Um basically, when we send the TV [12:51] commands telling it to record, we also [12:53] need to tell it where to send those [12:55] recordings to. [12:56] Um so, that's what the listening [12:58] server's for. [13:00] Um basically, this command uses netcat [13:03] and it tells this system to continuously [13:06] monitor port 1234 [13:09] and save whatever wave files it receives [13:12] into our test captures folder. [13:15] Um [13:15] >> And then do you have to [13:18] uh separately compromise the TV first? [13:21] >> No. This uh So, the only thing you need [13:25] you need to be on the same LAN and you [13:27] need to have the TV's IP address. [13:29] >> Right. [13:29] >> Yeah, so and we can't go into detail on [13:31] how specifically uh that all works, but [13:34] that's [13:36] that's how easy it is at least. [13:37] >> Right. [13:38] >> So. [13:39] All right, so you've got a listening [13:40] server set up. [13:41] >> Right, so after we tell it to uh save [13:43] all wave files to our test captures [13:45] folder, um we'll also set up a simple [13:48] HTTP server. [13:51] >> [music] [13:51] >> Um this just allows us to access the [13:54] test captures folder from other devices [13:56] on the local network uh via browser, so [13:59] >> So this is our simple web server. [14:00] >> Right, so if you just type in that [14:03] machine's IP address followed by port [14:05] 8000, you can find the basically all the [14:07] test captures that get saved. Um so [14:10] that's it for the listening server. [14:12] Uh [14:14] And this [14:14] >> have these running in VMs. [14:16] >> Right. [14:16] >> Any particular reason? Just easier or [14:19] >> Yeah, just easier to set up. Um it could [14:22] run perfectly fine on like a bare metal [14:24] device, but uh [14:26] this was just [14:27] convenient for us to set up multiple [14:29] configurations. [14:31] >> So then once you want to actually start [14:32] listening, what are you doing? [14:34] >> Um so once we want to actually start [14:36] listening, we'll use uh a different VM [14:38] to actually send those commands to the [14:40] uh TV. Um basically we use Mr. Bros's [14:44] RCE. Uh we tell it the TV's IP, we tell [14:48] it the IP of the device we're sending it [14:50] from, [14:51] >> [music] [14:51] >> and then we tell it the command we want [14:53] the TV to run. So in this case we're [14:55] using arecord. Um [14:58] it can record from the TV's built-in [15:00] microphones, and it specifies uh what [15:03] output, what format to use, um sampling [15:06] rate, how many channels, all that sort [15:08] of stuff, and [music] also how long to [15:10] record. [15:11] Um [15:13] So basically we tell the TV, use [15:15] arecord, use the built-in mic to record, [15:19] and then transmit it to the listening [15:20] [music] server. [15:22] Um so then they would all show up here [15:25] as it's uh [15:26] >> Yeah, so let's run one of those. And on [15:28] the top left, we should get a falsified [15:32] message. So, the attacker could set [15:34] this. "Update in progress. Unplugging [15:36] the TV can permanently disable the [15:38] device." Which sounds scary enough that [15:39] someone who doesn't know what they're [15:40] looking at might believe it. Uh, but you [15:43] could also theoretically [15:44] programmatically go in and and home [15:46] screen it or something. And it is still [15:48] recording, right? [15:49] >> Yes, that's correct. [15:50] >> So, it's still recording right now. So, [15:51] you could also send as Wendell showed in [15:53] the past that that home screen button [15:55] command programmatically and just clear [15:56] it immediately. [15:58] Uh, and now it's not even clear that [16:00] this is recording. [16:02] Which [16:03] recently there was an OpenAI incident, [16:05] but we'll talk about that in a separate [16:06] video probably. So, [16:08] uh [16:09] >> There's no toilet paper attached to the [16:11] back of this TV. [16:12] >> Yeah, that's right. This one does not [16:13] have the toilet paper device. And if you [16:15] don't know what that means, then you [16:16] have to check back soon and find out. [16:19] So, that's kind of how it all works. [16:21] Um, we're going to go through all the [16:22] details of the ASUS router vulnerability [16:25] now, and that'll explain how it all [16:29] functions, how Mr. Brot found it, and [16:31] what the fixes are. [16:32] >> Now, ASUS has slowly started rolling out [16:35] patches, but they haven't necessarily [16:37] all been put out there yet. And worst [16:39] yet, ASUS's response is a classic ASUS [16:42] response in that they're not really [16:44] being fully forthcoming with everything. [16:46] For example, [16:48] as far as we can find, ASUS has not [16:50] publicly disclosed a full and complete [16:53] list of which routers are affected by [16:55] this vulnerability, which we have found [16:57] to be irresponsible, but also not [17:00] surprising of ASUS in particular, [17:02] because that makes it hard for users to [17:04] know if they're affected. [17:06] Uh, the good news is we think we have an [17:08] estimation of users who might be [17:10] affected. So, Mr. Brot assumes that uh [17:13] it would be nearly all models that are [17:16] Wi-Fi 6 and newer. So, that's every [17:19] router that ASUS has made that's Wi-Fi 6 [17:21] and newer from roughly 2018 onward, [17:23] which maybe explains why ASUS wouldn't [17:25] list them. [17:27] Doing some basic searching, that's tens [17:29] of millions of devices. We know at least [17:31] 5 million people have downloaded their [17:33] app for the routers on Android Play [17:36] Store, Google Play Store, and upwards of [17:39] 100 million of these routers have been [17:40] sold. But, best sort of conservative [17:43] guess that the vulnerability affects [17:45] maybe 25 or 30 million or so devices. [17:48] But, ASUS didn't put it out there, so [17:50] we're just guessing at it. To summarize, [17:52] this means an attacker could send a [17:54] one-line command to update the router's [17:56] NTP server, replacing the address with [17:59] up to 31 usable characters of code to [18:01] fully open up access or the attacker's [18:04] own server address. The only obstacle [18:07] was that this particular method of [18:08] command injection requires an admin [18:10] authentication token. Fortunately, he [18:13] had no problem getting one. So, here's [18:15] how to hack an ASUS router [18:19] that hasn't been patched yet. [18:20] And only your own. This is only for [18:23] educational and research purposes. [18:25] All right, this is not a literal [18:27] tutorial, okay, YouTube? All right. Step [18:29] one is to download the ASUS router app [18:31] on a mobile device. Even though we never [18:34] would, there must be people out there [18:36] actually doing this. The Google Play [18:38] Store says it's had more than 5 million [18:40] downloads. Step two is to never do that [18:42] again and stop doing that. Don't use [18:45] apps on your phone to connect to your [18:47] router. Just set it up as locally as [18:50] possible, but the real step two is to [18:53] complete OAuth on the router and link an [18:55] account, which is [ __ ] but ASUS [18:57] sells a lot of routers. So, what the [18:59] [ __ ] do we know? Undoubtedly, some of [19:01] these customers are getting tricked into [19:02] thinking account linking is necessary. [19:04] Just to be clear, it's not, and you [19:07] really shouldn't be linking external [19:08] accounts [19:10] to your ASUS router account [19:13] for so many reasons, all of them privacy [19:15] related. When Patrick links the ASUS [19:17] router app to the router, the router [19:19] creates a shared secret that's then [19:21] passed back to the app. Under normal [19:24] circumstances, the secret is a [19:25] 64-character hexadecimal string that's [19:28] used to encode and decode communications [19:30] for validation. Here's how all this [19:32] works using an actual real-world example [19:34] where Patrick used his phone to set up [19:36] the router. So, in this example, Patrick [19:38] takes his phone. It's got the ASUS app [19:39] on it. Patrick uses the ASUS app to [19:42] change the settings in the router. When [19:44] that happens, it sent a device ID that [19:48] identified his phone along with an [19:50] encrypted payload that contained a [19:52] timestamp and the MAC address of the [19:54] router. The router looks up the device [19:56] ID for the phone. It finds the [19:58] associated secret, and then it uses it [20:01] to decrypt that encrypted payload. If [20:05] the router successfully decrypted and [20:07] sees its own MAC address and a timestamp [20:12] that's less than 2 minutes old, it mints [20:14] or creates an authentication token so [20:17] that Patrick can then start making those [20:19] changes. So, this is how the two devices [20:21] communicate with each other, and they [20:23] try to authenticate and make sure this [20:24] is a legitimate user who actually wants [20:27] to change these things and should have [20:28] access. The problem is that on the [20:30] router side, ASUS initializes the secret [20:33] it's about to use for decryption as a [20:34] blank string. access_secret [20:37] equals blank. Then, it checks if it [20:40] knows Patrick's device ID. And then if [20:42] it does, it pulls the secret out of [20:45] storage and overwrites the blank string [20:47] with it. access_secret equals [20:50] entry.secret. If it doesn't have any [20:53] record of Patrick's phone, it never [20:55] overwrites that placeholder blank [20:57] string. And then it tries to decrypt the [20:59] payload anyway with a blank secret. What [21:03] that means is that Mr. Bruh could [21:05] encrypt a valid payload, timestamp and a [21:08] router MAC address, both extremely easy [21:10] to get, with a blank string. Then, pass [21:13] it to the router with some random device [21:15] ID the router has never seen. The router [21:17] can't find a match, so it defaults to [21:20] decrypting the payload with a blank [21:22] string, which works, so it mints the [21:24] authentication token. Pretty easy [21:26] access, but admittedly that leaves one [21:28] big flaw to the exploit. Quote, one [21:30] weakness to this exploit that I did not [21:32] realize at the time is that if no [21:34] devices, aka a mobile device, have been [21:36] paired with the router, this exploit [21:38] does not work and the router will [21:40] respond with a 400 error. End quote. [21:42] That's not security genius on ASUS's [21:44] part. It's just a coincidence that if [21:46] there's an empty list of device IDs, it [21:48] breaks the exploit. What this means is [21:50] that the the good news is if you've [21:53] never associated and paired your router [21:56] with the ASUS app, you can feel [21:58] appropriately smug about your decision [22:01] to not use the app and pair those [22:04] devices. The bad news is that at least 5 [22:07] million people downloaded the app from [22:09] the Android store alone. There are tens [22:11] of millions of devices out there that [22:13] have the potential for some variation of [22:16] this vulnerability, and then there's [22:18] also other versions of the app like on [22:19] iOS, for example, which we have not [22:21] tested. Mr. Bro pointed out that the [22:23] exploit only works when you're on the [22:25] local network and connected to the [22:27] router, but that includes guest [22:29] networks. Quote, you need access to the [22:31] target's network you're hacking. You'd [22:33] need access to the open network like a [22:35] guest network, maybe free Wi-Fi for [22:37] students. Or for a business, maybe [22:39] there's free Wi-Fi in like the ground [22:41] floor, in reception, or whatever. End [22:44] quote. And there are plenty of other [22:45] ways to get on networks, too, from [22:46] intercepting wireless handshakes to [22:48] phishing attacks to laterally moving [22:51] through LG smart TVs or other smart TVs [22:53] that may have vulnerabilities of some [22:55] kind. Quote, for business, it could be [22:58] an attack vector if they left an [22:59] Ethernet wall socket in the cafeteria or [23:02] reception, you need maybe 30 seconds to [23:05] gain persistence on the network via the [23:06] compromised router." End quote. We were [23:08] trying to brainstorm with Mr. Braus some [23:09] of the more devious ways that these [23:11] types of attacks on ASUS routers could [23:13] be used to understand the scope of the [23:15] potential damage. And some examples we [23:17] came up with concretely are that it [23:20] basically gives an attacker the ability [23:21] to create a point of presence on a [23:22] network and have persistent access to [23:24] it. So, they could then try to work [23:27] through any device on the LAN that's [23:29] potentially vulnerable. Maybe you have [23:31] some NAS that has known vulnerabilities [23:32] out there, it's unpatched, you're not [23:34] aware of them. That's a potential access [23:36] point. Maybe you have a smart TV like an [23:38] LG smart TV. That's an example of where [23:40] you could use something like like this [23:43] to move through a network and attack [23:46] another device. And now suddenly you've [23:48] gone from just access to the router, [23:51] where you know some stuff about what [23:53] websites the people on the network are [23:54] visiting, for example, to access to a [23:56] lot worse things, like maybe converting [23:58] the TV into something that can record [24:01] audio and video and send it back to a [24:02] server somewhere. This is that point in [24:04] the middle that can be used to make all [24:06] that easier. Now, as Wendell taught us, [24:08] this is known as exploit chaining, and [24:10] it allows you to use one vulnerable path [24:12] into a network to exploit other [24:14] vulnerabilities that seem less [24:15] problematic because they require network [24:18] access. This also means that you don't [24:20] need physical presence in a facility [24:22] because gaining access to one device via [24:24] an internet attackable vulnerability may [24:27] get you LAN access anyway. So, one of [24:29] the easiest ways to exploit this would [24:31] be to plug into an exposed wall socket [24:34] in a cafeteria or whatever. That's [24:36] physical access, though. Or accessing an [24:39] open or a guest Wi-Fi network. That's [24:42] semi-physical. Maybe you're in front of [24:43] the store, but it's still kind of [24:44] physical. But, you don't necessarily [24:46] have to be there if you chain this with [24:48] other things. Or, for example, you do [24:50] something like a Bluetooth snipe, where [24:52] now [24:53] kind of physical, but you might be 200 m [24:55] away in some of those scenarios. So, [24:57] there's ways to exploit this that get [25:00] kind of increasingly scary, [25:02] uh but the easiest is [25:04] plugging it in or being on the Wi-Fi [25:06] already. Some of our other brainstorming [25:08] turned up, for example, attacking a NAS [25:10] that's on a network where it may not be [25:12] password protected. That's why you [25:13] should always password and username [25:14] protect stuff with like actual usernames [25:16] and passwords that are hard to brute [25:19] force, even if it's never supposed to [25:21] have access to the internet and it only [25:23] lives on your network. Uh So, that would [25:25] be one example of where it could be [25:26] abused. Another one that I want to ask [25:28] Mr. Bra was this, quote, "The other [25:30] option is targeted attacks. So, either [25:32] against businesses or specific people, [25:35] so maybe journalists." End quote. Gee, [25:39] thanks, Mr. Bra. [25:41] >> Thanks, Steve. [25:42] >> Quote, "Once they've got on the network, [25:43] they could put malware on it that phones [25:45] home. That keeps talking to the [25:47] malicious server, so they can basically [25:48] make it do anything. It's effectively [25:50] like a computer that's plugged into the [25:52] Wi-Fi network, so that they could use it [25:54] to listen in. They could use it to see [25:56] what network requests the person is [25:57] doing. So, for a journalist, it could be [25:59] the case that they could see what sites [26:01] they're visiting, which could give [26:03] information into what they're working [26:04] on." End quote. Another way it could be [26:06] used is credibility attacks, for [26:07] example, by trying to damage or [26:09] disparage the credibility of someone [26:11] who's doing that kind of work. It's a [26:12] pretty common way to try and attack the [26:14] credibility of a report, for example. He [26:16] also pointed out that even without [26:18] actively attacking in some way, the [26:21] information that you get from a router [26:24] is still valuable. Like the network [26:26] information, other connected devices, [26:27] where all the other devices and their [26:29] MAC addresses, you can get that from the [26:31] router. Then, those can be mapped to [26:34] vendors. Quote, "So, if you want to [26:35] break into the house of the journalist, [26:37] right? If you've confirmed they're doing [26:39] things you don't like, you can make the [26:41] router, every 10 minutes, check is their [26:44] phone home? Based on the MAC address [26:46] that's likely to be their phone. And [26:48] then, you break into the home as soon as [26:50] they've left." end quote. You know, Mr. [26:53] Bra, I [26:55] I don't like these examples. These [26:58] These examples aren't fun anymore. [27:01] I [27:02] Let's move on. To show how easy this is, [27:05] we ran a proof of concept provided by [27:06] Mr. Bra for reliable demo attack. We [27:09] just used the off bypass to enable SSH [27:12] since quote, although RCE as admin user [27:15] works, it's a bit fiddly to get working. [27:18] You can actually just abuse the [27:19] authentication bypass to enable SSH on [27:21] the router, which gives you the exact [27:23] same control that the exploit does, end [27:25] quote. To do that, we needed a router. [27:27] We picked up the first result on Amazon [27:29] for ASUS routers, which was a cheap [27:31] RT-AX1800S [27:33] V2 with nearly 3,000 reviews and over [27:37] 1,000 of purchases in the last month. [27:39] After being greeted by a EULA that was [27:41] filled with impossible scenarios, namely [27:43] that it says you agree that you already [27:45] agreed to the EULA just by turning the [27:46] device on, we decided to check the US [27:49] government's most directly targeted [27:50] router victim in the router band and see [27:53] if everyone requires agreeing to a EULA. [27:56] We did a factory reset on a cheap [27:58] TP-Link router and didn't see any EULA. [28:00] Also, it politely asked whether we [28:02] wanted automatic updates or not instead [28:04] of telling us they were mandatory. [28:05] Anyway, back to ASUS. After agreeing to [28:07] its EULA, next up was a privacy notice. [28:10] ASUS's privacy notice says you agree to [28:12] share data with ASUS mainly involving [28:15] integrations with Google and Amazon [28:16] voice assistants and IFTTT. If you [28:19] agree, unless you're under 16. Except, [28:22] there's a problem. You can't even get to [28:24] this page without agreeing that you're [28:27] over 16. So, to be clear cuz this is a [28:30] little hard to follow, ASUS put the age [28:33] check in the wrong order from the [28:34] agreement, which means that you can't [28:36] opt out of the data sharing with the [28:39] toggle you're supposed to be able to use [28:40] to opt out of since you can't proceed to [28:42] this page without certifying that you're [28:44] over 16. That must make it easy on ASUS. [28:47] Just share everything anyway. The bottom [28:49] of the statement says, quote, "To [28:51] protect your privacy, please proceed [28:52] with the age check." end quote. Except [28:54] that was on the previous page, not this [28:57] page, and the previous page was required [28:59] to get to this one. So, the age check is [29:01] supposed to be on the page that would [29:03] say if you choose under 16, which anyone [29:05] can click that button. It's not like [29:06] they [ __ ] know for now, then they [29:09] transmit less data or maybe none of it [29:11] at all. It's not really 100% clear, but [29:14] the buttons are on the previous page, [29:16] and you have to agree that you're over [29:18] 16 to get to the page where if you were [29:20] under 16, then they don't share as much [29:23] data, but that button's on the other [29:25] page and you already said you're over. [29:26] So, [29:27] it's Surely this is a mistake. [29:31] Surely they wouldn't do this on purpose [29:35] to maximize the amount of data sharing [29:37] you're agreeing to. The privacy policy I [29:41] I don't think it would be [29:42] Steve's razor, which is, as we all know, [29:45] why attribute to incompetence what could [29:47] easily be described as corporate malice [29:49] to extract and exfiltrate as much data [29:51] as possible for your network. [29:54] A little lengthy is [29:56] going to be a long like Wikipedia entry, [29:58] I guess, but it's it's a well-known [30:00] razor. [30:01] Look it up. The good news is that you [30:03] can proceed by disagreeing. Although the [30:05] dark patterns that ASUS uses in the [30:07] highlighting makes it look otherwise. [30:08] Critically, disagreeing here breaks the [30:10] authentication bypass we're about to [30:12] abuse. So, we had to agree for the test. [30:15] We recommend always clicking disagree. [30:18] It adds an extra layer of protection [30:19] anyway. It's also a good reason to [30:21] actually read these things and click the [30:22] button, or at least try to click the [30:24] button that lets you opt out to make [30:26] sure cuz sometimes they they make it [30:27] look like you can't through dark [30:29] patterns, but then you actually can. So, [30:31] the vulnerability works by abusing the [30:33] ASUS router mobile app to gain access. [30:35] Mr. Brod disclosed issues to ASUS in [30:37] advance for purposes of patching them [30:39] before we publish this [30:41] uh because millions of people would [30:43] otherwise have a ticking time bomb. ASUS [30:45] has still dragged their feet on that. [30:46] We'll talk about that in a minute. But, [30:48] because of that, we can use a secondary [30:50] exploit to bypass the authentication [30:52] requirement. From the attacker's laptop, [30:54] we ran the Windows SSH keygen command to [30:57] generate a public-private key pair. [30:59] Next, we connected that attacker laptop [31:02] to the router's local network. This [31:03] could be done with an open wall socket [31:05] in a business requiring physical access. [31:07] Could be done via open Wi-Fi SSID, guest [31:10] Wi-Fi SSID, or it could be done with [31:12] remote access via exploit chaining from [31:13] a secondary compromised device. That [31:15] gave us everything we needed to run the [31:17] proof-of-concept exploit Python script [31:19] with the newly generated public key. The [31:22] script performs the off bypass, turns [31:24] SSH on in the router settings, and [31:26] inserts the public key into the SSH [31:28] settings. Checking the router UI [31:30] revealed that SSH was now enabled, and [31:33] our public key had been added. Now that [31:34] we've SSH'd in with our private key, we [31:37] had immediate access without a username [31:39] or password challenge by the router. As [31:41] far as the router is concerned, we have [31:43] completely legitimate SSH access. So, [31:46] now we can do whatever we want. If we [31:49] tell the router to reboot, it reboots. [31:51] If we want to tell the router to log [31:52] every single website that users of this [31:54] router access and what time and how long [31:56] they spend on that page, we can do that, [31:58] too. Or maybe if we want to harvest all [32:02] the other devices that are connected to [32:03] the network through that router to try [32:05] and find other vulnerable endpoints, we [32:07] can also do that. It's a pretty open [32:09] book in terms of your options. According [32:11] to Mr. Bruh, SSH access on ASUS routers [32:14] has, quote, "very minimal restrictions [32:15] on what can be done, allowing attackers [32:18] to completely compromise the router if [32:19] they can gain access to it." End quote. [32:21] We still needed the actual username of [32:23] the administrator account on the router, [32:25] which we set to ASUS router during [32:26] setup. Plenty of routers just have the [32:28] username admin or root, and that makes [32:31] them easy to guess, or otherwise it [32:33] could be brute-forced eventually. This [32:34] is It's good general reminder that, [32:36] wherever possible, we think you should [32:38] treat your usernames like your [32:40] passwords. Ideally, you use password [32:42] managers that are not internet connected [32:45] and you generate a username just like [32:47] you generate a password to make it [32:48] harder to brute force if that's the only [32:50] true way into something. Now we get into [32:52] something that's never been ASUS's [32:54] strength, responding to problems. Mr. [32:56] Bros submitted a report to ASUS on June [32:58] 27th and ASUS put out beta firmware a [33:00] couple months later. But the 90-day [33:03] disclosure period ended on September [33:05] 26th without a full rollout from ASUS. [33:08] That's already a failing grade. [33:09] Remember, this affects tens of millions [33:11] of routers [33:13] and the customers who bought them and [33:15] they took more than 90 days to do a full [33:18] rollout for those affected customers. So [33:21] they failed. ASUS requested an extension [33:24] on September 16th and said that, quote, [33:27] "We anticipate that the necessary [33:28] updates and fixes will be ready for [33:30] release between the end of October and [33:32] the middle of November." End quote. So [33:34] they're approaching five to six months. [33:36] We don't know why ASUS chose to drag its [33:38] feet when it had already put out beta [33:40] firmware that, as far as Mr. Bros aware, [33:43] already fixed the issues. It's possible [33:45] that it's because ASUS's Q3 earnings are [33:47] in November. [33:48] So, ideally, you would tell the public [33:51] about [33:52] the massive security concern after [33:55] earnings. [33:56] But I I don't know. This is This is me [33:58] using my like [34:00] my what would Nvidia do brain and ASUS [34:02] might not be quite at that size yet. Uh [34:04] so, we have no idea why they chose to [34:07] wait so long. Granting extensions is [34:09] entirely up to the researcher, many of [34:11] whom follow the Project Zero guidelines, [34:13] which state that, quote, "If they make a [34:14] patch available within 90 days, Project [34:17] Zero will publicly disclose details of [34:19] the vulnerability 30 days after the [34:20] patch has been made available to users." [34:21] End quote. ASUS didn't really do that. [34:24] So Mr. Bros rightfully refused to grant [34:26] the extension. As of this writing, it [34:28] appears that ASUS is rolling out a [34:30] non-beta fix on at least some devices, [34:33] but without further communication to Mr. [34:35] Brot. So, we don't really have a full [34:37] picture. The version for our router is [34:39] dated September 29th. They seem to be [34:41] automatically flashing firmware on [34:44] devices people own, forcing firmware [34:46] updates over the internet is a problem [34:49] in and of itself for different reasons, [34:51] and it could be its own security [34:53] concern, but in the very least, for [34:55] something like a router that a lot of [34:57] people set up and never look at again, [35:00] maybe gives them some extra level of [35:01] protection by forcing that update down, [35:03] um and should at least patch this hole [35:06] and protect the users who don't ever [35:07] check the router or its firmware. The [35:10] real risk, [snorts] as always, is that [35:12] someone else may have already discovered [35:14] this vulnerability, just like Mr. Brot [35:16] discovered it, but unlike him, they may [35:18] have chosen to exploit it. [35:22] That's always the risk. And that could [35:25] be a nation-state attacker on one [35:27] extreme end of examples, although not [35:29] that uncommon at this point. Uh and [35:32] those types of attackers would not [35:34] follow disclosures because they wouldn't [35:36] want people to know about the [35:37] vulnerabilities. So, our best advice is [35:40] to avoid buying ASUS stuff whenever you [35:42] can, based on our past experiences. But, [35:45] uh in the very least, don't make an ASUS [35:47] account, don't log into any non-local [35:50] accounts on your router, but especially [35:52] your ASUS router. So, internet-connected [35:54] accounts to manage your router, we would [35:57] advise against that wherever possible. [35:58] Wherever you can avoid it, if it's for [36:00] your home network, do it all local if [36:02] you can, and don't pair a mobile app [36:04] with your router. It's not necessary. It [36:06] opens up a lot of holes with the promise [36:09] of convenience, but it also opens up a [36:11] lot of privacy concerns, giving them a [36:13] lot more access after you've bought the [36:15] device. This is the future of this [36:16] stuff, remember. [36:18] Anything that can connect to the [36:19] internet, companies are going to want to [36:21] go the smart TV route. This isn't like [36:22] some tin foil hat conspiracy brained [36:25] whatever. [36:26] We're seeing this happen, and it's [36:28] because if a company can sell you a [36:31] router once every Let's take the [36:32] non-technical user, someone not [36:34] typically in our audience. We'll say [36:36] once every 5 years they sell a router. [36:39] That's not really enough for them. They [36:41] want to sell you something every year. [36:43] So, what if they take the data from the [36:46] thing you bought, and they sell that [36:49] to sell you other things from their [36:50] partners. [36:51] That's the direction that [36:53] devices are going in general. So, the [36:56] point of saying that is you should [36:58] really make an active effort to minimize [37:01] how much access to extra data these [37:03] companies have. In the case of a router, [37:06] that means avoiding something like an [37:07] app unless there is some really specific [37:10] reason that you need it that I'm not [37:11] aware of. If there is, more power to [37:13] you, but you know, for us, we would just [37:15] set this up through the local user [37:17] interface, through the browser, not on [37:20] the internet or through an app. So, that [37:22] would be the safer way to do it. Um and [37:24] that's kind of our general guidance. [37:26] But, also change all the default [37:27] usernames and passwords, even if they [37:29] look random, uh because they probably [37:31] aren't, and they probably follow some [37:32] kind of guessable key. It's also a good [37:34] idea to take passwords and security as [37:37] seriously for offline devices as you do [37:39] for online accounts on forums and things [37:42] like that. By which we mean, you know, [37:43] if it's a NAS where you're like, "Well, [37:45] this isn't exposed on the public [37:46] internet. It's just plugged into my [37:48] router. Only I can access it when I'm [37:49] home." [37:50] That should probably be passworded [37:52] immediately, uh because it's not [37:54] necessarily the case if someone can [37:56] tunnel through another device, and um [37:59] and that's not something like camera, [38:00] same thing. If you have a uh CCTV, like [38:02] actual closed circuit system, but it's [38:06] still connected to a router for, you [38:08] know, local use or whatever, that closed [38:10] circuit might turn into an open one real [38:13] quick with some kind of vulnerability. [38:15] And uh chaining those devices or [38:16] Bluetooth sniping attacks is another way [38:18] into a network that people don't think [38:19] about, uh other open end points. So, we [38:21] may follow up with some of the other [38:22] vulnerabilities that Mr. Br uncovered. [38:24] He found a ton of them on routers. The [38:26] Linksys one especially is pretty [38:28] interesting. So, we've got a lot more to [38:29] talk about on routers. Keep an eye on [38:31] his blog as well for more. We'll link [38:33] that below as we've been doing. Mr. Br [38:35] has a coffee page where he accepts [38:38] donations. He does security research for [38:40] the benefit of the public. He worked [38:42] with us on the LG investigation and [38:44] several other pieces that we've [38:45] published. Uh so, we'll link that below [38:48] as well if you want to support him in [38:49] addition to us. And for us, you can go [38:51] to store.gamersnexus.net [38:53] to grab one of our Data Dragon campaign [38:55] backer packs where you can do a [38:57] Kickstarter-style campaign support for [39:00] us. You get a bunch of cool stuff in [39:01] return, physical and digital, and uh [39:05] helps us out directly. Or you can go to [39:06] patreon.com/gamersnexus. [39:08] Thanks for watching. Subscribe for more. [39:10] We'll see you all next time.