search engine poisoning/iframe insertion in url

worried · Post by **worried** » Sun Mar 09, 2008 9:31 pm

there's been a rash of this lately, using bogus querries to other engines to insert malware/adware iframes into the indexed urls. google still has thousands of these active, just search for

allinurl: search OR results "iframe src"

firefox2 is not immune, try any one of the following (sanitized for your surfing safety) links

http://www.aoa.gov/search/search.asp?q= ... 3E&s=&r=50
http://www.aoa.gov/search/search.asp?q= ... 3E&s=&r=50
http://www.aoa.gov/search/search.asp?q= ... 3E&s=&r=50
http://www.aoa.gov/search/search.asp?q= ... 3E&s=&r=50

check the page info and you will find that all the injected links have been downloaded.

Question: is there any way we can use adblockPlus to prevent downloading the drek short of compiling and maintaining an active malware site list?

rick752 · Post by **rick752** » Sun Mar 09, 2008 10:02 pm

Is there any instance in the wild that you know of?

From your example, it is hard to tell. All I know is that:

Code: Select all

|http://google.com/|$subdocument

... would block that particular iframe.

Is the query actually called "live' when you visit an infected site? If so, the query itself should be able to be blocked by using some kind of $subdocument block against the google query.

worried · Post by **worried** » Sun Mar 09, 2008 10:41 pm

rick,

just try the google query listed above, that's what the AoA prototype is from. this will return thousands of "live", potentially lethal examples.

this is really a firefox issue (what the hell are they doing retrieving an iframe buried in a url?) but until they get a fix it would be good to have a stopgap.

the problem is that there are an unlimited number of potential malware sites out there, no possible way to track them in real time. what's wanted is to block the "form" of the iframe (buried in a url) rather than the "substance" (whatever drek it points to).

even better would be to block all iframes that aren't a part of the html body. then when some lazy cheezeball tacks an iframe onto the beginning or end of a defaced page, we would just dumpit. perhaps that could be done with a contentPolicy change, but i have no idea how.

rick752 · Post by **rick752** » Sun Mar 09, 2008 10:56 pm

Ah ... I see now.
No link ... no site

Code: Select all

#a(href*=?q=)(href*=%3CIFRAME)

rick752 · Post by **rick752** » Sun Mar 09, 2008 11:07 pm

2nd EDIT (Added 3rd rule):

Actually rules like these may be better:

Code: Select all

#a(href*=%3CIFRAME+src)
#a(href*=%3Ciframe+src)
#a(href*=%3Ciframe%20src)

Can't click what you can't click.

Wladimir Palant · Post by **Wladimir Palant** » Sun Mar 09, 2008 11:20 pm

About "firefox2 is not immune": This is not a browser issue but an XSS (cross-site scripting) vulnerability on the site in question. Unfortunately, at least 80% of the sites have XSS vulnerabilities. There is little a browser can do about this. Using SiteBlock extension to block anything that has "%3Ciframe" in the address might be a good idea however - I see only one valid reason to have this in an address, namely that you are searching for "<iframe" on Google & Co.

worried · Post by **worried** » Mon Mar 10, 2008 12:34 am

rick - thanks, i'll try those.

wladimir - sorry, imho this is a bowser flaw. if the url is properly escaped (and most of these are) the bowser should Not unescape them and interpret them as a "free floating" html tag. this is taking "quirks mode" to a ridiculous extreme.

these particular examples are the fault of the original search engine not properly validating the input and google not validating/sanitizing the urls it is delivering (none of the urls are recognized as pointing to "bad" places by google). none of these sites has been "compromised", just gamed by their greed for page rankings. a full rundown can be found at

http://ddanchev.blogspot.com/

afik these same urls show up on msn, yahoo, etc. with the same results. firefox2 is a great bowser and shouldn't be porked by such simple silliness.

worried · Post by **worried** » Mon Mar 10, 2008 3:04 am

update:
rick - the cached versions are just as dangerous as the direct links. the following set seems to nail most of the baddies.

