4 ms·

How did the attackers get the JS onto the cart page? That's the interesting part to me that the article leaves out. They managed to break into a PCI-compliant

How did the attackers get the JS onto the cart page? That's the interesting part to me that the article leaves out. They managed to break into a PCI-compliant website that presumably has significant defenses and auditing in place.

vkjv 8y ago
Unfortunately, PCI does not put very many restrictions on the parent website. If credit card elements are in an iFrame, the parent site is excluded from most requirements because the iFrame is "secure." Of course, if you own the parent site you can replace the iFrame with anything you want.
- tyingq 8y ago
  PCI also doesn't necessarily mandate some common sense things either, like monitoring for unexpected changes on the cart page.
- marak830 8y ago
  I'm still confused as to how they could insert code here. Are we talking about a server intrustion where they modified the actual cart code, or something between Newegg and the payment servers? (Sorry this isn't my domain, I'm just curious)
  - lacker 8y ago
    It looks to me like a server intrusion where they modified static files kept on a webserver (like apache or nginx). But it also seems like we don't have enough evidence to know for sure. (Edit: or they might have been static files kept on a CMS.)
- vkjv 8y ago
  FWIW, I just checked and they don't use an iFrame approach. This means their entire checkout page must be in scope for SAQ-D.
lacker 8y ago
The article on the British Airways hack goes into a bit more detail, but still not enough to slake my curiosity. https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ https://www.riskiq.com/blog/labs/magecart-british-airways-br... It seems like we just don't have enough information to know how exactly the attackers got the JS onto the page. What it looks like, though, is that some machine serving static files for the website got compromised, and the attackers replaced an innocent file with one that had some custom javascript tacked onto the end, that skimmed the credit card numbers. For what it's worth, PCI compliance doesn't really help you keep your webservers secure, or to keep people from breaking into your servers at all, it's more about the way you permanently store credit card numbers.
- pjc50 8y ago
  It was appended to "Modernizr.js". That suggests a number of further possibilities by which that may have been replaced on a developer's computer, or at the point of download by a package manager (are packages authenticated?) It could well have been included in a legitimate re-deploy if that was the case.
  - lacker 8y ago
    Since that file was served from "/cms/global/scripts/lib", perhaps their CMS got compromised. Anecdotally it seems like CMS's are more frequently prone to compromises than systems like nginx or apache.
zeveb 8y ago
Ditto. As an aside, while it's certainly true that if one can compromise a web server (whether serving static HTML or generating dynamic HTML) then it's game over, the modern style of JavaScript-centric development greatly expands the attack surface. An attacker can compromise any of a number of different servers (e.g. analytics providers), via numerous means; moreover, he can serve dynamic malicious code, and quickly respond to changes the targeted site makes (his implant needs to survive for awhile, but his access can be revoked and folks can still be compromised). Websites which served static pages and received credit-card information via simple forms would be far more secure than dynamic web apps stitched together from JavaScript served from multiple servers in countries across the globe, with data inserted into the DOM retrieved from multiple servers across the globe. I contend that a more traditional, static architecture would tend to lead to better architectural isolation. As an example, if one needed to install server-side analytics software rather than simply injecting it into a page at runtime, then one would download and install it once: any compromise of the analytics provider after one had download it would be irrelevant. But with dynamic JavaScript, one's users download the analytics software with every single page load: a compromise instantly affects users. Moreover, with traditional server-side software one tends to have reasonably-well defined protocols for interaction, rather than just saying, 'hey, I'll run all your code in the same process as everything else.' But with client-side JavaScript, any piece of code can see everything. As an engineering community, we've adopted a style which has great costs as well as great benefits. My opinion is that we moved too quickly, and now we're feeling the pain. While a universal portable app framework is pretty awesome, JavaScript layered over a document system is probably not the best way to achieve that. As I wrote years ago, JavaScript delenda est.
adreamingsoul 8y ago
PCI compliance isn't that hard to get. And, typically the code is changed after the compliance review. Also, developers and engineers at Newegg are probably changing lines of code every day. Which means, at any point in time someone could have accidentally introduced a vector that allowed the attackers to inject their code. Auditing and security reviews only work if every line of code is tested, reviewed, and verified. However, that be extremely costly and slow, which isn't "good for business". Maybe, we as consumers, engineers, managers, and executives should demand that code safety and security is prioritized over profit. I would rather have a secure website then a new redesign every two years.
- yspeak 8y ago
  This isn't fort Knox It's credit card info. There's always a cost benefit. You can spend all your time and money on doingsecurity reviews but without profit there ain't no company.
- saas_sam 8y ago
  Do you have any evidence to suggest "that code safety and security" was NOT "prioritized over profit"? How would you falsify this? Are we to assume that every security breach indicates that profit was prioritized over security? Doubtful. Also, "profit" is the reward for doing things efficiently, it is not some kind of scoreboard for how much a company is ripping off consumers. NewEgg is in such a hyper-competitive & mature space with margins in the low single-digits on average. Incidents like this can absolutely tank them, especially this close to the holiday season. E-commerce companies do not make money on security breaches, they lose it. Lots of it. I think you should be a little more open-minded to how businesses operate, that's all.

