« Previous 1 2 3 4 Next »
Throw Down the Gauntlet
Security As Code
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 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 “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. 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.
« Previous 1 2 3 4 Next »