© bluebay, 123RF.com

© bluebay, 123RF.com

Throw Down the Gauntlet

Security As Code

Article from ADMIN 47/2018
By
Gauntlt is a sophisticated DevOps tool that can test the security of your continuous integration/continuous delivery pipeline.

Special Thanks: This article was made possible by support from  Linux Professional Institute

When you add features to your software frequently, each iteration needs to be checked meticulously to iron out wrinkles before they cause more headaches further upstream in production. It should go without saying that a critical part of that testing process relates to security, and initiating as many (useful) tests as possible to catch anomalies and potential security holes can only be of great benefit in both the long and the short term.

One of the most satisfying of these security tools is Gauntlt, whose well-constructed ReadMe file provides the following description: “Gauntlt is a ruggedization framework that enables security testing that is usable by devs, ops, and security.” The learning curve is not particularly steep, and once you have written your security requirements as code, you should find the results are easy to read and refactor when changes are necessary.

That Gauntlt website also offers welcome news that 2018 marks “re-launching development efforts and building a community of practice.” Further information also encourages volunteering for the worthwhile cause of improving Gauntlt.

In this article, I will be firing some shots at existing systems to provide some simple security testing examples, and I point you toward a number of vanilla examples later on.

Run The Gauntlt

The powerful Gauntlt’s raison d’etre is to write security as code into your test suites (e.g., the ever-popular Travis CI or GitLab CI), which integrates easily with tools you might normally use manually. These tools might be used for database hacking, penetration testing, open network port probing, or analysis of an SSL/TLS connection configuration. On Gauntlt’s homepage, a brief list of just some of these tools is available, some of which I list in Table 1.

Table 1: Some Useful Security Tools Gauntlt Can Use

Tool Description
curl Alongside the well-known wget tool, the impressive curl is mostly used for pulling down data within scripts and running manual queries online. The tool is simply invaluable for diagnosing issues and is used in all sorts of diverse devices and services worldwide.
Garmr A lesser-known tool is Garmr, but it’s not one to be dismissed. Garmr is from Mozilla and was put together from their secure coding guidelines.
sqlmap If SQL injection and other nefarious SQL activities float your boat, then the mighty sqlmap is probably already known to you. It’s very slick, powerful, and incredibly dangerous.
nmap Many people think Nmap is present in the hacker’s toolkit just for probing ports and testing networks. Little do they know that they can also run some very nasty exploits with the prodigious Nmap. (Consider yourselves warned.)
sslyze SSLyze is one of the examples in this article. It is designed to provide feedback on a target’s SSL/TLS setup. It’s fast, clever, and very useful.

Why Did I Come into This Room?

If you’ve been around the block a few times or used open source security tools before, you’ll see that Gauntlt’s chosen integration tools are unfathomably useful. The Gauntlt website refers to these tools as “attack adaptors.” By adding Gauntlt’s powerful scripting language, your security-as-code can provide a consistent and predictable security posture.

In addition to integrating these flexible tools into your continuous integration/continuous delivery (CI/CD) process, you can automate the monitoring of your systems, dependent on your scenario.

Gauntlt’s scripts come in the form of “attack files,” and each plain text file ends with the .attack extension. Listing 1 shows the general structure.

Listing 1: Attack File Structure

# my.attack
Feature: Description for all scenarios in this file
  Background: ...
    Given ...
  Scenario: Description of this scenario
    When ...
    Then ...
 
  Background: ...
    Given ...
  Scenario: ...
    When ...
    Then ...

The attack files are nice and logical and should be pretty self-explanatory, but a quick word about the Background section before I proceed: You can intertwine some variables in this section. You might replace <hostname> with your website’s DNS www A record (e.g., I might use my website www.devsecops.cc ). You can also list multiple variables. Look carefully because these are present a little later in other examples.

As an aside, you are advised to keep the number of scenarios in a single attack file to a minimum. In the interest of simplicity, you should also make sure that the contents of one file, which might contain potentially varied scenarios, are closely related.

Travel Adaptors

Because Gauntlt simply has too many areas to explore, I’ll look at a few specific examples to get you started on your journey and whet your appetite to explore the tool further.

To begin, I’ll look at the powerful SSLyze, but without using Gauntlt. Before I set up Gauntlt, I’ll run SSLyze on its own to see what to expect from its output. One reason to do this first is that you always need the tools (the attack adaptors) installed before running them through Gauntlt. The following commands will get you started:

$ apt install python-pip
$ pip install --upgrade setuptools
$ pip install --upgrade sslyze

Notice that for my examples I’m using a Debian derivative (Ubuntu 16.04, but via Linux Mint); however, pip commands should work with Red Hat derivatives equally well. I hope simply replacing apt with yum will work, but I haven’t tried it.

To run the excellent SSLyze, execute the command:

$ python -m sslyze --regular www.devsecops.cc:443

As you can see in Listing 2, the tool makes many checks, including for the older and insecure SSLv2 ciphers and other encryption-in-transit issues. (If my memory serves me, SSLv2 was around in the mid-1990s courtesy of Netscape.)

Listing 2: Abbreviated SSLyze Output

SCAN RESULTS FOR WWW.DEVSECOPS.CC:443
 ------------------------------------------------------
 
 * SSLV2 Cipher Suites:
      Server rejected all cipher suites.
 
 * TLSV1_3 Cipher Suites:
      Server rejected all cipher suites.
 
 * Resumption Support:
      With Session IDs:                  OK - Supported (5 successful, 0 failed, 0 errors, 5 total attempts).
      With TLS Tickets:                  OK - Supported
 
 * OpenSSL CCS Injection:
                                         OK - Not vulnerable to OpenSSL CCS injection
 
 * TLSV1_1 Cipher Suites:
       Forward Secrecy                   OK - Supported
       RC4                               OK - Not Supported
   
 * SSLV3 Cipher Suites:
      Server rejected all cipher suites.
 
 * Downgrade Attacks:
       TLS_FALLBACK_SCSV:                OK - Supported
 
 * Deflate Compression:
                                         OK - Compression disabled
 
 * TLSV1_2 Cipher Suites:
       Forward Secrecy                   OK - Supported
       RC4                               OK - Not Supported

Unfortunately, the output of this excellent tool is too comprehensive to display in its entirety, so apologies (to the authors) for splitting up the output. Moving on to Listing 3, you can see which “trusts” are checked. Those with eagle eyes will spot that my website uses Let’s Encrypt certificates.

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus