Well, I’m glad to be back in the land of the living - I’ve been doing so much travel lately, I feel like my brain is melting. I’ll be traveling several more times this month too. However, I’ve learned a lot in my travels, and now it’s just a matter of sitting down and prioritizing what’s important and writing it all down. So just for starters, here’s something I have been playing with. Lately I’ve been playing around with a predictable resource locater that I wrote which eventually got morphed into a PHP RFI (remote file includes) attack tool to speed up certain types of audits. Yes, other people have built these kinds of things before, but I haven’t so it was an interesting exercise for yours truly.
Anyway, I started really looking at milw0rm pretty heavily, just looking through pages and pages of historical RFI disclosure reports. At first glance, it’s really ugly. None of it is consistent, half of it is almost entirely designed to make cutting and pasting the exploit a pain in the butt, and there are the other bad guys. Let’s take two examples. The first is from a PeopleAggregator exploit:
Pretty simple, just replace the word shell with your PHP shell on your server, pre-pend the domain name and poof, you’ve got yourself a working exploit. Now let’s look at a bad one from a Component JoomlaPack exploit:
Someone not familiar with how RFI works could easily just prepend the vulnerable machine name, not knowing what it would do, but in turn they are owning it with a working shell from a live server. This gives the author of the exploit access to many more machines without a) having been the person to perform the vulnerability, and b) having to scan for the vulnerable application (or even necessarily having access to it). In some cases the vulnerable machine may be behind a firewall and accessible only to internal staff. Now you’ve not only owned the machine but potentially installed shell that can connect back to a parent (via IRC probably) and give the attacker a way into the network.
There are lots of variants of this, that I’ve seen now. Another one that’s pretty clever is from a phpMyPortal exploit. The way the exploit is written it requires that you throw it up on a webserver somewhere (probably yours if you are testing to see if your install is vulnerable) and poof you install a backdoor from spy-art.com. Nasty.
We’ve seen this kind of thing happen before with shell code that’s been written to own the user who runs it, and this is no different. Watch out for those crazy vulnerability reports. And this is yet another reason to make sure your soft juicy internal networks are secure too. When in doubt if you don’t understand the report, rather than running it yourself, it’s probably better left to the experts.