Cryptopocalypse Reference Paper
20 Mar 2014 - Javed Samuel
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
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
The paper can be downloaded here.
AWS environment security assessment with Scout2
19 Feb 2014 - Loïc Simon
This article is part of the AWS blog post series
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.
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
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:
iOS certificate pinning code updated for iOS 7
01 Feb 2014 - Alban Diquet
We've updated the iOS certificate pinning code which is part of iSEC's
SSL Conservatory project on Github. This new version brings the
- 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.
Code and instructions are available on the project's Github page.
Announcing the Release of RtspFuzzer
07 Jan 2014 - Michael Lynch
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.
See the Github repository page to download the tool and for quick start instructions:
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.
iOS 7 tool updates
02 Jan 2014 - Alban Diquet
With the availability of the evasi0n7 jailbreak and the subsequent release two
days ago of Cydia Substrate with support for iOS 7 and ARM64, a
full-blown iOS 7 penetration testing environment can now be setup. To this
extent, we've updated our publicly available iOS tools for blackbox
testing in order to add support for iOS 7 and ARM64. We just released the two
The pre-compiled packages for these tools now contain both an armv7 and an
arm64 slice, which means that they will work on 64 bits iOS Apps for devices
with an A7 chip (such as the iPhone 5s and the iPad Air).
Both tools were successfully tested on an iPhone 5s running iOS 7.0.4:
Sandbox changes in iOS 7
While testing Introspy-iOS on iOS 7, I ran into issues with the sandboxd
daemon denying write access to specific files the tool was trying to create.
Interestingly enough, it seems like the Seatbelt profiles deployed on iOS 7
have been updated, compared to iOS 6. Specifically:
- AppStore Apps can no longer write to the root folder of their container
directory, for example
- System Apps can no longer write to /var/mobile/
Because of these changes, I had to modify the locations where Introspy-iOS
stores its files, to the following paths:
- [App Container]/Library/ for AppStore Apps.
- /var/mobile/Library/Preferences/ for System Apps.
It is unclear why the Seatbelt profiles were changed, although the ability to
write to these locations was not actually needed by Apps. More information
regarding the Seatbelt profiles used for various iOS Apps is available on the