iSEC Research Labs

Tool Release: You'll Never (Ever) Take Me Alive!

09 May 2014 - Tom Ritter

A year ago, we released You'll Never Take Me Alive — a tool that helps protects Full Disk Encrypted Windows computers from DMA and cold boot attacks.

YoNTMA runs as a background service and begins monitoring your computer any time the screen is locked. If the power cable or Ethernet cable is disconnected from the system while your laptop is locked, YoNTMA will immediately hibernate the machine to ensure that the disk encryption keys do not remain in RAM. This ensures that if a thief walks off with your powered-on laptop, your encrypted data stays protected.

It's been a great tool that I've used happily, but when I got a new Macintosh, I ran up against Issue #3 — there's no Mac version! Until today. We're releasing a new version of YoNTMA for Macs. The source is still open and the .dmg can be downloaded from Github. Due to some tricks of how Macintoshes hibernate, you'll need to provide your administrative password (just once) to update the power management settings to enable a secure hibernation. Or, if you're paranoid, you can run those commands yourself and re-launch the app — don't worry, you won't hurt my feelings.

The only issue we're aware of is a lingering issue in OS 10.9; that said, while I've experienced this issue in the past, I'm currently running 10.9 and haven't had issues in the past few months. Feel free to test and if you have problems, open an issue on Github.

DIBF Tool Suite

16 Apr 2014 - Nicolas Guigo

Introducing iSEC Partners' Windows driver testing suite. The source, binaries and example output are available at under the GPLv2 license. Currently three tools are included:

DIBF - Dynamic IOCTL Brute-Forcer (and fuzzers)

This tool encompasses two distinct features. It guesses the IOCTL values that the driver accepts, and also their valid size limitations, and stores the results are in a file for future reuse. The second feature is composed of 3 dumb fuzzers: a pure random fuzzer, a sliding DWORD fuzzer and a fully asynchronous fuzzer. Any combination of the 3 fuzzers can be run sequentially, and numerous options can be set from the command line, including time limits for each fuzzer run, the maximum number of failed requests in a row (indicating further fuzzing might be pointless due to lack permission for instance) and the verbosity level. Any fuzzer run can be stopped cleanly with ctrl-c, and upon completion cumulative statistics are displayed. See the README and usage for more information on all options and features.

IOSEND - sending single IOCTL to a driver

This is a tool intended for proofing vulnerabilities and is meant to be used in conjunction with a hex editor. Once the request of interest has been crafted in the editor, this utility will send it to the driver using command line parameters. The response gets sent to stdout.

IOCODE - simple encoding/decoding utility for IO codes

This very simple tool encodes and decodes windows IOCTL control codes. It provides a user-friendly way to deal with IO encoding of device types, function number, transfer method and access type.

SSLyze v 0.9 released - Heartbleed edition

16 Apr 2014 - Alban Diquet

A new version of SSLyze is now available. SSLyze is a Python tool that can analyze the SSL configuration of a server by connecting to it. This version brings a few improvements and bug fixes as well as a new plugin to identify servers affected by the Heartbleed vulnerability.

Heartbleed Testing

To implement the Heartbleed check, I used the methodology described on Mozilla's blog, which has the advantage of not directly exploiting the vulnerability unlike most Hearbleed-testing scripts that have been released. Mozilla's technique does not retrieve memory from the server, thereby avoiding server crashes or sensitive data exposure.

Additionally, SSLyze's implementation uses the tool's existing networking code, allowing Heartbleed testing against multiple servers at the same time and on StartTLS services including XMPP, LDAP, SMTP, FTP and POP. Also, just like all of SSLyze's checks, Heartbleed tests can be tunneled through an HTTPS proxy.

Full Changelog

  • Experimental support for Heartbleed detection; see --heartbleed. Heartbleed detection has also been added to --regular scans
  • Capped the maximum number of concurrent connections to around 30 per server in order to avoid DOSing the scanned servers. Scans are slightly slower but a lot less aggressive, resulting in better scan results with less timeout and connection errors
  • Support for Basic Authentication when tunneling scans through an HTTPS proxy with --https_tunnel
  • Bug fixes for IPv6 and XMPP support
  • Updated OpenSSL to 1.0.1g
  • Updated the Apple, Microsoft, Mozilla and Java trust stores
  • Cleaned up the text output of PluginOpenSSLCipherSuites


SSLyze requires Python 2.7; the supported platforms are Windows 7 32/64 bits, Linux 32/64 bits and OS X 64 bits. Pre-compiled packages available in the release section of the project's page on GitHub.

iSEC Completes TrueCrypt Audit

14 Apr 2014 - Tom Ritter

Is TrueCrypt Audited Yet? Yes, in part!

For nearly a decade, tens of millions of users have been trusting the open source encryption software, TrueCrypt. Over the past year, however, revelations about the capabilities of intelligence agencies have shaken the very foundations of much of the cryptography community. Owing to its popularity and widespread use, TrueCrypt has come under intense scrutiny with many openly asking if TrueCrypt could be trusted to function as claimed.

The Open Crypto Audit Project (OCAP) is a new organization that is attempting to answer questions of importance to the cryptography community, including those about trust in TrueCrypt. OCAP began a grassroots campaign to raise money to answer fundamental questions about TrueCrypt. These fundamental goals were identified. First, resolve questions regarding TrueCrypt's license status. Second, produce repeatable, deterministic builds. And third, conduct a public analysis of the code.

