{"id":58841,"date":"2024-08-13T18:49:57","date_gmt":"2024-08-13T15:49:57","guid":{"rendered":"https:\/\/packetstormsecurity.com\/files\/180085\/msplayready-revocation.txt"},"modified":"2024-08-13T18:49:57","modified_gmt":"2024-08-13T15:49:57","slug":"microsoft-playready-design-issue","status":"publish","type":"post","link":"https:\/\/afaghhosting.net\/blog\/microsoft-playready-design-issue\/","title":{"rendered":"Microsoft PlayReady Design Issue"},"content":{"rendered":"<p>Hello All,<\/p>\n<p>There is an architectural \/ design issue of PlayReady, which can be<br \/>successfully exploited to gain access to license server by arbitrary<br \/>clients. The problem has its origin in flat certificate namespace \/<br \/>reliance on a single root key in PlayReady along no auth at license<br \/>server end by default (deemed as no bug by Microsoft).<\/p>\n<p>PlayReady client certificates encountered in Windows 10 \/ 11 and<br \/>CANAL+ STB device environments share a common feature. They are all<br \/>digitally signed by the so called WMRMECC256 Key identified by the<br \/>following public component:<\/p>\n<p>C8 B6 AF 16 EE 94 1A AD AA 53 89 B4 AF 2C 10 E3<br \/>56 BE 42 AF 17 5E F3 FA CE 93 25 4E 7B 0B 3D 9B<br \/>98 2B 27 B5 CB 23 41 32 6E 56 AA 85 7D BF D5 C6<br \/>34 CE 2C F9 EA 74 FC A8 F2 AF 59 57 EF EE A5 62<\/p>\n<p>Such an approach implicates the following:<br \/>&#8211; all PlayReady license servers deployed across different content<br \/>providers need to embed private key of WMRMECC256 Key for client<br \/>identity verification purposes. Compromise of one provider can<br \/>potentially impact other providers too,<br \/>&#8211; client identities originating from different environments are to be<br \/>successfully validated by PlayReady license server as long as the<br \/>client identity certificate chain is signed by WMRMECC256 Key.<\/p>\n<p>We exploited the above flat certificate namespace \/ reliance on a<br \/>single root key in PlayReady in the context of CANAL+ environment.<\/p>\n<p>On Aug 12, 2024, the compromised STB certificate used by us to<br \/>demonstrate the possibility of a massive piracy in CANAL+ environment<br \/>has been finally revoked.<\/p>\n<p>Compromised device certificate revocation hasn&#8217;t addressed the core of<br \/>the issue though (no client auth at PlayReady license server end). It<br \/>took us less than an hour to change the code of our POC (PlayReady<br \/>Toolkit) in order to make it work again, successfully obtain licenses<br \/>for content and download arbitrary movies from CANAL+ VOD library, all<br \/>regardless of the certificate revocation.<\/p>\n<p>We imported the identity file generated for Windows 10 PlayReady<br \/>client to it (some arbitrary identity from May 2024) along private<br \/>signing and encryption keys corresponding to it and obtained through<br \/>attacks #3 and #4 (complete client identity compromise).<\/p>\n<p>The end result was a fully functional POC and Windows PlayReady client<br \/>working in what one would assume to be an isolated PlayReady<br \/>environment of CANAL+ set-top-boxes. Microsoft PlayReady license<br \/>server successfully accepted and processed identity certificate chain<br \/>with obfuscated keys and leaf certs specific to Windows environment.<\/p>\n<p>Such an operation of PlayReady license server makes any certificate<br \/>revocations to be rather irrelevant (vide hundreds of millions of<br \/>identities associated with Windows PlayReady clients).<\/p>\n<p>Thank you.<\/p>\n<p>Best Regards,<br \/>Adam Gowdiak<\/p>\n<p>&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-<br \/>Security Explorations &#8211;<br \/>AG Security Research Lab<br \/>https:\/\/security-explorations.com<br \/>&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Hello All, There is an architectural \/ design issue of PlayReady, which can besuccessfully exploited to gain access to license server by arbitraryclients. The problem has its origin in flat certificate namespace \/reliance on a single root key in PlayReady along no auth at licenseserver end by default (deemed as no bug by Microsoft). PlayReady &hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-58841","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/58841","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=58841"}],"version-history":[{"count":0,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/58841\/revisions"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=58841"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=58841"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=58841"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}