Security as Code

Throw Down the Gauntlet

And Now, for My Next Trick

Next, I'll use another tweaked Gauntlt example from the GitHub page and combine a couple of useful techniques together into one attack file. I'll use the prodigious nmap scanning tool to check whether a host is up, and, using the results of that test, I'll then output the results to an XML file and parse it to see whether I should be concerned about the test failing or succeeding. If you want to tweak this example yourself further, the majority of this code [9] can be found on the GitHub page. My tiny changes are displayed in Listing 6.

Listing 6

The Nmap Attack Adaptor

@slow @announce
Feature: nmap attacks for www.devsecops.cc
  Background:
    Given "nmap" is installed
    And the following profile:
      | name           | value            |
      | hostname       | www.devsecops.cc |
      | tcp_ping_ports | 80,443           |
  Scenario: Using tcp syn ping scan and the nmap fast flag
    When I launch an "nmap" attack with:
      """
      nmap -F -PS<tcp_ping_ports> <hostname> -oX shiny.xml
      """
    Then the file "shiny.xml" should contain XML:
      | css                                                         |
      | ports port[protocol="tcp"][portid="80"] state[state="open"] |
      | ports port[protocol="tcp"][portid="443"] state[state="open"] |

In the attack file, you can see the modus operandi for this attack. A word to the wise in the form of another reminder: You need to install the nmap package if it's not already on your system. It is usually as simple as the commands that follow (for Debian and Red Hat derivatives, respectively):

$ apt install nmap
$ yum install nmap

If you are not familiar with nmap, the command in Listing 6 uses -F for fast mode, -P for a "protocol ping" (or port status test), and -S to attempt to spoof the IP address, so the targeted machine doesn't know where the probe is coming from.

To run the nmap attack, enter

$ gauntlt nmap.attack

and check Listing 7 for some familiar nmap output. This time, however, it has bells on. I hope you agree that the output is simple to read, and the attack has achieved its objective; namely, confirmation that the HTTP and HTTPS ports are live.

Listing 7

Nmap Output with Extra Logic

@slow @announce
Feature: nmap attacks for www.devsecops.cc
  Background:                  # nmap.attack:3
    Given "nmap" is installed  # gauntlt-1.0.13/lib/gauntlt/attack_adapters/nmap.rb:4
    And the following profile: # gauntlt-1.0.13/lib/gauntlt/attack_adapters/gauntlt.rb:9
      | name           | value            |
      | hostname       | www.devsecops.cc |
      | tcp_ping_ports | 80,443           |
  Scenario: Using tcp syn ping scan and the nmap fast flag # nmap.attack:10
$ cd /root/gt
$ nmap -F -PS80,443 www.devsecops.cc -oX shiny.xml
    When I launch an "nmap" attack with:                   # gauntlt-1.0.13/lib/gauntlt/attack_adapters/nmap.rb:8
      """
      nmap -F -PS<tcp_ping_ports> <hostname> -oX shiny.xml
      """
