-----BEGIN PGP SIGNED MESSAGE----- ___________________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ ____________________________________________________________________ INFORMATION BULLETIN Vulnerabilities in Lotus Notes Domino Aired at DefCon 8 August 3, 2000 01:00 GMT Number K-062 ________________________________________________________________________ PROBLEM: At the DefCon 8 convention in Las Vegas, NV (July 28-30, 2000) some consultants described and demonstrated vulnerabilities in Lotus Notes Domino. The vulnerabilities involve poor encryption on the http password, cached passwords, and a vulnerability to malicious code when Internet Explorer is used as the reader. The first two vulnerabilities require physical access to the machine being attacked while the last concerns problems generic to Internet Explorer. PLATFORM: Lotus Notes Domino Servers and Clients. DAMAGE: Intruders can gain access to a user’s account. SOLUTION: Upgrade the encryption of the Notes http passwords, do not leave a system unattended while it is logged into Notes, and do not run applications that are unexpectedly attached to web pages or mail documents. See the note below and the Lotus security pages (www.lotus.com/security) for more details. ________________________________________________________________________ VULNERABILITY Low - These vulnerabilities require physical access to ASSESSMENT: the machine being attacked or they require that you allow malicious applets and attachments to run. ________________________________________________________________________ [Response from Lotus to the assertions made at the DefCon 8 conference.] Comments on DefCon 8.0 Presentation on Domino Security Vulnerability Lotus is aware that DefCon 8.0 in Las Vegas featured a presentation by consultants describing security attacks against Lotus Notes and Domino. Several of the scenarios focus on poor security administration and some involve new exploits. At Lotus, we are committed to security and encourage administrators to thoroughly examine possible risks and implement precautions to keep their Domino environment secure. For further information on Domino security guidelines and preventative measures, please consult the on line documentation and visit the ITCentral security zone at www.lotus.com/security. The scenarios raised in the DefCon presentation can be categorized into four main areas: Assertion 1: The encryption key used to unlock a user's Notes ID can be derived from the default format used to store the HTTP password in the person document. Preconditions: This vulnerability does not affect all Notes/Domino installations and can be easily prevented. In order for this type of exploit to be successful, all of the following conditions must be met: 1. a user has access to a Domino server from both Notes client and web client 2. their Notes ID password and http password are identical 3. the http password is stored in the default format 4. a malicious user has access to the users workstation 5. and access to sophisticated programming tools........ THEN the malicious user can impersonate a user. Solution: System administrators can easily upgrade to a stronger http password format using a tool introduced in R4.6. To do so, select all person documents in the Domino Directory (names.nsf), and then from the menu, select Actions\Upgrade to More Secure Internet Password Format. Assertion 2: Using F5 to lock the Notes ID (or specifying a timeout for the Notes ID) does not completely clear the password in all situations. In certain circumstances, Notes API programs running on the local workstation can access files using the cached credentials. These credentials allow background replication and agent execution to take place unattended. Preconditions: This problem affects any program, not just Notes, running on an operating system that does not support protected memory segments. A malicious user must have physical access to the workstation and sophisticated programming tools must be used. Solution: When workstation is left unattended, either exit the Notes client or lock the workstation using the operating system. Assertion 3: Notes does not provide additional security when a) using Notes with Internet Explorer as your browser and/or b) when launching attachments with Internet Explorer configured as the default browser in Windows beyond the Internet Explorer ActiveX warnings. Preconditions: When the default browser in Notes is configured to use "Notes with Internet Explorer", it is subject to the types of attacks that can affect Internet Explorer as a stand-alone product. If the user ignores ActiveX warnings generated by Internet Explorer (example shown below), the user may be vulnerable to malicious active content. If executable attachments are sent via email, use caution in executing them. Once an attachment has been detached or launched, it is no longer subject to ECL controls and is dependent on the operating system. Solution: Do not launch or run executable code or any kind from unknown/untrusted sources. Do not ignore security warnings from the Notes ECL or from Internet Explorer ActiveX controls. In Notes, attachments can be Viewed instead of Launched or Detached. The remainder of the presentation focused on recommendations for securing Notes and Domino environments, and reiterated many best practices as documented by Lotus. Notes and Domino provide a range of security options to allow systems administrators to configure their environment according to their needs. Information on how best to configure security options for a particular environment or situation are described in the Lotus Notes and Domino documentation, articles on Notes.net, white papers, Lotusphere presentations, redbooks and in Knowledge Base technotes. Lotus recommends that administrators review these resources and make appropriate configuration decisions based on their environment and security policies. For reference, visit the Technical Library on Security at www.lotus.com/security In particular, the following links are excellent starting points: A Guide to Securing Domino Applications http://www.ciac.org/developers/itcentral.nsf/ wdocs/74070EA8E6B8DAC8852568320061FA74 Four Tips for Securing your Domino Web Site http://www.ciac.org/developers/itcentral.nsf/ wdocs/F445DCF40CAD7E4E852567AF006F95B7 [End of Lotus Response] ________________________________________________________________________ CIAC wishes to acknowledge the contributions of Lotus Development for the information contained in this bulletin ________________________________________________________________________ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 925-422-8193 FAX: +1 925-423-8002 STU-III: +1 925-423-2604 E-mail: ciac@llnl.gov For emergencies and off-hour assistance, DOE, DOE contractor sites, and the NIH may contact CIAC 24-hours a day. During off hours (5PM - 8AM PST), use one of the following methods to contact CIAC: 1. Call the CIAC voice number 925-422-8193 and leave a message, or 2. Call 888-449-8369 to send a Sky Page to the CIAC duty person or 3. Send e-mail to 4498369@skytel.com, or 4. Call 800-201-9288 for the CIAC Project Leader. Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://www.ciac.org/ (or http://ciac.llnl.gov -- they're the same machine) Anonymous FTP: ftp.ciac.org (or ciac.llnl.gov -- they're the same machine) Modem access: +1 (925) 423-4753 (28.8K baud) +1 (925) 423-3331 (28.8K baud) PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained via WWW at http://www.first.org/. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) K-052: AIX cdmount Vulnerability K-053: Linux setuid Kernel Fix K-054: Vulnerability in Linux wu-ftpd K-055: HP Web JetAdmin Vulnerability K-056: IRIX WorkShop cvconnect(1M) Vulnerability K-057: Microsoft "Active Setup Download" Vulnerability K-058: OpenSSH UseLogin Vulnerability K-059: Microsoft "DTS Password" Vulnerability K-060: Microsoft's Malformed E-Mail Header Vulnerability K-061: Microsoft "Office HTML" & "IE" Script Vulnerabilities -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5.2 iQCVAwUBOYnyYbnzJzdsy3QZAQH8oAQAysBgM2z3Ppbds0b+iHF0SFHCdsDxuqIn 94uKd7nRQLd7wielbqyms1ae2JLHj1cfdeNiawbzNp9+G+CYOB8Fg8Iq3I27Qcud 1WMlXCrW1GX6O6FmkvGn+QNtqr+h2iO0ubmli3djy9mBPaTnhFKQ6rjYQBlq52Ep GX5wDThBktQ= =BRin -----END PGP SIGNATURE-----