Attack Campaign Hits Thousands of MS-SQL Servers For Two Years (csoonline.com) 33
"In December, security researchers noticed an uptick in brute-force attacks against publicly exposed Microsoft SQL servers," reports CSOnline.
"It turns out the attacks go as far back as May 2018 and infect on average a couple thousand database servers every day with remote access Trojans and cryptominers."
Slashdot reader itwbennett writes: While the primary goal of the attack seems to be cryptocurrency mining, "what makes these database servers appealing for attackers apart from their valuable CPU power is the huge amount of data they hold," say researchers from Guardicore who investigated the attacks. The researchers also note that most machines (60%) stay infected only briefly, but "almost 20% of all breached servers remained infected for more than a week and even longer than two weeks," and 10% become reinfected...
[T]he attackers aggressively remove malware from competitors from targeted machines.
Many of the infected machines are located in America, India, South Korea, and Turkey, according to the article, which adds that the researchers traced the campaign back to China.
"The scans and attacks originate from Chinese IP addresses -- likely associated with infected and hijacked machines -- and the command-and-control servers are also hosted in China and use Chinese language for their web-based management interfaces."
"It turns out the attacks go as far back as May 2018 and infect on average a couple thousand database servers every day with remote access Trojans and cryptominers."
Slashdot reader itwbennett writes: While the primary goal of the attack seems to be cryptocurrency mining, "what makes these database servers appealing for attackers apart from their valuable CPU power is the huge amount of data they hold," say researchers from Guardicore who investigated the attacks. The researchers also note that most machines (60%) stay infected only briefly, but "almost 20% of all breached servers remained infected for more than a week and even longer than two weeks," and 10% become reinfected...
[T]he attackers aggressively remove malware from competitors from targeted machines.
Many of the infected machines are located in America, India, South Korea, and Turkey, according to the article, which adds that the researchers traced the campaign back to China.
"The scans and attacks originate from Chinese IP addresses -- likely associated with infected and hijacked machines -- and the command-and-control servers are also hosted in China and use Chinese language for their web-based management interfaces."
Re: (Score:2)
Re: Black hats removing malware is amusing. (Score:1)
I'n expert, but I suspect being shot and bleeding to death on the street can be an amusement killer ...
Database on the open internet (Score:3)
Databases (Score:3, Informative)
Here's the setup I've seen used that's pretty secure:
DMZ - Reverse proxy into the data center through a firewall. Only 443 traffic allowed, the proxy handles the redirect from 80, so nothing unencrypted is outside of the datacenter. Ideally the proxy just runs nginix or Apache, and ssh allowed only from the data center.
Data center: Separate App/Web and Database servers with an optional caching/static server. These sit in their own subnet firewalled off from the rest of the intranet - you have to log into a
Re: (Score:1)
And block all Chinese and Russian subnets at your firewall. Not guaranteed to stop anything but also makes attacks much less likely.
Re: (Score:2)
And block all Chinese and Russian subnets at your firewall. Not guaranteed to stop anything but also makes attacks much less likely.
An excellent idea. Unless your business does business in China or Russia. Then you have to go into whack-a-mole mode where you allow some networks/IP's in while blocking the rest.
Worst case would be a retail provider with consumers directly connecting to your webheads from their home.
Re: (Score:2)
And this is what the Chinese government want - they don't have to do the "great firewall of China" if they can make sites block China due to various kinds of attacks.
Yeah, I've got US IP blocks blocket. (Score:1)
On my site, the median IQ went up by 30 pointy.
Re: (Score:2)
Many attacks come from china and russia because there are lots of insecure servers there. That doesn't mean these countries are the ultimate source of the attack (ie where the hacker himself is located)... Machines in these countries are often highly insecure because piracy is rampant and installing updates can overwrite cracks and cause outages, so systems are never updated. Also many operating systems are primarily designed to run in english, which makes it harder for people in these countries to understa
Re: (Score:3)
Unless you design your jump server very well, it will become a prime target... Compromise that box and you get access to everything, plus copies of everyone's credentials..
Compromising the database is not miraculous, SQL injection vulnerabilities are fairly common and will allow them to compromise the database server even without compromising the appserver...
If the attacker is after your data then this is already enough, if they want to compromise the appserver there are potential routes from the database (
Re: (Score:3)
Unless you design your jump server very well, it will become a prime target... Compromise that box and you get access to everything, plus copies of everyone's credentials.
True, though securing one server is much easier than securing all the clients on the intranet. That's the idea. The internet facing data center is segregated from the rest of the internal network, minimizing attack vectors. Also, the credentials used for the jump server are different than the credentials used to log in to the backend servers, and users are only given permission to access the servers they need. These are all separate from the regular corporate credentials.
Compromising the database is not miraculous, SQL injection vulnerabilities are fairly common and will allow them to compromise the database server even without compromising the appserver...
Of course. The idea here is to minim
Re: (Score:2)
True, though securing one server is much easier than securing all the clients on the intranet. That's the idea. The internet facing data center is segregated from the rest of the internal network, minimizing attack vectors.
You still have to secure all the clients, if a client device is compromised and the user logs into the jump server from it then you now have credentials for the jump server and potentially for any system beyond depending on the user.
You also have to secure any systems used to manage the clients, such as a domain controller etc - as if you compromise that, you gain access to all the clients anyway.
Then you also have to secure the hypervisors if you're using virtual machines.
If your workstations are all stand
It all depends on the exposed API. (Score:1)
A web server (especially with server-side scripts) or e-mail server is also publicly exposed. But the interfaces are designed for it.
You could just as well design your SQL server and configuration that way.
It is not SQL per se, that is the problem. It is an API that was not designed for it.
E.g. if each client gets a fully separate isolated process with his own database storage directory, and the OS can enforce those rules, then it's not much different than e.g. a PHP web page, and all you need, is tell the
Re: (Score:2)
Re: (Score:1)
If this is only SQL Servers, it implies that the infection is through the DB server process itself.
The fact that the DB server process can install programs and alter configuration settings is really bad. Is Windows missing mandatory access controls similar to SELinux?
Then, as others have pointed out: the DB server should not be exposed to the Internet. It should be behind a firewall and access should be
Re:It all depends on the exposed API. (Score:4, Informative)
No indeedy - large numbers of people realise that the problem is Microsoft SQL.
Sane people do not use Microsoft products. There are other SQL products on the market (although you might want to avoid Oracle) - and they work better too.
Re: (Score:2)
Sane people do not use Microsoft products.
Sane people judge each product on the merits.
Re: (Score:2)
Sane people don't expect a repeat offender to stop offending without being forced.
Re: (Score:2)
It is not SQL per se, that is the problem. It is an API that was not designed for it.
It's a stream protocol not an API.
E.g. if each client gets a fully separate isolated process with his own database storage directory
You can install as many instances of SQL Server as you want on a single system all during initial installation where each runs as a separate unprivileged user.
Don't expect MS to ever get that right though. :)
I don't understand how poor configuration and guessable passwords are the vendors fault. You have to take explicit steps to enable TCP protocol access to SQL server database AND reconfigure the local firewall to allow it thru.
These exact same brute force attacks have been going on for decades on SSH enabled Linux sys
Re: Database on the open internet (Score:2)
Code Red [wikipedia.org]: why on earth does anybody put their DB server directly on the internet?
Re: (Score:3)
Never put your database (any database) on the open internet.
Anyone smart enough to know that isn't going to be using MS-SQL in the first place.
Re: (Score:2)
Anyone smart enough to know that isn't going to be using MS-SQL in the first place.
SQLite FTW.
Re: (Score:2)
Never put your database (any database) on the open internet. You can be 100% invulnerable to these kinds of attacks with a simple firewall.
At least until someone clicks that email attachment from "HR".
The wonderful thing about computers (Score:1)
Why ... are they publicly exposed ...? (Score:1)
Oh wait, you said *MS*-SQL. ... Yeah, competency-wise, that sounds about right.
Two problems (Score:1)