Server-Side Exploitation

A web app often needs something the shell is already good at, so it takes the easy road and shells out: it glues a command together as a string and runs it. Marquee does this to turn your words into an ASCII banner with figlet.

The catch is that a shell scans a command for its own special characters before it runs anything. The developer expects your word to be a word, and drops it straight into the figlet command. You can send anything they forgot to block. A ; ends one command and starts the next, so where the developer sees one command, the shell is glad to run two.

The real code lives at /challenge/server. Read it, then see if you can trick it into handing you the flag!

Command injection has a quirk: you never pick the spot in the command where your input lands. The developer settled that when they wrote the code, and sometimes the spot is cramped. Here Marquee wraps your input in single quotes before handing it to figlet. Between single quotes the shell reads ;, $, and the rest as ordinary text, all the way up to the closing quote. Can you bypass it?

Plenty of developers know command injection exists and try to swat the obvious cases. This level won't let you use ;. But chaining commands was never a one-character trick. A shell has more than one way to run a second command, so go find another!

This time the developer went all in, blocking just about every dangerous character they could think of. Nearly every one. Find the character the filter forgot.

Every level so far handed the command's output straight back to you, so a successful injection was easy to spot: you just read the reply. Real apps are rarely so kind. This version of Marquee ships your banner off to a print queue and answers with nothing but "queued." The injection still lands, but the output goes somewhere you can't see.

This is blind command injection, and it is the common case in the wild. When the answer never comes back, you stop trying to read the result and start making the command act on its own. Have it hand the flag to something that can carry it back out, or leave it somewhere you are allowed to look. The flag is still one command away. You just have to route it to yourself instead of reading it off the reply.

Now the whole app runs boxed in. Before it serves a single request, it walls itself off into its own namespaces and filesystem view, with the flag mounted read-only inside. Your injected command lands inside those walls, running as root, with the flag sitting right next to it.

Reading it is nothing. Getting it back to you is the whole game. The old move, leaving the flag somewhere your shell can pick it up, dies here: the box has its own filesystem, so anything you touch stays inside and your shell outside never sees it.

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.