Safely storing Ansible playbook secrets

see the forest for the trees

More and more organizations use dedicated software to safely handle the creation and management of secrets (for example SSL certificate keys, private variables and passwords). Three 'well known' solutions are Square's Keywhiz, Hashicorp's Vault and crypt in combination with etcd or consul.

As with all security solutions the roll-out can be quite cumbersome. The correct implementation (think key management, think audit trails, think key recovery) of any one of these solutions is difficult. And difficult means that most people won't use it, at least not right away (remember SELinux ?).

There are a number of tools available to encrypt secrets within (Ansible) repositories. One of them for instance is Ansible Vault (look here for a more in-depth review). Although the idea of selectively encrypting data is a good one, text-oriented version control systems like git or Subversion aren't meant to store binary blobs of encrypted data. Moreover you still run the risk of accidentally uploading or sharing unencrypted files. Mitigations like adding filenames of unencrypted secrets to a .gitignore file are error-prone.

How to facilitate developers and system operators to store secrets in a safe place, outside the repositories where Ansible playbooks and configuration files are kept ?

This article describes a …

more ...

OWASP AppSecEU 2015 review - more and more DevOps


This year, the European edition of OWASP AppSec conference was held in Amsterdam, The Netherlands.
One of the things I really like about OWASP conferences is the atmosphere. Usually it consists of a nice blend of IT people from literally all over the world, and this conference didn't disappoint. One of the added values of visiting such a conference is that you hear stories from the trenches from peers and likeminded people. It makes it easier to (try to) spot trends in the security world.

Some observations:

DevOps

I'm a big fan of the DevOps movement, and what it means for security. More cooperation plus more automated testing means more secure systems. Thankfully there were a lot of presentations that focused on how to integrate automated security testing into the continuous deployment pipeline. As the O from OWASP stands for open, mainly open source testing tools were covered, like OWASP ZAP, Arachni and the Gauntlt framework. Some tools still need quite some tweaking to be successful, but the landscape surely is promising.

Dev is running faster than Ops

I'm still under the impression that the DevOps movement is mainly led by developers. The tools that are improving faster are the …

more ...

OpenSSL the Ansible vault... using PBKDF2

OpenSSL the Ansible vault

Ansible is a popular open-source software platform for configuring and managing computers. It helps sysadmins to provision new servers in a reliable and repeatable way, and helps developers who want to push their code as fast as possible. It takes scripts (playbooks) as input, which a lot of people can and do share with each other. The beauty of open source. Playbooks can contain sensitive data like passwords and SSL keys - stuff that you don't want to share, or incidentally upload to GitHub.

Last year Ansible added a tool to its arsenal to easily encrypt structured datafiles (containing sensitive data), called Ansible Vault. You can specify a key or keyfile when running a playbook, which decrypts the data on-the-fly. Encrypted data can still be edited

I love it when people make it easier to use encryption. The easier it becomes, the more people will use it, the safer everybody will be.

Another beauty of open source is that you can inspect the code. And modify it! I wanted to be able to encrypt and decrypt the data where/when you cannot use Ansible vault, by using other tools and languages like OpenSSL and Bash script.

Under the hood Ansible vault …

more ...

Replacing ChaCha20/Poly1305: a new owner

A post back I wrote about the 'design goals' of the 1.0.2-chacha fork of OpenSSL - see https://www.onwebsecurity.com/openssl/the-work-flow-of-the-full-featured-openssl-fork-chacha20poly1305.

A new owner

The ChaCha20 / Poly1305 code in the 1.0.2-chacha fork is originally from the OpenSSL repository, but has since been abandoned there. BoringSSL became its new home, where it's actively being maintained by Google (primarily Adam Langley and David Benjamin). Over time I applied several patches that BoringSSL applied to the ChaCha20 / Poly1305 code, to keep it as up to date as possible.

The issue now is that BoringSSL diverges more and more from the OpenSSL code, which makes it more difficult to maintain (error-prone), and, more important, makes the fork itself diverge too much from OpenSSL.

That's why it's my intention to replace the current ChaCha20 / Poly1305 code from 1.0.2-chacha with more recent attributions that align better with the official OpenSSL code. As far as I understood the official OpenSSL distribution will add ChaCha20 / Poly1305 at some time in the future, which of course would be the best possible outcome. Official support.

Until that time I will do my best to maintain the 1.0.2-chacha branch.

more ...

The workflow of the Full-Featured openssl Fork (ChaCha20/Poly1305) 1.0.2-chacha

