In a recent incident a school server (not an ISIS server) was compromised. PHP code was injected that listened to and executed commands passed through a POST request with ‘www’ user privileges. Some of the commands that were run include id, pwd as well as directory searches and wgets of various files. The compromised machine also served as a hop in a pharmacy ad delivery scheme. It redirected HTTP requests for medications to a possible ‘mothership’ server. There is evidence that links to our server were posted as ads on websites like MySpace.
Archive for the 'Reverse Engineering' Category
While I’ve been sitting at home, sick for the last few days, I’ve been trying to keep my mind at least somewhat sharp by watching some light videos here and there. The usual stuff, some TED, some 30 Rock, and I came across this gem I thought many people on this list might be interested in:
Crouching Powerpoint, Hidden Trojan: An analysis of targeted attacks from 2005 to 2007
Presented by Maarten Van Horenbeeck of the SANS ISC at the 24th Chaos Communication Congress
http://events.ccc.de/congress/2007/Fahrplan/events/2189.en .html
See the links at the bottom for presentation materials including a PDF, video, and analysis of actual targeted exploits. I highly recommend the video, the torrent was extremely fast.
Enjoy :-)
I will try to keep this to the point. Auto-completion on the terminal is something we all love and it makes using a UNIX system and running commands far more pleasant. Most shells can auto-complete path names, binary names, and built in commands. Bash goes further and supports auto-completing user names, hosts and a few other trivial things. No shell that I know of has ever attempted to auto-complete the arguments that the binaries take. Leaving out support for this makes sense, as there is no common way for a binary to store the arguments it can take inside the program binary, and it is bound to be a porting nightmare.
Keeping this in mind, I realized that almost every single UNIX binary gets its arguments from the shell in a standard, POSIX-compliant way. The getopt libc function call parses the input from the shell in to usable internal flags. If one were to peek inside what each binary gives to getopt(), one would find out all arguments it is expecting to take and provide more insight about the executable! This is what I have done and what the remainder of the post is about.
This is what my previous post related to. Now I realize this is a slightly silly goal. My primary reason for doing this is to learn the techniques I’ve used to get there, which I simply could not learn without experimentation and a concrete goal in mind. The way this problem was attacked as follows:
In the last few weeks, I have been needing to understand a lot of existing source code. People, including myself, often try to reverse-engineer binaries and not pay much attention to reverse-engineering available code, if that’s the proper way to call it. While not reverse-engineering in its core, analyzing source code tends to tickle similar parts of the brain as when reverse-engineering binaries. This post is a short description of the tools and techniques I’ve been using and hope to receive suggestions to techniques I have been missing.
The tool in question is ltrace, which I believe is a doing of mostly the Debian project (I can be wrong), with a port to FreeBSD which is what I have been using. I have spent enough hours trying to just read source code, using grep to look for where to look for my next step.
Read on for descriptions!
Recent Comments