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.
During the Watergate hearings, Senator Howard Baker asked John Dean a now-famous question: "My primary thesis is still: What did the president know, and when did he know it?" If you understand why that question was important, you have some sense as to why I am very concerned that "zero-day exploit capability" appears as an operative phrase in the Department of Commerce Bureau of Industry and Security (BIS) proposed rules to implement the Wassenaar Arrangement 2013 Plenary Agreements regarding Intrusion and Surveillance Items.
In my last post, I presented how to create a YAF application label signature rule that corresponds to a text-based Snort-type rule. In this post, I discuss methods for using Analysis Pipeline to provide context to those signatures.
The context for signatures can take many forms. Some context can be derived from the individual flows that match the signatures. This information is easy to obtain from either SiLK or another traffic analysis tool--just look at the traffic that matched the signature. Analysis Pipeline lets you easily do more. I will discuss three simple options, but Analysis Pipeline can be used for more complex analyses.
By David Svoboda Senior Member of the Technical Staff CERT Division
Whether Java is more secure than C is a simple question to ask, but a hard question to answer well. When we began writing the SEI CERT Oracle Coding Standard for Java, we thought that Java would require fewer secure coding rules than the SEI CERT C Coding Standard because Java was designed with security in mind. We naively assumed that a more secure language would need fewer rules than a less secure one. However, Java has 168 coding rules compared to just 116 for C. Why? Was our (admittedly simplistic) assumption completely spurious? Or, are there problems with our C or Java rules? Or, are Java programs, on average, just as susceptible to vulnerabilities as C programs? In this post, I attempt to analyze our CERT rules for both C and Java to determine if they indeed refute the conventional wisdom that Java is more secure than C.