Under the Radar: Opportunities for Social Engineering and the Windows MCE user
Since my current consulting engagement has me a stone's throw away from the lower cased one, we have lunch on a fairly regular basis and the topics are all over the map. His footprint is not the same as mine, but his diversity is amazing. He's been a speech MVP, a compact framework MVP and now a Web Services MVP. Don't sit still, man.
So his last work was some stuff on the Pocket PC and NASA World Wind. He's now onto some coolness with Windows Media Center Edition (MCE).
So at lunch last Thursday, as he tells me of the MCE interface and its extensibility and the coolness that is casey in what he is doing, it occurs to me what Windows MCE appears to be: An invitation to phish. Before we start, let me state my disclaimer: I'm not a qualifed security professional or analyst by any measure. I am not a party with malicious intent. My objective is to raise awareness. The quality of software and the quality of security in use in software improves with awareness. My perspective is that the MCE appears weak and may need to be hardened. In fact, I'm focused on many other activities (and others) at the moment and will admit that I have not attempted to determine if these are viable, hence my use of the term opportunities in the title. I've been having a few ethics debates (with myself) about this as well.
Perhaps its much ado about nothing. Let's review.
I hate to keep cross referencing schneier lest he think that I'm a trying to up my juice, but I find him once again on point (and always many steps ahead) with topics that keep hitting my radar. This post refers to an excellent exposition by these guys. As I have not posted on Social Engineering, phishing and related topics, I'll defer to these links.
So back to Windows MCE and the opportunity. The MCE UI is enlarged and dumbed-down (in a good way) so that the user can sit comfortably on their couch, view the interface on a large television and make their choices using a remote control. The entire front end for MCE is a windows application, apparently written in .Net. For clarity, lets refer to this as the extender. The extender allows for application extensions written either in .Net or HTML. The extender allows for the installation of a "Hosted HTML Application" and exposes an IE browser container (mshtml2) allowing for applications written in DHTML (active content). The extender also allows for the installation of a ".Net Add-In", i.e. an assembly written in .Net to be bound into the same process space as the extender to provide functionality.
To make certain that the user experience is wonderful (and it is a beautiful interface , kudos to the MCE team for this), the UI exposes no standard address bars, no privacy/cookie status and no security status (SSL or otherwise). Additionally, there are premium services just a click away. Just select the service that you'd like and away you go. From the comfort of their couch, users can navigate to content using an interface that provides no indication of the security context.
So if I look at the potential targets, people willing to spend $5000 or more on a TV, spend $50 or more per month on subscription based services and are likely not aware of these type of security risks, they are perfect targets. I speculate that Microsoft has a small number of seats of the MCE product deployed, currently estimated at 1.4 million, (a relatively small number compared to the number of seats of Windows XP Professional or Home), so the opportunity for revenue for parties that perpetrate fraud in the form of phishing or pharming may appear small.
Threats (without threat model classification)
This guy has a link to threat modeling here, Microsoft style (translated: If you are a developer on Microsoft platforms, pay attention to this guy and his team). I present threats for the MCE here purposely without appropriate threat model classification:
Hosted HTML application - DHTML software has long been known for its abilities to run "active script" on the client. MCE supports application installations of DHTML.
No security constraint on the wire - It would appear that anyone can write applications for the MCE extender and distribute them. There appear to be no specifications on the level of security required for any outbound or inbound HTTP (or other tcp/udp) communications in an MCE application. This includes intended usage of communications channels by legitimate content providers as well as malicious usage of communications by anonymous parties.
.Net add-in snooping - The .Net add-ins appear to run in the same process space. I haven't seen any specifications on isolation that prohibits the abuse of the MCE user's personal information, i.e. any MCE credentials or personal information in the MCE extender process, from a malicious add-in (more on this below).
Initial address heist - It appears that the extender uses a centralalized point (an URL) for initialization of the user presentation. It is not clear what protections are on this information. This must be considered a first-class entry point for a phishing or pharming attack again in the presence of an interface that provides no indication of the security context.
Perspectives on Security
A search in the MCE SDK documentation for the word security yields 18 results. A few of the entries are interesting:
There is an actual entry titled "Avoiding Internet Explorer Security Dialog Boxes". Apparently, according to the documentation, "Because these dialog boxes cause unnecessary concern and are difficult to read on a TV screen, they can create an unpleasant experience for the user".
For authors of Media Center Applications there is a page titled "Reviewing your Media Center Application". It states "If the user will need to log in to use your application, does your application provide a secure way to persist the user name or password (or both) on an opt-in basis? (Any kind of typing is burdensome with a remote control, and most users are comfortable with the level of physical security they have provided for their computers at home.)".
In the section entitled "Handling the Limited Access Rights of a Media Center Extender Session", we find the quote "To deliver the optimum level of security, a Media Center Extender session runs in the context of a limited user account. This account is created during the Media Center Extender installation process. It is hidden from the user and cannot be used outside of a Media Center Extender session." This is a practical approach and I believe that this policy is useful for many different threats. But the issue is the location of the credentials of the MCE user. The MCE extender has access to transport those credentials to receive content, i.e. it has read access to that information. The ability to create add-ins and Hosted HTML applications in the same process space provides an opportunity for snooping in the current process. If the credentials are available in any way and there is no Code Access Security (CAS), i.e. the partitioning of security context for items in the runtime environment, the credentials are at risk for snooping. A search for "code access" (with double quotes around the two words) yields "No topics available." NOTE to MCE team: If CAS is there, advertise this fact.
Conclusion: I am not trying to be an alarmist with these issues. With respect (and admiration) for the Security and MCE teams at Microsoft and the issues they face, this just doesn't look right to me.