![]() |
Взлом Web 2.0: проникновение в Intranet, определение IP
Cпециалисты сошлись во мнениях: сегодня безопасность корпоративных сетей находится под большой угрозой, хакерам удалось проникнуть за периметр локальных сетей. На сей раз из боевого арсенала они выбрали наиболее уязвимое звено в безопасности – веб-приложения. По данным Web Application Security Consortium, исследования 2006 года показали, что более чем 85% веб приложений уязвимы к атакам XSS: http://img257.imageshack.us/img257/2764/web1qa2.png Статистика не рисует радужных перспектив для пользователей, в тоже время она не может не радовать хакеров. Используя XSS, хакеры могут внедрять свой код на чужие сайты с целью хищения данных клиентов. Помимо уже популярных сценариев с кражей личных данных, номеров кредитных карт, и т.д., сегодня стали популярными схемы проникновения в корпоративные сети клиентов средствами одних только веб технологий. Комбинации из PHP, JavaScript и Java превращают невинные веб-ресурсы в капканы для внутренних сетей больших корпораций. Именно об этом мы сегодня и поговорим… Проникновение с использованием веб-технологий накладывает на нас определенные ограничения в выборе методов для атаки, а заложенная в них специфика требует применения изощренных техник. В ближайших статьях мы рассмотрим сценарии проникновения в корпоративные сети, сканирование сети и атаки на внутренние веб-сервера. А в этой части поговорим исключительно про определение характеристик внутренней сети. Эти данные окажутся нам полезными на втором этапе проникновения – сканировании сети. Итак, наша цель определить - внутренний IP-адрес клиента, чтобы в дальнейшем иметь представление о маске сети. Допустим, что сотрудник компании зашел на страницу хакера: http://www.hacker.com/go2intranet.php . Первое и самое простое, что мы можем узнать о клиенте – это его внешний адрес. Внешний адрес Авторизация пользователя на сервере может осуществляется по многим критериям, это может быть идентификатор сессии в HTML-коде, содержимое данных cookie или же внешний IP-адрес клиента. В зависимости от задачи, разработчики выбирают наиболее подходящий им метод, но, независимо от этого, веб-сервер предоставляет им все имеющиеся данные. Для злоумышленника, в данном случае, представляет интерес внешний адрес клиента, который можно легко узнать средствами языка PHP. В PHP собранная сервером информация хранится в массиве $_SERVER, сюда входят данные о самом сервере, активной странице и, собственно, о клиенте. Конкретно адрес клиента хранится в переменной REMOTE_ADDR, и если вы посетили страницу хакера, последний без труда вычислит ваш внешний IP: PHP код:
REMOTE_ADDR: 20.20.20.20 REMOTE_PORT: 37938 REMOTE_HOST: proxy.isp.com Но что нам дает эта информация? Если разобраться, то не так уж и много. Для атаки на внутреннюю сеть этих данных менее чем достаточно, ведь внешний IP скорее всего не имеет никакого отношения к компании. Вероятнее всего, адрес принадлежит компании, предоставляющей доступ в Интернет… В самом простом виде схему подключения корпоративного пользователя можно представить как цепь из 4-х систем: http://img170.imageshack.us/img170/2772/web2ma0.png Не считая систему клиента и сам веб-сервер (30.30.30.30), у нас остаются два участника: внутренний сервер компании и внешний сервер провайдера, предоставляющий доступ в Интернет. В прошлом примере мы узнали внешний адрес клиента, но это не его внутренний IP, это, вероятнее всего, адрес прокси-сервера провайдера. Можно делать догадки и точно определить его принадлежность, но такое расследование выходит за рамки этой статьи, мы же будем считать, что 20.20.20.20 - это сервер ISP. На этом наши поиски не закончились, продолжим изучать переменную $_SERVER. Маршрут Кроме уже описанных данных, в переменных сервера могут храниться заголовки X-Forwarded-For и Via. Они являются служебными и формируются промежуточными серверами по мере транспортировки запроса. Эти поля в последующем используются для идентификации клиента, пославшего запрос, чтобы потом доставить ему ответ сервера. PHP код:
В результате мы получили: X-FORWARDED-FOR: 192.168.10.5, 10.10.10.10 VIA: 1.1 proxy.intranet.com(squid/2.6.STABLE9), 1.0 proxy.isp.com(squid/2.6.STABLE9) Эта информация уже более существенная, в ней даже присутствует локальный адрес клиента. Объединим полученные данные и посмотрим, что у нас получилось: http://img211.imageshack.us/img211/1178/web4or0.png Теперь, нам известно, что proxy.isp.com действительно принадлежит провайдеру. Если посмотреть на значение VIA в заголовке, то видно, что пакет проходит через proxy.intranet.com, а уже потом через proxy.isp.com. Также можно добавить, что обе прокси работают по порту 3128 и используют squid 2.6. Опираясь на значение X-Forwarded-For, мы определяем локальный адрес клиента (192.168.10.5), поскольку proxy.intranet.com лежит в той же подсети, его адрес будет 192.168.10.ХХ. Корпоративный прокси предоставляет доступ в сеть провайдера, в его подсети он имеет адрес 10.10.10.10. Больше про сеть провайдера мы не можем ничего сказать, но это и не важно, ведь наша - цель проникновение в корпоративную сеть. Итак, мы нашли адрес клиента и имеем некоторую информацию о маршрутизации Интернет-трафика. Все наши сведения получены с помощью данных, хранящихся в заголовках запросов, но часто пользователи или провайдер пытаются скрыть эту информацию и блокируют передачу таких данных… Java applet В тех случаях, когда прокси обрезает эти заголовки или хакер не имеет доступа к серверной стороне (например, если его скрипт внедрен в чужой сайт), вышеописанная техника не будет эффективной. Но если у клиента установлена виртуальная машина Java, хакер может создать специальный апплет и уже с его помощью определить локальный адрес клиента. Впервые этот способ был продемонстрирован еще в 2002 году. Lars Kindermann, автор идеи, тогда даже не подозревал, насколько востребованным может стать его решение в будущем. Идея программы заключается в том, что Java-код, находящийся на сервере www.hacker.com, создает подключение к самому себе. В результате создается экземпляр класса java.net.socket, в котором хранится сетевая информация о клиенте: Цитата:
Цитата:
http://img169.imageshack.us/img169/7479/web5ho6.png На практике он может делать специальный запрос на веб-сервер, чтобы передать полученные данные хакерскому скрипту. Далее мы рассмотрим комплексное решение по определению клиентского IP-адреса, поэтому обработку данных оставим на потом. Следует заметить, что прокси или антивирус может блокировать активное содержимое, в таком случае следует применять обфускацию кода. Тэг апплета можно добавлять в документ на лету, используя JavaScript: Цитата:
Цитата:
Firefox и Java У хакера есть еще вариант определить локальный IP клиента. Один из способов получить нужные нам данные - это использовать возможность доступа к java-классам из JavaScript в браузере Firefox. Такую особенность имеют также Opera и Netscape, первые сигналы о беде поступили еще в 2003 году, именно тогда были продемонстрированы примеры создания сокетов и чтения локальных файлов с использованием API ява-классов из JavaScript. Для определения локального адреса клиента, как и в последнем примере, создается подключение к серверу через класс java.net.Socket, но уже из JavaScript: Цитата:
Цитата:
Cross Site Tracing Вернемся к заголовкам X-Forwarded-For и Via. Бывают такие случаи, что хакер не имеет возможности использовать PHP (или любой другой скрипт на стороне сервера). Такое может произойти, если он внедряет код на чужой сайт через ХSS, а формировать запросы к посторонним адресам не является возможным. В этой ситуации единственное доступное средство для хакера – JavaScript. Атакующий может использовать объект XmlHttpConnection, для того чтобы делать POST- и GET-запросы на взломанный им сервер. У него также есть возможность добавлять свои заголовки в запрос, но X-Forwarded-For и Via генерируются прокси-сервером, а поэтому на момент подключения они неизвестны и доступны только веб-серверу. Как же узнать, какие данные получает сервер? Ответ на этот вопрос лежит в документации HTTP-протокола. Как описано в стандарте, помимо методов POST и GET, существуют и другие. Некоторые из них можно встретить лишь на бумаге, но есть и такие, которые могу помочь нам с решением данной задачи. Для диагностических целей консорциумом был утвержден метод TRACE. Если сервер получает TRACE-запрос, он должен вернуть его клиенту как ответ. Использование этого метода в хакерских целях получила название XST (Cross site Tracing), который изначально использовался для чтения данных Cookie с флагом httpOnly. Хакер уже писал об этом, и вы можете самостоятельно с ней разобраться. До недавнего времени считалось, что уже нет возможности к его применению. Но в январе 2006 года Amit Klein опубликовал в Интернете пример его успешного использования: Цитата:
В результате responseText содержит полный текст нашего запроса, который можно легко извлечь, чтобы получить исключительно нужные нам значения: Цитата:
Цитата:
|
Flash XMLSocket Практически все программные средства, доступные из браузера, используют его настройки при сетевом обмене данными. Поскольку прокси-сервер настраивается в нем же, то все подключения должны делаться через него. Так оно и есть, за исключением некоторых объектов, которые игнорируют прокси сервер. Один из таких объектов - XMLSocket, реализованный во Flash. Объект XMLSocket используется для обмена данными между Flash-приложением и сервером без использования прокси. Его реализация имеет ряд ограничений, самое существенное из которых - это требования к порту подключения. В целях безопасности номер порта должен быть больше 1024, поэтому у хакера должна быть возможность его прослушивать со стороны сервера. Также стоит заметить, что на сервере должен находиться файл policy.xml, позволяющий подключение по выбранному порту. В самом простом варианте он должен иметь следующее содержание: Цитата:
Цитата:
Metasploit Decloaking Engine Очень хорошее решение нашей задачи предложил проект Metasploit. Демонстрация использует несколько вариантов тестирования, чтобы более точно определить сетевую конфигурацию клиента. Самое интересное в этом решении - это определение DNS-сервера провайдера, предоставляющего доступ в Интернет. http://img66.imageshack.us/img66/9263/web7te3.png Идея достаточно проста и основана на специфике в реализации работы DNS. Когда клиент пытается подключиться к удаленному хосту xxx.hacker.com, ему необходимо определить IP-адрес для подключения. Для этого он посылает lookup-запрос к своему локальному DNS-серверу. Последний, в свою очередь, передает запрос на DNS-сервер хоста hacker.com, чтобы получить адрес для xxx.hacker.com. Но DNS-сервер хакера модифицирован, чтобы сохранять всю информацию о запросах: имя поддомена(xxx) и IP-адрес запросившего(DNS-сервер провайдера). А теперь самое интересное. XXX – это идентификатор сессии клиента, например, 347205.hacker.com. Значит, если из адреса 50.50.50.50 поступил lookup запрос на 347205.hacker.com, то для пользователя, имеющего сессию 347205, DNS-сервер провайдера - это 50.50.50.50. Инициировать такой запрос очень просто, достаточно сослаться на ресурс из домена, например, на изображение: Цитата:
Комплексное решение В зависимости от ситуации, хакер может применить те или иные методы. Каждый из способов специфичен, поэтому в некоторых случаях придется отказаться от некоторых из них. Например, вариант с использованием PHP будет работать даже через рисунок: Цитата:
Цитата:
PHP код:
Цитата:
Цитата:
Цитата:
Для конечных пользователей можно лишь посоветовать использовать анонимные прокси, отключить поддержку Java и Flash. Не самая радужная перспектива, зато полезная штука для соблюдения корпоративной безопасности. Взято с сайта журнала "Хакер" тут |
| Время: 20:42 |