SQL Injection has been the bane of database administrators all over the world, with this being one of the main attack vectors used by hackers all over the world. I'd have hoped by 2010 we had stopped allowing most of these attacks, but this is still an issue in 2020. At least it's not the biggest security issue.

Recently there was a description of a hack against the Google cloud platform from some security researchers. They describe the process of working their way through an attack on the Google Cloud SQL platform. Specifically, they are going against a MySQL instance, though PosgreSQL and SQL Server are available as managed services.

In their work, the researchers find a way with SQL Injection to write to the file system, then they use this to start their malicious attack. Actually, it's not, but it could be if these weren't researchers. What I found really interesting was that as they were experimenting and trying different probes, someone at Google detected their work.

On the file system, the researchers found a file, greetings.txt, with a note from an SRE at Google. Google had detected the unauthorized hacking and left a note. Presumably Google engineers were also looking to patch the issue. Google did patch, and eventually were in touch with the researchers after the issue was patched. This is why the story got published, in the spirit of responsible disclosure.

It's hard to tell how Google detected their work, perhaps when a container crashed, which isn't what we want from a database. However, in this new world of persistent storage and containerized apps, maybe that is how our database platforms will run. In any case, the hacking efforts were detected.

Would you detect some hacking on your database? Do you have some equivalent of Advanced Threat Protection enabled? Any logging that might detect some unauthrorized use of xp_cmdshell or the equivalent? I bet most people don't, and wouldn't know about any attack until the attacker broke something or contacted them.

That's not ideal, and certainly, it's something that I would hope is addressed in future versions of SQL Server. I hope we get more security knobs, more auditing, and better controls. Of course, it's more likely that we'll just get advanced thread detection deployed locally through Azure Stack and at a $15/month cost. That's not a bad price for production, but for all of our other systems?

Maybe we should just ensure we don't have sensitive data outside production, or easy connectivity from non-production systems.