`Date: Mon, 5 Apr 1999 23:50:56 +0200 From: Jan Vogelgesang To: BUGTRAQ@netspace.org Subject: security hole in ICQ-Webserver Hi, Some days ago i've read a message here in Bugtraq from Ronald A. Jarell about a vulnerability in the ICQ-Webserver . I tried to reproduce this vulnerability with my computer (win95) and find out the following: -sending any non-http stuff or even a simple "get" (without any other characters however) crashes the ICQ-Client. This works with ICQ99a V2.13 Build 1700, but not with Build 1547. Moreover, there is a much bigger hole in the ICQ-Webserver: If you have the webserver enabled, everyone can access your complete(!) harddisk with a simple webbrowser. When your page is activated and you are online, each request to "http://members.icq.com/" will be redirected to your computer. Thus, every visitor get to know your current ip. Nevertheless, only the files in "/ICQ99/Hompage//personal" should be accessible. But a visitor can "climb up" the directory tree with some dots, e.g. "http:///...../a2.html" would present him the file "a2.html" in the "ICQ99" directory. With some more dots, he would come to the root-directory of your harddisk. But there is one barrier: The ICQ-Webserver only delivers files with a ".html" extension. After some experiments I found a way to trick it out: I add ".html/" to the URL and the Webserver sends every file I request. For instance, "http:///............./config.sys" won't work, but "http:///.html/............./config.sys" would. I have test this both with Build 1700 and with Build 1547. In my opinion, this is a significant security problem, because password files or even the registry in the windows directory can be read. I warned Mirabilis about it and hope they will informe the ICQ-community. sorry for my poor english... Jan Vogelgesang ------------------------------------------------------------------------------- Date: Thu, 8 Apr 1999 08:45:48 -0400 From: "[iso-8859-1] José Reyes Cedeño" To: BUGTRAQ@netspace.org Subject: Re: ICQ Webserver bug >Well, my box was win 98, and the remote box I tested it against was >win 95. Didn't have anyone running NT handy to test against. However, >another person I corresponded with who was testing this did get it to >drop a 95 box, but not every time. Did it every time for me; but there's >apparently other factors that contribute as well. > >-- >Ron Jarrell >VA Tech Computing Center I try to test this on my NT box ( NT server 4.00.1381, Sevice pack 3 ) and I could not reproduce the error. I've used ICQ Version 99a Beta v.2.13 Build 1700. It would be beneficial if Ron Jarrell or Jan Vogelgesang, explained the procedure that they carried out to arrive to the error detailedly. Best regards, Jose. ------------------------------------------------------------------------------- Date: Thu, 8 Apr 1999 19:35:35 +0000 From: sven@MSC-MEDIA.COM To: BUGTRAQ@netspace.org Subject: Re: security hole (READ AS: security chasm) in ICQ-Webserver On 8 Apr, DaChronic wrote: > I can confirm this with Win9x but not with WinNT 4.0 sp3 and hotfixes > nor sp4 (can anyone else?). .......... As it was discussed some time ago in this list the 'more than 2 dot' feature is not working with NT. But it is definitely working with 95/98. Maybe replacing /.../ with /../../ will work ? CU Sven ------------------------------------------------------------------------------- Date: Thu, 8 Apr 1999 18:08:06 -0700 From: Scott To: BUGTRAQ@netspace.org Subject: Re: ICQ Webserver bug I'm using Win98/4.10.1998 w/ ICQ Version 99a Beta v.2.13 Build #1700 I could crash my ICQ webserver and read files remotely. When I have tried this on other computers, it only works some of the time, sometimes it returns "Forbidden" when I try to crash it or d/l files ------------------------------------------------------------------------------- Date: Thu, 8 Apr 1999 19:30:18 -0400 From: Kaven Rousseau To: BUGTRAQ@netspace.org Subject: Re: ICQ Webserver bug At 08:45 1999-04-08 -0400, you wrote: >>Well, my box was win 98, and the remote box I tested it against was >>win 95. Didn't have anyone running NT handy to test against. However, >>another person I corresponded with who was testing this did get it to >>drop a 95 box, but not every time. Did it every time for me; but there's >>apparently other factors that contribute as well. >> >>-- >>Ron Jarrell >>VA Tech Computing Center > >I try to test this on my NT box ( NT server 4.00.1381, Sevice pack 3 ) and I >could not reproduce the error. I've used ICQ Version 99a Beta v.2.13 Build >1700. It would be beneficial if Ron Jarrell or Jan Vogelgesang, explained >the procedure that they carried out to arrive to the error detailedly. > >Best regards, Jose. I tested it against my own win98 box with IE5 final (english) result: I was vulnerable. My friend with win98 and ie4 (french) result: vulnerable An other friend with win98 and IE5 (french) result: vulnerable we were all using ICQ99a build 1700 Method used: telnet to port 80 send: QUIT it disconnects after 5 to 10 seconds. , | | Kaven Rousseau | rousseau@globetrotter.qc.ca | FingerPrint: F1C8 F915 9F0F DD5E DACB 024B 5C6F 163D F097 40D6 `------------------- ---- -- - ------------------------------------------------------------------------------- Date: Sat, 10 Apr 1999 20:45:56 +0200 From: Frank Dekervel To: BUGTRAQ@netspace.org Subject: Re: ICQ Webserver bug humm, i d like to add one last thing to this according to me much too long thread. (seems some writers ain't thinking about the cause) if you have a look at the pseudocode below, which i suspect mirabilis to use, you ll find thousands of ways to exploit icq. fread(my_socket,"%s %s %s", getword, url, httpversion); /// if you only feed two or one word, it 'dumps core', gpf under windoze change the slashes in url to backslashes; url = "c:\program files\icq\webroot_dir\" + url; /// yes, this is the '../../../../' bug ... open(fd,url); read(fd,buffer); write(socket,buffer); close(socket); i think its this because i made small webserver earlier to see common bugs. i checked on the net, and the dynamic server of francois piete (known for delphi components) and various shareware servers, or remote admin modules for eg. proxy servers are vulnerable. greetz, kervel (kervel@svennieboy.terbank.kotnet.org) ------------------------------------------------------------------------------- Date: Sat, 1 May 1999 13:58:41 +0200 From: Jan Vogelgesang To: BUGTRAQ@netspace.org Subject: Update: security hole in the ICQ-Webserver Hi, some weeks ago, I wrote a message about an security hole in the ICQ-webserver (look at http://www.geek-girl.com/bugtraq/1999_2/0028.html to read it again). Mirabilis found the bug and fixed it with Build 1701, that can be downloaded from the http://www.icq.com/download/ . But they don't put a warning on their Webpage and inform the ICQ-community about the bug. That's bad. Moreover, the fix leaves a small problem (not really a bug) in the Webserver: ----describtion of the security problem in Build 1701 ---- Problem: When the ICQ-Webserver is enabled (i.e. "Activate Hompage" is checked) everybody can test if a specific file exsist on this computer. Although an attacker can't view the contents of the files, he can test, for example, if a certain application is installed on this computer. This knowledge is usefull to prepare other attacks, e.g. sending specialized macro viruses or do some specialized D.o.S. - attacks. Details: Mirabilis fixed the old ICQ-Webserver-Bug. With the new version (build 1701), the ICQ-webserver would only deliver Files in the ICQ-Homapge-directory. If an attacker tries to read a file that is not in the hompage-directory of ICQ99 (with the same method as in the old bug), the ICQ-webserver would'n deliver the file. If the file exsists on the specific location the attacker would receive "403 Forbidden". If the file doesn't exsist he would receive "404 Not Found". Thus, he can test if a specific file exsist. It seems that the ICQ-Webserver first tests if the requested file exsists and than if the request is secure. I think, this order should be reversed. Jan Vogelgesang `

Query Builder