Royal Apps

Hello,

I have some concerns about the security of Royal TS which I would like to share.

Royal TS is really unparalleled in flexibility, longevity, features and ease of use and we'd therefore like to deploy it in a sensitive / high-security environment on Privileged Access Workstations. So far, the CISO team won't let us because they deem the protections and security features of Royal TS insufficient.

I have collected some of the objections and issues that have been brought forward and I would like to detail them here (I hope this is the right place). I don't know if all of them are still valid in the current version or some features that mitigate this are already available, so I apologize in advance if some of the issues raised should be unjustified in some instances.

Security concerns that have been raised include:

1. The only protection Royal TS seems to offer is a simple password.

2. There are no multi-factor authentication options, even something simple like using an Authenticator app, or any biometric options such as a fingerprint scanner or smartcard reader. Windows does provide APIs for biometric devices and implementing TOTP that works with any Authenticator app should be very easy. Also, as far as I am aware, Royal Server already has some MFA options.

3. There is no option to use keyfiles (like e.g. in Veracrypt) as an additional authentication method (this is generally used to protect against hardware keyloggers as well). Again, this should not generally be very difficult to implement.

4. Royal TS does not optionally use the Windows Secure Desktop for the login form which means that any installed keylogger can easily snoop the master password. KeyPass and many other programs do support this, it has been requested before, and it should not be very difficult to implement.

5. There is no lock-out policy (i.e. quietly limit brute-force attempts by e.g. increasing wait time and always displaying a "wrong password" message after the 3rd or 5th try regardless of whether the correct password is entered).

6. There is no option to delete all credentials from a document after a number of failed login attempts (e.g. after the 10th attempt or so. This would also have to be done quietly.)

7. There is no reporting of failed login attempts (e.g. sending an email or logging this to the Windows log).

8. There seems to have been no security audit done on either Royal TS as a whole and/or the encryption part specifically.

9. It is unclear, what - if any - mechanisms are in place to protect an open Royal TS document from being exploited through any number of bugs through connections (such as malicious web pages, RDP, SSH or MITM attacks by a red team on the same network) which could then expose the complete Royal TS document with all credentials to the attacker.

10. There seems to be no option to have sensitive information copied to the clipboard automatically cleared after a given time of after it has been inserted once. Many password managers actually support this: They keep a username or password copied to the clipboard only there for 15 seconds or so until they overwrite it again. This could also be combined with Royal TS's function of "typing the clipboard" where the clipboard is cleared immediately after it has been typed out once (e.g. into an SSH session). This should of course be optional although I would reckon that most users do not need to paste a password multiple times in a row regularly and that this function is mostly used for single pastes only.

11. There is no built-in prevention that stops key sequences or pastes from going rogue and typing in the wrong window because of a focus error. It has probably happened to everyone who uses those features extensively that the focus is outside of Royal TS and an elaborate key sequence does all kinds of interesting things with the OS including typing cleartext passwords into any input field it can find. I realize that this might be difficult to prevent, although there could be options that say "Execute key sequence/paste clipboard only in the active Royal TS tab and stop immediately if there is no Royal TS tab in focus". Alternatively, you could mark key sequences as "sensitive" and select that they may only be written or typed into certain explicitly specified, selected and focussed tabs and connections (so that you cannot execute a sensitive key sequence by accident while having another tab focussed).

12. There is no information on memory protection by Royal TS, i.e. whether or not it uses e.g. CryptProtectMemory and CryptUnprotectMemory to protect passwords and connection strings, obfuscates or regularly overwrites memory to protect both credentials and its own security routines. I realize that this is not a trivial subject but there is lots of code, APIs and frameworks that can make such tasks easier. Also, Royal TS comes with licensing and activation features which customarily make heavy use of protection and obfuscation to frustrate cracking and reverse engineering so maybe some of the necessary routines for this are already implemented ;-)

