Jump to content
Buckit

Feature request: database content protection

Recommended Posts

Hiya,

 

I was poking around the MSSQL database backend for PasswordState and noticed a few fields that are not stored with encryption, while they could be (ab)used to gain access to sensitive data. Or to wipe tracks should an actor gain access to the database and/or PasswordState. Obviously it's imperative that the database backend is secured to the teeth, but it's also not unlikely that the designated DBAs do not have admin-rights in PasswordState. Having access to the database may thus lead to an escalation of privileges.

 

Most notably:

  • Valid usernames may be harvested from the database, but I realize there's not much we can do about that.
  • The dbo.SecurityAdmins and dbo.SecurityGroupsMembership tables are unencrypted. Could it be that the GUID field plays a role in checksumming the data, to ensure that nobody is adding access rights to their own account?
  • Valid usernames in dbo.PrivilegedAccounts are not encrypted, giving insight into juicy targets for other platforms.
  • Is there some method of auditing the dbo.Auditing table? What prevents a DBA from diking out a bunch of incriminating evidence?

 

Anywho... just some thoughts, while at the office in those lost days between one holiday and the next :D

Share this post


Link to post
Share on other sites

Hi Buckit.

 

Thanks for your request. When we encrypt fields in the database, it does prevent you from searching for them in the UI - so we need to be careful about which ones we encrypt.

 

You can also send all Auditing data to a Syslog server, and not give your DBA's access to this.

 

And if you want, you can use SQL Server encryption over the top of ours - we've never tested it ourselves, but believe it should be possible.

Regards

Click Studios

Share this post


Link to post
Share on other sites

You make some great points, thank you!

 

I have already resolved to using an external Syslog box for the audit logging; that should suffice in that regard. And I hadn't thought of the SQL Server encryption yet, I'll thrown that in with the team and see what they think. Thank you!

Share this post


Link to post
Share on other sites
3 hours ago, Buckit said:

You make some great points, thank you!

 

I have already resolved to using an external Syslog box for the audit logging; that should suffice in that regard. And I hadn't thought of the SQL Server encryption yet, I'll thrown that in with the team and see what they think. Thank you!

2

Hi Buckit,

 

do you process the audit logs in the external box? Or you just simply offload all the logs and do not care?

Share this post


Link to post
Share on other sites

I will jump ahead and drop this one 

I have been looking around into this topic for some time already. In our organization, we use ELK stack to a quite a significant extent. I do have a free version of Splunk, but I haven't tried to point the logs there. The problem of using syslog protocol is that the data is not structured therefore difficult to write filters for it. Best option, for now, is to use something like that https://qbox.io/blog/migrating-mysql-data-into-elasticsearch-using-logstash

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

Thanks  for the heads-up Azkabahn! That's a good thing to keep in mind. Being a Unix-person I'm used to dealing with Syslog, so I hadn't expected difficulties with importing such a stream. I know that Splunk has proper parsers for the format, but thanks to you I realize that not all solutions are created equal ;)

Share this post


Link to post
Share on other sites

Well in my case, we have done several integration with continuous deployment tools and it generates a huge amount of logs. PasswordState doesn't perform well when it has millions of records in the audit table. On the other hand, we have requirements in place to keep the logs of all actions being done. With ELK/Splunk you could very easily build dashboards for various metrics etc. not to mention use it for logs offloading :)

Share this post


Link to post
Share on other sites

Hi Guys,

 

Yes, we try and recommend keeping the auditing records to no more than a million rows if possible. There are certain features in Passwordstate that needs to interrogate all auditing data, and if you have many millions or rows like Azkabahn does, then it can cause performance issues. We're hesitant to remove these features, as there are not many customers who have this much auditing data.

Regards

Click Studios

Share this post


Link to post
Share on other sites

×