Story Title: (N)jinxed Ubuntu nginx privesc vulnerability
Synopsis/Talking points: Debian and Ubuntu suffer from a nginx privesc from the www-data user to root due to loose file permissions on files in /var/log/nginx. A symlink could be dropped by the www-data user, replacing one of the nginx logs that gets executed by logrotate. Logrotate will then execute the symlink, resulting in root permissions.
Long story short: clever use of logrotate and symlinks results in privilege escalation to root
Story Title: An example of how myopic Linux can get (NSF file vulnerability in Ubuntu 12.04.5)
Synopsis/Talking points: Ubuntu takes great strides in trying to be a user-friendly OS. If you choose to enable mp3 support during an Ubuntu installation, it turns out, that support for a bunch of other audio formats is added as well, include the .nsf file format for playing NES “chiptunes”.
The vulnerability comes from poor bounds checking.
Scope of vulnerability is relatively low (e.g. phishing attack/drive-by exploitation is about all this is good for
Ubuntu ships with two NSF players. One can delete the vulnerable NSF library with little to no side-effects. WTAF.
Story Title: Mash keys, get shells
Synopsis/Talking points: Vulnerability with LUKS/cryptsetup results in a “failopen” scenario and root shell.
If the root partition of the OS is encrypted with LUKS, all an attacker with console access has to do is fail the password guesses, and repeatedly mash “Enter”. There is a portion during boot where the system will panic that the device doesn’t exist and will drop to an initramfs root shell.
This is a classic “fail open” scenario.
Reminiscent of the mysql auth bypass vulnerability a few years back https://www.exploit-db.com/exploits/19092/
Also reminiscent of the GRUB “mash the escape key” vuln a while back too. (http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html)
Story Title: LD_PRELOAD rootkits, and you
Synopsis/Talking points: Let’s talk about /etc/ld.so.preload and how it can be abused
Linux userland rootkits are nasty pieces of work.
An LD_PRELOAD rootkit works by implementing alternative versions of functions provided by the libc library that many Unix binaries link to dynamically. Using these ‘hooks’, the rootkit can evade detection by modifying the behaviour of the functions and bypassing authentication mechanisms, e.g. PAM, to provide an attacker with a backdoor such as an SSH login using credentials configured by the rootkit. (1)
Can be detected by … LD_PRELOAD=/location/of/libc.so.6 [command to run here] what this does: bypasses /etc/ld.so.preload library hooks by setting the LD_PRELOAD variable for a command/process you want to run. This means that libc library hooks are avoided; a core component of many userland rootkits.
Can also be detected via cold disk forensics, memory forensics, network monitoring, etc.