Jump to content

Passwordstate Self Destruct Message


Recommended Posts

Hello,

 

Is there any chance we can get the Self destruct Message function like the "old" situation? (without the app server part).

In the context of security is the "new" situation not secure for us.

 

We had everything configured so Passwordstate can be reached internal only. And the Self Destruct Message site as a DMZ so external systems are able to reach the Self Destruct Message site only and NOT Passwordstate which is for internal use only.

 

This is not possible in the new siuation which requires constant connection to Passwordstate and we are not happy about it.

 

Can you provide us a solution, please?

 

 

Link to comment
Share on other sites

Hello PBA,

 

Unfortunately we can no longer provide this - for various reasons, customers had many issues getting the old installation working i.e. load balancers, reverse proxies, etc, so we had to change the architecture for this feature.

You can encrypt settings in your web.config file if you like, and this is documented in the installation guide - https://www.clickstudios.com.au/downloads/version9/Passwordstate_App_Server_Install_And_Administration_Guide.pdf

Regards

Click Studios

Link to comment
Share on other sites

We were just about to migrate to a separate self destruct portal and VPN only access to the passwords via mobile. I just upgraded to V9 in prep and was reading about the changes and see that is apparently no longer possible in V9. What a huge disappointment. So now if we want to use self destruct, and if we want mobile access, we have no choices. Open it up to the internet and don't use a VPN. I sure would like to understand the rationale behind greatly limiting our ability to secure this sensitive data. This forces us to simply trust that Click Studios won't have any vulnerabilities in their code. 

 

Not sure I even understand the point of a self destruct portal anymore since it also handles mobile access to Passwordstate.

Link to comment
Share on other sites

Hi Rob,

You can still place your Passwordstate App Server behind your VPN - have you found some documentation which states otherwise? You can also have multiple installs of the App Server if you like i.e. one for mobile access, and one for Self Destruct.

And you do not need to use the Mobile App functionality that comes with the App Server. By default, you cannot use it unless you configure some System Settings to enable it. And you can also prevent all users from using it on the screen Administration -> Feature Access -> Mobile.

 

With our installation guide, it also recommends encrypting settings in your web.config file - for improved security.

 

During the beta phase of version 9, we partnered with an external security penetration testing company, and they spent two weeks thoroughly testing the new App Server, and native Apps, and found no issues at all. In fact, we had to remove two layers of security from the Apps, just so they could do any testing.

So we can assure you, that we have taken every care to ensure the new App Server is secure.

Regards

Click Studios

Link to comment
Share on other sites

So I can have one app server that only works for mobile access, and nothing else. And then I can have another one for self destruct and nothing else? The self destruct portal will be unable to be exploited and then used to access passwords? 

 

My goal is to have self destruct for clients without a VPN, and then no ability to access passwords without a VPN. Meaning that self destruct portal simply cannot be used in any way, even if breached, to attack the passwordstate server. That's still possible?

 

The post above leads me to believe it's not possible.

 

To be clear, we want mobile access, but we want to require a VPN for it, and we want the self destruct portal to have no ability to access passwords that aren't currently on it waiting to self destruct.

Link to comment
Share on other sites

Hi Rob,

 

Yes, you can have separate installs for this purpose.

The only people who can access the Mobile portion of it, is your internal staff who can scan the QR Code on the mobile phones, from the Preferences screen. And this is linked back to the URL you specify for the App Server, on the system settings screen.

 

As mentioned, we have done everything possible to make the new App Server as secure as possible. Ultimatley it will be up to you to perform your own security assessment, if you need this reassurance.

Regards

Click Studios

Link to comment
Share on other sites

I understand that I can enable or disable mobile access. I am still concerned that the app server is not isolated like the previous self destruct portal and if compromised, has full access to passwordstate. Specifying different URLs in the config doesn't actually disable the app servers ability to access password state if it's compromised via a vulnerability.  

 

Our requirements:

1. An App Server for Self Destruct open to the internet. This server should have zero ability to access passwordstate, even if compromised and an attacker has bypassed authentication in some way. We would like to block this servers ability to even initiate connections to passwordstate at the network level.

2. A Mobile Access App server behind a VPN that does allow access to passwords via passwordstate

 

Can you provide guidance on how we achieve #1 so that if an attacker somehow bypassed auth and fully compromised the app server for self destruct that they wouldn't have access to passwords in passwordstate? Can the App Server still work for Self Destruct if it's firewalled off from the passwordstate server like was previously possible with self destruct portal?

Link to comment
Share on other sites

Hi Rob,

 

Unfortunately what you are asking in Number 1 is no longer possible in version 9 - the App Server needs to communicate to your Passwordstate database - for which, the contents are encrypted, and can only be decrypted via our assemblies.

As you are an MSP, is there an option to limit access to your Self Destruct URL to your customer's firewalls i.e. IP Address restrictions - just a suggestion.

Regards

Click Studios

Link to comment
Share on other sites

That would be far too difficult to use an IP based ACL on the self destruct portal for us. MSPs are getting hit left and right. We have to do all we can to plan for a breach via a compromised system and one with open inbound access from the internet is certainly a candidate to be compromised. I'll have to carefully consider our options here since there is no way to disallow communication from the self destruct portal.

Link to comment
Share on other sites

Hello,

 

Sorry for the delayed reaction.

 

Thank you Rob, this is exactly what I mean.

 

It was one of the major reasons we are using Passwordstate.

Maybe you guys can consider bringing the function back, I think many of your customers are thinking the same way.

 

 

Link to comment
Share on other sites

