Dayz.st server database hacked

dirtbikr59

New Member
That’s right ladies and gentleman. Our Dayz.st server was maliciously hacked. I am not just referring to in-game nukes, ammo boxes, and teleporting. The database tables were completed expunged and new tables were created containing juvenile statements such as, “F@#$ you guys again.” After the first hacking, passwords were changed, Day.st was contacted, and server was wiped fresh. The hackings reoccurred two additional times.

Day.st customer service (IRC chat) was very condescending and appeared the least bit helpful. Is there anything that can be done to prevent further database attacks? I attached a portion of the IRC chat with Dayz.st. I am an engineer, not a software/networking guy. Can someone offer a real solution?
 

Attachments

  • IRC Chat.txt
    8.2 KB · Views: 83
Can you use your own Database with DayZ.st?
If so, get your own MySQL Server and limit access to your Gameserver IP.
If not, search for a new gameserver provider, or the best, get your own dedicated server.
 
Can you use your own Database with DayZ.st?
If so, get your own MySQL Server and limit access to your Gameserver IP.
If not, search for a new gameserver provider, or the best, get your own dedicated server.

I do not believe you can use your own database with the limited server access provided by Dayz.st. After getting banned in IRC chat, our server was shut down by Day.st and our money was refunded. They believe the intrusion resides with the ARMA II programming structure and that server-side security is nonexistent. Honestly, good riddance to this relationship. Long ago, as a young employee, I learned that paying customers require a degree of respect and understanding. This was ill received.
 
My bet is they use the same database user for each server. For instance the host they use is '%' which means anyone from any ip can use it to connect to the database. If this is true, then a hacker could loadfile your hiveext.ini file to get the login info for the database and do whatever they want. I suggest you ask them to make sure that the database user can only connect from your server IP and no other IP.
 
My bet is they use the same database user for each server. For instance the host they use is '%' which means anyone from any ip can use it to connect to the database. If this is true, then a hacker could loadfile your hiveext.ini file to get the login info for the database and do whatever they want. I suggest you ask them to make sure that the database user can only connect from your server IP and no other IP.

They indeed stated that the hiveext.ini file was the origin of hacking. We inquired about providing them [Dayz.st] a client side IP address used for verification purposes. However, it was explained that this was not feasible. They also briefly mentioned utilizing a database IP address (TheLaughingMan’s reference), but smugly conveyed an associated loss of database functionality as well as restriction of external control panels. Thank you for the information.
 
You would lose no DB functionality if they created a user that could only be used by your server IP and put that in hiveext.ini. What it would mean is that you would not be able to connect via the same user from home, they or you would need to create a user for that.
 
We told you several times we could limit the database connection to your servers' IP only and you refused...

We told you our tools (phpmyadmin and the live map) would not work while this restriction was in place, which was unacceptable to you. PHPMyAdmin and the live map are both hosted on the same server - if we allowed access to the live map the attacker would have full access to your database through phpma. You would still be allowed to access your database from an external IP of your choosing directly, not sure if/why someone told you otherwise.

In any case we've been aware of the problem for awhile (I remember talking to TheLaughingMan about it months ago, and he was extremely helpful) but nobody had abused the exploit (which only exists because of security holes in arma2 itself...) and we had more important things to worry about - and as I also personally told you we will fix it permanently as soon as we get back from Los Angeles on the 26th, until then you can either accept our temporary fix or cancel and get a full refund. It looks like the latter has already happened.
 
what u mean to say nobody knew about the exploit until this post Ersan i have a very easy fix for ur issue although im sure u guys are on it i host my tools on a local web-server which is encrypted up to its balls on the admin panel on my site where the primary logon is that only basically link buttons to the local tools which require a secondary logon and are Dependent on the ip address logged at the primary logon to the website easy to implement
 
Ya we have a pretty easy fix, we're just going to make two users with different passwords - one internal that hiveext uses and that is limited to the server the customer is on, and one that is external used everywhere else. It's fairly easy to do, just hard to transition 3000 servers over to it without interrupting service. It's a high priority for when we get back on the 26th and should be done fairly quickly.
 
yeh man i dont envy u 3000 servers nightmare im happy with the 13 i host lol pays for my work Internets little shitty hackers do anything they can these days
 
We told you several times we could limit the database connection to your servers' IP only and you refused...
Dayz.st was emailed with our acceptance of this offer (Despite the perceived lack of administration functionality). In return, we received a reply once again exonerating Day.st of server-side security claims and which did not address the original email.

We told you our tools (phpmyadmin and the live map) would not work while this restriction was in place, which was unacceptable to you. PHPMyAdmin and the live map are both hosted on the same server - if we allowed access to the live map the attacker would have full access to your database through phpma. You would still be allowed to access your database from an external IP of your choosing directly, not sure if/why someone told you otherwise.
As you are well aware, moderating a Day-Z server is a full time job. The ability to extrapolate locations of players is essential to identifying suspects of teleporting and hacking. PHPmyadmin is an indispensible tool that if deprived of, leaves us lacking the competitive edge in advertising our server. Pbo file modification is archaic and tedious to add simple features such as buildings and their associated instances. Why amputate the arm to mend a broken bone?

In any case we've been aware of the problem for awhile (I remember talking to TheLaughingMan about it months ago, and he was extremely helpful) but nobody had abused the exploit (which only exists because of security holes in arma2 itself...) and we had more important things to worry about - and as I also personally told you we will fix it permanently as soon as we get back from Los Angeles on the 26th, until then you can either accept our temporary fix or cancel and get a full refund. It looks like the latter has already happened.
The phrase “Temporary fix” was not utilized by your representative. Not to mention the premature cancellation of our server without formal authorization from us. Some might say that server security is a high priority item.

Ya we have a pretty easy fix, we're just going to make two users with different passwords - one internal that hiveext uses and that is limited to the server the customer is on, and one that is external used everywhere else. It's fairly easy to do, just hard to transition 3000 servers over to it without interrupting service. It's a high priority for when we get back on the 26th and should be done fairly quickly.
Many server restarts reoccur daily. Why not implement this sooner? The community would accept an update that will prevent unrelenting server rollbacks and hackings.
 
Actually, every private server is vulnerable to this kind of attack.

This is due to a combination of remotely executing loadfile/preprocessfilelinenumbers and child:999. What TLM suggested will solve the loadfile issues but not the child:999 attack vector.

So don't be surprised when your sql database gets destroyed :oops:
 
If you are running your MySQL server and phpMyAdmin on the same machine as the gameserver, another way to reduce your risk here might be to prevent that dayz MySQL user from logging in remotely, or from phpMyAdmin.

You can set a whitelist of MySQL users who are allowed to login via phpMyAdmin by adding some lines in your config.inc.php, for example:
PHP:
$cfg['Servers'][$i]['AllowDeny']['order'] = 'explicit';
$cfg['Servers'][$i]['AllowDeny']['rules'] = array('allow user1 from all', 'allow user2 from all', 'allow user3 from all' );

That will allow only "user1", "user2", and "user3" to login via phpMyAdmin.

Basically, just restrict that dayz MySQL user as much as possible and create other accounts for manually interacting with the database.
 
Back
Top