On September 29, Art Manion and I attended the first meeting of the Multistakeholder Process for Cybersecurity Vulnerabilities initiated by the National Telecommunications and Information Administration (NTIA), part of the United States Department of Commerce. There has been ample coverage of the meeting in blogs (e.g., by Dr. Neal Krawetz and by Cris Thomas), mailing lists, and media reports, so I won't attempt to duplicate that information.
During the course of the meeting, I became increasingly aware that no one had actually specified who the "stakeholders" are. The name of the process implies there are more than one, but nowhere in the accompanying materials was there a comprehensive list of who is perceived to hold a stake in this process. In this post, you'll find my take on who those stakeholders are and how the set of players has changed over the past decade.
A few months ago, a widely-publicized set of vulnerabilities called StageFright hit the Android ecosystem. While Google fixed the vulnerabilities in what appears to be a reasonable amount of time, the deployment of those fixes to end-user devices is another story. Many Android devices have a lengthy supply chain, which can make the process of deploying OS updates a slow and uncertain process. In this blog post, I investigate the supply chain of the Android platform and show how it can affect the security of the OS.
There has been a lot of press recently about security in Internet of Things (IoT) devices and other non-traditional computing environments. Many of the most talked about presentations at this year's Black Hat and DefCon events were about hacking IoT devices. At the CERT/CC, we coordinate information about and discover vulnerabilities in various devices, and the number of vulnerabilities keeps growing.
One thing that I've personally been researching is finding vulnerabilities in vehicles. In recent weeks, even non-technical friends and family have asked me about the Jeep vulnerability, the Mobile Devices C4, Rolljam, Tesla, and other recent car-related vulnerabilities. These attacks are novel not because of the technical details, but because of the attack vectors and impact, which differ dramatically from those in traditional IT resources.
A number of us on the Vulnerability Analysis team have been out and about giving talks at various conferences recently. This post provides links to the presentation slides, related blog posts, and the videos where available.
About a year ago, I started looking into Android applications that aren't validating SSL certificates. Users of these applications could be at risk if they fall victim to a man-in-the-middle (MITM) attack. Earlier this year, I also wrote about the risks of MITM attacks on environments that use SSL inspection. Lately I've been checking whether IOS applications are consistently checking SSL certificates, and they appear to be pretty similar to Android applications in that regard.
Some might wonder how easy it might be to fall victim to an MITM attack. The KARMA attack, which was outlined over ten years ago, can cause a client system to unknowingly connect to an attacker's Wi-Fi, allowing an MITM attack. Despite the age of this attack, I've found that it can still be effective on modern platforms.
Every day, we receive reports from various security professionals, researchers, hobbyists, and even software vendors regarding interesting vulnerabilities that they discovered in software. Vulnerability coordination--where we serve as intermediary between researcher and vendor to share information, get vulnerabilities fixed, and get those fixes out in the public eye--is a free service we provide to the world.
Art Manion and I recently submitted comments to the Department of Commerce Bureau of Industry and Security on their proposed rule regarding Wassenaar Arrangement 2013 Plenary Agreements Implementation: Intrusion and Surveillance Items. While our detailed comments are lengthy, we summarize our contributions here.
While investigating a few of the exploits associated with the recent HackingTeam compromise, I realized an aspect of the Windows User Account Control (UAC) that might not be widely known. Microsoft has published documents that indicate that the UAC is not a security boundary. For these or other reasons, some folks may have disabled the UAC on their Windows systems. I will explain in this blog post why disabling the UAC is a bad idea.