As you might know I maintain a fork of OpenSSL at https://github.com/PeterMosmans/openssl The 1.0.2-chacha fork started out of adding the ChaCha20/Poly1305 ciphers to the official fork, and slowly more and more ciphers and features were added.

workflow

The main goals of the fork are

  1. add as much ciphers and (test)functionality as possible
  2. to keep the source as aligned to the original as possible
  3. keep the patches transparent (easily applicable to the original source)
  4. keep the patches maintainable
  5. write as little custom/new code as possible

For 2 (to keep the source as aligned to the original as possible) I try to merge and test the code as often as I can, so that the fork is never too far behind the official repository.

As it was my first idea to start a feature branch I used no-fast forwarding git merges. This kept it transparent when I merged the code, and what the history of the commits was. However, since I'm probably going to maintain this fork besides the official fork I'm going to use fast-forwarding merges from now on (March 2014) whenever possible. I think this will keep the commit history cleaner - see …

more ...

FREAK!

As you probably read somewhere else, and on another place, and another... on March 3rd 2015, another attack on SSL/TLS was published. Following the tradition of BEAST, CRIME, Heartbleed, LUCKY13 and POODLE this one also has a catchy name: FREAK (Factoring RSA Export Keys).

It's a man-in-the-middle attack where a man in the middle can decrypt a SSL/TLS connection between a client and a server.

FREAK

Vulnerable *servers* are servers that accept export-grade ciphers (RSA-EXPORT). Checking whether a server is vulnerable can be done in many ways.

analyze_hosts --ssl HOST

If you see any EXPort ciphers, the server is vulnerable.

cipherscan HOST:443

If you see any EXPort ciphers, the server is vulnerable.

  • Yet another way is by using nmap:
nmap --script ssl-enum-ciphers -p433 HOST

If you see any EXPort ciphers, the server is vulnerable.

You get the idea...

Mitigate this vulnerability server-side by making sure that your server doesn't allow export ciphers in the OpenSSL configuration: add the following expression

!EXP

There are also vulnerable clients...

Clients using OpenSSL are not vulnerable if they were built after CVE-2015-0204 was published.

The …

more ...

Us versus them: CrikeyCon 2015 review

I had the chance to visit CrikeyCon February 2015, which was held in Brisbane

CrikeyCon

It was the second time this event was held, but it already got the looks and feel of a professional organization behind it. The program was really diverse, from social engineering and awkward hugs to iOS runtime hacking, and everything in between.

Takeaway ? Well, it surprised me to hear that there's still a general feeling of us versus them. We the security gods who lay bare all the faults and stupid mistakes the others make.

As a security professional, especially as a pentester, it's your job to find vulnerabilities and weaknesses. It's your job to hunt for other people's mistakes, lack of knowledge, or constrained security budgets. Security falls into the quality assurance department.

This means that most of the time you're telling other people what's wrong with an application. Unfortunately it's not your job to tell them how awesome their web application is, how well it scales, or the nifty features it has.

One of the more challenging issues when for instance presenting a pentest report to a group of developers is to get everybody on board, to get everybody to work together. And if …

more ...

OpenSSL 1.0.2 - now with less whitespace!

On January 22 2015, version 1.0.2 of OpenSSL was released. Besides some new bugfixes and features, the biggest change under the hood was a complete reformatting of the source code. An official coding style document was published, and as a result primarily buckets and lots of tabs and newline characters have been converted into whitespaces.
Personally I hope that this action, which affected the majority of lines(!) of code, will help the project for the best and will make it easier to maintain the project in the future.
One disadvantage of reformatting code for instance however is that it makes it a lot harder to spot differences in code between certain versions, as almost all files have most of their lines changed.
Another disadvantage is that merging additional patches (like the ChaCha20 and Poly1305 ciphers) back into OpenSSL took a great deal of extra time. Unnecessary time, one might say.
The OpenSSL 1.0.2 fork including the ChaCha20 and Poly1305 ciphers has been pushed to the github repo at https://github.com/PeterMosmans/openssl/
As always, you can find compiled Windows 32 and 64 bit binaries at https://www.onwebsecurity.com/cryptography/openssl.

February 2015 update: read …

more ...

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.

CVSSv2

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 https://www.onwebsecurity.com/cryptography/openssl for the Windows 32 and 64 bit binaries, and more information.

more ...

MSYS2 - successful successor of MSYS ?

MSYS2

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 ...