Tag Archives: Magecart

Magecart, the Credit Card Stealing Monster, Is Alive and Well

In one research report researchers have discovered Magecart attacks affecting 17,000 web domains including some in the Alexa Top 2000.  You may remember that Magecart is what took down British Airways and likely caused them to be fined 183 million Pounds by the UK Information Commissioner’s Office.

Magecart is not a single hacker or even a single organization, but rather a technique for injecting Javascript that steals credit card information into otherwise okay web pages.  This group looked for unprotected Amazon S3 buckets (really, did people not get the memo – apparently not) to compromise the Javascript code.  In this case, many of the pages are not even checkout pages, so they are just spraying to see what they get.

The Javascript code that they are inserting is heavily obfuscated to make it very difficult for anyone to figure out what it does.  Most developers looking at code like that will just  move on.  Source: The Hacker News.

In a separate report, Sanguine Security says that they identified 962 web sites that were infected with Magecart in one day.   They described it as the largest automated campaign to date.  The previous record was 700 in one day.  Source: Info Security Magazine.

Whether there is some overlap in sites between these two research groups is unknown, but what is clear  is that attackers are very successfully figuring out how to inject malicious code in otherwise reputable web sites undetected.    Two examples of large web sites that have been infected by this technique are Ticketmaster (EU) and British Airways, so it is not just effective on small sites.  Most of the sites infected are, in fact, relatively smaller sites.

Bottom line is that all sites need to consider the possibility of their code being infected with malware and take measures to reduce the risk of that happening.  This includes things like checksumming files and installing software to detect modification of existing files and the addition of new files.

But this also affects third party code that is integrated into your web site.  As we have seen with a number of third party attacks, the attackers hit the weakest point, and if that is third party code that you use, that is fine with them.

 

Facebooktwitterredditlinkedinmailby feather

eCommerce Sites Hacked by Their Ads

The Magecart malware has stolen credit card information from such high profile web sites as British Airways,  Ticketmaster and Newegg.

The malware works by inserting a little bit of code – usually Javascript – into the page(s) of a web site that collects credit card information.  When a customer visits that page the  malware collects the credit card data, usually encrypts it and then sends it on to the attacker.

Sometimes the hackers break into the target website and insert the code but other times they compromise software libraries that web site developers use.

Now there is a new version of the Magecart malware.

Instead of infecting the website, this version infects the advertisements that run on those websites.

The ads get inserted when the web page is delivered and the malware is unleashed.  The credit cards are stolen in the same manner as the other attacks.

The reason that this is attractive to hackers is that if you can infect the advertising software you will be able to attack hundreds, thousands or even more web sites at once.  To a hacker, that is nirvana.

What is depressing to the merchant is that the attack is not under their control because they don’t have any visibility into the ads that are shown  on their websites.  For more details on how the attack works, visit the link at the end of this post.

So what is a merchant to do?

There are some things that you can do.

If you run a web server, most data transfers should be as a result of responding to an inbound request from a potential customer.  

When the hacker sends the credit card data to its collection machine, it is initiating an outbound session that isn’t based on a customer request.  Those should be blocked or at least scrutinized.

Also you can look at the metrics of how much data you send in response to a customer request.  If the hacker is moving data in large blocks, that might be a tip off.

The hackers could send the data to a server in the US or at Amazon, but they also might send the data to a server offshore.  Unless your business is international, you should block those off shore connections and if your off shore business is limited – say to Europe – then block connections to Africa and Asia.

Finally, check your code and query the ad networks that you use.  Everyone should be sensitive to the issue and if you don’t get an answer that you like, there are other ad networks.

Information for this post came from Bleeping Computer.

 

Facebooktwitterredditlinkedinmailby feather

News Bites for the Week Ending December 7, 2018

Australian Parliament Passes Crypto Back Door Law Overnight

Politics always wins.  After the Prime Minister said that the opposition party was supporting terrorism, the opposition completely folded after claiming that Parliament would implement amendments after the first of the year.

Since politicians lie about 99.99% of the time, the party in power is now saying that they only might, possibly, consider some amendments.

It is not clear what software companies will do if asked to insert back doors.  One thing that is likely true is that they won’t tell you that they have inserted back doors into your software.  Source: The Register.

 

Sotheby’s Home is the Latest Victim of Magecart Malware

Magecart is the very active malware that has been found in hundreds of web sites and which steals credit card details from those sites before they are encrypted.

Sotheby’s, the big auction house, says that if you shopped on the site since, well, they are not sure, your credit card details were likely stolen.