The use of "prep_for_fs_check" is deprecated. It will be removed soon.
Starting Nmap 7.01 ( https://nmap.org ) at 2018-06-11 16:08 BST
Nmap scan report for www.devsecops.cc (138.68.149.181)
Host is up (0.11s latency).
rDNS record for 138.68.149.181: echo2.net
Not shown: 91 closed ports
PORT      STATE    SERVICE
7/tcp     filtered echo
26/tcp    filtered rsftp
79/tcp    filtered finger
80/tcp    open     http
443/tcp   open     https
3000/tcp  filtered ppp
3986/tcp  filtered mapper-ws_ethd
8443/tcp  filtered https-alt
49152/tcp filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 1.95 seconds
The use of "prep_for_fs_check" is deprecated. It will be removed soon.
    Then the file "shiny.xml" should contain XML:          # gauntlt-1.0.13/lib/gauntlt/attack_adapters/gauntlt.rb:15
      | css                                                          |
      | ports port[protocol="tcp"][portid="80"] state[state="open"]  |
      | ports port[protocol="tcp"][portid="443"] state[state="open"] |
1 scenario (1 passed)
4 steps (4 passed)
0m2.023s

The next thing to look for after that confirmation, however, is whether a file called shiny.xml exists somewhere. Low and behold, from within my current working directory it does indeed exist at tmp/aruba/shiny.xml. Listing 8 shows a snippet of the XML to prove its format is valid.

Listing 8

It Walks, Quacks, and Looks Like XML

<port protocol="tcp" portid="7"><state state="filtered" reason="no-response" reason_ttl="0"/><service name="echo" method="table" conf="3"/></port>
<port protocol="tcp" portid="26"><state state="filtered" reason="no-response" reason_ttl="0"/><service name="rsftp" method="table" conf="3"/></port>
<port protocol="tcp" portid="79"><state state="filtered" reason="no-response" reason_ttl="0"/><service name="finger" method="table" conf="3"/></port>
<port protocol="tcp" portid="80"><state state="open" reason="syn-ack" reason_ttl="52"/><service name="http" method="table" conf="3"/></port>
<port protocol="tcp" portid="443"><state state="open" reason="syn-ack" reason_ttl="52"/><service name="https" method="table" conf="3"/></port>
<port protocol="tcp" portid="3000"><state state="filtered" reason="no-response" reason_ttl="0"/><service name="ppp" method="table" conf="3"/></port>
<port protocol="tcp" portid="3986"><state state="filtered" reason="no-response" reason_ttl="0"/>   <service name="mapper-ws_ethd" method="table" conf="3"/></port>
<port protocol="tcp" portid="8443"><state state="filtered" reason="no-response" reason_ttl="0"/>   <service name="https-alt" method="table" conf="3"/></port>
<port protocol="tcp" portid="49152"><state state="filtered" reason="no-response" reason_ttl="0"/>   <service name="unknown" method="table" conf="3"/></port>

Helicopter Heads

If these two attack file examples have piqued your interest, visit the Gauntlt GitHub page for other various examples [10]. At this point, you can probably see how powerful of a combination these attack files could be. No doubt you could make a serious dent in your testing requirements with Gauntlt, and I'm exceedingly glad that it's being developed actively again. Long may it continue, and if you can assist with the development efforts, then please do.

It Ends Here

As DevOps continues to gain traction, a growing number of compliance, security, and sanity testing tools have appeared for CI/CD pipelines. With a little forethought, however, Gauntlt ticks so many boxes that, to my mind, it should be the first CI/CD tool to try.

Spread the word, and keep the interest in Gauntlt alive and kicking.

Infos

Gauntlt: http://gauntlt.org/
ReadMe file: https://github.com/gauntlt/gauntlt/blob/master/README.md
Travis CI: https://travis-ci.org/
GitLab CI: https://about.gitlab.com/features/gitlab-ci-cd/
Secure Coding Guidlines: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines
Attack files: https://github.com/gauntlt/gauntlt/blob/master/README.md#attack-adapters
Trust Stores Observatory: https://github.com/nabla-c0d3/trust_stores_observatory
New page: https://github.com/nabla-c0d3/sslyze
Code for Nmap attack adaptor: https://github.com/gauntlt/gauntlt/blob/master/examples/nmap/tcp_ping_ports.attack
Gauntlt GitHub examples: https://github.com/gauntlt/gauntlt/tree/master/examples

The Author

Chris Binnie's latest book, Linux Server Security: Hack and Defend , shows how hackers launch sophisticated attacks to compromise servers, steal data, and crack complex passwords, so you can learn how to defend against such attacks. In the book, he also shows you how to make your servers invisible, perform penetration testing, and mitigate unwelcome attacks. You can find out more about DevOps, DevSecOps, Containers, and Linux security on his website: https://www.devsecops.cc.

« Previous 1 2 3