13. There seems to be no option to automatically close or lock an open Royal TS document quickly with one click (Panic button) or after a given time with no user interaction has elapsed. Options that should be there, include lock document when workstation is locked (Win+L), the monitor goes dark or the screensaver comes on. Lock the document after the workstation has not been used (mouse/keyboard) for a given number of seconds/minutes. Lock the document after Royal TS has not been interacted with (e.g. running in background) for a given amount of time.

Background:

Given that Royal TS is routinely installed on admin workstations (also mobile devices) everywhere and not exactly a hobbyist's tool, it seems that much more investments should be poured into the security features and options to keep Royal TS as safe as possible. I have personally seen open Royal TS instances on-site with saved credentials to the server farms of multi-billion dollar conglomerates just sitting there... and even though I recognize that this is in large part the user's responsibility, developers must recognize that users/admins are extremely, extremely lazy and value convenience above anything else. In fact this is the very reason why they are using Royal TS in the first place! :-)

Therefore, Royal TS should make it as convenient and easy as possible to use any number of security features that don't require anything from the user (Windows Secure Desktop, Clipboard handling, internal isolation that prevent exposure of a whole document etc.) and combine them with options that make it even more secure for those who choose to go the extra mile (i.e. time-outs/auto-locking, multi-factor authentication, TOTP, keyfiles, logging, reporting etc.).

Side note:

I realize that security, as always, is a cost-center first and foremost and it can be difficult to argue why one should prioritze security features over other features that might at first glance be easier to sell. So security is always seen as a hedge at best, or a luxury. However, this can turn around quickly the very moment there is an actual attack or hacking attempt (examples are plentiful). I also believe that for Royal TS, exquisite and top-notch security features can and will open a whole new market and provide a unique value proposition for which users might well be willing to pay even extra, so if the developers need economic justification for adding a large number of extra security features, they might well consider offering an "enterprise feature license upgrade" that enables these (although it should not be outlandishly priced - like many other products in this space - as even small shops might benefit greatly from these features and might be willing to pay for them, as long as they are proportionate - the great thing with Royal TS has always been that procurement has been more or less a no-brainer, for large corporations as well as small shops, as the price point is very attractive across the board).

I would love to hear some feedback, especially by the developers and I am open to provide more details if I can on some of the points. If any of the issues raised are moot or have already been implemented, I apologize and would love to know so I can take note of this and share that information accordingly.

Jonnie W has done a really nice job explaining concerns.  I hesitate to encourage my team to utilize Royal TS from their privileged access workstations (PAW).  I performed a simple test the other day and it was trivial to echo a saved credential to clear text password via a command task.

I was encouraged to learn that Royal TS can use the Windows Credential Manager but all that is doing is storing the password to open up Royal TS and then all the saved credentials can be output clear text.  We ensure our users have complex AD passwords but there doesn't see to be anything in Royal TS preventing somebody from using Winter2021! to lock the document which is easily guessed and will then provide access to all saved passwords.

Needs more enterprise management features. 

He Stefan,

I'd like to comment on what you are saying here:

I think providing access for users to critical systems but trying to prevent them to see a shared password is the wrong approach to security. In my mind, each user should be identified with their own credentials for auditing alone.

Well, I strongly disagree. The exact opposite is true - not having the need to know passwords is the best approach to security. 

Users can still be perfectly identified and held responsible for their actions, even without knowing credentials. You don't believe me? Then try to study this very basic concept that is called just-in-time access or also sometimes called "checking out/in workflow" which is a keystone in all Privileged Access/Session Management (PAM/PSM) solutions.

This is not to say that Royal TS must follow the route of PAM but others with similar products are trying it. See Devolutions and their PAM module for the Devolutions Server (=Royal Server).

I'm saying this because I've been trying to compare Royal with Devolutions and it looks like Devolutions make a clearer roadmap from local password management to final, centrally managed PAM. Because the PAM should be the your ultimate goal when you want to have privileged access under control.

Kind regards.