The second hashcalc challenge is much the same as the first (make sure to read it!). Except this version is launched from inetd instead of being a forking server. This is annoying because it means that stack cookies and library offsets change every run. Let’s verify that by adapting our exploit to dump the GOT to the new binary.
The control flow relevant to the bug is as follows:
So what we have is a blind format string bug in request_handler, and a buffer overflow in reply_func. The buffer overflow is normally detected because of a damaged stack cookie however. Since the stack and libs are randomized we really want to have the freedom to explore the address space using ROP instead of just using a printf exploit, so let’s see if we can find a way to make the overflow work.
Another quick pCTF 2011 write-up. This is a windows Application made using .NET. Upon launching you get 3 sliders with a range of 0-255 and a button. Goal is to find the correct permutation for the 3 sliders. When you enter the wrong slider values you will get a nice failed message.
When decompiling the application using ILspy we find the following relevant code bits:
This is a quick write up of the Django webchallenge from PlaidCTF 2011.
Web application is a guestbook written using Django and can be found at: http://a12.amalgamated.biz/DjangoProblem1
Upon investigation it turns out they have pagecaching in Django enabled using Memcache. Memcache is a key/value store accessible over TCP. The memcache server is publicly accessible on the default memcached port 11211.
Some snooping around on the memcached server reveals Django uses python serialized objects in the cache. Serialized objects in the memcache keystore have a flag of ‘1’. (We missed this detail for a long time :/)