Полезные (?) советы школы хакеров ЦРУ

в 17:38, , рубрики: WikiLeaks, взлом, вредоносное ПО, информационная безопасность, разведка, хакеры, ЦРУ, метки:

В новой утечке данных на WikiLeaks содержатся советы о том, как нужно и как не нужно писать эксплоиты

image

В данных, выложенных на WikiLeaks, содержатся тысячи файлов, относящихся к группе разработчиков ЦРУ (Engineering Development Group, EDG). Эта организация из центра киберразведки ЦРУ отвечает за создание инструментов взлома цифровых устройств по всему миру – для достижения целей ЦРУ. Утекли документы с сервера, используемого для отслеживания и документирования проектов.

Многие из этих документов не засекречены – там, к примеру, можно найти инструкции от Lockheed Martin и других производителей. Большая часть имеет гриф «секретно», включая такие безобидные вещи, как инструкция для начинающих по Microsoft Visual Studio – судя по всему, любимый инструмент подразделения EDG, департамента прикладных разработок (Applied Engineering Department, AED). Также там можно найти немного компонентов для создания мемов и анимированные GIF из манга-сериала Триган.

У небольшой части документов стоит гриф «совершенно секретно». Раздел с этими документами отмечен, как «особые данные» (Special Intelligence, SI) и NOFORN (не распространять за пределами страны). Из первой группы, состоящей из более чем 1000 документов, на таком уровне засекречено всего два параграфа. Эти данные описывают детали того, как должны работать криптографические функции инструментов подразделения ЦРУ по работе с сетями и как ЦРУ получает и подготавливает телефоны для использования в своей лаборатории эксплоитов.

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

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

Чтобы продемонстрировать это, мы прокомментировали некоторые выдержки из секретов разработки вредоносов от AED. Многие из этих правил применимы к разработке любого приложения из области компьютерной безопасности. Большая их часть связана с затруднением исследования этих приложений – с тем, чтобы команде противника было сложнее определить и разобраться в том, как работает вредонос. Среди некоторых банальных вещей по поводу правил написания кода встречаются и такие:

1. Не оставляйте визитных карточек

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

«Не оставляйте меток даты и времени, таких, как временные метки компилятора, линкера, билдера, время доступа и т.п., соответствующие рабочему времени на территории США (с 8 утра до 6 вечера по Восточному времени)». Такие артефакты часто используются аналитиками для определения как часть процесса по определению страны-источника вредоносного ПО.

Разработчикам рекомендуют использовать время UTC для всех операций, зависящих от времени. Это обеспечит связную работу и отсутствие намёков на какую-то определённую временную зону.

«Удаляйте всю отладочную информацию, манифесты [от Microsoft Visual C++], пути сборки, имена разработчиков из финальной сборки бинарного файла». Такие вещи тоже можно использовать для установления авторства. По тем же причинам документы уговаривают разработчиков «не оставлять в бинарниках данные, указывающие на причастность к разработке или использованию этого инструмента ЦРУ, правительства США или их партнёрских компаний».

Встречается одно из основных предупреждений по безопасности: «Не храните в бинарнике данные, содержащие терминологию ЦРУ или правительства США, названия отделов, кодовые названия операций или другую терминологию».

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

2. Не нарушайте работу компьютера жертвы

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

