This section will start with discussing how to enable various security features that are disabled be default, and end with general notes on the framework’s security.

Trouble editing Spludlow configuration files? Are you in “SpludlowGroup”?

By default only the “SpludlowUser” and “SpludlowAdmin” users are menbers of “SpludlowGroup” meaning they have write permission to the configuration files.

Your current user (the one you log in as to do things) is not a member. Even if you are an administrator programs like notepad will give you hassle when you try to save a file (save to the desktop then drag it over).

You can achieve this using Computer Manager->Local Users and Groups->Groups->SpludlowGroup->Members. The first video also demonstrates the notepad problem, you can skip to the middle.

NOTE: On Home editions of Windows “Locals Users and Groups” is not included you have to do it with net commands (see 2nd video).

NOTE: Perform a reboot for changes to take effect.

WARNING: Web Services are by default unsecured

By default, the framework’s configuration flag “IgnoreSecurityKey” is set to true. This means anyone with a host’s web service address can access the framework, upload and run code.

Action must be taken if any of the following apply to your scenario:

· Multiple Networks in Use – If you are using the Framework with public (Internet) web service addresses so hosts may communicate through the Internet.

· Potential Local Network Attacks – Large networks where local rouge employees could attack the system, or someone with leaked VPN, remote desktop, or dial-in details connecting in.

Don’t panic too much, the Framework’s setup automatically appends random alphanumeric characters to all web service addresses when it installs them, this will prevent trivial attacks that fish for default URLs, even if you aren’t using the security key.

When “IgnoreSecurityKey” is set to false then all web service communications, WCF and HTTP, require a security key be passed. This security key is a simple shared secret, identical on all hosts, and stored by the Framework’s Credentials system, see below.

Enable the Web Service Security Key

Create a security key

The video shows generating a random key using the Intranet, but you can use anything

· On the call page search “random” and select the method “Spludlow.RandomKeys.Password(Int32)”

· Enter a length, 64 in this example. Change the address to web service (nothing after host).

· Click “Make Call Text” then “Run Call Text”, the random password is shown.

· Copy this key and keep a note of it.

Put the key into the Credentials System

The credentials system encrypts per user, this step will put the key into the “SpludlowUser” and “SpludlowAdmin” user’s credentials.

Enter the following command (inserting your key in the double quotes):

"C:\Program Files\SpludlowV1\Spludlow-Process\Spludlow-Process.exe" Spludlow Spludlow.Security SetSecurityKey ""

This command will distribute the key to all hosts. You can look in the directory “C:\ProgramData\SpludlowV1\Config\Credentials” and you will see the 2 user’s credentials file.

NOTE: You can run this through the Call Page but be aware of angled brackets in the password my cause the ASP.NET page fail.

NOTE: If you do use the Call Page do a web service call (not queue) on the master host.

Enable the key in Configuration

On the Intranet Config page set "IgnoreSecurityKey" to false and release to all hosts.

When everything has restarted check the Status and Logs pages.

Web service calls are now only permitted with the correct key.

Allow other Users

Attempt to run “TestForm.exe” using it to make web service calls. You get the “Invalid Security Key” exception.

The user we are logged in as, “Admin” in the video, is not set up with the key in the credentials system, only “SpludlowUser” and “SpludlowAdmin” are configured by default.

Enter the following command (inserting your key in the double quotes):

"C:\Program Files\SpludlowV1\Spludlow-Process\Spludlow-Process.exe" Spludlow Spludlow.Security SetCurrentUserSecurityKey ""

Look in the directory “C:\ProgramData\SpludlowV1\Config\Credentials” and you will see a file for your currently logged in user.

Try “TestForm” again it should now work, make sure you exit and run it again.

NOTE: Attempting this step through the Intranet Call page would not work because the Intranet runs as the user “SpludlowUser” not the user you are logged in as.

Changing the Key

You can create a new key and run the “SetSecurityKey” and “SetCurrentUserSecurityKey” at any time.

NOTE: You don’t have to keep a copy of the key when all your hosts and users that log in have been configured.

