[BreachExchange] 100+ online shops compromised with payment data-stealing code

Inga Goddijn inga at riskbasedsecurity.com
Fri Oct 7 10:23:55 EDT 2016


https://www.helpnetsecurity.com/2016/10/07/payment-data-stealing-code/

Since March 2016 (and possibly even earlier), someone has been compromising
a variety of online shops and injecting them with malicious JavaScript code
that exfiltrates payment card and other kinds of information users entered
to pay for their shopping.

The threat actor has compromised more than 100 online shops, including that
of UK book publishing house Faber and Faber, clothing/fitness company
Everlast, GUESS Australia, fashion brand Rebecca Minkoff, beauty products
retailer The Beauty Place, and many, many more
<https://www.riskiq.com/blog/labs/magecart-keylogger-injection/>.

Most of them have hopefully been cleaned by now but according to RiskIQ and
ClearSky researchers, the campaign – which they dubbed Magecart – is still
ongoing, albeit at a reduced scope and pace.
Magecart: A well-oiled machine

“In order to implant the malicious JavaScript code, the attackers first had
to get access to change the source code of the website,” ClearSky
researchers explain <http://www.clearskysec.com/magecart/>.

“They might have gained this access by exploiting a vulnerability in the
web platform (such as Magento Commerce, Powerfront CMS, OpenCar, etc.) or
by getting a hold of admin credentials.”

Then, they would change certain web pages’ code to make them load the
malicious script from one of the many domains they set up to host it.

“The credit card stealer works in a very similar manner on the compromised
web server as a banking trojan functions on a compromised victim
workstation,” RiskIQ researchers point out.

“Code is injected which can ‘hook’ web forms and access data form
submissions much like a formgrabber. Data is exfiltrated from the
compromised server to a dropzone for attacker collection. There is also
some indication in related payloads that attackers may be injecting bogus
form fields into payment forms to solicit additional data from victims.”

The attackers have been refining the system for months. They’ve been
testing obfuscation techniques (payload delivery in two stages, conditional
activation of stealer scripts, etc.), renaming the malicious script to
blend in with the site, registering attack domains with names that use the
company’s name or that of commonplace web technologies, and so on.

They also made sure that the sites hosting the malicious code had a valid
SSL certificate, so that the code would be served over HTTPS. As most
online shops use SSL to protect users’ payment data, loading the malicious
script from a HTTP site would trigger a “mixed content” warning, and make
users suspicious.
What can we do about it?

Unfortunately, if you have bought products from one of these shops at a
time when they were compromised, your payment card and other info has been
slurped by the attackers.

The only way to prevent this type of attack is to use content whitelisting
plugins such as NoScript, RiskIQ researchers note.

“These types of add-ons function by allowing the end user to specify which
websites are ‘trusted’ and prevents the execution of scripts and other
high-risk web content. Using such a tool, the malicious sites hosting the
credit card stealer scripts would not be loaded by the browser, preventing
the script logic from accessing payment card details,” they explained.

It’s also in the best interest of the owners and administrators of these
(and all) types of websites to do their best to keep them secure by:

   - Hardening their installations and shopping cart software
   implementations, and regularly updating them and patching them
   - Keeping their credentials for accessing admin interfaces and
   underlying web hosting environments secure
   - Using strong authentication schemes and 2-factor authentication or
   2-step verification, and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20161007/0d68108a/attachment.html>


More information about the BreachExchange mailing list