Software Engineering Institute | Carnegie Mellon University

SEI Insights

CERT/CC Blog

Vulnerability Insights

This post is co-authored with Sam Perl.

The CERT Division of the Software Engineering Institute (SEI) at Carnegie Mellon University recently released the Cyobstract Python library as an open source tool. You can use it to quickly and efficiently extract artifacts from free text in a single report, from a collection of incident reports, from threat assessment summaries, or any other textual source.

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.

We at CERT are very proud of our collaboration with ACM to create the journal ACM Digital Threats: Research and Practice. One of the goals of the journal is to facilitate the communication between researchers and practitioners in the field of Cybersecurity. We have two columns to aid us in achieving this goal.

A few years ago, I announced the release of CERT Tapioca for MITM Analysis. This virtual machine was created for the purpose of analyzing Android applications to find apps that don't validate SSL certificates. Since the original release of Tapioca, we have received a request to make it easier to use and add some additional features.

The new version of CERT Tapioca improves on the original in multiple ways in that it offers the following:

  • is installable on multiple Linux distributions.
  • contains a GUI.
  • includes the ability to utilize a HOSTAP-compatible WiFi adapter for providing wireless connectivity.
  • can save results from multiple targets tested.
  • can search network traffic for specified strings.

With this blog post I will describe a few use cases of CERT Tapioca.

Back in 2016, a coworker of mine was using CERT BFF, and he asked how he could turn a seemingly exploitable crash in Microsoft Office into a proof-of-concept exploit that runs calc.exe. Given Address Space Layout Randomization (ASLR) on modern Windows platforms, this isn't as easy as it used to be. One strategy to bypass ASLR that is possible in some cases is to leverage a memory leak to disclose memory addresses. Another strategy that is sometimes possible is to brute-force attack the vulnerability to make ASLR irrelevant. In this case, however, the path of least resistance was to simply use Rich Text Format (RTF) content to leverage Object Linking and Embedding (OLE) to load a library that doesn't opt in to using ASLR.

As I started pulling the thread of RTF and OLE, I uncovered a weakness that is much more severe than an ASLR bypass. Continue reading to follow my path of investigation, which leads to crashed Windows systems and stolen passwords.