Компания
548,77
рейтинг
27 апреля 2013 в 17:42

Разное → Linux/Cdorked.A: хроники нового Apache-бэкдора

На прошлой неделе коллеги из Sucuri прислали нам модифицированную версию бинарного файла веб-сервера Apache, который перенаправлял некоторые, адресованные к нему запросы, на набор эксплойтов Blackhole Exploit Kit. Проведенный экспертами нашей антивирусной лаборатории анализ показал, что эта Linux-угроза, получившая название Linux/Cdorked.A, предназначена для перенаправления трафика на вредоносные сайты. Информация Sucuri об этом инциденте.

В процессе анализа мы пришли к выводу, что Linux/Cdorked.A представляет из себя наиболее сложный Linux-бэкдор из всех, что мы видели прежде. С помощью нашей облачной технологии ESET Live Grid мы получили статистику о сотнях скомпрометированных веб-серверов. В отличии от других подобных угроз, бэкдор не оставляет каких-либо следов своей деятельности на жестком диске скомпрометированного хоста, что заметно усложняет его обнаружение. Вместо этого, он хранит всю используемую им информацию в памяти, без привлечения жесткого диска. Кроме этого, злоумышленники используют обфусцированные HTTP-запросы для передачи служебной информации вредоносному коду, которые не фиксируются в лог-файле работы Apache. Таким образом следы взаимодействия вредоносного кода с C&C сервером также отсутствуют.



Бинарный файл Linux/Cdorked содержит все важные строки в зашифрованном виде, при этом используется известная схема XOR со статическим ключом. Версия Linux/Cdorked, которую мы анализировали содержит около 70 таких строк, при этом использовался ключ, указанный ниже на скриншоте (27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F).


Рис. Код расшифровки строк.


Рис. Ключ для расшифровки.

Как упоминалось выше, бэкдор не использует файлы на диске для служебных целей. Вместо этого, он выделяет около 6 MB общей памяти (shared memory) для хранения своих данных и информации о конфигурации. Этот блок памяти, называемый POSIX Shared Memory, используется всеми дочерними процессами Apache, также к нему может получить доступ любой другой процесс в системе, поскольку авторы вредоносного кода не ограничивают его использование с использованием прав доступа. На скриншоте ниже показаны права доступа к этому региону общей памяти (чтение и запись для всех).


Рис. Получение доступа к блоку общей памяти.

Существует два способа, с помощью которых атакующий может контролировать поведение скомпрометированного сервера: через обратное подключение с использованием командной строки и с помощью специальных команд. Оба этих способа активируются через HTTP-запросы. Первый метод с использованием командной строки вызывается через GET запрос HTTP протокола. Он исполняется, когда происходит запрос специального пути, при этом строка имеет определенный формат и содержит имя хоста и порт для соединения. Клиентский IP-адрес используется как ключ для расшифровки передаваемой строки, т. е. 4-байтовый XOR-ключ. Дополнительно, IP-адрес, указанный в заголовках пакетов X-Настоящий_IP или X-Перенаправленный_на будет замещать клиентский IP как ключ для расшифровки. Это означает, что мы можем изготовить заголовок для X-Настоящий_IP, который будет выступать как ключ "\x00\x00\x00\x00". Строка запроса должна быть в hex-формате перед отправкой.


Рис. Пример исполнения команды.

Пока злоумышленник имеет доступ к командной строке, активное HTTP-соединение не будет разорвано. Это означает, что активность вредоносного кода может быть замечена, если проверить продолжительные по времени HTTP-подключения. С другой стороны, лог Apache не предоставляет никакой информации об этом подключении, поскольку вредоносный код контролирует появление этой информации.

Скомпрометированный веб-сервер осуществляет перенаправление клиента на вредоносные веб-страницы, для этого код бэкдора добавляет закодированную в формате base64 строку запроса, которая содержит информацию об оригинальном URL и был ли запрос адресован к js-файлу, для того, чтобы сервер смог предоставить правильную полезную нагрузку.



Пример такой строки:

hxxp://dcb84fc82e1f7b01. xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3
Zja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2ZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG9hY3Vsb3VzLjEuOC4yLm1pbi5qcw==


В расшифрованном виде мы видим следующие параметры:

js=1&nvcbimuf=ccvckqju&time=1304161827-360453650&src=232&surl=www.infectedserver.com&sport=80&key=13D90950&suri=/forum/wcf/js/3rdParty/protoaculous.1.8.2.min.js

Параметр «surl» указывает на скомпрометированный (зараженный) хост, а «suri» указывает на оригинальный запрос.

