iSEC Research Labs

DIBF Tool Suite

16 Apr 2014 - Nicolas Guigo

Introducing iSEC Partners' Windows driver testing suite. The source, binaries and example output are available at https://github.com/iSECPartners/DIBF 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

Download

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 https://opencryptoaudit.org/reports.

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

Introducing iSEC's Smart Password Evaluation Service

01 Apr 2014 - Michael Lynch

Note: This post was written as an April Fool's Day joke; we will (fortunately) not be offering this service. We hope you enjoyed this bit of humor about the current challenges in the security industry.

The Trouble with Password Strength Meters

One of the main downfalls of using passwords as an authentication mechanism is that it's extremely difficult to convince users to select strong passwords. In the past few years, several web applications have begun to use "password strength meters" which show the user how resistant their chosen password is to brute force attempts.

eBay's password strength meter

A recent paper by Carnavalet and Mannan showed that, while these meters are somewhat effective at increasing the strength of passwords, they are easily fooled. Many meters rate passwords like "password$1" as strong despite the fact that modern attack tools could easily crack such a password.

iSEC's Service

What's the problem here? Is your attacker a little JavaScript snippet with a pretty colored bar? No! Your attacker is a constantly evolving and adaptable human adversary. What's the only way to defeat a human? With a human!

With this in mind, iSEC is proud to announce iSEC Smart Password Evaluation Service, the first and only password evaluator that uses live humans to judge the strength of passwords.

How it Works

Let's say you register a new account with XYZ Bank. They're an iSEC customer who wisely uses our Smart Password Evaluation Service. When you enter your desired password into the XYZ Bank application, their web server makes a backend request to our service. This request includes all of your registration information and your attempted password in plaintext. (Note that this backend request takes place over leased lines. This escapes the dangers of crossing Internet infrastructure and allows us to maintain the fastest service possible by securely omitting encryption.)

Design Diagram

iSEC's trained specialists then evaluate the password and determine whether it meets the length and complexity requirements of XYZ Bank. We also use our human intelligence to look for weaknesses that a computer could never determine, such as:

  • Is your password derived from your personal information?
  • Is your password some obfuscated form of the word "password" that a computer cannot detect (e.g. "p4ssW0rd")
  • Does your password contain the letter "z"? (All passwords should contain one or more "z" because it's always the last character that hackers attempt in brute force attacks.)

Examples

Let's take a look at some real life examples, taken from customers in our pilot program.

Financial Services Application

Our first example comes to us from one of our financial services customers. Accounts on this site control millions of dollars worth of assets, so the security of these accounts is paramount. No one other than the end user should ever have access to the user's personal details, especially not their password, so it's critical that we evaluate the password thoroughly.

Example 1 - Weak Password

The user's password here demonstrates a very common password weakness: it is largely based on the customer's personal information. If the attacker compromised the full user database (which is quite common in large data breaches), they could combine dictionary words with the user's personal information to discover the password.

In this case, the user's password is simply the word "Go" followed by their favorite sports team and year of birth. iSEC's analyst therefore rejected this password as weak and the user was required to select a new, stronger password.

Message Board Application

We want to protect all the Internet's users, not just those of large financial services clients. There are many smaller sites in our pilot program as well. Our next example comes to us from a customer who runs a free message board where users can discuss young adult fiction:

Example 2 - Strong Password

This site collects fewer personal details during registration so our analysts have less to work with. What we can see is that the English word "Team" appears in the password, which is bad. However, the remainder of the password are 12 random, nonsense characters that no attacker could guess, so we mark the password as very strong.

Scaling

We expect that very soon, every major web site on the Internet will use iSEC Smart Password Evaluation Service to solve their password woes. How do we scale our solution to address millions of requests per second? After all, each request requires manual interaction from a trained specialist.

Well, like most difficult problems in security, the answer is: the cloud.

Specifically Amazon's Mechanical Turk service. For those not familiar, Amazon's Mechanical Turk allows companies to hire temporary workers for "micro-tasks": short jobs that can be completed within a few minutes.

Of course, evaluating passwords is very sensitive, skilled work so we can't allow any anonymous user on the Internet to do it. Before any Mechanical Turk worker can begin evaluating passwords, they must complete a rigorous examination that challenges their security acumen as well as their personal integrity.

Analyst Qualification Test

We're only a few months into our pilot program, but we have already found thousands of Mechanical Turk workers who are extremely enthusiastic about their work. Every day they tell us, "Please send us more passwords!" At first we worried that our workers would shy away from the responsibility of evaluating passwords for high value accounts such as banks or stock exchanges, but those types of accounts are proving to be our most popular. Some of our workers have even offered to pay us for the opportunity to protect these accounts! Talk about passionate employees!

Conclusion

After software developers and security professionals have spent decades of struggling to get password authentication right, iSEC is very proud to have solved passwords once and for all.

We will be expanding our Smart Password Evaluation Service pilot program very soon. If you run a web site and are interested in joining the next wave of our pilot program, stay tuned to this blog over the next few weeks for instructions on how to start using our service on your site.

Note: This post was written as an April Fool's Day joke; we will (fortunately) not be offering this service. We hope you enjoyed this bit of humor about the current challenges in the security industry.