Page 1 of 1
search engine poisoning/iframe insertion in url
Posted: Sun Mar 09, 2008 9:31 pm
by worried
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?
Posted: Sun Mar 09, 2008 10:02 pm
by rick752
Is there any instance in the wild that you know of?
From your example, it is hard to tell. All I know is that:
... 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.
Posted: Sun Mar 09, 2008 10:41 pm
by worried
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.
Posted: Sun Mar 09, 2008 10:56 pm
by rick752
Ah ... I see now.
No link ... no site
Posted: Sun Mar 09, 2008 11:07 pm
by rick752
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.
Posted: Sun Mar 09, 2008 11:20 pm
by Wladimir Palant
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.
Posted: Mon Mar 10, 2008 12:34 am
by worried
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.
Posted: Mon Mar 10, 2008 3:04 am
by worried
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" ...
Posted: Mon Mar 10, 2008 7:24 pm
by worried
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 ...
Posted: Mon Mar 10, 2008 7:54 pm
by Wladimir Palant
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.
Posted: Tue Mar 11, 2008 7:52 pm
by worried
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?
Posted: Wed Mar 12, 2008 9:29 pm
by worried
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 ...