Hi, this is Jose Morales, researcher in the CERT:CES team. In early 2012, a backdoor Trojan malware named Flame was discovered in the wild. When fully deployed, Flame proved very hard for malware researchers to analyze. In December of that year, Wired magazine reported that before Flame had been unleashed, samples of the malware had been lurking, undiscovered, in repositories for at least two years. As Wired also reported, this was not an isolated event.
Hi, Timur Snoke here with a description of maps I've developed that use Border Gateway Protocol routing tables to show the evolution of public-facing autonomous system numbers.
Organizations that route public internet protocol (IP) addresses receive autonomous system numbers (ASNs), which uniquely identify networks on the Internet. To coordinate traffic between ASNs, the Border Gateway Protocol (BGP) advertises available routing paths that network traffic could take to access other IP addresses. BGP tables select and advertise the best routes for network traffic. Consequently, BGP data often provide better insight into traffic ownership than the physical or the logical layer. This blog post describes maps that I have developed that use BGP routing tables to represent the evolution of public-facing ASNs.
Hi, it's Timur Snoke of the CERT NetSA group, posting on behalf of Deana Shick and Angela Horneman. It's not every day that 9.6 terabytes of data is released into the public domain for further research. The Internet Census 2012 project scanned the entire IPv4 address space using the Nmap Scripting Engine(NSE) between March and December of 2012. The engineer of this data set (identity unknown) saved and released the collected data in early 2013. The data is broken down into seven types of scan results: ICMP ping, reverse DNS, service probes, host probes, syncscan queries, TCP/IP fingerprints, and traceroute.
Hi, this is Will Dormann of the CERT Vulnerability Analysis team. One of the responsibilities of a vulnerability analyst is to investigate the attack vectors for potential vulnerabilities. If there isn't an attack vector, then a bug is just a bug, right? In this post, I will describe a few interesting cases that I've been involved with.
Hi folks, it's Will Dormann. A few months ago I published a blog entry called Don't Sign that Applet! that outlined some concerns with Oracle's guidance that all Java applets should be signed. The problem is that with Java versions prior to 7u25, there is nothing that prevents a signed applet from being repurposed by an attacker to execute with full privileges. As it turns out, Java 7u25 introduced features to prevent a Java applet from being repurposed. Thanks to CERT/CC blog reader Rob Whelan for pointing this out! There are some potential pitfalls when using this feature, however.
Hi folks. It's Will Dormann from the CERT Vulnerability Analysis team. Today we're announcing the release of updates to both of our fuzzing tools, the CERT Basic Fuzzing Framework (BFF) version 2.7 and the CERT Failure Observation Engine (FOE) version 2.1. In this blog entry I will describe some of the major changes with these tools.
According to DevSecOps: Early, Everywhere, at Scale, a survey published by Sonatype, "Mature DevOps organizations are able to perform automated security analysis on each phase (design, develop, test) more often than non-DevOps organizations." Since DevOps enables strong collaboration and automation of the process and enforces traceability, mature DevOps organizations are more likely to perform automated security analysis than non DevOps organizations. My previous blog post, Microcosm: A Secure DevOps Pipeline as Code, helped address the problem that most organizations do not have a complete deployment pipeline in place (and are therefore not considered to be DevOps mature) by automating penetration tests of software applications and generating HTML reports as part of the build process through the Jenkins CI service. In this follow-up blog post, I explore the use of a service evolution of Microcosm as a simple one-stop shop for anyone interested in learning how to implement a DevSecOps pipeline.