SoylentNews is people
SoylentNews
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.
(Score: 0) by Anonymous Coward on Friday June 23 2017, @06:32AM (9 children)
Not the ideal situations, but it is how it is. "Don't change what ain't broke".
I was still working on kernel 2.4 workstations a few years ago.
(Score: 2) by Arik on Friday June 23 2017, @08:31AM (4 children)
Apache was what was broken. An old version of Apache, yes, but additionally one without even security fixes. Running as ((nobody)).
Cause, you know, it's so much easier to get it all working quickly that way.
If laughter is the best medicine, who are the best doctors?
(Score: 3, Interesting) by TheRaven on Friday June 23 2017, @08:56AM (3 children)
sudo mod me up
(Score: 1) by anubi on Friday June 23 2017, @10:33AM (2 children)
I believe things like this are precisely the reasons we need a very *simple* public general OS that is just about as hard to phkup as a hand-calculator.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by TheRaven on Friday June 23 2017, @10:50AM
sudo mod me up
(Score: 2, Disagree) by tibman on Friday June 23 2017, @01:31PM
That might not be the OS you would use to serve the websites of 3,400 companies.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by bzipitidoo on Friday June 23 2017, @02:28PM (1 child)
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.
(Score: 2) by kaszz on Friday June 23 2017, @05:15PM
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.
(Score: 2) by shipofgold on Friday June 23 2017, @06:14PM (1 child)
Given the publicity of ShellShock bash vulnerability you would have thought that someone would have though a little about updates....I find it hard to believe that anyone running Linux would not have heard about ShellShock and at least gave an inkling to updating to a newer version of bash.
I wonder how many production systems still have ShellShock active and waiting for fun like this.
However, to paraphrase what parent stated: "if it aint broke don't fix it." Admins probably thought about updating, but given the age of the system feared something would break...updating to fix ShellShock probably meant a full system upgrade to a later release...I know how painful that can be.
In the end it cost somebody $1M which aint nothing.
IMHO, no backups is more unforgivable than no updates. Weekly backups would have given them a route around a $1M payment.
(Score: 0) by Anonymous Coward on Friday June 23 2017, @07:08PM
...and Heartbleed.
N.B. I love how big unpatched vulnerabilities in FOSS OSes are so rare that M$ fanboys make an effort to create cute names and logos for those.
Too bad those folks don't put that effort into Redmond's software and curing its Vulnerability of the Day thing.
...or has it gotten to Vulnerability of the Hour already?
-- OriginalOwner_ [soylentnews.org]