27 May 2013. Updated.
26 May 2013
Cryptome Infected with Cookie Script
Recently Cryptome's ISP, or malware, began returning a cookie for HTML
accesses like this:
document.cookie='ooooooo=3d01dac1ooooooo_3d01dac1; path=/';window.location.href=window.location.href;
We are trying to locate and eliminate the script which is not visible to
us. Purge cookies and turn off.
A3 sends:
I noticed the nasty cookies a couple of days ago and have seen your reference
to them on the site in the last few hours.
http://whois.domaintools.com/205.178.145.72
reveals the names of 4 other sites of the *384* hosted at that IP address:
http://1freespirit.com
http://1stpentecostal.org
http://abingdonkiwanis.org
http://acescasinonights.com
Looking at each of those sites shows that they are all serving the same corrupt
content, therefore the server is compromised.
I suggest that your best course of action is to shift the site to another
host, or at least to another server. It seems from other's experiences that
this may be faster and easier than getting Network Solutions to fix their
machine.
http://www.webhostingtalk.com/showthread.php?t=1255471
Network Solutions response to Cryptome's service request:
Subject: Network Solutions - Service Request # 1-673273482
Date: Mon, 27 May 2013 02:50:20 +0800
From: "Network Solutions"
<customerservice[at]networksolutions.com>
To: "John Young" <jya[at]pipeline.com>,
Dear John Young,
I apologize for any inconvenience. I received your online ticket regarding
the concealed script that has implanted on your site.
You can take advantage of our MyTime Support Service for only $ 59.99 wherein
a dedicated person will take care of your request. You can contact us using
the number listed below for better assistance.
I hope this information has been helpful. If you have any other questions
about this issue, please contact our Support Center and refer to Service
Request 1-***273482. A Specialist will be happy to further assist you and
ensure that we completely resolve your issue as quickly as possible.
Thank you,
KEVIN050
Technical Support Specialist
Network Solutions
US/Canada: 1.866.391.4357
International: 1.570.708.8788
(c) Copyright 2013 Network Solutions, LLC. All rights reserved.
A2 sends:
About the cookie-related shenanigans: similar behavior has been observed
in the past by others on other websites. For example:
- 2005:
http://nepacrossroads.com/about28856.html
- 2011:
http://webmasters.stackexchange.com/questions/41098/gwt-big-traffic-change-
for-top-url
- 2012:
https://www.secure.versio.nl/954-php_error_documentcookiebbbbbb.html
- 2013:
http://productforums.google.com/forum/#!msg/webmasters/CCHRHVV_3fA/B_
HQdIlzXkkJ
Comments below the 2012 link suggest it might be related to a(n
application-level) firewall; I think it might just as well be
performance/benchmarking-related.
I have not yet been able to find any product or service that employs a
cookie-injecting HTML page. I took a look at the webservers in the range
205.178.145.60-80, and found that 205.178.145.65 behaves similar to
205.178.145.72.
The injection seems to be done for ALL websites running at those webservers;
it is not bound to any specific domain/website. The cookie is not set with
an Expires-parameter, which means it is a session cookie that will be deleted
once the user closes his/her browser. Hence I do not even consider it to
be a privacy invasion.
In conclusion: the cookie shenanigans is not specific to Cryptome and there
is no reason to believe it is anything else than a nuisance.
A sends this analysis:
Cryptome ISP sets the cookie via javascript before any Cryptome page is loaded.
If this is disabled, no Cryptome page will load.
This is the entire content of the very first page that loads from 205.178.145.72
when accessing http://cryptome.org from the browser for the first time:
<html><body><script>document.cookie='vvvvvvv=aacad09avvvvvvv_aacad09a;
path=/';window.location.href=window.location.href;</script></body></html>
Then 205.178.145.72 sends RESET packet.
Once this cookie is set and transmitted to 205.178.145.72 once, the subsequent
cryptome.org pages will load OK from the same browser instance although the
cookie is deleted and js disabled. It appears that the originating browser-side
socket is memorized on the server side, and subsequent requests served to
requests coming from that socket.
This effectively disables access from javascript-disabled browsers, although
js is not really used on cryptome.org. Perhaps intentional, perhaps not.
Cookies on the subsequent requests are sent in plaintext, and although cryptome
site may not be using them, it's trivial to scan network traffic for that
pattern and Cryptome requests will stand out.
|