10 июня южнокорейская хостинговая компания NAYANA стала жертвой атаки вируса-вымогателя Erebus (обнаружен Trend Micro как RANSOM_ELFEREBUS.A). В результате было заражено 153 Linux-сервера и более 3400 бизнес-сайтов, которые размещает хостинг-провайдер.
В сообщении, опубликованном на сайте NAYANA 12 июня, компания сообщила, что злоумышленники потребовали беспрецедентный по размеру выкуп в 550 биткоинов (BTC) или 1,62 миллиона долларов за расшифровку файлов на всех заражённых серверах. Вот часть переговоров с вымогателями:
Мой босс сказал мне дать вам хорошую цену, так как вы покупаете много машин,
550 BTC
Если у вас недостаточно денег, вам нужно взять кредит
У вас 40 сотрудников,
Годовой оклад каждого сотрудника 30 000 долларов США
Все сотрудники 30 000 * 40 = $ 1 200 000
Все сервера 550BTC = $ 1,620,000
Если вы не можете заплатить, вы банкрот.
Вам придётся смотреть в глаза своим детям, жене, клиентам и сотрудникам.
Также вы потеряете вашу репутацию и бизнес.
Вы получите множество судебных исков.
Позднее 14 июня NAYANA сообщила о договорённости по выплате в рассрочку суммы в размере 397,6 BTC (около 1,01 миллиона долларов США по состоянию на 19 июня 2017 года). 17 июня компания сообщила, что проведён второй из трёх платежей. 18 июня NAYANA начала восстанавливать сервера партиями. В настоящее время на некоторых серверах второй партии имеются ошибки баз данных. Третий платеж будет выплачен после успешного восстановления первой и второй партии серверов.
Хотя это не сопоставимо по сумме выкупа, случай напоминает произошедшее с больницей в Канзасе, сотрудники которой не получили полный доступ к зашифрованным файлам после выплаты. Вместо этого вымогатель требовал выкуп повторно.
Erebus был впервые замечен в сентябре 2016 года, тогда он распространялся через вредоносную рекламу. Вновь он появился в феврале 2017 года, уже используя метод, который обходил контроль учётной записи Windows. Вот некоторые из технических подробностей, которые доступны о Linux-версии Erebus:
Рисунок 1: Erebus имеет многоязычное уведомление о выкупе (вариант на английском языке выше)
Рисунок 2: Кадр демонстрационного видео от злоумышленников, в котором показано, как расшифровать файлы
Возможный вектор вирусных атак
Что касается того, как заражаются Linux-системы, мы можем только предположить, что Erebus, возможно, использовал эксплойт Linux. Например, на основе информации с открытым исходным кодом исследователи установили, что сайт NAYANA работает на ядре Linux 2.6.24.2, которое было скомпилировано ещё в 2008 году. Поэтому угрозы безопасности, такие как DIRTY COW, могут предоставить злоумышленникам root-доступ к уязвимым Linux-системам.
Кроме того, на веб-сайте NAYANA используются устаревшие версии Apache 1.3.36 и PHP 5.1.4, обе из которых были выпущены еще в 2006 году. Используемая NAYANA версия Apache запускается под пользователем nobody(uid=99), что указывает на то, что некоторые ранее известные эксплойты также могли быть использованы в атаке.
Рисунок 3: Erebus Linux Rasomware
Стоит отметить, что этот вирус-вымогатель ограничен по географическому охвату и, по сути, атаки сконцентрированы в Южной Корее. Однако, данные сервиса VirusTotal показывают иное — несколько образцов также были получены из Украины и Румынии. Возможной причиной может быть то, что они были отправлены другими исследователями в области информационной безопасности.
Процедура шифрования
Каждый файл, зашифрованный Erebus, будет иметь следующий формат:
| Header (0x438 bytes) |
| RSA-2048-encrypted original filename |
| RSA-2048-encrypted AES key |
| AES-encrypted RC4 key |
| RC4-encrypted data |
Сначала каждый отдельный файл, разбивается на блоки по 500 кБ и скремблируется с помощью алгоритма шифрования RC4 со случайно сгенерированными ключами. Затем ключ RC4 кодируется алгоритмом шифрования AES. AES-ключ снова зашифровывается с использованием алгоритма RSA-2048, открытый ключ которого сохраняется в файле.
Каждый файл имеет один общий для всех открытый ключ RSA-2048. Ключи RSA-2048 формируются локально, при этом необходимый для расшифровки закрытый ключ сохранён в зашифрованном при помощи дополнительного случайно сгенерированного (возможно, в том числе на основе Machine ID) AES-ключа. Анализ показывает, что дешифрование невозможно без получения RSA-ключей.
Целевые типы файлов
Обычно шифрование направлено на офисные документы, базы данных, архивы и мультимедийные файлы. Это характерно и для этой версии Erebus, которая шифрует 433 типа файлов, но также наблюдается направленность на шифрование веб-серверов и данных, хранящихся на них.
В таблице ниже указаны папки, которые ищет Erebus.
var/www/ — папки, в которых хранятся файлы/данные веб-сайтов, а файлы ibdata используются в MySQL:
| Included directories: | Excluded directories: |
| var/www/ | $/bin/ |
| Included files: | $/boot/ |
| ibdata0 | $/dev/ |
| ibdata1 | $/etc/ |
| ibdata2 | $/lib/ |
| ibdata3 | $/lib64/ |
| ibdata4 | $/proc/ |
| ibdata5 | $/run/ |
| ibdata6 | $/sbin/ |
| ibdata7 | $/srv/ |
| ibdata8 | $/sys/ |
| ibdata9 | $/tmp/ |
| ib_logfile0 | $/usr/ |
| ib_logfile1 | $/var/ |
| ib_logfile2 | /.gem/ |
| ib_logfile3 | /.bundle/ |
| ib_logfile4 | /.nvm/ |
| ib_logfile5 | /.npm/ |
Как защититься?
Одной уязвимой машины в сети иногда достаточно, чтобы заразить все подключенные системы и серверы. Учитывая риски для операционной деятельности, репутации и прибыли, компании должны проявлять инициативу в устранении таких угроз. Рекомендации по снижению рисков включают в себя:
- Резервное копирование важных файлов
- Отключение или минимизация количества сторонних или непроверенных репозиториев
- Применение принципа наименьших привилегий
- Обновление ПО серверов и терминалов (или использование виртуальных патчей)
- Регулярный мониторинг сети
- Проверка журналов событий для обнаружения признаков вторжения или заражения
Хеш-функции SHA256 RANSOM_ELFEREBUS.A:
0b7996bca486575be15e68dba7cbd802b1e5f90436ba23f802da66292c8a055f
d889734783273b7158deeae6cf804a6be99c3a5353d94225a4dbe92caf3a3d48
Мы обновим этот пост в случае, если будет получена новая информация об особенностях распространения вируса.
Комментарии (40)
BigEl
20.06.2017 12:23+3Как много пользователей Юникс-систем будет утверждать после этого, что но Линукс вирусов нет? Только «Окошки» страдают.
Вирусы пишут под популярные системы. Линукс вышел за грань гик-ОС, вирусописатели это увидели, вот результат.
Надеюсь случай не выйдет на поток и не будет похожего случая как с Вана-Крайем в мае 2017.
ErshoFF
20.06.2017 12:38-7Что подтверждает растущую популярность «Линукс».
И подающую «Окошков».
Если что-то растёт — что-то должно падать, общий объем=const.Stroce
20.06.2017 13:06+4Если общий объем константа, то не использовалась бы ни одна система, потому что в самом начале константа равнялась нулю)
Fox_exe
20.06.2017 12:46+6В любом софте есть дыры.
Но в статье идет речь про дыры, которые с 2006-2008 годов существуют и давно закрыты. Но компания решила последовать главному правилу сисадмина — «Работает — не трож!» и не обновлялась годами. «Результат немного предсказуем» (с).
zedroid
20.06.2017 12:58+10Уязвимость была закрыта всего 9 месяцев назад, а существовала 10 лет. Многие системы не могут быть обновлены on-the-air.
nikitasius
21.06.2017 09:09+1Многие системы не могут быть обновлены on-the-air
Для этого правильные пчелы, которые делают правильный мед, рассылают письма вроде "Пацаны, через 3 дня в 2 ночи будет даунтайм не дольше 2-3 минут, нам надо обновится. Мы сие прогнали на тесте, все путем".
BigEl
20.06.2017 13:06-1не обновлялась годами. «Результат немного предсказуем»
Вот вот. В народе бродит поговорка «пока не клюнут — не перекрестишься».
Я вот тоже на домашних системах в конце мая обновил все компы, отключалось перед выходом Вин10 (чтоб автоматом не обновиться, когда еще навязывали жестко). Тьфу-тьфу пронесло.
Остается только пожелать удачи всем пользователям и пожелания своевременных обновлений.
prishelec
23.06.2017 13:18Старый хакер успокаивает своего приемника: да не переживай ты, на твой век «дыр» в софте и серверах хватит. К сожалению: но что есть, то есть.
Crandel
20.06.2017 13:28+4Уязвимости в линукс системах находят постоянно, успевай только обновляться. Как бы люди ошибки делают периодически, такова наша природа. Вот только тут все от тебя зависит, а не нужно ждать, пока индусы в Майкрософт накидают очередной костыль, чтобы закрыть это решето.
optimizer
20.06.2017 23:05в этом топике мы не увидим «у меня стоит linux и я не заразился, что я делаю не так?»
KonstantinSpb
20.06.2017 12:46-1Гентушники тихо смеются над данными проблемами :)
Fox_exe
20.06.2017 12:47+4Все, кто обновляется своевременно сейчас ржут над NAYANA.
ErshoFF
20.06.2017 12:52+2А NAYANA может себе позволить выплатить часть денег ранее съэкономленных на обновлениях.
Wolfas
20.06.2017 15:34Это точно… Не просто так говорят.
Скупой платит дважды.
Экономия на обновлениях и людях всегда приводит к большим затратам. Не важно будь то безопасность или разработка.
AlexBin
20.06.2017 13:12+13Гентушники тихо смеются над данными проблемами :)
Хм, я думал гентушникам некогда смеяться.
vlreshet
20.06.2017 13:28+8Да и вообще, пакет «смех» надо сначала собрать и скомпилировать :)
LynXzp
20.06.2017 15:06Ну не знаю, как в генту, я тут недавно ставил Espressif SDK, список команд занимает… да вот он: https://github.com/esp8266/esp8266-wiki/wiki/Toolchain
А потом начинается самое веселое — скомпилировать пример (не тот что blink, а тот что IoT от самой Espressif) — вот это квест, в старом духе линукса когда репозиториев не существовало.
teecat
20.06.2017 13:07+1А самое интересное, что узнав о такой сумме выкупа на хостинг-провайдеров сейчас начнут атаки кому не лень. Вангую традиционную реакцию на успешную атаку или новость
AlexBin
20.06.2017 13:13+1Не переживайте, наши законодатели придумают какой-нибудь закон, который решит данную проблему.
teecat
20.06.2017 13:27Кстати да. Законодатели, реагирующие на новости (а не на мнения аналитиков), тоже традиционное событие. Встречал мнение, что новости могут писаться так, чтобы определенные политики автоматически самоподтягивались под раскрутку.
equity
20.06.2017 13:34Возможно, некоторые законы пишутся под предлогом чего-то, так предлогом может быть и безопасность хранения данных. Причины у законодателей есть свои.
Arty_K
21.06.2017 07:10+1Учитывая то, сколько хостеров до сих пор использует устаревший больше года назад BILL manager 4, это может быть очень перспективная ниша)
sotnikdv
21.06.2017 08:56+2Ключи RSA-2048 формируются локально, при этом необходимый для расшифровки закрытый ключ сохранён в зашифрованном при помощи дополнительного случайно сгенерированного (возможно, в том числе на основе Machine ID) AES-ключа. Анализ показывает, что дешифрование невозможно без получения RSA-ключей.
Окей, поверим. Итак, сформировали keyring локально. Зашифровали закрытый ключ паролем AES. Дальше что? А дальше у нас следующие возможности
1. Симметричный ключ аплоадится на сервер или получается с сервера (в т.ч. KDF от инфы с сервера). Нужен инет.
2. Симметричный ключ теряется. Декодирование невозможно
3. Используется KDF от машины. Декодирование возможно без оплаты.
4. Авторы накосячили в статье. Происходит банальное гибридное шифрование с использованием публичного ключа, вшитого в код. Заголовок файла на это и намекает. И никакой генерации keyring на клиенте не происходит.
Также вызывает вопрос использование скомпрометированного RC4, видимо сделали скорости ради, хотя имхо тупая идея.
fukkit
21.06.2017 09:06С такими кейсами в приличном обществе у битка должны начаться реальные проблемы.
ElvenSailor
21.06.2017 11:01Остались непонятными два момента:
1. Всё же, как они эту дрянь подхватили?
Версия ПО на сайте конторы и внутри хост-машин, в общем случае, никак не связаны. Хотя…
Тут больше похоже на утечку креденшелов админа.
2. Бэкапов вообще не было? или их тоже пошифровало?
В первом случае ребята редкостные оптимисты :)
Во втором интереснее.
misha057
21.06.2017 12:20Если были у них, например, ежедневные бекапы, а старые бекапы затирались, то стоило немного подождать, пока шифрованные бекапы перезапишут старые.
DeLuxis
Первый звоночек.
Сейчас начнут ломать все UNIX сервера подряд. Ибо бизнес будет платить, и суммы будут значительно крупнее чем у домохозяек.
Пошел обновляться…
XakRU
Звоночков было много, только звоночки говорили о другом. Вижу главную проблему не в ПО, а в людях, которые забыли про безопасность и бекапы.
webmasterx
И проверять бекапы