vkjv 8y ago

Unfortunately, PCI does not put very many restrictions on the parent website. If credit card elements are in an iFrame, the parent site is excluded from most requirements because the iFrame is "secure." Of course, if you own the parent site you can replace the iFrame with anything you want.

tyingq 8y ago
PCI also doesn't necessarily mandate some common sense things either, like monitoring for unexpected changes on the cart page.
marak830 8y ago
I'm still confused as to how they could insert code here. Are we talking about a server intrustion where they modified the actual cart code, or something between Newegg and the payment servers? (Sorry this isn't my domain, I'm just curious)
- lacker 8y ago
  It looks to me like a server intrusion where they modified static files kept on a webserver (like apache or nginx). But it also seems like we don't have enough evidence to know for sure. (Edit: or they might have been static files kept on a CMS.)
vkjv 8y ago
FWIW, I just checked and they don't use an iFrame approach. This means their entire checkout page must be in scope for SAQ-D.

lacker 8y ago

The article on the British Airways hack goes into a bit more detail, but still not enough to slake my curiosity. https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ https://www.riskiq.com/blog/labs/magecart-british-airways-br... It seems like we just don't have enough information to know how exactly the attackers got the JS onto the page. What it looks like, though, is that some machine serving static files for the website got compromised, and the attackers replaced an innocent file with one that had some custom javascript tacked onto the end, that skimmed the credit card numbers. For what it's worth, PCI compliance doesn't really help you keep your webservers secure, or to keep people from breaking into your servers at all, it's more about the way you permanently store credit card numbers.

pjc50 8y ago
It was appended to "Modernizr.js". That suggests a number of further possibilities by which that may have been replaced on a developer's computer, or at the point of download by a package manager (are packages authenticated?) It could well have been included in a legitimate re-deploy if that was the case.
- lacker 8y ago
  Since that file was served from "/cms/global/scripts/lib", perhaps their CMS got compromised. Anecdotally it seems like CMS's are more frequently prone to compromises than systems like nginx or apache.

zeveb 8y ago

Ditto. As an aside, while it's certainly true that if one can compromise a web server (whether serving static HTML or generating dynamic HTML) then it's game over, the modern style of JavaScript-centric development greatly expands the attack surface. An attacker can compromise any of a number of different servers (e.g. analytics providers), via numerous means; moreover, he can serve dynamic malicious code, and quickly respond to changes the targeted site makes (his implant needs to survive for awhile, but his access can be revoked and folks can still be compromised). Websites which served static pages and received credit-card information via simple forms would be far more secure than dynamic web apps stitched together from JavaScript served from multiple servers in countries across the globe, with data inserted into the DOM retrieved from multiple servers across the globe. I contend that a more traditional, static architecture would tend to lead to better architectural isolation. As an example, if one needed to install server-side analytics software rather than simply injecting it into a page at runtime, then one would download and install it once: any compromise of the analytics provider after one had download it would be irrelevant. But with dynamic JavaScript, one's users download the analytics software with every single page load: a compromise instantly affects users. Moreover, with traditional server-side software one tends to have reasonably-well defined protocols for interaction, rather than just saying, 'hey, I'll run all your code in the same process as everything else.' But with client-side JavaScript, any piece of code can see everything. As an engineering community, we've adopted a style which has great costs as well as great benefits. My opinion is that we moved too quickly, and now we're feeling the pain. While a universal portable app framework is pretty awesome, JavaScript layered over a document system is probably not the best way to achieve that. As I wrote years ago, JavaScript delenda est.

adreamingsoul 8y ago

PCI compliance isn't that hard to get. And, typically the code is changed after the compliance review. Also, developers and engineers at Newegg are probably changing lines of code every day. Which means, at any point in time someone could have accidentally introduced a vector that allowed the attackers to inject their code. Auditing and security reviews only work if every line of code is tested, reviewed, and verified. However, that be extremely costly and slow, which isn't "good for business". Maybe, we as consumers, engineers, managers, and executives should demand that code safety and security is prioritized over profit. I would rather have a secure website then a new redesign every two years.

yspeak 8y ago
This isn't fort Knox It's credit card info. There's always a cost benefit. You can spend all your time and money on doingsecurity reviews but without profit there ain't no company.
saas_sam 8y ago
Do you have any evidence to suggest "that code safety and security" was NOT "prioritized over profit"? How would you falsify this? Are we to assume that every security breach indicates that profit was prioritized over security? Doubtful. Also, "profit" is the reward for doing things efficiently, it is not some kind of scoreboard for how much a company is ripping off consumers. NewEgg is in such a hyper-competitive & mature space with margins in the low single-digits on average. Incidents like this can absolutely tank them, especially this close to the holiday season. E-commerce companies do not make money on security breaches, they lose it. Lots of it. I think you should be a little more open-minded to how businesses operate, that's all.