 |  |
https://bugtraq.ru/review/archive/1999/02-02-99.html |
|
|||
|
|
|
||
| https://bugtraq.ru/review/archive/1999/02-02-99.html |
||||
| ||||
2 февраля 1999, #61
Есть нечто завораживающее в наблюдении за статистикой. Плавное перемещение по ступенькам рейтинга, что может с этим сравниться? Разве что процесс перестановки разноцветных блоков в дефрагментаторе, круговерть гуппи в аквариуме...
Как вы поняли, я очередной раз о HackZone Team. Прогресс действительно впечатляющий, а что будет, когда развернется более активная рекламная компания - и подумать страшно... :)
Однако хотелось бы еще раз подчеркнуть - устанавливая клиента на чью-то машину, озаботьтесь извещением ее владельца, а то всякое бывает...
Писем сегодня будет много. Начнем с письма, пришедшего 2.02.99 в 23:31, а также прошедшего по листам BANNERS и EZHE
|
Наша сегодняшняя передача про то, как любой ребенок может за 3 (три)
минуты взломать баннерную сеть Russian Link Exchange
(http://www.rle.ru/) и остаться довольным.
Ура! Ура! Мы попали на аккаунт самих хозяев. В качестве развлечения добавили туда баннер Reklama.Ru, но не стали его включать. Теперь, ребята, вы можете с этим паролем (у вас он будет другой, так как он для каждого IP-адреса другой, зато универсальный) входить под АБСОЛЮТНО ЛЮБЫМ аккаунтом в RLE. Что Gold, что Common. Все равно, сладкие мои. Если у вас уже есть аккаунт в RLE, вы можете не регистрировать нового, а использовать зашифрованый пароль для входа к любому участнику. P.S. Домашнее задание для Кирюши из Петербурга: "Какая система самая дырявая?"
Спокойной ночи, малыши!
|
Небольшая предыстория. Суть проблемы в следующем: управление аккаунтом баннерной системы - штука довольно громоздкая, состоящая из многих форм - добавить баннер, подкрутить параметры показа, посмотреть статистику, настроить пресловутый таргетинг и т.п. Доступ к ней, естественно, запаролен. Дальше же начинается самое для нас сейчас интересное - как реализована система аутентификации, потому как взломанная баннерная сеть - лакомый кусочек. Как я писал в статье Ставим пароль на страницу, наиболее естественным было бы воспользоваться средствами сервера. В apache, например, после успешной авторизации имя пользователя лежит в переменной окружения REMOTE_USER, чем обычно и пользуются скрипты. Насколько я понимаю, именно этот механизм использует Rambler и система конференций WebClub'а
Ни одна из популярных баннерных систем этот подход не использует. Чем сие вызвано, желанием ли накрутить немеряной красоты дизайн вокруг формы для логина, или какими-то высшими соображениями, сказать сложно, но во всех системах мы встречаем аутентификацию средствами CGI. Ну, вольному-воля, как в свое время все программисты на С/С++ считали своим долгом написать свои собственные библиотеки для работы со строками, списками и окнами, так и для web-программистов любимое упражнение - написание гостевых книг и всяких парольных систем.
Но, возвращаясь к нашим баранам, система управления аккаунтом достаточно громоздка, и требовать от пользователя каждый раз на каждой странице вводить пароль не есть хорошо. Приходится его где-то хранить. Вариантов не так уж и много: в cookie хранить не совсем хорошо, потому как все-таки не все их разрешают, остается одно - хранить в hidden-поле формы. Во всех последующих вызовах скрипта значение пароля будет уже браться оттуда. Как не так давно заметил Кирилл Готовцев, REKLAMA.RU хранит пароли открытым текстом. Точто в такой же форме они хранятся и в InterReklame. Последняя при этом использует более опасный в данной ситуации метод GET, что приводит к передаче пароля открытым текстом в URL - а уж его вытащить из логов прокси совсем просто.
На этом фоне казалось бы сильно в лучшую сторону выделялась RLE, шифрующая пароль перед записью в поле, причем привязывая его к ip-адресу посетителя. Судя по внешнему виду, используется при этом стандартная функция crypt, дающая вполне приемлемый результат. Подобная реализация представляется мне наиболее надежной из перечисленных, но плюха, продемонстрированная в процитированном выше соообщении, портит все впечатление. Потеря при шифровании самого объекта шифрования - это очень серьезная потеря, как сказал бы Тру-ля-ля :)
Впрочем, все уже закончилось более-менее благополучно. Латание подобной дырки сводится к корректировке нескольких строчек кода, что, по сообщению Антона Воскресенского, и было проделано к двум часам ночи. Лично меня смущает фраза "Лица (сайты), воспользовавшиеся дырой, исключены из сети навсегда" - ведь на самом деле было понятно, что логи с сервера никуда не денутся, и подобные действия могут быть обычной подставой.
Дискуссию о соответствии морального облика авторов сообщения кодексу строителя капитализма и возможности их преследования в судебном порядке оставляю листу banners.
На Linux'овой улице праздник - выход ядра из новой стабильной серии - Linux 2.2. Версия 2.2.0 вышла в прошлый понедельник, но как и следовало ожидать, 2.2.1 не заставила себя долго ждать, и в четверг благополучно вышла.
Праздник и на улице пользователей русской NT - как-то незаметно подкрался 4-й ServicePack. Учитывая, что hot-fix'ы к русскому SP3 выходили далеко не все, его установка всячески рекомендуется. Что характерно, на русском сайте microsoft нет ни малейшего упоминания об этом факте. Вообще, пользователям локализованного ПО можно только посочувствовать. Скажем, упомянутая в прошлом выпуске дырка в Word'97, связанная с обходом запрета на выпоолнение макросов, если макросы находятся в прилинкованном шаблоне, лечится патчем, требующим установки Office'97 Rervice Release 2, о котором на русском сайте ms уж который месяц пишут, что вот-вот будет доступен. А дырка, между прочим, не просто опасна, а очень опасна. Штука в том, что в Word'97 имя шаблона может быть указано в виде URL, да и Internet Explorer при щелчке на doc-файл норовит открыть его непосредственно в Word'е без всяких вопросов. А в макросах можно ой как много всего написать...
Ну и для кучи - об очередном баге IE4. Если добавить к некому URL строчку типа %01someURL, IE посчитает, что документ загружается с домена, указанного в someURL. Нсколько примеров использования: передача файла на сервер, "window spofing" - попадаем на "враждебный сайт", адрес же указывает на сайт, которому мы доверяем, считывание autoexec.bat с помощью ActiveX-компонента.
С письмами вообще нынче беда. Понемногу возрождается традиция сообщать всем знакомым о появлении страшного вируса "Join the Crew" или "Penpals". И как объяснить простому честному юзеру, в чем разница между ним и таким вот письмом (переправил Олег Моргунов, было разослано пользователям ИнтерСвязьСпутника):
|
Вас приветствует группа разработчиков Microsoft Windows! Мы рады сообщить, что неполадка в системе защиты Microsoft Windows УСТРАНЕНА!!! Достаточно один раз запустить прилагаемый к письму файл UPDATE.EXE. После того, как вы его запустите, библиотека winsock32.dll будет обновлена до версии 2.5. В этой обновлённой версии библиотеки устранена возможность "нюка" и "флуда" , а также доступа ко ВСЕМ ресурсам пользователя Microsoft Windows (таких как информация на жёстких дисках, пароли и другая важная информация). По всем вопросам обращайтесь: UpdateService@hotmail.com Надеемся, что это обновление обеспечит стабильную работу в среде Microsoft Windows. |
Или очередным Happy99? Только убедишь - и на тебе, подарочек в чем-нибудь хтмльно-вордовом. Нет в жизни щастя...
Хвосты от прошлого выпуска. По поводу идентификатора у SPARC'ов меня поправило сразу несколько человек. Спасибо всем откликнувшимся, приведу здесь самое первое письмо:
|
Hi. На тему идентификатора спарков. Похоже речь идет не об идентификаторе процессоров ( ну номера они на них печатают конечно, но вот упоминаний про что-либо "зашитое" в сам кристалл я не видел ), а о Sun-овском HOSTID. С hostid же все просто. Во-первых hostid - производная от onboard ethernet hw адреса. То есть если ether=8:0:20:ab:cd:ef, то hostid равен 80abcdef. Во-вторых hostid прошит не в нестираемом ПЗУ, а в перезаписываемой памяти EEPROM. Выполнено в виде заменяемой микросхемы на процессорной плате. С батарейкой. В-третьих перепрошивается на раз. Так что с интелями перекликается, насколько я понимаю, слабо.... P.S. стоит еще упомянуть, что собственно сами кристалы для Sun печатает Texas Instruments, также этим занимались Fujitsu. P.P.S. а ранние саны вааще были на интелях ( 386 ) и моторолах. Так что привязки к процессору по его номеру похоже изначально не подразумевалось ( SunOs 4.x гоняется на старых сановских тазиках с любым из трех камней ).
|
Возразить тут особо нечего, но все-таки всеобщая истерия вокруг идентификатора в Pentium III представляется мне чрезмерной.
И к сообщению о дырке в Lotus Notes.
|
День добрый! Маленкое замечание к сообщению Александра Гусева о дырке в Notes. Дырка наверное есть, да и вообще Notes лучше не обсуждать - одна большая бага. По моему мнению, во всяком случае. Дело в другом. Александр пишет: "Против этого вида атаки бессмысленно защищаться с помощью брэндмауера" Любой приличный firewall не только фильтрует пакеты ip, udp, tcp согласно некоторым правилам, но и контролирует содержание пакетов наиболее распространенных протоколов. Содержимое пакетов SMTP проверять велел сам бог. Иначе, я думаю, завалить можно любой почтовый сервер, посылая на 25 порт большое количество всякой дряни. И Notes оказался крайним по банальной причине: он и так еле живой. Протокол SMTP достаточно прост. В реальной жизни работает еще более простое подмножество этого протокола. Нет никакой технической сложности в анализе на firewall'е команд на 25 порт и проверки на соответствие синтаксису SMTP. Причем синтаксису более строгому чем "полный" SMTP. Firewall анализирует поступающие команды SMTP и просто не пропускает "подозрительные". Серверу передающему не остается ничего иного, как пользоваться самым простым подмножеством SMTP команд, так как ему кажется что других принимающий сервер просто не понимает. Это вполне не противоречит RFC, описывающему SMTP. Именно способностью анализировать пакеты прикладного уровня firewall отличается от обычного пакетного фильтра. Отвечаю за то, что SMTP подробно разбирается Cisco PIX Firewall. При этом
это животное делает это само. Мне, например, не удалось добиться того, чтобы
он этого не делал :) При этом он не стесняется писать в Log все
подозрительные SMTP команды. Надо отдать ему должное в том, что: все
"подозрительные команды" действительно подозрительны.
|
Пара сообщений от Сергея Пустовойтова. Первое касается инструкции по взлому hotmail. Всего-то и надо - послать со своего hotmail-аккаунта письмо на master_get_pass@hotmail.com с адресом, для которого хочется узнать пароль, и своим паролем :). Интересно, много ли лох... эээ... желающих нашлось?
Второе - взлому официального сервера FIDE, предположительно произшедшего 1 декабря. По крайней мере, на сайте висит гордая надпись "Note: This site was damaged by hackers and is under repair". Непонятно - то ли правда, то ли попытка оправдать убогий дизайн...
Напоследок - новость, которой поделился Евгений Ильченко. Дырка, затрагивающая большинство существующих ftp-серверов и ftp-клиентов, подключающихся в пассивном режиме, получила название "Pizza Thief". После получения запроса на такое подключение, сервер открывает порт для передачи данных клиенту, и в этот момент к нему может подключиться любой клиент, а не только тот. что посылал запрос. Тот, кто успеет первым, и получит всю информацию. Хотя конечно еще надо угадать номер искомого порта, но и это теоретически возможно после анализа статистики ответов сервера.
У вас есть новость или ссылка, заслуживающие внимания наших читателей ? Пишите.
| « | » | |
|
|
|