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