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://ift.tt/2skT34f http://ift.tt/2Epzooc 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.
Source: Gmail -> IFTTT-> Blogger
No comments:
Post a Comment