Hello All, A couple of weeks ago, Platform NC+ [1], one of the major digital SAT TV providers in Poland issued an official message [2] to subscribers about the policy of content security. Among other things, the following statements were included in it: "Platform nc+ as a technology leader in the market and an operator with a rich program offer conducts many activities aimed at providing a high security of the offered content". "In order to fulfill the requirements of content providers, platform nc+ is obliged to completely secure the Multiroom service". We decided to have a look underneath the implementation of the security of Multiroom service and found out that the above claims hardly reflect the reality. More specifically we discovered that a shared AES key used to secure the Multiroom service of NC+ operator can be discovered. This is due to the following: 1) MPEG broadcast stream containing SSU image for certain NC+ devices is not encrypted (software upgrade image can be downloaded regardless of the presence of a Conax card in the STB device - there is no need to decrypt MPEG stream with the use of Control Words). 2) software upgrade image for ITI-5800S Multiroom client device, although encrypted can be easily decrypted (in 2012, we published information about plaintext SW upgrade keys being broadcasted along the upgrade image [3][4], this issue hasn't been addressed), 3) ITI-5800s upgrade file embeds Compressed ROMFS image containing root filesystem for ITI-5800S device, this image can be extracted under Linux OS, 4) the binary of a main STB application embeds a custom Java File System (ROMFS), which can be also successfully extracted / unpacked, 5) ROMFS filesystem contains obfuscated Java classes of which one includes a hardcoded initialization vector and AES key used to secure Multiroom service of NC+ operator (this key is used to encrypt / decrypt a file carrying authorization data for a client device). Full report along a Proof of Concept code illustrating our findings can be downloaded from the following locations: http://www.security-explorations.com/materials/se-2011-01-33.pdf http://www.security-explorations.com/materials/se-2011-01-33.zip We usually follow our Disclosure Policy [5] (modified recently to reflect SRP research [6]) when it comes to reporting and disclosing vulnerabilities. We do not when experiencing issues like that [7]: "Vendors not responding to our email messages for 7+ days: - Advanced Digital Broadcast (set-top-box vendor) awaiting response to the message from 11-Jan-2012 - ITI Neovision (SAT TV operator) awaiting response to the message from 01-Feb-2012". Thank you. -- Best Regards, Adam Gowdiak --------------------------------------------- Security Explorations http://www.security-explorations.com "We bring security research to a new level" --------------------------------------------- References: [1] NC+ Platform http://ncplus.pl/ [2] Polityka Zabezpieczenia Treści http://ncplus.pl/zabezpieczenie-tresci [3] SE-2011-01 Issues #5-16,#25-32 (Advanced Digital Broadcast), http://www.security-explorations.com/materials/se-2011-01-adb.pdf [4] "Security threats in the world of digital satellite television” http://www.security-explorations.com/materials/se-2011-01-hitb1.pdf [5] Security Explorations - Disclosure Policy http://www.security-explorations.com/en/disclosure-policy.html [6] Security Research Program http://www.security-explorations.com/en/srp.html [7] SE-2011-01 Vendors status http://www.security-explorations.com/en/SE-2011-01-status.html
