Multiple Vulnerabilities in MDaemon + WorldClient

Application: WorldClient and MDaemon

Platform: Windows Clients.

Version: MDaemon/WorldClient - and probably earlier versions

Severity: Several Vulnerabilities - one of which gives system access.

[ ]

Vendor Status:
informed on 4th May 2002
ALT-N & EyeonSecurity worked together on a patch
which was released on 7th May 2002



(extracted from

WorldClient, integrated with MDaemon Pro 5.0, allows users access to
their e-mail accounts, folders, address books, and spell checkers with
any standard web browser. By using a web browser to access e-mail,
users can access their e-mail from anywhere on the Internet. Unlike
typical e-mail client applications, WorldClient does not require
reconfiguration to use, and does not leave any traces of messages on
the Internet terminal; an ideal feature for anyone that travels.
WorldClient also stores all of the messages on the MDaemon server, not
a third party server, a key for anyone that uses e-mail for sensitive
or confidential communications.

Multiple Problems

1. Default Username with default password.

MDaemon has a default user called MDaemon which is used by
the application itself. When trying to change any setting of
this user, and error pops up :
"The MDaemon account is built in system mail account. It is
critical for system purposes and should not be edited needlessly.
Attempting to use the MDaemon system account as if it were a
regular mail account can cause unpredictable results."

By decoding the password (as described in problem 2), it was easy to
discover that the password for this account is always MServer.

This account may then be used to further exploit other vulnerabilities
in this software - or simply as a free anonymous account by attackers,
spammers etc. Use your imagination :-)

2. Weak encryption for Password files.

The password is by default stored in a file called userlist.dat in the
MDaemon/App directory. The location of this file is usually

The password is encrypted using a weak encryption making it very easy
to decode. Each character is changed by a static offset and the final
result is base64 encoded.

3. Buffer Overflow in WorldClient

There is a BufferOverflow in WorldClient. When an attacker executes arbitrary
code using this vulnerability, such code is executed as SYSTEM on a Windows
2000 machine.

The overflow occurs when trying
to create a folder with a long name by using the Web interface (worldclient).
In my tests, the EIP is overwritten at 0x0123FFA8. The folder name has to be
about 1000 characters long to cause the overflow. It is important to note
that the client exploiting this issue has to be authenticated when sending
the exploit string. In my tests I made use of the MDaemon default account
and was able to execute arbitrary code on the target machine.

4. Deletion of any file on the same drive as WorldClient.

When creating a new e-mail messege, users can attach files. The attached files
stored in the user's folder. While WorldClient checks for filenames which
possibly dangerous characters such as "../" when creating a new file, it does
put this check when deleting attached files. This means that any file on the
drive as MDaemon can be deleted, possibly leading to a Denial of Service.

Exploit Examples.

Buffer Overflow Example:

POST /WorldClient.cgi?Session=xxxx&View=Options-Folders&Reload=Yes HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
Host: victim:3000
Content-Length: 1636
Connection: Keep-Alive
Cookie: User=MDaemon; Lang=en; Theme=Standard; Session=xxxxx


File Deletion Example:

POST /WorldClient.cgi?Session=xxxx&View=Compose-Attach HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Content-Type: multipart/form-data;
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
Host: victim:3001
Content-Length: 407
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: User=MDaemon; Lang=en; Theme=Standard; Session=xxxx

Content-Disposition: form-data; name="Attachment"; filename=""
Content-Type: application/octet-stream

Content-Disposition: form-data; name="Attachments"

Content-Disposition: form-data; name="Remove"



The issue has been fixed on May 7 2002
[The vendor has been quick to release a patch - congrats]
An update can be found at : - English - German

This fixes issues #1,#3 and #4.

To prevent users from decoding the userlist.dat file (issue #2) it was
recommended by the vendor that the correct NTFS permissions are in place.

Thanks ...

go to Arvel Hathcock of Alt-N Technologies Ltd - and his team, for the
good support and quick response (issues were fixed in 3 days). It's been
nice working with you guys.


The information within this document may change without notice. Use of
this information constitutes acceptance for use in an AS IS
condition. There are NO warranties with regard to this information.
In no event shall the author be liable for any consequences whatsoever
arising out of or in connection with the use or spread of this
information. Any use of this information lays within the user's


Please send suggestions, updates, and comments to:

Eye on Security
mail :
web :