4

A linux VM with postgres 9.4 was hacked into. (Two processes taking 100% cpu, weird files in /tmp, did not reoccur after kill(s) and restart.) It was decided to install the system from scratch on a new machine (with postgres 9.6). The only data needed was in one of postgres databases. A pg_dump of the database was made after the attack.

Regardless of whether the data - the tables/rows/etc. - were modified during the attack: is it safe to restore the database in the new system?

P.S. I consider using pg_restore with the -O option which ignores the user permissions

user1713059
  • 145
  • 3
  • 4
    Depends on what you have in the database. If you're loading executable scripts from within the database (please don't do this), then you'll just move the problem across. If it's basic data, might be safer. If you're transferring the user tables, might be better to recreate with new passwords instead. You might want to perform some investigation into the data before importing to ensure that it's not been affected adversely. – Matthew Dec 01 '16 at 17:16
  • 2
    *Two processes taking 100% cpu, weird files in /tmp, did not reoccur after kill(s) and restart.* that's not really an indication of being "hacked"; it's an indication of two processes going haywire. Or maybe, these two processes just doing their job – you don't tell us what processes those were. "Strange files in /tmp" sounds like my dad deleting stuff from his hard drive and then wondering that things don't work anymore... – Marcus Müller Dec 01 '16 at 17:16
  • @MarcusMüller It is a very good indication especially when googling process names and the script contents leads you to a malware description. – user1713059 Dec 02 '16 at 11:12
  • You did not mention that. You just mentioned CPU usage and cite - "weird" files. Edit your question to include that info. Also,be wary of Google results. There's more than one guy trying to make people do something to make it easy to access their system by "explaining" how to get rid of "imaginary" malware. – Marcus Müller Dec 02 '16 at 11:14
  • If you could specify what malware the scripts suggested you were infected with, that would help us answer your question. Without that information we can only really say "you're probably fine, but not necessarily". – demize Dec 13 '16 at 21:13
  • @demize I wanted a general answer independent of the exact name/nature of the malicious script. Personally in such matters I assume the system was "totally compromised". The script could be a bait and some could have root access despite less harmful trojan being obviously visible. – user1713059 Dec 15 '16 at 12:07

1 Answers1

0

No. It is not secure to restore the data without taking steps to ensure that the data was not corrupted in ways that can lead to more security holes. It is also unlikely that upgrading from 9.4 to 9.6 is going to make any difference, and might actually complicate the restoration.

Many attacks involve the altering security information stored in the database. Even if you don't have such tables, it is just as common for attackers to embed code in what would normally be considered data and exploit security holes in the boundaries between code and data.

The correct way to proceed is to take a dump immediately prior to the attack and compare it with the last dump. This takes some skill, and you may have to assume a worst case scenario if you can't ascertain from audit and log files when the attack began.

Try to find ways to compare the before and after dumps, eliminating legitimate changes with each compare iteration. You will eventually find nothing, in which case you may have to take a risk of importing the data or restore to the last known good backup and live with the loss.

It would be better if you could use the compare and log and audit information to reverse engineer (best case) or determine the likely breadth of (less sure) the attack.

As unhappy as the truth is in this case. This IS like rocket science. You may need to ask more questions. Of course, much depends on how sure you need to be that you've cleaned all potential threats from the system, which depends on how critical the data and the user accounts are.

Douglas Daseeco
  • 614
  • 3
  • 17