• XSS.stack #1 – первый литературный журнал от юзеров форума

Уязвимости в клиенте ICQ

Отслеживать
Great

Great

CPU register
Пользователь
Регистрация
13.11.2005
Сообщения
1 622
Реакции
6
Программное обеспечение AOL ICQ - потенциальная возможность для атак
b_toolbar.jpg

Core Security предупреждает относительно многочисленных уязвимостей в программном обеспечении AOL ICQ. ICQ Pro 2003b и ICQ панель для Internet Explorer содержат уязвимость, которая может быть использована для атак.
Программная ошибка в ICQ Pro 2003b разрешает специальные сообщения, которые могут вызвать переполнение памяти в куче, которое может быть эксплуатировано. Уязвимости обнаружена с помощью специальной fuzzing-утилиты. Согласно сводке уязвимостей, ICQ 5.1 и ICQ2Go! не подвержены этой уязвимости и Core Security предлагает обновиться до ICQ 5.1
Так же ICQ панель для Internet Explorer недостаточно контролирует входящие данные. Код скрипта, содержащийся в данных RSS, может быть выполнен в пределах локалького Internet Explorer. Это дает практически неограниченные правда на скачивание и запуск программ. Можно так же управлять различными настройками панели. Уязвимая версия - 1.3, версий с закрытой уязвимостью пока нет. AOL предлагает перейти на версию 1.2, не поддерживающую RSS и поставляемую с ICQ 5.1.
 
Ну хорошо, вот тхзническое описание

Technical Description - Exploit/Concept Code:

A heap overflow vulnerability was found in the ICQ Pro 2003b build #3916 IM client. The problem derives from the way the vulnerable client handles the length of a specific type of message received from other clients.

The ICQ protocol supports exchange of IM messages both using servers as well as with direct client-to-client connections, where data is sent without a need for an intermediate ICQ server to process it.

The vulnerability was tested using the client-server-client model, presenting a high-risk scenario since exploitation does not require the establishment of a direct client-to-client connection with the victim system. In the tested case, ICQ communications servers will pass malicious traffic to unsuspecting clients without inspecting it first and without enforcing strict sanity checks on the data fields.

To understand the technical description that follows, a few terms from common ICQ message communication terminology will be defined:

FLAP: A 6 bytes structure, used to identify the channel (login[1], connected[2], errors[3], logout[4], ...) for the packet being sent.

It also contains a sequence number and the length of the whole packet.

SNAC: A 10 bytes header used to identify the purpose of the packet. SNACs identify packet types through a family type (Word) as well as a SubType (Word).

TLV: Type-Length-Value, a container structure where the first two fields are a Type (Word) and a Length (Word), followed by the data.

LNTS: A null terminated string preceded by a word (Little Endian), indicating the length of the NTS, including the terminating null character.

The vulnerability is triggered when a specific packet is received by a vulnerable client on FLAP Channel 2, the channel in which most of the packets are sent during a successful connection.

There are 3 main types of messages at the time of exchanging data between ICQ clients when communicating through servers:
[Type 1] - Simple, plaintext messages.
[Type 2] - Messages, extended to support rtf, colors, etc.
[Type 4] - Utility messages, used for URLs, contacts, etc..

The issue resides inside a Type 2 message. Messages are stored inside the Channel 2 FLAP with a SNAC of family-type 4, subtype 6.

Here is the outlook of ICQ communications packet so far:
[FLAP channel 2
[ SNAC type 4 - subtype 6
[message type 2]
]
]

There are two other encapsulation layers within the described packet that need to be inspected in order to identify malicious data that could trigger or exploit the described bug. Inside the Type 2 Message, a TLV of Type 5 will include a set of information such as client capabilities and sequence numbers. These are split in different Sub-TLVs within the type 5 TLV (carried within a Type-2 message of SNAc type4, subtype 6).

There is one Sub-TLV in particular that we want to look at: TLV Type 0x2711.

TLV Type 0x2711 will hold, among other things, a Message structure that includes LNTs.

So, let's look at an updated version of the previous outline:

[FLAP channel 2
[ SNAC type 4 - subtype 6
[message type 2
...
[ TLV type 5
...
[TLV type 0x2711
....
[Message - LNTS ]
]
]
]
]
]

It is inside the TLV type 0x2711 where a LNTS field resides with the contents of the [Message]. AS explained above, the first word of a LNTS determines the length of the message, followed by a null-terminated string.

The ICQ Pro 2003b client does not perform any sanity check on this length field and does not compare it to the actual size of the 0x2711 TLV or the size of the entire received packet. Unlike with other packet fields, an intermediate server does not perform any sanitation on the contents of this field either and therefore passes potentially malformed data to connected clients, making a fully controllable attack vector available to using potentially malicious IM client programs.

The nature of the bug can be understood by attaching a debugger to the ICQ Pro 2003b client and tracing down the issue to find the problem inside a routine called “MCRegEx__Search”, which calls memset to clear the contents of a heap allocated buffer, directly using our length field (described above) as the third argument to the memset function. [4]

The following short disassembly should provide more detail:

First breakpoint is set inside ICQCUtl!ReadStringBCStreamFormat:

20002108 ff152cb00020 call dword ptr [ICQCUtl!MCRegEx__Search+0x89d4
(2000b02c)]{ICQRT!Ordinal360 (21382b39)} ds:0023:2000b02c=21382b39

The reason the initial breakpoint is set inside ReadStringBCStreamFormat is because MCRegEx__Search is constantly called from several different locations.

It is inside this routine that a call to ICQRT!Ordinal116+0x1af ends up calling memset and using our length value directly:

213821ea 0fbe442414 movsx eax,byte ptr [esp+0x14]
213821ef 53 push ebx (length specified in the LNTS)
213821f0 50 push eax (character being written, 0)
213821f1 8b4604 mov eax,[esi+0x4]
213821f4 034608 add eax,[esi+0x8]
213821f7 50 push eax (destination buffer)
213821f8 e8b5300000 call ICQRT!Ordinal116+0x1af (213852b2)

ICQRT!Ordinal116+0x1af is the stub for memset that contains a direct jmp to the msvcrt.
 
В клиенте ICQ (AOL ICQ 5.1) обнаружена критическая уязвимость, позволяющая злонамеренному пользователю выполнить произвольный код на целевой машине скрытно от жертвы.
Уязвимость кроется в функции DownloadAgent элемента управления ICQPhone.SipxPhoneManager.
Уязвимость устранена и в настоящий момент клиенты скачивают патч при входе в сеть.
 
А что на эта ICQ 5.1? Покажите мне человека, который пользуется им?
Щас по моему ICQ юзают только ламеры, которым по фиг, что использовать...

P.S. Миранда руль :crazy:
[mod][not null:] Личное мнение по поводу того, какой клиент лучше, в этой теме никого не интересует. В следующий раз получаешь минус[/mod]
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх