injectionsoftwareandsecurityllc / propane Goto Github PK

During a recent dc404 meeting a feature request was made to add in a toggle to disable the click-able link that is displayed with the target machines on the scoreboard.

The use cases that justify this feature are as follows:

• Writing/using a PropAcc that scores a specific service, thus rendering the web-service unnecessary, which makes a link to a web page unnecessary
• Having a web service disabled on purpose (i.e. something like portknocking opens the webservice, or the attacker must configure/start it themselves once they gain access to the box)
• Just piss off your users in general by forcing them to type the IP manually. This also is intended to encourage them to do more recon besides looking at a webpage.

Enhancement was suggested by Matt

This is a minor issue, but Propane and the setup.sh script won't run correctly unless you are in their respective directory at the time of running.

Not a huge issue, but we should definitely add in relative paths for referencing so this isn't a problem.

Implement a new option that will backup the scoreboard data on a set interval and save it to a new "db_backups" directory. This will be an optional configuration that can be turned on via Propane's settings.

It will need two config flags:

• EnableBackups (True/False)
• BackupInterval (time value in seconds)

This will create a "db_backups" directory if enabled, and copy the scoreboard file at a certain interval, then move it to the "db_backups" directory renamed with the timestamp it was copied.

Simple modification to the hello world PropAcc to inform them they have turned PropAcc's on, and should probably delete this PropAcc if they don't want to see this message.

Had an epiphany inspired by something one of the developers who is working on NetKotH (thanks Brimstone!)

In the future how we implement this might change, but there is no reason why the scoring engine can't auto generate the appropriate columns in the template for scored boxes based on the IP addresses supplied by the configuration file.

For example:
I add in the IP "somebox = http://10.0.0.4/index.html" to the config.

Then I have to add placeholder tag into my template.

This makes it a pain if some one would like to dynamically add boxes to the game as they have to update both the config and the template.

The config file should be a one stop solution to dynamically updating the game, an admin shouldn't have to branch out to edit other files unless it's a serious change. This is something we can make simpler by parsing the config file and dynamically updating the template.html based on the machines found in the config.

Currently the easy install script for Propane is adequate, but it could be better.

clamsec suggested we only target the latest versions of Apache to make things as simple as possible for noobs installing on bare bones systems. This sets the reasonable expectation that anyone who has a more complex setup is also capable of figuring out how to configure Propane manually.

Ideas to consider for this:

• Updated script with dependency installer. Supports only the latest and greatest.
• Keep a manual install mode as an option for the install script.
• Use relative Paths in Propane to allow Propane itself to be run from anywhere and be abstracted from the web directory (i.e. you don't have to put everything in /var/www but you can leave it in your home folder if you like or put it in /opt etc...). This will require the setup script to do some more complex things, like generating custom config if a manual path is specified.
• Allow the install script to automatically populate the Target machines based on IPs you give it during installation.

Theses are simply ideas and are not all guaranteed to be implemented, although most of them likely will be.

The goal here is to make install and set up of Propane as painless as possible from scratch. Currently it's not bad, and it's well documented, but it could be better.

We need to implement a service checker in addition to the current web scraper to accurately determine a service status and we also need to display that status on the scoreboard so users can see if a machine is down, or if an opponent simply removed the web page.

This can most likely be done using python sockets, or a simple curl based bash script if necessary. Pure python implementation is best to keep from relying on external dependencies.