I received an email from a hacker stating that they obtained the databases for a site I manage and are demanding bitcoin. It seems like they actually did get the DB data because they provided a sample of the data and it does appear to match up.
The website uses PHP (an older version) and MySQL. The code is a bit old for this site, but, I’m not really sure how they were able to get the database contents via the website, which appears is how they did it. I don’t believe there was a breach of the actual server. I got a notification of a signup to this website a few weeks ago that seemed suspicious and when I looked up the IP number for that signup in the server logs I see lots of entries like this:
[Sat Apr 23 11:19:33.527742 2022] [cgi:error] [pid 9898] [client xx.xx.xx.xx a:45818] script not found or unable to stat: /var/www/cgi-bin/htimage.exe [Sat Apr 23 11:19:33.556184 2022] [cgi:error] [pid 11858] [client xx.xx.xx.xx a:45700] script not found or unable to stat: /var/www/cgi-bin/htmlscript [Sat Apr 23 11:19:33.559824 2022] [cgi:error] [pid 11784] [client xx.xx.xx.xx a:44400] script not found or unable to stat: /var/www/cgi-bin/imagemap.exe [Sat Apr 23 11:19:33.571326 2022] [cgi:error] [pid 9934] [client xx.xx.xx.xx a:45712] script not found or unable to stat: /var/www/cgi-bin/index.html [Sat Apr 23 11:19:33.597727 2022] [cgi:error] [pid 10490] [client xx.xx.xx.xx a:46344] script not found or unable to stat: /var/www/cgi-bin/login [Sat Apr 23 11:19:33.689271 2022] [cgi:error] [pid 3341] [client xx.xx.xx.xx a:45634] script not found or unable to stat: /var/www/cgi-bin/login.cgi [Sat Apr 23 11:19:33.858026 2022] [:error] [pid 10644] [client xx.xx.xx.xx a:46414] script '/var/www/cgi-bin/login.php' not found or unable to stat [Sat Apr 23 11:19:33.858506 2022] [cgi:error] [pid 11691] [client xx.xx.xx.xx a:45822] script not found or unable to stat: /var/www/cgi-bin/printenv.pl [Sat Apr 23 11:19:33.865787 2022] [cgi:error] [pid 9310] [client xx.xx.xx.xx a:45476] script not found or unable to stat: /var/www/cgi-bin/test-cgi [Sat Apr 23 11:19:33.866803 2022] [cgi:error] [pid 9898] [client xx.xx.xx.xx a:45818] script not found or unable to stat: /var/www/cgi-bin/php.ini [Sat Apr 23 11:19:33.868400 2022] [cgi:error] [pid 10529] [client xx.xx.xx.xx a:45442] script not found or unable to stat: /var/www/cgi-bin/test.cgi
I removed the actual IP just for security purposes (it appears to be an Amazon data center IP when I look that IP up). There are thousands of lines like above probing all kinds of directors and files on the webs server, so, I think they must have found some vulnerability in a PHP script that let them somehow obtain the databases.
If anyone can tell me how this would be possible, that would help me find the vulnerability so I can try to fix it. Right now, I have no idea how they did this via a web browser. Are there any tests I can do to check this kind of vulnerability and see how they did it?
Let me know if you need any other info, thanks in advance for any advice.
Sql injection was probably used with an existing SELECT query to cause the contents of any available database table to be output onto the web page.
You would need to post actual code to get any specific help with it.
I’m not sure what code to post, as I don’t know which code has the vulnerability.
How would they be able to run a SELECT command for MySQL from the URL? I’d like to try this myself to see if it works so I can try to pinpoint where they did this.
Is there any way to prevent SQL injections? The code is using older commands such as myql_query(). Some of the code that has been upgraded in the past year is using the new PDO query stuff. If there’s a way I can try an actual injection command on my site to see how it reacts, that might help me figure out where the vulnerability is.
It would be naive to assume it was done through a web browser. There are numerous ways to hack a server or an application. Without someone doing an actual pen test you cant be sure where all the vulnerabilities are. Having outdated versions of software definitely does not help.
It could be as simple as the same credentials were used on some other site that was hacked and they simply just logged in. There are just too many possibilities without seeing the code or the server.
SQL injection involves including sql query syntax in an external data value that you put into an sql query statement, that satisfies (escapes from) your sql query statement and adds its own sql query syntax, usually a UNION SELECT … query to get any data it wants from any table(s).
Use a (true) prepared query when supplying external, unknown, dynamic values to a query when it gets executed. Note: PDO has emulated prepared queries, that should be turned off, that if you haven’t set the character set, when you make the connection, to match your database table(s), is still open to sql injection.
As stated, there are many attack vectors these days.
Maybe a good place to start would be looking at the database calls, with attention to how variables are put into queries.
I have taken a look. There are numerous vulnerabilities including XSS and Blind SQL Injection vectors. I wont dare say what Php version it is running. Waiting on code for review.
There could be numerous things that could attribute to this outcome. Since you using a login system, we can break that down first. So what I tend to see from a lot of folks on here and everywhere when they write a PHP login system is that they don’t really care about security. Not talking about security in the sense of SQL injections and what not, but something like brute force. If an attacker knows there’s an entry point, they will try every single possible way to get down to your database.
This means if you’re outputting database errors to the screen, well, that’s the culprit. Other things like providing a very weak hashed password could also be the problem. Using things like MD5 and SHA1 to hash passwords are forbidden in a login system and this is why. Especially if the passwords are just stored as plain text. Other things like not enforcing stronger passwords or even the use of passphrases could be it as well. Lastly, there is no other top level security layer such as multi-factor authentication put in place. This would have deterred the attacker. The attacker does not need to know your database username and password. If there is a weak point in your script and they see an error being outputted to the screen such as directory paths or what not, they can easily get into your ACTUAL filesystem on your website and have gotten the database information that way.
There could be a ton of other possibilities as to how it got to this point. Ultimately, I hope this is a good lesson to start using updated code.
Sorry for dragging this off-topic, but this is something I’ve wondered about. I can see how inserting additional terms into the query might allow an unscrupulous user to delete or drop a table, but how would they be able to display anything? How would me (well, not me) adding an extra SELECT clause to an existing query alternate what the code for the page displays?
As I type this I wonder whether you’re referring to something like a SELECT CONCAT (xx, yy) to stick other values into the one that actually does get displayed.
(No, I don’t have any live sites based on PHP that require any kind of security).
^ This is used as part of what I have seen.
If you have a main SELECT x, … query that you are going to loop over to display the result of, any row(s) that an injected UNION SELECT query adds to the result set will also get looped over and displayed. By using CONCAT, for the columns you want, in the first SELECTed position, the concatenated column result will get displayed the same as the x column values from the main query.
It depends on many variables, including how the code display the data pulled from the database.
In most cases, you will not be able to see additional data by SQL injection, but you can for example get access to information tied to other accounts on the system or update other accounts on the system. Basically, using the features the website has to display/update the data, only that you apply the change to other accounts than the one you are logged in with.
In the cases where someone gets access to the content of the database, it is normally due to being able to inject PHP code into your files that allow them to do anything the PHP/Webserver user is allowed to do on the server. Or by breaching the server itself, and getting access that way.