As announced in December 2013, iSEC Partners (iSEC) worked with the Open Crypto Audit Project on the final goal -- conducting a methodical analysis of TrueCrypt through code review and penetration testing.

In January 2014, iSEC Partners kicked off the engagement to audit the following portions of TrueCrypt: the Windows kernel code, the bootloader, the filesystem driver, and the areas around this code. The scope was kept narrowly focused to avoid stretching resources too thin and ensure that the review conducted was thorough and robust.

The audit conducted by iSEC is now complete and the findings are available now. iSEC did not identify any issues considered "high severity" during this testing. iSEC found no evidence of backdoors or intentional flaws. Several weaknesses and common kernel vulnerabilities were identified, including kernel pointer disclosure, but none of them appeared to present immediate exploitation vectors. All identified findings appeared accidental. Overall, iSEC does think changes can be made to improve code quality and maintainability, and that the build process should be updated to rely on recent tools with trustworthy provenance. In sum, while TrueCrypt does not have the most polished programming style, there is nothing immediately dangerous to report.

Given TrueCrypt's popularity, the entire security industry benefits from knowing more about the software and how secure it is. iSEC believes in the importance of working with organizations like the Open Crypto Audit Project and the Open Technology Fund to support the development and security of technologies that promote trust and security throughout the Internet.

iSEC hopes both the TrueCrypt project and the larger Open Crypto Audit Project continue their work. The security community will benefit from continued review, new versions, and reproducible builds of the software in the future.

iSEC is grateful and honored to have been a part of the TrueCrypt security audit and feels that the analysis was both productive and important. iSEC's full report is now available to the public. It is unchanged save two items: correcting a few late-stage misspellings and redaction of the consultants' phone numbers. It is available at

Heartbleed (CVE-2014-0160) Advisory

10 Apr 2014 - Andy Grant, Justin Engler, Aaron Grattafiori

News of a major widespread vulnerability discovered by Neel Mehta came out Monday, April 7 2014. This vulnerability allows a network attacker to read memory from programs that use certain versions of the OpenSSL library, e.g. web servers, VPN clients and servers, or mail transfer agents. Vulnerable data could include:

  • Certificate private keys and session keys
  • Any credentials (such as username and password) sent to the endpoint. Session cookies and similar bearer tokens are also affected.
  • The actual data that was intended to be protected (such as financial data or account numbers).
  • Other potentially sensitive data in memory (such as memory addresses and their contents) that could allow an attacker to more easily exploit other vulnerabilities.

What is vulnerable?

This vulnerability has been in source code since December 2011 and in production OpenSSL versions since March 2012:

  • OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
  • OpenSSL 1.0.1g is NOT vulnerable
  • OpenSSL 1.0.0 branch is NOT vulnerable
  • OpenSSL 0.9.8 branch is NOT vulnerable

Even if you are not directly using OpenSSL, a large number of software packages incorporate OpenSSL and are vulnerable.

Who is vulnerable?

Anyone who has run any product using OpenSSL versions 1.0.1 through 1.0.1f even if you are currently patched is vulnerable. Even if your organization does not run OpenSSL directly, it is a part of many other software packages. Additionally, appliances such as SSL/TLS terminators, mail servers, instant messaging servers, and VPN concentrators could be running OpenSSL internally. This is not limited to servers either. Any client software that uses a vulnerable version of OpenSSL can be attacked. Our investigations into the exploitability of client software are ongoing.

What action should be taken on the server side?

iSEC recommends performing the following discovery and remediation steps:

Discovery: determine if you are running a vulnerable version of OpenSSL

Fix the base issue going forward:

  • Update to OpenSSL 1.0.1g or newer, or recompile the current version in use with heartbeats disabled via the –DOPENSSL_NO_HEARTBEATS option.
  • Restart all processes that load the OpenSSL library

Mitigate potential damage:

  • Generate and deploy a new public and private key pair.
  • Revoke old, assumed-compromised private key. Check with the issuing Certificate Authority (CA) for details on how to revoke a compromised private key. You may wish to request a new certificate even before your production systems are fully patched so that it has a chance to age before deployment to minimize problems for clients with incorrect clocks.
  • Invalidate all active sessions
  • Encourage users to change passwords
  • Elevate fraud detection procedures
  • Notify vendors of any vulnerable commercial software or appliances.

Due to the severity of the impacts of an exploit, if a service cannot be upgraded or recompiled, consider removing the service from the internet until fixes can be applied.

What action should be taken with client software?

Currently the most active threat is to servers, however a network attacker could use this bug to attack clients as well. Depending on the functionality and use of your product, client-side attacks could steal sensitive session data, user credentials, and private keys for client certificates.

Discovery: determine if clients/products are using a vulnerable version of OpenSSL.

Fix the base issue going forward:

  • Update to OpenSSL 1.0.1g or newer, or recompile with heartbeats disabled
  • Release update/patch

Mitigate potential damage:

  • Notify customers
  • Invalidate sessions
  • Encourage users to change passwords
  • Encourage users to generate new public and private key pair for client-side certificates
  • Revoke old, assumed-compromised private key of client-side certificates
  • Elevate fraud detection procedures

What action should be taken by users/consumers?

Almost every person uses some service or software that is vulnerable to Heartbleed. Although much of the burden resides on software vendors to provide prompt patches, there are a few things you can do to minimize your personal risk:

  • Log out of services
  • Determine if services are currently vulnerable by looking for an advisory or checking one of the available lists, such as Mashable's list
  • Avoid using vulnerable services and notify them that they are vulnerable
  • After services are no longer vulnerable, change passwords

More information