Compromising desktop single sign-on

Desktop single sign-on systems allow using your primary (i.e. Windows) logon to provide access to legacy/alien applications (i.e. mainframe green screens) by caching credentials securely and supplying those automatically on behalf of the users. They also allow enterprise administrators to assign credentials to the users so that they don’t even know their TN3270 logons and such.

Examples of the products I’m talking about are ActivIdentity SecureLogin SSO and BMC Enterprise Single Sign-On. And the vendors are pitching their solutions as the ways to achieve regulatory compliance. For example:

GLBA (Gramm-Leach-Bliley Act, a US law mandating financial institutions to maintain consumer privacy – SP) requires financial institutions to employ extensive physical, electronic, and procedural controls to protect customers’ personally identifiable financial data. This is essential in light of the rapid growth of online services, such as paying bills, transferring funds, and trading stocks.
One of the easiest, fastest and most effective technologies to institute and document compliance is Enterprise Single Sign-On. Financial applications are often not properly locked down – many users are under one account. Financial institutions and their service providers need to assure that applications are password protected in order to prevent improper access. Sometimes many users share one password, but GLBA mandates an audit trail. One password would make it difficult to track usage and culpability. Users need individual passwords with strict selection criteria to make it more difficult for the criminal to gain access. Passwords should be changed regularly to keep systems secure.

Single sign-on makes it easy for every user to start every computerized session with proper authentication. The result is simple to use security combined with verified privacy. Audit trails facilitate accountability for personally identifiable information usage.

So we have a crappy application, but this new system hides the logon from the users and requires them to log on – with individual complex passwords, or even smart cards – and offers audit trail.

Do you see a problem? To me, it’s obvious. The old and insecure application is still there, fully accessible by the users (thus SSO). What if I want to avoid audit trail provided by the SSO solution? I need to find out what my legacy credentials are. The TN3270 password that SSO system sends to the host on my behalf. How do I do that? I can always capture network traffic and recover passwords in clear. But what if the password is sent over SSL or SSH?

I’ll spoof the target then. That is, I’ll change the network environment so that the URL, or the host name will point not to a legitimate system but to something that I control – running TN3270 server, or SSH daemon; I’ll mimic the prompts and the dialog boxes too. Chances are, the SSO system doesn’t verify trust (SSL cert, SSH key) – it will imply that the user does that. It will send password to the host that I control. Done. I have user name, password and the application – all available to me and accessible without the SSO system and its audit trail.

Which means we need to know what issues SSO will fix for us and what it doesn’t. Fixing insecure applications is a better approach to security. Just very expensive sometimes.

I must note that this is pure speculation (regarding the products mentioned) and it will be couple of months at least until I prove myself right or wrong. I feel rather confident though – I have seen too many issues with implicit trust (I’ve written about it before).

Leave a Reply

Your email address will not be published. Required fields are marked *