Re[2]: ICQ 2003a Password Bypass

From: CauÇ Moura Prado (mouraprado_at_infoguerra.com.br)
Date: 07/08/03

  • Next message: Matt Zimmerman: "[SECURITY] [DSA-343-1] New skk, ddskk packages fix insecure temporary file creation"
    Date: Tue, 8 Jul 2003 06:22:40 -0300
    To: gvs@demos.net
    
    

    First off I have notified ICQ Inc. three days ago and what I got was
    an automatic reply. I have released the exploit to encourage them to
    release a new build of ICQ Pro. The vulnerability may be exploited
    locally. If it was exploitable remotely make no mistake that I would
    wait for a new release or patch before spreading my code.

    And you didn't miss anything. That's right.
    ICQ STORES the password on your machine even if you don't want to!

    Second off you've supposed wrong! This vulnerability has nothing to do with
    connection timeout exceeding. And The exploit has NO limitation.
    It does what it claims to do. If a poor soul did install ICQ 2003a on its machine
    then all UINs registered on that machine will be vulnerable. It's sad that you
    didn't try to exploit the vuln before replying me.
    If you had ran the exploit you would realize that ICQ itself sends the
    password to authenticate the session the same way it does when you
    check "save password" function! SO, there's a password and server will
    not refuse to autorize the connection! The problem is:
    If you have never checked "save password" function the password
    should not be in anyplace. But it's there.
    The exploit just enables you to click on Online status and force ICQ to
    send the correct password to the server. Got it?

    ps: ICQ is vulnerable even when you change your security level to
    High!

    see ya
    ca1

    Tuesday, July 8, 2003, 2:49:29 AM, Seva Gluschenko wrote:

    SG> Message of Cauã Moura Prado at Jul 5 13:30 ...

    CMP>> Software: ICQ 2003a
    CMP>> Threat: Login password can be bypassed locally

    SG> I maybe missed smth but does it mean ICQ 2003a and other mentioned
    SG> cache registered user's password regardless of yser's intention or you
    SG> guys just run your "exploit" just after valid user's session, so that
    SG> status might be changed back to online just before connection timeout
    SG> exceeds? I suppose, the latter.

    SG> As a matter of fact, it still can be considered an exploit, but timing
    SG> limitations must be documented properly. It's hard to believe you can
    SG> start ICQ session w/o having UIN's password because server will just
    SG> refuse to authorize that.

    SG> And, I'm afraid to ask, you notified vendors before releasing the
    SG> thing, didn't you?

    -- 
    Best regards,
    ca1
    

  • Next message: Matt Zimmerman: "[SECURITY] [DSA-343-1] New skk, ddskk packages fix insecure temporary file creation"

    Relevant Pages


    Loading