На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Другие методы взлома UNIX-ob

Отдельные ACCOUNT bi
Это большая дыра в защите многих UNIX-систем. В общем слу­чае, если пользователь отсоединяется, предварительно не предупре­див систему об окончании работы его Account может остать­ся на линии и, тихо присоединившись к этой линии, можно получить доступ к системе напрямую. Теперь, если кто-то вызывает систему и присоединяется к этому tty, он автоматически оказывается внутри системы и получает Account от предыдущего пользователя. Имеются некоторые интересные способы использования этого недостатка.
Для примера, если вы желаете получить пароли других пользо­вателей, вы можете сделать и установить программу-ловушку, эмули­рующую login этой системы, и отсоединиться. Затем какой-то пользо­ватель подсоединяется к этому каналу и в ответ на запрос вашей про­граммы вводит свои username и password. Программа-ловушка запо­минает полученные данные на диске, выдает сообщение «Login incor-rect», убивает shell и пользователь получает реальный запрос «login»:
UID SHELLS.
Когда бит «UID» поставлен у программы-оболочки (shell), ее выполнение изменяет ваш user id на user id владельца этой программы,
и вы будете использовать полученный acccount, пока не выйдите из этой вторичной оболочки. Это дает вам возможность исполнять лю­бые команды под user id полученного account'a. Это чем знание пароля для account'a, вы можете пользоваться account'oM, пока существует этот файл в системе, даже если владелец сменит пароль. Обычно, когда получают доступ к account'y, делают копию shell в ка­кой-то директории и ставят UID и GID биты. Теперь, если доступ к этому account'y потерян, можно из другого запустить и по­лучить необходимый доступ.
UID и GID биты ставятся программой chmod. Например: chmod 6555 /tmp/sh
Изменение UID программ
Если вы имеете доступ по_записи (write access) к UID файлу, то
можно легко превратить его в оболочку. Скопируйте файл, затем набе­рите:
cat /bin/sh >  [uid файл]
Это заменит его содержимое на содержимое shell, но UID оста­нется прежним. Теперь запустите замененную программу, сделайте скрытый UID shell и верните UID файл в прежнее состояние из копии.
Как найти рутовские файлы с suid? Попробуйте:
find / -user root -perm -6000 -print
Срыв стека
Вот поистине самая новомодная методика взлома UNIX. В программах, написанных на языке С, под массивы отводится место в стеке программы. Если при работе с таким массивом происходит за­пись в массив за его границей, это приводит к разрушению стека про­граммы и непредсказуемым результатам. Например, при выходе из мо­дуля происходит переход по случайному адресу.
Переполнение стека приводит к изменению адреса возврата из функции и может быть использовано для изменения нормального хо­да выполнения программы. Логично было бы заставить программу вы­полнить какие-то незапланированные действия, например, запустить (spawn) shell. Но если в программе не содержится необходимого кода? Как поместить необходимый код в адресное пространство инструк­ций? Необходимо поместить код для выполнения в переполняемый
буфер и переписать адрес возврата на точку внутри этого буфера.
Код, при выполнении которого происходит запуск shell, получил
название «Shell Code». Если программа, из которой происходит запуск shell проинсталлирована как      root, то получается root shell.
Поиск программ с возможностью срыва стека
Как было сказано выше, переполнения буфера происходят из-за помещения в него большего количества информации, чем предполага­лось. Так как язык С не имеет каких-либо встроенных средств для про­верки границ массивов данных, переполнения встречаются часто.
Стандартная библиотека С предоставляет ряд функций для копирова­ния и конкантенации строк, и эти функции не имеют проверок границ. Вот некоторые из этих функций: strcat(), strcpy(), sprintf() и vsprintf(). Эти функции используют строки, заканчивающиеся символом «\0», и не проверяют на переполнение при обработке принимаемой строки. gets() — это функция, которая считывает строку со стандартного вво­да (stdin) в буфер до тех пор, пока не встретит символ новой строки или EOF. Эта функция не производит проверки на переполнение бу­фера. С семейством функций scanf() может возникнуть такая же ситу­ация, если в строке формата используется и принимающая стро­ка недостаточно велика. Если принимающий массив какой-нибудь из этих функций представляет собой буфер постоянной длины и данные,
его заполняющие, каким-либо образом зависят от ввода или другой информации, зависящей от пользователя, то скорее всего вы можете вызвать ситуацию переполнения буфера.
Другая, часто использующаяся при программировании конст­рукция, это цикл посимвольного ввода из stdin или другого файла в буфер до тех пор, пока не будет встречен символ конца строки (EOL), конца файла (EOF) или другой разделитель. В такой конструкции обычно используются функции getc(), fgetc()ran getchar(). Если при этом нет проверок на переполнение, то в таком коде тоже легко можно вызвать переполнение буфера.
Программа grep играет значительную роль в поиске таких сла­бых мест в программах. Исходные тексты свободно распространяемых операционных систем вполне доступны. И этот факт становится весь­ма интересным, учитывая то, что многие коммерческие операционные системы базируются на исходных текстах свободно распространяемых систем. В общем, изучайте исходные тексты UNIX!
Ломаем ГГР-сервер
Оказывается, сломать FTP-узел гораздо легче, чем запихнуть медведя в консервную банку. Для этого используется обычный cgi скрипт, а вернее ошибка в нем, так называемый PHF BUG. С 1996 года (а именно тогда был обнаружен баг) почти ни один FTP-узел не по-фиксил эту ошибку. Ну и хорошо... нам же лучше. Включаем IRC кли­ент и коннектимся к любому серверу.
Но он нам нужен не для болтовни... Обычно самые протухшие и окаменевшие сисадмины водятся университетских сер-
верах типа *.
Так вот... мы берем и в командной строке нашего IRC клиента
вводим /who *. edu, где * — это имя университета. Але-оп! И перед то­бой милый списочек юзеров, юзающих этот университетский сервак.
Далыпе - больше... Выбираем кого-нибудь, например, юзера под име­нем Lama-Doma@lama-doma. lox. fuu. ganduras. edu:2. lama-doma-lox и пишем /dns Lama-Roma. Этим мы узнаем его IP, например, 123. 456. 789. 6. Дальше берем программу «Grinder» с ftp. technotronic. com. Она позволяет найти любой файл в заданном диапазоне IP-адресов. Так вот, после этой команды мы видим IP Lama-Dom'bi. Запускаем Грин-дера. Он предлагает нам найти index, htm, но нам он нужен, как холо­дильнику пепельница. Ищем /cgi. bin/phf. cgi в диапазоне от 123. 456. 789. О — 123. 456. 789. 256, то есть в диапазоне Айпи, в котором может оказаться наша жертва.
Если Гриндер написал URL FOUND, тогда запоминаем Айпи,
где был найден этот кусок cgi скрипта. Допустим, это 123. 456. 789. 3.
И ТЕПЕРЬ БЕЖИМ к броузеру и пишем там
http://123.   456.   789.   3/cgi-bin/phf?Qalias=%off/bin/ cat%20/etc/password
И, как по мановению волшебной палочки, перед нами в окне бра­узера файл с паролями всех юзеров! Сохраняем его у себя на винте, а потом качаем любой взломщик Юниксовских паролей (самый классный — это John The Ripper, в любой поисковой машине миллион л инков на него достанешь) и ломаем... И вот, берем вскрытые пассы и бежим на ftp сайт этого университета, и входим туда не под логином ANONIMUS, а под логином/паролем, достатым такими титанически­ми усилиями. Теперь нам доступны ВСЕ файлы, которые там есть, в том числе и защищенные...
О том, для чего все это делается...
Вечером 8 декабря 2001 года была взломана защита на одной из самых популярных справочных систем Yahoo. Хаке­ры пригрозили глобальными разрушениями компьютерных систем, если их требования не будут удовлетворены.
При этом, возможно, только несколько тысяч людей в те­чение нескольких минут смогли видеть обращение хакеров. По заверениям Дианы Хант (Diane Hunt), представительницы
Yahoo, содержимое сервера поисковой машины было остав­лено в неприкосновенности, да и компьютерные системы мира остались незатронутыми, по крайней мере, пока.
Некто неизвестный вторгся в систему Yahoo около 7 вечера 8 декабря. «У нас имеется система мониторинга безопаснос­ти сайта, которая немедленно сообщила нам о случившим­ся», - сообщила Хант. Администраторы Yahoo незамедли­тельно приняли соответствующие меры, и уже в 7.15 страни­ца была полностью восстановлена. Хант сказала, что никакие файлы не были разрушены и обращавшиеся извне компьюте­ры не подверглись поражению компьютерным вирусом, обе-щенному взломщиками.
По соображениям безопасности, она не сообщила, каким
образом защитный барьер Yahoo был прорван, но повторила,
что всего несколько тысяч людей могли наблюдать это напа­дение.
Большинство «жителей» Сети не могли видеть результаты хулиганских действий, потому что содержание текста, поме­щенного хакерами на заглавную страницу Yahoo, было доступно только для тех, кто использовал браузеры, которые не поддерживают фреймы. Те же, кто работал с браузерами Netscape 2.0, Internet Explorer 2.0 и более старшими их верси­ями, не могли видеть текст воззвания атаковавших.
Лишь те, кто использовал для просмотра «Всемирной Пау­тины» очень старые браузеры Netscape или другие, типа Lynx, могли видеть посланное сообщение (в течение некоторого времени на прошлой неделе оно было доступно по URL http://www.clipper.net/~skully/yahoo/, но затем, сославшись на перегруженность сервера, доступ к нему закрыли).
Сообщение гласит, что компьютер каждого, кто посетил Yahoo в течение предшествующего месяца (Yahoo сообщает, что сайт имеет около 26 миллионов обращений отдельных
пользователей в месяц), был инфицирован «логической бом­бой/червем». Подобный сценарий считается практически не­возможным. Но многие из невозможных сценариев, типа ви­русов, передаваемых по e-mail, в своих странствиях по Сети, случается, уничтожают большие компьютерные системы.
Хакеры пообещали, что «бомба взорвется» на Рождество,
сообщение гласит, что «значительный ущерб будет нанесен
компьютерным сетям всей планеты». Затем, конечно, пред­лагается решение созданной ими проблемы: выпустите хаке­ра Кевина Митника (Kevin Mitnick) из тюрьмы, и программа-антидот, «находящаяся на компьютере где-то в южном полу­шарии», будет выпущена. В заключение Диана Хант подчерк­нула, что ни один из персональных компьютеров не был инфи­цирован, а сам вирус — просто трюк. Такое же мнение выра­зил и Рене Виссе (Rene Visser) — технический специалист ан­тивирусного центра Symantec Corporation. Он сообщил, что данная проблема Yahoo была исследована, при этом вирус не
был обнаружен.
Информацию о заражении сервера он считает обманом.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика