Hard to tell, some databases that we don’t use often were not attacked. Those connected to web apps running as services on a Windows Server seemed to be the vulnerable ones…
First of all, databases should NEVER be directly accessible from the internet. They should only allow connections from a trusted connection like localhost (if you are using an API) or SSH or VPN.
Next, make sure you install security patches (both windows and Postgres) as soon as you can. It can be a pain, but it saves you even more later.
Just checked again the “attack pattern”, there is no apparent link between database use and the attack. But the weird thing is that some of them were left alone. For example, “baseplan” was cleared of its tables but “baseplanBK1”, “baseplanBK2” and “baseplanBK3” were still as I left them before Easter…
[quote=326689:@Roger St-Arneault]Glad to feel supported Thanks!
Just checked again the “attack pattern”, there is no apparent link between database use and the attack. But the weird thing is that some of them were left alone. For example, “baseplan” was cleared of its tables but “baseplanBK1”, “baseplanBK2” and “baseplanBK3” were still as I left them before Easter…[/quote]
If that’s the case, I would think that they breached Postgres itself and only managed to access that one database.
Windows Server? Open RDP-Port? Open DB Ports? No Reverse Proxy in-between? I wouldn’t run a Windows Server directly on the net! WIndows IIS has a plethora of .idx .idc etc. file extensions linked to classic ASP or .NET runtimes. They all shouldn’t (correction: must not) be enabled but they are in most cases.
The database server is a standalone machine. It only hosts Postgres, and it’s only accessible from localhost and the middleware server.
The software that accesses the database runs on the middleware server.
Access to middleware is restricted to the local network and VPN connections.
Access to the server is restricted via ssh.
Almost every SQL statement is run through prepared statements. (I mean the ones outside our ORM system.) The only exceptions (very rare) is where SQL injection is impossible (searching for an integer, for example.)
The Postgres accounts that can access the database are limited and have secure passwords.
Sensitive database is encrypted within the database and must be decrypted by the accessing software. The encryption key is nowhere on the SQL server.
Messages between middleware and the GUI are RSA-signed. The initial user password is RSA-encrypted.
I’m probably forgetting other steps we’ve taken, and until you know how it happened, we won’t know if any of this would have helped you.
Is using a VPN essential? I mean, if I want the app to be accessible for many users with minimal restrictions and considering that I’m often geographically far from my clients, managing access through VPN appears to necessitates too much technical support. Am I right?
Our software is accessible only to our employees so it’s a little different. As always, there is a balance, and tradeoff, between security and convenience.
You actually see no new foreign files on the server? Seems like 90% of the things we have seen over the years, basically winds up being a breach that allowed the hacked to write a new file. Which normally was a PHP while, that would then be able to include any of the config files, etc… that may have the database connection info.
Basically they install an entire little PHP Dashboard, or they refer to it as a PHP Shell…
Thanks Don, we’ll take a look a that for sure, we have a feeling that phpPGAdmin configuration files have been read and used to access the databases.
I took a look at the PostgreSQL Server logs and I note that the attack was targeting all databases but they were unable to “access” them because “cross-database references” were not implemented on these specific databases :
[quote]2017-04-18 04:05:18 EDT STATEMENT: DROP TABLE coursBK_2016_09_14.public.“cours_horaire_cours” CASCADE
2017-04-18 04:05:18 EDT ERROR: cross-database references are not implemented: “coursbk_2016_09_14.public.cours_horaire_cours”[/quote]