Solved Server hacked 'To recover your lost Database.."

I am running FreeBSD 11.3 and being using SSHGuard.. Today I had my MySQL hacked with a bitcoin ransom.

Obviously I have to rebuild MySQL change my passwords and fine a better solution to brute attacks the SSHGuard.

I would appreciate any suggestion for a) scanning for trojans/worms they left behind. and b) better options to SSHGuard.
 
a) wipe the whole system and start over. Forget about scanning, nothing can be trusted on that system any more.

b) sshguard doesn't look at MySQL logins, at all. Simple solution, don't have MySQL listen on your external address, bind it to a local address or 127.0.0.1. Do remote management over an SSH tunnel.

c) double check your websites, specifically look for SQL injection issues.
 
If you're going to have MySQL listen on the internet port, at least configure MySQL to reject IPs that aren't your machines (take asterisks out of your usernames). Barring that, use a simple firewall rule to do this.
 
If you really need connecting MySQL from other machines and they are in different locations you should use some VPN solution, no direct connections via the Internet.
 
It's obvious you've been to Dover for deliverance of an SQL injection. (I know bad multiple references but I couldn't resist.)

SSH and VPN and don't use default ports ingress from the Internet. I don't run SSH on port 22 ingress from the Internet. They're always going to be scanning the commonly used ports. If someone wants to try an SSH brute force attack on me they have to find out what port I'm using. You can easily change what ingress SSH ports you use on a given day if necessary and make it just as confusing as Fizbin to any cyber terrorist. I don't bother to enable telnet as someone might be snooping my WiFi. I expect people trying to crack my WiFi encryption especially with DEF CON being in my backyard every summer.

SirDice is right. You need to nuke and start over from scratch. Restore your database from a known good backup prior to the security breach if that's an option. SQL injections are not uncommon. Never expose SQL to the Internet. Use SSH with a different ingress port than 22 from the Internet or VPN. Anything exposed to the Internet to remote sites should be a secure protocol, period.

You should have a redundant security plan and a DMZ; layered security. This would also be a good time to upgrade to 12.1 if you were looking to upgrade unless you need something that's being deprecated in 12.x and removed.

You've been targeted once. They will be back and test what you've done.
 
I had this attack like a month ago. I show some more info.
I had my personal website (just for training) on VPS (RedHat/Amazon Web Services).
I had there PostgreSQL DB, and access to it from website via POST/GET methods by Python/psycopg2 script, Apache and thats all. When backend got POST/GET request it logged as db user and perform INSERT/SELECT. My database that contained ~8 numbers (and was called "numbers") has been deleted and they replaced it with:
atak.png

xd

In logs I can see that attacking bot was looking for lot of standard weakpoints, here aiming f.e. myphpadmin and wordpress(this is just few of them, I didn't have any PHP on site so these are blind tries):
Code:
"GET /?XDEBUG_SESSION_START=phpstorm HTTP/1.1" 200 823 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
5.101.0.209
"GET /?a=fetch&content=<php>die(@md5(HelloThinkCMF))</php> HTTP/1.1" 200 823 "-" "Mozilla/5.0 (...) Chrome/78.0.3904.108 Safari/537.36"
5.101.0.209 - -
"GET /index.php?s=/Index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP HTTP/1.1" 404 207 "-" "Mozilla/5.0 (...) Chrome/78.0.3904.108 Safari/537.36"
...
"GET //phpMyAdmin/scripts/setup.php HTTP/1.1" 404 226 "-" "-"
"GET //phpmyadmin/scripts/setup.php HTTP/1.1" 404 226 "-" "-"
"GET //pma/scripts/setup.php HTTP/1.1" 404 219 "-" "-"
"GET //myadmin/scripts/setup.php HTTP/1.1" 404 223 "-" "-"
"GET //MyAdmin/scripts/setup.php HTTP/1.1" 404 223 "-" "-"
...
"GET /wordpress/ HTTP/1.1" 404 208 "-"
...

Finally bot found GET/POST methods and performed SQL Injection in my case :
Code:
CREATE TABLE cmd_exec(cmd_output text);
    COPY cmd_exec FROM PROGRAM 'cat /proc/cpuinfo' encoding 'gbk'; - hmmm?
    SELECT * FROM cmd_exec;

CREATE TABLE cmd_exec(cmd_output text);
    COPY cmd_exec FROM PROGRAM 'ps auxw|grep -v grep|grep -v nginx|sort -rn -k3|awk {if($3>50.0) print $2}|xargs kill -9' encoding 'gbk';
             - Checks for open processes take more than 50% of cpu and kills them.
    SELECT * FROM cmd_exec;


CREATE TABLE cmd_exec(cmd_output text);
    COPY cmd_exec FROM PROGRAM 'killall postgresq1' encoding 'gbk';
    SELECT * FROM cmd_exec;

STATEMENT:  SELECT pg_terminate_backend(pg_stat_activity.procpid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'please_read_me_xmg' AND procpid <> pg_backend_pid();
             - Here bot created db with "WARNING"

Also tried to log as root:

DETAIL:  Role "root" does not exist.

To prevent such attack one needs to use database users and priviliges properly, always pass arguments to database driver, hide (and hash?) all source code and doble check request in script. Propably a lot more, but Im noob. Still should be enough against blind bot.
Whole attack lasted for 5 days according to logs. If I was watching them, I could react.
a) wipe the whole system and start over.
After that attack I have changed my server provider and OS to FreeBSD.

Never expose SQL to the Internet.
How should I connect (add/remove items f.e.) to database from website then in short words? Maybe you know some good texts about it ?

Cheers
 
Sevendogsbsd pretty much covered it plus you have this site. Put your database backend on your internal network and audit audit audit log files. When I have servers exposed externally to the Internet, I regularly audit everything in my /var/log directory on all servers looking for security breaches and anomalies both internal and external. This is something you need to do daily. With practice you get very good at skimming log files. I acquired the ability of skimming netflow text output from Cisco devices from my former employer deworming remote sites and doing snap shot troubleshooting.

Hackers are constantly evolving and you have to constantly watch your server farm or garden for pestilence. I'd put it on a secure VLAN behind your DMZ. Depending on your network design and implementation, you may want to make all connections to your SQL server(s) use ssh tunneling or VPN. Once someone breaches an external server, there's no telling what they can do.

On a certain social media site, we were having fun with our own profiles we can edit using SQLi attacks with a web authoring plug in creating our own role title in our profile. If I had the ability to do it here, I'd make mine here as "Core Curmudgeon" instead of "Member." Granted some people here will probably say I can be a big member. 😉

It didn't harm the site as it was harmless fun we were having among ourselves. The site admin eventually fixed the SQLi vulnerability.
 
I had this attack like a month ago. I show some more info.

Wow, thanks. This is enlightening indeed! :)

Code:
"GET //phpMyAdmin/scripts/setup.php HTTP/1.1" 404 226 "-" "-"
"GET //phpmyadmin/scripts/setup.php HTTP/1.1" 404 226 "-" "-"
"GET //pma/scripts/setup.php HTTP/1.1" 404 219 "-" "-"
"GET //myadmin/scripts/setup.php HTTP/1.1" 404 223 "-" "-"
"GET //MyAdmin/scripts/setup.php HTTP/1.1" 404 223 "-" "-"

So that's what this crap is about! I have tons of these on my webserver, for years. After it got me bored (that didn't take long) I decided to just ignore the logs of the webserver entirely.