google.com#a(href*=3Ciframe-src)
google.com#a(href*=3Ciframe+src)
google.com#a(href*=3CIFRAME-src)
google.com#a(href*=3CIFRAME+src)
google.com#a(href*=3Ciframe%2Bsrc)
google.com#a(href*=3CIFRAME%2Bsrc)

hopefully this will suffice until google hoses out their cache. or the bad guys figure out how many possible case combinations there are for
"iframe src" ...

worried · Post by **worried** » Mon Mar 10, 2008 7:24 pm

update2: oops, missed one. the set should be

google.com#a(href*=3Ciframe-src)
google.com#a(href*=3Ciframe+src)
google.com#a(href*=3CIFRAME-src)
google.com#a(href*=3CIFRAME+src)
google.com#a(href*=3Ciframe%20src)
google.com#a(href*=3Ciframe%2Bsrc)
google.com#a(href*=3CIFRAME%20src)
google.com#a(href*=3CIFRAME%2Bsrc)

these hide the potentially lethal ones while letting the "harmless" ones thru. for msn, yahoo etc. you're on your own ...

Wladimir Palant · Post by **Wladimir Palant** » Mon Mar 10, 2008 7:54 pm

worried wrote:wladimir - sorry, imho this is a bowser flaw. if the url is properly escaped (and most of these are) the bowser should Not unescape them and interpret them as a "free floating" html tag.

The "bowser" isn't doing anything in this case - other than passing (escaped) parameter to the side. It is the site (a script on the server) that is unescaping the parameter and inserting it into the resulting HTML code. And the browser is only displaying what it gets then. The site should validate parameters properly.

worried · Post by **worried** » Tue Mar 11, 2008 7:52 pm

wladimir - many thanks for the enlightenment. using the "sanitized" link

http://www.wired.com/search?query=presc ... le.com/%3E

and doing the ol' view source shows that toward the bottom wired helpfully advises

Code: Select all

<h3>Your search - prescription drug tramadol <iframe src=//google.com/> - did not match any documents.</h3>

which ff2 interprets as a perfectly valid iframe and fetches like a good "bowser". it's wired's screwup, not ff2.

BTW: there's a "not very good but better than nothing" Adblock (not Plus) list of current malware dispensers available at http://www.malware.com.br. perhaps rick or one of the other list maintainers could chat with the operators about outputting a Plus compatible .txt file for a subscription?

worried · Post by **worried** » Wed Mar 12, 2008 9:29 pm

update3: they have been busy, script tags are now being injected as well. copy the following into a text editor and save it somewhere as googlePoison.txt (or whatever you like). then just import it into your adblockPlus filter list.

Code: Select all

[Adblock Plus 0.7.1]
!-
!- googlePoison
!-	simple element hiding filters for google
!-	hides poisoned links so they can't be clicked
!-
google.com#a(href*=3Ciframe-src)
google.com#a(href*=3Ciframe+src)
google.com#a(href*=3CIFRAME-src)
google.com#a(href*=3CIFRAME+src)
google.com#a(href*=3Ciframe%20src)
google.com#a(href*=3Ciframe%2Bsrc)
google.com#a(href*=3CIFRAME%20src)
google.com#a(href*=3CIFRAME%2Bsrc)
!-
google.com#a(href*=3Ciframe%2520src)
google.com#a(href*=3Ciframe%252Bsrc)
google.com#a(href*=3CIFRAME%2520src)
google.com#a(href*=3CIFRAME%252Bsrc)
!-
google.com#a(href*=3Cscript-src)
google.com#a(href*=3Cscript+src)
google.com#a(href*=3CSCRIPT-src)
google.com#a(href*=3CSCRIPT+src)
google.com#a(href*=3Cscript%20src)
google.com#a(href*=3Cscript%2Bsrc)
google.com#a(href*=3CSCRIPT%20src)
google.com#a(href*=3CSCRIPT%2Bsrc)
!-
google.com#a(href*=3Cscript%2520src)
google.com#a(href*=3Cscript%252Bsrc)
google.com#a(href*=3CSCRIPT%2520src)
google.com#a(href*=3CSCRIPT%252Bsrc)
!

i expect that this list will grow ...