5929542 2001-01-08 15:28 +0100 /100 rader/ Michal Zalewski <lcamtuf@DIONE.IDS.PL>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-08 19:01 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: lcamtuf@DIONE.IDS.PL
Mottagare: Bugtraq (import) <14638>
Ärende: Lotus Domino: security hole the size of Texas,
------------------------------------------------------------
plus somewhat smaller protocol auditing utility From: Michal
Zalewski <lcamtuf@DIONE.IDS.PL> To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID:
<Pine.LNX.4.10.10101081523420.12819-100000@squirrel.tpi.pl>
[ Ben, this is an updated version. Plese let this one thru, if it
isn't ] [ too late. Thanks. ]
Even my girlfriend said this bug is incredible :P Sit and relax.
* First of all, a few words from me. Sorry for that if you hate my
* occassional intros - please appreciate that I am not putting 80x20
* ASCII 'A D V I S O R Y' header at the begining of every post ;)
* Standard disclaimer applies, these are my private beliefs based on
* assumptions and observations that do not have to be true.
<intro>
I am observing really dangerous and alarming tendency in commercial
software. To be short, more and more vendors are claiming their
products are secure - and they have proofs: extended authorization
mechanisms, PKI support, dynamic passwords, SSL support or other
advanced techniques. Oracle, Lotus, other vendors of software which
is supposed to be secure - from data exchange systems to firewalls -
well, just go to their websites and click on 'SECURITY'. But what's
behind? Too often we can expect nothing more than "Saturday Night
Live" solutions, which are *not* tested to provide enough security
and are developed by programmers with little or no knowledge about
trust relationships in computer networks (eg. having propertiary
client software does NOT mean you can accept everything coming from
it). Really poor implementations of good algorithms. Where are they
going? *NOTHING* can replace good coding.
</intro>
Ok, an example (as if there were not enough - see Oracle problems,
for example - and a lot of solutions I've recently focused on): Lotus
Domino client <-> server communication when accessing corporate
mail. Lotus Domino is used by banks, insurance companies, large
corporations etc. It is supposed to keep privacy of its users, right?
Hmm...
These observations were made on default Lotus Domino installation
from the box. I have no idea if setting up per-user ACLs would help -
comments are welcome.
Let's assume we have user of (randomly chosen) name 'Antonio
Banderas'. He is using Lotus Domino client to access his corporate
e-mail account. His client contacts the server using port 1352
(IIRC, we're talking about TCP/IP communication), and sends all
necessary authorization data. Well done, Antonio, you know your
password. In the response coming from the server, we can see the
following string:
CN=acme_server/O=ACME/C=PLmail\abandera.nsf4
(or similar, depending on server's name, organization, country,
mailbox localization etc)
Funny, server is sending mailbox name to the client. Nothing
uncommon, but what happens then? In order to access user's mailbox,
Antonio's client is sending this name back to the server - see packet
dumps and look for 'mail\abandera.nsf'... BZZZT, ALERT!:)
Especially for this occassion, I have developed small and quick hack
which can be used to transparently modify packets travelling thru
your gateway - or, generally, any interface(s) including loopback
device. It is called netsed, by rather obvious analogy to 'sed' ;)
You can get it at:
http://lcamtuf.na.export.pl/netsed.tgz
This little proggy can be really useful for futher propertiary
protocol audits and other appliances, but no matter - see the README
if you are interested :)
Ok, I used my NetSED to change mail\abandera.nsf in the packets
travelling between client and server. I have replaced 'abandera' with
'dmaradon', as Diego Maradona seems to be user of this purely
hypotetical e-mail server as well :P
And what happened? Dear readers! This is ridiculous! Antonio, without
knowing Maradona's password, gained access to his mailbox! Well,
consequences are obvious. Lemme turn my caps lock on ;) OK.
ANY AUTHORIZED USER OF LOTUS DOMINO MAIL SYSTEM CAN GAIN UNAUTIORIZED
ACCESS TO *ANY* MAILBOX IN THE SYSTEM BY MODIFYING THE TRAFFIC
BETWEEN HIS CLIENT AND DOMINO SERVER OR BY MODIFYING CLIENT SOFTWARE
ITSELF.
(with great sorrow, have to turn my caps lock off)... Not to mention
accessing / modifying other files than mail\*.nsf entries. I haven't
checked for that - should be more problematic, but probably can be
done.
Again - as I said - your comments are welcome. First of all, it would
be nice to confirm this problem, and to see if ACLs might help. And
*NO* - encrypting TCP/IP connection won't change anything, as stated
above.
--
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=---> Did you know that clones never use mirrors? <---=
(5929542) --------------------------------(Ombruten)
5930788 2000-01-08 21:52 +0100 /22 rader/ Michal Zalewski <lcamtuf@DIONE.IDS.PL>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-09 01:15 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: lcamtuf@DIONE.IDS.PL
Mottagare: Bugtraq (import) <14657>
Ärende: Re: Lotus Domino: security hole the size of Texas,
------------------------------------------------------------
plus somewhat smaller protocol auditing utility
From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.30.0001082151040.322-100000@dione.ids.pl>
On Mon, 8 Jan 2001, Robert van der Meulen wrote:
> Entertaining ;) Do you have more detailed information about this ? I
> wouldn't mind knowing what version(s) you tried this on, and where it
> worked..
No problem. Premilinary tests were done on Lotus Domino Release
5.0.5... erm, I have no specific info on a few confirmations I've
received. We've confirmed that ACLs are NOT preventing this kind of
attack.
--
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=--=> Did you know that clones never use mirrors? <=--=
(5930788) --------------------------------(Ombruten)
5939848 2001-01-10 10:15 +0000 /21 rader/ <paolo_armando@CEDATI.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-10 21:04 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: paolo_armando@CEDATI.COM
Mottagare: Bugtraq (import) <14711>
Ärende: Re: Lotus Domino: security hole the size of Texas,
------------------------------------------------------------
plus somewhat smaller protocol auditing utility
From: paolo_armando@CEDATI.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010110101517.5988.qmail@securityfocus.com>
>[snip]
> ANY AUTHORIZED USER OF LOTUS DOMINO
MAIL SYSTEM CAN GAIN UNAUTIORIZED
> ACCESS TO *ANY* MAILBOX IN THE SYSTEM BY
MODIFYING THE TRAFFIC BETWEEN HIS
> CLIENT AND DOMINO SERVER OR BY
MODIFYING CLIENT SOFTWARE ITSELF.
>[snip]
no, you are wrong. in the standard install everyone
can read public documents (not mail) in the mail user
db. for more info , go to :
http://www.notes.net/46dom.nsf/df537c4a2ff2611f852
5689c005c6bf2/db3e837e8e9970c8852569d00032a2
2d!OpenDocument
(5939848) ------------------------------------------
5950269 2001-01-12 07:40 +0000 /105 rader/ <paolo_armando@CEDATI.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-12 23:03 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: paolo_armando@CEDATI.COM
Mottagare: Bugtraq (import) <14784>
Ärende: Re: Lotus Domino: security hole the size of Texas,
------------------------------------------------------------
plus somewhat smaller protocol auditing utility
From: paolo_armando@CEDATI.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010112074002.9567.qmail@securityfocus.com>
This is the official lotus response:
The following document will be posted shortly to the
Security Zone web
site at http://www.lotus.com/security. It is also
documented in technote #183851 (still in editorial
process).
In the event of any updates, please see the technote,
or the web site.
Reported Issue:
In a recent post to an Internet mailing list, the author
asserts that,
regardless of ACL settings, anyone who can intercept
network packets
between a Notes client and Domino server can
circumvent the ACL ( Access
Control List) and gain access to another user's mail
file.
Lotus Response:
We have thoroughly investigated this claim and have
determined it to be
false. The Domino server checks and enforces the
ACL for each request
based on the user's authenticated identity. To
prevent interception of
the user's credentials, network port encryption can
and should be enabled
on the Domino servers.
Supporting Information:
The report discusses two potential issues. Neither
of these should be
considered a bug in the software.
The first part of the attack can be described as a
"Man-in-the-Middle"
attack. This type of attack intercepts packets on the
network and either
modifies or reads them. Notes and Domino offer a
network port encryption
feature which prevents this type of attack. This
feature is very simple
to enable and has been in the product since its initial
release (R1).
Details on how to enable this feature are included at
the end of this
document. Similar attacks can be executed against
web servers as well.
That is why administrators configure SSL (Secure
Sockets Layer) on web
servers to protect user credentials and confidential
data by encrypting
network traffic.
The second alludes to a potential issue with ACLs.
In the example
described, User A's credentials have been
intercepted and are used to
access User B's mail file. Based on a user's
authenticated identity,
Domino checks the ACL (access control list) and
determines whether the
user has authorized access to the database. In this
case, an entry for
User A is checked in the ACL for User B's mail file. If
User A is not
listed explicitly in the ACL or as part of a group listed
in the ACL, the
level of access assigned to "Default" will apply. The
standard ACL for
mail files has "Default" access set to "No Access".
Users can optionally
enable other users to view public documents, which
are typically Calendar
and Scheduling documents.
To encrypt network data on a port
1. From the Domino Administrator, choose the
server for which you
want to encrypt network data.
2. Click the Server - Status tab.
3. On the tool bar, choose Setup Ports
4. Select a network port in the Communication
Ports box.
5. Select Encrypt network data.
6. Click OK.
Thomas Hinders
Technical Account Manager / SE - New York
Lotus Development Corp / An IBM Company
Phone: 610-578-2565 Fax: 610-970-5633
Notes: Thomas Hinders@ Lotus
Notes Net: Thomas Hinders@ Lotus @ Notes Net
Internet: thomas_hinders@lotus.com
(5950269) ------------------------------------------
5950502 2001-01-12 17:27 +0800 /32 rader/ Vinci Chou <Captainbig@BIGFOOT.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-13 00:08 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Captainbig@BIGFOOT.COM
Mottagare: Bugtraq (import) <14787>
Ärende: Re: Lotus Domino: security hole the size of Texas,
------------------------------------------------------------
plus somewhat smaller protocol auditing utility
From: Vinci Chou <Captainbig@BIGFOOT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3A5ECE0A.917A0D2C@bigfoot.com>
Lotus has posted the official response at
http://www.lotus.com/home.nsf/welcome/securityzone or you can go to
the page directly at
http://www.lotus.com/developers/itcentral.nsf/F09A97EFEF47030F8525674B00574590/22E3F54E2239EE63852569D2000AD6B6?OpenDocument
Basically, Lotus refuted his claims.
Also, my colleagues have downloaded the netsed program from Michal
Zalewski's web site but we were unable to reproduce what he claimed.
If we modify the user name from UserA to UserB at the initial
connection, we got an authorization failure. If we modify the
mailbox name from mail\UserA.nsf to mail\UserB.nsf after the initial
authorization, we observed that the server returned the *modified*
mailbox name, i.e. mail\UserB.nsf in the response. Also, when you
click on the properties of the mailbox icon, it says mail\UserB.nsf.
At this point, you would have think that you successfully switched to
the mailbox of UserB. However, when you open the mailbox, the actual
content displayed is still that of UserA!
So, what have been changed was only the mailbox name as shown in the
mailbox icon. Michal Zalewski could have been misled to think that he
is accessing the mailbox of UserB.
Vinci
(5950502) --------------------------------(Ombruten)