NOTE: The Framework can always decrypt and display this key, through the Intranet Call page or any other technique.

Locked out

The method “SetSecurityKey” is designed to work with “IgnoreSecurityKey” set to False, everything should all get the same key and restart everything on the hosts, they should all synchronise in unison. If something goes wrong, maybe a host not available, then hosts may get “locked out” because they don’t have the same key. You may also be adding a new host.

In this situation perform the following:

· On the Intranet Configuration Page set the “IgnoreSecurityKey” to True on all hosts and push out “Spludlow.config” out to all reachable hosts.

· Check on the Intranet Status which hosts are locked out.

· Log in manually to each locked out host.

· Edit “Spludlow.config” using notepad and set “IgnoreSecurityKey” to True.

· Restart all Framework related web application pools using IIS Manager->Application Pools

· Restart all Framework related service processes using Computer Management->Services and Applications->Services

· Check on the Intranet Status which that the host is now accessible

· Perform the steps mentioned above to re-enable the security key

To confirm the key is synchronised you can look for warnings in the logs before setting “IgnoreSecurityKey” back to False.

WARNING: Spludlow Intranet is not password protected by default

When the master is installed the Intranet is accessible to anyone (with the address). You can enable with 2 security options:

Password stored in plain text

To set up a simple password add the following configuration to the host running the Intranet (WSYS-HEAD-APP in the example):

Store password in Credentials

On the intranet Call page with the Intranet host selected (WSYS-HEAD-APP) find the method: Spludlow.Credentials.Set(String key, String userName, String password, String domain)

Enter a key of “IntranetPassword” and set the password to “CryPassword” (user name and domain can be left empty).

Run the call as a web service (not queue), the encrypted password is now stored.

Password to use Credentials

To set up an encrypted password add the following configuration to the host running the Intranet:

The ‘@’ means the value is the credentials key.

Send the configuration to the host running the Intranet.

NOTE: To test the password you can log out the Intranet

NOTE: If you get locked out the Intranet then edit Spludlow.config manually to remove "Spludlow.IntranetPassword" and restart the Intranet Application Pool.

WARNING: System Update Mode is enabled by default

By default the “Admin Web Service”, running with local administrator permissions, can be updated by the Spludlow Release system just like any other application (useful when working on it).

To prevent this behaviour so it cannot be updated by the release system then set “SystemUpdateMode” to false for each host in the Intranet Config page.

NOTE: Setting the web service security key may only be done with “SystemUpdateMode” set to true.

NOTE: This flag can be set back to true by anyone in the “SpludlowGroup” security group so you may want to completely this flag. See below on a better way of preventing Admin Web Service updates.

Modify UpdateWebServiceAdmin() for extra security

As mentioned in the previous section the “SystemUpdateMode” is kind of useless for protecting anyone in “SpludlowGroup” from modifying the Admin Web Service and therefore running code as Administrator.

By modifying this method in the Admin Web Service it makes it impossible for “SpludlowGroup” to initiate an update:

C:\Program Files\SpludlowV1 Admin\Spludlow-WebService-Admin\App_Code\Admin.cs

public int UpdateWebServiceAdmin(string securityKey)

{

this.ValidateSystemUpdateMode();

this.ValidateSecurityKey(securityKey);

// Un-comment this exception to prevent the Admin Web Service from being able to update its self

throw new ApplicationException("System Update mode has been disabled.");

//return Spludlow.Release.UpdateWebServiceAdmin();

}

NOTE: To update the Admin Web Service in future (higher version number) you will have to undo this change.

NOTE: Performing an update from the Spludlow Binaries will override any changes you have made, so you will have to re-apply them.

NOTE: Changes to the Admin Web Service are rare, so you will probably get away with not updating it that often.

NOTE: This change needs making on all hosts (the video shows only one). You can make the change in “C:\ProgramData\SpludlowV1\Release\Binaries\Spludlow-WebService-Admin\App_Code\Admin.cs” then perform a one-time update to all hosts.