«Не выполняйте операции, способные заставить компьютер перестать отвечать на запросы пользователя (всплески загрузки CPU, мерцание экрана, зависание, и т.п.» – говорится в документе.
«Не выполняйте операции с диском, из-за которых компьютер может перестать отвечать на запросы пользователя или подать сигнал системному администратору». Последнее, что нужно в такой ситуации – если кто-то посмотрит в инспектор системы и обнаружит, что программа Notepad.exe отжирает все ресурсы CPU, сети и ввода/вывода накопителя.
«Предусмотрите настройку максимального размера и количества записываемых файлов». Это, к примеру, предотвратит заполнение накопителя компьютера, после которого повышается риск инспекции компьютера специалистом из службы поддержки.

По той же причине документ рекомендует: «Не создавайте файлов crashdump и coredump, не вызывайте „голубой экран“, всплывающие диалоги Dr Watson и другие артефакты в случае падения программы». Сообщения об ошибках работают в обе стороны – они пригодятся как разработчикам, так и исследователям программ. Разработчикам AED рекомендуют специально ронять их программы, чтобы убедиться, что они не выдают себя в этом случае.

Полезные (?) советы школы хакеров ЦРУ - 2
Эти наставления такие же современные, как этот мейнрейм IBM System/370

3. Используйте шифрование

Ещё одна из особенностей незаметной работы – шифрование используемых инструментом данных; в памяти, на диске, в сети. Один из документов содержит следующие советы:

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

«Не записывайте на диск данные в виде простого текста», это быстро может привести к неудобным ситуациям. «Шифруйте все записываемые на диск данные» и «используйте безопасное затирание [перезапись данных нулями] при удалении данных с диска». Удалённые таким образом файлы нельзя будет восстановить.
«Используйте end-to-end шифрование для всех сетевых коммуникаций» – ведь пассивный сбор нешифрованных данных, уходящих в сеть, всё испортит.
Используйте стандартные интернет-протоколы, чтобы ваши коммуникации сливались с другим сетевым трафиком – а не собственный протокол, пытающийся сойти за что-то другое. Неправильно реализованные протоколы будут выглядеть как неправильный трафик на сетевом мониторе типа Wireshark, что может привлечь внимание.

Не полагайтесь только на SSL/TLS для обеспечения безопасности данных" – поскольку SSL прокси подвержены атаке MitM. Это вышло боком даже для самых безопасных приложений для передачи сообщений.
«Используйте переменный размер и случайные времена отправки [jitter] сетевых сообщений. Не отправляйте предсказуемые пакеты фиксированного размера и времени отправки. Правильно подчищайте сетевые соединения. Не оставляйте за собой остаточных соединений». Короче, смена размера и времени отправки сообщений поможет вашему инструменту меньше рекламировать своё присутствие.

4. Не облегчайте работу исследовательской команды противника

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

«Удаляйте вывод системы отладки из финальной сборки» – поскольку нет ничего удобнее для третьего лица, пытающегося выяснить, что делает программа, чем оставляемые ею инструменты отладки.
«Не вызывайте явно и не импортируйте функции, не соответствующие явному предназначению программы». Иначе говоря, если вы притворяетесь программой notepad.exe, она не должна вызывать процессы, которые не вызывала бы notepad.exe – это может вызывать подозрение и облегчить задачу по распознаванию истинного предназначения вашей программы при помощи статического анализа.
«Не экспортируйте функции с очевидными названиями; если для работы требуется экспорт, используйте обыкновенное или не вызывающее подозрений имя». Поскольку код типа "__declspec( dllimport ) void DoVeryBadThings()" может привлечь внимание аналитика.
«Без нужды не читайте, не записывайте и не кэшируйте данные на диске». Увлечение записями может оставить следы.
Не превышайте необходимых размеров: «принимайте разумные усилия по минимизации размеров всех бинарников, предназначенных для закачки на компьютер жертвы (без использования упаковщиков или сжатия). Идеальный бинарник полнофункционального инструмента не должен быть больше 150 Кб».
«Не допускайте возможности повтора передачи данных по сети». Это значит, что связь между программой и управляющим сервером должна зависеть от даты и времени, чтобы нельзя было записать трафик и отправить его на приём инструменту в попытках разобраться, что он делает.

5. Проверяйте реакцию антивирусов на программы

Полезные (?) советы школы хакеров ЦРУ - 3
В разработке всё работало

Часть рекомендаций, содержащихся в документах ЦРУ, относится к продуктам «PSP/AV» – «personal security products», продуктам для личной безопасности. Такое название уже встречалось в документах ЦРУ, опубликованных хакерами Shadowbrokers.

Часть цикла разработки AED, согласно документам, включает тщательное тестирование в виртуальной среде DART. Эту систему создали в Lockheed Martin на основе VMware и нескольких программ для автоматического тестирования и развёртывания. Но такое окружение не всегда будет идеальным для всестороннего тестирования разрабатываемых в AED программ, особенно в части проверки на их обнаружение антивирусами.

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

Кроме того, для надёжности эти тесты нужно проводить на недавно обновлённых антивирусах, поскольку их производители регулярно отправляют клиентам новые данные. «Проверяйте работу с PSP с работающим (или недавно работавшим) интернет-соединением», говорится в документе. Также он предупреждает: «необходимо соблюдать баланс между выгодой и риском, который нужно тщательно взвесить. Хорошо известно, что антивирусы закачивают себе примеры исследуемых программ».

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

Устаревшие данные

Неизвестно, насколько тщательно разработчики из ЦРУ придерживались рекомендаций из утёкшего документа – в частности, поскольку они сами понимали, насколько эти рекомендации устарели. В 2013 году два пользователя системы написали об этом в разделе комментариев: «Многие из советов по работе разведки на этой странице некорректны». Другой добавил: «Честно говоря, всё это уже, скорее всего, устарело». Неизвестно, как давно обновлялись эти рекомендации.

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

Автор: SLY_G

Источник

Поделиться

* - обязательные к заполнению поля