Date: Sat, 2 Jan 1999 06:15:04 -0500 From: Locke Nash Cole To: BUGTRAQ@netspace.org Subject: Re: Win32 ICQ 98a flaw You can also do this in the popular mIRC IRC Client, althou it has no "Open" option so there is a less chance of the person running it, however in explorer "mypic..bmp .exe" Kinda looks like a bmp the .exe is hard to see on some view modes, and if you opened the .exe file up in borland's resource editor (or any similar editor) and changed the exe files icon to that of mspaint.exe a person (sometimes even an advanced user) will double click anyway without seeing the far off .exe portion of the filename.. Also if they look in their status window they may discover the .exe, althou if you use a special dos program to write files to filenames that aren't normally allowed (with mIRC's CTRL-K color code) you could make the .exe part invisible in the status window... using CTRL+K0 for white text, and most people use the default white text background on the status window. I'm sure Eudora/Outlook Express could easily fool a user also into doing the same thing.. ----- Original Message ----- >From: Justin Clift To: Sent: Thursday, December 31, 1998 10:20 PM Subject: Win32 ICQ 98a flaw >Hello everyone, > >A while ago I found a flaw in ICQ which I believe to be fairly serious and >asked whom to notify. Thanks for everyone's assistance in this. :-) > >I notified Mirabilis and they have totally failed to respond (I've waited >about 2 weeks), so I'll now submit it here. > >It's a very simple flaw. At present I've only tested on the Win32 ICQ 98a >1.30 version, and have not tested on ICQ99 nor on other platforms. > >Here is how it works : When a person is sending a file to another user on >ICQ, the person receiving the file has a window pop up which shows the >filename, a description entered by the sender, and options of where to save >or not save etc. > >I've found there isn't a check on the length of the filename being sent. >The pane in the pop-up window will display as much of the filename as it >can, and if the filename is longer that the pane, the ending remainder won't >be displayed. > >Therefore a simple attack is possible, sending a file named (for example) : > >"leah2.jpg >.exe" > >will display leah2.jpg to the receiving user whom will only see "leah2.jpg" >in the pop-up window and assume it is a harmless picture file for example, >not executable code. > >This is very bad considering ICQ has the option of 'OPEN'ing the file once >the transfer is completed. Many people do this to have the picture >displayed to them (by the program associated with the extension). In the >case of this exploit, the executable code will be run instead of the program >the victim is expecting. A craftily coded program would be able to do both >so as to avoid suspicion on the part of the victim. > >One thing I have noted in testing is that on one person's system running >Win95 this did not work. His computer renamed the file to .zip on receiving >which stopped the file executing. I don't know why and as far as I have >been able to find out (I haven't had physical access to his PC) this is due >to his personal configuration and is not the norm. > >One additional thing should considered also, and I don't yet have the time >and ability to do so; is a buffer overflow exploit present here or in other >versions which allows remote automatic code execution? This depends on the >program and the protocol, of course. It could be *very* bad. > >Regards and best wishes, > >+ Justin Clift >Digital Distribution >www.digitaldistribution.com ---------------------------------------------------------------------- Date: Mon, 1 Feb 1999 14:01:50 -0500 From: Liam To: BUGTRAQ@netspace.org Subject: Re: Mirc 5.5 'DCC Server' hole I have also tested the balu perl script which was posted, having results exactly opposite to what Thomas has found. The only difference being I havn't tested it on an NT machine, however there are some important things to consider when using the script. Sending "C:\autoexec.bat" will not work for two reasons, in the hole described it was mentioned that mIRC does not filter the '.' or '\' characters, however this does not mean that it isn't going to filter the ':" character used to specify a drive. Although the script claims to send a fake filename breasts.jpg, if the mIRC victim chooses to maximize the dcc receive window they will see the following Filename: breasts.jpg ..\..\..\..\..\autoexec.bat Which is another reason why you can't specify a drive letter. C:\WINDOWS>cd ..\..\..\..\E:\download Invalid directory Even if we omit the drive letter, there is no guarantee that the victim has installed mIRC on the C: drive. Also note, if you attempt to send a file which the person already has on their hard drive they will be presented with a dialog box 'The file C:\autoexec.bat already exists' in which they may choose to overwrite, resume, or cancel. This defeats the purpose of sending a file breasts.jpg to get the person to accept. phear:~$./balu foo.bar.org RedMage ./evilfile.txt breasts.jpg 'windows\startm~1\programs\startup\evilfile.txt' Nick of receiver: RedMage - Resume requested at offset: 0 sending... done. phear:~$ C:\WINDOWS> dir startm~1\programs\startup\e*.txt Volume in drive C is BOOT Volume Serial Number is 6396-30DC Directory of C:\WINDOWS\Start Menu\Programs\Startup EVILFI~1 TXT 22 02-01-99 1:53p evilfile.txt 1 file(s) 22 bytes 0 dir(s) 246,480,896 bytes free C:\WINDOWS> Hence it was successful and evilfile.txt will open each time the computer is rebooted. Not only is this successful, but it is successful on both mIRC 5.5 and mIRC 5.41. I havn't tested it on any other versions but earlier versions of mIRC are probably also vulnerable. - Liam >gate:~# ./balu foo.bar.org Nickname ./autoexec.bat breasts.jpg >"c:\autoexec.bat" >Nick of receiver: unavailable - Resume requested at offset: >Broken pipe > >Tried many other settings, mirc client under win95, running balu from another >host etc. Nothing happens. > >Thomas.