|
|
| 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]]
| |
| − |
| |
| − | ===Metasploit===
| |
| − |
| |
| − | [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).
| |
| − |
| |
| − | UPDATE:
| |
| − | 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
| |
| − |
| |
| − | UPDATE2:
| |
| − | 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
| |
| − |
| |
| − | [[Category:Summerschools]]
| |
| − | [[Category:Hacks]]
| |
