Avoid hard-coding values within attack scripts through parameterization

[Stephanie]

Hi Everyone,

After seeing the Gauntlt presentation at AppSecUSA, I was inspired to test drive Gauntlt between all the delicious Thanksgiving dinners.  

I noticed that I needed to provide the hostname in each attack script. This of course makes sense until you want to target various hosts. As a traditional software vendor, I would target various hosts since different build servers would build different versions of the same product for Linux/Windows. Thus, the same attack script would need to support different builds. This is challenging because the current attack scripts seem to require me to hard code the hostname.

Use Case

Avoid hard-coding values within attack scripts through parameterization

Change Suggestion

In researching whether this functionality exists (does not appear to), I believe I have a change suggestion that can accomplish this:

• Use Cucumber profiles
• Cucumber already supports profiles. The caller for gauntlt just needs to:
• Create a folder called "config" in whatever directory it is in
• Create a file called "cucumber.yaml" in config/
• "cucumber.yaml" contents:
• This is up to the user but I have:
• [root@steph-lnx config]# cat cucumber.yml
• default: TARGET_HOSTNAME=target-machine01.internal.local SSLYZE_PATH=/root/sslyze-0.5_src/sslyze.py
• gauntlt-0.1.2/lib/gauntlt/attack_adapters/support/profile_helper.rb
• Modify add_to_profile function:

      def add_to_profile(k,v)

        puts "Overwriting profile value for #{k}" if gauntlt_profile.has_key?(k)

        #gauntlt_profile[k] = v

        if v =~ /^ENV\['.+'\]$/

          puts eval(v)

          gauntlt_profile[k] = eval(v)

        else

          gauntlt_profile[k] = v

        end

      end

By doing the above, I would be able create an attack file with the following profile to leverage values from cucumber profile if I need to. Otherwise, if I still want to hard code the hostname, the above code change suggestion would still work.

  And the following profile:

    | name     | value      |

    | hostname | ENV['TARGET_HOSTNAME'] |

This also makes transparent the SSLYZE path since it wouldn't need to be defined in the .bash_profile and the sslyze.rb file would automatically be able to retrieve this.

Next Steps

If this makes sense, I'll log an enhancement ticket on github.com. I'd love to attempt to check this in if the approach is good as a means to try and contribute back to the community.

Thanks making gauntlt!

Steph

[Mani Tadayon]

Hi Steph,

Thanks for looking at gauntlt and welcome to the google group. (I am Mani, the main developer for gauntlt.)

I believe you have a very good suggestion--we have been talking about this issue for a while and this solution looks very promising.

Would be very glad to look at a pull request! Let me know if you have any questions.

Best,

Mani

Sent from my iPhone

--