Anonymizing RFI Attacks Through Google

netbuzz writes "Noam Rathaus on his SecuriTeam blog describes a technique by which 'Google can be utilized to hack into websites — actively exploiting them (not information gathering by the use of "Google hacking," although that is how most of the sites vulnerable to RFI attacks are found).' He cites examples in the wild and even mentions that the technique could be used as a 'covert' communications channel."

Comments

but is it a crime...

[Sensor]

There is actually quite an interesting aside to this, would someone who used this technique actually be guilty of hacking? Afterall they don't run the exploit and arguably can't guarentee that anyone will.

If I happen to create a utility capable of cracking a site but then store it for research, never distribute and never actively use then I've not committed a crime. If I distribute it to other researchers in good faith then I'm covered - at present its only the person who actively uses it that is guilty of a crime.

However, in this scenario (even if I could be traced) its arguable that *I* never attacked a site, all I did was to place a tool that could be used in that way in a public location. I'm not sure that would completely stand up given the recent ammendment to the UKs computer misuse act (i.e. reasonable belief that the tool would not be used in that fashion), but still...

As always it comes down to people...

PS:
Aas an aside I am currently running a survey for my MSc dissertation on IT admin access to confidential information. If you'd like to help out (and would like a shot at winning a £25 or $40 amazon voucher) then please take a look at:

https://msc-survery.priogenus.com/amazon.php

Anonymous?

[tttonyyy]

Aside from triggering the attack, how does this make it anonymous?

Surely the "http://URI-with-malicious-code.php" section will still create logs on the victim server pointing to the source of the malicious code (but perhaps not who triggered it).

Re:Anonymous?

[Zedrick]

Yes, but the URI-with-malicious-code is usually something like: http://www.geocities.com/xxxxxxx/xxx.txt

At least that's what I usually see every time I check the logs of a website I'm going to shut down for allowing foreign includes (to be run).

change behaviour for bots

[cucucu]

In your server, you can code the logic to take another action if the user agent is a bot.
Here you have a db of web robots.

How not Who

[MartinJW]

If your web application is vulnerable to attack then I would have thought it makes no difference where that attack comes from - be it a 'real' person or a search bot. You should spend more time worrying about whether your application is secure, the how is more important than the who.

Remote File Inclusion

[Bogtha]

Remote File Inclusion. It's a pretty poor term for this type of attack, because it's not the act of inclusion that causes the problem, it's the act of requesting the file in the first place.

RFI? How about defining this?

[Ashtead]

Radio Frequency Interference? Request for Information? Radio France Internationale? Rodent Fangs Implementation? WHAT?

How about explaining what such an ambigious acronym actually means initially. As neither TFA nor the summary seems to have done so, I therefore will have do it here, just to make heads and tails of the rest of the discussion and perhaps illuminate someone else. Hit Google, slog through a pile of links indicating one of the above, or some company whose name includes the three letters. There are many of these. On Page 3 I found the Wikipedia page for this TLA, on which there is a dead link to what this must be: Remote File Inclusion.

How about that.

I was wondering if it was just me, that I had been off-line for too long (like 2 days) and missed out on the latest and greatest buzzword, again?

Re:RFI? How about defining this?

[hey!]

I'm guessing from the text of the article it is Remote File Inclusion.

The description of the mechanism doesn't really makes sense. If you can exploit a victim site by feeding it an evil URL in a form parameter, why use Google at all? You've lost anonymity by including the URL.

Looking at the described effects, it sounds like what they do is feed google some malicious code wrapped up in something that looks like a URL on the victim site. Then Google spiders the URL, placing malicious content in the form parameters.

So, suppose you have a malicious SQL injection attack that causes your database dump the password table to a remote database. The trick is that you get Google to launch the attack for you. You have the malicious code obfuscate the destination, and it isn't clear skullduggery is going on by casual inspection of the logs. It won't show up in the database logs either because its not a transaction.

Simple solution

[vivekg]

Seriously, I hate to read article like this one. They don't offer any solution.....this kind of attacks are not new at all, you can find tons of such attacks from access.log file/p> tail -f /var/log/httpd/access.log

First get rid of fat apache and use like small and secure lighttpd if you are running a *small personal* web site. Second put lighttpd / Apache in chrooted jail and no one can install *php/perl* shell. I have documented the procedure for putting lighttpd in jail:

http://www.cyberciti.biz/tips/howto-setup-lighttpd -php-mysql-chrooted-jail.html

Both yahoo and google runs entire webserver in chrooted jail. Other choice is use OpenBSD which runs Apache in chrooted jail out of box.