This is what it looks like when your website is hit by nasty ransomware Malware appears to have hijacked the British Association for Counselling and Psychotherapy (BACP)'s website – and held it to ransom. The front page of the site has been replaced with instructions on how to pay off the extortionists: $150 (£100) in Bitcoin must be coughed up by February 22, or the association's web data will …
There was previously similar malware that attacked and encrypted Linux based NASs called Synlocker. Presumably someone has adapted it to a new target vector, or has written a similar one. After all there are no shortage of holes to target on open source based web stacks...
Probably not best to link directly to a website which is known to have been hacked.
Whether the server was hacked or files transferred from a naughty Windows PC, it seems unwise to be sending el Reg's innocent eyeballs to a site which could well spring malware to the undeserving.
I was thinking along similar lines: A pointy-clicky amateur Windows mess sitting behind a grown-up, possibly professionally operated proxy/cache/firewall.. and someone sitting at the back-end "server" checking their email doubleclicked on a dodgy.pdf.exe which had appeared on the desktop. Or somesuch.
Alternatively, a NFS connection from a (pwned) Windows "admin" desktop to the server's DocumentRoot might be an effective way to achieve the effect?
I'm also imagining there was probably a lot of member account data and member-only material accessible only to account holders on the thing which won't be externally crawled/cached.
Hope they bothered to maintain a proper backup regimen and won't be too damaged by their lesson.
We hear about homepage hacks all the time.
Has anyone @ BACP actually verified they've been hit, I wonder?
With the number of high-profile homepage hacks some simple social engineering would make the appearance of a bit-locker claim make the target convinced it was true.
Have they actually tried restoring the website, I wonder? That may well be all that's wrong (plus bloody awlful security in the first place)
"This stuff looks for and spreads to backups before it announces itself."
Which is exactly why at my company we don't back up from our web server.
We have an in-house development system that is airgapped from the internet. When we deploy a website, we burn a DVD (No USB drives are permitted on our development machines) from the dev system and upload that to our web host. If there are any changes to be made, a new disc is burned and uploaded to the web host. The only thing that comes back from the web host is the contents of the databases and that goes onto DVD as backup each day. This copy is then checked against an offline MySQL server to ensure the data has not been secretly encrypted. If it has been, then we know our web host has been infected and can take remedial action.
Should any of our sites become infected with malware, we simply reimage the web server and restore from the last DVD from our dev system.
It's clumsy and old-fashioned, and wouldn't work for a massive multinational site spanning multiple data centres, but for our small-scale ecommerce and SME sites it works like a charm.
When will people learn to use the RO flag on the partition they are using for their web documents?
The web boxen I'm responsible for are placed behind a load balancer and with code inserted into nginx's rc script that if /www/ is writable, it'll shut down immediately. I update the site by shutting down nginx, unmounting /www, running newfs against it, then extracting the tarball with the fresh contents into the new /www, remounting it as RO and starting nginx. In fact, every partition is mounted read-only by default, except /tmp and /var/log.
Its immune to defacement, malware, and even clumsy PFYs.
"I think you need a new name."
Wish I could change it...
I got the name several years back when we were doing massive amount of work on a 100,000+ physical machine datacenter. We were merging with another organization that was bringing 25,000 of their own boxes in. Plus there was all the OS / Application integration that had to take place as well. I ended up doing about 6 weeks of 15 hour days so I just went down to the local Ikea and bought a futon, a table, and a combination mini-fridge/microwave and set them up in a storage room attached to the DC. So for about a month I lived in the datacenter, the storage area was insulated enough that the temperature was just right and the servers' fans produced a comfortable level of white noise. Come to think of it, it was probably the best sleep I ever had...
I love that strategy. But it only works for static content. So, yes, please run your CDN that way, but any CMS-based part of the site will at the very least have the database as a mutable component. Usually there is a directory that holds uploads and temporary files as well. You can and should defend those, but that is a larger attack surface and therefore intrinsically more vulnerable.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
