Difference between revisions of "Summerschool Aachen 2004/Programming Errors Lab"

From C4 Wiki
Jump to: navigation, search
(Wait till the fun stuff arrives.)
Line 1: Line 1:
==Notes from the Lab Session==
===Solution for case 1a===
* use gdb to get the address of buf
* print 20 no-ops (0x90) into a file
* append the shellcode (e.g. from packetstorm) to that file
* fill that file to 104 bytes
* append the address of buf to that file
* run ./case1a "`cat $file`" and voila!
--[[Alexander Becher]]
===Writing a tunnelling program in order to tunnel arbitrary prtocols into HTTP===
We are currently working on a program to tunnel arbitrary protocols into HTTP. The programing language we are using  is C using among other libraries the socket.h library.
--[[Jan Gall and Samad Nasserian]]
===Exploiting buffer overflows===
I worked on stack based buffer overflows. The first part of the task, i.e. just creating a buffer overflow, was quite simple. The size of the buffer was 100 bytes and as 4 bytes are used in order to store the value of the saved frame pointer in the the stack I first thought that an input string of length 105 would already be enough to cause a buffer overflow. However, since gcc allocates more than 100 bytes for the buffer in the stack, 124 bytes of imput were necessary in order to cause a buffer overflow.
The second part was more difficut as here, I needed to insert shellcode in order to start a shell AND to overwrite the return address saved in the stack with the address of the shellcode which is supposed to start a shell. In order to accomplish this task I used the tutorial "Smashing the stack for fun and profit", which was very useful.
-- [[Samad Nasserian]]
[http://www.metasploit.com/ Metasploit] is a nice repository for shellcode, UNIX as well as Windows.
-- [[Lisa Thalheim]]
===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.
--[[Steven Murdoch]]
===Exploiting Buffer Overflows===
When I tried to exploit buffer overflows like case 1 on my Fedora Core 2 system
I noticed some difficulties. First of all, the place for the local variables on
the stack is significantly larger than it was declared in the source file. This
is a problem if you want to exploit off-by-one programming errors, because you
are not able to overwrite something usefull. The second thing I noticed was
even worser. Normally, all memory offsets of local stack variables stay at the
same place, even if you restart the program. Of course it depends on the input,
but I used the same arguments and the offsets were allways different.
It was the Gnu C Compiler that troubled my day. Since version 3.0
Gnu changed the memory alignment of the compiler, but i don't know the details.
Because Sami had still the older GCC 2.9 on his system, we started trying to
exploit the buffer overflows on his system. We were succesfull with Case 1 and
tried Case 2 until it was too late to think any further. Yes, days are getting
shorter ;)
--[[User:Feanor|Feanor]] 22:34, 22 Sep 2004 (CEST)
=== FreeBSD Shellcode ===
In the lab session I had to find out that my old FreeBSD shell code didn't work
anymore, because I loaded %al with the syscall number, but missed to initialize
%ah to zero before. They changed the syscall behaviour some time ago, which I
had not realized. This took me some time...<br />
I solved case 1a and used a small perl script for actually exploiting it. Now
I'm still working on the other cases. Btw, Ilja has done a very cool preparation.
Thanks! 8)<br />
--[[User:Cpunkt|Cpunkt]] 11:45, 23 Sep 2004 (CEST)
=== Wait till the fun stuff arrives. ===
I researched the php bugs demonstrated at the lecture (originally
found by Martin Eizsner), and made some interesting discoveries.
Due to security reasons these can't be disclosed yet (they *should*
get disclosed once the bugs are fixed).
Then I decided to audit tor and if I found a trivial bug, I could
leave these notes at the system running tor. Unfortunatly I didn't
find such a trivial bug. I did find a few other issues, which I can't
disclose yet either (they should also get disclosed some time soon).
The tor bugs are fixed, you can read about them here:
- http://archives.seul.org/or/dev/Oct-2004/msg00003.html
- http://archives.seul.org/or/cvs/Oct-2004/msg00032.html
The php bug is fixed. Apparently there is even a public exploit for it.
When phpbb is used the unserialize bug is exploited to get administrative
access to phpbb.
-- Ilja van Sprundel

Revision as of 08:34, 9 February 2006