You said, "I have no idea if setting up per-user ACLs
would help - comments are welcome."

ACL are Access Control Lists, used by Domino to
determine a user's access to any particular
database. If you setup the default access to be
Manager (or even Reader), you will be able to browse
the contents of that database. It seems to me that
you have access to both of your test databases with
or without your tool. If you just use the regular Notes
client, I would be willing to bet that you can open up
Diego Maradona's mail file without switching Notes
IDs. If you can, your test is worthless because you
already have access.

If you want to secure your database with more than
the default level of Domino security, you can encrypt
the database to force a key-exchange required-
response for access. If you do not hold the key in
your Notes ID file, you do not get access regardless
of what kind of "proggy" you want to use.

You can also encrypt the network port on the server,
therefore requiring an encryption key on the Notes
client. Same idea, no key, no access.

But the default security model should be enough in
your scenario. Each user's mail file has only the
user's name and their home server in the ACL of that
database. Any user trying to access information will
be rejected. You can allow public document access
(for instance to check your calendar file) which allows
users to view public docs, and this is controlled
through the ACL. If you set the default access wide
open, then anyone can access your mail file. For
public mail-in databases, this is often done.

Notes has many security layers. Authentication with
the server for initial access (no certificate, no
access), Server access fields, database level ACL
access, document-level security, section-level
security, and field-level security. With that, you can
throw in form and view level security and the abiltiy to
encrypt this information at any level. Man in the
middle attacks of this sort will only work if the
targeted database in question already allows the
attacking user access.

> [ 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 [lcamtuftpi.pl] [tp.internet/security]
> [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
> =---> Did you know that clones never use mirrors?
<---=
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]