They became aware of the breach in October and think that the bad guys had been stealing card data since at least March 2017.

Eventually governments will increase the fines enough (Uber just got fined $148 million – we are talking REALLY large fines) that companies will make the decision that it is cheaper to deal with security than pay the fines.  GDPR will definitely help in that department with worst case fines of up to 4% of a company’s global annual REVENUE (not profit).

Sotheby’s acquired the “Home” division about 8 months ago, so, like the Marriott breach, the malware was there when they acquired the company and their due diligence was inadequate to detect it. Source: The Register.

 

Sky Brazil Exposes Info on 32 Million Customers Due to User Error

I continue to be amazed at the number of companies that can’t seem to do the simple things right.

Today is it Sky Brazil, the telecom and Pay-TV company in Brazil.

They were running the open source (which is OK) search tool Elastic Search, made it exposed to the Internet and didn’t bother to put a password on it.  Is password protecting your data really that hard?  Apparently!

What was taken – customer names, addresses, email, passwords (it doesn’t say, so I guess they were not encrypted), credit card or bank account info, street address and phone number, along with a host of other information.

After the researcher told them about their boo-boo, they put a password on in quickly.  We are not talking brain surgery folks. How hard is it really to make sure that you put a password on your publicly exposed data?

Apparently the data was exposed for a while, so the thought is that the bad guys have already stolen it.  Nice.  Source: Bleeping Computer.

 

Yet Another Elastic Search Exposure – Belonging to UNKNOWN

Maybe this is elastic search week.  Another group of researchers found a data trove of elastic search data, again with no password.  Information on 50 million Americans and over 100 million records.

Information in this case is less sensitive and probably used to target ads.  The info includes name, employer, job title,  email, phone, address, IP etc.  There were also millions of records on businesses.

In this case, the researchers have no idea who the data belongs to, so it is still exposed and now that they advertised the fact that it is there, it probably has been downloaded by a number of folks.

That kind of info is good for social engineers to build up dossiers on tens of millions of people for nefarious purposed to be defined later.  Source: Hackenproof.

 

Microsoft Giving Up on Edge?  Replacing it with Chrome?

If this story turns out to be true – and that is unknown right now – that would be a bit of a kick in the teeth to Microsoft and a huge win for Google.

Rumor is that the Edge browser on Windows 10, which is a disaster, along with Microsoft’s Edge HTML rendering engine are dead.  Rumor is that Microsoft is creating a new browser, code named Anaheim,  based on the open source version of Chrome (called Chromium) which also powers the Opera and Vivaldi browsers.

If this is true, Google will effectively own the browser market or at least the browser engine market.  That could make them even more of a monopoly and a target for the anti-trust police.  Source: The Hacker News.

 

Turnabout is Fair Play

While the Democratic party seems to have escaped major hacks in this election cycle, apparently, the Republicans didn’t fare as well.

Several National Republican Congressional Committee senior aides fell to hackers for months prior to the election.  The NRCC managed, somehow, to keep it quiet until after the election, even though they had known about it for months.

Once way they kept is quiet is by not telling Speaker Paul Ryan,  Majority Leader Kevin McCarthy or other leaders about it.

In fact, those guys found out when the media contacted them about the breach.  I bet they are really happy about being blindsided.

Anyway, the cat is out of the bag now and the NRCC has hired expensive Washington law firm Covington and Burling as well as Mercury Public Affairs to deal with the fall out.  I suspect that donors are thrilled that hundreds of thousands of dollars of their donations are going to controlling the spin on a breach.

Whether the hack had anything to do with the NRCC’s losses in the past election is unknown as is the purpose of hacking the NRCC.  It is certainly possible that the hackers will spill the dirt at a time that is politically advantageous to them.  I don’t think this was a random attack.  Source: Fox News.

 

Another Adobe Flash Zero-Day is Being Exploited in the Wild

Hey!  You will never guess.

Yes another Adobe Flash zero-day (unknown) bug is being exploited in the wild.  The good news is that it appears, for the moment, to be a Russia-Ukraine fight. The sample malware was submitted from a Ukraine IP address and was targeting a Russian health care organization.  Now that it is known, that won’t last long.

The malware was hidden inside an Office document and was triggered when the user opened the document and the page was rendered.

Adobe has released a patch.  Source: The Hacker News.

Facebooktwitterredditlinkedinmailby feather

Credit Card Theft Continues to Rise

The hackers seem to be winning.

