This is the first of four notes I am putting up as I work through some research on HbbTV. The earlier piece on exploiting the default browser baked into a current smart TV is the prior art for all of this — it's worth reading first, but it isn't required.
I have spent the past few weekends with a Samsung Q60T on the bench, an SDR, and a stack of ETSI specifications, and the conclusion I have reached is one I would rather not have. The shared-area TV — the meeting-room screen, the reception display, the corporate noticeboard, the open-plan info-radiator — is, in 2021, comfortably the worst-defended computer in most UK offices. Not because it is full of CVEs, although it is. Because it is not classed as a computer at all.
It is classed as AV equipment. It is bought by the facilities team. It is patched by nobody. It is rebooted on Monday morning when someone notices the BBC News feed has frozen, and that is the entirety of its security lifecycle. And on the back of it, behind the wall bracket, there is a small antenna and a small wireless card, both of which the procurement spec did not mention and the buyer did not think about.
The thing I want to write about across these four posts is the standard called HbbTV — Hybrid Broadcast Broadband TV — and what it lets a sufficiently-motivated attacker do to that meeting-room screen. The short version is "rather a lot, with no user click, from across the street". The long version is what follows.
What HbbTV is
HbbTV is an open standard — ETSI TS 102 796 — that bolts an interactive web layer on top of a normal DVB television transmission. It is the thing that puts the BBC's "press red for more" overlay on the screen during the news. It has been live in production since around 2010 and is supported in roughly nine out of ten TVs sold in Europe since 2014. Almost certainly your TV at home speaks it. Almost certainly the TV behind reception in your office speaks it. Almost certainly the one in your boardroom speaks it.
The way it works is fairly elegant when you read the spec, and fairly horrifying when you think about what it implies:
- The broadcaster — at the head end, where playout happens — embeds a small structure called an AIT (Application Information Table) into the MPEG-TS that they are broadcasting.
- The AIT says, in effect: "there is an interactive application available; here is the URL of its HTML entry point; please launch it
AUTOSTARTorPRESENT". - The TV's HbbTV stack parses the AIT, fetches the HTML, hands it to the embedded browser, and runs it.
- The embedded browser is a chromium/WebKit derivative. On most Samsung TVs of this generation it is the Tizen browser. On LG it is webOS's chromium. On Sony it is Android TV's chromium. The implementation varies; the principle does not.
The two words that should give a security person pause in the description above are AUTOSTART and embedded browser. AUTOSTART means the TV launches the application the moment it tunes the channel. There is no user gesture. The "press red" thing is one specific UI flow inside an HbbTV app — there are many others, and AUTOSTART is the default for a great many real-world deployments. The embedded browser is the same browser surface that the chromium project ships, several major versions behind, with no automatic update path, on a device whose vendor patches it twice a year if you are lucky.
What the threat model looks like
The interesting question is who can be the broadcaster. If you stop reading after this list, please at least read this list:
- The state and the licensed broadcasters. They already broadcast. They already have access to a great many TVs in your country. This is out of scope for what I am writing about — it's interesting for other reasons.
- A compromised broadcaster supply chain. If you can edit playout at a licensed broadcaster, every TV in their reception footprint runs the application you embed. There have been a couple of notable incidents in this space already; the 2015 demonstrations of HbbTV-based attacks via real BBC iPlayer integrations are the canonical reference.
- Anyone with a van, a DVB-T modulator, and line of sight to a building. This is the one I want to talk about. TVs do not authenticate the broadcaster. They lock to the strongest legal-looking signal on the multiplex. If your transmitter is closer to a building than the licensed transmitter (which it almost certainly is, since the licensed one is at Crystal Palace or Winter Hill or wherever), the TVs in that building will accept your stream, your AIT, and your application, exactly as if you had been broadcasting BBC One for the last fifty years.
The transmitter does not have to be expensive. A HackRF One is about £280. A USRP B210 is £1500. You can encode and modulate a DVB-T stream on a laptop with tsduck, dvb-t-radio and ffmpeg. You can stitch a custom AIT in maybe 200 lines of Python. The capital cost is well within hobbyist range and well within targeted-attacker range. It is below the cost of a single zero-day on the open market.
The thing the threat model does to my brain
I have done a lot of consulting work in UK organisations over the years where the conversation went something like: "we are worried about phishing, we are worried about supply-chain, we are worried about ransomware". I do not remember a single conversation that went: "we are worried about the meeting-room TVs". Not one. And yet:
- They are running a chromium build that is two-plus years behind.
- They are accepting code over the air from anybody loud enough.
- They are sitting on the corporate LAN, with full DHCP, full DNS, full reachable-from-NAS routing.
- They are also sitting on a second network interface that nobody asked for and nobody disabled — the onboard WiFi card, which can join any open hotspot it can see.
- They are not patched. There is no EDR agent. There is no SIEM rule that knows what a TV is.
The next three posts walk through the actual research, in the order I did it. The plan is:
- Part 2 — the lab rig. What I built on the bench to make this safe to test, including the legal bit (do not actually transmit DVB into open air in the UK — Ofcom will, justifiably, ruin your week).
- Part 3 — the exploitation chain. Getting from the AIT-triggered page load to a shell, including how the public chromium V8 type-confusion bug (CVE-2020-6383) does most of the heavy lifting for you.
- Part 4 — the back door that nobody asks about. What you can do once you have a shell on a TV that has wlan0 enabled and a corporate firewall that nobody told about wlan0.
If you are the person in your organisation who can sign off on procurement specifications, I would suggest reading at least Part 4 before you next buy a TV. The rest is interesting; that one is operationally useful.
A small ask
If you are doing your own work in this space, especially on non-Samsung TVs, I would like to compare notes. The published literature on HbbTV abuse is thinner than it should be — Oren and Keromytis's 2014 USENIX paper From the Aether to the Ethernet is still the most-cited piece, and that work is now seven years old. There is room here for several more bench reports before we collectively have a clear picture. Email is in the footer.
Next post: the lab rig.