Vision Direct 'fesses up to hack that exposed customer names, payment cards Vision Direct has admitted customers' personal and financial data was leaked earlier this month after hackers compromised the company's website. The breach took place between 00:11 GMT on 3 November and 12:52 GMT on 8 November, said Vision Direct, which purports to be Europe's largest etailer of contact lenses and eye care …
"He suggested it could be the type of breach where..."
A bit behind. It was due to a keylogger using a fake Google Analytics script called "https://g-analytics dot com". This was inserted into the page which skimmed the details and intercepted users and cookies.
Vision Direct claimed that the developers had tried to mitigate attacks like this but the signature was different, however they had completely inadequate security against an attack like this and were not following PCI best (required?) practice. The security scan of their site -> https://ibb.co/m35V20
How did the script get on there? Well they use Google Tag Manager so if someone gets access to the console of that then they can put any tags they want on.
however they had completely inadequate security against an attack like this and were not following PCI best (required?) practice.
That's rather a large assumption to make based on Scott Helms' IO headers site, which is mostly bollocks.
If you use htbridge.com or ssllabs.com then the site scores an "A" in both cases, and if you look at visiondirect.co.uk it scores "A+" even though it still supports TLS1.0 - which is probably a commercial decision.
SSLlabs checks you SSL security and other associated bits an pieces. It doesn't check for XSS, CVE vulnerabilities, patch management etc.
A simple CSP header would have stopped this attack (and other script injection attacks) and should be a basic security measure for most sites, especially one like this that has a credit card checkout and uses third party content.
As always with PCI, if there are compensatory controls in place and documented, then it can be PCI compliant.
One of our environments has to still support TLS1.0, because a high percentage of the clients connect using it, and we have no control over the clients.
That's why I said it would be a business decision. If turning off TLS1.0 breaks your site for 40% of it's users, then you don't do it. It is entered on the risk register, and the QSA will sign it off.
That's rather a large assumption to make based on Scott Helms' IO headers site, which is mostly bollocks.
Bit harsh. Whilst using the site as a tick-boxing exercise would not necessarily leave you with a secure system, it's nonetheless a useful tool for double-checking configurations. Moreover, this attack could have been mitigated with an appropriate CSP, the lack of which is highlighted by Helme's site, along with a failure to set XSS-Protection.
Having a good score on securityheaders.io does not mean your system is secure (e.g. unpatched CVEs, insecure server config, etc) but having a bad score does tend to indicate that the devs are probably not paying attention to best practices and if they haven't bothered to set CSPs or the HSTS header (on an e-commerce site which should be all-HTTPS all-the-time) then it's a good indicator to ne'er do wells that there are probably other vulnerabilities waiting to be exploited.
Having a good score on securityheaders.io does not mean your system is secure (e.g. unpatched CVEs, insecure server config, etc) but having a bad score does tend to indicate that the devs are probably not paying attention to best practices
That's nonsense, it simply means that the devs haven't implemented all the headers that Scott feels should be there - two of which, by the way are still very much experimental, but he still marks you down for.
You might notice that www.google.com only scores a "C" on Scott's site, but that doesn't mean they are shoddy or third rate, it just means they've chosen not to implement CSPs etc.
if they haven't bothered to set CSPs or the HSTS header (on an e-commerce site which should be all-HTTPS all-the-time)
The HSTS header serves no useful purpose if your site / server only responds on HTTPS, and has no HTTP bindings.
As for Content Security Policies, they are fine if you control all of the content appearing on the site.
However in practice, if the site is hosted by one company, on behalf of the client (in this case Vision Direct) and the client regularly employs SEO consultants who change their minds every 3 months, or the client wants to generate Ad revenue, then you end up with a site full of javascript from multiple domains, none of which you have control over.
It becomes impossible to create CSPs that don't inadvertently break one or other tag manager, tracking pixel or whatever.
I'm not advocating that this is right or proper, but it is the reality of hosting e-commerce sites on behalf of third parties.
It would be great if we could dictate to clients that they must only use content providers we approve, or not use third-party script etc, but we wouldn't have a business for very long if we did that.
HSTS is highly desirable. The website itself might not have a HTTP binding, but MITM creating a HTTP binding is pretty trivial.
Re CSP domains - in this case it would have helped. For the BA hack it wouldn't have as the script host was compromised. Doesn't make it easy to implement of course.
Tell me... why are they storing CVV for any purpose at all whatsoever?
https://blog.pcisecuritystandards.org/faq-can-cvc-be-stored-for-card-on-file-or-recurring-transactions
Not least:
"It should also be noted that PCI DSS Requirement 3.2 applies regardless of any permission the entity may have received from their customer to store the sensitive authentication data on their behalf. A customer’s request or approval for an entity to retain the card verification codes/values has no validity for PCI DSS and does not constitute an allowance to store the data."
I hope they lose the ability to take payment cards, because it's not only unnecessary, it's downright stupid.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
