FAQ

Frequently Asked Questions

What is commix?

commix (short for [comm]and [i]njection e[x]ploiter) is an open source penetration testing tool that automates the detection and exploitation of OS command injection flaws. Given a request and a place in it to test, it works out whether the target runs what it is given, by which of four techniques the answer comes back, and - once one holds - what can be done through it: a command, a shell, a file read or written, the Windows registry, the target's users and their password hashes.

How do I run commix?

python commix.py -h

The full list of options, with the ones a first run rarely needs:

python commix.py -hh

commix needs Python 3.7 or newer and nothing else - every third-party library it uses is bundled, which is why a clone is all it takes. --dependencies says which of the optional ones this host has.

Can I integrate commix with a tool I am developing?

Yes. commix is released under the terms of the GPLv3, so a derivative work may be distributed under the rights that licence already grants.

There are three ways to drive it from somewhere else, in rising order of how much you want back:

• The exit status - 0 where an injection point was found, 2 where everything asked for was tested and nothing was, 1 where the run ended on an error. See what a run exits with.
• --report-json - the findings, the payload behind each, a curl command that reproduces it, and what went wrong where something did. Written as the run goes, so it can be read while it is still going.
• The REST API - commixapi.py, where each scan is a task that is created, given options, started, and then read.

How can I report a bug or ask for a feature?

Bug reports are welcome. Please open one on the issue tracker.

What makes a report easy to act on:

• Check the open and closed issues first, and the user's manual.
• Reproduce it against the latest development version, since it may already be fixed.
• Say what you ran and what happened. The whole command line, with -v4 where the problem is in what was sent, and the traceback where there is one.
• A target anyone can reach is worth more than any description of one. The commix-testbed is the easiest way to show a case that does not depend on a site only you can see.
• For a feature, say what it would let you do that nothing else does.

Can I contribute?

Yes. Clone the repository, read the user's manual, and send a pull request.

A few things that make a patch land faster:

• One logical change per patch.
• Match the surrounding code: two spaces of indentation, lower_snake_case names, UPPERCASE constants, and comments that say why rather than what.
• Run the suite - python -m unittest discover -s tests -t . - and the smoke test, python commix.py --smoke-test. The build runs both.
• A new technique, module or tamper script has a place it is registered rather than wired in by hand; module development describes one of them.
• Leave src/thirdparty/ alone.

Can you hack a site for me?

No. commix is for testing systems you own or have been given permission to test, and attacking anything else is a crime wherever you are reading this. The project does not take such requests and nobody on it will answer one.

Where can I practise?

The commix-testbed is the official one: a container of deliberately vulnerable pages, one per shape of the bug, which every example in this wiki is captured against. The command injection testbeds page lists the others worth knowing.

Another tool gets through to the target, but commix does not

Then use that tool.

Tools are written around different assumptions about what a target does with the value it is given, so the sets of targets they handle overlap without matching, and neither side of that is a fault in the other. What matters is that the target gets tested; which program reached it is secondary.

Which tamper script gets past this WAF?

There is no answer that holds for every one of them, because what a filter blocks is what decides it. What does work is reading what the target refused and picking the script that stops producing it: a filter that eats whitespace wants space2ifs or one of its neighbours, one that blocks a command's name wants ansiquote or phpnoletters, one that blocks $() wants backticks.

--list-tampers prints every script with what it does to a payload, the tamper script table records what each is compatible with, and filters bypass examples works through real ones. Several can be combined, and are applied in a fixed order.

Does commix test anything besides OS command injection?

Yes. --eval tests the string a target evaluates as code, in PHP, Python, Ruby, JavaScript or PowerShell, over the same techniques. The shellshock module tests CGI targets for CVE-2014-6271, and --jwt reads a JSON Web Token the request carries and tests its kid as an injection point of its own.

Nothing comes back from the page. Is it still worth testing?

Yes - that is what three of the four techniques are for. Only the results-based one needs the command's output to reach the response. The boolean-based one reads which of two pages came back, the time-based one reads the delay, and the file-based one reads a file the command wrote. Where none of those can answer, --oob has the target reach a server you control instead. The techniques page describes what each one asks of a target.

What is the difference between --technique and --type?

A technique is how execution is proven, and a type is what the finding is reported as. --type="c" is the same as --technique="r", and --type="b" the same as --technique="btf" - so the second is the shorter way to ask for a whole class when the distinction that matters is whether output is visible at all. The two cannot be given together.

Why does the file-based technique ask me where to write?

Because it has to put a file somewhere the web server will serve back, and the document root is not something a target usually says. Where commix cannot work it out, it offers the common locations, a list of your own, a file of them, or a brute-force search - see the document root menu. --web-root skips the question when you already know it.

How do I make a blind run faster?

• --threads - the bytes of an answer are independent of one another, so several can be read at once. Nothing here is timed, so overlapping requests cost the answer nothing.
• --charset - telling it the output is a number, or a hash, is a question not asked for every byte.
• --maxlen - a shorter ceiling is a shorter search for the length itself.
• A technique that is not going to answer is time spent either way: --technique names the ones to try.

Does commix work against Windows targets?

Yes. The payloads, the shells and the enumeration all have a cmd.exe and PowerShell side, and --os forces the choice where detection cannot make it. Windows and Unix-like targets at a glance sets out how the two differ.

Does a second run have to start over?

No. What a run learns about a target is kept in a session file of its own, so a second run against the same target answers at once rather than testing again - resume from stored session data. --flush-session discards it and --ignore-session leaves it in place and ignores it.

How do I get a shell?

--os-shell is the one to reach for first: a prompt on the target over whichever technique confirmed. Beyond it there are the built-in reverse_tcp and bind_tcp handlers, upgradeable to a full PTY with --pty, and the Metasploit ones. Getting shells works through each.

Where can I find older versions?

Every release is tagged in the repository. --version says which one is running, and --update brings a clone up to the latest development version.