MRT is a file format used in BGP; in particular, it is used when the router writes updates into a log file. There are many programs out there for parsing these files, but I'm going to talk about a new program created at the CERT Division for searching the files. The program is designed to find routes that affect a given set of CIDR blocks, and to do it quickly.
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.
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.
Hi all, this is Jonathan Spring with my colleagues Leigh Metcalf and Rhiannon Weaver. We've been studying the dynamics of the Internet blacklist ecosystem for a few years now and the 2015 Verizon Data Breach Investigations Report has corroborated our general results. We get a lot of questions about which list is which and if we can recommend a list. We won't reveal which is which generally, but in this blog post we'll make a small exception (with permission of course) in a case study to update the results.
Ever want to use a Snort-like rule with SiLK or Analysis Pipeline to find text within packets? Timur Snoke and I were recently discussing how we could do this and realized that while neither SiLK nor Analysis Pipeline themselves do packet inspection, YAF can be used to create an application label that can be used in analyses in both SiLK and Pipeline (field 29, application). This post outlines the steps required and provides an example.
Hi. This is Angela Horneman of the SEI's Situational Awareness team. I've generated service specific network flows to use as baseline examples for network analysis and am sharing them since others may find them helpful.
We have been looking at implementing Network Profiling in Analysis Pipeline to automatically generate lists of active servers and to alert when new IPs start acting as servers. As part of this initiative, we started looking at alternatives to using flags in the identification process, since not all collection methods capture TCP flag data. In this process, I looked for example network flows for verified services.
Recently, SuperFish and PrivDog have received some attention because of the risks that they both introduced to customers because of implementation flaws. Looking closer into these types of applications with my trusty CERT Tapioca VM at hand, I've come to realize a few things.
In this blog post, I will explain
The capabilities of SSL and TLS are not well understood by many.
SSL inspection is much more widespread than I suspected.
Many applications that perform SSL inspection have flaws that put users at increased risk.
Even if SSL inspection were performed at least as well as the browsers do, the risk introduced to users is not zero.
Hi folks, Allen Householder here. In my previous post, I introduced our recent work in surveying vulnerability discovery for emerging networked systems (ENS). In this post, I continue with our findings from this effort and look at the differences between ENS and traditional computing in the context of vulnerability discovery, analysis, and disclosure.
Hello, this is Kate Meeuf of the SEI's Situational Awareness team. I'm pleased to announce the publication of the new technical report, Regional Use of Social Networking Tools, which explores regional preferences for social networking tools.
The federal government is facing a shortage of cybersecurity professionals that puts our national security at risk, according to recent research. "As cyber attacks have increased and there is increased awareness of vulnerabilities, there is more demand for the professionals...