Skip navigation

Monthly Archives: May 2012

In order to learn more about the above topic, I’ve been working my way through the Nebula challenge VM found here: http://exploit-exercises.com/

The VM comes packaged as a small linux installation with multiple accounts corresponding to levels. To progress from one level to the next, you need to find a way to exploit some program that runs with the permissions of the next user up, and steal their flag, although all levels are available from the beginning, I can only assume that they’re ordered by intended difficulty. On the off chance anyone actually reads this, I don’t want to include spoilers, but I do intend to document what I have learned.

1) Pay attention to environment variables

In two of the challenges so far, the solution was in the environment variables. In one, the privileged program was running a stock application, but by changing the PATH variable, it was possible to substitute your own booby trapped application for the legitimate one. You could then cause the privileged user to execute your own code.

Another challenge was more direct, calling system() on a string containing an environment variable. If that variable were, for example, to be set to “;/bin/bash;” … Needless to say, this all falls back to one of the golden rules: DON’T TRUST USER INPUT.

2) Pay attention to file/folder permissions

If you keep anything sensitive in your home folder or a subdirectory (*cough* ssh keys *cough*) you need to be pretty sure nobody who should not have access to that file actually does. If they can get your ssh keys, they have a much better shot at logging in as you. You ARE using a strong passphrase, yes?

In fact, none (so far) of these exploits would have been possible if other users’ home directories were off limits.

—————

More thoughts to come as I progress further through the challenges.

Advertisements