Attacker Entry Points

There are 3 main entry points into the system; web service, message queue, and file system. Below each is described and possible types of attack and defence strategies are discussed.

Web Service

The framework communicates, to other hosts, both on the local network and to remote networks using HTTPS with a shared security key within the requests. When using the WCF interface the key is passed as a simple method parameter. In the HTTP interface the security key is passed as an additional field in the HTTP header. For testing and development, as a last resort, you can use the query string to pass the key.

WARNING: Don’t do it but if you have to pass the key to the HTTP interface in the query string then, although the query string is encrypted over the wire within SSL, they can still end up in the following places:

· Server Logs

· referrer HTTP header to other webs browsed to

· Local browser history

This simple approach of using SSL with a shared key was chosen as it will get you up and running quickly, with little OS configuration, and keep the standard system portable.

Message Queues

This type of attack can only originate from the local network, provided you have not configured Windows Firewall, routers, and firewalls to expose MSMQ to the Internet. The framework routes to remote message queues through web services and does not require any other form of access to MSMQ except local network. An attacker could send a rouge message to a queue that would then be executed by the Framework.

File System

You may think it’s already too late if an attacker has got access to the file system. But provided they only have read only access to the Framework’s files then they aren’t in yet, this may be the case if a rouge employee simply logs into a host using their daily login credentials.

If they only have read access, then they can look at the “Spludlow.config” file giving them the web service addresses. But they still cannot read any secrets stored in the Framework’s Credentials system, like the security key, even though they can read the files they are encrypted on a per user scope, and they aren’t “SpludlowUser”.

NOTE: Security can be improved on Spludlow directories by removing the “Users” group’s read only permissions.

The Admin Web Service

The framework requires elevated permissions to perform a few basic functions that are not available to a standard user (not in the administrators group). These are querying, starting, and stopping both web application pools and service processes (windows services).

An additional web service “Spludlow-WebService-Admin” exists that runs as a local administrator account to perform these elevated tasks. This web service only has limited methods available, unlike the main web service that can run anything.

The Program files for the Admin Web Service are kept in a separate directory to the rest of the Framework, which is not writable by “SpludlowUser”. This means the Framework can update its self but can’t modify the Admin Web Service, the only bit running as administrator, and replace it with a hacked version.

NOTE: For extra security modify the UpdateWebServiceAdmin() in the Admin Web Service, so however the “SystemUpdateMode” flag is set it can’t update its self.

Credentials System

The framework keeps its secrets in the directory “C:\ProgramData\SpludlowV1\Config\Credentials”. A strict TextTable with encrypted columns is stored for the Framework users, “SpludlowUser” and “SpludlowAdmin” a developer user that is a member of “SpludlowGroup” may also have a file here.

Encryption is performed using the .net class “System.Security.Cryptography.ProtectedData” which is a wrapper for the OS Data Protection API (DPAPI). The protection scope used is current user, meaning that only the same user can encrypt and decrypt, not other users on the host.

Modify the Framework Yourself

There are ways you can improve security yourself by making small changes to the Framework’s code. Just make sure you can coordinate them with updates.

You could modify sensitive classes to operate in a non-standard way so attackers won’t find what they are looking for.

Access Denied – It’s my computer, just let me do it.

There are scenarios where you just don’t want to mess about with permissions or security. Maybe you don’t care, or not connected to a network, or a single computer on a home network.

If you are having problems accessing resources on the local machine, like the file system, and just want to get on with it, and can’t be bothered to set permissions on resources then add the “SpludlowUser” user to the local group “Administrators”:

· Go to Computer Management->System Tools->Local Users and Groups->Groups

· Double click on the “Administrators” group

· Click the “Add” button and find the user “SpludlowUser” and add it

WARNING: This is not recommended, it is a dirty work around, you should learn to assign permissions for the user “SpludlowUser” to the resources you can’t access.

HTTP without SSL

If you can’t be bothered to set up SSL certificates, putting http: at the start of all web service addresses instead of https: will still work.