https://bugtraq.ru/review/archive/1999/20-05-99.html

20 мая 1999, #72

Старое доброе правило - стоило один раз расслабиться, и вот уже очень сложно возвращаться в нормальный рабочий ритм. Слабым оправданием может служить то, что я не совсем уж бил баклуши эти две недели, и за это время были подготовлены и выложены web-версии всех номеров бумажной HackZone за прошлый год, а также полный текст книги "Атака через Internet", выход второго издания которой ожидается летом.

Тем, кто еще не совсем оправился от 26 апреля, и у кого по каким-то причинам не сложилось с tiramisu, стоит попробовать MRecover - правда первый раздел будет восстановлен, только если на нем была fat32. В вышедшей сегодня версии обещана поддержка linux'овых разделов.

За ссылку спасибо b o n o.

Вышла и очередная версия Jammer'а. Несмотря на то, что в NT фильтрация трафика по-прежнему не работает (хотя и обещается в будущих версиях), отслеживание изменений в наиболее критичных участках реестра (помимо традиционных Run, RunOnce отслеживается и ICQ Launch List) вполне работоспособно, равно как и вывод списка процессов и netstat. В будущих версиях планируется и слежение за файлами/каталогами (за тем же autoexec и Startup). В общем, пользователи Win'9x уже сейчас могут выкидывать NukeNabber :)

Как вы уже, наверное, знаете, вышел очередный, пятый Service Pack для NT. Hot-fix'ов к момменту его выхода накопилось всего-то ничего, однако полторы сотни исправлений он все-таки содержит. Каких-то нововведений в нем не замечено.

А еще в конце апреля NT4.0+SP3 была сертифицировна в Англии по классу E3/FC-2 - по словам MS, это высшая из возможных оценок защищенности операционной системы общего назначения. Заявляется, что это примерно эквивалентно американскому классу C2, оценка на соответствие которому обещается в ближайшее время. Интересно, помнится, в последний раз сертифицировалась NT3.5 (или 3.51?), отключенная от сети...

Да, тут на днях к этой самой сертифицированной системе вышла заплатка, исправляющая ошибку в WinHelp - при слишком длинном имени cnt-файла у программы случалось банальное переполнение буфера, позволяющее выполнить некий код.

Ну а здесь лежит руководство "Building a Windows NT bastion host in practice". Скрипт и утилиты прилагаются.

Как недавно выяснилось, ICQ хранит свои пароли в совершенно открытом виде. А здесь уже лежит готовая утилита для их вытаскивания - ICQ Password Revealer. Кроме этого, на той же странице лежит некое расширение для ICQ, реализующее шифрование сообщения открытым ключом - Top Secret Messenger for ICQ. Длина ключа в незарегистрированной версии ограничена 8 битами. Авторы последовательны и для демонстрации слабости этого ключа прилагают программу DecryptIt, взламывающую ее простым перебором :)

Ссылку прислал Мурик.

За время, прошедшее с моего последнего упоминания, сильно обновился сайт Криса Касперски, заодно переехавший на новый адрес. На сайте выложены книги "Философия и технология хакерских атак" и "Образ мышления IDA". Здесь же объявлен очередный конкурс из серии crackme, анонсировать который я, боюсь, уже опоздал, поскольку трио победителей уже определилось.

Ссылки на пару любопытных статей прислал Алекс Фарбер. Первая посвящена размещению люков (backdoors) за файрволами (aka сетевыми фильтрами), вторая - анонимизации unix-систем (т.е. защита пользовательской и системной информации от постороннего нескромного взгляда). Обе статьи - плод творчества немецкой группы The Hacker's Choice (также на сайте: еще несколько статей, утилиты, исходники, четыре номера THC Magazine).

Возможно, вы уже пользовались так называемыми bookmarklets. Ссылки под рукой сейчас нет, но идея там в следующем: среди закладок сохраняется url вида "javascript:", и дальше идет небольшой фрагмент кода, который может, к примеру, поменять размер окна броузера (любимые кнопки: 800, 1024, Full), перекинуть поисковику выделенный текст и т.п.

Так вот, выяснилось, что эти скрипты рассматриваются обоими ведущими броузерами как исполняющиеся в контексте текущих выбранных доменов и протоколов, и в случае, если таковыми оказались file://..., могут получить доступ к локальным файлам. Демонстрации: для NN, для IE.

Аналогичные проблемы возникают у Netscape, если в закладки помещена страница с тегом <script> внутри <title></title>.

На 4 июня запланирована международная акция протеста "Free Kevin". Международной она стала после подключению к проекту России: подготовкой демонстрации с соответствующими лозунгами перед американским посольством в Москве занялась Гражданская Школа Хэкеров. Организационная встреча назначена на следующий вторник, 25 мая. Интересно, много ли найдется желающих, и знают ли американские дипломаты, кто такой Кевин Митник?

