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 2014 we investigated cache poisoning and found some in some damaging places, like mail-handling domains. It can't be assumed behaviors on the internet continue unchanged, so I wanted to repeat the measurement. I used our same passive DNS data source and the same method, but now four years later, to investigate this question.
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.
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.
While investigating BKS files, the path I went down led me to an interesting discovery: BKS-V1 files will accept any number of passwords to reveal information about potentially sensitive contents!
In preparation for my BSidesSF talk, I've been looking at a lot of key files. One file type that caught my interest is the Bouncy Castle BKS (version 1) file format. Like password-protected PKCS12 and JKS keystore files, BKS keystore files protect their contents from those who do not know the password. That is, a BKS file may contain only public information, such as a certificate. Or it may contain one or more private keys. But you won't know until after you use the password to unlock it.
Update March 21, 2018: We have updated this blog post based on feedback from Thomas Pornin, and confirmation from the Bouncy Castle author. Like JKS files, BKS files do not protect the metadata of their contents by default. The keystore-level password and associated key is only used for integrity checking. By default, private keys are encrypted with the same password as the keystore. These private keys are not affected by the keystore-level weakness outlined in this blog post. That is, even if an unexpected password is accepted by a keystore itself, that same password will not be accepted to decrypt the private key contained within a keystore. Original wording in this blog post that is now understood to be inaccurate has been marked in strikeout notation for transparency.
This post is co-authored by Deana Shick, Eric Hatleback and Leigh Metcalf
Buzzwords are a mainstay in our field, and "cyberterrorism" currently is one of the hottest. We understand that terrorism is an idea, a tactic for actor groups to execute their own operations. Terrorists are known to operate in the physical world, mostly by spreading fear with traditional and non-traditional weaponry. As information security analysts, we also see products where "terrorists" are ranked in terms of sophistication, just like any other cyber threat actor group. But how does the definition of "terrorism" change when adding the complexities of the Internet? What does the term "cyber terrorism" actually mean?
In the first post in this two-part series, we covered five unique challenges that impact insider threat programs and hub analysts. The challenges included lack of adequate training, competing interests, acquiring data, analyzing data, and handling false positives.
As you read the new challenges introduced in this post, ask yourself the same questions: 1) How many of these challenges are ones you are facing today? 2) Are there challenges in this list that lead to an "aha" moment? 3) Are there challenges you are facing that did not make the list? 4) Do you need assistance with combating any of these challenges? Let us know your answers and thoughts via email at firstname.lastname@example.org.