While writing with Kuza55 an article about local file inclusion advanced exploitation a very interesting code emerged on milw0rm that shows another technique that has advantages and disadvantages but is surely smart and not that well known (while documented on some papers and actually exploited in the past).
It's demonstrated in the "Trixbox 2.6.1 lfi 2 root", known on FD as "Trixbox 2.6.1 and below, remote root shell through local file inclusion". "This is an update of the previous exploit. We can now get a root shell, thanks to sudo." (http://seclists.org/fulldisclosure/2008/Jul/0102.html)
With Kanedaaa we dissected the exploit and the Trixbox .iso and understood that this vuln fall under the category of multi-layered security issues that lead to complete remote 0wnage.
The entry point is a standard local file inclusion.
$ cat user/index.php
$language = $_SESSION['trixbox_Language'];
include('modules/'.$value.'/language/'.$language.'.php');
$_SESSION['trixbox_Language'] is driven by user inputs as later shown. Injected path has the common php nullbyte attack to get rid of the leading .php extension. The exploit stores the payload (php with perl `` eval'd code) into the language variable that is saved in the session in a serialized (but still usable, as the code demonstrates) state.
$ cat includes/application_top.php
if(isset($_POST['langChoice'])){ $langChoice = $_POST['langChoice'];
$_SESSION['trixbox_Language'] = $langChoice; $language =
$_SESSION['trixbox_Language'];
Notice that POST langChoice is used both for payload injection into the session and for the LFI. PHP default session handler stores sessions on the filesystem in files named /tmp/sess_%{PHPSESSIONID} and readable by the apache user (in this case asterisk).
$ egrep -i "^User|^Group" httpd.conf User asterisk Group asterisk
This is not interesting for the accessibility of that session file, that is normally owned by the same user running the webserver, but for the successive escalation is performed. Logfiles (the common way to exploit LFI to get remote code execution) on the other side are sometimes unreadable by the user running mod_* cause owned and opened by root before dropping privileges (the file descriptor is still open naturally). The local file inclusion is then used to include the session file and execute the previously injected payload.
Escalation to root is possible since sudo is misconfigured in it's most obvious way (no abuse of password caching, tty ticket, etc).
00_trixbox_defaults.sh sed -i 's/^Defaults requiretty/# Defaults requiretty/g' /etc/sudoers for sudocmd in /sbin/shutdown /usr/bin/nmap /usr/bin/yum /bin/chown \ /bin/chmod /bin/touch /sbin/service /sbin/init /sbin/route /bin/hostname \ /bin/ln /bin/bash; do if ! grep "asterisk ALL = NOPASSWD: $sudocmd" /etc/sudoers >/dev/null 2>&1; then echo "asterisk ALL = NOPASSWD: $sudocmd" >> /etc/sudoers echo "asterisk ALL = NOPASSWD: $sudocmd added to /etc/sudoers" fi done
Thanks to the 00_trixbox_defaults.sh script two set of critical changes are performed on /etc/sudoers: sudo will no more require a TTY (requiretty), meaning that non interactive usage is allowed and the user asterisk is granted to execute a number of binaries as root password-less (NOPASSWD). At this point the gained remote code execution is used to exploit the sudo configuration and become root.
In short:
A lfi to our "own" session file injected with php code that executes a perl reverse shell that spawns an interactive bash with root privileges thanks to sudo misconfiguration. It's surely smart and probably the public exploit that better demonstrate and use this technique (including the session files). Has advantages against logfiles since there are generally less issues with filesystem permissions but on the other side it's not always possible to drive contents of $_SESSION.
Cool work Jean-Michel BESNARD!
References (mail me at ascii @ thisdomain for corrections, i'm seeking the oldest piece of information that mentions including session files as Wisec says he first seen it back in 2000):
The session mechanism also supplies another convenient place that attackers have their input saved into a file on the remote machine. For examples above where the attacker needed PHP code in a file on the remote machine, if they cannot use file upload they can often use the application and have a session variable set to a value of their choosing. They can then guess the location of the session file, they know the filename 'php<session id>' they just have to guess the directory, usually /tmp.
Quoted from: http://milw0rm.com/papers/download/14
Text version of the article: http://ush.it/team/ascii/hack-lfi2root/lfi2root_session_file.txt