I just completed our migration to V9 with an App Server for self destruct and mobile access. Passwordstate itself is now blocked from offsite access. I guess we are going to setup a 2nd Passwordstate server and move our own critical infrastructure creds to this 2nd one and it will not have mobile access, self destruct, or external access. It seems we aren't allowed however to setup a 2nd instance per the licensing so we will be limited to 5 free user accounts on this second deployment.

 

But in the end, the risk was too great for us to have both client passes, as well as our own infrastructure passes for our private cloud services in the same basket. I wish Passwordstate would allow us to deploy a second instance for the same users we already pay for. 

Link to comment
Share on other sites

Hey guys, I would just like to echo the OP; it seems like a serious security regression.

 

Are you guys willing to provide details of the pentesting that was done along with who did it? For a security product I think that'd be pretty important.

 

Also, is there any capability to use a read-only SQL account from Self Destruct to the passwordstate database and\or limit permissions in SQL in any other way?

Link to comment
Share on other sites

Hello Moiz,

 

We are under an NDA for the penetration tests we arrange, meaning we are unable to share results of this.

 

In theory, you could use an account which only has read access to the database, but there are a couple of tables which would require separate 'UPDATE' permissions to those tables only i.e. SelfDestruct and QueuedEmail. Is that acceptable, because in theory the other tables could still be read? We'll try and have a look to see if access can be removed from all other tables, but it might take us some time to look into that.

 

We have spent months re-developing this feature, and we do not have any plans to revert back to the old method. Ultimately you will need to decide whether you wish to use this feature or not.

Regards

Click Studios

Link to comment
Share on other sites

We are also very upset about this change.
This function (and especially the way it works) was one of the main reasons why we chose this product.
In our data center we are bound to strict IT security compliances. So if that is the final statement from clickstudios, we are forced to look at other products, too bad.
Fortunately, this change came before we were buying additional instances for our customers.
Amazing that nobody from clickstudios sees that the new architecture building a bridge between the Internet and the Passwordstate database and that these are for some customers a security issue.

Link to comment
Share on other sites

On 3/16/2021 at 4:55 PM, support said:

In theory, you could use an account which only has read access to the database, but there are a couple of tables which would require separate 'UPDATE' permissions to those tables only i.e. SelfDestruct and QueuedEmail. Is that acceptable, because in theory the other tables could still be read? We'll try and have a look to see if access can be removed from all other tables, but it might take us some time to look into that.

I think this would be reasonable if we can lock down access only to the specific tables required.

Link to comment
Share on other sites

Hi Guys,

 

We appreciate the feedback. The Pen Testing company do not believe this architecture is insecure, but if there is enough interest, we can consider other options.

 

So we can take this feedback to management, can you please outline why you believe this is a security regression? Is your concern you may have an elevated administrative breach on your web server where this is being hosted?

Regards

Click Studios

Link to comment
Share on other sites

Honestly, the main reason is that we now have to secure access to the SQL database server. If the Passwordstate database is co-located with other databases (typically to make maximum use of Microsoft's expensive per-core SQL licensing) this now expands the potential attack surface of the environment to "everything that uses SQL" instead of just Passwordstate.

 

Also ideally you want one-way communication from PasswordState web server (trusted) to Self-Destruct server (untrusted) only. I get that this still means there's an SQLite database sitting on the Self-Destruct server in some form (ideally only containing the SelfDestruct and QueuedEmail tables), but at least a compromise means 0 access to the rest of the PasswordState database, as well as potentially other databases.

 

Just my $0.02.

Link to comment
Share on other sites

What if you never had to expose any portion of your PasswordState infrastructure directly?

 

Any layer 7 load balancer should be able to add a layer of security here (I'd suggest the open source version of HAProxy if you don't have an existing load balancer for your external network).

 

You can also use URL rewrite rules in IIS (look near the bottom of the MS page below) to restrict or allow specific IP addresses from accessing portions of the Passwordstate instance (the selfdestruct portal is self contained wholly to /selfdestruct/*).

 

You can get pretty creative and only allow specific vlans to access the /selfdestruct/* portion of the site, while letting your IT vlan hit the entire site. Useful if you have sections of your network that you'd like to use the selfdestruct portal with, but don't want those same devices accessing the whole instance.

 

https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/creating-rewrite-rules-for-the-url-rewrite-module

 

Maybe Passwordstate support could publish details on the exact tables in the database that the App Server needs read/write access to. You could use a separate SQL user that had explicit read/write permissions for this functionality only as an additional layer of security.

 

IMHO, there are ways you can architect and securely design the service that make it no more risky than having your VPN endpoints exposed to the internet.

 

image.thumb.png.eb89167abdb24839de18121d37260ead.png

Link to comment
Share on other sites

The current Passwordstate Security Administrators Manual makes this confusing.  I think it is describing the old setup.

 

2.31.19 Self Destruct Messages

Quote

There is a specific Self Destruct Message web site that recipients access via a link for their email,and this web site is embedded by default in your main Passwordstate web site i.e.with /selfdestruct at the end of your URL, or we provide a separate installer for the site so it can be installed in your DMZ. The Self Destruct Message web site does not need any access back to your main Passwordstate web site, as it is your instance of Passwordstate which pushes and pulls all data to the Self Destruct site.

 

Link to comment
Share on other sites

Hi jtstuedle,

 

Thanks very much for your support - we appreciate it.

 

From where the Self Destruct Web site is installed, it requires the following access back to the SQL database:

  • SelfDestruct - Read/Update/Delete
  • DebugInfo - Insert
  • SystemSettings - Read
  • Auditing - Add
  • QueuedEmail - Insert


Regards

Click Studios

Link to comment
Share on other sites

×
×
  • Create New...