Paid Advertising
web application security lab

The Danger of Pre-canned RFI Exploits

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 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.

4 Responses to “The Danger of Pre-canned RFI Exploits”

  1. hackathology Says:

    Hi Rsnake, its been a long time since you last post. I had been auditing banking applications recently and i came across a lot of applications that allow shell code execution or command execution. It may or may not be RFI attack, but i can proudly say that it is dangerous and banks are not taking it seriously. To them, security is just a small part of the process and more importantly, they are concerned with the functionality and usability of the applications. Well, its sad because if the banks are not secure and vulnerable, how can we entrust our hard earned money to them? :(

  2. Daniel Says:


    I don’t think this is the case at all. I’ve spent the past 6 years working for very large and well known investment/high street banks and generally they have been clued up on the SDLC process.

    One factor is budget; Banks have a shitload of it so therefore often have more spending power than your smaller FTSE/NYSE listed company.

    The issue I have been finding is that business logic flaws are common factor, mainly because not many testers know how to look for them but also developers generally don’t think like attackers.

    As for backdooring exploits, that’s older than most things and i remember gobbles code was backdoor’d more often than normal, with loads of muppets happy to run shellcode they had no idea about.

    this stuff comes full circle as usual

  3. hackathology Says:

    Well, for me, the banks here are really prone to command injection and other injection flaws. Of course i do agree that business logic flaws are common too, but from my perspective here, i had been successful with lotsa injection flaws and found quite a number of risky things.

  4. Dr.C Says:

    Hlo again Mr. Snake Sir!

    Long time since I got a first into to Java AppSec testing, while working on a major health care App–those great XSS resources at your site were a ton of help! Did a POC with a Phish on 5 of their 7 landing pages, showing I could collect uid/pwd at my and still do a successful pass-through AA.

    After that, went to a major financial site and their concerns were layers 2-4/audit, even though they had demonstrable flaws on their website, which used asp (that means “always security problems” I think). You’d expect that multiple XSS would matter enough to fix existing code, even if a new release using .NET was 6 months away, but apparently not. After that, I decided I’d better start buying gold, because there was no telling where my bank account might wind up.

    Thanks again for some great resources,