Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by n1 on Friday June 23 2017, @05:43AM   Printer-friendly
from the dummies dept.

Bleeping Computer reports South Korean Web Hosting Provider Pays $1 Million in Ransomware Demand

Nayana, a web hosting provider based in South Korea, announced it is in the process of paying a three-tier ransom demand of nearly $1 million worth of Bitcoin, following a ransomware infection that encrypted data on customer' servers.

The ransomware infection appears has taken place on June 10, but Nayana admitted to the incident two days later, in a statement[1] on its website.

A Trend Micro analysis of the Nayana systems reveals endemic problems. It is no surprise that the hosting provider fell victim to this infection.

NAYANA's website runs on Linux kernel 2.6.24.2, which was compiled back in 2008. [...] Additionally, NAYANA's website uses Apache version 1.3.36 and PHP version 5.1.4, both of which were released back in 2006. Apache vulnerabilities and PHP exploits are well-known;[...]. The version of Apache NAYANA used is run as a user of nobody(uid=99), which indicates that a local exploit may have also been used in the attack.

The Register reports:

South Korean hosting co. pays $1M ransom to end eight-day outage

More than 150 servers were hit, hosting the sites of more than 3,400 mostly small business customers.

After a lengthy negotiation with the hackers, a demand for Bitcoin worth 5 billion won (nearly $4.4 million) was trimmed to around $1 million (397.6 Bitcoin), and the company paid up. The ransom was demanded in three [installments]; so far, two have been made.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by bzipitidoo on Friday June 23 2017, @02:28PM (1 child)

    by bzipitidoo (4388) on Friday June 23 2017, @02:28PM (#530025) Journal

    Production environment is always a balancing act. Yes, absolutely do not patch the system for mere bug fixes. Just too much chance something will break. The most innocent seeming tiny change can cause problems. Don't try anything too edgy, such as btrfs, stick with ext4, maybe xfs. Lot of work to move everything to a different file system if it was on btrfs, and the processes do a lot of syncing which was notoriously slow on btrfs and for that reason it's necessary to use something else. If you're lucky, a rollback can undo the damage. You can still log in remotely even though it takes a solid two minutes for a shell to come up, and every command you type takes another minute to execute. But that can be good enough to slowly regain control. Stop the services, free up some space, and see the server become much more responsive.

    If you're unlucky, the change has caused all the RAM and swap space to be allocated, the hard drives to fill with garbage and the systems to go down, or something else ugly, so that a trip to the data center is necessary. Not to mention that the company's website or core services are now offline and likely to remain so for hours while everyone scrambles to fix things. You always want to test security patches as much as possible before deploying them.

    Yet running such old versions of Apache and the Linux Kernel is unacceptable. This strikes me as more of a case of management not wanting to pay to update their systems. And, don't they keep backups? Also too cheap to back things up daily, or at least weekly? Jeez, do they also like to go for swims in crocodile infested rivers? So they got pwned and now they're going to pay a whole lot more in ransom. And maybe they'll get the data back.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by kaszz on Friday June 23 2017, @05:15PM

    by kaszz (4211) on Friday June 23 2017, @05:15PM (#530089) Journal

    Now that you point it out:
      * No update of kernel or Apache since 2008
      * No backup

    One could be forgiven perhaps for one. But both of them just smells negligence a long way.