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.
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?
This post was co-authored by Robert Nord. Technical debt communicates the tradeoff between the short-term benefits of rapid delivery and the long-term value of developing a software system that is easy to evolve, modify, repair, and sustain. Like financial debt,...