Alex Stamos, Tom Ritter and Javed Samuel presented “Preparing for the Cryptopocalypse” at Black Hat 2013, looking into the latest breakthroughs in the academic cryptography community. The original presentation can be downloaded here.

Today we’re releasing a full whitepaper that provides additional detail and extensive references which will explain the latest breakthroughs in the academic cryptography community and look ahead at what practical issues could arise for popular cryptosystems. Specifically, it focuses on the recent major developments in discrete mathematics and their potential ability to undermine our trust in the most basic asymmetric primitives, including RSA.

It explain the basic theories behind RSA and the state-of-the-art in large numbering factoring, and how several recent papers may point the way to massive improvements in this area. It also describes some of the mathematics of Elliptic Curve Cryptography (ECC).

The paper then switches to the practical aspects of the doomsday scenario, and will answer the question “What happens the day after RSA is broken?” It will point out the many obvious and hidden uses of RSA and related algorithms and outline how software engineers and security teams can operate in a post-RSA world. We will also discuss the results of our survey of popular products and software, and point out the ways in which individuals can prepare for the “zombie cryptopocalypse”.

The paper provides a detailed list of references to the latest academic papers related to asymmetric cryptography. In addition, references that discuss the current level of ECC support in various popular products and software are included.

The paper can be downloaded here.

Security engineers at iSEC Partners are regularly involved in projects that require assessing the security of an Amazon Web Services (AWS) environment. Thoroughly reviewing AWS configuration requires poring through dozens to hundreds of pages in the AWS console, depending on the environment’s size. In 2012, iSEC Partners released AWS Scout to help AWS administrators assess their environment’s security posture. Unfortunately, APIs have changed since then, and the tool wasn’t written in a particularly maintainable fashion.

AWS Scout2

iSEC Partners developed a new, more comprehensive, version of AWS Scout in order to address its need for an AWS configuration review tool. AWS Scout2 is an open-source application written in Python that connects to the AWS API and downloads configuration data for the following AWS services:

• Identity and Access Management (IAM)
• Elastic Compute Cloud (EC2)
• Simple Storage Service (S3)

The information gathered is then rendered in an offline HTML report. In addition to AWS configuration, this HTML report displays a number of security risks.

Project page

iSEC Partners is pleased to release AWS Scout2 to the security community. See the Github repository page for full details on how to download and use the tool:

https://github.com/iSECPartners/Scout2

We’ve updated the iOS certificate pinning code which is part of iSEC’s SSL Conservatory project on Github. This new version brings the following changes:

• The Xcode project was re-created as a static library (instead of an iOS App) to facilitate integration. Sample code demonstrating how to use the library has been moved the project’s unit tests.
• A new convenience delegate class for NSURLSession, the HTTP connection framework introduced in iOS 7, was added to the project. Similarly to the existing convenience class for NSURLConnection this class makes it easy to add certificate pinning to connections relying on NSURLSession.

Project page

Code and instructions are available on the project’s Github page.

iSEC Partners is pleased to announce the release of RtspFuzzer, an open-source fuzzer for the real-time streaming protocol (RTSP). RTSP is a text-based protocol that facilitates media streaming. We have been developing this fuzzer over the past several months as we fuzz different media players. Though this protocol doesn’t receive much attention, most popular media players implement it and these implementations have previously been a source of critical security vulnerabilities (including QuickTime and Windows Media Player).

Using RtspFuzzer, we uncovered a new, critical vulnerability in the Live555 library, an open-source implementation of the RTSP protocol that several media players and servers use, including VLC. The vulnerability allowed an attacker to gain remote code execution on a victim’s system if they could induce a VLC user to visit a malicious web page or open a malicious playlist file.

Using RtspFuzzer

See the Github repository page to download the tool and for quick start instructions:

https://github.com/iSECPartners/RtspFuzzer

We created the fuzzer using the Peach fuzzing framework. RtspFuzzer has built-in configurations for Windows binaries of QuickTime, VLC, and openRTSP, but users can easily adjust the configuration and use this fuzzer to test any RTSP client on any Peach-compatible platform.

Advice for developing fuzzers with Peach

Creating RtspFuzzer was a great way to learn to use Peach. Peach is a very powerful framework for fuzzing, but many people shy away from it and instead create one-off fuzzers because they perceive Peach’s learning curve as too steep. Peach does indeed take some time to learn, but it does also save you from rolling your own implementation of a lot of things that Peach does for you, such as integrating with debuggers, mutating your data to match common attack patterns, or logging results in an organized way.

I would like to see Peach succeed because, despite its current problems, Peach makes it easy to write fuzzers that others can reuse and adapt. As more people use Peach, more information about its use will be available and this will reduce the learning curve. The Peach development team is very responsive, and as the user base increases, more people will be able to report bugs and feature suggestions. If you’re thinking of writing a fuzzer with Peach, keep the following tips in mind:

• Treat your Peach pit like a regular program. Keep it under source control and use bug tracking to maintain a list of issues in your fuzzer. Debugging your fuzzer will be a lot easier if you can revert to a known good state.
• Expect bugs in Peach. While Peach has existed since 2004, the latest 3.x version is a complete rewrite of the product in .NET and was first released in May, 2013. Peach works well for the most part, but there are definitely some rough edges, especially as your pits get more complex. You need to account for this in planning if you’re building your fuzzer on a schedule. I recommend building Peach from source so that if you suspect you’ve run into a bug in the framework itself, you can debug it more easily.
• Fuzz early and fuzz often. When I started working on the RTSP fuzzer, my first task was to define the RTSP protocol as precisely as I could in Peach. What I wish I had done first was build a mostly dumb fuzzer that spoke just enough RTSP to do basic fuzzing of a test application such as VLC, then build up from there. Seeing how Peach works and how it interprets the data in pit files is immensely helpful in designing your fuzzer. Look at the kind of data that Peach generates and see if anything is causing iterations to run slowly or to stop.