Gherkin on Steroids

Or we can just plug that behavior right into the Background. This must also include, in detail, everything needed to run the app. Our target bWAPP is a PHP web server; Maybe you’re running it inside a bee-box virtual machine? Or did you set up the LAMP server yourself? On what operating system? All of this must be in the background, in order to allow reproducibility.

I, for one, am running bWAPP inside a Docker container made by raesene, so let there be a record of that in our attack feature:

All programs and versions are explicitly listed, plus the URL and field where the vulnerability was found. Note how we can refere to external evidence files, too.

Now, the cryptic message in the page might be trying to tell us something. Where can we climb? As it turns out, anywhere. The next hint is in the URL. The page takes a GET parameter page=message.txt. So the file message.txt is a simple text file that contains the words above, and what the page does is display it. What if we change it to another text file? Let’s try /commandi.php.

Notice two things here: first, the PHP code and text commentaries are shown. Hence we could theoretically access the PHP source of any page in this server. Second, the HTML part is actually rendered in the browser, which could lead to a XSS or CSRF attack.

But wait. The server is not just `floating'' in space: it lives inside a `GNU/Linux machine. And 'everything' in such an OS is a file, many of which are plain-text files. One of them is of particular importance: /etc/passwd, which stores information about users. Let us try to display it in this page, setting page=/etc/passwd:

We can document that using Gherkin data tables, in a scenario of its own, due to the importance of the finding:

Now we know how many users there are on the server, and which of them have passwords set. Those are stored in /etc/shadow in the form of hashes, which can be cracked if the passwords are weak. However, the shadow file, unlike the passwd file, is protected:

'Drat!' Well, we’ll find a way around it, sooner or later. Now that we got the hang of it we can try other files. Since we always do the same: change page=message.txt to page=desired-file.txt we can use a Scenario Outline for that, using one column for what we give as input, and the other for the result:

It is only natural to make several tries, some of which fail, some of which succeed. All of them should be reported in the most scientific spirit.

Let us see why passwd could be read and shadow couldn’t. From 'inside' the server let us say

Notice that passwd has three r’s: one for the owner (the user `root), one for the the owner’s group (again, just root) and the final one is for everyone else. However shadow doesn’t have that last r, so it can only be read by root.

While we’re at static detection of problems, let us see what is wrong with that page so we can try to fix it. The source code for the page simply takes the GET parameter page, and displays it.

We can include this exact snippet, numbers and all, between docstrings, while discussing code exploration in our feature file.

Now the main problem with this is that we can pass, as seen before, any file as a GET parameter and it will be shown, i.e., that input should have been validated and cleaned before show_file.

To fix that, a good first step would be to clean strings like .., ./ and ../, which is what you would generally use to ``climb higher Spidy'':

This would block attackers who do not know the file system hierarchy in the server, but still allows us to give absolute paths as the parameter. An even better defense would be that the user should not be allowed to display files outside the current folder:

But this still allows us to display the file with the heroes' passwords. In fact, it would be better just not to allow users to display files at their will.

So far, we’ve documented in Gherkin:

To finish a proper .feature file, we’re missing, well, the feature itself, which is the vulnerability, or rather, the finding and exploitation thereof.

Remember that we can document features and scenarios using 'descriptions'. After the keywords Feature, Scenario, Scenario Outline or Example we can write anything we like, as long as no line starts with a keyword (including comments - you can’t mix descriptions with comments, I learned that the hard way).

It is usual to describe features with the format As <type of user> I want to <do something> In order to <get some result>. We can take advantage of such a structure to document the 'Scenario' and 'Actor' of the vulnerability, the 'Threat' and what records can be 'compromised'. We can also use that space to document anything else we consider to be globally important:

For anything else, use comments. I will include details such as the vulnerability code, CWE, CVE if present, computed metrics such as CVSS scores, etc in comments (#) at the beginning of the file. See the full feature below.

And that is how we propose using this language to document attacks. You may ask: why Gherkin and not just plain text? Because it is line-oriented and has a light structure, we can define a template like the one discussed here, and we can enforce following of the format using the readily available parsers, linters and compilers for the language. We still need to work further on the template definition, so stay tuned.