CVSSv2 rating of new vulnerabilities patched in OpenSSL

On January 8th, 2015, the OpenSSL team published an OpenSSL Security Advisory containing 8 previously unknown vulnerabilities in OpenSSL.

Unfortunately, as with most large software suppliers/vendors nowadays, OpenSSL uses its own severity classification system for vulnerabilities. There are many classifications systems out there, which results in less transparent patching policies and procedures for system administrators and end users. Fortunately NIST publishes the CVSSv2 Severity Base Score of most, if not all vulnerabilities with a CVE entry. This makes it easier to classify.


Two of the eight vulnerabilities (CVE-2014-3571 and CVE-2015-0205) have the OpenSSL vulnerability rating 'moderate'. This corresponds to a CVSSv2 base score of 5.0 (MEDIUM) for CVE-2014-2571 as well as CVE-2015-0205 Both of these vulnerabilities could be exploited for a Denial of Service attack of the OpenSSL service. The remaining six vulnerabilities have a lower rating.

The 1.0.2-chacha and 1.0.1-chacha branches of the ChaCha20 - Poly1305 fork of OpenSSL have been patched for all of the published vulnerabilities.

As always, see for the Windows 32 and 64 bit binaries, and more information.

more ...

MSYS2 - successful successor of MSYS ?


MSYS can best be described as a Bash shell and some GNU tools, which facilitate compiling sources under and for a Windows environment. It's the environment to use when compiling for instance OpenSSL or Emacs on Windows.

MSYS2 is the 'new and improved' version of MSYS.

One of its biggest advantages is better package management. MSYS2 has pacman, a package manager from Arch Linux. Upgrading can finally be done from within the shell session itself, with only a few basic commands.

# download package descriptions from the remote repositories
pacman -Sy
# upgrade MSYS2 core components and the shell itself
pacman --needed -S bash pacman msys2-runtime
# restart MSYS2 if any package needed updating, then update the rest
pacman -Su

This was 'somewhat more difficult' under MSYS.

Another advantage is the Bash version - currently at 4.3.30 versus 3.1.17 on MSYS. Bash 4 means support for functions like associative arrays and fancier redirections:

# redirect stdout and stderr at the same time
command &> output

# same command in Bash 3 syntax
command > output 2>&1

# pipe stdout and stderr at the same time
command |& someothercommand

# same command in Bash 3 syntax
command 2>&1 \| someothercommand

The third big plus is that it's …

more ...

OpenSSL: Fatal SSL alert number 47 (Illegal Parameter)

As a pentester, I regularly test the configuration of SSL servers. For this purpose I use my customized OpenSSL fork which contains a lot more ciphers than the official version, and wrapper scripts (easier than remembering command line options).
Last month I ran into an issue with servers behind a SSL terminator from a well-known network equipment supplier. As soon as the SSL Client Hello offered 128 or more ciphers to the server and the tls1_2 protocol was specified, the handshake was aborted with the following error message
9304:error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:s3_pkt.c:1481:SSL alert number 47 9304:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:636:

The supplier hadn't heard of this bug yet - I suspect that not that many browsers or generic SSL clients offer 128 or more ciphers. A bugreport has been filed.

To facilitate the testing of SSL/TLS handshakes I created a script, which can be found at GitHub. Currently 3 handshake bugs are identified.

Of course you can test for this bug using a version of OpenSSL with enough (128 or more) ciphers, and the command

openssl s_client -connect host:port -tls1_2
more ...

Black Hat Europe 2014 review

Black Hat Europe was held in Amsterdam in October, 2014. The so called Briefings (tech talks) were extremely versatile, ranging from Android pentesting to SCADA hacks. It was difficult to choose which talk to attend - there were around 50 or so, each title vying for your attention ("Hack Your ATM with Friend's Raspberry.Py" [sic], or "Endrun - Secure Digital Communications for Our Modern Dystopia").

Black Hat Europe 2014

I really enjoyed the technical depth of some talks, and it was great to hear someone like Adi Shamir, one of the inventors of the famous RSA algorithm, talk about his current research.

Because of the sheer size I couldn't find one generic takeaway, or see the, or a current bigger picture in information security land. Even all of the vendors' offerings looked similar.

Now that I come to think of it, that actually IS the key takeaway: Genericity.

more ...

Creating and verifying digital signatures of files