После перенаправления, для браузера клиента устанавливаются cookie, так что в дальнейшем, исключено его повторное перенаправление. Также этот cookie устанавливается в том случае, если запрашивается веб-страница, похожая на страницу администрирования сервера. Вредоносный код проверяет такие аргументы как URL, имя сервера, поле referrer на совпадение следующих строк: "*adm*", "*webmaster*", "*submit*", "*stat*", "*mrtg*", "*webmin*", "*cpanel*", "*memb*", "*bucks*", "*bill*", "*host*", "*secur*", "*support*". Возможно такие проверки делаются для того, чтобы избежать отправки вредоносного содержимого администраторам веб-сайта, таким образом факт компрометации обнаружить будет сложнее. Скриншот ниже показывает часть кода, ответственную за обработку cookie.



Для успешного перенаправления вредоносный код так же проверяет некоторые другие аргументы запроса, например, проверяется наличие полей Accept-Language, Accept-Encoding, Referrer.

Нами были обнаружены 23 команды, которые Linux/Cdorked.A может отправить на сервер через POST-запрос HTTP с использованием специально сформированного URL. Запрос должен содержать поле cookie, которое начинается с маркера "SECID=". Строка запроса должна иметь два hex-байта, которые представляют собой значения, зашифрованные с помощью клиентского IP-адреса. Параметр SECID также используется как аргумент в некоторых других командах. Мы считаем, что URL-адреса, которые используются бекдором для перенаправления посетителей используют именно этот метод. Информация об этих адресах будет храниться в зашифрованном виде, с использованием общей памяти. Также очевидно, что условия для перенаправления устанавливаются следующим образом: белый список user agent-ов, для которых редиректы могут быть заранее настроены и черный список IP-адресов, для которых перенаправление не осуществляется.

Полный список команд, которые поддерживает бэкдор «DU», «ST», «T1», «L1», «D1», «L2», «D2», «L3», «D3», «L4», «D4», «L5», «D5», «L6», «D6», «L7», «D7», «L8», «D8», «L9», «D9», «LA», «DA».

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



Как упоминалось ранее, права доступа на блок общей памяти позволяют получить к нему доступ любому работающему в системе процессу. Мы разработали бесплатный инструмент (dump_cdorked_config.py), который поможет системным администраторам проверить наличие такого блока памяти и сохранить его в файл. Наши специалисты также рекомендуют использовать инструмент debsums для Debian и Ubuntu систем, а также команду “rpm –verify” для RPM-based Linux систем, которые позволят проверить целостность модулей вашего Apache сервера. Проверка на наличие блока общей памяти является рекомендованным способом убедиться в том, что вы не заражены. Наша антивирусная лаборатория заинтересована в получении таких дампов памяти для дальнейшего анализа.

На момент написания статьи, система отслеживания угроз ESET Live Grid показывает сотни веб-серверов, которые были скомпрометированы этим бэкдором. При этом тысячи посетителей этих серверов перенаправлялись на вредоносный контент. В ближайшее время мы опубликуем больше информации о ситуации с Linux/Cdorked.A.
Автор: @esetnod32
ESET NOD32
рейтинг 548,77

