Difference between revisions of "Summerschool Aachen 2004/Programming Errors Lab"
| Line 9: | Line 9: | ||
-- [[Lisa Thalheim]] | -- [[Lisa Thalheim]] | ||
| − | ==Example vulnerability on the [http://www.srcf.ucam.org/ SRCF]== | + | ===Example vulnerability on the SRCF== |
| + | |||
| + | As I think I mentioned, the [http://www.srcf.ucam.org/ SRCF] has a big | ||
| + | problem allowing so many users to run CGI and PHP scripts on our | ||
| + | webserver. We try to limit the number of insecure scripts by looking | ||
| + | for old versions of vulnerable software, but we do not have the | ||
| + | resources to check whether user-written scripts are exploitable. What | ||
| + | we try to do is stop one user's script from interfering with other | ||
| + | user's scripts, and stop attackers from being able to escalate a | ||
| + | exploitable CGI into a root exploit. | ||
| + | |||
| + | This approach does not always work and there have been two successful | ||
| + | root compromises since 2000. The first was simply getting a user shell | ||
| + | using an exploitable CGI ([http://www.ikonboard.com Ikonboard]). The | ||
| + | attacker then used a [http://lwn.net/Articles/25669/ ptrace] exploit | ||
| + | to get root. This was before a patch to the vulnerability has been | ||
| + | released. They then installed the | ||
| + | [http://www.phrack.org/show.php?p=58&a=7 SuKIT] rootkit. | ||
| + | |||
| + | The more interesting one was where the attacker used site-specific | ||
| + | knowledge to get root. It is likely he used a vulnerable CGI to look | ||
| + | around the system. What he noticed is that one other vulnerable CGI | ||
| + | was written by an ex-sysadmin and so could get access to that | ||
| + | account. While that user did not have root access, he did own one old | ||
| + | file which was processed by a cron job. This cron job ran as root and | ||
| + | did not check for shell metacharacters in the input file (since it was | ||
| + | meant to only be written to by sysadmins). The attacker embedded a | ||
| + | command in the input file so as to create a root shell when it was | ||
| + | processed by the cron job. Fortunately we stopped tha attack before | ||
| + | any harm could be done, and we also captured a list of | ||
| + | [[Summerschool2004/SrcfHackingLog|commands he entered]]. In reaction | ||
| + | to this attack we introduced two new policies. Firstly all scripts run | ||
| + | as root were audited to ensure that no files writable by non-root | ||
| + | users were opened. Secondly each system administrator had a new account | ||
| + | created, which was isolated from their normal account, and that could | ||
| + | not run CGIs. | ||
Revision as of 16:37, 22 September 2004
Contents
Presentation Summary
Notes from the Lab Session
Notes from Presentations
Metasploit is a nice repository for shellcode, UNIX as well as Windows.
=Example vulnerability on the SRCF
As I think I mentioned, the SRCF has a big problem allowing so many users to run CGI and PHP scripts on our webserver. We try to limit the number of insecure scripts by looking for old versions of vulnerable software, but we do not have the resources to check whether user-written scripts are exploitable. What we try to do is stop one user's script from interfering with other user's scripts, and stop attackers from being able to escalate a exploitable CGI into a root exploit.
This approach does not always work and there have been two successful root compromises since 2000. The first was simply getting a user shell using an exploitable CGI (Ikonboard). The attacker then used a ptrace exploit to get root. This was before a patch to the vulnerability has been released. They then installed the SuKIT rootkit.
The more interesting one was where the attacker used site-specific knowledge to get root. It is likely he used a vulnerable CGI to look around the system. What he noticed is that one other vulnerable CGI was written by an ex-sysadmin and so could get access to that account. While that user did not have root access, he did own one old file which was processed by a cron job. This cron job ran as root and did not check for shell metacharacters in the input file (since it was meant to only be written to by sysadmins). The attacker embedded a command in the input file so as to create a root shell when it was processed by the cron job. Fortunately we stopped tha attack before any harm could be done, and we also captured a list of commands he entered. In reaction to this attack we introduced two new policies. Firstly all scripts run as root were audited to ensure that no files writable by non-root users were opened. Secondly each system administrator had a new account created, which was isolated from their normal account, and that could not run CGIs.
