Written by Taylor Hawes
Wednesday, November 6th, 2013
In May of 2013, former National Security Agency contractor Edward Snowden fled the United States with classified documentation revealing some of the most sophisticated and prolific public spying in American history. The PRISM program he divulged is an extensive campaign that utilizes classified intelligence directives to acquire “metadata” from major Internet players like Google and Yahoo. Since then, Snowden has brought to light myriad directions of similar ilk, geared toward data collection in the name of intelligence efforts.
In a recent leak, however, it was revealed that PRISMs scope pales in comparison to the NSA’s international data mining project, known by the acronym MUSCULAR and run in tandem with the British GCHQ. The program, it was shown, utilizes the linkages between Google and Yahoo data centers, mining entire data flows and shipping the data back to NSA data warehouses in Fort Meade.
The NSA program utilizes a structural flaw in the two companies’ architecture. Yahoo and Google maintain high speeds through decentralized data centers spanning multiple continents and connected by thousands of miles of fiber optic cable. In order to maximize performance, these data centers continuously sync information between repositories, including whole user accounts and email indexes.
In order to obtain the information desired, the NSA needed to circumvent exemplary data security protocols. These protocols include 24-hour guards, biometric identity verification, and heat-sensitive camera at data centers. According to the article in the Washington Post, company sources had reason to believe that their internal networks were safe.
Despite these measures, a weakness was uncovered. An internal NSA slide show leaked by Snowden contained a hand-drawn diagram outlining the transition point between Google internal networks and user computers. The drawing highlighted Google front-end servers as the weak point, noting that these servers actively decrypted information and could be exploited for data acquisition purposes.
Neither company was aware of the backdoor intrusion. Both companies acknowledge and acquiesce to front-end requests for data but maintained that their internal networks were secure. Google vice president for security engineering Eric Grosse even announced plans to encrypt linkages between data centers with the presumption of security.
Since the leak, both companies have reacted in outrage. Google’s chief legal officer, David Drummond remarked on the subject: “We have long been concerned about the possibility of this kind of snooping, which is why we have continued to extend encryption across more and more Google services and links, especially the links in the slide.” Yahoo commented: “We have strict controls in place to protect the security of our data centers, and we have not given access to our data centers to the NSA or to any other government agency.”
Legally speaking, the NSA is exploiting a loophole related to international espionage practices. While Congressional oversight has limited domestic spying, international monitoring remains less inhibited. Because the data centers of the two Internet giants span multiple continents, interception of these data flows is technically permitted under Section 702 of the FISA Amendments Act of 2008.
This international monitoring occurs with the cooperation of the British GCHQ. The UK agency maintains a data cache that can hold three-to-five days of traffic data before recycling storage. During this time, NSA software utilizes search terms in order to sift desirable data from the dredges. This data, once identified, is shipped via fiber-optic cables to the data warehouses in Fort Meade. This information, the agency claims, has produced intelligence leads against “hostile foreign governments.” At this point, this assertion of intelligence value remains largely unsubstantiated, likely due to the classified nature of such leads.
The scope of the MUSCULAR program lies in the volume of search terms used while sifting through acquired data. According to records, these inquires include 100,000 terms, more than two-fold the amount used in the PRISM program. The volume indicated in the Washington Post’s documents topped 181 million records over a 30 day period. The data acquired includes who sent or received emails, the subject of these emails, when and where they were sent, and the text, audio, and video content of these messages.
The program strikes a chord with both companies due to its unique nature. Both organizations were willing participants in the collection of data through front-end means, but the back-end intrusion remains uncharacteristically aggressive. Google, as mentioned, will move to encrypt its internal networks, however Yahoo has not indicated whether it will do the same.
The ramifications of these revelations is yet to be seen. However it is likely that, in the wake of negative public reaction to the PRISM documents, the sentiment will be similar. Ultimately, the continued exposure of agency programs continue to demonstrate the inter-connected and heavily monitored nature of our digital communications; a fact that can no longer go unacknowledged.
Written by Sean Valant
Friday, August 23rd, 2013
Yesterday (August 22nd, 2013) a massive number of IP addresses used for email gateways on virtually every webhost in the world became blacklisted on multiple networks. This resulted in a global inability for email to be received (any time the email originated from one of the blacklisted IPs and was “received” on one of the blacklisting networks).
The issue is on-going at the time of this writing, and some customers are still being affected at this moment, however HostGator was one of the first companies to successfully mitigate the situation and we have since been assisting other companies with this issue. As it stands, we are presently working to now get our IP’s removed from the blacklists and restore full worldwide email deliverability from our network.
This situation resulted from a combination of multiple factors stretching back a few months. Before we explain the circumstances, we want to once again stress the importance of keeping all scripts on all hosting accounts updated. Failure to update scripts, as well as not exercising basic security practices, is what allows situations like this to continue to occur. An out-dated script on a hosting account is akin to an unlocked car left in a parking lot… it’s an invitation for maliciousness by unscrupulous individuals.
Unlike the situation back in April that affected WordPress, this time the target was Joomla. Back in May, there was a string of exploits against known vulnerabilities in Joomla. These vulnerabilities, related to a component called JCE, had been previously addressed via certain mod_sec rules. However, a workaround was discovered that allowed malware to be installed, and later activated, to allow the uploading and execution of mailing scripts.
These mailing scripts were activated en masse yesterday, beginning a massive spamming campaign resulting in the blacklisting of email gateway IPs worldwide. One of the largest networks with users reporting issues initially was AOL, resulting in us creating this forum post.
As with all issues of this nature, there are lessons to be learned. The most important lesson here is to (again) keep all scripts on your hosting account up-to-date. Most scripts have a one-click feature to update them anytime a new version is released. Keeping scripts up-to-date is paramount in ensuring a secure hosting account.
HostGator has now added additional monitoring capability to our systems which will alert us to situations like this even faster than yesterday. Our work is on-going, though we should have the majority of the blocks resolved by tomorrow (spam lists move slow, with good reason). But remember, there is no better way to keep your car safe than to lock it. Please take this moment to log into your hosting script back-ends and ensure they are up-to-date. Don’t give the bad guys an open door to walk through.
Written by Sean Valant
Monday, April 29th, 2013
WordPress has been under fire lately, though it is important to note that although WordPress has been the target that there is truly nothing the platform has done to cause these recent circumstances to occur. You may have heard about the recent distributed brute force attack, which is presently on-going still and targets the “admin” user name.
A subsequent, and slightly lower-level attack has since been launched against popular WordPress plugins, like WPSuperCache and W3TotalCache. While we did identify this circumstance very early on and take pre-emptive measure to effective mitigate this attack on our server farm, it simply reiterates a point we often try to make: please make sure your scripts and plugins are always up-to-date.
Metaphorically speaking, having out of date scripts or plugins installed is akin to having a very nice house, with a very nice door with a very nice deadbolt on it that you simply choose to not engage, effectively leaving your door wide open to anyone what wants to walk in and do as they see fit with your property.
As a web host, we provide the house, the door and the lock. We also hand you the key to the lock on the door, but we cannot force you to engage that lock, we can only highly encourage you to do so.
One thing to note in regards to keeping your script installs themselves up to date is that HostGator’s proprietary script install tool, QuickInstall, does allow you to opt in to automatic updates for WordPress and other popular scripts. We highly encourage you to utilize QuickInstall and it’s automatic update functionality.
Please take a moment to log into the dashboards of all of your CMS-backend websites and take a moment to ensure everything is up-to-date. Otherwise, you are choosing not to engage that deadbolt on your front door and ultimately welcoming in all manner of individuals who may not have your best interests in mind.
Written by Sean Valant
Thursday, April 11th, 2013
As I type these words, there is an on-going and highly-distributed, global attack on WordPress installations across virtually every web host in existence. This attack is well organized and again very, very distributed; we have seen over 90,000 IP addresses involved in this attack.
At this moment, we highly recommend you log into any WordPress installation you have and change the password to something that meets the security requirements specified on the WordPress website. These requirements are fairly typical of a secure password: upper and lowercase letters, at least eight characters long, and including “special” characters (^%$#&@*).
You have now changed your WordPress password, correct? Good.
The main force of this attack began last week, then slightly died off, before picking back up again yesterday morning. No one knows when it will end. The symptoms of this attack are a very slow backend on your WordPress site, or an inability to log in. In some instances your site could even intermittently go down for short periods.
We are taking several steps to mitigate this attack throughout our server farm, but in the same breath it is true that in cases like this there is only so much that can actually be done. The servers most likely to experience service interruptions will be VPS and Dedicated servers hosting high numbers of WordPress installations, due to the incredibly high load this attack has been seen to cause.
If you are hosted on a VPS or Dedicated server and you would like for us to take a more severe, heavy-handed approach to mitigate this attack, we can do this via means such as password-protecting (via .htaccess) all wp-login.php files on the server. If you would like our assistance with this, please contact us via normal support channels.
Again, this is a global issue affecting all web hosts. Any further information we could provide at this moment would be purely speculation. Our hope is that this attack ends soon, but it is a reminder that we must all take account security very seriously.
We will update this blog post when we have further information.
If you have just a few WordPress sites, you can add the additional layer of security mentioned above, as well as block this attack, by following the instructions outlined in this article from our KnowledgeBase: http://support.hostgator.com/articles/specialized-help/technical/wordpress/wordpress-login-brute-force-attack