Slashdot Mirror

← Back to Stories (view on slashdot.org)

Year-Old Critical Magento Flaw Still Exploited, Payment Info Stolen

Posted by yaelk on from the bugs dept.

Orome1 writes: A whole year has passed since a critical e-shop hijacking flaw in the Magento CMS has been patched, but the vulnerability is still being exploited in attacks in the wild, warns Sucuri researcher Denis Sinegubko. At the time, the Magento development team pushed out a patch (SUPEE-5344) but after two whole months, 98,000 online merchants still hadn't implemented it. This forced the team to send out email alerts directly to the users, urging them to apply the patch immediately. Obviously, even that was not enough. Attackers are still actively deploying malware that exploits the vulnerability to inject malicious code into the Magento core file.

35 comments

  1. Helmet by Anonymous Coward · · Score: 2, Funny

    We all know by now. Just take off his helmet and Professor X can get in his mind.

    1. Re:Helmet by Chris+Mattern · · Score: 1

      Came to make Magneto joke, was beaten to it.

    2. Re:Helmet by Anonymous Coward · · Score: 0

      But How are you gonna take it off....it's made of metal!
      LOL

    3. Re: Helmet by Anonymous Coward · · Score: 0

      Just have someone (not Wolverine) whack him in the head with a plank.

  2. Hmmm .... by gstoddart · · Score: 1

    So, the oh-so-predictable "assume random e-commerce sites are security risks and don't use them"?

    Now I'm shocked that everyone who hoists a storefront on the web shouldn't be trusted. No, wait, the other one.

    This seems like it should have been expected, that's an awful lot of sites to assume they'd all keep up with security updates.

    --
    Lost at C:>. Found at C.
    1. Re:Hmmm .... by Anonymous Coward · · Score: 1

      Magento is the Wordpress of eCommerce. Free software that anyone can download, install on a server and modify/maintain/neglect as they see fit. A handy platform if you know what you are doing. A disaster waiting to happen if you don't.

      I also expect that a large percentage of the "stores" out there are zombie installations that never transact any business.

  3. No mention of the merchants? by Anonymous Coward · · Score: 0

    I'd like to avoid those merchants since they're potentially putting me at risk.

    1. Re:No mention of the merchants? by gstoddart · · Score: 1

      I'd like to avoid those merchants since they're potentially putting me at risk.

      Are they on the internet? Then they're probably putting you at risk.

      If big players like Amazon can get security breeches, that mom and pop shop which had a college student build them an e-commerce site hasn't got a chance.

      Plan accordingly. Small security holes on the internet tend to get magnified into big, giant, widespread security holes.

      --
      Lost at C:>. Found at C.
    2. Re:No mention of the merchants? by Grishnakh · · Score: 1

      This is exactly why sites should never handle credit card or other financial info. Decent mom-n-pop sites just use Paypal or Square or whatever, where all they do is implement a shopping cart, send the total over to the payment processor's website and redirect the user there, and then the user pays the processor (so the mom-n-pop shop never sees the CC#), then gets returned to the merchant website for confirmation.

      It's easy to write the code for this, and security just isn't a big concern because the mom-n-pop site isn't handling any critical data. There's not even a need for HTTPS encryption (until they get forwarded to the payment processor). Why sites would do it any other way is beyond me; the main reason seems to be something stupid like "so the customer has a consistent experience".

      Let the payment processor handle the critical data and deal with PCI compliance and all that. Don't try to do it yourself.

    3. Re:No mention of the merchants? by Anonymous Coward · · Score: 0

      Use crappy services that are both corrupt and have a strong political bent?

      I am sure a small retailer can afford to get accounts frozen by PayPal, or the account suddenly closed by Square for political reasons.

      Not to mention the distrust clients will have of PayPal after getting spam and phishing attempts in their email boxes for years...

      Great idea there pal.

    4. Re:No mention of the merchants? by Anonymous Coward · · Score: 0

      This is exactly why sites should never handle credit card or other financial info. Decent mom-n-pop sites just use Paypal or Square or whatever, where all they do is implement a shopping cart, send the total over to the payment processor's website and redirect the user there, and then the user pays the processor (so the mom-n-pop shop never sees the CC#), then gets returned to the merchant website for confirmation.

      Technically, you are correct. In fact Magento, which is part of the eBay & PayPal family (forget who owns what) includes this capability out of the box (but only for PayPal).

      The problem is that these methods create "friction" in the shopping experience which reduces sales. It is just a fact of life. What about the "friction" created by credit card fraud? So far, it simply isn't a priority. That's life.

      As far as PCI compliance, you can can be compliant enough to qualify for a nifty "PCI-DSS Compliant" badge on your site while still exposing payment info to card scrapers. I've seen hacks that scrape it out of the HTTP post after it is decrypted but before it is re-encrypted and forwarded to the payment gateway. I have also seen hacks that inject JS into pages that forwards payment info directly from the customer's browser to a remote server.

    5. Re:No mention of the merchants? by Grishnakh · · Score: 1

      So basically they do it because customers are so stupid they want a "frictionless" experience on the website rather than the security of only trusting their credit card details to a large organization that is more likely to have proper security than some random mom-n-pop website?

    6. Re:No mention of the merchants? by Anonymous Coward · · Score: 0

      So basically they do it because customers are so stupid they want a "frictionless" experience on the website rather than the security of only trusting their credit card details to a large organization that is more likely to have proper security than some random mom-n-pop website?

      Yes, exactly.

      However, please note that the larges organizations of all are CC companies who are as complicit in everyone in this risk management attitude.

    7. Re:No mention of the merchants? by Anonymous Coward · · Score: 0

      Yes, I understand what you are saying. Any online seller's website could put me at risk. However, this is a matter of where the there's a list of sites that do put me at risk because they are known to be vulnerable. I'd like to be aware of what sites to avoid since the risk is known.

    8. Re:No mention of the merchants? by Anonymous Coward · · Score: 0

      > If big players like Amazon can get security breeches

      That's "Safety Pants" to you.

      S-S-S-S
      A-A-A-A
      F-F-F-F
      E-E-E-E
      T-T-T-T
      Y-Y-Y-Y

    9. Re:No mention of the merchants? by Anonymous Coward · · Score: 0

      The problem is many folks don't go through First Data/etc - they use intermediaries that have written easy-to-consume libraries and web services and integrate those with their POS systems because they can get better rates than with Square and Paypal. Don't get me started on the "encrypted" swipers being sold (I see your XOR bit manipulation and bruteforce your "secret" in mere seconds), the fact that many swipe devices use the audio jack and frequencies well within hearing range that could be recorded and sent over the web, or that most of the Windows-based POS implementations I've seen use antiquated encryption libraries that allow you to get a pointer to the unencrypted string before it's encrypted.

      So yes - Square and Paypal are probably the most secure routes, but they're far more expensive than many alternatives and that's the biggest factor in many business decisions.

    10. Re:No mention of the merchants? by Grishnakh · · Score: 1

      Maybe I'm missing something, but what the heck are you talking about? This is about Magento, which is a PHP-based e-commerce system that runs on smallish websites. This has nothing to do with smartphone-based in-person payment systems (like you'd see at a small brick-and-mortar shop), or with Windows in any way (no one runs PHP on Windows, and you're talking about Windows-based POS, we're not talking about POS here, we're talking about web shops).

      For a small mom-n-pop web shop, I don't think you're going to find a payment processor with better rates than Paypal/Square. Bigger sites with a lot of volume can find better rates, but when you're small they're generally not worth it because of the fees.

  4. Question: Why is 1 year the threshold? 1 day? by Anonymous Coward · · Score: 0

    1 year seems like an awfully large unit to finally re-notice some glaring unfixed problem with common payment systems.

  5. What? Say it isn't so! by JustAnotherOldGuy · · Score: 1

    Headline Translation: "Users Don't Update Stuff, Film at 11"

    --
    Just cruising through this digital world at 33 1/3 rpm...
    1. Re:What? Say it isn't so! by gstoddart · · Score: 1

      And until companies bear legal liability for these kinds of things they fail to fix, assume it will keep happening.

      Running an e-commerce site with a year old known flaw? Sorry, that's either negligence or incompetence. In neither case should you be trusted to run an e-commerce site.

      The internet is a cesspool of terrible security, and I don't see that changing as long as companies just utterly fail to keep on top of this stuff.

      --
      Lost at C:>. Found at C.
    2. Re:What? Say it isn't so! by Grishnakh · · Score: 1

      What's incompetent is implementing a small e-commerce site which actually handles financial data. There's simply no reason to. It's almost trivial to set up a Paypal business account which handles payment processing; the e-commerce site just sends the shipping cart over and redirects the customer to Paypal, and then the customer enters their credit card info there (or logs in), pays, and gets redirected back for order confirmation.

      The only reason the e-commerce site should ever handle that data is because they're someone like Amazon and want to make it really easy for the customer to re-order stuff or buy more stuff on the same card, and also because if you're Amazon you do your own payment processing. If you're some little mom-n-pop shop, you shouldn't be thinking about any of that stuff, you should be staying far away from handling customer financial data and letting your payment processor handle it for you.

    3. Re:What? Say it isn't so! by JustAnotherOldGuy · · Score: 1

      What's incompetent is implementing a small e-commerce site which actually handles financial data. There's simply no reason to. It's almost trivial to set up a Paypal business account which handles payment processing; the e-commerce site just sends the shipping cart over and redirects the customer to Paypal, and then the customer enters their credit card info there (or logs in), pays, and gets redirected back for order confirmation.

      ^^^^^THIS. Get a Paypal business account or use something like Authorize.net or 2CheckOut or any of a hundred other solutions.. Ecommerce is fraught with pitfalls and if Joe and Jane Sixpack do it you can almost bet they'll do it wrong. Keeping credit card numbers (a mistake I see over and over) is just plain foolish, and can subject you to some serious penalties if you screw up (or if someone screws you up).

      So I agree 100%- let a well-established company handle this stuff. I have quite a few card payment forms on various sites but I never handle the transactions- customers fill in a minimal amount of info and then get forwarded to Authorize.net or 2CheckOut for the actual processing. I never see any of their card data and so I don't have to worry about keeping it secure.

      --
      Just cruising through this digital world at 33 1/3 rpm...
    4. Re:What? Say it isn't so! by hairyfeet · · Score: 1

      Exactly and its because these sites are not being held to the same standards as B&M stores and this needs to end. If a local B&M let their security get THIS lax, so money and merchandise was just walking out the store by the truckload and customers were getting robbed and their cars busted into a dozen times a day? No insurance would have anything to do with them, no suppliers would sell to them, and most importantly the CC companies would yank every card scanner they had and they would go out of business in a week.

      The same needs to happen with e-commerce, the CC companies need to pull their ability to take cards, in fact I would go one further and say we need something similar to WOT or Comodo DNS blocking when it comes to e-commerce, something that will load a page when you try to go to these sites that has something like a red stop sign and "This site has been cited for not securing user data and credit information X number of times, and it has been reported that they are using software as of (this date) that is currently vulnerable to attack. Do you wish to continue?" so that the user can make a somewhat informed choice as to whether to shop there. I'm sure if this were to happen? These companies would go out of their way to fix shit REAL quick.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    5. Re:What? Say it isn't so! by Anonymous Coward · · Score: 0

      Get a Paypal business account or use something like Authorize.net or 2CheckOut or any of a hundred other solutions.

      Magento includes an Authorize.net integration. This is one of the payment methods that is being exploited, because even though the Magento site does not store the payment info, it must pass it from the customer's request to the gateway. Either PHP is hacked to scrape this data as soon as the customer's request is decrypted, or the CMS is hacked to inject card-scraping JS into the browser (which forwards it before it is ever submitted to the Magento site).

      The only way to avoid this type of vulnerability is to forward the user to the payment provider's separate website. Customers don't like this, and customers are always right!

    6. Re:What? Say it isn't so! by Anonymous Coward · · Score: 0

      . . .and most importantly the CC companies would yank every card scanner they had and they would go out of business in a week.

      The same needs to happen with e-commerce, the CC companies need to pull their ability to take cards, in fact I would go one further and say we need something similar to WOT or Comodo DNS blocking when it comes to e-commerce, something that will load a page. . .

      You seem to believe that CC companies are motivated to deal with this type of issue. They aren't. From their perspective, measures to combat fraud more effectively would cost them more than they currently lose to fraud. Security is bad for (their) business.

  6. That's okay, because Magento is an app! by Anonymous Coward · · Score: 0

    Modern app appers know that ONLY apps can app apps, so LUDDITE hackers can't app the app; only apps can!

    Apps!

    1. Re:That's okay, because Magento is an app! by Anonymous Coward · · Score: 0

      Oh, give it a fucking rest.

      You're not even as funny as the cows troll, who's about as funny as a dick-shaped door knocker.

  7. Open source by mystikkman · · Score: 0

    Isn't it open source?

    Why is there no fix then?

    1. Re:Open source by Anonymous Coward · · Score: 1

      For crying out loud, did you even read the *summary*?

    2. Re:Open source by Grishnakh · · Score: 1

      -1 Stupid. Read the fucking summary, open-source-hating moron.

      There *is* a fix, the problem is the users haven't applied it.

      And Magento is only barely "open source". There's not a single comment anywhere in their source code; it's not made to be easy for others to work with, it's only "open" so they can sell it as such, and then get customers to send them $$$ for customizations because it's too much of a PITA to do it yourself when the code is so intentionally obtuse.

  8. They need to publish the list by jafiwam · · Score: 1

    So everybody knows not to use those merchants and they find themselves with their foolish SEO navel gazing efforts.

  9. Patch Non-Production Servers As Well by Anonymous Coward · · Score: 1

    I had my own run in with this bug. I'd patched my production servers, but had an unpatched development server that was publicly exposed to the Internet for testing some things with outside vendors. I didn't realize it was unpatched--just happened to install that from a backup that predated installing SUPEE-5344. It was fun to go through the system in a virtualbox after it got hacked and mess around with the "Linux.Encoder.1" ransomware they uploaded to the server. http://daviddeppner.com/blog/magento-ransomware is a Blog post I wrote about the experience.

  10. Upgrade mech sucks by cdwiegand · · Score: 1

    Too bad its update mechanism sucks balls. You can apply "patches", which I find often require fuzzy matches to work, but you can't actually UPGRADE to a newer version, you have to install that on a separate folder and database, then schedule a time to take it all down and export/import the whole database, orders, themes and all. It's crazy complex compared to Wordpress' simply Upgrade Now button.

    --
    . Define sqrt(x) as something really evil like (x / rand()), and bury it deep. Watch your coworkers go nuts.
  11. All software needs simple automatic updates by Anonymous Coward · · Score: 0

    All software needs simple automatic updates by default.
    If a user is advanced enough to apply it themselves, then they are generally smart enough to disable automatic updates if needed.

    I think having an automatic patch schedule selection grouping that corresponds to an automatic installation delay, would be beneficial for this.
    For example, if there's groups 0-10 (range of security vs stability), default is randomly assigned groups 3-6, where group 0-2 installs stable patches first (manually assign for dev\test\staging respectively), 3-6(would be default and should be for most systems), 7-9 (manually assign, and would be insecure the longest, but the last group to install patches, for internal prod apps, public prod apps, and critical prod apps respectively), and 10 which would disable auto updates.

    ChromeOS and debian both have autoupdate functionally, which I've seen work very well (maybe all software needs to support apt-get ;-) ).