One solution I have advocated for over the last many years to reduce credit card fraud is a technique called credit card tokenization.  When a merchant accepts a credit card, that card information is immediately tokenized and that token is all that the merchant keeps.  If they need to rerun the credit card, say for a monthly recurring charge, they present that token to their payment processor and they get paid.  If hackers steal the tokens, it does them no good because those tokens can be locked down to that merchant or even to that server.

So the hackers innovate, even though the vast majority of merchants don’t tokenize.

They slip a tiny bit of code (15 lines) into a library that MANY merchants use and it watches for a credit card passing through.  They grab the card info before it is encrypted and before it is tokenized.

Since online transactions do not take advantage of chip technologu (yet), this card information can be used in other online environments.

This week’s announcement is NewEgg.Com, a computer hardware and software seller.  The hackers ran wild from mid August to mid September.  The malware is called MageCart.

This is the same malware that attacked Ticketmaster and also British Airways.

Along with thousands of other sites.

So What do you do?

If you are a merchant, you have to deal with the lack of security on your web server that could allow a bad guy to install MageCart.  Since this is buried inside some other software that you use as part of the your development.   Eliminating this is part of what the DoD calls SCRM or Supply Chain Risk Management.  Not easy, but absolutely required.

If you buy things online, you can protect yourself by shopping locally.  🙂

Sure.  That is not gonna happen.

But there are a couple of things you can do.

Sign up for text alerts from your bank or credit card company so that you get notified EVERY time you card gets used.  In real time.  That way, at least, you can kill the card before even the first transaction clears.

Second, you can use one of the vendors that single use credit card numbers.  The biggest issuer that does this that I am aware of is Capital One.  Their service, called ENO (one spelled backwards), includes a browser plugin that automatically issues disposable card numbers that are uniquely tied to a single merchant.  If the number is stolen, it can’t be used at a different merchant and while that card number is tied to your actual card, the actual card number is never exposed so that if that one site is hacked, only that card number has to be replaced, not every one.  And, since they have a browser plugin, the process is pretty simple to use.

The last option I have is to use prepaid cards.  Most banks offer them.  Chase calls theirs Chase Liquid, for example.  Sometimes the bank charges a few bucks a month for the service, but often you can get them to waive that.  That card is tied to your online userid but the account does not draw from any other account.  If you, for example, leave $100 in that account, that is the max the bad guys will get and you will be reimbursed by the bank if the charge is unauthorized.  The challenge is that you have to manage having exactly the right amount of money in that account, so the Capital One strategy is a lot easier.

Information for this post came from The Hacker News.

Facebooktwitterredditlinkedinmailby feather

Third Party (Vendor) Cyber Risk Management Rears its Ugly Head AGAIN!

This seems to be a recurring topic, but it doesn’t seem to be getting any better, so I will leap back into the fray.

Last month Ticketmaster announced they had a breach and they led people to believe that it was isolated and that it had something to do with their software.

According to RiskIQ, the breach at Ticketmaster is due to a third party vendor named Inbenda, but that is just one vendor affected – the one that Ticketmaster uses.

Tools that may be affected or infected include Magento, Powerfront and Opencart.  Payment services including Braintree and Verisign may be being targeted.

The attack has been refined over time since 2016.

RiskIQ has identified 800 infected websites including some from very big companies.

Magecart, which is what they are calling the attack itself, continues to expand and some of the infected tools could capture 10,000 victims at a time.

So what do YOU do?

First of all, you need to identify all of the third party software that you use and that your contract developers use.  This includes software that is integrated into the various software products and tools that are installed on the servers where the products run.  It doesn’t matter if the software is commercial or open source.

Then you need to create a vendor cyber risk management program.  That will measure the overall cyber security awareness and preparedness of each vendor.

YOU need to make sure that these vendors are on top of bugs in their systems and then you need to make sure that your IT and development teams have created a way to be alerted BOTH when bugs are found and then when patches are released.

Finally, you need to make sure that ALL patches are installed on all machines.  Depending on the piece of software affected, it may require a completely new build from the vendor and then a reinstall of the product.  Make sure that you understand what is required because it may not be obvious.

Then, of course, you need to test the patch to make sure that it really fixed the bug.  They don’t always!

If this seems like a pain in the &^%$#, it is.  Sorry.

And, you need to do this for each software product from each vendor.  On each computer on which it is installed.

That is why many companies don’t have a vendor cyber risk management program and why many companies get caught in breaches like this.  Sometimes they don’t even know that they are vulnerable or that they have been compromised.

Information for this post came from RiskIQ.

Facebooktwitterredditlinkedinmailby feather