This post is intended to serve as an example of something NOT to do when running a LUNA private server, or any other type of server for that matter. Making a similar mistake could end up costing you dearly, even more so if you were to make this mistake at your actual job.

Disclaimer: This article is intended solely for educational purposes and does not promote or condone any unauthorized or illegal access or use of software. The events within this post took place nearly two years ago now, in mid 2023, and involve a LUNA private server that no longer exists, as such despite the sensitive nature of the contents discussed here, there shouldn’t be any possibility of the details discussed here causing any damage to anyone who was involved. Any exploration that was done was with no ill-intent and with the intent to notify appropriate parties of any vulnerabilities found. If you have any concerns, feel free to reach out to the email in this site’s footer.

Investigating RA LUNA started out like any other of the dozen or so other private servers that pop up every year. Stumble onto a server online, download the client, virus scan the heck out of it, extract it, and dig in. Finding the AES keys and PAK file format with a combination of our trusty hex editor and IDA. Nothing too special, variants of variants of variants, just like most servers.

The next thing I do with each server is archive them, both the installer and all the available patch files, to enable later examining what changes they were making to things and when. This is usually fairly easy to do, by just looking for URLs in the patcher with a hex editor. When that doesn’t work, firing up WireShark and seeing what the patcher connects to will give you the answer just as quickly. The result is an FTP server address, as well as a rather insecure username and password of ftp://raluna:raluna123@103.254.197.118/Patch/. And this is where things start to get a bit messy…

While waiting for all the patches to download from their rather slow FTP server, I took notice of the fact that the patches were in a sub directory on said server, rather than the ftp server being configured with the patch folder as its root directory. Unusual, but not unheard of, perhaps they are hosting the client installer on this FTP server as well, from another directory? I press the button to go to the parent directory, and you will never guess what I found! No, not a puppy.

Screenshot showing the root of the server's hard drive

That’s right, they had an FTP server running, with the root directory being their entire C:\ drive, protected by nothing except a short password between everything on the server and the entire internet. Even worse, the FTP server was running under a privileged account, with read/write access to the entire file system. Uh Oh…

I did what any upstanding citizen would do of course, and started poking around everywhere else. Some DB backups, some DB change scripts for adjusting existing stored procedures, and their entire website, front and back end. All sorts of fun stuff. Naturally, having access to their LUNA server directory would make obtaining the username and password for the MSSQL database quite trivial, as the LUNA server binaries make no attempt to hide or obscure them. But that didn’t end up being necessary, as it turns out the database credentials were right there in plain text in the website configuration… Uh Oh… On top of that, they’re the same as the FTP server credentials! Worse still, this same config file also includes their PayPal API keys, not shown here for reasons I would hope are obvious.

DB_USERNAME=raluna
DB_PASSWORD=raluna123
DB_DATABASE0=LUNA_GAMEDB
DB_DATABASE1=LUNA_MEMBERDB

And this is where it gets even worse. Surely, despite not locking down the FTP server, their MSSQL server wouldn’t be accepting connections over the network? Do they have it behind a firewall, an IP whitelist, or even have TCP access disabled entirely? Nope, the MSSQL server is wide open to the internet as well, and the LUNA server’s user has full admin permissions as well. Even worse, they were storing usernames and passwords completely in plain text… Double Uh Oh… (Censored here for obvious reasons)

Screenshot showing the server's MSSQL database open to the table containing login details

This means unlimited database access, combined with essentially unlimited file system access, could have allowed all sorts of nefarious activity, deleting of files or even wiping of the database and deleting all the backups. Obviously I didn’t do either, because that would be rather rude. I had intended to let them know about the issues before anyone else could stumble onto them and cause havoc, but by the time I wrote up my findings and went looking for appropriate contact information, the server had shut down. Was that because someone else found the issue in the meantime and destroyed the server? Or did they just shut down in short order like every other private server tends to? Sadly, we may never know.

The moral of the story? Don’t expose your entire server drive via a poorly secured FTP server. Don’t leave your MSSQL server accessible over the network for anyone to try getting into. Don’t reuse passwords, or usernames for that matter, when critical infrastructure is concerned. And most importantly, don’t use raluna123 as your damn password. Don’t use 123 in any password. Ever.

See ya next time!