1
2	Motivations Ongoing, widespread compromises Over 20 sites that span .mil, .gov, .edu Over 3000 computers Unknown # of accounts Specifically targeting laboratory and academic systems Speculate due to the # of shared accounts Very similar to unresolved compromises from 2003 Common Modus Operandi Acquire legitimate username/password via keyboard sniffers and/or trojaned clients and servers Log into system and use “off the shelf” rootkits to acquire root Install sniffers and compromise services, modify ssh-keys Iterate This round of compromises, as well as the compromise from 2003 are the largest DOE compromises in recent memory (in terms of # hosts and sites)
3	Observations Users typically use the same password across many sites History files provide hackers with potential remote targets Not possible to assure completely up to date patch levels across all systems at all sites In at least one incident, kernel exploit was only published for a few weeks before it was used to gain entry Kernel versions and software rev levels may not be flexible due to requirements by applications users Some systems may be understaffed, or have different priorities and have trouble keeping up to date with patches Some systems have are committed to vulnerable, but commonly used services (NFS) Bottom Line: passwords are only as secure as the least secure site that shares some of your users Security is an Arms Race Hackers get smarter, and through the miracle of automation, leading edge techniques trickle down to script kiddies in a matter of months There is no silver bullet, there is end in sight: we cannot afford to deploy a solution that is short sighted – must think a few moves ahead
4	One Time Passwords One Time Passwords (OTP) Defangs entire class of password harvesting attacks Sites that deploy OTP are now protected from vulnerabilities at other sites Do not require hardware interfaces at all client systems (as SmartCards would) Does not address compromised services Does not address stolen long term tokens (ssh keys, grid certificates) Does not address stolen short term tokens (kerberos tokens, Grid proxies) If deployed without proper planning, may cripple: Grids and Distributed Applications Automated services (especially wide area automated services: file replicators) Only a single component in a broader security regime But it addresses an immediate and very damaging problem
5	Potential Problems Forcing each and every incoming connection through OTP via a single gateway Bottleneck at gateway Cripples bulk transfers, automated processes, distributed applications Users may be burdened with enormous token collection Users don’t like carrying around many tokens, and sometimes stop using them because they’ve forgotten the PIN code Software based tokens may not be secure For convenience, soft token may be installed on laptops, cluster nodes and other locations that are vulnerable. If hardware tokens are shared, then must protect against cross site replay attacks Time based passcodes are replayable cross site within passcode window (3 minutes in some cases) Deterministic (“event based”) passcode sequences subject to replay unless some form of cross site synchronization in place Challenge response is safest, but some vendors do not support it (SecurID does not support CR)
6	Requirements (short term) Must have a roadmap to cross site authentication Necessary to minimize the number of tokens users must carry Must have provisions to prevent cross site replay attacks OTP system used only for authentication, authorization is locally determined Must use Hardware tokens s/w tokens likely to be installed on easily compromised hosts, resulting in “Emperor’s New One Time Password System” Smartcards require hardware at client machines for reading – no good for mobile users S/Key and OPIE are good for initial testing, but have scalability issues when it comes to managing key lists and cross site authentication Vendor must have demonstrated ability and willingness to support DOE Lab sized population Must support core services and platforms used for DOE Computing Unices (Solaris, AIX, Linux, etc…) Services (ssh, ftp, Grid services, Web, etc…) Support RADIUS protocol, either directly or through appropriate translators Support of PAM for client authentication, either directly or via radius Must not cripple Bulk data transfers Automated services Distributed Applications and Grids
7	Requirements (longer term) Account Security is an Arms Race – so we need to think ahead Must be able to integrate OTP with Grids Grid certs are vulnerable due to lack of password controls and inability to audit proxy generation Hackers are already aware of ssh keys, minimal conceptual leap to Grid certs All techniques necessary for certificate hijacking already exist certs are only safe due to the relative obscurity of Grid authentication A widespread move to OTP may result in requirement that proxies be issued based on OTP authentication Tokens such as Kerberos tickets and Grid proxies need better security Kerberos vulnerabilities have been known for decades, but due to relative obscurity, it hasn’t been specifically targeted Grid Proxy vulnerabilities are virtually identical Widespread use of Kerberos in Windows is lifting veil of obscurity Once proxy certificate stolen, hackers have free access to all sites that trust that cert No current method of revoking proxy certs Certificate Revocation Lists do not seem to be widely enabled Develop real time proxy/kerberos ticket revocation Develop extensions or procedures for limiting authorization of vulnerable certs
8	Recommendations Deploy Hardware token based OTP systems that support Radius Proxies Short term use of SKey/OPIE may be acceptable until federated solution becomes available, but cost of doing 2 deployments must be thought out Use Kerberos/GSI for bulk data transfer, automation, distributed applications and for batch jobs that need to authenticate Put grid certificates into a central store such as MyProxy/GridLogon Integrate OTP with Kerberos or MyProxy/GridLogon so that tokens can be used without dependence on static passwords Deploy OCSP or related services when they become available Do not force a single OTP protected gateway model on users Investigate cross realm authentication using Kerberos and OTP Where possible, deploy small cross site OTP with an eye towards eventually large scale federation Eliminate the use ssh-keys Already instances of ssh-keys being replaced by hackers, cannot be secured Enable and properly maintain Certificate Revocation for your site
9	Findings Current vendor provided OTP solutions are not scalable for cross site auth Example: RSA SecurID supports only 6 sites (DOE alone is over 20) Generally require a flat user namespace Tokens cannot (realistically) be shared across vendors Radius Proxies provide a common transport for cross site, cross vendor authentication But will require routing and name translation “glue” Will also need some replication strategy No “off the shelf” OTP solution seems to exist that will scale for cross site auth vendors don’t seem interested in building such a system on our behalf Home grown systems are at least a year or more away Site’s plans for deployment are on much shorter time scale
10	Future Work GridLogon ESNet Radius Proxy fabric DOE labs evaluating OTP solutions Mailing lists: otp-eng@nersc.gov : OTP engineering otp-users@nersc.gov : OTP user forum Send mail to majordomo@nersc.gov with “subscribe otp-eng” and/or “subscribe otp-users”