Server-Side Exploitation

Web applications often do more than just serve static pages: a photo-sharing site might resize an uploaded picture before displaying it, while a reporting service might turn submitted data into a PDF before sending it back to the user.

Established command-line tools already handle jobs like these, so reusing their tested implementations saves the application's developers from writing and maintaining their own image converters or document renderers. One convenient way to call them is to shell out: the application builds a command with the desired options, perhaps including a filename or some text from the request, then asks a shell to run it and collects the result.

This connection between web requests and local programs goes back to the early web: the Common Gateway Interface (CGI), in use since 1993, let a web server pass a request to an external program and use its output to answer the client. These programs had access to local files and tools, so mistakes in how they handled request data could let an attacker read private files or execute commands on the server.

The shell parses the complete command string, so if the application trusts user input without proper quoting or validation, characters from the request can become shell syntax. A ;, for example, can separate the intended command from another one, giving you control over what the server executes when you were only supposed to supply text or a filename! This is command injection, which lets an attacker run injected commands with the server process's permissions.

In this challenge, the application uses figlet to turn your text into an ASCII banner, and your goal is to exploit its command injection vulnerability to read /flag. Read /challenge/server to see how it runs the command.

A banner should be allowed to contain punctuation without launching another command! The server now puts your text inside single quotes, making ; part of an argument and preventing $ from introducing an expansion, so both can reach figlet as ordinary text.

Your input still becomes part of the same string as the quotes the developer supplied, and the shell parses everything together. To get beyond a harmless banner, you'll have to account for the complete command, including the quotes around your input, instead of treating your input as a command on its own.

Try a ; or a quote now, and the server rejects your request before starting a shell. The developer has traded quoted input for a blocklist, a list of characters the application refuses to accept. The list includes backslashes and many other characters used in shell syntax too, leaving you with far fewer ways to express a command.

That's a lot of forbidden punctuation, but the shell still receives a command containing your unquoted text and interprets whatever the filter lets through. You now have to satisfy two programs: pass the application's character check while still making the shell do more than render a banner.

Now the server has stopped showing its work! It still runs a command for each accepted request, but it throws away the command's output and sends back the same confirmation. An injected command could print the entire flag and the page would look exactly as if figlet had run normally.

The filter and your injection technique are unchanged from the previous challenge, but the response no longer tells you what your command did, so you're now dealing with blind command injection. Printing isn't the only effect a command can have, though; it can also change a file or send data, giving you other ways to observe its result from your terminal.

Leaving a file behind is a handy way to recover data from a blind injection, provided your terminal can open it. This time, /tmp has a surprise: the server's /tmp and your terminal's /tmp are different directories. Your command can create a file successfully without giving you anything you can open from the terminal.

The server now runs in a sandbox, which limits what the application can access even after an attacker takes control. The sandbox gives the server a separate filesystem view with private writable directories. Your injected commands still run as root, and /flag is mounted read-only inside, so reading the flag is well within their reach!

Getting that data back is another matter. The character filter and missing command output remain, so your command needs to get the result across the sandbox's boundary without relying on a shared writable directory.

This level looks at what happens when careless path handling meets a request from someone who isn't playing along. Files serves documents out of /challenge/files over HTTP, and it builds the path to each one from the name you hand it.

The developer has a filename in mind. But a path is a set of directions through the filesystem, and directions can go backward as easily as forward. Nothing here forces yours to stay inside /challenge/files. That's path traversal.

The code is at /challenge/server. Read through it, find the weak spot, and read /flag!

This time the app repairs your path instead of refusing it, deleting the traversal it finds on the way through. It looks once and trusts the result. Can you hand it something that only becomes a traversal after it's done looking?

The last level let you walk out with .., so this one forbids .. outright. But banning one spelling of "somewhere else" only shows the developer still hasn't grasped how many ways a path can point away from where they meant it to. Can you still reach the flag?

Another attempt, another misunderstanding. This one doesn't reject your input, it "cleans" it, shaving off the characters it thinks make a path dangerous. Trouble is, it only cleans the parts it bothers to look at. Read the server and find the parts it skips.