One of the biggest problems that I saw with DNP and WSP still seems to persist in this version; that is the fact that the server site runs as an administrative user. This allows a compromised site running ASP or .net to be able to extract the credentials for this account from the MetaBase.
To make matters worse, if the server si on a domain then they can use tools like Mimikatz to capture domain level credentials and spread filth across your entire windows domain. I would really like to see the sites use non-admin credentials and then talk to a backend service that has the admin access. This would greatly reduce the risk associated with using this product.
Additionally, this product should handle filesystem permissions like Plesk does; that is lockdown filesystem access for the SCP_IUSRS group so that the group has no access to anything they do not need, and there should be a system in place where you can tell SCP what custom permissions it should set for this group on third party objects that SCP doesn’t just know about.
The lack of these two things is preventing us from deploying this product.
My point is that a website should never run with admin credentials, especially not domain admin. On a shared hosting server there is always a way for an attacker to gain access to information in the metabase. In fact, prove it to yourself, set up a server with SCP, lock it down as you say you should, put a site on it, put a copy of aspxspy on one of the sites, then have fun reading registry information and metabase properties. If you haven’t seen this happen then you either don’t run production shared hosting servers, have been very lucky, or just aren’t checking out what is happening on your servers. This isn’t the only tool out there, one the worst is mimikatz, it doesn’t even have to be downloaded, it can just be loaded into memory and executed.
- Views6589 times
- Answers9 answers