Vulnerability demonstration on Ubuntu 9.04

Question

For a class on IT security, I want to demonstrate privilege escalation to the students. To do so, I looked through the exploit/linux/local list in the Metasploit Framework, finding (among others) exploit/linux/local/sock_sendpage from August 2009.

I set up a VM with 32-bit Ubuntu Server 9.04 (http://old-releases.ubuntu.com/releases/9.04/ubuntu-9.04-server-amd64.iso) from April 2009. uname -r gives me 2.6.28-11-generic. According to the exploit's description

All Linux 2.4/2.6 versions since May 2001 are believed to be affected: 2.4.4 up to and including 2.4.37.4; 2.6.0 up to and including 2.6.30.4

So it seems that the Ubuntu server that I set up should be suitable for demonstration. However, I was not able to get it to work.

I added a (regular) user on the server and SSH access works. From within the Metasploit Framework, I can create an SSH session using auxiliary/scanner/ssh/ssh_login. However, when I run the exploit, I get

[*] Writing exploit executable to /tmp/mlcpzP6t (4069 bytes)

[*] Exploit completed, but no session was created.

I don't get any further information, not even when setting DEBUG_EXPLOIT to true. /tmp is writabe, also from within the Metasploit SSH session:

$ sessions -c "touch /tmp/test.txt"
[*] Running 'touch /tmp/test.txt' on shell session 1 ([redacted])

$ sessions -c "ls -l /tmp"
[*] Running 'ls -l /tmp' on shell session 1 ([redacted])

total 0

-rw-r--r-- 1 [redacted] [redacted] 0 2016-03-28 09:44 test.txt

I also tried setting WriteableDir to the user's home directory on the server, but without any changes. What am I missing here? Is this version of Ubuntu server (that I have deliberately not updated!) not vulnerable?

Solution 1

The 9.04 release was supported until October 23 2010. The vulnerability you found was reported in August 2009. It seems reasonable that, since the release was still current and supported at the time, the ISO was patched and what you downloaded was a version that is no longer vulnerable.

Furthermore, you seem to have demonstrated quite nicely that it isn't vulnerable. After all, you tried the exploit and it looks like it failed.

Why don't you try a newer exploit? Something like CVE-2013-2094 which should also affect Ubuntu, for example.

Solution 2

This does not answer your specific query, rather it gives you more priv esc choices to show your students...

You may want to also consider the following two administrator miss-configurations that could lead to priv esc on 'nix (there are many other ways to miss-configure a 'nix box that could allow priv esc so please consider this a whetting of appetite)....

1. suid and guid binaries owned by root/root group (find / -uid 0 -perm -4000 -type f 2>/dev/null and find / -uid 0 -perm -2000 -type f 2>/dev/null) and see if they are world writable to allow low privilege user to change them; the folder they exist in is writable by your low priv user - for possible library path injection. What about the libraries they use - are those able to be changed: check the values of any DT_RPATH and DT_RUNPATH ELF headers within the binaries using one of the following commands:

   • objdump -x ...
   • readelf -a ...
   • scanelf (from PaX)
   • elfdump (from Sun)
   • readelf -a binary | grep PATH

2. sudoers flaws

   • NOPASSWD - A local attacker could use this access to escalate their privileges within the operating-system when the user forgets to lock their screen

   • Missing Executables in Sudoers - Some executables in the /etc/sudoers file do not exist. If the executables are created they can be run via sudo as root which would allow for privilege escalation.

   • Orphaned Sudoers Entries - The /etc/sudoers file may contain a number of orphaned entries for which there is no corresponding account configured in the /etc/passwd file. If a user were created with one of the orphaned names it would provide the user with a means to escalate privileges to full root access.

   • Some Programs should not be in sudo - like vi, use :e or Ctrl o and use :w to access /etc/shadow.

   • Incorrectly thought out/bad command used in the sudoers file - I often see httpd in sudoers - so try as a low priv user with sudo access to run just that command (sudo -l or sudo -ll will show what a user can do): sudo /usr/bin/httpd -t /etc/shadow and look at the error.

   • file perms of commands and files mentioned in sudoers are weak - see my earlier paragraph on suid and guid bit binaries owned by root

Comments

[terdon]

@AndreasUnterweger oh, sorry, I didn't realize there was no module. I just found that one randomly by searching for "privilege escalation". As for the pkexec exploit, have you checked the version of libpolkit-backend-1? The page you link to states that the vulnerability requires a version of that older than 0.94-1ubuntu1.1.

[Andreas Unterweger]

According to dpkg -s libpolkit2, the version that is installed is 0.9-2ubuntu1.

[terdon]

@AndreasUnterweger in that case, I have no idea. Sorry. You might be better off posting a question on Information Security, asking for a specific privilege escalation exploit and distribution combination that is known to work.

[terdon]

@AndreasUnterweger and ThorbjørnRavnAndersen please take this discussion to chat. I have already moved your previous comments there.

[Richard Braganza]

btw you can also try Spender's original code for the metasploit module in case the metasploit module is not quite correct: grsecurity.net/~spender/exploits

[Andreas Unterweger]

Thank you very much for listing these items. However, I fear that both groups of items will require too much background information and context from the students - they barely know Linux at this point of their studies. I want to show them that privilege escalation is a real thing and that they should always patch the systems they are/will be responsible for. Ironically, I have failed so far to demonstrate an actual privilege escalation as the one described above. EDIT: I'll have a look at Spender's code, but am currently running out of time, unfortunately. Thank you very much for the link.