I didn't really understand the scheme: my appserver isn't on the webserver (and my DB server isn't on the appserver),
and there are no passwords to hack, because no passwords do exist. (Passwords are not needed, because we have a Kerberos in the base system.)

Finally bot found GET/POST methods and performed SQL Injection in my case :
Code:
CREATE TABLE cmd_exec(cmd_output text);
    COPY cmd_exec FROM PROGRAM 'cat /proc/cpuinfo' encoding 'gbk'; - hmmm?
    SELECT * FROM cmd_exec;

Eh, that would expect that the web app user is allowed to do such things (not to mention the "cmd_exec" - that's not SQL as I know of it.)

COPY cmd_exec FROM PROGRAM 'ps auxw|grep -v grep|grep -v nginx|sort -rn -k3|awk {if($3>50.0) print $2}|xargs kill -9' encoding 'gbk';
- Checks for open processes take more than 50% of cpu and kills them.
That would require that the database backend engine has system superuser priviledges.


Now, the important thing: with this data we can "reverse engineer" the logic: as we know, some really major shops fell victim of such bitcoin ransom stuff (I think I remember a major nationwide public transport). So from here we can conclude what kind of server installations these folks seem to afford, for my good money. :(
 
you can encode the data to base64 and insert it to database, this is really secure method to prevent code injection for web server. and you could use ajax to decode this data to display it.
but when you need search something, you need a index tool to make database keyword index.
 
I probably should have added this to my previous comment. The gist is there. The best CERT or security officer is someone who looks for a problem before it happens as much as possible. Be proactive. Have a disaster recovery plan for if that breach ever happens.
 
you can encode the data to base64 and insert it to database, this is really secure method to prevent code injection for web server. and you could use ajax to decode this data to display it.
but when you need search something, you need a index tool to make database keyword index.

Agree with msplsh - this is a bad idea. Base64 is easily decoded and is not encryption or hashing at all. Very unsecure.
 
Agree with msplsh - this is a bad idea. Base64 is easily decoded and is not encryption or hashing at all. Very unsecure.

So then, what would be a good advice? As far as I see it (but I'm not a pro) there are two risks.
  • code could be inserted which is not payload but commands which the database will then execute,​
  • code could be inserted which then, when redisplayed, is some commands a browser will execute.​
and two problems:
  • often you don't write it all from scratch, but use some toolkit, so you're dependent on how well that toolkit does the protection schemes,​
  • while the database function set is rather conservative, the things a browser can do change often and significantly, so it is almost impossible to keep track on what there is and how it might be possible to abuse it.​
The usual advice to "upgrade often" just implies that the community processes of identifying and fixing possible problems would work well. But, do they?
 
  • Put all administrative tools behind a Basic or Digest authentication prompt in the web server
  • Use parameterized SQL queries
  • Learn how to sanitize inputs/outputs and how XSS exploits work (Read OWASP documents)
 
So then, what would be a good advice? As far as I see it (but I'm not a pro) there are two risks.

This is SQL injection and msplsh's advice is good to prevent this.
code could be inserted which is not payload but commands which the database will then execute

This is stored cross-site scripting and msplsh's suggestions are good to prevent this.
code could be inserted which then, when redisplayed, is some commands a browser will execute.

If you want to encrypt data contained in a database, you certainly can, but keep in mind that in order for the data to be used, it has to be decrypted on the fly. Depending on how this is done, the encryption itself may be pointless because the system has to return unencrypted data in order for users to read it.

I am not a developer but I believe there are modern web application frameworks out there that can sanitize data and help prevent these attacks. Here is a good resource on this: XSS prevention

Also, there are web server security headers you can set to help prevent XSS attacks: Web server security headers.
 
Back
Top