Digital signatures can be used to establish the authenticity and integrity of a (binary) file. These signatures can also be used for non-repudiation purposes, but that's usually not the intention when you're distributing or receiving files. (Note: non-repudiation means impossible to reject; to make sure beyond a doubt that the signer's key has been used to create that signature).

The easiest and most secure way of creating and verifying digital signatures is by using PGP. The following commands assume that you have downloaded and configured GPG, the free and complete implementation of the OpenPGP standard.

Create a digital signature of FILENAME

gpg --armor --detach-sig --output FILENAME.sig FILENAME
--armor make sure that the file is ASCII armored (Radix-64 encoded)
--detach-sig create a separate signature file
--output the name of the signature file

Paranoid options

--no-version don't show which software version has been used to create the signature
--comment don't show which software has been used to create the signature

Verify a digital signature

gpg --verify FILENAME.sig

This command assumes that the original file is FILENAME and resides in the same location as the signature file FILENAME.sig. To verify a signature you also need the signer's public key. If …

more ...

Patched openssl SSLv3 downgrade attack (POODLE) with ChaCha20 and Poly1305 support

The OpenSSL team published a security advisory on October 15th 2014, see the OpenSSL site for more information.
In short, SSLv3 using Cipher Block Chaining mode (CBC) has a weakness, which can be exploited using the POODLE attack having CVE entry CVE-2014-3566.
The POODLE attack depends on SSLv3 and tries to downgrade a connection to that specific, really old protocol. This downgrade can be mitigated by using the signaling cipher suite value (SCSV) TLS_FALLBACK_SCSV, which is implemented in the/this latest version of openssl. Please be advised that not only the server, but the client itself also has to support this relatively new method.

All vulnerabilities in the advisory have been patched in the latest versions of OpenSSL 1.0.2-chacha. Moreover, the new binaries/source are aligned with the latest beta release (3).

  • SRTP Memory Leak (CVE-2014-3513)
  • Session Ticket Memory Leak (CVE-2014-3567)
  • SSL 3.0 Fallback protection
  • Build option no-ssl3 is incomplete (CVE-2014-3568)

As always, check for the latest Windows 32 and 64 bit binaries, and for the latest sources.

more ...

Patched vulnerabilities in OpenSSL with ChaCha20 and Poly1305 support

The OpenSSL team published a security advisory on August 6th 2014, see the OpenSSL site for more information. All vulnerabilities in that advisory have been patched in the latest versions of OpenSSL 1.0.1-chacha and 1.0.2-chacha:

  • Information leak in pretty printing functions (CVE-2014-3508)
  • Crash with SRP ciphersuite in Server Hello message (CVE-2014-5139)
  • Race condition in ssl_parse_serverhello_tlsext (CVE-2014-3509)
  • Double Free when processing DTLS packets (CVE-2014-3505)
  • DTLS memory exhaustion (CVE-2014-3506)
  • DTLS memory leak from zero-length fragments (CVE-2014-3507)
  • OpenSSL DTLS anonymous EC(DH) denial of service (CVE-2014-3510)
  • OpenSSL TLS protocol downgrade attack (CVE-2014-3511)
  • SRP buffer overrun (CVE-2014-3512)

As always, check for the latest Windows 32 and 64 bit binaries, and for the latest sources.

more ...

DevOps 2014 Brisbane and security

DevOps is a worldwide phenomenon, which is reflected by the global popularity of its major event, the DevOps Days.

DevOps Days 2014 - Brisbane

I was fortunate enough to attend the DevOps Days 2014 in Brisbane.

The keynote speaker was Sidney Dekker, a Dutchman who has extensive experience on human factors and safety. He argued that a lot of major incidents don't have any precursor events.

You can have a clean track record with regards to security and still suffer a huge incident. Do I agree ? Not completely, but nonetheless thought provoking.

Personally I think that the inverse will always hold true: There is a higher chance on a major security incidents after a number of several minor security incidents. Cluttered desks mean cluttered minds after all.

Some buzzwords and issues that were (frequently) discussed:

  • Docker - A lightweight virtualization platform (can it live up to its sky-high expectations ?)
  • Microservices - Build small, independently deployable services
  • ChaosMonkey
  • Terminate random virtual machines to test (and improve) resiliency
  • Edwards Deming - The godfather of Devops ?

For me the key takeaway was that DevOps doesn't really changes your (level of operational) security. Whether system administrators deploy code built by developers or developers push their own code to an environment - in both …

more ...

Should you disable RC4 in SSL/TLS ?

I'm by no means a crypto expert. Still I'm frequently getting (and answering) questions regarding the use of RC4 in SSL/TLS. Should you disable it? Or keep it enabled?

March 2015 update - A 'new' attack method (Bar Mitsvah Attack) using a previously known RC4 vulnerability was presented, thereby reducing the RC4 security even more.

February 2015 update - RFC 7456 has been published, which effectively prohibits the use of RC4 in TLS.

This document requires that Transport Layer Security (TLS) clients
and servers never negotiate the use of RC4 cipher suites when they
establish connections. This applies to all TLS versions.


Here is my reasoning to disable all ciphersuites using RC4:

  • RC4 is a stream cipher that has been around since 1987. The number and quality of attacks on RC4 (in SSL/TLS) increases. Fact: Attacks on encryption algorithms only get better, they never get worse.
  • A lot of sites still enable RC4 in their ciphers, to support a wide browser base. Fact: Even Internet Explorer on Windows XP supports DES-CBC3-SHA (an alternative to one of the RC4 ciphers)
  • RC4 is one of the few ciphers that is resistant to the BEAST attack …
more ...

git on Windows - location of configuration files

Git is used as distributed version control system for the majority of projects I work on. On Windows I use the official Git for Windows version, as well as the 'native' mingw/MSYS2 git binary when using the MSYS2 shell.

The location of the system and global gitconfig configuration files varies, depending on which environment (native Windows command, Windows shell or MSYS2 shell) you're using, and depending on which binary (Git for Windows versus native git). There's a logic to it, but it can be hard to figure out...

Git version 2 introduced a much easier method of finding where the git configuration files are stored, the --show-origin flag. This parameter tells you exactly where each of the configuration files can be found.

Retrieve the locations (and name value pairs) of all git configuration files:

git config --list --show-origin

Retrieve the location (and name value pairs) of the system git configuration file:

git config --list --system --show-origin

Retrieve the unique locations of all git configuration files:

git config --list --show-origin | awk '{print $1}' | uniq


Regardless from where you use git on Windows, the repository (local) configuration always resides at the same location, in the root directory of your repository …

more ...