Комментарии (32)

  • +6
    Товарищи, ставьте NGINX (хотя бы как прокси).
    • +4
      В случае использования apache только для php от него вообще можно безболезненно отказаться, за одно сэкономив памяти.
      • +1
        А его ни для чего другого в большинстве случаев и не используют.
        • 0
          Ну да, конечно. А как же всякие mod_perl, mod_python и прочие ruby?
          • +1
            Тыкните пальцем в того извращенца, кто использует apache для ruby :) Обычно — unicorn, thin, puma. Для питона uwsgi гораздо удобнее.
          • 0
            На свалке.
    • +1
      А как это спасет от подмены его бинарных файлов с места загрузки дистрибутива или с работающего сервера?
      • –2
        Ну по моему, апач не первый раз встречается в сообщениях об уязвимости.
        • +2
          Апач скорее всего ни при чём, сервер должен быть порутан: «We also don’t have enough information to pinpoint how those servers are initially being hacked, but we are thinking through SSHD-based brute force attacks.»
    • 0
      Я просто оставлю это здесь… http://www.securityfocus.com/archive/1/526439
  • +11
    Дополнительно, IP-адрес, указанный в заголовках пакетов X-Настоящий_IP или X-Перенаправленный_на будет замещать клиентский IP как ключ для расшифровки
    Какой странный способ перевода заголовков. Понятнее будет, если вы напишите как они выглядят, а в скобках укажете перевод.
  • –4
    Не ради минусов на харбре, но просто интересно, что такого в Apache, почему его нельзя заменить nginx? Реально интересует опыт тех, кто не заменил ещё Apache. htaccess понятно, но его можно эмулировать, но не факт при shared-хостинге. Но в этом случае можно использовать Apache 1.3.
    • 0
      Для подавляющего большинства заменять .htaccess просто лениво либо недостаточно знаний. И клали они на безопасность под видом «да кому я нужен».
      • +4
        В данном случае апач не причем. Точно такой же бэкдор можно сделать и для нгинкс. Если уже не сделали.
        • +2
          Я отвечал на вопрос, не более.
        • 0
          уже сделали
          Linux rootkit in combination with nginx
          то ли ещё будет…
          • 0
            Никакого отношения указанный по ссылке руткит к nginx не имеет. Просто nginx-у не повезло быть установленным на том сервере.
    • +1
      Кстати, а как эмулировать htaccess?
      • 0
        Иногда бывает тяжело. Вот в этом случае blog.tavda.net/2012/03/microcosm-lighttpd-nginx.html я переделывал конфиг из lighttpd в конфиг nginx. В документации есть только пример .htaccess. Пришлось дополнить документацию. Благо, проект опенсорсный.
      • 0
        Учитывая, что бэкэндом зачастую выступает PHP и htaccess используется для управления поведения интерпретатора, то можно юзать .user.ini файлы.

        Но в целом htaccess для nginx это всячески порицаемая практика.
      • +2
        Не нужно эмулировать, нужно переписать логику htaccess под nginx в секцию server {}, тем более обычно там что-то вроде:

        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule .* index.php/$0 [PT,L]
        

        которое замещается одной строкой

        try_files $uri $uri/ /index.php?$query_string;
        
  • +6
    Расскажите кто-нибудь для тех, кто в танке: А как происходит подмена исполняемых модулей Apache?
    Сложно представить, что сисадмин запускает на сервере (за работоспособность которого ему голову могут оторвать) «левые» програмки. А если бы был заражен репозиторий, то проблема коснулась бы не считанных сотен серверов, а прошлась бы по планете пандемией.
    • 0
      Согласно исходнику, репозиториев не касается, т.к. cPanel компилирует апач. Там же пишут, что заражение наиболее вероятно через брут ssh.
      • 0
        давайте не будем давать руту ssh
        • 0
          Я бы дополнил: «давайте не будем давать парольный ssh root-у».
          • 0
            У меня включен SSH руту, при этом используются ключи, а в качестве запасного варианта — 25-символьный пароль из букв разного регистра и цифр. Этого достаточно?
            • +2
              sshd не имеет ограничение на количество попыток входа. К примеру, вот количество таких попыток начиная с 21-ого числа у меня:
               for day in `seq 21 28`; do echo -n "$day: "; grep "Apr $day" /tmp/auth.log | grep failure | wc -l; echo; done
              21: 1189
              
              22: 1723
              
              23: 1464
              
              24: 1466
              
              25: 6838
              
              26: 751
              
              27: 2822
              
              28: 1228
              
              


              25 символов конечно немало, но при современных мощностях это вполне посильная цифра для перебора особенно если пароль на сервере меняется не очень часто (а то не менялся со времен установки сервака). В общем есть хочется сохранять парольный вход, то стоит менять почаще пароль + использовать iptables, fail2ban или что-то другое для ограничение скорости коннектов, а то и бана адресов с неудачным входом.
              • 0
                Круто. Меня всегда воодушевляли люди, которые знают bash так хорошо.
                • +1
                  Вы же не серьёзно, правда?:)

                  for day in `seq 21 28`; do echo -n "$day: "; grep -Ec "Apr $day.*failure" /tmp/auth.log; done
            • 0
              Конечно, достаточно! Современные растущие мощности не ускоряют подбор пароля к удалённому сервису; это не то же самое, что подбирать пароль к локальному файлу.

              2-5 тысяч паролей в день у alekciy — это неделя только на то, чтобы проверить список самых популярных паролей, вроде «12345678», «555» и английских слов. sshd писали эксперты, он не даёт перебирать слишком быстро, а с fail2ban это становится ещё сложней.

              25 символов — это даже лишка. Тепловая смерть вселенной (или технологическая сингулярность) наступит на порядки раньше. Если я верно помню расчёты, не-словарный пароль из 7 букв/цифр будет как раз на грани того, что можно перебрать за несколько лет, всё, что больше — безопасно.

              Впрочем, если кому не лень заглянуть в sshd.conf, найти там максимальную частоту попыток входа, и просчитать необходимую сложность — буду рад увидеть точный ответ.
              • 0
                Почему не укоряют? Таже генерация радужных таблиц очень даже зависит от имеющихся мощностей. Под вычислительными мощностями я понимаю не только вертикальное наращивание гигагерц, флопсов и гигабайт, но и горизонтальное — технологии распределенных вычислений. И тут не суть важно локальный это файл или удаленный сервис. Если на последнем нет ограничений на скорость попыток входа, то распределенный атакующий бот может полностью утилизировать ресурсы сервера в попытке брудфоста. А у дедика вычислительные возможности, как и канал, обычно довольно приличные.

                Но в целом учитывая даже дефолтные настройки sshd (MaxAuthTries, MaxSessions, MaxStartups) и отсутствие других ограничительных механизмов, при рандомном пароле в 25 символов можно спать спокойно.
  • 0
    подкиньте такую цветовую схему для IDA :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное