PREFACE – Hacking UMB’s CS Apply program

This page serves as a preface to the 11-part series of research I have written directly to blog. There is an ‘apply’ program in the Computer Science (CS) department at my university, University of Massachusetts Boston. This program allows students,faculty,staff,alumni,and other welcome associates an opportunity to register a UNIX account.

Since I am a CS undergrad, I have one of these UNIX accounts from registering through the apply program. I think it is in my blood to hack computers, and one day I took my instincts toward the school. Me, being the hacker type, was snooping around the filesystem / just looking around to see what was there. I found a /sources directory with the source code to various tools, I noticed apply source code there. Through network auditing tools I also discovered that the same central server for the entire remote administration of 90% CS department network is the same server where the apply program would accept remote applicants. Do you see where I am going with this? I thought, several things — “I wonder if I can exploit apply,” sums it up.

At that point in time, I had never written a novel exploit, nothing beyond learning about basic stack-based execution overflows from that book “The Art of Exploitation” Ed. 1, and certainly nothing more than an example “vulnerable” program. The level of security is pretty intimidating to a hacker who has never had the chance to exploit anything in the wild at all. And it is discouraging when he understands that it may take forever before he becomes ready to exploit in-the-field applications. This story covers just that — my first live exploit of a running application in the field. I got lucky, of course :) — this application is using some a very insecure function that would not go unnoticed in a serious environment whatsoever.  Anyways, it was through the retrieval of the source code that I took a gander and saw that it was in fact using this vulnerable function — gets().

There was another pre-requisite that had to pass before I knew I could investigate stack overflow on this program. As with any SPARC program, there has to be nested function calling going on with register window allocation. I’m not getting into the specifics of that in the preface. This is quite a preface as it is. I eventually found ‘apply’ to pass my checks and I knew I could possibly exploit it!

Part I begins tackling the first problem I faced — exploiting a gets(). Anyone who has researched buffer overflows on SPARC must notice the same thing I did — there are no examples other than with strcpy(). And in these examples, the vulnerable function is exec’d from within the exploit… Exploiting a gets() is much different — the exploit comes in through STDIN, and the same rules do not apply as with strcpy(). Maybe I missed the memo, but you cannot pass in 0x0a bytes for instance in the shellcode because that is a \n which causes the string to cease. Anyways, it’s tough to stay simple in the memo.

This series is literally brain dumpings – it is my raw live research developments in action. It contains my live development of shellcode, to GDB debugging sessions, to complex relationships between multiple stack frames in memory, to memory peeking through a heap overflow in order to understand remote LibC offsets in order to execute a shell from an app with a non-executable stack, hoola-ba-loo. It’s great, I promise. Any enthusiast or hacker enthusiast will love reading through my story of conquering task after task in order to gain entry to the central remote administration server at my school. I believe that gaining remote LibC offset knowledge through a char* info disclosure is a novel thing. You just don’t read about that stuff on Google. I’m glad that I figured out how to do it myself, a real hacker would.