NutriBullet, the blender company, has been outed by RiskIQ for its continued failure to remove credit card skimming malware from its website. The attack was first detected on February 20th. Despite being warned of the attack, NutriBullet has ignored RiskIQ.
However, the inaction by NutriBullet enabled the attackers to change the code to point to another exfiltration site. When that was taken down, they changed the code again. This puts anyone using the online shop on the NutriBullet website at risk of having their data stolen.
According to the blog written by Yonathan Klijnsma: “RiskIQ researchers reached out to NutriBullet via their support channel and NutriBullet leadership via LinkedIn less than 24 hours after the incident and continued outreach over the next three weeks.
“As of the date of this blog, our attempts at communication with NutriBullet have not been answered. The compromise is ongoing, and credit card data may still be getting skimmed, even as NutriBullet runs ad campaigns to pull in more customers.”
The timeline of the NutriBullet attack
The timeline of the attack shows how quickly attackers can rebuild an attack when the infrastructure is taken down.
20th February: Magecart Group 8 places JavaScript Skimmer on the Nutribullet site. Code detected at 3pm and RiskIQ attempts to contact NutriBullet. After no response RiskIQ initiates takedown of the exfiltration domain with the help of AbuseCH and ShadowServer.
- March 1st: Skimmer removed.
- March 5th: New skimmer added at 7pm GMT. RiskIQ gets the infrastructure neutralised.
- March 10th: Another skimmer added.
- March 18th: RiskIQ goes public to protect users from the skimmers and NutriBullet inaction.
How did the code get on the website?
There is nothing special in how this attack unfolded. The attackers simply attacked a common resource – the jQuery JavaScript Library. The skimmer code was appended to the bottom of the jQuery library ensuring that it would get called whenever the library was loaded.
Klijnsma notes that the code being used by Magecart Group 8 is well known. It has been used in multiple attacks since 2018. He goes as far as saying: “So far, we have observed this skimmer code on over 200 victim domains and have identified 88 unique actor-owned domains.”
The attack itself raises the question of what measures were being taken to protect the code on the website? Setting the right permissions and security is the first thing to do. There are a lot of files on websites that should be read-only. Setting this is table stakes for website security.
Creating an individual hash code for all files on a website and comparing it to the previous day is another measure. It will quickly show when a file has been changed and allow administrators to identify and remedy any attack. This is a process that can be easily automated to speed things up on sites with very large numbers of files.
According to Jake Moore, Cybersecurity Specialist at ESET: “At a time like this, many companies may take their eye off the ball, but these threat actors are persistent and will exploit anywhere they can. The automated nature of these attacks suggests that the code used in the website was not properly secured as the attackers were able to automatically spot which sites had vulnerabilities.”
Organisations need vulnerability reporting mechanisms
At RSA 2020, Veracode was one of several vendors who presented on the need for a proper vulnerability reporting mechanism. In other talks, some researchers admitted spending months or even a year or more getting the attention of vendors. The use of social media to shame companies into talking to researchers is becoming a common theme.
In this case, it seems that RiskIQ has tried all the expected sources such as email and LinkedIn. Those have all been ignored or rebuffed, hence its move to publicly out NutriBullet for its lack of response. This should be taken as a lesson for companies who are struggling to establish their own reporting processes. Act now or risk being publicly shamed.
As Moore says: “This highlights the need for web developers, especially ones dealing with inputs of sensitive information like credit cards, to keep updated for any discovered vulnerabilities to reduce exposure. The likes of Ticketmaster and British Airways have been struck in the past like this so these attackers are aiming big.”
Enterprise Times: What does this mean?
While Moore is right that the attackers are persistent, organisations have to take responsibility for security. In this case, NutriBullet is capturing customers payment details and not acting to protect them. The lack of a process to report this vulnerability will be of interest to regulators when they investigate this breach.
The failure to act may also cause credit card companies to act. By not patching and fixing the issue, the company is pushing the problem back to them to deal with. They will want to know what is happening and how the company intends to fix it.
For now, consumers use the site at their own risk until NutriBullet announces that it has identified and fixed the problem.
