Download Security Flaws in One Time Password Implementation: A Case Study and more Slides Software Engineering in PDF only on Docsity! Secure Security Software Docsity.com Overview •Background •Code sample •Analysis •Conclusions •Related Works Docsity.com Background: One Time Passwords • While OTP schemes are useful, they're not often used o Complexity Setting up the infrastructure Multiple users Handling bad logins Generating challenges Provisioning keys User interfaces Training users how to use an OTP o Cost OTP calculators -- extra hardware o Security Disclosure of password list (OTPW, S/KEY) Still requires protection from MITM attacks Docsity.com Background: One Time Passwords • Both OTPW and S/KEY (Lamport's Scheme) use cryptographically secure hash functions to generate passwords o Cryptography libraries are traditionally difficult to implement right Reuse code libraries But be sure you're reusing them in the right way! o The hash functions operate on a combination of the user's input and known states of both parties ("what you know") • Other types of OTPs o Hardware access tokens (not covered) Still vulnerable if poorly implemented Docsity.com About The Code • For the purpose of this project, we will focus on the verification stage • Assume all other stages are implemented in a correct and secure manner • The verification procedure should also be implemented in a correct manner, but it has major security flaws • The overall goal of the software is thwarted because it was not developed in a secure manner • Security is only as strong as its weakest link Docsity.com Analysis • What's wrong? o Input validation -- none! o File names can be selected by the attacker o Command injection immediately apparent What happens if I enter "|rm -r /" as the user? • If the program is running as a superuser to generate security tokens (e.g. provide login services), we have a privilege escalation issue o Anonymous user => root o Anything can happen • If the program is restricted, things are a little bit better o Might be able to run programs as a restricted user o May be able to view or modify configuration information (system secrets?) Docsity.com Conclusions • We have shown that software security is needed in security software. Using a well-known protocol is not enough to ensure the software's security • Other examples exist of security software with software security vulnerabilities -- try visiting Bugtraq, or NVD o CVE-2006-3961: Network Associates: McAfee Security Center 6.0.23, buffer overflow, arbitrary remote code execution o CVE-2007-5603: SonicWall: SSL-VPN NetExtender buffer overflow, arbitrary remote code execution o CVE-2010-0107: Symantec: Norton Internet Security, buffer overflow, arbitrary remote code execution • Very few bugs of this flavor (high risk, arbitrary remote code execution) are present in today's security software o Improving code quality? Docsity.com Conclusions • It is unfair to say that S/KEY (or any OTP scheme) is immediately vulnerable o We're only implementing a tiny stub to show "what could go wrong." • On the other hand, it could still be applicable: o Looking up byte-by-byte what "bob.tmp ;rm -r /; mkdir pwnt" would be in the dictionary o Looking up byte-by-byte what "bob.tmp ;rm -r /; mkdir pwnt" would be as a hexadecimal byte string and feeding it in to the server Docsity.com
