|
||
|
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; 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 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 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 (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:
- 2011:
http://webmasters.stackexchange.com/questions/41098/gwt-big-traffic-change- - 2012: https://www.secure.versio.nl/954-php_error_documentcookiebbbbbb.html
- 2013:
http://productforums.google.com/forum/#!msg/webmasters/CCHRHVV_3fA/B_ 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.
|