Category: Vulnerability Mitigation

Approximately eight years ago (September 2010), Microsoft released EMET (Enhanced Mitigation Experience Toolkit) 2.0. In the world of software defenders, there was much rejoicing. EMET allows users to not be at the mercy of their software vendors when it comes to opting in to vulnerability exploit mitigations.

As we fast-forward to November 2016, Microsoft released a blog post called Moving Beyond EMET, which announced the end-of-life (EOL) date of EMET and explained why Windows 10 makes EMET unnecessary. I took issue with this blog post, primarily because, at that time, Windows 10 could NOT provide opt-in, application-specific protections like EMET can.

Microsoft dropped support for EMET on July 31, 2018. Let's see what has changed and what we can do to protect ourselves on Windows systems today.

As a vulnerability analyst at the CERT Coordination Center, I am interested not only in software vulnerabilities themselves, but also exploits and exploit mitigations. Working in this field, it doesn't take too long to realize that there will never be an end to software vulnerabilities. That is to say, software defects are not going away. For this reason, software exploit mitigations are usually much more valuable than individual software fixes. Being able to mitigate entire classes of software vulnerabilities is a powerful capability. One of the reasons why we strongly promote mitigation tools like EMET or Windows Defender Exploit Guard, which is the replacement for EMET on the Windows 10 platform, is because exploit mitigation protections are not limited to the specific vulnerability du jour.

While looking at a recent exploit for VLC on Windows, I noticed some unexpected behaviors. In this blog post, I will describe how my journey led me to the discovery of several flaws that put users of many applications at unnecessary risk. VLC isn't the only victim here.

In this blog post, I discuss the impact of insecure software updates as well as several related topics, including mistakes made by software vendors in their update mechanisms, how to verify the security of a software update, and how vendors can implement secure software updating mechanisms.

While investigating the fixes for the recent Microsoft Office OLE vulnerability, I encountered a situation that led me to believe that Office 2016 was not properly patched. However, after further investigation, I realized that the update process of Microsoft Update has changed. If you are not aware of these changes, you may end up with a Microsoft Office installation that is missing security updates. With the goal of preventing others from making similar mistakes as I have, I outline in this blog post how the way Microsoft Office receives updates has changed.

Recently, Microsoft published a blog post called Moving Beyond EMET that appears to make two main points: (1) Microsoft EMET will no longer support EMET after July 31, 2018, and (2) Windows 10 provides protections that make EMET unnecessary. In this blog post, I explain why Windows 10 does not provide the additional protections that EMET does and why EMET is still an important tool to help prevent exploitation of vulnerabilities.

The Google Identity Platform is a system that allows you to sign in to applications and other services by using your Google account. Google Sign-In is one such method for providing your identity to the Google Identity Platform. Google Sign-In is available for Android applications and iOS applications, as well as for websites and other devices.

Users of Google Sign-In find that it integrates well with the Android platform, but iOS users (iPhone, iPad, etc.) do not have the same experience. The user experience when logging in to a Google account on an iOS application is not only more tedious than the Android experience, but it also conditions users to engage in behaviors that put their Google accounts at risk!

Application whitelisting is a useful defense against users running unapproved applications. Whether you're dealing with a malicious executable file that slips through email defenses, or you have a user that is attempting to run an application that your organization has not approved for use, application whitelisting can help prevent those activities from succeeding.

Some enterprises may deploy application whitelisting with the idea that it prevents malicious code from executing. But not all malicious code arrives in the form of a single executable application file. Many configurations of application whitelisting do not prevent malicious code from executing, though. In this blog post I explain how this is possible.

Recently, there has been a resurgence of malware that is spread via Microsoft Word macro capabilities. In 1999, CERT actually published an advisory about the Melissa virus, which leveraged macros to spread. We even published an FAQ about the Melissa virus that suggests to disable macros in Microsoft Office products.

Why is everything old new again? Reliability of the exploit is one reason, but the user interface of Microsoft Office is also to blame.

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.

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.

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.

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

  1. The capabilities of SSL and TLS are not well understood by many.
  2. SSL inspection is much more widespread than I suspected.
  3. Many applications that perform SSL inspection have flaws that put users at increased risk.
  4. Even if SSL inspection were performed at least as well as the browsers do, the risk introduced to users is not zero.

Hi, it's Allen. In addition to building fuzzers to find vulnerabilities (and thinking about adding some concurrency features to BFF in the process), I've been doing some work in the area of cybersecurity information sharing and the ways it can succeed or fail. In both my vulnerability discovery and cybersecurity information sharing work, I've found that I often learn the most by examining the failures -- in part because the successes are often just cases that could have failed, but didn't.

In this blog post I focus on an area of cybersecurity information sharing that's considerably less well understood than incident reporting, malware analysis, or indicator sharing. I'm talking about coordinated vulnerability disclosure and why it's hard.

Hi, it's Will. We are all probably annoyed by software that bundles other applications that we didn't ask for. You want a specific application, but depending on what the application is, where you downloaded it from, and how carefully you paid attention to the installation process, you could have some extra goodies that came along for the ride. You might have components referred to as adware, foistware, scareware, potentially unwanted programs (PUPs), or worse. Sure, these may be annoyances, but there's an even more important security aspect to these types of applications: attack surface.

Hey, it's Will. I was recently working on a proof of concept (PoC) exploit using nothing but the CERT BFF on Linux. Most of my experience with writing a PoC has been on Windows, so I figured it would be wise to expand to different platforms. However, once I got to the point of controlling the instruction pointer, I was surprised to discover that there was really nothing standing in the way of achieving code execution.

The WebReady and Data Loss Prevention (DLP) features in Microsoft Exchange greatly increase the attack surface of an Exchange server. Specifically, Exchange running on Windows Server 2003 is particularly easy to exploit.

It's public knowledge that Microsoft Exchange uses Oracle Outside In. WebReady, which was introduced with Exchange 2007, provides document previews through the use of the Oracle Outside In library. Outside In can decode over 500 different file formats and has a history of multiple vulnerabilities. See CERT vulnerability notes VU#520721, VU#103425, VU#738961, and VU#118913.

Slowloris is a denial-of-service (DoS) tool that targets web servers. We have some suggestions about mitigation techniques and workarounds to protect your server. However, use caution if you implement any of these suggestions because they will likely have some unintended side effects.