PHP version 5.6 through PHP 7.1 has become EOL. Host 99 is the only Host provider that allows these versions until 2020. We must act to meet new server technology
PHP version 5.6 through PHP 7.1 has become EOL
PHP version 5.6 through PHP 7.1 has become EOL. Host 99 is the only Host provider that allows these versions until 2020. We must act to meet new server technology
New changes are coming to the SAQs!
Self-Assessment Questionnaires (SAQ) are forms used by eligible organizations to report the results of a PCI Data Security Standard (PCI DSS) self-assessment. On 30 January, the PCI Security Standards Council
PHPMailer Security Advisory (PCI Compliance & Standard Accounts Effected)
Exploit type: Remote Code Execution in third-party PHPMailer library CVE Numbers: CVE-2016-10033 and CVE-2016-10045 http://www.securityweek.com/critical-rce-flaw-patched-phpmailer All versions of the third-party PHPMailer library distributed are vulnerable to a remote code execution
Did you know SHA-1 is no longer secure?
Find out what you need to do to update your security and protect your data! What is SHA? Contrary to popular belief, SHA is not an encryption. SHA stands for
PHP version 5.6 through PHP 7.1 has become EOL
PHP version 5.6 through PHP 7.1 has become EOL. Host 99 is the only Host provider that allows these versions until 2020. We must act to meet new server technology and to be able to offer new features that we currently cannot to our customers.
Dates of Deprecation:
PHP 5.6 End of Life happened on December 31, 2018.
PHP 7.0 End of Life happened on January 10, 2019.
PHP 7.1 End of Life happened on December 1, 2019.
Current Status: X represents not available after marked dates
Laravel 5.7: PHP >= 7.1.3 – X
Craft CMS 3.0.25: PHP >= 7.0 -X
WordPress 4.9.8: PHP >= 7.2
Symfony 4.1: PHP >= 7.1.3 -X
Neos 4.0: PHP >= 7.1 – X
Drupal 8: PHP >= 5.5.9 -X
PHPUnit 7: PHP >= 7.1 -X
Within the past 3 years. Starting January 1, 2020. Host 99 technicians will start pulling these versions and will not longer function. There is no further support or patches for these versions and they are deemed a HIGH security risk to be in use and are not PCI-DSS Compliant.
Please proceed to update as soon as possible to avoid downtime. If you have any questions please feel free to contact us, our technicians will assist you with your requests.
#pcicompliance #newfeatures #bettersecurity #prosper #webhosting #security #development #ecommerce #zencart #wordpress
PHP version 5.6 through PHP 7.1 has become EOL
PHP version 5.6 through PHP 7.1 has become EOL. Host 99 is the only Host provider that allows these versions until 2020. We must act to meet new server technology and to be able to offer new features that we currently cannot to our customers.
Dates of Deprecation:
PHP 5.6 End of Life happened on December 31, 2018.
PHP 7.0 End of Life happened on January 10, 2019.
PHP 7.1 End of Life happened on December 1, 2019.
Current Status: X represents not available after marked dates
Laravel 5.7: PHP >= 7.1.3 – X
Craft CMS 3.0.25: PHP >= 7.0 -X
WordPress 4.9.8: PHP >= 7.2
Symfony 4.1: PHP >= 7.1.3 -X
Neos 4.0: PHP >= 7.1 – X
Drupal 8: PHP >= 5.5.9 -X
PHPUnit 7: PHP >= 7.1 -X
Starting January 1, 2020. Host 99 technicians will start pulling these versions and will not longer function. There is no further support or patches for these versions and they are deemed a HIGH security risk to be in use and are not PCI-DSS Compliant.
Please proceed to update as soon as possible to avoid downtime. If you have any questions please feel free to contact us, our technicians will assist you with your requests.
#pcicompliance #newfeatures #bettersecurity #prosper #webhosting #security #development #ecommerce #zencart #wordpress
New changes are coming to the SAQs!
Self-Assessment Questionnaires (SAQ) are forms used by eligible organizations to report the results of a PCI Data Security Standard (PCI DSS) self-assessment. On 30 January, the PCI Security Standards Council (PCI SSC) issued revised SAQs for use with PCI DSS version 3.2. In this Q&A with PCI SSC Senior Director of Data Security Standards Emma Sutcliffe, we look at what merchants need to know about new updates to the SAQs .
SAQs were updated with the publication of PCI DSS 3.2 in April 2016, so why is the PCI Council making changes to the SAQs now?
Emma Sutcliffe: The changes clarify points of confusion PCI SSC has heard from industry stakeholders since the SAQs were updated to align with PCI DSS version 3.2 in April 2016. This type of update is what we call an “errata”, which is a way for us to correct language that wasn’t clear enough and to fix typos and grammatical errors.
This is not a major update, but the changes do include the addition of guidance and may impact how SAQs are filled out. Additionally, some merchants may need to start validating to additional requirements, so it’s important for merchants to review their applicable SAQ and work with their merchant (acquiring) banks to understand any implications for them.
Are there any new SAQs?
Emma Sutcliffe: No, there are no new SAQs. Currently there are nine SAQs, each one intended to meet a different scenario based on how an organization stores, processes, or transmits cardholder data. The errata introduces minor updates to several of the existing SAQs.
Which SAQs are affected?
Emma Sutcliffe: The updated SAQs are SAQ A: Card-not-present Merchants, All Cardholder Data Functions Fully Outsourced; SAQ B-IP: Merchants with Standalone, IP-Connected PTS Point-of-Interaction (POI) Terminals – No Electronic Cardholder Data Storage; SAQ-C: Merchants with Payment Application Systems Connected to the Internet – No Electronic Cardholder Data Storage; and SAQ-C-VT: Merchants with Web-Based Virtual Payment Terminals – No Electronic Cardholder Data Storage.
What are the key changes merchants should be aware of?
Emma Sutcliffe: The updates include the addition of two requirements to SAQs B-IP and C-VT. The first is Requirement 8.3.1 (use multi-factor authentication for all non-console administrative access into the cardholder data environment). Merchants that perform administrative access via non-console connections are already required to secure these connections with strong cryptography (Requirement 2.3), and the addition of Requirement 8.3.1 provides consistency for how these connections are secured.
The second requirement added to these SAQs is Requirement 11.3.4 (verify segmentation controls, if segmentation is used). SAQs B-IP and C-VT both require that specific device types be used, and that the defined devices are not connected to other systems. The addition of Requirement 8.3.1 in SAQs B-IP and C-VT is consistent with requirements in other SAQs for merchants using segmentation.
Details of the changes for each SAQ can be found in the “Document Changes” table near the top of each SAQ.
When do merchants need to begin using the updated SAQs?
Emma Sutcliffe: There is a transition period to allow merchants time to review changes to applicable SAQs and prepare to adopt them. Merchants may continue to use the SAQs published in April 2016 (Rev. 1.0) until 30 September, 2017. Starting on 1 October 2017, merchants will need to use the updated SAQs (Rev. 1.1, published on 30 January 2017). Prior to 1 October 2017, merchants can use either the April 2016 or the January 2017 version of the SAQs.
How do merchants determine which SAQs they are eligible to use?
Emma Sutcliffe: Merchants should contact their acquirer or the applicable payment brand(s) to understand if they are eligible or required to submit an SAQ, and if so, which SAQ is appropriate for their environment. The SAQ Instructions and Guidelines document also provides additional guidance about the PCI DSS self-assessment process and the different SAQs.
PHPMailer Security Advisory (PCI Compliance & Standard Accounts Effected)
Exploit type: Remote Code Execution in third-party PHPMailer library
CVE Numbers: CVE-2016-10033 and CVE-2016-10045
http://www.securityweek.com/critical-rce-flaw-patched-phpmailer
All versions of the third-party PHPMailer library distributed are vulnerable to a remote code execution vulnerability.
We have listed a few applications effected. Immediate upgrade is required to avoid interruptions to the PHP mailer system built within your application. To protect our servers and networks this required action is not exceptional and must be repaired to avoid such actions and interruptions.
Software Known To the Advisory and thousands of others:
1. WordPress
2. Zen-Cart – 15.4 Versions & below. 1.5.5 claims to fix this issue.
2. OpenCart
3. CubeCart
4. WHMCS
All the listed above are known as well as many others. This critical PHPMailer flaw is to be taken seriously and leaves millions of websites vulnerable. Please update all applications that use this open-source software. Updating to the latest version should take care of the issue and will avoid interruptions of email services.
If you have any questions regarding this announcement or regarding how to get your website updated please contact our development & security team by opening a support request at https://www.host-99.com/submitticket.php.
Did you know SHA-1 is no longer secure?
Find out what you need to do to update your security and protect your data!
What is SHA?
Contrary to popular belief, SHA is not an encryption. SHA stands for Secure Hashing Algorithm, which takes a bunch of data, runs it through some algorithms, and reduces it down to a small summary, or a digest. A digest is a 40-character hexadecimal string that looks like a bunch of gibberish that represents the original data. The same data put through the process should result in the same hash every time. If any part of the data has changed, the resulting hash will be different, which would notify any recipient that the data may have been tampered with.
SHA is used for digital signatures and security certificates. SHA is also used in code verification and email signatures. It has a lot of applications, but the primary application is used in SSL certificates. An SSL certificate is given a signature that’s provided by an authority. You can verify that a certificate is correct through SHA-1 hashing. It’s a way the communications systems can trust they’re talking to the right server/computer.
There are three different types of SHA: SHA-1, SHA-2 and SHA-3. SHA-1 is where some of the problems are happening in data security.
What’s the problem with SHA-1?
The way SHA-1 is supposed to work is no two pieces that run through the process should ever equal the same hash. SHA-1’s hash is a 160-bit long—a string of 160 ones and zeros. This means that there are 2160, or 1.4 quindecillion (a number followed by 48 zeros) different combinations. Normally this would be enough to deter any brute force attacks.
However, because the number of possible hashes is finite, but the possible combinations of data input are infinite, we sometimes run into what is called a collision.
A collision is where two pieces of data will end up with the same hash. How is this possible? In statistics, there’s a phenomenon called “the birthday paradox,” which is: if you get at least 23 people in a room the probability of finding two people that share the same birthday is at least 50%. Applied to SHA-1, this means the strength of SHA-1 is more equated to a string that is 280, which means only about half of the effort is required to find a collision.
The vulnerabilities in SHA-1 open the way to several types of attacks, particularly phishing and man-in-the-middle attacks.
This vulnerability allows hackers to act as a Certificate Authority (organizations that issue SSL certificates) and sign certificates using a key that appears to be from a true Certificate Authority. From there, hackers can exploit other vulnerabilities to direct web traffic to a malicious website and present a seemingly valid certificate for the original website. The browser will check the signature of the rogue certificate against the list of trusted signatures/hashes that are built into browsers, see the certificate has been signed by a trusted Certificate Authority, and connect to the website.
From there, a hacker can intercept any information entered into the website by the user. Meanwhile, the user believes they’re on the correct and secure website because they see the HTTPS address and/or the padlock icon somewhere on their browser.
Cryptologists have worked to improve the SHA process and make it much more difficult to find two pieces of info that create the same hash. SHA-2 and SHA-3 are results of that effort,
What’s being done?
As a user, there is not much that needs to be done. Most browsers are already updated to handle SHA-2 and SHA-3. However, anyone hosting a website protected by an SSL certificate will need to pay attention. All of the major browser vendors have stated that due to the vulnerability in SHA-1, between now and January 1, 2017, they will start displaying warnings to users that the SSL certificates in use may not be secure. After January 1, 2017, all certificates signed with SHA-1 will be rejected and a connection will not be made.
Because of the significant impact of this weakness, there has been talk of even pushing the January 2017 date to as early as June 2016.
While the SHA-1 to SHA-2 migration isn’t being pushed directly by the Payment Card Industry, it may have an impact on merchants attempting to reach and maintain compliance. SSL Certificates signed by SHA-2 or SHA-3 are only supported by TLS 1.2 and 1.3. According to the PCI DSS, all versions of SSL and TLS 1.1 or newer are no longer considered sufficiently secure for protecting data.
Merchants with existing implementations in place prior to April 2015 were given until July 2018 to make the migration to TLS 1.2, but the SHA-1 to SHA-2 migration may push you to update to TLS 1.2 much sooner than that.
What are people worried about?
People are afraid the change from SHA-1 to SHA-2 will more or less break the Internet. They fear the mass migration will overload the Internet and cause damage. But it won’t, because SHA-1 and SHA-2 has nothing to do with web coding.
Everything with SHA is happening behind the browser. So it’s up to the browser to negotiate that “handshake.” The key is the browser needs to be current to use SHA-2 or SHA-3.
The good news is the latest version of nearly every browser will be able to support SHA-2 and SHA-3. Unless you’re using a very old browser, there shouldn’t be problems.
On the server side there may be more problems. If the SSL certificates used for the server/website aren’t updated to SHA-2 by January 2017, the browser will not trust the certificate and users will receive warnings of untrusted/unsecure connections.
What should you do?
Contact your certificate authority on getting a new certificate with a SHA-2 signature. This is particularly important for companies that are using their own server. This impacts anyone who accesses your website.
Here are some additional things to you should do to protect your network:
- Update browsers and servers
- Implement all security patches
- Migrate from using SSL to TLS encryption
- Have your network scanned regularly for vulnerabilities
- Restrict access to your servers to prevent social engineering
Updating your servers to SHA-2 or SHA-3 is just another step in protecting your network. It’s up to you to make sure your servers are secure.
UPDATE: Host-99 Service Maintenance Scheduled
We have completed the scheduled maintenance for Server 23.
Unfortunately, Server 25 is still undergoing maintenance and transfers due to PCI Compliance requirements. Some of those accounts have already been transferred to their new destination. The remaining accounts under Server 25 will be under scheduled maintenance from April 25th, 2016 at through April 30th, 2016 to prevent as less downtime as possible & the transfer process will be slower to move the accounts to the upgraded network.
Server 23 has been completed and no further actions is required from those accounts. Server 23 customers should update their cPanel destination please log into your Host 99 account and navigate to “My Services Details” area and obtain the information there.
We greatly appreciate your patience, understanding during this transition.
Servers that will be affected as of today:
Server 25
Host-99 Service Maintenance Scheduled
Please be advised that we will be performing a scheduled network maintenance during the following date and time:
Starting Wed., April 20th, 2016 at 6 a.m. EST through Monday, April 25th, 2016 6 a.m. EST
Servers that will be effected:
Server 23
Server 25
This maintenance is necessary to perform upgrades on our servers to meet latest stable versions of the following components on our shared hosting platforms.
Server Hardware
cPanel Versions (Security)
Kernel Upgrade
Centos Upgrade From 6 to 7 on some machines from Centos 5 to 7
Network Switches (Gateways)
PCI Compliance Upgrades:
Regarding Host-99 PCI Compliance hosted customers we will be updating the following components on some of our PCI Compliance platforms.
PCI 2.0 to PCI 3.0
PCI Data Security Standard (DSS)
PIN Transaction (PTS) Security Requirements
Application Firewall and Hardening
Security Information and Event Management (SIEM)
Two-factor authentication
Encryption: FIPS-140-2
Internet Load Balancing
Dedicated Spotlight Server
Patching of the required infrastructure and operating system components
During this maintenance we will be moving switches onto a higher capacity switch fabric to enable faster connections to the Host-99 network from all points of the globe.
Action required: No action is required by our customers at this time. Your services will remain online during the upgrade unless otherwise noted. No data or inbound messages will be lost during this time, they will be stored on our mail relay servers until they can be delivered to your mailbox. If any changes are required our server technicians will send out a bulletin stating the requirements and full instructions to follow.
This maintenance will be SERVICE IMPACTING do to propagation of our new DNS servers (MINIMAL IMPACT). During this maintenance window you may experience two separate instances of latency and/or packet loss lasting up to 10 minutes each once we have made the changes.
You can check back from time to time on our Facebook page, Twitter and our blog for any posted updates or announcements. Please we ask all customers not to submit support tickets unless absolutely necessary if you are hosted on these two servers. We are aware of the effects of this maintenance process an each and every account will be restored back to normal operations when completed.
We appreciate your business and we appreciate your patience during this transition.
Great news for our customers: CodeGuard is here
We are pleased to announce that we’ve added
CodeGuard’s website backup service to your account.
“We highly recommend that you use these Free Website Backup Services.”
Trust the leading website backup service in the world!
Automated Daily Backups that never let you down.
CodeGuard offers the most reliable backup on the market – 99.999999999% reliable. We achieve this by replicating your data in secure locations across the world – again and again and again.
Receive ChangeAlerts when content on your site changes.
When CodeGuard takes the daily backup, it compares what is on your website with the last version of your website stored CodeGuard’s system. If any changes are found, CodeGuard emails you with the details!
Use Time Machine to view older versions of your website!
CodeGuard takes a picture of what your website looks like each time it takes a backup. Then, when you need to sort through older versions of your site, it’s much easier when you can look at them!
Get UNDO Power for when anything goes wrong
CodeGuard helps should anything go wrong – deleted files are now recoverable, overwritten files are now obtainable, and if your site is hacked, the malware is easily removable. All of this with nothing to install.
Easily Scan for Malware and Google Blacklisting
You can rest safe knowing that CodeGuard is also looking out for malware. We interact with Google on a regular basis to make sure your site is neither blacklisted nor infected.
Source Code and Database Differential Storage
CodeGuard seamlessly backs up your source and databases. And it does it in an elegant way that saves you space and makes it easy to see changes between each backup/version.
Go to your control panel to get started!
PCI 3.0 Now In Full Effect
PCI 3.0 has been applied to all PCI servers, PCI 3.0 requirements are now in full effect. Regarding PCI 3.0 with questions. Host 99 will now fully enforce PCI 3.0 for all PCI Shared, VPS and Dedicated Servers. We will monitor for any non compliance and reports will be made regarding logs and findings. Please contact your ASV for more information.
Based on feedback from the industry, in 2010 the Council moved from a two-year to a three-year standards development life cycle.The additional year provides a longer period to gather feedback and more time for organizations to implement changes before a new version is released.
Version 3.0 will introduce more changes than Version 2.0. The core 12 security areas remain the same, but the updates will include several new sub-requirements that did not exist previously. Recognizing that additional time may be necessary to implement some of these sub-requirements, the Council will introduce future implementation dates accordingly. This means until 1 July 2015 some of these sub-requirements will be best practices only, to allow organizations more flexibility in planning for and adapting to these changes. Additionally, while entities are encouraged to begin implementation of the new version of the Standards as soon as possible, to ensure adequate time for the transition, Version 2.0 will remain active until 31 December 2014. The nature of the changes reflects the growing maturity of the payment security industry since the Council’s formation in 2006, and the strength of the PCI Standards as a framework for protecting cardholder data.
Cardholder data continues to be a target for criminals. Lack of education and awareness around payment security and poor implementation and maintenance of the PCI Standards leads to many of the security breaches happening today. The updates address these challenges by building in additional guidance and clarification on the intent of the requirements and ways to meet them. Additionally, the changes in PCI DSS and PA-DSS 3.0 focus on some of the most frequently seen threats and risks that precipitate incidents of cardholder-data compromise.
The updated standards will help organization s not by making the requirements more prescriptive, but by adding more flexibility and guidance for integrating card security into their business-as-usual activities. At the same time, the changes will provide increased stringency for validating that these controls have been implemented properly, with more rigorous and specific testing procedures that clarify the level of validation the assessor is expected to perform. Overall, the changes are designed to give organizations a strong but flexible security architecture with principles that can be applied to their unique technology, payment, and business environments.The updated versions of PCI DSS and PA-DSS will:
- Provide stronger focus on some of the greater risk areas in the threat environment
- Provide in creased clarity on PCI DSS & PA-DSS requirements
- Build greater understanding on the intent of the requirements and how to apply them
- Improve flexibility for all entities implementing, assessing, and building to the Standards
- Drive more consistency among assessors
- Help manage evolving risks / threats Align with changes in industry best practices Clarify scoping and reporting Eliminate redundant sub-requirements and consolidate documentation
Important: WordPress 4.2.2 Security and Maintenance Release
WordPress 4.2.2 is now available. This is a critical security release for all previous versions and we strongly encourage you to update your sites immediately.
Version 4.2.2 addresses two security issues:
- The Genericons icon font package, which is used in a number of popular themes and plugins, contained an HTML file vulnerable to a cross-site scripting attack. All affected themes and plugins hosted on WordPress.org (including the Twenty Fifteen default theme) have been updated today by the WordPress security team to address this issue by removing this nonessential file. To help protect other Genericons usage, WordPress 4.2.2 proactively scans the wp-content directory for this HTML file and removes it. Reported by Robert Abela of Netsparker.
- WordPress versions 4.2 and earlier are affected by a critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site. WordPress 4.2.2 includes a comprehensive fix for this issue. Reported separately by Rice Adu and Tong Shi.
The release also includes hardening for a potential cross-site scripting vulnerability when using the visual editor. This issue was reported by Mahadev Subedi.
Thanks to those who have practiced responsible disclosure of security issues. WordPress 4.2.2 also contains fixes for 13 bugs from 4.2. For more information, see the release notes or consult the list of changes. Download WordPress 4.2.2 or venture over to Dashboard → Updates and simply click “Update Now.” Sites that support automatic background updates are already beginning to update to WordPress 4.2.2.
UPDATED: Server 23 Apache and TSL Upgrade
ALL SERVICES ON SERVER 23 ARE FULLY RESTORED USING TSL 1.1 AND 1.2
Security Advisory: XSS Vulnerability Affecting Multiple WordPress Plugins
Multiple WordPress Plugins are vulnerable to Cross-site Scripting (XSS) due to the misuse of the add_query_arg() and remove_query_arg() functions. These are popular functions used by developers to modify and add query strings to URLs within WordPress.
The official WordPress Official Documentation (Codex) for these functions was not very clear and misled many plugin developers to use them in an insecure way. The developers assumed that these functions would escape the user input for them, when it does not. This simple detail, caused many of the most popular plugins to be vulnerable to XSS.
To date, this is the list of affected plugins:
- Jetpack
- WordPress SEO
- Google Analytics by Yoast
- All In one SEO
- Gravity Forms
- Multiple Plugins from Easy Digital Downloads
- UpdraftPlus
- WP-E-Commerce
- WPTouch
- Download Monitor
- Related Posts for WordPress
- My Calendar
- P3 Profiler
- Give
- Multiple iThemes products including Builder and Exchange
- Broken-Link-Checker
- Ninja Forms
There are probably a few more that we have not listed. If you use WordPress, we highly recommend that you go to your wp-admindashboard and update any out of date plugins now.
This issue was first identified by Joost from Yoast in one of his plugins (he did a great write up about it as well). We worked together with him to investigate the issue and found that it likely affected a lot more plugins than just that one.
Our research team, along with a few friends (especially Joost from Yoast ) have been going through the WordPress repository for the last few days in an attempt to find and warn as many plugin developers as possible – to warn and help them patch the issue.
Coordinated Disclosure
This vulnerability was initially discovered last week, due to the varying degrees of severity and more importantly, the large volume of plugins affected, we coordinated a joint security release with all developers involved and the WordPress core security team. It was great team work, and a pleasant experience to see so many developers united and working together for the common good. We can happily say that all plugins have been patched, and as of this morning updates should be available to all users. (yes, everyone pushed their updates in unison 2 hours ago).
If you use WordPress, now it is your turn to update your plugins!
If you have automatic updates enabled, your site should already be patched, especially in the most severe cases.
There are more plugins vulnerable
Our team only analyzed the top 300-400 plugins, far from all of them as you might imagine. So there are likely a number of plugins still vulnerable. If you’re a developer, check your code to see how you are use these two functions:
add_query_arg
remove_query_arg
Make sure you are escaping them before use. We recommend using the esc_url() (or esc_url_raw())functions with them. You should not assume that add_query_arg and remove_query_arg will escape user input. The WordPress team is providing more guidelines on how to use them here.
Update Time!
If you use any of these plugins, make sure to update them now! We will continue to investigate and look for more plugins vulnerable and keep our list here current.
This is also a good time to remind everyone that all software will have bugs and some of those bugs will inevitably lead to security vulnerabilities, such is the life we live in. This applies to plugins, themes, webservers, CMS’s and basically anything that is written by people and based on code. As much as developers try to minimize them and deploy secure coding principles, mistakes will inevitably still happen. We just have to be prepared and find ways to minimize the affect of any vulnerability in your environment; a perfect example of such an approach is what you’re seeing today with this coordinate release.
Here are some tips and tricks to remember to help reduce your overall threat risk, helping to improve your individual security posture:
- Patch. Keep your sites updated.
- Restrict. Restrictive access control. Restrict your wp-admin directory to only white listed IP Addresses. Only give admin access to users that really need it. Do not log in as admin unless you are really doing admin work. These are some examples of restrictive access control policies that can minimize the impact of vulnerabilities in your site.
- Monitor. Monitor your logs. They may give you clues to what is happening on your site.
- Reduce your scope. Only use the plugins (or themes) that your site really needs to function.
- Detect. Prevention may fail, so we recommend scan your site for indicators of compromise or outdated software. Our plugin and Sitecheck can do that for free for you.
- Defense in Depth. If you have an Intrusion Prevention System (IPS) or Web Application Firewall (WAF), they can help block most common forms of XSS exploits.
These principles are commonly applied to most secure networks (or on any business that needs to be PCI compliant), but not many website owners think of them for their own site / environment.
These are but a few high level recommendations; we recommend going through our blog for more ideas on how to keep your sites safe and ahead of the threats.
SNI (Server Name Indicator)
We are proud to announce Host 99 will be fully supporting Server Name Indication.
What is SNI support?
SNI (Server Name Indication) support allows you to host multiple SSL certificates for different domains on the same IP add ress. At the start of the “handshake” process, SNI indicates the hostname to which the client connects. Users who are on shared servers that support SNI can install their own certificates without a dedicated IP address.
In order to experience the full benefit of SNI, all operational servers must run an operating system that supports this functionality, such as CentOS 6.
(SNI) is an extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS.
Name-based virtual hosting allows multiple DNS hostnames to be hosted by a single server (usually a web server) on the same IP address. To achieve this the server uses a hostname presented by the client as part of the protocol (for HTTP the name is presented in the host header). However when using HTTPS the TLS handshake happens before the server sees any HTTP headers. Therefore it is not possible for the server to use the information in the HTTP host header to decide which certificate to present and as such only names covered by the same certificate can be served from the same IP address.
In practice, this means that an HTTPS server can only serve one domain (or small group of domains) per IP address for secured browsing. Assigning a separate IP address for each site increases the cost of hosting, since requests for IP addresses must be justified to the regional internet registry and IPv4 addresses are now in short supply. The result is that many websites are effectively prevented from using secure communications over IPv4. IPv6 naturally deals in blocks of IP addresses at a time so is unaffected by this issue.
How SNI fixes the problem
SNI addresses this issue by having the client send the name of the virtual domain as part of the TLS negotiation. This enables the server to select the correct virtual domain early and present the browser with the certificate containing the correct name. Therefore with clients and servers that implement SNI, a server with a single IP address can serve a group of domain names for which it is impractical to get a common certificate.
SNI was added to the IETF’s Internet RFCs in June 2003 through RFC 3546, Transport Layer Security (TLS) Extensions. The latest version of the standard is RFC 6066.
(SNI) will only be available to Non PCI Compliant Regulated Accounts at this time. More details regarding SNI will be posted periodically on our blog and social media.
Payment Card Industry (PCI) Version 3.0 Changes
PCI 3.0: What You Need to Know
What requirements changed from PCI 2.0, and why?
The PCI DSS was updated for the fourth time (1.0, 1.2, 2.0, 3.0) in November 2013. As always, the changes the PCI Council made address the latest vulnerabilities and include additional clarification and new guidance.
While we won’t cover every single nitty-gritty aspect that changed from 2.0 to 3.0 (like all the clarifications), we are covering the most important changes affecting the majority of merchants.
The newest Payment Card Industry Data Security Standard (PCI DSS) officially goes into effect on January 1, 2015. With the introduction of PCI DSS version 3.0, many merchants want to know how it will affect their business. Here are answers to a few commonly asked questions.
Requirement 0 – PCI Intro
The introduction section probably holds the biggest change for PCI 3.0. Web redirection systems are now defined as system components, which means they’re now part of scope for PCI DSS.
The principal of redirection is when a website points users to a third party that collects and processes all card data. Another form of redirection is client side redirection, in which a customer types card data into a web form generated by the merchant, and is then sent directly to a third party. Either way, card data will not pass through the original website.
In the past, these forms of redirection were validated using SAQ A, but new emphasis in PCI DSS 3.0 changes that.
This new direction will affect many merchants who were previously completing an SAQ A and now must move to an SAQ A-EP, which is significantly longer and includes things such as external vulnerability scans and penetration testing. The reason behind this requirement change? If a hacker is able to manipulate redirection code, he could direct your customers to a fake payments page that looks identical to the one you had originally outsourced.
Attacker directing customers to a fake payments page (i.e., man-in-the-middle attack)
Requirement 1.1.3
A cardholder data flow diagram should show how cardholder data enters your network, the systems it touches as it flows through your network, and any point it may leave your network (e.g., sent to a payment processor). You’ll want to maintain a diagram for each card flow that exists. Most businesses will have just one flow, but you might also have an additional flow if your website processes payment cards.
Physically creating a document that explains the processes will help you better understand where card data lives on your network.
Requirement 2.4
This requirement involves a document that lists all in scope device types and their function (e.g., POS systems, computers). This inventory list is also a great place to document software/firmware versions. If you’re feeling a little daunted by this task, interviewing department heads is a great place to start.
Requirement 4.1
In addition to GSM (cellular) connections and wireless Internet, it is now required that any communication that includes cardholder data sent over satellite should be encrypted. Depending on your business, this may not have much impact.
There is many large retail chain clients (e.g., gas stations, hospitality, restaurant chains). Many of these chains use satellite communications between chains and even as a backup connection. According to the PCI Council, it’s no longer good enough to rely on the link provider’s system security. It’s your responsibility to keep this data secure.
Requirement 5.1.2
For systems not commonly affected by viruses and don’t have anti-virus software installed, you are required to implement and document a new process that shows you periodically evaluate these systems against emerging threats.
The point of Requirement 5.1.2 is to acknowledge hackers invent new ways to hack into systems every day. It requires merchants to research and pay attention to security notices from PCI vendors. If a new attack method is deemed a threat to your system, evaluate if the threat requires anti-virus.
Requirement 5.3
This requirement states that anti-virus can’t be altered without managerial approval. Often, anti-virus needs to be turned off to do system maintenance. During maintenance, who knows what could slip past your unguarded system.
Our advice is, if you are updating an application that requires disabling an anti-virus, don’t. Instead, take that system off the network or cut off its Internet connectivity for that period. As a side note, it’s not OK for system admins to just give all users admin access to get around the requirement. That’s missing the point entirely.
Requirement 6.3
Any custom software application for a cardholder environment (whether in-house or commissioned by a third party developer) is under your jurisdiction. It’s ok to outsource your software development, but it’s not OK to outsource your responsibility to ensure secure development practices are followed. If you’re planning to use the application, remember that it’ll be part of your PCI assessment…not your third party’s.
Requirement 6.5.10
This requirement to protect against broken authentication was added to fix common application vulnerabilities. You should create/add/adjust your application code to mitigate any exposure to vulnerabilities. This can be done through not exposing session IDs in URLs, using secure cookies, and enforcing appropriate session timeouts.
Requirement 7.1.1
You’re required to have a role-based access control system. That means access to card data and systems should only be granted on a need-to-know basis. PCI 3.0 requires a defined list of the roles that have access to the card data environment.
On this list, you should include each role, definition of each role, access to data resources, privilege level, and what privilege level is necessary for each person to perform normal business responsibilities. Users must fit into one of the roles you outline.
Requirement 8.4
Organizations are now required to not just document, but also train their users on how to implement password policies. This training should include guidance on how to select a strong password, how to secure it, and instructions not to reuse it.
It’s also crucial that you communicate password policy to your users. This will help them understand how to change their passwords and also not to use the same password between work and home.
Requirement 8.5.1
This new requirement is targeted specifically towards service providers who have remote access into a customer environment. This is common practice with vendors who do remote support or software training.
Any service provider with access to multiple customer systems is now required to maintain unique credentials for each customer environment. The PCI Council knows this requirement in particular will take some time to change, so they’ve given until July 2015 before this is officially required.
Requirement 8.6
The use of alternative authentication mechanisms (e.g., logical tokens, smart cards, certificates) must be tied to an individual user account and not shared among user accounts. To ensure this is met, every merchant must implement a control to enforce those authentication methods can only be used by the intended user (e.g., requiring a PIN, password, or biometric scan in addition to the token to validate the person is authorized).
Requirement 9.3
This requirement is all about controlling employee access to sensitive areas, which must be related to an individual’s job function. To meet this requirement, I suggest documenting exactly who has access to these environments and their business need. Access must be kept up to date, especially when individuals are terminated or their job role changes.
Requirement 9.9
This is a huge addition to the PCI standards. Organizations that use point of sale systems,PIN pads, mobile devices etc., are required to do three new things:
- Maintain an up-to-date list of all devices (9.9.1) including physical location, serial numbers, make/model.
- Periodically inspect devices (9.9.2). That means looking at device surfaces to make sure they haven’t been tampered with, making sure the serial numbers match, checking that seals haven’t been broken, etc. This could be a very large task depending on the size of your organization. Whether you inspect devices every day or month is based on how at risk you are of tampering (e.g., publically accessible 24/7 gas station terminals vs. a behind-the-counter card swipe device). Make sure you document what you find.
- Provide staff awareness training (9.9.3) for staff that interact with card present devices on a day to day basis (e.g., cashiers), and record the who, what, and when for future reference. Ideally, the training will help staff detect any suspicious activity around a payment device. Training should include how to report suspicious behavior and what to do when third parties claim they need to work on the system. For example, rather than assuming IT came in last night to install a new device on the side of her terminal, an employee should question if its supposed to be there and notify appropriate persons.
Requirement 10.6.2
Depending on its size and complexity, this requirement could have a large impact on your environment. In addition to the logging requirements in 10.6.1, you’re now required to review logs of all other system components periodically, based on your policies and risk management strategy.
Lots of different systems in your environment may impact your payment security. As part of your annual risk assessment, you need to identify systems that pose risk and define a process to periodically look at their logs to determine suspicious activity.
Requirement 11.1.1
Maintaining a complete list of authorized wireless access points will require extra documentation, especially in large environments. This list should include a documented business justification for each wireless access point.
It’s difficult to determine which wireless devices to remove if you don’t have an accurate list of them to begin with. That’s why the PCI Council requires you create a total list. If you’re a small ecommerce provider and all your systems fit into a single rack in your data center, this requirement should be pretty easy. If you’re a widespread organization, it will take a bit more time.
Requirement 11.3
The rewrite of section 11.3 is intended to provide additional guidance to both merchants and penetration testing organizations on penetration testing’s intended coverage.
The rewrite of section 11.3 is intended to provide additional guidance to both merchants and penetration testing organizations on penetration testing’s intended coverage.
Penetration testing organizations are now required to have documented and standardized testing methodologies that meet industry accepted standards, such as NIST 800.115. In addition, guidance is provided on how best to scope the penetration test and identify critical systems.
A penetration test Special Interest Group has been organized by the PCI Council to help merchants and penetration test organizations best interpret this new set of requirements. Results from this SIG group are expected near the end of 2014.
The PCI Council knows this requirement in particular will take some time to change, so they’ve given until July 2015 before the changes in the penetration testing requirement become official. However, this doesn’t mean you can wait to receive a penetration test until July 2015. The guidance provided in PCI DSS 2.0 for penetration testing is still valid until then.
Requirement 12.8.5
Not only should merchants maintain a list of a third party service providers, but now they must maintain a list of all PCI requirements their service provider meets, and a list of PCI requirements they’re required to meet.
Requirement 12.9
In conjunction with Requirement 12.8.5, service providers are now required to provide written documentation to all customers stating which PCI requirements they cover on their behalf. These two requirements attempt to avoid past miscommunication problems between service providers and merchants.
Summary
Overall, PCI DSS 3.0 focuses on detecting, rather than reacting to, security vulnerabilities. With improved aspects like documentation and system monitoring, 3.0 will increase proficiency among merchants, service providers, and PCI vendors alike.
10 Commonly Asked Questions
The new SAQ-A EP form is designed for eCommerce merchants using client side redirection.
1. Why is there a new standard?
As always, new security guidance addresses the latest vulnerabilities affecting today’s merchants and also includes additional clarification. Three main reasons contributed to this updated security standard:
- Additional guidance: New guidance sections provide layman’s explanations of why standards are important and how noncompliance may put your business at increased risk.
- Evolving requirements: As technology, threats, and security risks change, the PCI DSS must adapt to the changing environment. PCI DSS 3.0 has evolved to not only address emerging threats, but also new technology like EMV, P2PE, and mobile payments.
2. Who does this affect?
The transition from PCI 2.0 to PCI 3.0 will affect everyone governed by PCI. If you store, process, or transmit payment card information, this change affects you.
3. When is the PCI DSS 3.0 deadline?
January 1, 2014 was PCI 3.0’s effective date. However, PCI DSS 2.0 compliant merchants have until January 1, 2015 to transition to the new standard. Some changes will continue to be best practices until June 1, 2015 (see question 8).
This means merchants do not need to revalidate until their compliance expires. For example, if your annual validation occurs in November 2014, you technically don’t need to validate compliance to 3.0 until November 2015. However, you are required to be compliant with the new standard starting January 1, 2015.
4. What does PCI DSS 3.0 mean for my business?
If you follow PCI 3.0 requirements, you will eliminate the majority of your business risk to compromise. PCI DSS 3.0 focuses on detecting, rather than reacting to, security vulnerabilities. But the standard only works if merchants comply. The best thing merchants can do now is review their compliance status. If you have a passing grade, great! Now it’s time to review PCI 3.0 requirements to make sure you will be in compliance once January 1, 2015 hits. If you have a failing grade, PCI 3.0 is a great time to reevaluate your security and begin securing your business.
5. What will happen on January 1, 2015?
If you haven’t complied with PCI 3.0 by January 1, 2015, you will technically be in violation of PCI DSS. If you are compromised, you may face heavy fines due to your noncompliance.
6. What is the biggest change for ecommerce merchants?
If you are an ecommerce merchant, the biggest change for you will be the new SAQ A-EP. Originally, ecommerce merchants were validated using SAQ A but many of those merchants must now move to a SAQ A-EP, which includes more requirements. Learn which ecommerce methods qualify for SAQ A-EP.
7. What new documentation does PCI DSS 3.0 require?
Documentation is a key theme of PCI 3.0. For example:
- 1.1.3 requires a cardholder data flow diagram that shows how cardholder data enters your network.
2.4 involves the creation of an inventory list of all your in-scope device types and their function (e.g., - POS systems, computers).
- 9.9.1 requires an up-to-date list of all devices, including physical location, serial numbers and make/model.
- 11.1.1 involves maintaining a complete list of authorized wireless access points and the justification for each.
- 12.8.5 requires a list of all third party service providers in use, a list of all PCI requirements the service providers meet, and a list of PCI requirements the merchant is required to meet
8. What are the new ‘best practice’ requirements?
The PCI Council knows some requirements will take more time for merchants to apply. There are six requirements considered ‘best practice’ until they are officially required on June 2015. They are:
- 6.5.6: Insecure handling of PAN and SAD in memory
- 6.5.11: Broken authentication and session management
- 8.5.1: Unique authentication credentials for service providers with access to customer environments
- 9.9: Protecting of point-of-sale devices from tampering
- 11.3: Developing and implementing a methodology for penetration testing
- 12.9: Additional requirement for service providers on data security
9. How can I ensure compliance with PCI DSS 3.0?
The only way to ensure lasting compliance with the PCI DSS 3.0 is to make data security part of your company culture. According to Bob Russo, GM of the PCI Security Standards Council, PCI 3.0 is “about making PCI compliance part of your business, not a once-a-year, study-for-the-test kind of thing.” The new standard helps you implement security controls without disrupting your day-to-day processes—allowing you to focus on your business while maintaining appropriate data protection.
10. What is ASV’s are doing to help me with PCI DSS 3.0?
To simplify the transition, Your ASV will update its SAQs, customer interface, and PCI scoping wizard on January 1, 2015. As part of the PCI 3.0 SAQ, select standards will be written in easy-to-understand language for the ease of the user. Because PCI 3.0 introduces more SAQs, your ASV will offer combination SAQs when more than one SAQ applies.
To Boost Card Security, American Express Takes a Cue From Apple
Earlier this week, American Express (AMEX) launched its American Express Token Service. Despite what its name may suggest, AMEX isn’t making a pass at the less-than lucrative video arcade space, but rather they’re making a significant move to secure your financial transactions online.
American Express Token Service helps make transactions more secure by replacing payment card details with randomized tokens. Called “tokenization,” this practice is quickly becoming the standard method used to secure your mobile and online purchases.
If the concept of tokenization sounds familiar, it’s because the concept recently made headlines with the emergence of Apple Pay, Apple’s mobile payment solution that employs tokenization for purchases made with an iPhone 6 or iPhone 6 Plus.
So why is tokenization so great?
For as hectic as department stores can get, the payment process is usually quite simple. There is a checkout area, a retail employee, a buyer and a payment card. It’s a direct transaction, albeit a physical one. But go online and you have a more complicated process: there’s the retailer and the means to process payments (the Internet), but there are also millions of other buyers, all competing with one another for the retailer’s attention. Add in a third party payment company and delivery service, and you’ve got yourself a crowd. Unfortunately, mixed in with that crowd are some very attentive listeners, whose ears are tuned to pick out the numbers and names associated with your credit card.
Tokenization is a process where sensitive information is substituted with an insensitive doppelgänger called a “token.” This token, in the context of a payment, represents a credit card number while containing none of that card’s sensitive information. It’s like singing a particular tune to the cash register to pay, rather than shouting credit card numbers. And for each digital cash register you use, there’s a different, unique, tune created.
So what happens if a hacker intercepts your token? Nothing. Unlike if the hacker had obtained your credit card number, a token does not contain your banking info, and a hacker cannot use the token’s information outside of the retailer associated with that specific transaction. These restrictions kill the value of a stolen account. No more panicked calls to the bank and credit agencies needed.
But tokenization is still in its infancy. Many banks and retailers still need to get on board. So what can you do to protect your financial information online in the mean time? Well, there are a few options:
Shop with trusted retailers online. Scammers, always looking to make a quick buck, will be heating up their efforts as the holiday season approaches. Don’t let them trick you. Stick to retailers you’re familiar with and use comprehensive security solutions, like McAfee LiveSafe™ service, to block spam and guard against hackers.
Purchase items on a secure network only. If you’re going to shop online, especially with Cyber Monday coming up, do so safely. Only shop on a network you know is secure—which means avoiding public Wi-Fi. That way you can avoid any man-in-the-middle attacks and other maladies associated with unsecured networks.
Monitor your bank statements. Even with a tokenized service, you should check your bank statements for fraudulent or suspicious activity on a regular basis. They’re not always obvious: sometimes fraudsters charge a few dollars (or even a few cents) on your card before making larger purchases.
USPS RateV4 Intl RateV2 October 30, 2014 K6 for – November 2, 2014
USPS October 30, 2014 K6 has updates for the November 2, 2014 changes that include previous updates for September 7, 2014
This module adds the ability to obtain the Online quote for First-ClassTM Package Service. First-ClassTM Package Service is not available for Retail.
Insurance is added to the:
$methods[] = array(‘id’ => $type_rebuilt,
‘title’ => $title . $show_hiddenCost,
‘cost’ => $cost,
‘insurance’ => $usps_insurance_charge,
);
that can be used with an Order Totals module to make Insurance optional by customer choice. This would require additional customization to the:
/includes/modules/pages/checkout_shipping/header.php
First-Class Large Envelopes should be available on the USPS Production Server, once updated on November 2, 2014 by USPS. This can be tested on the USPS Test Server, prior to that.
Current version is available at:
http://www.zen-cart.com/downloads.php?do=file&id=1292
Original Post Found Here
SSL 3.0 POODLE Vulnerability Has Wide Ranging Effects
What is “POODLE”?
POODLE is an acronym for a newly discovered vulnerability in a specific version of the SSL protocol. POODLE requires an “active” attacker, meaning there must be another ‘bad’ computer intercepting messages between the client and server. Ultimately, the vulnerability allows the attacker to decode messages encrypted with SSL v3.0 (the specific, and only, version of the protocol affected).
SSL v3.0 is an old version of the SSL protocol, a very old version – from the late 90s. However, almost all servers on the Internet still accept connections using it. Luckily, there is a straightforward way to protect yourself from this attack (see “As An SSL Provider, What Should I Do?” section below). The attack also is fairly complex to perform, because of its reliance on being an “active” attack which affects the client. There are also no known attacks using the POODLE vulnerability (yet). For this reason, it is much less serious than the Heartbleed vulnerability from earlier this year. Security expert Robert Graham said, “If Hearbleed/Shellshock merited a 10, then this attack is only around a 5.
However, this does not mean that POODLE should be ignored, because all servers or clients running SSL v3.0 are vulnerable. (See section, “Who is Affected?” for specific details on this and threat analysis).
The vulnerability is serious enough that Mozilla has declared POODLE “the end of SSL 3.0, and Google said “to achieve secure encryption, SSL 3.0 must be avoided entirely.
Please note that (luckily) this is a flaw in an outdated version of the SSL protocol itself, so no changes to any existing certificates themselves are needed. This vulnerability is the result of some bad math back when this version of the protocol was created back in the late 90s.
Solutions to this vulnerability are most effectively implemented at the server level (even though the attack is on the client, its reliant on the server allowing a connection using SSL v3.0 to occur), so education and awareness of the issue is the best way to mitigate the effects of the POODLE vulnerability.
How does the Attack Work?
The POODLE vulnerability can be implemented by an attacker who has control or influence over the network connection between the client and the server – often called a “Man in the Middle Attack” (MITM).
An attack using POODLE begins with a “downgrade attack” to repeatedly cause the client’s connection to the server to fail. This causes the server to allow an encrypted connection with older versions of the protocol, because it believes a lack of modern protocol support is the cause. This downgrading continues to occur until the connection is downgraded all the way to SSL v3.0, at which point the POODLE attack can be used.
This downgrade attack works because, while almost every server supports a newer version of the SSL protocol which are not affected, they ALSO support SSL v3.0 in order to avoid any incompatibility issues with older (“legacy”) clients. After forcing stronger clients to downgrade to SSL v3.0, they can use a flaw in the protocol to figure out the encryption key for an SSL connection, and read the contents as if they were unencrypted.
If you would like to know more about how the attack works, Google provides some excellent information in their paper which announced the discovery: “This POODLE Bites: Exploiting The SSL 3.0 Fallback.
Who is Affected?
Any browser or server which supports SSL 3.0 can be victim to POODLE. Critically, “any website that supports SSLv3 is vulnerable to POODLE, even if it also supports more recent versions of TLS. This means that sites trying to provide backwards compatibility for older clients are at risk. For this reason, supporting SSL v3.0 at all can make a server or client vulnerable.
SSL Pulse is a website that collects monthly demographic statistics of SSL support of the 150,000 most popular websites. SSL Pulse’s most recent scan, conducted before the disclosure of the POODLE vulnerability, found that 98% of these sites still have SSL v3.0 support, potentially putting them at risk of a POODLE attack. Extrapolating from this, it can be assumed most servers on the Internet still include support for the decrepit SSL v3.0.
However, there is very little client traffic still using SSL v3.0 to justify support of this deprecated and flawed protocol version. The most notable software affected by this attack is Internet Explorer 6 on Windows XP versions WITHOUT Service Pack 3.
Support for this flawed protocol version should not be kept for users still on IE6. On Cloudflare, a major provider of DDoS protection, only 0.65% of their received SSL traffic uses (not relies on) SSL v3.0, and 98% of their Windows XP traffic is properly patched to Service Pack 3 which enables TLS 1.0 (the next version of the SSL protocol after SSL v3.0). Mozilla similarly estimates only 0.3% of traffic actually uses SSL v3.0, yet around 98% of servers allow it! The number of clients still needing SSL v3.0 simply does not justify keeping it on.
As an SSL provider, what should I do?
The SSL Store’s recommendation is to totally disable support for SSL v3.0. This should be disabled on your servers and communicated to your customers. There are solutions to the POODLE attack, mainly the new protocol mechanism “TLS_FALLBACK_SCSV. However, this mechanism relies on server and browser compatibility, which introduces too much uncertainty to its effectiveness. TLS FALLBACK also does not fix the issue for devices that ONLY have SSL v3.0 support, leaving the biggest vulnerable software – IE6, still exposed.
So, to be totally safe from POODLE, and other discovered and undiscovered flaws in SSL v3.0, its best to disable support for it altogether at the server side. This falls in line with what is recommended by Google, Mozilla, Cloudflare, and other major technology companies.
On the client side, Firefox will be disabling SSL v3.0 by default in Firefox 34, which is to be released on Nov 25th. Google will also be removing SSL v3.0 support in client devices, including Chrome, “in [the] coming months. With this pressure on the client-side removing SSL v3.0 support, the tiny number of client’s using SSL v3.0 should tumble even further.
(Also note, if you recently switched to SHA2 certificates, as the SSL industry is encouraging and requiring, you have downgraded the user experience for sluggish clients still on IE6 with Windows XP pre-Service Pack 3. So disabling SSL v3.0 will be the nail in the coffin for them – thats a good thing.)
Does this mean SSL is insecure?
No. SSL, or more accurately, TLS, is fine. While most people use the word “SSL” still, the proper technical term for the encryption protocol we use today is TLS. This stands for Transport Layer Security and has been the official name of the SSL protocol since 1999. The newest version of the TLS protocol, Version 1.2, was released in 2008 and is four versions senior of SSL 3.0. All ‘modern’ browsers and computers, and smartphones should have support for some version of TLS, and the majority of SSL connections are using TLS. TLS 1.0 and 1.1 are not perfect, but they are much improved over SSL v3.0 and are considered suitable by security experts.
SSL v3.0 is over 15 years old! So it’s only reasonable for it to be abandoned at this point.
How Do I Disable SSL v3.0 on my Server? (Already completed on all shared, VPS and Dedicated Servers) on the Host 99 network.
This depends on the type of server you are operating.
For Apache Tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=54691
For Apache, Nginx, and IIS: https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/
For Lighttpd: https://cipherli.st/
If you do not want to drop SSL v3.0 support, you can implement TLS_FALLBACK_SCSV on OpenSSL. However this should just be a stopgap solution and replacements for devices requiring SSL v3.0 should be actively pursued. https://www.openssl.org/news/secadv_20141015.txt
Further Resources:
In addition to the citations on this resource, please see:
The University of Michigan’s data on server support and presence of SSL v3.0: https://zmap.io/sslv3/
For technical details on how the vulnerability works, see Google’s original paper: https://www.openssl.org/~bodo/ssl-poodle.pdf
For the single best understanding of POODLE and what it means as a Internet user concerned with security, or a server operator, see Robert Graham’s notes on POODLE at his personal website: http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEUcTvnF-MJ
Microsoft’s Security Advisory on POODLE: https://technet.microsoft.com/en-us/library/security/3009008.aspx
- http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEWwk4t4p1-
- https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
- https://www.openssl.org/~bodo/ssl-poodle.pdf
- http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEUcTvnF-MJ
- http://blog.cryptographyengineering.com/2014/10/attack-of-week-poodle.html
- Also see Adam Langley’s slightly different explanation on his personal site: https://www.imperialviolet.org/2014/10/14/poodle.html
- Section: “Issue” https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
- https://www.trustworthyinternet.org/ssl-pulse/
- https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/
- https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
- https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/
- http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
There Is a New Security Vulnerability Named POODLE, and It Is Not Cute
On a day when system administrators were already taxed addressing several security updates released by Microsoft, Oracle, and Adobe, there is now word of a new security hole discovered in a basic protocol used for encrypting web traffic. Its name is POODLE, which stands for Padding Oracle on Downgraded Legacy Encryption, and it was discovered by three Google security researchers—Bodo Moller, Thai Duong, and Krzysztof Kotowicz. They published a paper (.pdf) about it today.
POODLE affects SSLv3 or version 3 of the Secure Sockets Layer protocol, which is used to encrypt traffic between a browser and a web site or between a user’s email client and mail server. It’s not as serious as the recent Heartbleed and Shellshock vulnerabilities, but POODLE could allow an attacker to hijack and decrypt the session cookie that identifies you to a service like Twitter or Google, and then take over your accounts without needing your password.
To exploit the vulnerability, you must be running javascript, and the attacker has to be on the same network as you—for example, on the same Starbucks Wi-Fi network you’re using. This makes it less severe than an attack that can be conducted remotely against any computer on the Internet.
The attack works only on traffic sessions using SSLv3. Although this is an old protocol that has been replaced in many client and server configurations with TLS (Transport Layer Security), many browser clients and web servers that use TLS for connections still support SSLv3. Some products and browsers, like Internet Explorer 6 for Windows XP, only use SSLv3. There are also clients that support SSLv3 as an alternative to use whenever a TLS connection to a web server fails. An attacker could exploit this compatibility to downgrade a connection to SSLv3 and then conduct the POODLE attack to hijack your session.
Google’s security team has recommended that systems administrators simply turn off support for SSLv3 to avoid the problem. But this will mean that some users trying to connect securely to a web server using SSLv3 will have trouble connecting if they’re using a client that only supports this protocol.
“This attack is really against clients—you have to worry about it if you’re in a place like Starbucks,” says Rob Graham, CEO of Erratasec. “If you’re at home there’s probably no one man-in-the-middling you except the NSA. So as a home user, you don’t need to panic. As a server [administrator], you probably don’t need to panic if your customers are coming in over home connections. Only if they’re coming in over [something like] a Starbucks Wi-Fi.”
Heartbleed and Shellshock were vulnerabilities that allowed an attacker to hack a server. POODLE instead targets the clients.
“The fear of rushing to go fix this is very low because of that,” Graham says. “People with servers can’t get hacked, and people with [vulnerable] clients also can’t get hacked unless they’re on an open Wi-Fi.”
Important Note: As of January 1, 2015 Host 99 will no longer support SSLV1, SSLV2, SSLV3. Only TLS V1.1, TLSV1.2 combined with SHA-2 will only be supported. Any current SSL holders can renew their active SSL certificates early or wait until the current SSL expires that may be currently in use. After the mentioned date, only SHA-2 SSL will be used and installed. We urge any SSL holder to upgrade before this date but no interruptions will occur during the current period.
Hackers exploit ‘Shellshock’ bug with worms in early attacks
Everything you need to know about the Shellshock Bash bug
Remember Heartbleed? If you believe the hype today, Shellshock is in that league and with an equally awesome name albeit bereft of a cool logo (someone in the marketing department of these vulns needs to get on that). But in all seriousness, it does have the potential to be a biggie and as I did with Heartbleed, I wanted to put together something definitive both for me to get to grips with the situation and for others to dissect the hype from the true underlying risk.
To set the scene, let me share some content from Robert Graham’s blog post who has been doing some excellent analysis on this. Imagine an HTTP request like this:
target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
http-header = Host:() { :; }; ping -c 3 209.126.230.74
http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Which, when issued against a range of vulnerable IP addresses, results in this:
I’m a system admin – what can I do?
Firstly, discovering if you’re at risk is trivial as it’s such an easily reproducible risk. There’s a very simple test The Register suggests which is just running this command within your shell:
env X=”() { :;} ; echo busted” /bin/sh -c “echo stuff”
You get “busted” echo’d back out and you’ve successfully exploited the bug.
Of course the priority here is going to be patching at risk systems and the patch essentially boils down to ensuring no code can be executed after the end of a Bash function. Linux distros such as Red Hat are releasing guidance on patching the risk so jump on that as a matter of priority.
Read More from the original poster.