Как я взломал Facebook и обнаружил чужой бэкдор

- КиТ :: Будь в СЕТИ!

Исследователь по безопасности Orange Tsai взломал один из серверов Facebook и обнаружил бэкдор для сбора учетных записей сотрудников компании, оставленный злоумышленником. Как пишет исследователь в своем блоге, его всегда больше привлекали сервер-сайд атаки, нежели клиент-сайд (XSS и т.д). В 2012 году Facebook запустил BugBounty программу, которая побудила исследователя принять участие в поиске уязвимостей на серверах этой популярной социальной сети. В первую очередь проводится этап разведки и сбора информации, или т.н

recon по объекту атаки.

Исследователь поставил себе несколько целей:

Что можно обнаружить с помощью запросов Google Hacking?; Сколько используется подсетей класса B и C?; Whois, reverse-ip и axfr запросы; Используемые доменные имена, поддомены; Программное и техническое оснащение оборудования (вендоры, версии ПО и т.д.); Возможные утечки исходных кодов на сервисах Github или Pastebin И т.д.

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

Используя технику reverse whois им был обнаружен интересный домен — tfbnw.net. По данному названию он предположил что имеет дело с TheFacebook Network.

На этом домене располагался поддомен vpn.tfbnw.net, на котором находился веб-интерфейс Juniper SSL VPN. К сожалению исследователя эта версия не содержала публичных уязвимостей. Тем не менее, исследовав эту подсеть C-класса он обнаружил несколько интересных сервисов:

Mail Server Outlook Web App; F5 BIGIP SSL VPN; CISCO ASA SSL VPN; Oracle E-Business; MobileIron MDM;

Также, среди этих IP-адресов был обнаружен сервер files.fb.com. Судя по футеру веб-приложения использовался Accellion’s Secure File Transfer (также известный под аббревиатурой FTA): FTA является продуктом, который обеспечивает безопасную передачу файлов, общий доступ к файлам и синхронизации, а также интеграцию с механизмами входа в систему, включая AD, LDAP и Kerberos. Версия Enterprise поддерживает службы SSL VPN.

Исследователь попытался найти актуальный публичный эксплоит для этой уязвимости и обнаружил упоминание об уязвимой версии 0.18 ().

Версию можно определить запросом “/tws/getStatus”. На сайте была установлена последняя версия — 0.20, не содержащая вышеописанных уязвимостей.

Если не получилось найти уязвимости методом черного ящика — их можно попытаться найти белым. Исследователь скачал исходные коды FTA и приступил к поиску уязвимостей в этом продукте.

Исследовав приложение, было сделано несколько выводов:

Веб-интерфейс представляет из себя комбинацию Perl и PHP; PHP был обфусцирован с помощью IonCube; Использовалось множество Perl-демонов.

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

Результатом исследований FTA стало нахождение:

3 уязвимости класса XSS; Pre-Auth SQL-инъекция приводящая к удаленному выполнению кода (Remote Code Execution); Предиктивный secret-key, приводящий к удаленному выполнению кода (Remote Code Execution); 2 уязвимости, приводящие к локальному повышение привилегий (Local Privilege Escalation).

Помимо отправки сообщения об уязвмостях в Facebook Security Team, были отправлены соответствующие уведомления и вендору уязвимого ПО — компании Accellion. Уязвимостям присвоены следующие CVE:

CVE-2016-2350 CVE-2016-2351 CVE-2016-2352 CVE-2016-2353

(Больше деталей будет раскрыто после применения политики раскрытия/неразглашения уязвимостей).

Т.н. «залитие шелла» с помощью sql-injection: После получения доступа к серверу исследователь выполнил вполне предсказуемые шаги по изучению серверного окружения для минимизации обнаружения. Им были обнаружены:

Блокировка исходящих TCP и UDP соединений на порты 53, 80 и 443; Удаленный сервер Syslog; Включенный журнал auditd.

Несмотря на запрещающие правила фаервола для исходящих соединений исследователю удалось установить соединение с помощью ICMP-туннеля.

После того, как исследователю удалось установить приемлемый контроль над веб-сервером он обнаружил некоторые странные сообщения об ошибках в логах /var/opt/apache/php_error_log: Исследовав сообщения об ошибках и перейдя в затронутые директории он обнаружил веб-шелл, оставленный предыдущим «посетителем». Содержимое некоторых «интересных» файлов:

sshpass

bN3d10Aw.php

uploader.php

d.php

sclient_user_class_standard.inc

В require_once_once последнего файла содержится вызов «штатного» файла sclient_user_class_standard.inc.orig для проверки пароля. Злоумышленник использовал модифицированный файл в качестве своеобразного прокси для сбора GET и POST запросов, значения COOKIES в plain-text.

Неизвестный злоумышленник формировал лог-файл, который без труда можно было получить со взломанного веб-сервера: Пример перехваченной учетной записи: C 1 по 7 февраля было перехвачено порядка 300 учетных записей пользователей "@fb.com" и "@facebook.com":

Обычные пользователи — учетные записи хранятся в БД и шифруются «солёным» SHA256. Сотрудники Facebook (@fb.com) авторизуются по протоколу LDAP.

Данные, полученные злоумышленником могли привести к компрометации смежных сервисов (VPN, OWA и т.д.).

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

Каждые несколько дней злоумышленник чистил логи: Архивировал файлы: Исследовал внутреннюю сеть: Использовал ShellScript для сканирования внутренней сети, но забыл перенаправить STDERR: Пытался соединиться с LDAP-сервером: Пытался получить прямой доступ к OWA: Пытался украсть корневой ssl-сертификат: После проверки в браузере видно, что files.fb.com подписан сертификатом fb.com: Исследователь сообщил о выявленной уязвимости и активности злоумышленника на сервере техническим специалистам компании Facebook. Анализ логов показал что было два вторжения в систему — в июле и сентябре. Был ли это один и тот же злоумышленник — неизвестно. Июльский инцидент произошел как раз в момент появления эксплоита к вышеуказанной CVE-2015-2857 от Rapid7 в составе Metasploit Framework.

ПодпискаБудь в СЕТИ! Новости социальных сетей - всегда актуальное
 
Группы: ВК | OK | Tg