Бьюсь об заклад, что большинство из вас никогда не слышало об электронном журнале BoW (Brotherhood of Warez). Восемь его выпусков вышло с 1992 по 1994 год, и вот на днях случился девятый номер. Непривыкшим к стилю речи "Y0!@#!$$%^&^%$! L1st3n up ph3ll0w BoW du0dZz, it'z Th3 V3lkr0 K0d3 W4rr10r h3r3" будет весьма затруднительно прочитать процентов 80 его содержания :)

Сравнительные тесты - заразная штука. После предыдущего обзора, где речь шла о mindcraft'овских тестах NT и Linux, пришло письмо от Дениса Танаева, в котором он рассказывал о результатах небольшого сравнительного тестирования IIS и Apache/Win32 в конфигурациях по умолчанию, показавшего весьма приличное отставание последнего.

ZD WebBench. 5 клиентов, 1 сервер. Celeron-333,124,6.4 Quantum. Клиенты - NTW, сервер- NTS (NT Server). Вышло что, когда IIS и апач по производительность вышли на прямую линию, то оказалось что IIS делает апач в 3 слишним раза со счётом 245:80 (реквестов в секунду). Конечно это тест неправильный, апач под NT это не апач, но... Предположим, что нормальный tuning IIS`а позволит увелисить производительность на 50%, ну ладно, на 30%. Разве апач под Linux работает в 4 с лишним раза быстрее чем он же под NT? Я как-то в этом сомневаюсь... Хотя чем чёрт не шутит... Но всё равно мне в это верится с трудом. т.е. мне так кажется, что IIS и апач под линукс находятся на равной планке для равных систем начального уровня... т.е. могут быть расхождения в производительности процентов в 20, но это будут просто флуктуации.... А вот системы высшего уровня... Там вообще ни линуксу ни NT делать нечего.

Время, с	Запросы		Запросы/с
	Apache	IIS	Apache	IIS
1	0	19	0	19
2	1	96	1	77
3	2	172	1	76
4	2	246	0	74
5	3	322	1	76
6	4	398	1	76
7	4	475	0	77
8	5	549	1	74
9	6	626	1	77
10	48	702	42	76
11	111	779	63	77
12	175	853	64	74
13	238	929	63	76
14	299	1005	61	76
15	361	1082	62	77
16	423	1156	62	74
17	487	1232	64	76
18	550	1309	63	77
19	610	1386	60	77
20	673	1458	63	72

Меня это, само собой, заинтересовало, и результаты этого интереса вы можете наблюдать в таблице сбоку и трех графиках внизу. Сети и ZD WebBench, правда, под рукой не оказалось, писалось на коленке, ну и Peer Web Services из NTWS как бы не совсем IIS, а посему сравнивать с результатами Дениса это было бы не совсем корректно.

В таблицу сведены результаты работы perl-скрипта, тупо запрашивающего килобайтный файл с локально установленного web-сервера (PII-450, 128RAM, NTWS+SP5, Peer Web Services из поставки, Apache/Win32 1.3.4, настройки по умолчанию). Эти же результаты изображены на первых двух графиках. Как видно, перевес сохранился, но он уже не столь впечатляющий - всего-то процентов 30 (возможно, последние версии Apache все-таки получше оптимизированы, а может быть, PWS все-таки существенно отличается от IIS). Правда процесс становится установившимся только после десятой секунды непрерывных запросов, на первых же секундах превосходство IIS просто подавляющее (что как раз гораздо важнее для серверов со средней нагрузкой - для справки, текущий не самый маленький трафик hackzone соответствует примерно полутора запросам в секунду).

Потом мне захотелось посмотреть, как поведут себя подопытные с запросами от нескольких клиентов. Для этого была написана небольшая программка на C++, использующая стандартные MFC-шные классы CInternetSession и CHttpFile, и запускающая цикл с запросами в нескольких потоках (многопоточность на однопроцессорной машине штука весьма относительная, но при небольшом количестве потоков эффект все же был заметен). Результаты оказались не столь показательны. Во-первых, эффективность программы при работе с одним потоком оказалось раза в полтора меньше, чем у perl-скрипта, что говорит о качестве MFC-кода (не скажу, что я полностью исключаю собственные кривые руки, но кода, работающего собственно с http, в программе всего пара строк, и я не представляю, где тут можно было напороть). Во вторых, при работе с одним потоком разница между серверами практически сошла на нет, зато при росте количества потоков Apache опять стал уступать.

Такие дела. Похоже, что говорить о реальном использовании Apache/Win32 пока еще рано - разве что в отладочных целях.

1. X - время, Y - запросы


2. X - время, Y - количество запросов в секунду


3. X - количество потоков, Y - среднее количество запросов в секунду

У вас есть новость или ссылка, заслуживающие внимания наших читателей ? Пишите.

«		»