Don't Laugh - Bash Script/ Alias Sec(ish)

For the discussion of Perl, Python, Ruby, and PHP and other interpreted languages.

Don't Laugh - Bash Script/ Alias Sec(ish)

Post by -Ninjex- on Thu Jan 31, 2013 9:35 pm
([msg=73096]see Don't Laugh - Bash Script/ Alias Sec(ish)[/msg])

Okay, so I just started learning how to create bash scripts and the alias command today, so don't give me to much shit! lol

Basically I learned today that you can use alias to create your own commands in the linux terminal with something like:
Code: Select all
alias back2='../../'

This will create a command called back2 that executes the command to go back two directories (../../)
You can run this command from the terminal session you created it in simply by calling it's name: 'back2' with no quotes.
However, these are only stored in memory, and destroys itself after the terminal session is closed.
To make this command stay forever, we go to our home directory
Code: Select all
~/
and edit the .bashrc file.
Adding our command in there the same way as before will allow the command to live for as long as it is located in the file.

So I then read more today and learned about bash scripting, which I had very slim knowledge of before and never tried to learn until today. I decided it would be cool because you could use a bash script to write your own alias keywords for you.

Then of course me and my crazy ideas (Flash back to when I renamed my Desktop to .Desktop) I thought about changing commands that are commonly used. For instance, the command cd is used so much, so let's tweak it..
Code: Select all
alias cd='cd /'

The command above would make someone stay in the home directory no matter where they try to change directories to. (I created a directory called Fail, and keep it stuck in that directory)

So anywho, I thought well this could be potentially useful if someone did mange to ssh into my machine, or I am gone from my computer, etc.. The only issue is that it would be a pain in the ass to remember all of the commands that I make, and trying not to fall into traps, etc... This is also not effective if the user knows about the alias command, they could simply run:
Code: Select all
alias cd='cd'

and it is no longer effective.

So I came up with an idea. I wanted a way to allow me to use certain commands, and disallow them if they are not me. So, for instance, if someone wanted to run a sudo command, they would get prompted for a complete different password that can be anything, so that if someone bruteforced into my machine via ssh, when they try to run a certain command, they will get prompted for the chosen password. Basically if the password is answered, the user can continue about their day with no further encounters of the issue, unless specified otherwise.
However, if the password is incorrect, I want to shut them out from using any commands, besides a very few specified commands. Since everything is on the machine, the last thing you would want is someone to get in your machine, and get your password wrong, because the effects take place on your machine in your .bashrc file! This would mean if someone tunneled into my machine and answered the password wrong, I would suffer from it, and not be able to use any commands!!! This could be dangerous, so we need a work around which I will explain later.

So the first step needed is to make a directory called Fail in my home directory; so I ran
Code: Select all
sudo mkdir ~/Fail

This will be where we send the user striped from most useful commands, when they try to use the machine with unauthorized access.
Next, we need to edit our .bashrc file located at ~/.bashrc and add the following commands which we will explain why later
Code: Select all
alias sudo='. ~/sudo.sh'
alias fix='. ~/fix.sh'
alias pro='. ~/pro.sh'

The first alias sudo command overwrites the traditional sudo command, and tells it to execute the bash file sudo.sh in the home directory

After we have added the commands above to our .bashrc file, we now need to create our first bash script! This script is called sudo.sh
The code is explained in the comments inside of it!
Code: Select all
#!/bin/bash

# If there is no file called .bashrc2, we copy .bashrc2 to that name
# This is useful for our next script fix.sh
# Note that any time we mv/make/copy a file we need to chmod a+r+w to allow the use of them
if [ ! -f ~/.bashrc2 ]; then
        cp ~/.bashrc ~/.bashrc2
        chmod a+r+w ~/.bash*
fi
# When the user enters the sudo command, we make a password prompt
#that looks very similar to the traditional sudo prompt, except that ours does
#not hide characters when being input
echo "[sudo] password for "$(whoami)":"
read pass
# If the passowrd is hts, we tell alias to append the traditional sudo command to .bashrc
# This will overwrite the traditional sudo prompt of alias sudo='~/sudo.sh'
if [ $pass = "hts" ]; then
        echo "Authentication Successful!"
        echo "Please open a new terminal for effects to take place!"
        echo "alias sudo='sudo'" >> ~/.bashrc

else
# If the password is invalid, we append multiple alias commands to commonly used commands
# this makes the commands useless, even if they work still. We then close the terminal
# Closing the terminal forces them to open a new one where the appended commands will take place
        echo "Invalid Password"
if [ $pass != "hts" ]; then
        echo "alias cd='cd ~/Fail/'" >> ~/.bashrc
        echo "alias alias='cd ~/Fail/'" >> ~/.bashrc
        echo "alias sudo='cd ~/Fail/'" >> ~/.bashrc
        echo "alias l='cd ~/Fail/'" >> ~/.bashrc
        echo "alias ls='cd ~/Fail/'" >> ~/.bashrc
        echo "alias nano='cd ~/Fail/'" >> ~/.bashrc
        echo "alias gedit='~/Fail/'" >> ~/.bashrc
        echo "alias vi='~/Fail/'" >> ~/.bashrc
        echo "alias chmod='~/Fail'" >> ~/.bashrc
fi
exit
fi

The summary of the code above is:
If you get the wrong password, your terminal session ends and you get directed to the /Fail folder with limited commands. If the password is correct, we overwrite the sudo command to the traditional sudo command. A new terminal needs to be opened afterwards for the effects to take place!

Next we need to create the fix.sh script. This script is a command in the .bashrc file, and can be called on inside the Fail foder in case someone tries to gain unauthorized access, and makes these changes to our system. It would be a nightmare if we couldn't call this command from inside the Fail folder and this happened.
The fix script looks like this:
Code: Select all
#!/bin/bash
# Prompt the user for the password
echo "Enter the password for "$(whoami)":"
read pass
# If the password is hts, we take the .bashrc2 file that is a copy of the original .bashrc file
# and we move it to replace the current .bashrc file, which will in turn remove the appened
# bad alias commands, while still appending the password prompt for the sudo command
if [ $pass = "hts" ]; then
        echo "Authentication was a success!"
        echo "Fixes will begin taking effect!"
        mv ~/.bashrc2 ~/.bashrc
        chmod a+r+w ~/.bash*
else
        echo "Invalid Password"
fi



So now with the above, we can do the following:
1. Prompt user for password when they use the sudo command
2. If the pass is correct, we can overwrite the sudo alias, to allow the proper use of sudo
3. If the password is false, redirect them into the Fail folder with limited commands
4. Run the fix command in the Fail folder, and fix our machine in case if someone tried to gain unauthorized access

Now we are faced with another question. Everyone ends up running sudo sometime, and after you run sudo, the changes take effect system wide. Meaning if you run sudo once, and leave your machine on, or literally leave your machine, it is still dangerous. For instance if you ran sudo nmap, and answered your password prompt, the sudo command is overwritten by the real sudo command. This means that if say you left your computer in real life, someone could use sudo now. Same goes for if you used sudo, and someone made an ssh tunnel onto your machine, they can use the sudo command, because the effects are made on your system to the .bashrc file.

So how would we go about preventing this? The answer I came up with was to create another bash script called pro.sh, which is short for protect. However, before we do that, we need to create a file called .pro which should contain the normal .bashrc file with the sudo command directed to the sudo.sh script.
It should look like this:
Code: Select all
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines in the history. See bash(1) for more options
# ... or force ignoredups and ignorespace
HISTCONTROL=ignoredups:ignorespace

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
   # We have color support; assume it's compliant with Ecma-48
   # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
   # a case would tend to support setf rather than setaf.)
   color_prompt=yes
    else
   color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'
alias b2='cd ../../'
alias b3='cd ../../../'
alias moveall='sudo mv *'
alias copyall='sudo cp * ~/Desktop/copied/'
alias mymount='~/test.sh'

# Add an "alert" alias for long running commands.  Use like so:
#   sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi
alias sudo='. ~/sudo.sh'
alias fix='. ~/fix.sh'
alias pro='. ~/pro.sh'


Next we can create our pro.sh script which should look like this:
Code: Select all
#!/bin/bash

echo "Protecting sudo..."
echo "Moving .pro to .bashrc"
# We copy the sudo protected .bashrc file (.pro) to .bashrc with a,w,r chmod permissions
# After we move the file, we declare to copy it back as .pro unless .pro exists
mv ~/.pro ~/.bashrc
chmod a+w+r ~/.bash*

if [ ! -f ~/.pro ]; then
        echo "Cloning .bashrc to .pro"
        cp ~/.bashrc ~/.pro
        chmod a+w+r ~/.pro
else
        echo "The file already exists."
fi


So now, you can do the following:
1. Prompt user for password when they use the sudo command
2. If the pass is correct, we can overwrite the sudo alias, to allow the proper use of sudo
3. If the sudo command is not protected by the a
Code: Select all
lias sudo='~/sudo.sh'
command, we can choose to protect it
3. If the password is false, redirect them into the Fail folder with limited commands
4. Run the fix command in the Fail folder, and fix our machine in case if someone tried to gain unauthorized access

If you want to protect other keywords, you can just add them into the .bashrc file and declare them to execute your sudo.sh script,
for example if you wanted to protect the cd, mv, cp commands you would add these commands to those files:
Code: Select all
alias cd='. ~/sudo.sh'
alias mv='. ~/sudo.sh'
alias cp='. ~/sudo.sh'

Make sure you copy it over to any existing files that deal with the scripts!!! i.e. .conkyrc2, .pro, and .conkyrc

I recommend that you to do this to stay protected after you have set it up:
1. type in sudo
2. Give the password prompt the correct answer
3. Open your new terminal
4. Use the command 'pro' with no quotes ' '

This will allow you to use all commands until you end your terminal session, while keeping your system protected from anyone that tunnels in trying to use the commands. This is becuase your terminal holds the memory of the old .bashrc file! In summary, you can use sudo, and no one else can! However, if you walk away from your computer irl, close the terminal session.

If you ever open a terminal session and are immediately brought to the /Fail folder, you know someone tried to gain unauthorized access to your machine. From in there, you can run the command 'fix' with no quotes, which will in turn fix your .bashrc file, given that you provided the correct password.

Keep in mind, that you can from inside the Fail folder still use some commands such as nano and chmod, which take effect, but when you try and run the commands, they fail.
i.e. I recreated the fix.sh file inside the Fail folder using nano and gave it read write execute permissions for all users using chmod a+w+r+x, and ran the file. The file never took place and the .bashrc file remained unchanged.

Also note, that you may need to have your normal .bashrc file protected and then call in the script fix to change the keywords back after a given password. I say this because I do not believe that ssh sessions can exit out of a terminal session, which means that the effects wouldn't take place, however I am going to test this real soon and get back to you guys with the results.

Don't laugh,
- Ninjex

-- Thu Jan 31, 2013 10:23 pm --

Okay, I ran the test. I made a ssh tunnel and made note of a few things.
The main point is number 1, make sure you copy these to the root account home directory.
1. Add all of the scripts for this into the root accounts home directory, as well as other users.
2. The exit command on the bash scripts can close a ssh session for the user.
3. If the user is sudo, and they use su usernamehere, if they enter the wrong password, it will close them from the session of that user and back into the root session. i.e. (Say there are two account ninjex@192.168.1.69 and root@192.168.1.69) If they tunnel in as root@192.168.1.69 and use su ninjex, and become ninjex@192.168.1.69, and run sudo and enter a wrong password, it will force them back into a session with root@192.168.1.69

It is very important to copy these files over to all user's on your computer and your root account for the greatest security.

---
Tell me what you guys think about this.
I am planing on making it copy itself to all user's, and possibly making a directory called sec for all the files; which means I will have to re-write the scripts a little, as well as make a log file.
The log file may be similar to something like:
Code: Select all
history >> ~/log.txt
# If I make a directory for all of the files it may look similar to:
history >> ~/sec/log.txt


-- Fri Feb 01, 2013 3:18 am --

New
----
I added the files to a folder, that should be placed into the home directory, and a file used to install everything.
I also added more commands to the file for the root account, as having sudo protected on root is stupid.
I will make a video on this, and upload the files in a .tar.gz somewhere for those who are interested tomorrow.
If you're not willing to learn, no one can help you. If you're determined to learn, no one can stop you.⠠⠵
The absence of evidence is not evidence of absence.
I can explain it for you, but I can't understand it for you.
User avatar
-Ninjex-
Addict
Addict
 
Posts: 1302
Joined: Sun Sep 02, 2012 8:02 pm
Blog: View Blog (0)


Re: Don't Laugh - Bash Script/ Alias Sec(ish)

Post by tgoe on Mon Feb 04, 2013 7:40 pm
([msg=73423]see Re: Don't Laugh - Bash Script/ Alias Sec(ish)[/msg])

Cool, but I think a blacklist approach like this isn't too secure. Have you looked at the restricted mode of popular shells? Like rbash and rksh?
User avatar
tgoe
Contributor
Contributor
 
Posts: 639
Joined: Sun Sep 28, 2008 2:33 pm
Location: q3dm7
Blog: View Blog (0)


Re: Don't Laugh - Bash Script/ Alias Sec(ish)

Post by -Ninjex- on Mon Feb 04, 2013 8:10 pm
([msg=73425]see Re: Don't Laugh - Bash Script/ Alias Sec(ish)[/msg])

tgoe wrote:Cool, but I think a blacklist approach like this isn't too secure. Have you looked at the restricted mode of popular shells? Like rbash and rksh?


I have recently heard of them, and plan on looking into it soon, to see what it's about.
If you're not willing to learn, no one can help you. If you're determined to learn, no one can stop you.⠠⠵
The absence of evidence is not evidence of absence.
I can explain it for you, but I can't understand it for you.
User avatar
-Ninjex-
Addict
Addict
 
Posts: 1302
Joined: Sun Sep 02, 2012 8:02 pm
Blog: View Blog (0)



Return to Interpreted Languages

Who is online

Users browsing this forum: No registered users and 0 guests