Lotus Domino: security hole the size of Texas, plus somewhat smaller protocol auditing utility

[Michal Zalewski <lcamtuf () DIONE IDS 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? <---=